Ethereum Improvement Proposals (EIPs & ERCs) describe standards for the Ethereum platform, such as core protocol changes and application-level standards. Zola 2026-02-11T14:49:29+00:00 https://wg-eips.ritovision.com/category/core/atom.xml 2026-02-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Chris Matahttps://github.com/protocolwhisper https://wg-eips.ritovision.com/8149/

Verify multiple (z, y) evaluations against a single EIP-4844 blob commitment in one precompile call.

<h2 id="abstract">Abstract</h2> <p>Add a precompile that verifies multiple KZG openings <code>(z_i, y_i)</code> for a single <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> blob commitment, returning the same 64-byte output as the existing point-evaluation precompile.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> provides a point-evaluation precompile at <code>0x0A</code> costing 50,000 gas per opening. Contracts needing multiple blob values (e.g., fraud proofs) must pay this cost repeatedly. A batch interface verifies <em>k</em> openings in one call, reducing overhead.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>MULTI_POINT_EVALUATION_PRECOMPILE_ADDRESS</code></td><td><code>TBD</code></td><td>precompile address</td></tr> <tr><td><code>MAX_MULTI_POINTS</code></td><td><code>128</code></td><td>maximum number of evaluation points</td></tr> <tr><td><code>MULTI_POINT_EVALUATION_BASE_GAS</code></td><td><code>TBD</code></td><td>base gas cost</td></tr> <tr><td><code>MULTI_POINT_EVALUATION_PER_POINT_GAS</code></td><td><code>TBD</code></td><td>gas cost per evaluation point</td></tr> </tbody></table> <p>We introduce a precompile to perform multi KZG point evaluation:</p> <p>It verifies multiple KZG openings <code>(z_i, y_i)</code> for a single EIP-4844 blob commitment in one call. The verification uses BLS12-381 pairing operations internally to check the multi-point opening proof. Gas cost is defined by <code>MULTI_POINT_EVALUATION_BASE_GAS + MULTI_POINT_EVALUATION_PER_POINT_GAS * n</code> where <code>n</code> is the number of evaluation points.</p> <h3 id="input">Input</h3> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>versioned_hash : Bytes32</span></span> <span class="giallo-l"><span>commitment : Bytes48</span></span> <span class="giallo-l"><span>n : uint32 (big-endian)</span></span> <span class="giallo-l"><span>pairs : n × (z: Bytes32, y: Bytes32)</span></span> <span class="giallo-l"><span>proof : Bytes48</span></span></code></pre> <p>Total length: <code>132 + (n × 64)</code> bytes. All <code>z</code> and <code>y</code> MUST be strictly less than <code>BLS_MODULUS</code>.</p> <h3 id="output">Output</h3> <p>On success, return 64 bytes identical to <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>FIELD_ELEMENTS_PER_BLOB : uint256 (big-endian)</span></span> <span class="giallo-l"><span>BLS_MODULUS : uint256 (big-endian)</span></span></code></pre><h3 id="multi-point-evaluation-precompile">Multi-point evaluation precompile</h3> <p>Add a precompile at <code>MULTI_POINT_EVALUATION_PRECOMPILE_ADDRESS</code> that verifies multiple KZG openings <code>(z_i, y_i)</code> for a single EIP-4844 blob commitment.</p> <p>The precompile executes the following logic:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> multi_point_evaluation_precompile</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span> versioned_hash</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span>:</span><span class="z-constant">32</span><span>]</span></span> <span class="giallo-l"><span> commitment</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">80</span><span>]</span></span> <span class="giallo-l"><span> n</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span class="z-support">input</span><span>[</span><span class="z-constant">80</span><span>:</span><span class="z-constant">84</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 1</span><span class="z-keyword"> &lt;=</span><span> n</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> MAX_MULTI_POINTS</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 132</span><span class="z-keyword"> +</span><span> n</span><span class="z-keyword"> *</span><span class="z-constant"> 64</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> z_values</span><span>,</span><span> y_values</span><span class="z-keyword"> =</span><span> [</span><span>]</span><span>,</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>n</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> =</span><span class="z-constant"> 84</span><span class="z-keyword"> +</span><span> i</span><span class="z-keyword"> *</span><span class="z-constant"> 64</span></span> <span class="giallo-l"><span> z_i</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span class="z-support">input</span><span>[</span><span>offset</span><span>:</span><span>offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> y_i</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span class="z-support">input</span><span>[</span><span>offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>:</span><span>offset</span><span class="z-keyword">+</span><span class="z-constant">64</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> z_i</span><span class="z-keyword"> &lt;</span><span class="z-constant"> BLS_MODULUS</span><span class="z-keyword"> and</span><span> y_i</span><span class="z-keyword"> &lt;</span><span class="z-constant"> BLS_MODULUS</span></span> <span class="giallo-l"><span> z_values</span><span>.</span><span>append</span><span>(</span><span>z_i</span><span>)</span></span> <span class="giallo-l"><span> y_values</span><span>.</span><span>append</span><span>(</span><span>y_i</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> proof</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">84</span><span class="z-keyword"> +</span><span> n</span><span class="z-keyword">*</span><span class="z-constant">64</span><span> :</span><span class="z-constant"> 84</span><span class="z-keyword"> +</span><span> n</span><span class="z-keyword">*</span><span class="z-constant">64</span><span class="z-keyword"> +</span><span class="z-constant"> 48</span><span>]</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> kzg_to_versioned_hash</span><span>(</span><span>commitment</span><span>)</span><span class="z-keyword"> ==</span><span> versioned_hash</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> verify_kzg_proof_multi</span><span>(</span><span>commitment</span><span>,</span><span> z_values</span><span>,</span><span> y_values</span><span>,</span><span> proof</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> U256</span><span>(</span><span class="z-constant">FIELD_ELEMENTS_PER_BLOB</span><span>)</span><span>.</span><span>to_be_bytes32</span><span>(</span><span>)</span><span class="z-keyword"> +</span><span> U256</span><span>(</span><span class="z-constant">BLS_MODULUS</span><span>)</span><span>.</span><span>to_be_bytes32</span><span>(</span><span>)</span></span></code></pre> <p>The <code>verify_kzg_proof_multi</code> function performs multi-point opening verification using the <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> trusted setup and BLS12-381 pairing operations. Implementations typically use Lagrange interpolation to construct a polynomial through all <code>(z_i, y_i)</code> pairs, which has O(n²) complexity. When evaluation points align with roots of unity, FFT-based methods reduce this to O(n log n). The final verification step uses a single pairing check to verify all openings simultaneously.</p> <h3 id="gas-cost">Gas Cost</h3> <p>The gas cost for multi point evaluation is:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> gas_cost</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> MULTI_POINT_EVALUATION_BASE_GAS</span><span class="z-keyword"> +</span><span class="z-constant"> MULTI_POINT_EVALUATION_PER_POINT_GAS</span><span class="z-keyword"> *</span><span> n</span></span></code></pre> <p>Gas constants SHOULD ensure batching is cheaper than <code>n</code> separate <code>0x0A</code> calls for <code>n &gt; 1</code>. The verification internally uses BLS12-381 pairing operations, which are computationally expensive but enable efficient batch verification of multiple openings.</p> <h2 id="rationale">Rationale</h2> <ul> <li>Preserves <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> versioned-hash model and return format.</li> <li>Adds a new precompile rather than modifying <code>0x0A</code> to avoid compatibility risks.</li> <li><code>MAX_MULTI_POINTS = 128</code> bounds input size while enabling meaningful savings.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No changes to <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> transactions, <code>BLOBHASH</code>, or the existing precompile at <code>0x0A</code>.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Reject non-canonical field elements (<code>&gt;= BLS_MODULUS</code>).</li> <li>Implementations MUST use the same trusted setup and subgroup checks as <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>.</li> <li>Gas pricing MUST reflect actual computational cost.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2026-02-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dmitry Gusakovhttps://github.com/dgusakov Dmitry Chernukhinhttps://github.com/madlabman Greg Koumoutsoshttps://github.com/gkoumout https://wg-eips.ritovision.com/8148/

Allow setting custom balance thresholds for sweep withdrawals for validators with compounding withdrawal credentials (`0x02, 0x03`).

<h2 id="abstract">Abstract</h2> <p>This EIP proposes an optional mechanism to set custom balance thresholds for sweep withdrawals for compounding withdrawal credentials (<code>0x02, 0x03</code>) validators. This mechanism allows validators to specify above which balance they want their rewards to be swept to their withdrawal address, providing greater flexibility and control over their staking rewards.</p> <h2 id="motivation">Motivation</h2> <p>The current default sweep threshold (2,048 ETH) for validators using compounding withdrawal credentials (<code>0x02, 0x03</code>) may not meet the needs of all validators. Some validators may prefer to accumulate rewards on the validator balance, while others may want to sweep before reaching the current threshold of 2,048 ETH. By allowing optional custom sweep thresholds, validators can optimize their reward management according to their individual strategies and preferences.</p> <p>Since the introduction of the <code>0x02</code> compounding withdrawal credentials type, we have observed a very low rate of validators transitioning to <code>0x02</code>. One reason is that many validators do not want to wait until they accumulate 2048 ETH in rewards before being able to participate in the automatic sweep of withdrawals. While partial withdrawals were considered a viable method for manually withdrawing portions of the validator balance, this approach was not widely adopted by staking protocols, node operators, and solo stakers for several reasons. First, it requires a user-initiated transaction to perform a withdrawal. Second, partial withdrawals utilize the general exit queue, which makes the time between partial withdrawal initiation and fulfillment unpredictable and heavily dependent on network conditions (see the recent spike in exit queue size in October 2025). This EIP aims to address this issue by allowing validators to set a custom threshold for sweep withdrawals.</p> <p>A simple example illustrates the utility of this feature. Consider a validator who wishes to accumulate rewards on their validator balance until reaching 128 ETH, at which point they want to sweep the rewards to their withdrawal address. Without this feature, the validator would have to initiate partial withdrawals at certain intervals manually and wait in the partial withdrawals queue, which can be time-consuming and inconvenient. The first inconvenience is that if staking protocols widely adopt partial withdrawals at some point, the queue for these withdrawals might become long and unpredictable, similar to the exit queue. The second inconvenience is that the user must monitor the validator's balance and manually initiate partial withdrawals, which adds complexity and overhead to the staking process. The third inconvenience is the frequency with which the validator can request partial withdrawals. A 128-ETH validator will receive approximately 0.07 ETH in rewards each week. Initiating partial withdrawals TX, for such a low amount might be considered unreasonable. At the same time, the sweep cycle will likely drop to a weekly cycle relatively soon, allowing the validator to automatically receive these 0.07 ETH of rewards on their withdrawal credentials. In general, with this EIP, the validator can set their desired sweep threshold and automatically benefit from sweep withdrawals.</p> <p>The proposed mechanism is completely optional and does not change anything in the default registration / withdrawal / exit process for validators. It's just an additional feature that could be ignored if not interesting, but provides a useful feature for many validators incentivizing switching to compounding validators.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="constants">Constants</h3> <h4 id="execution-layer">Execution layer</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_TYPE</code></td><td><code>0x03</code></td><td>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> type prefix for set sweep threshold request</td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</code></td><td><code>TBD</code></td><td>Where to call and store relevant details about set sweep threshold request mechanism</td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td><td>Address used to invoke system operation on contract</td></tr> <tr><td><code>EXCESS_SET_SWEEP_THRESHOLD_REQUESTS_STORAGE_SLOT</code></td><td><code>0</code></td><td></td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT</code></td><td><code>1</code></td><td></td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_QUEUE_HEAD_STORAGE_SLOT</code></td><td><code>2</code></td><td>Pointer to the head of the set sweep threshold request message queue</td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT</code></td><td><code>3</code></td><td>Pointer to the tail of the set sweep threshold request message queue</td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_QUEUE_STORAGE_OFFSET</code></td><td><code>4</code></td><td>The start storage slot of the in-state set sweep threshold request message queue</td></tr> <tr><td><code>MAX_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK</code></td><td><code>16</code></td><td>Maximum number of set sweep threshold requests that can be dequeued into a block</td></tr> <tr><td><code>TARGET_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK</code></td><td><code>2</code></td><td></td></tr> <tr><td><code>MIN_SET_SWEEP_THRESHOLD_REQUEST_FEE</code></td><td><code>1</code></td><td></td></tr> <tr><td><code>SET_SWEEP_THRESHOLD_REQUEST_FEE_UPDATE_FRACTION</code></td><td><code>17</code></td><td></td></tr> <tr><td><code>EXCESS_INHIBITOR</code></td><td><code>2**256-1</code></td><td>Excess value used to compute the fee before the first system call</td></tr> </tbody></table> <h4 id="consensus-layer">Consensus layer</h4> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>MIN_SWEEP_THRESHOLD</code></td><td><code>MIN_ACTIVATION_BALANCE + Gwei(1 * 10**9)</code> (33 ETH)</td></tr> </tbody></table> <h3 id="execution-layer-1">Execution layer</h3> <h4 id="definitions">Definitions</h4> <ul> <li><strong><code>FORK_BLOCK</code></strong> -- the first block in a blockchain after this EIP has been activated.</li> </ul> <h4 id="set-sweep-threshold-request">Set sweep threshold request</h4> <p>The new set sweep threshold request is an <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request with type <code>SET_SWEEP_THRESHOLD_REQUEST_TYPE</code> consisting of the following fields:</p> <ol> <li><code>source_address</code>: <code>Bytes20</code></li> <li><code>validator_pubkey</code>: <code>Bytes48</code></li> <li><code>threshold</code>: <code>uint64</code></li> </ol> <p>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> encoding of a set sweep threshold request is computed as follows. Note that <code>threshold</code> is returned by the contract little-endian, and must be encoded as such.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>request_type</span><span class="z-keyword"> =</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_TYPE</span></span> <span class="giallo-l"><span>request_data</span><span class="z-keyword"> =</span><span> read_set_sweep_threshold_requests</span><span>(</span><span>)</span></span></code></pre><h4 id="set-sweep-threshold-request-contract">Set sweep threshold request contract</h4> <p>The contract has three different code paths, which can be summarized at a high level as follows:</p> <ol> <li>Add set sweep threshold request - requires a 56-byte input: validator public key concatenated with a big-endian <code>uint64</code> threshold value.</li> <li>Fee getter - if the input length is zero, return the current fee required to add a set sweep threshold request.</li> <li>System process - if called by the system address, pop off the set sweep threshold requests for the current block from the queue.</li> </ol> <h5 id="add-set-sweep-threshold-request">Add Set Sweep Threshold Request</h5> <p>If call data input to the contract is exactly <code>56</code> bytes, perform the following:</p> <ol> <li>Ensure enough ETH was sent to cover the current set sweep threshold request fee (<code>msg.value &gt;= get_fee()</code>).</li> <li>Increase set sweep threshold request count by 1 for the current block.</li> <li>Insert a set sweep threshold request into the queue for the source address, validator public key, and the threshold.</li> </ol> <p>Specifically, the functionality is defined in pseudocode as the function <code>add_set_sweep_threshold_request()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> add_set_sweep_threshold_request</span><span>(</span><span class="z-variable z-parameter z-function">validator_pubkey</span><span>:</span><span> Bytes48</span><span>,</span><span class="z-variable z-parameter z-function"> threshold</span><span>:</span><span> uint64</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Add a new request to the set sweep threshold request queue, provided a sufficient value to cover the fee was sent.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sufficient value was provided.</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span> get_fee</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>msg</span><span>.</span><span>value</span><span class="z-keyword"> &gt;=</span><span> fee</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Insufficient value for fee</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Increment the request count.</span></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span> count</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Insert into the queue.</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> queue_tail_index</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>,</span><span> msg</span><span>.</span><span>sender</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>,</span><span> validator_pubkey</span><span>[</span><span class="z-constant"> 0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>,</span><span> validator_pubkey</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">48</span><span>]</span><span class="z-invalid z-illegal"> ++</span><span> threshold</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span> queue_tail_index</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span></code></pre><h6 id="fee-calculation">Fee calculation</h6> <p>The following pseudocode can compute the cost of an individual set sweep threshold request, given a certain number of excess set sweep threshold requests.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_fee</span><span>(</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_SET_SWEEP_THRESHOLD_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>excess</span><span class="z-keyword"> !=</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Inhibitor still active</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_SET_SWEEP_THRESHOLD_REQUEST_FEE</span><span>,</span></span> <span class="giallo-l"><span> excess</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> fake_exponential</span><span>(</span><span class="z-variable z-parameter z-function">factor</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> numerator</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> denominator</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> factor</span><span class="z-keyword"> *</span><span> denominator</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> numerator_accum</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> +=</span><span> numerator_accum</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> (</span><span>numerator_accum</span><span class="z-keyword"> *</span><span> numerator</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span>denominator</span><span class="z-keyword"> *</span><span> i</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> output</span><span class="z-keyword"> //</span><span> denominator</span></span></code></pre><h5 id="fee-getter">Fee Getter</h5> <p>When the input to the contract has zero-length, interpret this as a get request for the current fee, i.e. the contract returns the result of <code>get_fee()</code>. The contract reverts if any value is sent to prevent loss of funds.</p> <h5 id="system-call">System Call</h5> <p>At the end of processing any execution block starting from the <code>FORK_BLOCK</code> (i.e. after processing all transactions), call <code>SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</code> as <code>SYSTEM_ADDRESS</code> with no calldata. The invocation triggers the following:</p> <ul> <li>The contract's queue is updated based on set sweep threshold requests dequeued and the set sweep threshold requests queue head/tail are reset if the queue has been cleared (<code>dequeue_set_sweep_threshold_requests()</code>)</li> <li>The contract's excess set sweep threshold requests are updated based on usage in the current block (<code>update_excess_set_sweep_threshold_requests()</code>)</li> <li>The contract's set sweep threshold requests count is reset to 0 (<code>reset_set_sweep_threshold_requests_count()</code>)</li> </ul> <p>In response to the system call, the contract returns an opaque byte array of concatenated SSZ-serialized dequeued requests. There's no specific reasoning behind it, except aligning with the existing behaviour of the similar EIP, see <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a>, and possible simplification of the processing flow for client teams. Each set sweep threshold request must appear in the EIP-7685 requests list in the exact order returned by <code>dequeue_set_sweep_threshold_requests()</code>.</p> <p>Additionally, the system call and the processing of that block must conform to the following:</p> <ul> <li>The call has a dedicated gas limit of <code>30_000_000</code> (<code>SYSTEM_TRANSACTION_GAS</code>) and is not subject to the transaction limit cap introduced in <a href="https://wg-eips.ritovision.com/7825/">EIP-7825</a>.</li> <li>Gas consumed by this call does not count against the block’s overall gas usage.</li> <li>Both the gas limit assigned to the call and the gas consumed are excluded from any checks against the block’s gas limit.</li> <li>The call does not follow <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> fee burn semantics — no value should be transferred as part of this call.</li> <li>If there is no code at <code>SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</code>, the corresponding block <strong>MUST</strong> be marked invalid.</li> <li>If the call to the contract fails or returns an error, the block <strong>MUST</strong> be invalidated.</li> </ul> <p>The functionality triggered by the system call is defined in pseudocode as the function <code>read_set_sweep_threshold_requests()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Public function #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> read_set_sweep_threshold_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> dequeue_set_sweep_threshold_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> update_excess_set_sweep_threshold_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> reset_set_sweep_threshold_requests_count</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>.</span><span>join</span><span>(</span><span>ssz</span><span>.</span><span>serialize</span><span>(</span><span>r</span><span>)</span><span class="z-keyword"> for</span><span> r</span><span class="z-keyword"> in</span><span> reqs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Helpers #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ValidatorSetSweepThresholdRequest</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> source_address</span><span>:</span><span> Bytes20</span></span> <span class="giallo-l"><span> validator_pubkey</span><span>:</span><span> Bytes48</span></span> <span class="giallo-l"><span> threshold</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> dequeue_set_sweep_threshold_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_head_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> num_in_queue</span><span class="z-keyword"> =</span><span> queue_tail_index</span><span class="z-keyword"> -</span><span> queue_head_index</span></span> <span class="giallo-l"><span> num_dequeued</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>num_in_queue</span><span>,</span><span class="z-constant"> MAX_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>num_dequeued</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> (</span><span>queue_head_index</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span></span> <span class="giallo-l"><span> source_address</span><span class="z-keyword"> =</span><span> address</span><span>(</span><span>sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">20</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> validator_pubkey</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span class="z-keyword"> +</span></span> <span class="giallo-l"><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">16</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> threshold</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">16</span><span>:</span><span class="z-constant">24</span><span>]</span></span> <span class="giallo-l"><span> req</span><span class="z-keyword"> =</span><span> ValidatorSetSweepThresholdRequest</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> source_address</span><span class="z-keyword">=</span><span>Bytes20</span><span>(</span><span>source_address</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> validator_pubkey</span><span class="z-keyword">=</span><span>Bytes48</span><span>(</span><span>validator_pubkey</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> threshold</span><span class="z-keyword">=</span><span>uint64</span><span>(</span><span>threshold</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> reqs</span><span>.</span><span>append</span><span>(</span><span>req</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_queue_head_index</span><span class="z-keyword"> =</span><span> queue_head_index</span><span class="z-keyword"> +</span><span> num_dequeued</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> new_queue_head_index</span><span class="z-keyword"> ==</span><span> queue_tail_index</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Queue is empty, reset queue pointers</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span> new_queue_head_index</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> reqs</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> update_excess_set_sweep_threshold_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_SET_SWEEP_THRESHOLD_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> ==</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TARGET_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK</span><span>:</span></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_SET_SWEEP_THRESHOLD_REQUESTS_STORAGE_SLOT</span><span>,</span><span> new_excess</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> reset_set_sweep_threshold_requests_count</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span></code></pre><h5 id="bytecode">Bytecode</h5> <p>The following bytecode is produced by the geas compiler from the source code in the sys-asm repository.</p> <pre class="giallo z-code"><code data-lang="asm"><span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push20 </span><span class="z-constant">0xfffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xcb</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x11</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x68</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup5</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4d</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>swap4</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x88</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span>lt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span>calldatacopy</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>log0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>stop</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xdf</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0183</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffff00000000000000000000000000000000</span></span> <span class="giallo-l"><span class="z-keyword">and</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x40</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x07</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x30</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x06</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x28</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x05</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x18</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x08</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xe1</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0195</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01a0</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01cd</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01e2</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01e8</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span></code></pre><h5 id="deployment">Deployment</h5> <p>The set sweep threshold requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>TBD</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Sender: TBD</span></span> <span class="giallo-l"><span>Address: TBD</span></span></code></pre><h3 id="consensus-layer-1">Consensus layer</h3> <p>The defining feature of this EIP is <em><strong>allowing validators to set custom sweep thresholds for their withdrawals when using compounding withdrawal credentials (<code>0x02, 0x03</code>)</strong></em>.</p> <p>The <a href="https://wg-eips.ritovision.com/8148/#rationale">Rationale</a> section contains an explanation for this proposed core feature. A sketch of the resulting changes to the consensus layer is included below.</p> <ol> <li>Update the <code>BeaconState</code> container to include a <code>validator_sweep_thresholds</code> mapping.</li> <li>Add <code>SetSweepThresholdRequest</code> container to represent the set sweep threshold requests dequeued from the execution layer contract.</li> <li>Update the <code>ExecutionRequests</code> container to include a list of <code>SetSweepThresholdRequest</code> items.</li> <li>Add <code>process_set_sweep_threshold_request</code> function to handle the processing of set sweep threshold requests from the execution layer.</li> <li>Modify the <code>process_execution_payload</code> function to include the processing of set sweep threshold requests.</li> <li>Modify the <code>is_partially_withdrawable_validator</code> predicate to take into account the custom sweep threshold.</li> <li>Add <code>get_effective_sweep_threshold</code> helper function to compute the effective sweep threshold for a validator.</li> <li>Modify the <code>get_expected_withdrawals</code> function to use the custom sweep threshold when determining partial withdrawals.</li> </ol> <p>By default, all validators will have their sweep thresholds set to the current default <code>MAX_EFFECTIVE_BALANCE</code>, both for existing validators and new ones. Validators can choose to set a custom threshold above their current balance by submitting a set sweep threshold request through the execution layer contract.</p> <h2 id="rationale">Rationale</h2> <h3 id="overview">Overview</h3> <p>Most of the considerations regarding the messaging format, queue, and rate-limiting are similar to those discussed in <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a> for withdrawal requests, and so we refer the reader to that EIP for more details.</p> <h3 id="custom-sweep-thresholds">Custom Sweep Thresholds</h3> <p>The primary motivation for this EIP is to allow validators to set custom sweep thresholds for their withdrawals when using compounding withdrawal credentials (<code>0x02, 0x03</code>). This feature provides greater flexibility and control over how and when validators can access their staking rewards.</p> <h3 id="validator-sweep-thresholds-mapping-in-beaconstate"><code>validator_sweep_thresholds</code> mapping in <code>BeaconState</code></h3> <p>To store the custom sweep thresholds for each validator, we introduce a new mapping in the <code>BeaconState</code> container called <code>validator_sweep_thresholds</code>. This mapping associates each validator index with its corresponding sweep threshold. This approach was chosen instead of adding a new field to the <code>Validator</code> container to avoid modification of this type, which had not been changed since phase-0. Modification of the <code>Validator</code> container would have required more extensive changes to the consensus layer and potentially affected existing implementations of the applications using this container. Also, this is the standard way of adding info about validators into the state (e.g., validator balance is stored in <code>balances</code> field of <code>BeaconState</code> and several other PoS-related info have their own lists where each item corresponds to validators' data)</p> <h3 id="only-allowing-threshold-to-be-set-above-current-balance">Only allowing threshold to be set above current balance</h3> <p>This design decision is made to prevent usage of the custom sweep threshold mechanism to trigger immediate withdrawals. By enforcing that the threshold must be set above the current balance, we ensure that validators cannot use this feature to bypass the standard withdrawal process. Should a validator wish to set sweep threshold below current balance, they can first withdraw down to the desired level using partial withdrawals, and then set the sweep threshold accordingly.</p> <h3 id="immediate-requests-processing-instead-of-queuing-on-consensus-layer">Immediate requests processing instead of queuing on consensus layer</h3> <p>Unlike partial withdrawal requests, which are queued on the consensus layer, set sweep threshold requests are processed immediately upon being dequeued from the execution layer contract. This design choice simplifies the implementation and reduces the complexity of managing a separate queue on the consensus layer.</p> <h3 id="min-sweep-threshold-of-33-eth"><code>MIN_SWEEP_THRESHOLD</code> of 33 ETH</h3> <p>To ensure that validators do not set sweep threshold equal to <code>MIN_ACTIVATION_BALANCE</code>, we introduce a minimum sweep threshold of <code>MIN_ACTIVATION_BALANCE + 1</code> ETH (33 ETH). This ensures that people will opt-in to compounding withdrawal credentials only if they really want to accumulate rewards on the validator balance.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards incompatible changes to the block structure and block validation rule set. But neither of these changes break anything related to the current user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Most of the security considerations regarding fee overpayment, system call failure, and empty code failure are similar to those discussed in <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a> for withdrawal requests, and so we refer the reader to that EIP for more details.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2026-01-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin lightclienthttps://github.com/lightclient Felix Langehttps://github.com/fjl Yoav Weisshttps://github.com/yoavw Alex Forshtathttps://github.com/forshtat Dror Tiroshhttps://github.com/drortirosh Shahaf Nacsonhttps://github.com/shahafn https://wg-eips.ritovision.com/8141/

Add frame abstraction for transaction validation, execution, and gas payment

<h2 id="abstract">Abstract</h2> <p>Add a new transaction whose validity and gas payment can be defined abstractly. Instead of relying solely on a single ECDSA signature, accounts may freely define and interpret their signature scheme using any cryptographic system.</p> <h2 id="motivation">Motivation</h2> <p>This new transaction provides a native off-ramp from the elliptic curve based cryptographic system used to authenticate transactions today, to post-quantum (PQ) secure systems.</p> <p>In doing so, it realizes the original vision of account abstraction: unlinking accounts from a prescribed ECDSA key and support alternative fee payment schemes. The assumption of an account simply becomes an address with code. It leverages the EVM to support arbitrary <em>user-defined</em> definitions of validation and gas payment.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>FRAME_TX_TYPE</code></td><td><code>0x06</code></td></tr> <tr><td><code>FRAME_TX_INTRINSIC_COST</code></td><td><code>15000</code></td></tr> <tr><td><code>ENTRY_POINT</code></td><td><code>address(0xaa)</code></td></tr> <tr><td><code>MAX_FRAMES</code></td><td><code>10^3</code></td></tr> </tbody></table> <h3 id="opcodes">Opcodes</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>APPROVE</code></td><td><code>0xaa</code></td></tr> <tr><td><code>TXPARAMLOAD</code></td><td><code>0xb0</code></td></tr> <tr><td><code>TXPARAMSIZE</code></td><td><code>0xb1</code></td></tr> <tr><td><code>TXPARAMCOPY</code></td><td><code>0xb2</code></td></tr> </tbody></table> <h3 id="new-transaction-type">New Transaction Type</h3> <p>A new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction with type <code>FRAME_TX_TYPE</code> is introduced. Transactions of this type are referred to as "Frame transactions".</p> <p>The payload is defined as the RLP serialization of the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, sender, frames, max_priority_fee_per_gas, max_fee_per_gas, max_fee_per_blob_gas, blob_versioned_hashes]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>frames = [[mode, target, gas_limit, data], ...]</span></span></code></pre> <p>If no blobs are included, <code>blob_versioned_hashes</code> must be an empty list and <code>max_fee_per_blob_gas</code> must be <code>0</code>.</p> <h4 id="modes">Modes</h4> <p>There are three modes:</p> <table><thead><tr><th>Mode</th><th>Name</th><th>Summary</th></tr></thead><tbody> <tr><td>0</td><td><code>DEFAULT</code></td><td>Execute frame as <code>ENTRY_POINT</code></td></tr> <tr><td>1</td><td><code>VERIFY</code></td><td>Frame identifies as transaction validation</td></tr> <tr><td>2</td><td><code>SENDER</code></td><td>Execute frame as <code>sender</code></td></tr> </tbody></table> <h5 id="default-mode"><code>DEFAULT</code> Mode</h5> <p>Frame executes as regular call where the caller address is <code>ENTRY_POINT</code>.</p> <h5 id="verify-mode"><code>VERIFY</code> Mode</h5> <p>Identifies the frame as a validation frame. Its purpose is to <em>verify</em> that a sender and/or payer authorized the transaction. It must call <code>APPROVE</code> during execution. Failure to do so will result in the whole transaction being invalid.</p> <p>The execution behaves the same as <code>STATICCALL</code>, state cannot be modified.</p> <p>Frames in this mode will have their data elided from signature hash calculation and from introspection by other frames.</p> <h5 id="sender-mode"><code>SENDER</code> Mode</h5> <p>Frame executes as regular call where the caller address is <code>sender</code>. This mode effectively acts on behalf of the transaction sender and can only be used after explicitly approved.</p> <h4 id="constraints">Constraints</h4> <p>Some validity constraints can be determined statically. They are outlined below:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> tx</span><span>.</span><span>chain_id</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> tx</span><span>.</span><span>nonce</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">64</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>frames</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>frames</span><span>)</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> MAX_FRAMES</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>sender</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 20</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> tx</span><span>.</span><span>frames</span><span>[</span><span>n</span><span>]</span><span>.</span><span>mode</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 3</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>frames</span><span>[</span><span>n</span><span>]</span><span>.</span><span>target</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 20</span><span class="z-keyword"> or</span><span> tx</span><span>.</span><span>frames</span><span>[</span><span>n</span><span>]</span><span>.</span><span>target</span><span class="z-keyword"> is</span><span class="z-constant"> None</span></span></code></pre><h4 id="receipt">Receipt</h4> <p>The <code>ReceiptPayload</code> is defined as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[cumulative_gas_used, payer, [frame_receipt, ...]]</span></span> <span class="giallo-l"><span>frame_receipt = [status, gas_used, logs]</span></span></code></pre> <p><code>payer</code> is the address of the account that paid the fees for the transaction. <code>status</code> is the return code of the top-level call.</p> <h4 id="signature-hash">Signature Hash</h4> <p>With the frame transaction, the signature may be at an arbitrary location in the frame list. In the canonical signature hash any frame with mode <code>VERIFY</code> will have its data elided:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_sig_hash</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> FrameTx</span><span>)</span><span> -&gt;</span><span> Hash</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> frame</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>tx</span><span>.</span><span>frames</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> frame</span><span>.</span><span>mode</span><span class="z-keyword"> ==</span><span class="z-constant"> VERIFY</span><span>:</span></span> <span class="giallo-l"><span> tx</span><span>.</span><span>frames</span><span>[</span><span>i</span><span>]</span><span>.</span><span>data</span><span class="z-keyword"> =</span><span> Bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> keccak</span><span>(</span><span>rlp</span><span>(</span><span>tx</span><span>)</span><span>)</span></span></code></pre><h3 id="new-opcodes">New Opcodes</h3> <h4 id="approve-opcode-0xaa"><code>APPROVE</code> opcode (<code>0xaa</code>)</h4> <p>The <code>APPROVE</code> opcode is like <code>RETURN (0xf3)</code>. It exits the current context successfully and updates the transaction-scoped approval context based on the <code>scope</code> operand. It can only be called when <code>CALLER == frame.target</code>, otherwise it results in an exceptional halt.</p> <h5 id="stack">Stack</h5> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>offset</code></td></tr> <tr><td><code>top - 1</code></td><td><code>length</code></td></tr> <tr><td><code>top - 2</code></td><td><code>scope</code></td></tr> </tbody></table> <h5 id="scope-operand">Scope Operand</h5> <p>The scope operand must be one of the following values:</p> <ol> <li><code>0x0</code>: Approval of execution - the sender contract approves future frames calling on its behalf. Only valid when <code>frame.target</code> equals <code>tx.sender</code>.</li> <li><code>0x1</code>: Approval of payment - the contract approves paying the total gas cost for the transaction.</li> <li><code>0x2</code>: Approval of execution and payment - combines both <code>0x0</code> and <code>0x1</code>.</li> </ol> <p>Any other value results in an exceptional halt.</p> <h5 id="behavior">Behavior</h5> <p>The behavior of <code>APPROVE</code> is defined as follows:</p> <ul> <li>If <code>APPROVE</code> is called when <code>CALLER != frame.target</code>, revert.</li> <li>For scopes <code>0</code>,<code>1</code>, and <code>2</code>, execute the following: <ul> <li><code>0x0</code>: Set <code>sender_approved = true</code>. <ul> <li>If <code>sender_approved</code> was already set, revert the frame.</li> <li>If <code>CALLER</code> != <code>tx.sender</code>, revert the frame.</li> </ul> </li> <li><code>0x1</code>: Increment the sender's nonce, collect the total gas cost of the transaction from the account, and set <code>payer_approved = true</code>. <ul> <li>If payer_approved` was already set, revert the frame.</li> <li>If <code>frame.target</code> has insufficient balance, revert the frame.</li> <li>If <code>sender_approved == false</code>, revert the frame.</li> </ul> </li> <li><code>0x2</code>: <code>sender_approved = true</code>, increment the sender's nonce, collect the total gas cost of the transaction from <code>frame.target</code>, and set <code>payer_approved = true</code>. <ul> <li>If <code>sender_approved</code> or <code>payer_approved</code> was already set, revert the frame.</li> <li>If <code>CALLER</code> != <code>tx.sender</code>, revert the frame.</li> <li>If <code>frame.target</code> has insufficient balance, revert the frame.</li> </ul> </li> </ul> </li> </ul> <h4 id="txparam-opcodes"><code>TXPARAM*</code> opcodes</h4> <p>The <code>TXPARAMLOAD</code> (<code>0xb0</code>), <code>TXPARAMSIZE</code> (<code>0xb1</code>), and <code>TXPARAMCOPY</code> (<code>0xb2</code>) opcodes follow the pattern of <code>CALLDATA*</code> / <code>RETURNDATA*</code> opcode families. Gas cost follows standard EVM memory expansion costs.</p> <p>Each <code>TXPARAM*</code> opcode takes two extra stack input values before the <code>CALLDATA*</code> equivalent inputs. The values of these inputs are as follows:</p> <table><thead><tr><th><code>in1</code></th><th><code>in2</code></th><th>Return value</th><th>Size</th></tr></thead><tbody> <tr><td>0x00</td><td>must be 0</td><td>current transaction type</td><td>32</td></tr> <tr><td>0x01</td><td>must be 0</td><td><code>nonce</code></td><td>32</td></tr> <tr><td>0x02</td><td>must be 0</td><td><code>sender</code></td><td>32</td></tr> <tr><td>0x03</td><td>must be 0</td><td><code>max_priority_fee_per_gas</code></td><td>32</td></tr> <tr><td>0x04</td><td>must be 0</td><td><code>max_fee_per_gas</code></td><td>32</td></tr> <tr><td>0x05</td><td>must be 0</td><td><code>max_fee_per_blob_gas</code></td><td>32</td></tr> <tr><td>0x06</td><td>must be 0</td><td>max cost (basefee=max, all gas used, includes blob cost and intrinsic cost)</td><td>32</td></tr> <tr><td>0x07</td><td>must be 0</td><td><code>len(blob_versioned_hashes)</code></td><td>32</td></tr> <tr><td>0x08</td><td>must be 0</td><td><code>compute_sig_hash(tx)</code></td><td>32</td></tr> <tr><td>0x09</td><td>must be 0</td><td><code>len(frames)</code></td><td>32</td></tr> <tr><td>0x10</td><td>must be 0</td><td>currently executing frame index</td><td>32</td></tr> <tr><td>0x11</td><td>frame index</td><td><code>target</code></td><td>32</td></tr> <tr><td>0x12</td><td>frame index</td><td><code>data</code></td><td>dynamic</td></tr> <tr><td>0x13</td><td>frame index</td><td><code>gas_limit</code></td><td>32</td></tr> <tr><td>0x14</td><td>frame index</td><td><code>mode</code></td><td>32</td></tr> <tr><td>0x15</td><td>frame index</td><td><code>status</code> (exceptional halt if current/future)</td><td>32</td></tr> </tbody></table> <p>Notes:</p> <ul> <li>0x03 and 0x04 have a possible future extension to allow indices for multidimensional gas.</li> <li>The <code>status</code> field (0x15) returns <code>0</code> for failure or <code>1</code> for success.</li> <li>Out-of-bounds access for frame index (<code>&gt;= len(frames)</code>) and blob index results in an exceptional halt.</li> <li>Invalid <code>in1</code> values (not defined in the table above) result in an exceptional halt.</li> <li>The <code>data</code> field (0x12) returns size 0 value when called on a frame with <code>VERIFY</code> set.</li> </ul> <h3 id="behavior-1">Behavior</h3> <p>When processing a frame transaction, perform the following steps.</p> <p>Perform stateful validation check:</p> <ul> <li>Ensure <code>tx.nonce == state[tx.sender].nonce</code></li> </ul> <p>Initialize with transaction-scoped variables:</p> <ul> <li><code>payer_approved = false</code></li> <li><code>sender_approved = false</code></li> </ul> <p>Then for each call frame:</p> <ol> <li>Execute a call with the specified <code>mode</code>, <code>target</code>, <code>gas_limit</code>, and <code>data</code>. <ul> <li>If <code>target</code> is null, set the call target to <code>tx.sender</code>.</li> <li>If mode is <code>SENDER</code>: <ul> <li><code>sender_approved</code> must be <code>true</code>. If not, the transaction is invalid.</li> <li>Set <code>caller</code> as <code>tx.sender</code>.</li> </ul> </li> <li>If mode is <code>DEFAULT</code> or <code>VERIFY</code>: <ul> <li>Set the <code>caller</code> to <code>ENTRY_POINT</code>.</li> </ul> </li> <li>The <code>ORIGIN</code> opcode returns frame <code>caller</code> throughout all call depths.</li> </ul> </li> <li>If frame has mode <code>VERIFY</code> and the frame did successfully call <code>APPROVE</code>, the transaction is invalid.</li> </ol> <p>After executing all frames, verify that <code>payer_approved == true</code>. If it is, refund any unpaid gas to the gas payer. If it is not, the whole transaction is invalid.</p> <p>Note: it is implied by the handling that the sender must approve the transaction <em>before</em> the payer and that once <code>sender_approved</code> or <code>payer_approved</code> become <code>true</code> they cannot be re-approved or reverted.</p> <h4 id="frame-interactions">Frame interactions</h4> <p>A few cross-frame interactions to note:</p> <ul> <li>For the purposes of gas accounting of warm / cold state status, the journal of such touches is shared across frames.</li> <li>Discard the <code>TSTORE</code> and <code>TLOAD</code> transient storage between frames.</li> </ul> <h4 id="gas-accounting">Gas Accounting</h4> <p>The total gas limit of the transaction is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>tx_gas_limit = FRAME_TX_INTRINSIC_COST + calldata_cost(rlp(tx.frames)) + sum(frame.gas_limit for all frames)</span></span></code></pre> <p>Where <code>calldata_cost</code> is calculated per standard EVM rules (4 gas per zero byte, 16 gas per non-zero byte).</p> <p>The total fee is defined as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>tx_fee = tx_gas_limit * effective_gas_price + blob_fees</span></span> <span class="giallo-l"><span>blob_fees = len(blob_versioned_hashes) * GAS_PER_BLOB * blob_base_fee</span></span></code></pre> <p>The <code>effective_gas_price</code> is calculated per EIP-1559 and <code>blob_fees</code> is calculated as per EIP-4844.</p> <p>Each frame has its own <code>gas_limit</code> allocation. Unused gas from a frame is <strong>not</strong> available to subsequent frames. After all frames execute, the gas refund is calculated as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>refund = sum(frame.gas_limit for all frames) - total_gas_used</span></span></code></pre> <p>This refund is returned to the gas payer (the <code>target</code> that called <code>APPROVE(0x1)</code> or <code>APPROVE(0x2)</code>) and added back to the block gas pool. <em>Note: This refund mechanism is separate from EIP-3529 storage refunds.</em></p> <h2 id="rationale">Rationale</h2> <h3 id="canonical-signature-hash">Canonical signature hash</h3> <p>The canonical signature hash is provided in <code>TXPARAMLOAD</code> to simplify the development of smart accounts.</p> <p>Computing the signature hash in EVM is complicated and expensive. While using the canonical signature hash is not mandatory, it is strongly recommended. Creating a bespoke signature requires precise commitment to the underlying transaction data. Without this, it's possible that some elements can be manipulated in-the-air while the transaction is pending and have unexpected effects. This is known as transaction malleability. Using the canonical signature hash avoids malleability of the frames other than <code>VERIFY</code>.</p> <p>The <code>frame.data</code> of <code>VERIFY</code> frames is elided from the signature hash. This is done for two reasons:</p> <ol> <li>It contains the signature so by definition it cannot be part of the signature hash.</li> <li>In the future it may be desired to aggregate the cryptographic operations for data and compute efficiency reasons. If the data was introspectable, it would not be possible to aggregate the verify frames in the future.</li> <li>For gas sponsoring workflows, we also recommend using a <code>VERIFY</code> frame to approve the gas payment. Here, the input data to the sponsor is intentionally left malleable so it can be added onto the transaction after the <code>sender</code> has made its signature. Notably, the <code>frame.target</code> of <code>VERIFY</code> frames is covered by the signature hash, i.e. the <code>sender</code> chooses the sponsor address explicitly.</li> </ol> <h3 id="approve-calling-convention"><code>APPROVE</code> calling convention</h3> <p>Originally <code>APPROVE</code> was meant to extend the space of return statuses from 0 and j 1 today to 0 to 4. However, this would mean smart accounts deployed today would not beable to modify their contract code to return with a different value at the top level. For this reason, we've chosen behavior above: <code>APPROVE</code> terminates the executing frame successfully like <code>RETURN</code>, but it actually updates the transaction scoped values <code>sender_approved</code> and <code>payer_approved</code> during execution. It is still required that only the sender can toggle the <code>sender_approved</code> to <code>true</code>. Only the <code>frame.target</code> can call <code>APPROVE</code> generally, because it can allow the transaction pool and other frames to better reason about <code>VERIFY</code> mode frames.</p> <h3 id="payer-in-receipt">Payer in receipt</h3> <p>The payer cannot be determined statically from a frame transaction and is relevant to users. The only way to provide this information safely and efficiently over the JSON-RPC is to record this data in the receipt object.</p> <h3 id="no-authorization-list">No authorization list</h3> <p>The EIP-7702 authorization list heavily relies on ECDSA cryptography to determine the authority of accounts to delegate code. While delegations could be used in other manners later, it does not satisfy the PQ goals of the frame transaction.</p> <h3 id="no-access-list">No access list</h3> <p>The access list was introduced to address a particular backwards compatibility issue that was caused by EIP-2929. The risk-reward of using an access list successfully is high. A single miss, paying to warm a storage slot that does not end up getting used, causes the overall transaction cost to be greater than had it not been included at all.</p> <p>Future optimizations based on pre-announcing state elements a transaction will touch will be covered by block level access lists.</p> <h3 id="no-value-in-frame">No value in frame</h3> <p>It is not required because the account code can send value.</p> <h3 id="examples">Examples</h3> <h4 id="example-1-simple-transaction">Example 1: Simple Transaction</h4> <table><thead><tr><th>Frame</th><th>Caller</th><th>Target</th><th>Data</th><th>Mode</th></tr></thead><tbody> <tr><td>0</td><td>ENTRY_POINT</td><td>Null (sender)</td><td>Signature</td><td>VERIFY</td></tr> <tr><td>1</td><td>Sender</td><td>Target</td><td>Call data</td><td>SENDER</td></tr> </tbody></table> <p>Frame 0 verifies the signature and calls <code>APPROVE(0x2)</code> to approve both execution and payment. Frame 1 executes and exits normally via <code>RETURN</code>.</p> <p>The mempool can process this transaction with the following static validation and call:</p> <ul> <li>Verify that the first frame is a <code>VERIFY</code> frame.</li> <li>Verify that the call of frame 0 succeeds, and does not violate the mempool rules (similar to <a href="https://wg-eips.ritovision.com/7562/">ERC-7562</a>).</li> </ul> <h4 id="example-1a-simple-eth-transfer">Example 1a: Simple ETH transfer</h4> <table><thead><tr><th>Frame</th><th>Caller</th><th>Target</th><th>Data</th><th>Mode</th></tr></thead><tbody> <tr><td>0</td><td>ENTRY_POINT</td><td>Null (sender)</td><td>Signature</td><td>VERIFY</td></tr> <tr><td>1</td><td>Sender</td><td>Null (sender)</td><td>Destination/Amount</td><td>SENDER</td></tr> </tbody></table> <p>A simple transfer is performed by instructing the account to send ETH to the destination account. This requires two frames for mempool compatibility, since the validation phase of the transaction has to be static.</p> <p>This is listed here to illustrate why the transaction type has no built-in value field.</p> <h4 id="example-1b-simple-account-deployment">Example 1b: Simple account deployment</h4> <table><thead><tr><th>Frame</th><th>Caller</th><th>Target</th><th>Data</th><th>Mode</th></tr></thead><tbody> <tr><td>0</td><td>ENTRY_POINT</td><td>Deployer</td><td>Initcode, Salt</td><td>DEFAULT</td></tr> <tr><td>1</td><td>ENTRY_POINT</td><td>Null (sender)</td><td>Signature</td><td>VERIFY</td></tr> <tr><td>2</td><td>Sender</td><td>Null (sender)</td><td>Destination/Amount</td><td>SENDER</td></tr> </tbody></table> <p>This example illustrates the initial deployment flow for a smart account at the <code>sender</code> address. Since the address needs to have code in order to validate the transaction, the transaction must deploy the code before verification.</p> <p>The first frame would call a deployer contract, like EIP-7997. The deployer determines the address in a deterministic way, such as by hashing the initcode and salt. However, since the transaction sender is not authenticated at this point, the user must choose an initcode which is safe to deploy by anyone.</p> <h4 id="example-2-sponsored-transaction-fee-payment-in-erc-20">Example 2: Sponsored Transaction (Fee Payment in ERC-20)</h4> <table><thead><tr><th>Frame</th><th>Caller</th><th>Target</th><th>Data</th><th>Mode</th></tr></thead><tbody> <tr><td>0</td><td>ENTRY_POINT</td><td>Null (sender)</td><td>Signature</td><td>VERIFY</td></tr> <tr><td>1</td><td>ENTRY_POINT</td><td>Sponsor</td><td>Sponsor data</td><td>VERIFY</td></tr> <tr><td>2</td><td>Sender</td><td>ERC-20</td><td>transfer(Sponsor,fees)</td><td>SENDER</td></tr> <tr><td>3</td><td>Sender</td><td>Target addr</td><td>Call data</td><td>SENDER</td></tr> <tr><td>4</td><td>ENTRY_POINT</td><td>Sponsor</td><td>Post op call</td><td>DEFAULT</td></tr> </tbody></table> <ul> <li>Frame 0: Verifies signature and calls <code>APPROVE(0x0)</code> to authorize execution from sender.</li> <li>Frame 1: Checks that the user has enough ERC-20 tokens, and that the next frame is an ERC-20 send of the right size to the sponsor. Calls <code>APPROVE(0x1)</code> to authorize payment.</li> <li>Frame 2: Sends tokens to sponsor.</li> <li>Frame 3: User's intended call.</li> <li>Frame 4 (optional): Check unpaid gas, refund tokens, possibly convert tokens to ETH on an AMM.</li> </ul> <h3 id="data-efficiency">Data Efficiency</h3> <p><strong>Basic transaction sending ETH from a smart account:</strong></p> <table><thead><tr><th>Field</th><th>Bytes</th></tr></thead><tbody> <tr><td>Tx wrapper</td><td>1</td></tr> <tr><td>Chain ID</td><td>1</td></tr> <tr><td>Nonce</td><td>2</td></tr> <tr><td>Sender</td><td>20</td></tr> <tr><td>Max priority fee</td><td>5</td></tr> <tr><td>Max fee</td><td>5</td></tr> <tr><td>Max fee per blob gas</td><td>1</td></tr> <tr><td>Blob versioned hashes (empty)</td><td>1</td></tr> <tr><td>Frames wrapper</td><td>1</td></tr> <tr><td>Sender validation frame: target</td><td>1</td></tr> <tr><td>Sender validation frame: gas</td><td>2</td></tr> <tr><td>Sender validation frame: data</td><td>65</td></tr> <tr><td>Sender validation frame: mode</td><td>1</td></tr> <tr><td>Execution frame: target</td><td>1</td></tr> <tr><td>Execution frame: gas</td><td>1</td></tr> <tr><td>Execution frame: data</td><td>20+5</td></tr> <tr><td>Execution frame: mode</td><td>1</td></tr> <tr><td><strong>Total</strong></td><td>134</td></tr> </tbody></table> <p>Notes: Nonce assumes &lt; 65536 prior sends. Fees assume &lt; 1099 gwei. Validation frame target is 1 byte because target is <code>tx.sender</code>. Validation gas assumes &lt;= 65,536 gas. Calldata is 65 bytes for ECDSA signature. Blob fields assume no blobs (empty list, zero max fee).</p> <p>This is not much larger than an EIP-1559 transaction; the extra overhead is the need to specify the sender and amount in calldata explicitly.</p> <p><strong>First transaction from an account (add deployment frame):</strong></p> <table><thead><tr><th>Field</th><th>Bytes</th></tr></thead><tbody> <tr><td>Deployment frame: target</td><td>20</td></tr> <tr><td>Deployment frame: gas</td><td>3</td></tr> <tr><td>Deployment frame: data</td><td>100</td></tr> <tr><td>Deployment frame: mode</td><td>1</td></tr> <tr><td><strong>Total additional</strong></td><td>124</td></tr> </tbody></table> <p>Notes: Gas assumes cost &lt; 2^24. Calldata assumes small proxy.</p> <p><strong>Trustless pay-with-ERC-20 sponsor (add these frames):</strong></p> <table><thead><tr><th>Field</th><th>Bytes</th></tr></thead><tbody> <tr><td>Sponsor validation frame: target</td><td>20</td></tr> <tr><td>Sponsor validation frame: gas</td><td>3</td></tr> <tr><td>Sponsor validation frame: calldata</td><td>0</td></tr> <tr><td>Sponsor validation frame: mode</td><td>1</td></tr> <tr><td>Send to sponsor frame: target</td><td>20</td></tr> <tr><td>Send to sponsor frame: gas</td><td>3</td></tr> <tr><td>Send to sponsor frame: calldata</td><td>68</td></tr> <tr><td>Send to sponsor frame: mode</td><td>1</td></tr> <tr><td>Sponsor post op frame: target</td><td>20</td></tr> <tr><td>Sponsor post op frame: gas</td><td>3</td></tr> <tr><td>Sponsor post op frame: calldata</td><td>0</td></tr> <tr><td>Sponsor post op frame: mode</td><td>1</td></tr> <tr><td><strong>Total additional</strong></td><td>140</td></tr> </tbody></table> <p>Notes: Sponsor can read info from other fields. ERC-20 transfer call is 68 bytes.</p> <p>There is some inefficiency in the sponsor case, because the same sponsor address must appear in three places (sponsor validation, send to sponsor inside ERC-20 calldata, post op frame), and the ABI is inefficient (~12 + 24 bytes wasted on zeroes). This is difficult to mitigate in a "clean" way, because one of the duplicates is inside the ERC-20 call, "opaque" to the protocol. However, it is much less inefficient than ERC-4337, because not all of the data takes the hit of the 32-byte-per-field ABI overhead.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The <code>ORIGIN</code> opcode behavior changes for frame transactions, returning the frame's caller rather than the traditional transaction origin. This is consistent with the precedent set by EIP-7702, which already modified <code>ORIGIN</code> semantics. Contracts that rely on <code>ORIGIN = CALLER</code> for security checks (a discouraged pattern) may behave differently under frame transactions.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="transaction-propagation">Transaction Propagation</h3> <p>Frame transactions introduce new denial-of-service vectors for transaction pools that node operators must mitigate. Because validation logic is arbitrary EVM code, attackers can craft transactions that appear valid during initial validation but become invalid later. Without any additional policies, an attacker could submit many transactions whose validity depends on some shared state, then submit one transaction that modifies that state, and cause all other transactions to become invalid simultaneously. This wastes the computational resources nodes spent validating and storing these transactions.</p> <h4 id="example-attack">Example Attack</h4> <p>A simple example is transactions that check <code>block.timestamp</code>:</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> validateTransaction</span><span>(</span><span>)</span><span class="z-storage z-type"> external</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> require</span><span>(</span><span class="z-variable z-language">block</span><span>.</span><span>timestamp </span><span class="z-keyword">&lt;</span><span> SOME_DEADLINE</span><span>,</span><span class="z-string"> &quot;expired&quot;</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> ... rest of validation</span></span> <span class="giallo-l"><span class="z-entity z-name"> APPROVE</span><span>(</span><span class="z-constant">0x2</span><span>)</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Such transactions are valid when submitted but become invalid once the deadline passes, without any on-chain action required from the attacker.</p> <h5 id="mitigations">Mitigations</h5> <p>Node implementations should consider restricting which opcodes and storage slots validation frames can access, similar to ERC-7562. This isolates transactions from each other and limits mass invalidation vectors.</p> <p>It's recommended that to <em>validate</em> the transaction, a specific frame structure is enforced and the amount of gas that is expended executing the validation phase must be limited. Once the frame calls <code>APPROVE(0x2)</code>, it can be included in the mempool and propagated to peers safely.</p> <p>For deployment of the sender account in the first frame, the mempool must only allow specific and known deployer factory contracts to be used as <code>frame.target</code>, to ensure deployment is deterministic and independent of chain state.</p> <p>In general, it can be assumed that handling of frame transactions imposes similar restrictions as EIP-7702 on mempool relay, i.e. only a single transaction can be pending for an account that uses frame transactions.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2026-01-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Kevaundray Wedderburnhttps://github.com/kevaundray Ignacio Hagopianhttps://github.com/jsign Jihoon Songjihoon.song@ethereum.org Francesco Risitanohttps://github.com/frisitano Thomas Thieryhttps://github.com/soispokethomas.thiery@ethereum.org Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/8142/

Ensures execution payload data availability via blobs

<h2 id="abstract">Abstract</h2> <p>zkEVMs allow validators to verify the correctness of an execution payload using a proof, without downloading or executing the payload itself. However, removing the requirement to download the execution payload, also removes the implicit data availability (DA) guarantee; a block producer can publish a valid proof and withhold the execution-payload data since attesters no longer need them for consensus.</p> <p>This EIP introduces Block-in-Blobs (BiB), a mechanism that requires the execution-payload data (transactions and BALs) to be published in blob data, in the same beacon block that carries the corresponding execution payload's header. This ensures that execution payloads and their associated data are always published even when validators no longer require them to verify the state transition function (STF).</p> <p>In short, BiB works by having the block producer encode the execution-payload data into blobs as part of the execution layer's STF, requiring the beacon block’s blob KZG commitments to commit to those payload-blobs.</p> <h2 id="motivation">Motivation</h2> <p><strong>Validation via re-execution</strong></p> <p>Today, validators verify execution payloads by:</p> <ol> <li>Downloading the execution payload</li> <li>Executing the payload locally</li> <li>Checking the resulting state root and other fields against the fields in the header</li> </ol> <p>Implicitly this guarantees execution payload availability because the payload cannot be verified unless the node downloads it.</p> <p><strong>Validation with zkEVMs</strong></p> <p>With zkEVMs, validators instead:</p> <ol> <li>Download a proof attesting to the correctness of the execution payload</li> <li>Download the execution payload header</li> <li>Verify the proof with respects to the payload header (and other commitments)</li> </ol> <p>In this model, validators no longer require access to the full execution payload data itself in order to verify its correctness.</p> <p><strong>The DA problem</strong></p> <p>Removing the re-execution requirement in consensus removes the implicit requirement that consensus clients download the execution payload.</p> <p>A malicious or rational builder could:</p> <ul> <li>Publish a valid proof for a valid execution payload</li> <li>Withhold the execution-payload data entirely</li> </ul> <p><em>Builders</em>: Since builders will always need to re-execute in order to build blocks, a malicious builder would not publish the execution payload ensuring that they are the only ones that can build on top of the current chain.</p> <p><em>RPC and indexers</em>: Many nodes such as RPC providers and indexers cannot solely rely on execution proofs and must re-execute the execution payload.</p> <p>BiB addresses this by making the execution payload available via blobs.</p> <h2 id="specification">Specification</h2> <h3 id="terminology">Terminology</h3> <p><strong>Type-3 transaction:</strong> Refers to EIP-4844 blob-carrying transactions (transaction type 0x03). These transactions include blob versioned hashes that commit to blobs carrying user data.</p> <h3 id="overview-and-invariants">Overview and Invariants</h3> <p>BiB ensures the proven payload is published:</p> <ul> <li>The beacon block references a list of blob KZG commitments (via 4844/PeerDas)</li> <li>A prefix of those commitments is reserved for the execution-payload data encoded into blobs</li> <li>A zkEVM proof for the block must bind the proven execution payload to those prefixed blob commitments.</li> </ul> <p><strong>Payload availability invariant:</strong> A valid block implies there exists an ordered list of blobs whose bytes decode to the canonical execution-payload data, and the KZG commitments for these blobs match the first <code>payload_blob_count</code> blob commitments referenced by the block. The existing DAS mechanism will ensure that those blobs are available.</p> <h3 id="parameters">Parameters</h3> <h4 id="referenced-parameters">Referenced Parameters</h4> <p>These parameters are defined in EIP-4844 and related specs:</p> <table><thead><tr><th>Name</th><th>Value</th><th>Source</th></tr></thead><tbody> <tr><td><code>FIELD_ELEMENTS_PER_BLOB</code></td><td><code>4096</code></td><td>EIP-4844</td></tr> <tr><td><code>BYTES_PER_FIELD_ELEMENT</code></td><td><code>32</code></td><td>EIP-4844</td></tr> <tr><td><code>GAS_PER_BLOB</code></td><td><code>2**17</code></td><td>EIP-4844</td></tr> <tr><td><code>MAX_BLOBS_PER_BLOCK</code></td><td>Network-specific</td><td>EIP-7892</td></tr> </tbody></table> <p><strong>Note on <code>MAX_BLOBS_PER_BLOCK</code>:</strong> This constant represents the maximum number of blobs (both payload-blobs and type-3 transaction blobs) that can be included in a block. Per EIP-7892, the execution layer's <code>blobSchedule.max</code> MUST equal the consensus layer's <code>MAX_BLOBS_PER_BLOCK</code> configuration value at any given time. This value may change across forks (e.g., initially 6 in EIP-4844, potentially increased in subsequent blob throughput increase proposals).</p> <h4 id="derived-constants">Derived Constants</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>USABLE_BYTES_PER_FIELD_ELEMENT</code></td><td><code>BYTES_PER_FIELD_ELEMENT - 1</code> (31)</td><td>Usable bytes per field element (final byte must be zero to stay under BLS modulus)</td></tr> <tr><td><code>USABLE_BYTES_PER_BLOB</code></td><td><code>FIELD_ELEMENTS_PER_BLOB * USABLE_BYTES_PER_FIELD_ELEMENT</code></td><td>Total usable bytes per blob</td></tr> </tbody></table> <h3 id="execution-layer">Execution Layer</h3> <p><strong>Summary:</strong> The execution layer is modified in the following ways:</p> <ul> <li>The ExecutionPayloadHeader now has a <code>payload_blob_count</code> field to track how many blobs are used for the execution payload data, enabling verification of the correct number of payload-blobs at the Engine API boundary.</li> <li><code>engine_getPayload</code> computes the payload-blobs when building a block, sets <code>payload_blob_count</code> in the ExecutionPayloadHeader, and returns the payload blobs (with their commitments and proofs) alongside type-3 transaction blobs in the response.</li> <li><code>engine_newPayload</code> takes the ExecutionPayload and before passing it to the EL STF, it computes the payload-blobs, checks that the amount of blobs needed is equal to the <code>payload_blob_count</code> value in the ExecutionPayloadHeader and verifies that the expected version hashes match.</li> </ul> <h4 id="referenced-helpers">Referenced Helpers</h4> <p>The execution layer uses methods and classes defined in the corresponding consensus 4844/7594 specs.</p> <p>Specifically, we use the following methods from <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/46c1199d6b4584ba484dec807f03b8e6211dd725/specs/deneb/polynomial-commitments.md?#introduction">polynomial-commitments.md</a>:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/46c1199d6b4584ba484dec807f03b8e6211dd725/specs/deneb/polynomial-commitments.md#L578">verify_blob_kzg_proof_batch</a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#blob_to_kzg_commitment">blob_to_kzg_commitment</a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#compute_blob_kzg_proof">compute_blob_kzg_proof</a></li> </ul> <p>And the following methods from <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/2938e1ad74cea54f1a24508a85704d5bd87837ad/specs/fulu/polynomial-commitments-sampling.md">polynomial-commitments-sampling.md</a>:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/2938e1ad74cea54f1a24508a85704d5bd87837ad/specs/fulu/polynomial-commitments-sampling.md#compute_cells_and_kzg_proofs">compute_cells_and_kzg_proofs</a></li> </ul> <p>And the following methods from <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/beacon-chain.md#introduction">beacon-chain.md</a>:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/beacon-chain.md#kzg_commitment_to_versioned_hash">kzg_commitment_to_versioned_hash</a></li> </ul> <h4 id="helpers">Helpers</h4> <h5 id="bytes-to-blobs">bytes_to_blobs</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> bytes_to_blobs</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> List</span><span>[</span><span>Blob</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Pack arbitrary bytes into one or more blobs.</span></span> <span class="giallo-l"><span class="z-string"> Remaining space in final blob is zero-padded.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> blobs</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> offset</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> chunk</span><span class="z-keyword"> =</span><span> data</span><span>[</span><span>offset</span><span> :</span><span> offset</span><span class="z-keyword"> +</span><span class="z-constant"> USABLE_BYTES_PER_BLOB</span><span>]</span></span> <span class="giallo-l"><span> blob</span><span class="z-keyword"> =</span><span> chunk_to_blob</span><span>(</span><span>chunk</span><span>)</span></span> <span class="giallo-l"><span> blobs</span><span>.</span><span>append</span><span>(</span><span>blob</span><span>)</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> +=</span><span class="z-constant"> USABLE_BYTES_PER_BLOB</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> blobs</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> chunk_to_blob</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> Blob</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Pack up to USABLE_BYTES_PER_BLOB bytes into a single blob.</span></span> <span class="giallo-l"><span class="z-string"> If data is shorter than USABLE_BYTES_PER_BLOB, it is zero-padded.</span></span> <span class="giallo-l"><span class="z-string"> Each 31-byte chunk is stored in bytes [0:31] of a field element,</span></span> <span class="giallo-l"><span class="z-string"> with byte [31] (the final byte) set to zero to ensure value &lt; BLS modulus.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> USABLE_BYTES_PER_BLOB</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pad to exactly USABLE_BYTES_PER_BLOB if needed</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span class="z-keyword"> &lt;</span><span class="z-constant"> USABLE_BYTES_PER_BLOB</span><span>:</span></span> <span class="giallo-l"><span> data</span><span class="z-keyword"> =</span><span> data</span><span class="z-keyword"> +</span><span class="z-support"> bytes</span><span>(</span><span class="z-constant">USABLE_BYTES_PER_BLOB</span><span class="z-keyword"> -</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> blob</span><span class="z-keyword"> =</span><span class="z-support"> bytearray</span><span>(</span><span class="z-constant">FIELD_ELEMENTS_PER_BLOB</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">FIELD_ELEMENTS_PER_BLOB</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> chunk_start</span><span class="z-keyword"> =</span><span> i</span><span class="z-keyword"> *</span><span class="z-constant"> USABLE_BYTES_PER_FIELD_ELEMENT</span></span> <span class="giallo-l"><span> chunk</span><span class="z-keyword"> =</span><span> data</span><span>[</span><span>chunk_start</span><span> :</span><span> chunk_start</span><span class="z-keyword"> +</span><span class="z-constant"> USABLE_BYTES_PER_FIELD_ELEMENT</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Store 31 data bytes in [0:31], the final byte [31] stays zero</span></span> <span class="giallo-l"><span> blob</span><span>[</span><span>i</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span> :</span><span> i</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span class="z-keyword"> +</span><span class="z-constant"> USABLE_BYTES_PER_FIELD_ELEMENT</span><span>]</span><span class="z-keyword"> =</span><span> chunk</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Blob</span><span>(</span><span>blob</span><span>)</span></span></code></pre><h5 id="blobs-to-bytes">blobs_to_bytes</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> blobs_to_bytes</span><span>(</span><span class="z-variable z-parameter z-function">blobs</span><span>:</span><span> List</span><span>[</span><span>Blob</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-support"> bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Unpack blobs back to bytes.</span></span> <span class="giallo-l"><span class="z-string"> Returns all usable bytes from all blobs (including any padding).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> raw</span><span class="z-keyword"> =</span><span class="z-support"> bytearray</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> blob</span><span class="z-keyword"> in</span><span> blobs</span><span>:</span></span> <span class="giallo-l"><span> raw</span><span>.</span><span>extend</span><span>(</span><span>blob_to_chunk</span><span>(</span><span>blob</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> bytes</span><span>(</span><span>raw</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> blob_to_chunk</span><span>(</span><span class="z-variable z-parameter z-function">blob</span><span>:</span><span> Blob</span><span>)</span><span> -&gt;</span><span class="z-support"> bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Extract the 31 usable bytes from each field element.</span></span> <span class="giallo-l"><span class="z-string"> Validates that the final byte is zero for each field element.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> result</span><span class="z-keyword"> =</span><span class="z-support"> bytearray</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">FIELD_ELEMENTS_PER_BLOB</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate final byte is zero</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> blob</span><span>[</span><span>i</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span class="z-keyword"> +</span><span class="z-constant"> USABLE_BYTES_PER_FIELD_ELEMENT</span><span>]</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">00</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">Invalid blob: final byte must be zero</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract usable data bytes</span></span> <span class="giallo-l"><span> result</span><span>.</span><span>extend</span><span>(</span><span>blob</span><span>[</span><span>i</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span> :</span><span> i</span><span class="z-keyword"> *</span><span class="z-constant"> BYTES_PER_FIELD_ELEMENT</span><span class="z-keyword"> +</span><span class="z-constant"> USABLE_BYTES_PER_FIELD_ELEMENT</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> bytes</span><span>(</span><span>result</span><span>)</span></span></code></pre><h5 id="get-execution-payload-data">get_execution_payload_data</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_execution_payload_data</span><span>(</span><span class="z-variable z-parameter z-function">payload</span><span>:</span><span> ExecutionPayload</span><span>)</span><span> -&gt;</span><span> ExecutionPayloadData</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Extract the data from an ExecutionPayload that must be made available via blobs.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionPayloadData</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> blockAccessList</span><span class="z-keyword">=</span><span>payload</span><span>.</span><span>blockAccessList</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> transactions</span><span class="z-keyword">=</span><span>payload</span><span>.</span><span>transactions</span><span>,</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h5 id="execution-payload-data-to-blobs">execution_payload_data_to_blobs</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> execution_payload_data_to_blobs</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>:</span><span> ExecutionPayloadData</span><span>)</span><span> -&gt;</span><span> List</span><span>[</span><span>Blob</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Canonically encode the execution-payload data into an ordered list of blobs.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Encoding steps:</span></span> <span class="giallo-l"><span class="z-string"> 1. bal_bytes = data.blockAccessList</span></span> <span class="giallo-l"><span class="z-string"> 2. transactions_bytes = RLP.encode(data.transactions)</span></span> <span class="giallo-l"><span class="z-string"> 3. Create 10-byte header: [2 bytes version][4 bytes BAL length][4 bytes tx length]</span></span> <span class="giallo-l"><span class="z-string"> 4. payload_bytes = header + bal_bytes + transactions_bytes</span></span> <span class="giallo-l"><span class="z-string"> 5. return bytes_to_blobs(payload_bytes)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> The first blob will contain (in order):</span></span> <span class="giallo-l"><span class="z-string"> - [2 bytes] Payload encoding version (currently 0)</span></span> <span class="giallo-l"><span class="z-string"> - [4 bytes] BAL data length</span></span> <span class="giallo-l"><span class="z-string"> - [4 bytes] Transaction data length</span></span> <span class="giallo-l"><span class="z-string"> - [variable] BAL data (may span multiple blobs)</span></span> <span class="giallo-l"><span class="z-string"> - [variable] Transaction data (may span multiple blobs)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> This allows extracting just the BAL data without transactions.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Note: blockAccessList is already RLP-encoded per EIP-7928. Transactions are RLP-encoded as a list.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> bal_bytes</span><span class="z-keyword"> =</span><span> data</span><span>.</span><span>blockAccessList</span></span> <span class="giallo-l"><span> transactions_bytes</span><span class="z-keyword"> =</span><span class="z-constant"> RLP</span><span>.</span><span>encode</span><span>(</span><span>data</span><span>.</span><span>transactions</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Create 10-byte header: [2 bytes version][4 bytes BAL length][4 bytes tx length]</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span> (</span><span class="z-constant">0</span><span>)</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">2</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> bal_length</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>bal_bytes</span><span>)</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">4</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> txs_length</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>transactions_bytes</span><span>)</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">4</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> header</span><span class="z-keyword"> =</span><span> version</span><span class="z-keyword"> +</span><span> bal_length</span><span class="z-keyword"> +</span><span> txs_length</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Combine header + data</span></span> <span class="giallo-l"><span> payload_bytes</span><span class="z-keyword"> =</span><span> header</span><span class="z-keyword"> +</span><span> bal_bytes</span><span class="z-keyword"> +</span><span> transactions_bytes</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> bytes_to_blobs</span><span>(</span><span>payload_bytes</span><span>)</span></span></code></pre><h5 id="blobs-to-execution-payload-data">blobs_to_execution_payload_data</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> blobs_to_execution_payload_data</span><span>(</span><span class="z-variable z-parameter z-function">blobs</span><span>:</span><span> List</span><span>[</span><span>Blob</span><span>]</span><span>)</span><span> -&gt;</span><span> ExecutionPayloadData</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Canonically decode an ordered list of blobs into execution-payload data.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Decoding steps:</span></span> <span class="giallo-l"><span class="z-string"> 1. raw = blobs_to_bytes(blobs)</span></span> <span class="giallo-l"><span class="z-string"> 2. Read 10-byte header: [2 bytes version][4 bytes BAL length][4 bytes tx length]</span></span> <span class="giallo-l"><span class="z-string"> 3. Validate version is 0</span></span> <span class="giallo-l"><span class="z-string"> 4. Split into bal_bytes and transactions_bytes</span></span> <span class="giallo-l"><span class="z-string"> 5. return ExecutionPayloadData(blockAccessList, transactions)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract raw bytes from blobs</span></span> <span class="giallo-l"><span> raw</span><span class="z-keyword"> =</span><span> blobs_to_bytes</span><span>(</span><span>blobs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Read 10-byte header</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>raw</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">2</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> version</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>,</span><span class="z-storage z-type"> f</span><span class="z-string">&quot;</span><span class="z-string">Unsupported payload encoding version: </span><span class="z-constant">{</span><span>version</span><span class="z-constant">}</span><span class="z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> bal_length</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>raw</span><span>[</span><span class="z-constant">2</span><span>:</span><span class="z-constant">6</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> txs_length</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>raw</span><span>[</span><span class="z-constant">6</span><span>:</span><span class="z-constant">10</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract data portions</span></span> <span class="giallo-l"><span> bal_bytes</span><span class="z-keyword"> =</span><span> raw</span><span>[</span><span class="z-constant">10</span><span> :</span><span class="z-constant"> 10</span><span class="z-keyword"> +</span><span> bal_length</span><span>]</span></span> <span class="giallo-l"><span> transactions_bytes</span><span class="z-keyword"> =</span><span> raw</span><span>[</span><span class="z-constant">10</span><span class="z-keyword"> +</span><span> bal_length</span><span> :</span><span class="z-constant"> 10</span><span class="z-keyword"> +</span><span> bal_length</span><span class="z-keyword"> +</span><span> txs_length</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Decode transactions</span></span> <span class="giallo-l"><span> transactions</span><span class="z-keyword"> =</span><span class="z-constant"> RLP</span><span>.</span><span>decode</span><span>(</span><span>transactions_bytes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionPayloadData</span><span>(</span><span class="z-variable">blockAccessList</span><span class="z-keyword">=</span><span>bal_bytes</span><span>,</span><span class="z-variable"> transactions</span><span class="z-keyword">=</span><span>transactions</span><span>)</span></span></code></pre><h5 id="extract-data-from-type-3-tx">extract_data_from_type_3_tx</h5> <p>This method will be used to implement the modified logic in engine_getPayload.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> extract_data_from_type_3_tx</span><span>(</span><span class="z-variable z-parameter z-function">transactions</span><span>:</span><span> List</span><span>[</span><span>Transaction</span><span>]</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>List</span><span>[</span><span>Blob</span><span>]</span><span>,</span><span> List</span><span>[</span><span>KZGCommitment</span><span>]</span><span>,</span><span> List</span><span>[</span><span>List</span><span>[</span><span>KZGProof</span><span>]</span><span>]</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Extract blobs, KZG commitments, and cell proofs from type-3 (blob) transactions.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Returns a tuple of (blobs, commitments, cell_proofs) in the order they appear</span></span> <span class="giallo-l"><span class="z-string"> in the transaction list.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Implementation note: This is not new logic - a function(s) like this should already be available in your existing getPayload/blob bundle implementation.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p><strong>Invertibility invariant:</strong> <code>execution_payload_data_to_blobs</code> and <code>blobs_to_execution_payload_data</code> are mutual inverses on valid execution-payload data.</p> <h4 id="data-structures">Data structures</h4> <h5 id="executionpayloaddata">ExecutionPayloadData</h5> <p><strong>Execution-payload data</strong> refers to the subset of the ExecutionPayload that must be made available via blobs. This includes:</p> <ul> <li><code>bals</code> (Block Access List added in EIP-7928)</li> <li><code>transactions</code></li> </ul> <p>See <a href="https://wg-eips.ritovision.com/8142/#what-is-included-in-execution-payload-data">What is included in execution-payload data?</a> in the Rationale for details.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayloadData</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Block Access List (BAL) from EIP-7928, RLP-encoded</span></span> <span class="giallo-l"><span> blockAccessList</span><span>:</span><span class="z-support"> bytes</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> List of transactions, each transaction is RLP-encoded</span></span> <span class="giallo-l"><span> transactions</span><span>:</span><span> List</span><span>[</span><span>Transaction</span><span>,</span><span class="z-constant"> MAX_TRANSACTIONS_PER_PAYLOAD</span><span>]</span></span></code></pre> <p><strong>Note:</strong> This is not an SSZ Container - fields are RLP-encoded as described in the encoding functions. The <code>MAX_TRANSACTIONS_PER_PAYLOAD</code> bound is inherited from the ExecutionPayload field limit defined in the consensus specification.</p> <h5 id="executionpayloadheader">ExecutionPayloadHeader</h5> <p>This EIP adds a new field to the <code>ExecutionPayloadHeader</code>:</p> <ul> <li>payload_blob_count : uint64</li> </ul> <p>Semantics:</p> <ul> <li>Let <code>blob_kzg_commitments</code> be the ordered list of kzg commitments referenced by the beacon block</li> <li>The first <code>payload_blob_count</code> entries of <code>blob_kzg_commitments</code> are the payload-blob commitments (i.e. commitments to the blobs that correspond to the payload data)</li> <li>The remaining entries (if any) are for type-3 blob transactions.</li> </ul> <h5 id="blobsbundle">BlobsBundle</h5> <p>For the zkEVM-optimized variant of <code>engine_getPayload</code>, this EIP extends <code>BlobsBundle</code> with an additional field:</p> <ul> <li><code>payload_kzg_proofs</code>: List[KZGProof]</li> </ul> <p>Semantics:</p> <ul> <li>Contains random point KZG proofs for payload blobs only (not type-3 transaction blobs)</li> <li>Used as private inputs to the zkEVM circuit for payload consistency verification via <code>verify_blob_kzg_proof_batch</code></li> <li>The length of this list equals <code>payload_blob_count</code></li> </ul> <h4 id="engine-api">Engine API</h4> <p>This section specifies two equivalent formulations of <code>new_payload</code>. Implementers choose one based on their execution context:</p> <ul> <li><strong>Native execution variant</strong>: Uses <code>blob_to_kzg_commitment</code> directly. Suitable for pre mandatory proofs implementations.</li> <li><strong>zkEVM-optimized variant</strong>: Uses polynomial openings via <code>verify_blob_kzg_proof_batch</code>. Avoids the multiscalar multiplication (MSM) which is expensive to prove in a zkEVM circuit.</li> </ul> <p>Both variants enforce identical validity conditions. A block valid under one is valid under the other.</p> <h5 id="engine-getpayload-native-variant">engine_getPayload - Native Variant</h5> <p>The builder must compute the payload blob count when constructing the block:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_payload</span><span>(</span><span class="z-variable z-parameter z-function">payload_id</span><span>:</span><span> PayloadId</span><span>)</span><span> -&gt;</span><span> GetPayloadResponse</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Build the block (select transactions, etc.)</span></span> <span class="giallo-l"><span> payload</span><span class="z-keyword"> =</span><span> build_execution_payload</span><span>(</span><span>payload_id</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Compute payload blobs to determine count</span></span> <span class="giallo-l"><span> payload_data</span><span class="z-keyword"> =</span><span> get_execution_payload_data</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> payload_blobs</span><span class="z-keyword"> =</span><span> execution_payload_data_to_blobs</span><span>(</span><span>payload_data</span><span>)</span></span> <span class="giallo-l"><span> payload_blob_count</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>payload_blobs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 4. Set the count in the header</span></span> <span class="giallo-l"><span> payload</span><span>.</span><span>payload_blob_count</span><span class="z-keyword"> =</span><span> payload_blob_count</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 5. Compute blob commitments and cell proofs for payload blobs</span></span> <span class="giallo-l"><span> payload_commitments</span><span class="z-keyword"> =</span><span> [</span><span>blob_to_kzg_commitment</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> payload_blobs</span><span>]</span></span> <span class="giallo-l"><span> payload_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>kzg_commitment_to_versioned_hash</span><span>(</span><span>c</span><span>)</span><span class="z-keyword"> for</span><span> c</span><span class="z-keyword"> in</span><span> payload_commitments</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute cells and cell proofs</span></span> <span class="giallo-l"><span> payload_cells_and_proofs</span><span class="z-keyword"> =</span><span> [</span><span>compute_cells_and_kzg_proofs</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> payload_blobs</span><span>]</span></span> <span class="giallo-l"><span> payload_cell_proofs</span><span class="z-keyword"> =</span><span> [</span><span>proofs</span><span class="z-keyword"> for</span><span> _</span><span>,</span><span> proofs</span><span class="z-keyword"> in</span><span> payload_cells_and_proofs</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 6. Extract type-3 transaction blobs, commitments, and cell proofs</span></span> <span class="giallo-l"><span> type3_blobs</span><span>,</span><span> type3_commitments</span><span>,</span><span> type3_cell_proofs</span><span class="z-keyword"> =</span><span> extract_data_from_type_3_tx</span><span>(</span><span>payload</span><span>.</span><span>transactions</span><span>)</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> payload</span><span>.</span><span>transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span>.</span><span>extend</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 7. Combine: payload blobs first, then type-3 blobs</span></span> <span class="giallo-l"><span> all_blobs</span><span class="z-keyword"> =</span><span> payload_blobs</span><span class="z-keyword"> +</span><span> type3_blobs</span></span> <span class="giallo-l"><span> all_commitments</span><span class="z-keyword"> =</span><span> payload_commitments</span><span class="z-keyword"> +</span><span> type3_commitments</span></span> <span class="giallo-l"><span> all_cell_proofs</span><span class="z-keyword"> =</span><span> payload_cell_proofs</span><span class="z-keyword"> +</span><span> type3_cell_proofs</span></span> <span class="giallo-l"><span> all_blob_versioned_hashes</span><span class="z-keyword"> =</span><span> payload_versioned_hashes</span><span class="z-keyword"> +</span><span> type3_versioned_hashes</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> GetPayloadResponse</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> execution_payload</span><span class="z-keyword">=</span><span>payload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> blobs_bundle</span><span class="z-keyword">=</span><span>BlobsBundle</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> commitments</span><span class="z-keyword">=</span><span>all_commitments</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> blobs</span><span class="z-keyword">=</span><span>all_blobs</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> proofs</span><span class="z-keyword">=</span><span>all_cell_proofs</span></span> <span class="giallo-l"><span> )</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> block_value</span><span class="z-keyword">=</span><span>calculate_block_value</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>Note: The builder must account for payload blob usage when selecting type-3 transactions to ensure the total blob count does not exceed <code>MAX_BLOBS_PER_BLOCK</code>.</p> <h5 id="engine-getpayload-zkevm-optimized-variant">engine_getPayload - zkEVM-Optimized Variant</h5> <p>For the zkEVM-optimized variant, the builder must additionally compute random point KZG proofs for the payload blobs, which will be used as private inputs in the zkEVM circuit for payload consistency verification.</p> <p>This variant extends <code>BlobsBundle</code> with an additional <code>payload_kzg_proofs</code> field containing random point KZG proofs for payload blobs.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_payload_zk</span><span>(</span><span class="z-variable z-parameter z-function">payload_id</span><span>:</span><span> PayloadId</span><span>)</span><span> -&gt;</span><span> GetPayloadResponse</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Build the block (select transactions, etc.)</span></span> <span class="giallo-l"><span> payload</span><span class="z-keyword"> =</span><span> build_execution_payload</span><span>(</span><span>payload_id</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Compute payload blobs to determine count</span></span> <span class="giallo-l"><span> payload_data</span><span class="z-keyword"> =</span><span> get_execution_payload_data</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> payload_blobs</span><span class="z-keyword"> =</span><span> execution_payload_data_to_blobs</span><span>(</span><span>payload_data</span><span>)</span></span> <span class="giallo-l"><span> payload_blob_count</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>payload_blobs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 4. Set the count in the header</span></span> <span class="giallo-l"><span> payload</span><span>.</span><span>payload_blob_count</span><span class="z-keyword"> =</span><span> payload_blob_count</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 5. Compute commitments, cell proofs, and random point proofs for payload blobs</span></span> <span class="giallo-l"><span> payload_commitments</span><span class="z-keyword"> =</span><span> [</span><span>blob_to_kzg_commitment</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> payload_blobs</span><span>]</span></span> <span class="giallo-l"><span> payload_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>kzg_commitment_to_versioned_hash</span><span>(</span><span>c</span><span>)</span><span class="z-keyword"> for</span><span> c</span><span class="z-keyword"> in</span><span> payload_commitments</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Cell proofs</span></span> <span class="giallo-l"><span> payload_cells_and_proofs</span><span class="z-keyword"> =</span><span> [</span><span>compute_cells_and_kzg_proofs</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> payload_blobs</span><span>]</span></span> <span class="giallo-l"><span> payload_cell_proofs</span><span class="z-keyword"> =</span><span> [</span><span>proofs</span><span class="z-keyword"> for</span><span> _</span><span>,</span><span> proofs</span><span class="z-keyword"> in</span><span> payload_cells_and_proofs</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Random point proofs for payload consistency verification</span></span> <span class="giallo-l"><span> payload_random_point_proofs</span><span class="z-keyword"> =</span><span> [</span><span>compute_blob_kzg_proof</span><span>(</span><span>b</span><span>,</span><span> c</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span>,</span><span> c</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>payload_blobs</span><span>,</span><span> payload_commitments</span><span>)</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 6. Extract type-3 transaction blobs, commitments, and cell proofs</span></span> <span class="giallo-l"><span> type3_blobs</span><span>,</span><span> type3_commitments</span><span>,</span><span> type3_cell_proofs</span><span class="z-keyword"> =</span><span> extract_data_from_type_3_tx</span><span>(</span><span>payload</span><span>.</span><span>transactions</span><span>)</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> payload</span><span>.</span><span>transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span>.</span><span>extend</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 7. Combine: payload blobs first, then type-3 blobs</span></span> <span class="giallo-l"><span> all_blobs</span><span class="z-keyword"> =</span><span> payload_blobs</span><span class="z-keyword"> +</span><span> type3_blobs</span></span> <span class="giallo-l"><span> all_commitments</span><span class="z-keyword"> =</span><span> payload_commitments</span><span class="z-keyword"> +</span><span> type3_commitments</span></span> <span class="giallo-l"><span> all_cell_proofs</span><span class="z-keyword"> =</span><span> payload_cell_proofs</span><span class="z-keyword"> +</span><span> type3_cell_proofs</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> GetPayloadResponse</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> execution_payload</span><span class="z-keyword">=</span><span>payload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> blobs_bundle</span><span class="z-keyword">=</span><span>BlobsBundle</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> commitments</span><span class="z-keyword">=</span><span>all_commitments</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> blobs</span><span class="z-keyword">=</span><span>all_blobs</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> proofs</span><span class="z-keyword">=</span><span>all_cell_proofs</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> payload_kzg_proofs</span><span class="z-keyword">=</span><span>payload_random_point_proofs</span></span> <span class="giallo-l"><span> )</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> block_value</span><span class="z-keyword">=</span><span>calculate_block_value</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p><strong>Note for implementors:</strong></p> <ul> <li>The <code>payload_kzg_proofs</code> field contains KZG opening proofs for payload blobs only. It is used for payload consistency verification via <code>verify_blob_kzg_proof_batch</code>.</li> <li>The builder/prover should extract the first <code>payload_blob_count</code> commitments from <code>all_commitments</code> (i.e., <code>all_commitments[:payload_blob_count]</code>). This corresponds to the <code>payload_kzg_commitments</code> parameter in the zkEVM variant of <code>engine_newPayload</code>.</li> </ul> <h5 id="engine-newpayload-native-execution-variant">engine_newPayload - Native Execution Variant</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> new_payload</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> payload</span><span>:</span><span> ExecutionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> expected_blob_versioned_hashes</span><span>:</span><span> List</span><span>[</span><span>VersionedHash</span><span>]</span><span>,</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> PayloadStatus</span><span>:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Derive payload blobs and commitments</span></span> <span class="giallo-l"><span> payload_data</span><span class="z-keyword"> =</span><span> get_execution_payload_data</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> payload_blobs</span><span class="z-keyword"> =</span><span> execution_payload_data_to_blobs</span><span>(</span><span>payload_data</span><span>)</span></span> <span class="giallo-l"><span> payload_blob_count</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>payload_blobs</span><span>)</span></span> <span class="giallo-l"><span> payload_commitments</span><span class="z-keyword"> =</span><span> [</span><span>blob_to_kzg_commitment</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> payload_blobs</span><span>]</span></span> <span class="giallo-l"><span> payload_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>kzg_commitment_to_versioned_hash</span><span>(</span><span>c</span><span>)</span><span class="z-keyword"> for</span><span> c</span><span class="z-keyword"> in</span><span> payload_commitments</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Verify payload_blob_count matches header</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> payload_blob_count</span><span class="z-keyword"> ==</span><span> payload</span><span>.</span><span>payload_blob_count</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 3. Extract type-3 tx versioned hashes</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> payload</span><span>.</span><span>transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span> type3_versioned_hashes</span><span>.</span><span>extend</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 4. Verify versioned hashes: payload blobs first, then type-3</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> expected_blob_versioned_hashes</span><span class="z-keyword"> ==</span><span> payload_versioned_hashes</span><span class="z-keyword"> +</span><span> type3_versioned_hashes</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 5. Run EL STF</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> execute_payload</span><span>(</span><span>payload</span><span>)</span></span></code></pre><h5 id="engine-newpayload-zkevm-optimized-variant">engine_newPayload - zkEVM-Optimized Variant</h5> <p><strong>Note:</strong> Once zkEVM proofs are required for consensus, <code>newPayload</code> will be executed inside a zkEVM to generate a proof, rather than being executed natively by validators. This variant is designed to be cheaper in that context.</p> <p>This variant replaces the MSM in <code>blob_to_kzg_commitment</code> with polynomial opening proofs, which are cheaper to verify inside a zkEVM. The payload, commitments and KZG proofs are private inputs to the zkEVM circuit, while the corresponding versioned hashes (and payload header) are public inputs.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> new_payload</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> payload</span><span>:</span><span> ExecutionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> expected_blob_versioned_hashes</span><span>:</span><span> List</span><span>[</span><span>VersionedHash</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> public input</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> BiB additions: prefix metadata for payload blobs</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> payload_kzg_commitments</span><span>:</span><span> List</span><span>[</span><span>KZGCommitment</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> private input</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> payload_kzg_proofs</span><span>:</span><span> List</span><span>[</span><span>KZGProof</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> private input</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> PayloadStatus</span><span>:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0. Declared payload blob count from the header</span></span> <span class="giallo-l"><span> n</span><span class="z-keyword"> =</span><span> payload</span><span>.</span><span>payload_blob_count</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>payload_kzg_commitments</span><span>)</span><span class="z-keyword"> ==</span><span> n</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>payload_kzg_proofs</span><span>)</span><span class="z-keyword"> ==</span><span> n</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Construct payload blobs from execution-payload data</span></span> <span class="giallo-l"><span> payload_data</span><span class="z-keyword"> =</span><span> get_execution_payload_data</span><span>(</span><span>payload</span><span>)</span></span> <span class="giallo-l"><span> payload_blobs</span><span class="z-keyword"> =</span><span> execution_payload_data_to_blobs</span><span>(</span><span>payload_data</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>payload_blobs</span><span>)</span><span class="z-keyword"> ==</span><span> n</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Check the commitments correspond to the expected versioned hash prefix</span></span> <span class="giallo-l"><span> payload_versioned_hashes</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span> kzg_commitment_to_versioned_hash</span><span>(</span><span>c</span><span>)</span><span class="z-keyword"> for</span><span> c</span><span class="z-keyword"> in</span><span> payload_kzg_commitments</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> expected_blob_versioned_hashes</span><span>[</span><span>:</span><span>n</span><span>]</span><span class="z-keyword"> ==</span><span> payload_versioned_hashes</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 3. Verify blob–commitment consistency using batch KZG proof verification</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> verify_blob_kzg_proof_batch</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> blobs</span><span class="z-keyword">=</span><span>payload_blobs</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> commitments</span><span class="z-keyword">=</span><span>payload_kzg_commitments</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> proofs</span><span class="z-keyword">=</span><span>payload_kzg_proofs</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 4. Proceed with standard EL payload validation / execution</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> execute_payload</span><span>(</span><span>payload</span><span>)</span></span></code></pre><h3 id="consensus-layer">Consensus Layer</h3> <h4 id="validation">Validation</h4> <p>The consensus layer does not introduce new blob specific validation rules for payload-blobs beyond what we have for EIP-4844/EIP-7594.</p> <p>The Consensus Layer relies on <code>payload_blob_count</code> in the ExecutionPayloadHeader to interpret the ordering of blob commitments, but otherwise treats payload blobs identically to other blobs for availability and networking.</p> <h3 id="networking">Networking</h3> <p>BiB reuses the existing blob networking mechanism.</p> <p>We note the following for consideration:</p> <ul> <li> <p>Once proofs are made mandatory, a mechanism will be needed for execution payload retrieval. <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a> introduces an <code>execution_payload</code> gossip topic that we can use for this purpose. However, in the context of mandatory proofs where a super majority of stake operates zk validators (which only listen to header topics), a malicious builder could publish only the payload in blobs and gossip the execution payload header without gossiping on the <code>execution_payload</code> topic. This would allow zk validators to attest, but other nodes depending on the full payload from the gossip topic would be unable to progress.</p> </li> <li> <p>To mitigate this, nodes can implement a fallback mechanism: if they don't receive the payload on the <code>execution_payload</code> topic, they reconstruct it from the first <code>payload_blob_count</code> blobs and then seed the <code>execution_payload</code> topic themselves. This creates a resilient system where every node acts as a "bridge node" when needed, similar to how rollups use L2 gossip as a fast path but fall back to L1 data availability.</p> </li> <li> <p>Unlike most type-3 blob transactions, payload-blobs will not have been propagated to the network before a block is built. Depending on the deadlines imposed by ePBS, this may imply higher bandwidth requirements from block builders.</p> </li> </ul> <h3 id="fee-accounting">Fee Accounting</h3> <p>BiB introduces protocol mandated blob usage, rather than user initiated via type-3 transactions. Fee accounting for payload-blobs differ in nature from transaction blob fees as a result.</p> <h4 id="who-pays">Who pays?</h4> <p>This EIP does not mandate that payload-blobs pay a per-blob fee like transaction blobs.</p> <p>Instead payload-blobs are treated as a protocol-accepted cost when constructing the block. In particular:</p> <ul> <li>Payload-blobs do not correspond to a user transaction and therefore do not naturally map to a user-paid blob fee.</li> <li>The cost of including payload-blobs, in terms of blob gas usage, is accepted by the protocol as a necessary cost for maintaining data availability.</li> </ul> <h4 id="do-payload-blobs-compete-with-transaction-blobs-for-capacity">Do payload-blobs compete with transaction blobs for capacity?</h4> <p>Because payload blobs consume blob gas, they directly influence blob congestion and the blob base fee.</p> <h4 id="can-a-builder-artificially-inflate-blob-gas-usage">Can a builder artificially inflate blob gas usage?</h4> <p>A potential concern is whether a malicious builder could create artificially large execution payloads to inflate blob gas usage.</p> <p>This attack is economically constrained: to increase the size of the execution payload, a builder must include additional transactions with calldata. Since calldata costs execution gas, the builder would need to pay for this additional data through the normal gas mechanism. The cost of including extra calldata makes it economically unfavorable to artificially inflate payload size solely to manipulate blob fees.</p> <h4 id="open-questions-and-future-considerations">Open questions and future considerations</h4> <!-- TODO --> <ul> <li>Networking related: Payload-blobs require higher bandwidth due to the fact that they will not have been in the public mempool</li> <li>Explicit protocol level pricing for payload blobs</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="what-is-included-in-execution-payload-data">What is included in execution-payload data?</h3> <p>Execution-payload data includes <code>bals</code> (Block Access Lists from EIP-7928) and <code>transactions</code>.</p> <p><strong>Why transactions?</strong> Transaction data is the only component of the execution payload that cannot be derived from other components and is not provided by the consensus layer.</p> <p><strong>Why BALs?</strong> While BALs are technically the output of executing transactions and could be recomputed, once zkEVM proofs become mandatory for consensus, validators no longer execute payloads. A malicious builder could publish a valid proof and withhold both the execution payload data and the BALs. This would prevent other builders from constructing subsequent blocks and prevent RPC providers from serving the full state. Including BALs in payload-blobs ensures they remain available.</p> <p><strong>Why not withdrawals?</strong> Withdrawals can be derived on the consensus layer.</p> <p><strong>Why not execution requests?</strong> Execution requests can be recomputed from transactions and do not suffer from the same withholding attack as BALs because they are required by the consensus layer for validation.</p> <p><strong>Why not the header?</strong> The header cannot be put into blobs because it contains <code>payload_blob_count</code>, which depends on the number of blobs; causing a circular dependency.</p> <p><strong>Encoding optimization:</strong> The encoding includes an 8-byte header: <code>[4 bytes BAL length] [4 bytes transaction length]</code>. This allows extracting just the tx data after fetching the first blob.</p> <!-- TODO --> <p>TODO: We could also put the number of blobs that the BAL occupies in the execution payload header.</p> <h3 id="builder-discretion-vs-reserving-k-blobs">Builder discretion vs reserving <code>k</code> blobs</h3> <p>This EIP specifies that the block builder choose <code>payload_blob_count</code>, subject to the constraint imposed by <code>MAX_BLOBS_PER_BLOCK</code>.</p> <p>An alternative would have been to always reserve <code>k</code> blobs, where <code>k</code> corresponds to the worst case execution payload size. While this provides better predictability, it reduces flexibility under blob congestion.</p> <h3 id="why-not-encode-execution-payload-data-inside-the-core-el-execution-logic">Why not encode execution-payload data inside the core EL execution logic?</h3> <p>Doing it in the EL STF would require payload-blob commitments or versioned hashes to be made visible inside the core execution logic, rather than being handled at the Engine API boundary.</p> <h3 id="when-zkevm-proofs-become-mandatory-why-can-t-zk-attestors-download-the-full-execution-payload">When zkEVM proofs become mandatory, why can't zk-attestors download the full execution payload?</h3> <p>The execution payload grows linearly with the gas limit. Requiring attesters to download the payload for DA would create an increasing bandwidth burden as the gas limit grows.</p> <h3 id="compression-algorithm-for-encoding-execution-payload-data">Compression algorithm for encoding execution-payload data</h3> <p>Compression can be used on the serialized execution-payload data. This (in theory) should allow the usage of less payload-blobs, depending on the compression ratio. The tradeoffs being:</p> <ul> <li>That we will use more CPU/proving cycles for decompression</li> <li>A breaking change since we want to decompress on the hot-path. What this means is that the transactions would need to be compressed in the payload, and then decompressed when we attempt to validate it.</li> </ul> <p>Whether we should use a compression algorithm and which one requires more investigation, in particular we need to investigate:</p> <ul> <li>The average compression ratios achieved</li> <li>The proving cycle overhead</li> <li>The invasiveness of now requiring consensus aware objects to be compressed when passed for validation.</li> </ul> <p>For now we recommend using no compression algorithm and operating on uncompressed data.</p> <h3 id="serialization-algorithm-for-encoding-execution-payload-data">Serialization algorithm for encoding execution-payload data</h3> <p>Serialization of the execution-payload data uses RLP. Since transactions in the ExecutionPayload are already RLP-encoded, we simply RLP-encode the list of transaction bytes without any additional transformation.</p> <p>While a more zk-friendly serialization algorithm could be beneficial in the future, this EIP uses RLP for simplicity. Once EIP-7807 (SSZ execution blocks) is implemented, the encoding can be updated to SSZ-serialize the list of SSZ-encoded transaction bytes.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This requires changes to the execution payload header and the EL STF; so requires a fork. Nodes that do not implement BiB will not be able to validate blocks after activation.</p> <h2 id="test-cases">Test Cases</h2> <!-- TODO --> <p>TODO</p> <h2 id="reference-implementation">Reference Implementation</h2> <!-- TODO --> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p><strong>Interaction with blob congestion and denial-of-service</strong></p> <p>Payload-blobs consume blob gas and therefore are subject to the same congestion control mechanisms and blob limits as transaction blobs.</p> <p>As a byproduct, this ensures that a malicious block producer cannot make arbitrarily large execution payloads without accounting for blob gas limits. While a block producer could theoretically drive up the blob base fee by creating large payloads, this attack is economically constrained by calldata costs (see <a href="https://wg-eips.ritovision.com/8142/#fee-accounting">Fee Accounting</a> for details).</p> <p><strong>Data withholding</strong></p> <p>An attacker cannot withhold execution payload data without also withholding blob data, which would violate existing DAS guarantees and cause the block to be rejected by the consensus layer.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2026-01-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Han Nghttps://github.com/weiihann https://wg-eips.ritovision.com/8125/

Adds bounded-lifetime contract storage via TMPLOAD/TMPSTORE opcodes that is automatically cleared on a fixed schedule.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces <em>temporary storage</em>: a new contract-accessible key-value store that persists across transactions and blocks, but is automatically cleared at a protocol-defined schedule. Two new opcodes are added:</p> <ul> <li><code>TMPSTORE(key, value)</code> to write temporary storage for the executing contract.</li> <li><code>TMPLOAD(key)</code> to read temporary storage for the executing contract.</li> </ul> <p>Temporary storage is intended for data that does not need indefinite retention, providing a safer alternative to using permanent state for ephemeral data and enabling bounded growth of this class of state.</p> <h2 id="motivation">Motivation</h2> <p><img src="https://wg-eips.ritovision.com/8125/./assets/1.png" alt="" /></p> <p><em>Figure 1: Over 60% of the storage slots are written once and never accessed again onchain.</em></p> <p>Permanent contract storage is costly because it increases long-term node resource requirements (disk, I/O, state maintenance). However, many applications write data that is only valuable for a bounded time window.</p> <p>This EIP provides:</p> <ul> <li><strong>Bounded lifetime semantics</strong> without requiring explicit deletes.</li> <li><strong>Predictable clearing</strong> that can be relied upon at the application layer.</li> <li><strong>A building block</strong> for reducing state growth created by ephemeral use cases.</li> </ul> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="constants-and-parameters">Constants and parameters</h3> <table><thead><tr><th>Name</th><th style="text-align: center">Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td style="text-align: center">TBD</td><td>Activation block of this EIP</td></tr> <tr><td><code>TEMP_STORAGE_PERIOD</code></td><td style="text-align: center">TBD</td><td>The number of blocks that the temporary storage holds for a given period</td></tr> <tr><td><code>TEMP_STORAGE_SYSTEM_ADDRESS_0</code></td><td style="text-align: center">TBD</td><td>First reserved address used to store temporary storage</td></tr> <tr><td><code>TEMP_STORAGE_SYSTEM_ADDRESS_1</code></td><td style="text-align: center">TBD</td><td>Second reserved address used to store temporary storage</td></tr> <tr><td><code>TMPLOAD_GAS</code></td><td style="text-align: center">TBD</td><td>The gas cost of a warm read at temporary storage slot</td></tr> <tr><td><code>COLD_TMPLOAD_COST</code></td><td style="text-align: center">TBD</td><td>The gas cost surchage of a cold access at the temporary storage</td></tr> <tr><td><code>TMPSTORE_SET_GAS</code></td><td style="text-align: center">TBD</td><td>The gas cost of setting a slot from zero to non-zero at the temporary storage</td></tr> <tr><td><code>TMPSTORE_RESET_GAS</code></td><td style="text-align: center">TBD</td><td>The gas cost of changing a non-zero slot to another value at the temporary storage</td></tr> </tbody></table> <h3 id="temporary-storage-data-model">Temporary storage data model</h3> <p>Temporary storage is backed by <strong>two reserved system accounts</strong> at <code>TEMP_STORAGE_SYSTEM_ADDRESS_0</code> and <code>TEMP_STORAGE_SYSTEM_ADDRESS_1</code>.</p> <p>The temporary storage keyspace is a mapping of <code>(contract_address, key) -&gt; value</code>, where:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>derived_slot_key = keccak256(contract_address || key)</span></span></code></pre> <p>Temporary storage values are stored in the regular storage tries of the system accounts using <code>derived_slot_key</code> as the slot key.</p> <h3 id="periodic-rollover-storage-reset">Periodic rollover (storage reset)</h3> <p>Temporary storage is organized into periods, each of length <code>TEMP_STORAGE_PERIOD</code> blocks after activation.</p> <p>For blocks with <code>block.number &gt;= FORK_BLOCK</code>, define:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>period_index(block_number) = floor((block_number - FORK_BLOCK) / TEMP_STORAGE_PERIOD)</span></span></code></pre> <p>Define the current and previous system accounts for a block <code>B</code> (where <code>B.number &gt;= FORK_BLOCK</code>) as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>current_index = period_index(B.number) % 2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if current_index == 0:</span></span> <span class="giallo-l"><span> CURRENT_SYSADDR = TEMP_STORAGE_SYSTEM_ADDRESS_0</span></span> <span class="giallo-l"><span> PREVIOUS_SYSADDR = TEMP_STORAGE_SYSTEM_ADDRESS_1</span></span> <span class="giallo-l"><span>else if current_index == 1:</span></span> <span class="giallo-l"><span> CURRENT_SYSADDR = TEMP_STORAGE_SYSTEM_ADDRESS_1</span></span> <span class="giallo-l"><span> PREVIOUS_SYSADDR = TEMP_STORAGE_SYSTEM_ADDRESS_0</span></span></code></pre> <p>At the first block of each new period, the protocol MUST clear the storage of the system account that becomes the current.</p> <p>When processing a block <code>B</code> (with parent <code>P</code>) where both are <code>&gt;= FORK_BLOCK</code>, if <code>period_index(B.number) &gt; period_index(P.number)</code>, then before executing transactions in <code>B</code>, the protocol MUST perform:</p> <ul> <li><code>CURRENT_SYSADDR.storageRoot = EMPTY_TRIE_ROOT</code></li> </ul> <p>where <code>CURRENT_SYSADDR</code> is computed from <code>B.number</code> as specified above.</p> <p>No other accounts are modified by the rollover.</p> <p><strong>Effect:</strong> After rollover, entries written in the immediately previous period remain readable via <code>PREVIOUS_SYSADDR</code> for one additional period, while entries older than one period are removed.</p> <h3 id="new-opcodes">New opcodes</h3> <p>Add 2 new opcodes as follows:</p> <h4 id="tmpload-key"><code>TMPLOAD(key)</code></h4> <p>Compute <code>derived_slot_key</code> from <code>(contract_address, key)</code>. Then load <code>derived_slot_key</code> from <code>CURRENT_SYSADDR</code> first. If it doesn't exist (i.e. <code>value == 0</code> ), then load <code>derived_slot_key</code> from <code>PREV_SYSADDR</code>.</p> <h4 id="tmpstore-key-value"><code>TMPSTORE(key,value)</code></h4> <p>Compute <code>derived_slot_key</code> from <code>(contract_address, key)</code>. Then:</p> <ul> <li>If <code>value != 0</code>, store in the storage of <code>CURRENT_SYSADDR</code>.</li> <li>If <code>value == 0</code>, delete slot from both <code>CURRENT_SYSADDR</code> and <code>PREV_SYSADDR</code>.</li> </ul> <p><strong>Rationale:</strong> Because reads fall back from current to previous, clearing only the current store would allow an older previous-period value to be returned. Clearing both ensures <code>TMPSTORE(key,0)</code> makes subsequent <code>TMPLOAD(key)</code> return <code>0</code> (until a new non-zero is written).</p> <p>The call rules should follow <code>SSTORE</code> and <code>SLOAD</code>.</p> <p>The gas rules should follow the conventions in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> and <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> referencing <code>SSTORE</code> and <code>SLOAD</code>, except that:</p> <ul> <li>The gas costs should be much lower than <code>SSTORE</code> and <code>SLOAD</code>, but higher than <code>TSLOAD</code> and <code>TSTORE</code></li> <li>No refunds are given for clearing temporary storage</li> <li><code>TMPLOAD</code> MAY perform up to 2 storage reads (current then previous). Gas MUST account for this behaviour.</li> <li>Deletion in <code>TMPSTORE</code> is more expensive than creation/modification as the storage root of both system accounts are updated. Gas MUST account for this behaviour.</li> </ul> <h3 id="activation-and-reserved-address">Activation and reserved address</h3> <p>At <code>FORK_BLOCK</code>, the chain MUST treat <code>TEMP_STORAGE_SYSTEM_ADDRESS_0</code> and <code>TEMP_STORAGE_SYSTEM_ADDRESS_1</code> as reserved addresses:</p> <ul> <li>If either does not exist in the state trie, it is created with: <ul> <li><code>nonce = 1</code></li> <li><code>balance = 0</code></li> <li><code>codeHash = EMPTY_CODE_HASH</code></li> <li><code>storageRoot = EMPTY_TRIE_ROOT</code></li> </ul> </li> </ul> <p>No contract code is deployed at this address.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-not-just-use-transient-storage-eip-1153">Why not just use transient storage (EIP-1153)?</h3> <p><a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a> (transient storage) is discarded after every transaction, which is ideal for intra-tx operations. This EIP targets a different class of use cases where data must persist across multiple transactions/blocks, but does not need indefinite retention.</p> <h3 id="why-two-period-rollover">Why two-period rollover?</h3> <p>Two-period rollover provides a stronger usability guarantee:</p> <ul> <li>An entry is retained for <strong>at least</strong> one full <code>TEMP_STORAGE_PERIOD</code> after it is written (it will be readable in the next period via the previous-period system account).</li> <li>An entry is retained for <strong>at most</strong> two periods (once the current-period system account is cleared and reused).</li> </ul> <p>This provides a simple mental model for contract developers. That is, if an entry is stored in temporary storage, it will at least last for <code>TEMP_STORAGE_PERIOD</code>.</p> <p>In contrast, a single global rollover makes effective lifetime depend on when data is written within the period: a write near the end of a period could be cleared almost immediately, which may not be developer-friendly.</p> <h3 id="why-two-system-accounts">Why two system accounts?</h3> <p>Using two reserved system accounts allows constant-time rollover:</p> <ul> <li>At each period boundary, only the <strong>current-period</strong> system account is reset by setting a single <code>storageRoot = EMPTY_TRIE_ROOT</code>.</li> <li>The previous-period system account remains intact for one more period.</li> <li>Storage older than one period becomes unreachable and can be pruned.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork to implement.</p> <p>It does not change behavior of any existing opcodes. Therefore, it is backward compatible with all existing contract accounts.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li><strong>DoS surface</strong>: Temporary storage writes still create state that must be processed and stored for at least 1 period. Gas costs should be calibrated so that worst-case temp writes do not create new per-block disk I/O DoS attack vectors beyond existing storage writes.</li> <li><strong>Reorg safety</strong>: Clients should retain sufficient history to handle plausible reorg depths.</li> <li><strong>Application safety</strong>: Contracts MUST treat temp storage as ephemeral and handle the case where entries are unexpectedly missing.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2026-01-07T00:00:00+00:00 2026-02-11T14:49:27+00:00 Helkominehttps://github.com/Helkomine https://wg-eips.ritovision.com/8120/

Adds EVM opcodes for efficient single-byte memory and calldata loads.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces new EVM opcodes that allow loading a single byte from memory or calldata in a single operation, reducing gas cost and bytecode size compared to existing patterns based on <code>MLOAD (0x51)</code> or <code>CALLDATALOAD (0x35)</code> followed by bit shifting.</p> <h2 id="motivation">Motivation</h2> <p>Currently, the only way to read a single byte from calldata or memory is to use <code>CALLDATALOAD</code> or <code>MLOAD</code> and then shift the loaded 32-byte word. For example, reading the byte at offset x from calldata requires:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH x</span></span> <span class="giallo-l"><span>CALLDATALOAD</span></span> <span class="giallo-l"><span>PUSH1 248</span></span> <span class="giallo-l"><span>SHR</span></span></code></pre> <p>This pattern increases runtime gas cost and adds three extra bytes to the deployed bytecode for each single-byte access. Contracts that frequently parse byte-oriented calldata or instruction streams incur unnecessary overhead. This EIP proposes two new opcodes that allow loading a single byte directly in one operation.</p> <h2 id="specification">Specification</h2> <h3 id="mload8-tbd">MLOAD8 (TBD)</h3> <!-- TODO: Replace TBD with assigned opcode value --> <ul> <li><strong>Stack input</strong>: <code>offset</code></li> <li><strong>Stack output</strong>: <code>value</code></li> </ul> <p>Reads one byte from memory at position offset and pushes it onto the stack as a 32-byte word, with the byte placed in the least significant position. Memory expansion occurs prior to the load, after which the loaded byte is read. If the accessed byte lies beyond the previously allocated memory, the returned value is 0 due to zero-initialization. Memory expansion rules apply in the same way as for <code>MSTORE8</code> (extending memory to at least <code>offset + 1</code> bytes).</p> <h3 id="calldataload8-tbd">CALLDATALOAD8 (TBD)</h3> <!-- TODO: Replace TBD with assigned opcode value --> <ul> <li><strong>Stack input</strong>: <code>offset</code></li> <li><strong>Stack output</strong>: <code>value</code></li> </ul> <p>Reads one byte from calldata at position offset and pushes it onto the stack as a 32-byte word, with the byte placed in the least significant position. If offset is greater than or equal to <code>CALLDATASIZE (0x36)</code>, the returned value is 0.</p> <h3 id="gas-cost">Gas Cost</h3> <ul> <li>Base cost: 3 gas</li> <li><code>MLOAD8</code> additionally incurs memory expansion cost as defined by existing memory access rules. The base gas cost matches <code>MLOAD</code>, <code>MSTORE8</code>, and <code>CALLDATALOAD</code>, ensuring consistency with existing EVM pricing.</li> </ul> <h3 id="exceptional-conditions">Exceptional Conditions</h3> <p>Execution results in an exceptional halt if:</p> <ul> <li>There is insufficient gas to execute the instruction</li> <li>There are insufficient stack items (stack underflow)</li> </ul> <p>In both cases, execution halts and the current call frame is reverted, consistent with existing EVM behavior.</p> <h2 id="rationale">Rationale</h2> <h3 id="opcode-symmetry">Opcode Symmetry</h3> <p><code>MLOAD8</code> serves as a natural counterpart to <code>MSTORE8 (0x53)</code>: one stores exactly one byte from the stack to memory, while the other loads exactly one byte from memory to the stack. This symmetry improves conceptual clarity and developer ergonomics.</p> <h3 id="efficiency-for-byte-oriented-contracts">Efficiency for Byte-Oriented Contracts</h3> <p>Instruction-based architectures that interpret calldata as a sequence of byte-level commands benefit from reduced gas usage and smaller bytecode size when parsing instruction streams. A common pattern for reading a single byte from calldata today consists of the following instruction sequence:</p> <ul> <li><code>CALLDATALOAD</code> (3 gas)</li> <li><code>PUSH1</code> (3 gas)</li> <li><code>SHR</code> (3 gas)</li> </ul> <p>This results in a total cost of 9 gas per byte read, excluding additional stack manipulation overhead, and increases deployed bytecode size due to the extra instructions. Replacing this sequence with a single <code>CALLDATALOAD8</code> instruction priced at 3 gas saves 6 gas per byte read and reduces deployed bytecode size by approximately 3 bytes per occurrence. These savings compound in contracts that repeatedly parse byte-oriented calldata or instruction streams.</p> <h3 id="opcode-assignment">Opcode Assignment</h3> <p>While the final opcode values are subject to allocation during review, this proposal suggests placing <code>MLOAD8</code> and <code>CALLDATALOAD8</code> in the <code>0x4X</code> opcode range. The <code>0x5X</code> range, which primarily contains stack, memory, storage, and control flow operations, is largely exhausted. Tentative values of <code>0x4e</code> for <code>MLOAD8</code> and <code>0x4f</code> for <code>CALLDATALOAD8</code> are suggested to group these instructions near existing data access operations while minimizing the risk of opcode collisions. These assignments are intended to facilitate early client prototyping and collision checking and may be adjusted during the standardization process.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces new opcodes and does not modify the semantics of existing instructions. No backwards compatibility issues are introduced beyond those inherent to any opcode-adding hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Assume:</p> <ul> <li><code>calldata = 0x0123456789abcdef</code></li> <li><code>memory = 0xfedcba9876543210</code></li> </ul> <table><thead><tr><th>Bytecode</th><th>Description</th><th>Result</th></tr></thead><tbody> <tr><td><code>5f &lt;CALLDATALOAD8&gt;</code></td><td><code>PUSH0; CALLDATALOAD8</code></td><td>pushes <code>0x01</code></td></tr> <tr><td><code>6002 &lt;MLOAD8&gt;</code></td><td><code>PUSH1 0x02; MLOAD8</code></td><td>pushes <code>0xba</code></td></tr> <tr><td><code>&lt;CALLDATALOAD8&gt;</code></td><td>missing stack operand</td><td>exceptional halt</td></tr> <tr><td><code>&lt;MLOAD8&gt;</code></td><td>missing stack operand</td><td>exceptional halt</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>No new security considerations are introduced beyond those already known for memory and calldata access.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-12-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/8115/

Delay all priority fee credits from transactions to end of block

<h2 id="abstract">Abstract</h2> <p>This EIP defines how to optimize processing of priority fees from <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> fee market transactions.</p> <h2 id="motivation">Motivation</h2> <p>Priority fees are credited at the end of each transaction, leading to these complications:</p> <ol> <li> <p><strong>Limited parallelization:</strong> Each transaction writes to the fee recipient account balance.</p> </li> <li> <p><strong>Mempool complexities:</strong> A transaction sender may become solvent only after prior transactions in a block have been processed.</p> </li> <li> <p><strong>Accounting complexities:</strong> The fee recipient gets hundreds of micropayments for what could logically be a single credit.</p> </li> <li> <p><strong>Inaccurate logs:</strong> Proposals to emit logs on ETH transfers either have to omit priority fees, limiting their usefulness due to inaccuracies, or have to emit an extra entry for each individual fee, making them expensive.</p> </li> </ol> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="priority-fee-processing">Priority fee processing</h3> <p><a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> priority fees SHALL no longer be credited after each individual transaction. Instead, they SHALL be summed up and credited after all transactions of a block are processed but before <a href="https://wg-eips.ritovision.com/4895/">EIP-4895</a> withdrawals are processed.</p> <h2 id="rationale">Rationale</h2> <p>This EIP is one step towards fully accurate ETH balance logs. Batched crediting of priority fees improves parallel execution of transactions, as a transaction can no longer start with insufficient fees and only become eligible for execution after incremental priority fees have been credited.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The fee recipient now receives priority fees at the end of the block rather than incrementally after each transaction, making it only possible to spend them in the next block. This may require updates to block builder infrastructure and change liquidity requirements for MEV use cases.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security impact.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-12-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/8116/

Replace cumulativeGasUsed with gasUsed in on-chain receipt

<h2 id="abstract">Abstract</h2> <p>This EIP describes how to change the on-chain receipt data to track gas per transaction instead of cumulatively.</p> <h2 id="motivation">Motivation</h2> <p>Currently, on-chain receipts track a <code>cumulativeGasUsed</code> field which contains the running sum of all gas spent for all transactions in the block so far. This has a number of shortcomings:</p> <ol> <li> <p><strong>Inefficient verification:</strong> RPC clients that want to verify individual transaction <code>gasUsed</code> requires computation based on <code>cumulativeGasUsed</code> across consecutive receipts.</p> </li> <li> <p><strong>Limited parallelism:</strong> Receipt contents are stateful, even for transactions accessing mutually exclusive state.</p> </li> </ol> <p>The <code>logIndex</code> field exposed via JSON-RPC is currently also tracking an incremental block level index instead of a per-receipt index, with similar shortcomings.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="receipt-construction"><code>Receipt</code> construction</h3> <p>All receipts emitted after this EIP activates track the individual transaction's <code>gasUsed</code> instead of the incremental <code>cumulativeGasUsed</code> value.</p> <h3 id="json-rpc-api">JSON-RPC API</h3> <p>Within <code>logs</code>, the <code>logIndex</code> field is changed to indicate the log index position in the individual receipt, rather than in the entire block.</p> <h2 id="rationale">Rationale</h2> <p>This EIP is a step towards aligning on-chain data with the RPC data actually being consumed by client applications. Stateful components of receipts (<code>cumulativeGasUsed</code> / <code>logIndex</code>) are replaced with per-transaction equivalents.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Applications using verified <code>gasUsed</code> / <code>cumulativeGasUsed</code> values need to adapt to the new on-chain data semantics.</p> <p>Applications relying on the per block <code>logIndex</code> need adaptation, as <code>logIndex</code> now refers to an index per receipt. Note that this is solely an RPC change. Relative log ordering can be emulated by estimating <code>logIndex</code> as <code>transactionIndex * 4 + logIndex</code> (guaranteed to have same order as before, but absolute index values may be higher than before).</p> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-12-17T00:00:00+00:00 2026-02-11T14:49:28+00:00 Greg Colvinhttps://github.com/gcolvin Martin Holst Swendehttps://github.com/holiman Brooklyn Zelenkahttps://github.com/expede John Max Skallerskaller@internode.on.net https://wg-eips.ritovision.com/7979/

Three new instructions to support calls and returns, with optional validated control flow.

<h2 id="abstract">Abstract</h2> <p>This is the smallest possible change to the EVM to support calls and returns.</p> <p>This proposal introduces three new control-flow instructions to the EVM:</p> <ul> <li><code>CALLSUB</code> transfers control to the <code>destination</code> on the <code>stack</code>.</li> <li><code>ENTERSUB</code> marks a <code>CALLSUB</code> destination.</li> <li><code>RETURNSUB</code> returns to the <code>PC</code> after the most recent <code>CALLSUB</code>.</li> </ul> <p>Code can also be prefixed with <code>MAGIC</code> bytes. The complete control flow of <code>MAGIC</code> code can be traversed in time and space linear in the size of the code, enabling tools for validation, static analysis, and AOT and JIT compilers. On-chain, <code>MAGIC</code> code is validated at <code>CREATE</code> time to ensure that it cannot execute invalid instructions, jump to invalid locations, underflow stack, or, in the absence of recursion, overflow stack.</p> <p>These changes are backwards-compatible: all instructions behave as specified whether or not they appear in <code>MAGIC</code> code.</p> <h2 id="motivation">Motivation</h2> <p>In 2016 the lead author set out to write a compiler from the EVM to code for virtual or real register machines. The design was simple -- traverse the EVM stack code in one pass, emitting register code for the target machine. I was immediately stymied by the presence of dynamic jumps, which demand, worst case, a quadratic number of passes. <em>Dynamic jumps must die.</em></p> <p>How to kill them? First, some history.</p> <h3 id="babbage-1833-jumps-and-conditional-jumps">Babbage, 1833: Jumps and conditional jumps</h3> <p>In 1833 Charles Babbage began the design of a steam-powered, mechanical, Turing-complete computer. Programs were to be encoded on punched cards which controlled a system of rods, gears and other machinery to implement storage, arithmetic, jumps, and conditional jumps. Jumps were supported by a mechanism for shuffling forwards or backwards through the cards. Its first published description was by L. F. Menabre, 1842<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup>. The translator, Ada Augusta, Countess of Lovelace, made extensive notes. The notes include her famous program for recursively computing Bernoulli numbers — arguably the world's first complete computer program — which used conditional jumps to implement the required nested loops.</p> <h3 id="turing-1945-calls-and-returns">Turing, 1945: Calls and returns</h3> <p>In 1945 Turing proposed his Automatic Computing Engine<sup class="footnote-reference" id="fr-3-1"><a href="#fn-3">2</a></sup>, where he introduced the concept of calls and returns: <em>"To start on a subsidiary operation we need only make a note of where we left off the major operation and then apply the first instruction of the subsidiary. When the subsidiary is over we look up the note and continue with the major operation."</em></p> <p>The ACE supported calls directly with a stack of mercury-filled memory crystals holding return addresses. Turing's design was for a 32-bit RISC machine with vacuum tube integer hardware, floating point microcode, 32 registers, a 1024-entry return stack, and 32K of RAM on a 1 MHz bus. The smaller Pilot ACE was for a while the world's fastest computer.</p> <h4 id="lovelace-turing-an-aside-on-machine-intelligence">Lovelace &amp; Turing: An aside on machine intelligence</h4> <p>In Lady Lovelace's notes we find her prescient recognition of the Analytic Engine's power: "In enabling mechanism to combine together general symbols in successions of unlimited variety and extent, a uniting link is established between the operations of matter and the abstract mental processes of the most abstract branch of mathematical science."<sup class="footnote-reference" id="fr-1-2"><a href="#fn-1">1</a></sup> Here also we find her recognition of its limits: "It can do whatever we know how to order it to perform. It can follow analysis; but it has no power of anticipating any analytical relations or truths. Its province is to assist us in making available what we are already acquainted with."<sup class="footnote-reference" id="fr-1-3"><a href="#fn-1">1</a></sup></p> <p>In 1950 Alan Turing answered "Lady Lovelace's Objection" with a question of his own: "The majority of minds seem to be 'subcritical' ... an idea presented to such a mind will on average give rise to less than one idea in reply. A smallish proportion are supercritical. An idea presented to such a mind that may give rise to a whole 'theory' consisting of secondary, tertiary and more remote ideas... we ask, 'Can a machine be made to be supercritical?'"<sup class="footnote-reference" id="fr-2-1"><a href="#fn-2">3</a></sup></p> <h3 id="industry-practice-1945-2025">Industry practice: 1945 - 2025</h3> <p>Call and return facilities of various levels of complexity have proven their worth across a long line of important machines over the last 80 years: Burroughs' baroque ALGOL support, Intel's simple <code>CALL</code> and <code>RET</code>, RISC-V's subtly dynamic <code>JAL</code> and <code>JALR</code>, ARM's bare mimimum <code>BL</code>, and some such facility on most every other machine we have programmed or implemented: physical machines including the, CDC 7600, IBM 360, PDP-11, VAX, Motorola 68000, and others, as well as virtual machines for Scheme, Forth, Pascal, Java, Wasm, .NET and others.</p> <p>Especially relevant to the EVM's design are the Java, Wasm, and .NET VMs. They share some important features: their programs are all</p> <ul> <li>represented with a portable bytecode that</li> <li>can be directly interpreted and</li> <li>can be validated before runtime</li> <li>to have static control flow that</li> <li>can be compiled to machine code</li> <li>with a one-pass JIT.</li> </ul> <p>We propose that the EVM should share these features.</p> <h3 id="the-evm-control-flow-facility">The EVM control-flow facility</h3> <p>Unlike these machines, the Ethereum Virtual Machine <em>does not</em> provide facilities for calls and returns. Instead, they must be synthesized using the dynamic <code>JUMP</code> instruction, which takes its argument on the stack. Further, the EVM provides <em>only</em> this jump. The EVM's dynamic jump causes problems. First, the need to synthesize static jumps and calls with dynamic jumps wastes some space and gas. The much bigger problem is this: jumps that can dynamically branch to any destination in the program can cause quadratic "path explosions" when traversing the program's flow of control. We will give more detailed explanations in the Rationale.</p> <p>Dynamic jumps are common enough in physical machines, whose instruction sets are of course optimized for physical performance, but less so in virtual machines, whose code is often the source for JIT compilers and other downstream tools — a JIT compiler that can take quadratic time is less than useful. For this reason the Java, Wasm, and .NET VMs do not support dynamic jumps.</p> <h3 id="why-dynamic-jumps-must-die">Why dynamic jumps must die</h3> <p>For Ethereum, quadratic traversal times are a denial-of-service vulnerability for any online static analysis, including validating EVM bytecode and translating its virtual stack code to other representations such as virtual register code and machine code -- whether AOT at initialization time, or JIT at runtime.</p> <p>Even offline, dynamic jumps (and the lack of calls and returns) can cause static analyses of many contracts to become impractical, intractable or even impossible. The following are quotes from the abstracts for just a few recent papers on the problem:</p> <blockquote> <p>"Ethereum smart contracts are distributed programs running on top of the Ethereum blockchain. Since program flaws can cause significant monetary losses and can hardly be fixed due to the immutable nature of the blockchain, there is a strong need of automated analysis tools which provide formal security guarantees. Designing such analyzers, however, proved to be challenging and error-prone."<sup class="footnote-reference" id="fr-4-1"><a href="#fn-4">4</a></sup></p> <p>"The EVM language is a simple stack-based language ... with one significant difference between the EVM and other virtual machine languages (like Java Bytecode or CLI for .Net programs): the use of the stack for saving the jump addresses instead of having it explicit in the code of the jumping instructions. Static analyzers need the complete control-flow graph (CFG) of the EVM program in order to be able to represent all its execution paths."<sup class="footnote-reference" id="fr-5-1"><a href="#fn-5">5</a></sup></p> <p>"Static analysis approaches mostly face the challenge of analyzing compiled Ethereum bytecode... However, due to the intrinsic complexity of Ethereum bytecode (especially in jump resolution), static analysis encounters significant obstacles."<sup class="footnote-reference" id="fr-6-1"><a href="#fn-6">6</a></sup></p> <p>"Analyzing contract binaries is vital ... comprising function entry identification and detecting its boundaries... Unfortunately, it is challenging to identify functions ... due to the lack of internal function call statements."<sup class="footnote-reference" id="fr-7-1"><a href="#fn-7">7</a></sup></p> </blockquote> <p>There is an entire academic literature of complex, incomplete solutions to problems like these that this proposal, others before it, and the design of other VMs render trivial.</p> <p>With so much at stake on the blockchain -- currently valued at over 6000 metric tonnes of gold -- deploying correct contracts is imperative — there is no reason for the EVM to make that job any more difficult than necessary. Especially when it is so easy to fix.</p> <h3 id="taming-the-evm">Taming the EVM</h3> <p>To prevent control-flow traversal from "going quadratic" we must prevent the dynamic use of jumps. On-chain, most uses of <code>JUMP</code> and <code>JUMPI</code> are preceded by a <code>PUSH</code> — that is, they are effectively static. So not quite dead, but provably paralyzed. This proposal <em>requires</em> that in <code>valid</code> code <code>JUMP</code> and <code>JUMPI</code> are <em>always</em> used statically. Currently, the only places that jumps <em>must</em> be used dynamically are to support calls and returns. For that purpose we propose <code>CALLSUB</code> and <code>RETURNSUB</code> opcodes as replacements.</p> <h2 id="specification">Specification</h2> <blockquote> <p><em>The key words MUST and MUST NOT in this Specification are to be interpreted as described in RFC 2119 and RFC 8174.</em></p> </blockquote> <h3 id="callsub-0x"><code>CALLSUB (0x..)</code></h3> <p>Transfers control to a subsidiary operation.</p> <ol> <li>Pop the <code>destination</code> on top on the <code>stack</code>.</li> <li>Push the current <code>PC + 1</code> to the <code>return stack</code>.</li> <li>Set <code>PC</code> to <code>destination</code>.</li> </ol> <p>The gas cost is <em>mid</em> (<code>8</code>).</p> <h3 id="entersub-0x"><code>ENTERSUB (0x..)</code></h3> <p>The <code>destination</code> of every <code>CALLSUB</code> MUST be an <code>ENTERSUB</code>.</p> <h3 id="returnsub-0x"><code>RETURNSUB (0x..)</code></h3> <p>Returns control to the caller of a subsidiary operation.</p> <ol> <li>Pop the <code>return stack</code> to <code>PC</code>.</li> </ol> <p>The gas cost is <em>low</em> (<code>5</code>).</p> <h3 id="magic-0xef"><code>MAGIC (0xEF....)</code></h3> <p>After this EIP has been activated code beginning with the <code>MAGIC</code> bytes MUST be a <code>valid</code> program. Execution begins immediately after the <code>MAGIC</code> bytes.</p> <p><em>Notes:</em></p> <ul> <li><em>Values popped off the <code>return stack</code> do not need to be validated, since they are alterable only by <code>CALLSUB</code> and <code>RETURNSUB</code>.</em></li> <li><em>The description above lays out the semantics of these instructions in terms of a <code>return stack</code>. But the actual state of the <code>return stack</code> is not observable by EVM code or consensus-critical to the protocol. (For example, a node implementer may code <code>CALLSUB</code> to unobservably push <code>PC</code> on the <code>return stack</code> rather than <code>PC + 1</code>, which is allowed so long as <code>RETURNSUB</code> observably returns control to the <code>PC + 1</code> location.)</em></li> <li><em>Opcode and <code>MAGIC</code> values are still to be determined.</em></li> </ul> <h3 id="costs">Costs</h3> <p>A <em>mid</em> cost for <code>CALLSUB</code> is justified by it taking very little more work than the <em>mid</em> cost of <code>JUMP</code> — just pushing an integer to the <code>return stack</code></p> <p>A <em>jumpdest</em> cost for <code>ENTERSUB</code> is justified by it being, like <code>JUMPDEST</code>, a mere label.</p> <p>A <em>low</em> cost for <code>RETURNSUB</code> is justified by needing only to pop the <code>return stack</code> into the <code>PC</code> — less work than a jump.</p> <p>Benchmarking will be needed to tell if the costs are well-balanced.</p> <h3 id="validity">Validity</h3> <p>Execution is defined in the Yellow Paper as a sequence of changes to the EVM state. The conditions on <code>valid</code> code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state and cannot continue. The Yellow Paper defines six such states.</p> <ul> <li>State modification during a static call</li> <li>Insufficient gas</li> <li>More than 1024 stack items</li> <li>Insufficient stack items</li> <li>Invalid jump destination</li> <li>Invalid instruction</li> </ul> <p>We would like to consider EVM code <code>valid</code> iff no execution of the program can lead to an exceptional halting state. In practice, we must test at runtime for the first three conditions. We don't know whether we will be called statically. We don't know how much gas there will be, and we don't know how deep a recursion may go. (However, we can validate that non-recursive programs do not overflow stack.) All of the remaining conditions MUST be validated statically. To allow for efficient algorithms our validation does not consider the codes data and computations, only its control flow and stack use. This means we will reject programs with invalid code paths, even if those paths are not reachable.</p> <h4 id="constraints-on-valid-code">Constraints on <code>valid</code> code</h4> <p>Code beginning with <code>MAGIC</code> MUST be <code>valid</code>. Constraints on <code>valid</code> code MUST be validated at <code>CREATE</code> time, in time and space linear in the size of the code. The constraints on <code>valid</code> code are as follows.</p> <ul> <li>All executable opcodes must be <code>valid</code>: <ul> <li>They MUST have been defined in the Yellow Paper or a deployed EIP and</li> <li>MUST NOT have been deprecated in a subsequent deployed EIP.</li> <li>The <code>INVALID</code> opcode is <code>valid</code>.</li> </ul> </li> <li>The <code>JUMP</code> and <code>JUMPI</code> instructions MUST be preceded by a <code>PUSH</code> instruction.</li> <li>The <code>JUMP</code> and <code>JUMPI</code> instructions MUST NOT address immediate data, and MUST address a <code>JUMPDEST</code>.</li> <li>The <code>CALLSUB</code> instruction MUST be preceded by a <code>PUSH</code> instruction.</li> <li>The <code>CALLSUB</code> instruction MUST NOT address immediate data, and MUST address an <code>ENTERSUB</code>.</li> <li>The number of items on the <code>data stack</code> MUST always be positive and less than or equal to 1024.</li> <li>The number of items on the <code>return stack</code> MUST always be positive and less than or equal to 1024.</li> <li>The <code>stack height</code> is the absolute difference between the current <code>stack pointer</code> and the <code>stack pointer</code> at the most recent <code>ENTERSUB</code>.</li> <li> <ul> <li>During execution the <code>stack height</code> MUST be <em>the same</em> for every <code>PC</code>.</li> </ul> </li> </ul> <p>The guarantee of constant stack height prevents stack underflow, breaks cycles in the control flow, ensures finite stack use for non-recursive programs, enables one-pass recovery of control-flow, and allows virtual stack code to be directly serialized into virtual register code for faster interpretation and compilation to machine code.</p> <p><em>Note: The JVM, Wasm and .NET VMs enforce similar constraints for similar reasons.</em></p> <h4 id="validation">Validation</h4> <p>The above is a purely semantic specification, placing no constraints on the syntax of bytecode beyond being an array of opcodes and immediate data. "Subsidiary operations" here are not contiguous sequences of bytecode: they are subgraphs of the bytecode's full control-flow graph. The EVM is a simple state machine, and the control-flow graph for a program represents every possible change of state. Each instruction simply advances the state machine one more step, and state has no syntactic structure. We only promise that <code>valid</code> code will not, as it were, jam up the gears of the machine.</p> <p>Rather than enforce semantic constraints via syntax — as is done by higher-level languages — this proposal enforces them via validation: <code>MAGIC</code> code is proven <code>valid</code> at <code>CREATE</code> time. The constraints above MUST be proven true in time and space linear in the size of the code. We provide a simple algorithm below for doing so -- there are better ones.</p> <p>With no syntactic constraints and minimal semantic constraints we maximize opportunities for optimizations, including tail call elimination, multiple-entry calls, efficient register allocation, and inter-procedural optimizations. Since we want to support online compilation of EVM code to native code it is crucial that the EVM code be as well optimized as possible by our HLL compilers — upfront and offline.</p> <h2 id="rationale">Rationale</h2> <h3 id="how-can-dynamic-jumps-cause-quadratic-control-flow">How can dynamic jumps cause quadratic control flow?</h3> <p>Static analysis amounts to most anything you can do with a program without actually running it. And traversing the flow of control — in a way that follows every possible path only once — is a fundamental first step for many static analyses, especially for recovering control-flow graphs. When all jumps are static the number of steps is linear in the number of instructions: a fixed number of paths must be explored for each jump. But with dynamic jumps every possible destination must be explored at every jump: at worst, the number of steps can be quadratic in the number of instructions.</p> <p>Consider these three programs. They make for nice exploits, especially as they get longer. It's not important that at runtime <code>gas</code> isn't random or that the <code>jump</code> will most often fail -- what matters is that it is impossible to know at static analysis time where the jumps go, so every destination must be explored.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"></span> <span class="giallo-l"><span> jumpdest jumpdest jumpdest</span></span> <span class="giallo-l"><span> gas gas gas</span></span> <span class="giallo-l"><span> jump jump jump</span></span> <span class="giallo-l"><span> jumpdest jumpdest jumpdest</span></span> <span class="giallo-l"><span> gas gas gas </span></span> <span class="giallo-l"><span> jump jump jump</span></span> <span class="giallo-l"><span> jumpdest jumpdest jumpdest</span></span> <span class="giallo-l"><span> stop gas gas</span></span> <span class="giallo-l"><span> jump jump</span></span> <span class="giallo-l"><span> jumpdest jumpdest</span></span> <span class="giallo-l"><span> stop gas</span></span> <span class="giallo-l"><span> jump</span></span> <span class="giallo-l"><span> jumpdest</span></span> <span class="giallo-l"><span> stop</span></span> <span class="giallo-l"></span></code></pre> <p>And consider the control-flow graphs for these programs. Each block of instructions in a graph is a sequence from the above programs with one entry (a <code>JUMPDEST</code>) and one exit (a <code>JUMP</code>), and each arc is a transfer of control. Arcs on the left are backwards branches, arcs on the right are forwards branches.</p> <p><img src="https://wg-eips.ritovision.com/7979/./assets/control-flow.png" alt="Control-Flow Graphs" /> <em>Graph may be outdated</em></p> <p>Note that the number of arcs in a graph is equal to the number of blocks minus one, squared. That is, the number of possible paths of control flow, and thus the time needed to traverse them all, is quadratic in the size of the program.</p> <h3 id="do-we-save-on-code-size-and-gas">Do we save on code size and gas?</h3> <p>The difference these instructions make can be seen in this very simple code for calling a routine that squares a number. The distinct opcodes make it easier for both people and tools to understand the code, and there are modest savings in code size and gas costs as well.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"></span> <span class="giallo-l"><span>SQUARE: | SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas | entersub ; 1 gas</span></span> <span class="giallo-l"><span> dup ; 3 gas | dup : 5 gas</span></span> <span class="giallo-l"><span> mul ; 5 gas | mul ; 5 gas</span></span> <span class="giallo-l"><span> swap1 ; 3 gas | returnsub ; 5 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas |</span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span>CALL_SQUARE: | CALL_SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas | entersub ; 1 gas</span></span> <span class="giallo-l"><span> push RTN_CALL ; 3 gas | push 2 ; 3 gas</span></span> <span class="giallo-l"><span> push 2 ; 3 gas | push SQUARE ; 3 gas</span></span> <span class="giallo-l"><span> push SQUARE ; 3 gas | callsub ; 8 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas | returnsub ; 5 gas</span></span> <span class="giallo-l"><span>RTN_CALL: |</span></span> <span class="giallo-l"><span> swap1 ; 3 gas |</span></span> <span class="giallo-l"><span> jump ; 8 gas |</span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span>Size in bytes: 18 | Size in bytes: 13</span></span> <span class="giallo-l"><span>Consumed gas: 49 | Consumed gas: 38</span></span> <span class="giallo-l"></span></code></pre> <p>That's 32% fewer bytes and 30% less gas using <code>CALLSUB</code> versus using <code>JUMP</code>. So we can see that these instructions provide a simpler, more efficient mechanism. As code becomes larger and better optimized the gains become smaller, but code using <code>CALLSUB</code> always takes less space and gas than equivalent code without it.</p> <h3 id="do-we-improve-real-time-performance">Do we improve real-time performance?</h3> <p>Some real-time interpreter performance gains will be had, as reflected in the lower gas costs. But large real-time gains will come from AOT and JIT compilers. Crucially, the constraint that stack depths be constant means that in <code>MAGIC</code> code a very fast streaming JIT can traverse the control flow of the EVM code in one pass -- as it is executed -- generating machine code as it goes. <em>(Note again: the Wasm, JVM and .NET VMs share that property.)</em> The EVM is a stack machine, but real machines are register machines. So generating virtual register code for a faster interpreter is a win, (I have seen 4X speedups on JVM code) and generating good machine code gives orders of magnitude gains. But for most transactions storage dominates execution time, and gas counting and other overhead always take their toll. So these gains would be most visible in contexts where this overhead is absent, such as for L1 precompiles, on some L2s, and on some EVM-compatible chains. Code can also be compiled to a better instruction set for on-chain ZK work, such as RISC-V.</p> <h3 id="why-no-immediate-arguments">Why no immediate arguments?</h3> <p>This would of course break the promise of "the smallest possible change." <a href="https://wg-eips.ritovision.com/8013/">EIP-8013: Static relative jumps and calls for the EVM</a> is available if we want its size and performance advantages. It proposes five new EVM jump instructions (<code>RJUMP</code>, <code>RJUMPI</code>, <code>RJUMPV</code>, <code>RJUMPSUB</code>, and <code>RJUMPSUBV</code>) which encode destinations as signed immediate values. These can be useful for almost all <code>JUMP</code> and <code>JUMPI</code> use cases and offer improvements in cost, performance, and static analysis.</p> <h3 id="why-no-code-sections">Why no code sections?</h3> <p>Again, this would break the promise of "the smallest possible change," and <a href="https://wg-eips.ritovision.com/3540/">EIP-3540: EOF - EVM Object Format</a> remains available. But note that restricting jumps to code sections impedes important optimizations, which EOF supported by adding special opcodes. So if we want restricted code sections this becomes a much bigger change, and we should consider <a href="https://wg-eips.ritovision.com/4750/">EOF - Functions</a> and related EIPs separately. This proposal uses the same return-stack mechanism and poses no forwards compatability issues with EOF.</p> <h3 id="why-the-return-stack-mechanism">Why the return-stack mechanism?</h3> <p>In our experience most stack machines have separate stacks for data and for returns from calls, whereas most register machines have one stack for both data and return addresses, registers for computation, and instructions to support returns from calls in coordination with registers and the stack. The EVM is of course a stack machine, not a register machine. As an industry and a team we have substantial experience with the return-stack mechanism proposed here. It has been effectively used in many machines over the last eight decades since Turing invented it, and has been implemented, tested, and even ready to ship in many of our clients over the last nine years.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These changes are backwards compatible.</p> <ul> <li>There are <em>no changes</em> to the semantics of existing EVM code. <ul> <li>With the caveat that code with unspecified behavior might behave in different, unspecified ways. Such code was always broken.</li> </ul> </li> <li>Opcode semantics <em>are not</em> affected by whether the code begins with <code>MAGIC</code>. <ul> <li>What is affected is the <em>validity</em> of code. <code>valid</code> code MUST execute identically in any contracts, but in <code>MAGIC</code> contracts the code MUST be <code>valid</code>.</li> </ul> </li> <li>This proposal <em>does not</em> require maintaining two interpreters.</li> </ul> <p>These changes do not foreclose EOF, RISC-V, or other changes; new <code>MAGIC</code> numbers would mark future EVMs. Neither do these changes preclude running the EVM in zero knowledge; they would more likely help.</p> <h2 id="test-cases">Test Cases</h2> <p><em>(Note: these tests are known to be outdated and incorrect.)</em></p> <h3 id="simple-routine">Simple routine</h3> <p>This should jump into a subroutine, back out and stop.</p> <p>Bytecode: <code>0x60045e005c5d</code> (<code>PUSH1 0x04, CALLSUB, STOP, BEGINSUB, RETURNSUB</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>PUSH1</td><td>3</td><td>[]</td><td>[]</td></tr> <tr><td>2</td><td>CALLSUB</td><td>10</td><td>[4]</td><td>[]</td></tr> <tr><td>5</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[ 2]</td></tr> <tr><td>3</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Output: 0x Consumed gas: <code>18</code></p> <h3 id="two-levels-of-subroutines">Two levels of subroutines</h3> <p>This should execute fine, going into one two depths of subroutines</p> <p>Bytecode: <code>0x6800000000000000000c5e005c60115e5d5c5d</code> (<code>PUSH9 0x00000000000000000c, CALLSUB, STOP, BEGINSUB, PUSH1 0x11, CALLSUB, RETURNSUB, BEGINSUB, RETURNSUB</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>PUSH9</td><td>3</td><td>[]</td><td>[]</td></tr> <tr><td>10</td><td>CALLSUB</td><td>10</td><td>[12]</td><td>[]</td></tr> <tr><td>13</td><td>PUSH1</td><td>3</td><td>[]</td><td>[10]</td></tr> <tr><td>15</td><td>CALLSUB</td><td>10</td><td>[17]</td><td>[10]</td></tr> <tr><td>18</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[10,15]</td></tr> <tr><td>16</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[10]</td></tr> <tr><td>11</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Consumed gas: <code>36</code></p> <h3 id="failure-1-invalid-jump">Failure 1: invalid jump</h3> <p>This should fail, since the given location is outside of the code-range. The code is the same as previous example, except that the pushed location is <code>0x01000000000000000c</code> instead of <code>0x0c</code>.</p> <p>Bytecode: <code>0x6801000000000000000c5e005c60115e5d5c5d</code> (<code>PUSH9 0x01000000000000000c, CALLSUB, STOP, BEGINSUB, PUSH1 0x11, CALLSUB, RETURNSUB, BEGINSUB, RETURNSUB</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>PUSH9</td><td>3</td><td>[]</td><td>[]</td></tr> <tr><td>10</td><td>CALLSUB</td><td>10</td><td>[18446744073709551628]</td><td>[]</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Error: at pc=10, op=CALLSUB: invalid jump destination</span></span></code></pre><h3 id="failure-2-shallow-return-stack">Failure 2: shallow <code>return stack</code></h3> <p>This should fail at first opcode, due to shallow <code>return_stack</code></p> <p>Bytecode: <code>0x5d5858</code> (<code>RETURNSUB, PC, PC</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[]</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Error: at pc=0, op=RETURNSUB: invalid retsub</span></span></code></pre><h3 id="subroutine-at-end-of-code">Subroutine at end of code</h3> <p>In this example. the CALLSUB is on the last byte of code. When the subroutine returns, it should hit the 'virtual stop' <em>after</em> the bytecode, and not exit with error</p> <p>Bytecode: <code>0x6005565c5d5b60035e</code> (<code>PUSH1 0x05, JUMP, BEGINSUB, RETURNSUB, JUMPDEST, PUSH1 0x03, CALLSUB</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>PUSH1</td><td>3</td><td>[]</td><td>[]</td></tr> <tr><td>2</td><td>JUMP</td><td>8</td><td>[5]</td><td>[]</td></tr> <tr><td>5</td><td>JUMPDEST</td><td>1</td><td>[]</td><td>[]</td></tr> <tr><td>6</td><td>PUSH1</td><td>3</td><td>[]</td><td>[]</td></tr> <tr><td>8</td><td>CALLSUB</td><td>10</td><td>[3]</td><td>[]</td></tr> <tr><td>4</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[ 8]</td></tr> <tr><td>9</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Consumed gas: <code>30</code></p> <h2 id="reference-implementation">Reference Implementation</h2> <p><em>(Note: this implementation is known to be incomplete and incorrect.)</em></p> <p>The following is a pseudo-Python implementation of an algorithm for predicating code validity. An equivalent algorithm MUST be run at <code>CREATE</code> time in space and time linear in the size of the code. The following algorithm recursively traces the <em>code</em>, emulating its control flow and stack use and checking for violations of the rules above. It runs in time proportional to the size of the code, and the possible depth of recursion is proportional to the size of the code.</p> <h3 id="validation-function">Validation Function</h3> <p>We assume that instruction validation and destination analysis has been done, and that we have some constant-time helper functions:</p> <ul> <li><code>is_terminator(opcode) returns true iff opcode is a terminator.</code></li> <li><code>previous_data(pc) returns the immediate data for the instruction before pc (usually a PUSH.)</code></li> <li><code>immediate_size(opcode) returns the size of the immediate data for an opcode.</code></li> <li><code>removed_items(opcode) returns the number of items removed from the data_stack by the opcode.</code></li> <li><code>added_items(opcode) returns the number of items added to the data_stack by the opcode.</code></li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> # returns true iff code is valid</span></span> <span class="giallo-l"><span> int []stack_depths</span></span> <span class="giallo-l"><span> int []max_depths</span></span> <span class="giallo-l"><span> def validate_code(code: bytes, pc: int, sp: int, bp: int, max: int) -&gt; int, boolean:</span></span> <span class="giallo-l"><span> while pc &lt; len(code):</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # check stack height and return if we have been here before</span></span> <span class="giallo-l"><span> stack_depth = sp - bp</span></span> <span class="giallo-l"><span> max_depth = max + stack_depth</span></span> <span class="giallo-l"><span> if max_depth &gt; 1024</span></span> <span class="giallo-l"><span> return max_depth, false</span></span> <span class="giallo-l"><span> if stack_depths[pc] {</span></span> <span class="giallo-l"><span> if stack_depth != stack_depths[pc]:</span></span> <span class="giallo-l"><span> return 0, false</span></span> <span class="giallo-l"><span> if opcode == ENTERSUB:</span></span> <span class="giallo-l"><span> return max_depths[pc], true</span></span> <span class="giallo-l"><span> else</span></span> <span class="giallo-l"><span> return max_depth, true</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> stack_depths[pc] = stack_depth</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if is_terminator(opcode):</span></span> <span class="giallo-l"><span> return max_depth, true</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == CALLSUB:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # push return address and set pc to destination</span></span> <span class="giallo-l"><span> jumpdest = previous_data(pc)</span></span> <span class="giallo-l"><span> push(return_stack, pc)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # validate and track maximum height</span></span> <span class="giallo-l"><span> max_depth, valid = validate_code(jumpdest, 0, sp - bp, max)</span></span> <span class="giallo-l"><span> if !valid:</span></span> <span class="giallo-l"><span> return max_depth, false</span></span> <span class="giallo-l"><span> max_depths[jumpdest] = max_depth;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == RETURNSUB:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # pop return address and check for preceding call</span></span> <span class="giallo-l"><span> pc = pop(return_stack)</span></span> <span class="giallo-l"><span> max_depth = max + stack_depth</span></span> <span class="giallo-l"><span> return max_depth, true</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if opcode == JUMP:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # set pc to destination of jump</span></span> <span class="giallo-l"><span> pc = previous_data(pc)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == JUMPI:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> jumpdest = previous_data(pc)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # recurse to validate true side of conditional</span></span> <span class="giallo-l"><span> max_depth, valid = validate_code(jumpdest, sp, bp)</span></span> <span class="giallo-l"><span> if !valid:</span></span> <span class="giallo-l"><span> return max_depth, false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # apply instructions to stack</span></span> <span class="giallo-l"><span> sp -= removed_items(opcode)</span></span> <span class="giallo-l"><span> if sp &lt; 0</span></span> <span class="giallo-l"><span> return so, false</span></span> <span class="giallo-l"><span> sp += added_items(opcode)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # Skip opcode and any immediate data</span></span> <span class="giallo-l"><span> pc += 1 + immediate_size(opcode)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> max_depth = max + stack_depth</span></span> <span class="giallo-l"><span> if (max_depth &gt; 1024)</span></span> <span class="giallo-l"><span> return max_depth, false</span></span> <span class="giallo-l"><span> return max_depth, true</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>These changes introduce new flow control instructions. They do not introduce any new security considerations. This EIP is intended to improve security by validating a higher level of safety for EVM code deployed on the blockchain. The validation algorithm must use time and space linear in the size of the code so as not be a denial of service vulnerability. The algorithm here makes one linear-time, recursive pass of the bytecode, whose depth cannot exceed the number of <code>CALLSUB</code> and <code>JUMPI</code> instructions in the code.</p> <h2 id="copyright">Copyright</h2> <!-- ``` csl-json { "type": "article", "id": 4, "author": [ { "family": "Schneidewind", "given": "Clara" } ], "DOI": "arXiv:2101.05735", "title": "The Good, the Bad and the Ugly: Pitfalls and Best Practices in Automated Sound Static Analysis of Ethereum Smart Contracts., "original-date": { "date-parts": [ [2021, 1, 14] ] }, "URL": "https://arxiv.org/abs/2101.05735" } ``` ``` csl-json { "type": "article", "id": 5, "author": [ { "family": "Albert", "given": "Elvira" } ], "DOI": "arXiv:2004.14437", "title": "Analyzing Smart Contracts: From EVM to a sound Control-Flow Graph., "original-date": { "date-parts": [ [2020, 4, 29] ] }, "URL": "https://arxiv.org/abs/2004.14437" } ``` ``` csl-json { "type": "article", "id": 6, "author": [ { "family": "Contro", "given": "Filippo" } ], "DOI": "arXiv:2103.09113", "title": "EtherSolve: Computing an Accurate Control-Flow Graph from Ethereum Bytecode.", "original-date": { "date-parts": [ [2021, 3, 16] ] }, "URL": "https://arxiv.org/abs/2103.09113" } ``` ``` csl-json { "type": "article", "id": 7, "author": [ { "family": "He", "given": "Jiahao" } ], "DOI": "arXiv:2301.12695", "title": "Neural-FEBI: Accurate Function Identification in Ethereum Virtual Machine Bytecode.", "original-date": { "date-parts": [ [2023, 1, 30] ] }, "URL": "https://arxiv.org/abs/2301.12695" } ``` --> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-1"> <p>Menabre, L.F. Sketch of The Analytical Engine Invented by Charles Babbage. Bibliothque Universelle de Genve, No. 82, October 1842 <a href="#fr-1-1">↩</a> <a href="#fr-1-2">↩2</a> <a href="#fr-1-3">↩3</a></p> </li> <li id="fn-3"> <p>Carpenter, B.E. et al. The other Turing machine. The Computer Journal, Volume 20, Issue 3, January 1977 <a href="#fr-3-1">↩</a></p> </li> <li id="fn-2"> <p>Turing, A.M. Computing Machinery and Intelligence. Mind, Volume LIX, Issue 236, October 1950 <a href="#fr-2-1">↩</a></p> </li> <li id="fn-4"> <p>Schneidewind, Clara et al. The Good, the Bad and the Ugly: Pitfalls and Best Practices in Automated Sound Static Analysis of Ethereum Smart Contracts. DOI: 10.48550/arXiv.2101.05735 <a href="#fr-4-1">↩</a></p> </li> <li id="fn-5"> <p>Albert, Elvira et al. Analyzing Smart Contracts: From EVM to a sound Control-Flow Graph. DOI: 10.48550/arXiv.2004.14437 <a href="#fr-5-1">↩</a></p> </li> <li id="fn-6"> <p>Contro, Fillipo et al. EtherSolve: Computing an Accurate Control-Flow Graph from Ethereum Bytecode. DOI: 10.48550/arXiv.2103.09113 <a href="#fr-6-1">↩</a></p> </li> <li id="fn-7"> <p>He, Jiahao et al. Neural-FEBI: Accurate Function Identification in Ethereum Virtual Machine Bytecode. DOI: 10.48550/arxiv.2301.12695" <a href="#fr-7-1">↩</a></p> </li> </ol> </section> 2025-12-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Marcin Sobczakhttps://github.com/marcindsobczak Kamil Chodołahttps://github.com/kamilchodola Marek Moraczyńskihttps://github.com/MarekM25 https://wg-eips.ritovision.com/8096/

Increases cost of point evaluation precompile

<h2 id="abstract">Abstract</h2> <p>This EIP modifies the gas cost of <code>point evaluation</code> precompile introduced in <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>.</p> <h2 id="motivation">Motivation</h2> <p>Currently the <code>point evaluation</code> precompile is underpriced relative to its resource consumption. This EIP aims to address these discrepancies by adjusting the gas cost and making <code>point evaluation</code> precompile sufficiently efficient to enable potential further increases in the block gas limit.</p> <h2 id="specification">Specification</h2> <p>Upon activation of this EIP, the gas cost of calling the precompile at address <code>0x000000000000000000000000000000000000000A</code> will be doubled from <code>50_000</code> gas to <code>100_000</code> gas.</p> <h2 id="rationale">Rationale</h2> <p>Benchmarking the <code>point evaluation</code> precompile revealed that its gas cost is significantly underestimated. This modification aim to ensure that the <code>point evaluation</code> precompile's performance no longer impedes potential increases to the block gas limit.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a backwards-incompatible change. However, similar gas repricings have occurred multiple times in the Ethereum ecosystem, and their effects are well understood.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP does not introduce any new functionality or make existing operations cheaper, therefore there are no direct security concerns related to new attack vectors or reduced cost.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-11-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Luca Donnohttps://github.com/lucadonnohdonnoh@l2beat.com Justin Drakehttps://github.com/JustinDrakejustin@ethereum.org https://wg-eips.ritovision.com/8079/

Expose Ethereum's STF as a precompile for rollups to use

<h2 id="abstract">Abstract</h2> <p>Expose the state transition function to the execution layer via a new <code>EXECUTE</code> precompile.</p> <h2 id="motivation">Motivation</h2> <p>Today, EVM-equivalent rollups need to implement and maintain complex proof systems just to be able to replicate what Ethereum already provides on L1. Such complexity significantly increases the probability of encountering bugs and prevents projects from getting rid of security councils and from moving to Stage 2. EVM-equivalent projects are not similar enough and lack the proper incentives to benefit from each other efforts, significantly delaying multi-proof systems.</p> <p>Moreover, to maintain feature parity with Ethereum, rollups need to implement bespoke governance systems that can't be forced to follow Ethereum's governance decisions, and thus are free to arbitrarily diverge from it. Because of this, the best that an EVM-equivalent rollup can do is to provide long exit windows for their users, to protect them from its governance going rogue. No finite (and reasonable) exit window can protect all use-cases, especially those that rely on timelocks (governance, staking contracts, vesting contracts). Longer exit windows protect more use-cases, at the cost of increase un-equivalence time.</p> <p>This EIP provides a way for rollups to reuse Ethereum's state transition verification infrastructure, and as a consequence massively simplify their infrastructure and upgrade processes. This enables projects to better redirect resources towards user-facing features and products.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <!-- TODO --> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>PROOF_TX_TYPE</code></td><td><code>Bytes1(TBD)</code></td></tr> <tr><td><code>EXECUTE_PRECOMPILE_ADDRESS</code></td><td><code>TBD</code></td></tr> <tr><td><code>ANCHOR_ADDRESS</code></td><td><code>TBD</code></td></tr> </tbody></table> <h3 id="execute-precompile"><code>EXECUTE</code> precompile</h3> <p>Add a precompile at <code>EXECUTE_PRECOMPILE_ADDRESS</code> that verifies a state transition function with the provided inputs.</p> <p>The precompile executes the following logic:</p> <!-- TODO --> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> execute</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verify a `state_transition(chain: BlockChain, block: Block)`.</span></span> <span class="giallo-l"><span class="z-string"> Disable blob transactions and perform anchoring to enable L1-&gt;L2 messaging.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> chain</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">...</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> TBD</span></span> <span class="giallo-l"><span> block</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">...</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> TBD</span></span> <span class="giallo-l"><span> anchor</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">...</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> TBD</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> transactions</span><span class="z-keyword"> =</span><span> get_transactions</span><span>(</span><span>block</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Blob-carrying transactions are not supported</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> map</span><span>(</span><span>decode_transaction</span><span>,</span><span> transactions</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> isinstance</span><span>(</span><span>tx</span><span>,</span><span> BlobTransaction</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> ExecuteError</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> block_env</span><span class="z-keyword"> =</span><span> get_block_env</span><span>(</span><span>chain</span><span>,</span><span> block</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Perform anchoring</span></span> <span class="giallo-l"><span> process_unchecked_system_transaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> block_env</span><span class="z-keyword"> =</span><span>block_env</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> target_address</span><span class="z-keyword">=</span><span class="z-constant">ANCHOR_ADDRESS</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> data</span><span class="z-keyword"> =</span><span>anchor</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> state_transition</span><span>(</span><span>chain</span><span>,</span><span> block</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Bytes</span><span>(</span><span class="z-constant">...</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> TBD</span></span></code></pre><h3 id="header-extension">Header extension</h3> <p>The current header encoding is extended with a new 64-bit unsigned integer field representing the total amount of native tokens burned in the current block as part of the base fee.</p> <p>The resulting RLP encoding of the header is therefore:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>execution_payload_header_rlp = RLP([</span></span> <span class="giallo-l"><span> parent_hash,</span></span> <span class="giallo-l"><span> 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash</span></span> <span class="giallo-l"><span> coinbase,</span></span> <span class="giallo-l"><span> state_root,</span></span> <span class="giallo-l"><span> txs_root,</span></span> <span class="giallo-l"><span> receipts_root,</span></span> <span class="giallo-l"><span> logs_bloom,</span></span> <span class="giallo-l"><span> 0, # difficulty</span></span> <span class="giallo-l"><span> number,</span></span> <span class="giallo-l"><span> gas_limit,</span></span> <span class="giallo-l"><span> gas_used,</span></span> <span class="giallo-l"><span> timestamp,</span></span> <span class="giallo-l"><span> extradata,</span></span> <span class="giallo-l"><span> prev_randao,</span></span> <span class="giallo-l"><span> 0x0000000000000000, # nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas,</span></span> <span class="giallo-l"><span> withdrawals_root,</span></span> <span class="giallo-l"><span> burned_fees</span></span> <span class="giallo-l"><span>])</span></span></code></pre> <p>The cumulative value of <code>burned_fees</code> can be calculated as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>burned_fees</span><span class="z-keyword"> =</span><span> effective_gas_fee</span><span class="z-keyword"> -</span><span> gas_refund_amount</span><span class="z-keyword"> -</span><span> transaction_fee</span><span class="z-keyword"> +</span><span> blob_gas_fee</span></span></code></pre> <p>By making the value available for L1, it is also automatically made available for native rollups too.</p> <h3 id="proof-carrying-transactions">Proof-carrying transactions</h3> <!-- TODO --> <p>TBD: heavily depends on the ZK L1 design.</p> <h2 id="rationale">Rationale</h2> <h3 id="programmable-consensus-layer">Programmable "consensus layer"</h3> <p>The <code>EXECUTE</code> precompile allows rollups to define their own inputs and constrained their behaviour through smart contract. For example, in contrast to Ethereum's own consensus layer, a rollup can decide to:</p> <ul> <li>Restrict the use of transactions that are sequenced by a permissioned entity, allowing for centralized sequencing and fast pre-confirmations, or leaving it open to everyone (based sequencing), or restrict it to a staked sequencer network;</li> <li>Fix the <code>coinbase</code> address to be a DAO-controlled treasury, independent from the proposer address;</li> <li>Tweak gas limits or prices based on specific needs;</li> </ul> <p>This allows projects to preserve most of their configurations they already benefits from.</p> <h3 id="gas-tokens">Gas tokens</h3> <p>Several rollups implement new transaction types to be able to mint the rollup gas token when depositing funds on L1. We decide not to introduce complexity and instead rely on general L1-&gt;L2 messaging to unlock pre-minted tokens, as other existing projects already do. As a consequence, projects are free to decide what type of L1 interaction triggers the release of the rollup gas token, trivially enabling custom gas tokens without the need to modify the EVM behaviour at all.</p> <h3 id="anchoring">Anchoring</h3> <p>To support L1-&gt;L2 messages, rollups need to be able to "anchor" information from L1 to the L2. Inspired by <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> and existing implementations, we make use of a system transaction to inject a <code>bytes32 anchor</code> in the rollup state in a predeploy. This <code>anchor</code> can be used to relay L1's state root, a message root, or a rolling hash, or something completely different, based on design preferences.</p> <p>The trade-off of this approach, compared to some existing ones based on custom transaction types, is that the L2 side of an L1-&gt;L2 message cannot have the <code>msg.sender</code> derived from the sender on L1, and therefore L1 access control-based smart contracts need to be adapted when deployed on L2 and used with cross-chain permissions. We believe this trade-off to be acceptable as the same scenario already exists when supporting L2-&gt;L1 access controls, as Ethereum is already not natively aware of the L2 sender.</p> <h3 id="basefee-collection">Basefee collection</h3> <p>While Ethereum burns the base fee, most rollups collect it for themselves, which enables opinionated funding models that are not possible on L1. To enable this use-case, and to minimize the code changes, we simply expose the amount of fees burned through the <code>burned_fees</code> block header value. Projects can now decide to ignore the value, burning the L2 base fee too, or credit the amount to some address, allowing for base fee collection from the L1-&gt;L2 token escrow.</p> <h3 id="re-execution-vs-zk-proofs">Re-execution vs ZK proofs</h3> <!-- TODO --> <p>TBD</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Existing rollups can more or less easily migrate to being native based on their degree of equivalency, as native rollups do not support custom opcodes, custom precompiles or custom transaction types within the exposed state transition function.</p> <h2 id="test-cases">Test Cases</h2> <!-- TODO --> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <!-- TODO --> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <!-- TODO --> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-11-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francesco D'Amatohttps://github.com/fradamt https://wg-eips.ritovision.com/8080/

Allows exits to use consolidation queue, democratizing access to an unintended feature, improving liquidity while preserving security.

<h2 id="abstract">Abstract</h2> <p>This EIP allows exits to be routed through the consolidation queue when it is shorter than the exit queue, consuming churn that is allocated to consolidations. This democratizes access to a feature that is currently only available to validators with at least 2048 ETH through a loophole in the consolidation logic. The protocol then makes more efficient usage of the churn that its security parameters (weak subjectivity period) allow, and is able to process more exits without any security reduction.</p> <h2 id="motivation">Motivation</h2> <p>The existing design of consolidation mechanism allows validators with at least 2048 ETH to use the consolidation queue for exits through a loophole in the consolidation logic. When there is an imbalance between exit and consolidation queues favoring the latter, as has been the case since the introduction of the consolidation feature, this becomes an appealing way to speed up withdrawals. However, this feature is only available to a subset of validators, creating an unfair advantage.</p> <p>Rather than removing this unintended feature, this EIP democratizes it by making it available to all exits. This approach preserves fairness by ensuring equal access to this efficiency improvement, while also providing concrete benefits to the network. When consolidation activity is low, the consolidation churn would otherwise go unused. By allowing exits to use this churn, we ensure it is not wasted and can be put to productive use. This is particularly important given the current state of exit queue congestion, as the exit queue has been longer than forty days for an extended period of time. Long queues degrade user experience, slow operator response to market or operational events, and reduce the network's ability to reconfigure stake more quickly after adverse events. Besides, solo stakers are arguably the participants that suffer the most from a lack of liquidity today, as they do not have the ability to issue a liquid staking token or maintain liquidity reserves.</p> <p>By allowing exits to use consolidation churn when available, the maximum exit throughput increases significantly, without any security reduction since we are only reallocating churn that the protocol has already accounted for. In particular, the maximum exit churn that can be processed becomes <code>get_activation_exit_churn_limit(state) + 3 * get_consolidation_churn_limit(state) // 2</code>, where the <code>3 // 2</code> factor comes from the fact that one unit of exit churn corresponds to 2/3 of a unit of consolidation churn. With current parameters and with the current total stake approximately 35.7M ETH, this results in 256 (the capped exit churn) + (544 - 256) * 3/2 (the consolidation churn adjusted by the 3/2 factor) = 688 ETH per epoch, representing approximately a 2.5x increase over the current maximum exit churn of 256 ETH per epoch.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <p>Starting from the beginning of the epoch when this EIP is activated, Consensus Layer clients <strong>MUST</strong> use the modified <code>compute_exit_epoch_and_update_churn</code> function which routes exits through the consolidation queue when it is shorter than the exit queue.</p> <h3 id="modified-compute-exit-epoch-and-update-churn">Modified <code>compute_exit_epoch_and_update_churn</code></h3> <p>The only modification is this addition at the start of <code>compute_exit_epoch_and_update_churn</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> &gt;</span><span> state</span><span>.</span><span>earliest_consolidation_epoch</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> compute_consolidation_epoch_and_update_churn</span><span>(</span><span>state</span><span>,</span><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span> exit_balance</span><span class="z-keyword"> //</span><span class="z-constant"> 3</span><span>)</span></span></code></pre> <p>In particular, we route exits through the consolidation queue whenever <code>state.earliest_exit_epoch &gt; state.earliest_consolidation_epoch</code>, by using <code>compute_consolidation_epoch_and_update_churn</code>. Note that the <code>exit_balance</code> passed to the latter is only <code>2 * exit_balance // 3</code>, because each unit of exit churn corresponds to 2/3 units of consolidation churn from a weak subjectivity perspective. This way, we keep the weak subjectivity impact of the consolidation queue the same regardless of whether it is used by consolidations or by exits, maximizing the amount of operations we can process while keeping the same security guarantees.</p> <p>The full function is as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_exit_epoch_and_update_churn</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> exit_balance</span><span>:</span><span> Gwei</span><span>)</span><span> -&gt;</span><span> Epoch</span><span>:</span></span> <span class="giallo-l"><span> activation_exit_epoch</span><span class="z-keyword"> =</span><span> compute_activation_exit_epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>state</span><span>.</span><span>earliest_exit_epoch</span><span>,</span><span> activation_exit_epoch</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> NEW in this EIP</span></span> <span class="giallo-l"><span> earliest_consolidation_epoch</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>state</span><span>.</span><span>earliest_consolidation_epoch</span><span>,</span><span> activation_exit_epoch</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> earliest_exit_epoch</span><span class="z-keyword"> &gt;</span><span> earliest_consolidation_epoch</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> compute_consolidation_epoch_and_update_churn</span><span>(</span><span>state</span><span>,</span><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span> exit_balance</span><span class="z-keyword"> //</span><span class="z-constant"> 3</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> UNCHANGED FROM HERE</span></span> <span class="giallo-l"><span> per_epoch_churn</span><span class="z-keyword"> =</span><span> get_exit_churn_limit</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New epoch for exits.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> &lt;</span><span> earliest_exit_epoch</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> per_epoch_churn</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>exit_balance_to_consume</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Exit doesn&#39;t fit in the current earliest epoch.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> exit_balance</span><span class="z-keyword"> &gt;</span><span> exit_balance_to_consume</span><span>:</span></span> <span class="giallo-l"><span> balance_to_process</span><span class="z-keyword"> =</span><span> exit_balance</span><span class="z-keyword"> -</span><span> exit_balance_to_consume</span></span> <span class="giallo-l"><span> additional_epochs</span><span class="z-keyword"> =</span><span> (</span><span>balance_to_process</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> //</span><span> per_epoch_churn</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> +=</span><span> additional_epochs</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> +=</span><span> additional_epochs</span><span class="z-keyword"> *</span><span> per_epoch_churn</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Consume the balance and update state variables.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_balance_to_consume</span><span class="z-keyword"> =</span><span> exit_balance_to_consume</span><span class="z-keyword"> -</span><span> exit_balance</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> =</span><span> earliest_exit_epoch</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>earliest_exit_epoch</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The decision to democratize access to this unintended feature, rather than removing it or keeping it as is, is driven by:</p> <ol> <li><strong>Fairness</strong>: All validators gain equal access to this efficiency improvement, rather than it being restricted to those with at least 2048 ETH who can exploit the loophole.</li> <li><strong>Efficiency</strong>: When consolidation activity is low, the consolidation churn would otherwise go unused. By allowing exits to use this churn, we ensure it is not wasted and can be put to productive use, improving staking liquidity with unchanged security guarantees.</li> </ol> <p>To summarize, fairness is a strong motivation to either remove the feature or democratize it, and democratizing it is preferable to removing because we get a lot of efficiency benefits from it without any security cost.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.</p> <h2 id="test-cases">Test Cases</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="weak-subjectivity-period">Weak subjectivity period</h3> <p>This EIP does not impact the weak subjectivity period at all. The total churn remains the same, it is just allocated differently. In particular, the conversion factor (<code>exit_balance * 2 // 3</code>) preserves the same weak subjectivity impact regardless of whether consolidation churn is allocated to exits or to consolidations.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin Francesco D'Amatohttps://github.com/fradamt https://wg-eips.ritovision.com/8071/

Cancels consolidation if the max effective balance of the target validator will be exceeded, preventing the withdrawal of the unused balance

<h2 id="abstract">Abstract</h2> <p>Cancels a consolidation request if the effective balance of the target validator would exceed the max effective balance after processing it, which would result in the excess balance being withdrawn. This is an unintended way to speed up withdrawals when the consolidation queue is faster than the exit queue.</p> <h2 id="motivation">Motivation</h2> <p>The existing design of consolidation mechanism leaves an opportunity to use consolidation queue for exits which becomes appealing to be abused when there is an imbalance between exit and consolidation queues favoring the latter.</p> <p>At the date of writing this EIP, the consolidation flaw is being heavily exploited. There are public write ups on how to speed up withdrawals by using this vulnerability.</p> <p>Even though this is a UX rather than security issue, consolidation queue was never meant to be used for withdrawals, which makes the fix introduced by this EIP an important modification.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <p>Starting from the beginning of the epoch when this EIP is activated, Consensus Layer client <strong>MUST</strong> use the modified <code>process_consolidation_request</code> function which code is outlined below.</p> <h3 id="new-get-pending-balance-to-consolidate">New <code>get_pending_balance_to_consolidate</code></h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_pending_balance_to_consolidate</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> target_index</span><span>:</span><span> ValidatorIndex</span><span>)</span><span> -&gt;</span><span> Gwei</span><span>:</span></span> <span class="giallo-l"><span> pending_balance_to_consolidate</span><span class="z-keyword"> =</span><span> Gwei</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> pending_consolidation</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>pending_consolidations</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> pending_consolidation</span><span>.</span><span>target_index</span><span class="z-keyword"> ==</span><span> target_index</span><span>:</span></span> <span class="giallo-l"><span> source_validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>pending_consolidation</span><span>.</span><span>source_index</span><span>]</span></span> <span class="giallo-l"><span> pending_balance_to_consolidate</span><span class="z-keyword"> +=</span><span> source_validator</span><span>.</span><span>effective_balance</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> pending_balance_to_consolidate</span></span></code></pre><h3 id="modified-process-consolidation-request">Modified <code>process_consolidation_request</code></h3> <p><em>Note</em>: This function is extended with the check of the target's balance after consolidation and cancels consolidation request if the balance exceeds the max effective balance.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_consolidation_request</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> consolidation_request</span><span>:</span><span> ConsolidationRequest</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_valid_switch_to_compounding_request</span><span>(</span><span>state</span><span>,</span><span> consolidation_request</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> validator_pubkeys</span><span class="z-keyword"> =</span><span> [</span><span>v</span><span>.</span><span>pubkey</span><span class="z-keyword"> for</span><span> v</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>validators</span><span>]</span></span> <span class="giallo-l"><span> request_source_pubkey</span><span class="z-keyword"> =</span><span> consolidation_request</span><span>.</span><span>source_pubkey</span></span> <span class="giallo-l"><span> source_index</span><span class="z-keyword"> =</span><span> ValidatorIndex</span><span>(</span><span>validator_pubkeys</span><span>.</span><span>index</span><span>(</span><span>request_source_pubkey</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> switch_to_compounding_validator</span><span>(</span><span>state</span><span>,</span><span> source_index</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that source != target, so a consolidation cannot be used as an exit</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> consolidation_request</span><span>.</span><span>source_pubkey</span><span class="z-keyword"> ==</span><span> consolidation_request</span><span>.</span><span>target_pubkey</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the pending consolidations queue is full, consolidation requests are ignored</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>state</span><span>.</span><span>pending_consolidations</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> PENDING_CONSOLIDATIONS_LIMIT</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If there is too little available consolidation churn limit, consolidation requests are ignored</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> get_consolidation_churn_limit</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> MIN_ACTIVATION_BALANCE</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> validator_pubkeys</span><span class="z-keyword"> =</span><span> [</span><span>v</span><span>.</span><span>pubkey</span><span class="z-keyword"> for</span><span> v</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>validators</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify pubkeys exist</span></span> <span class="giallo-l"><span> request_source_pubkey</span><span class="z-keyword"> =</span><span> consolidation_request</span><span>.</span><span>source_pubkey</span></span> <span class="giallo-l"><span> request_target_pubkey</span><span class="z-keyword"> =</span><span> consolidation_request</span><span>.</span><span>target_pubkey</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> request_source_pubkey</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> validator_pubkeys</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> request_target_pubkey</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> validator_pubkeys</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span> source_index</span><span class="z-keyword"> =</span><span> ValidatorIndex</span><span>(</span><span>validator_pubkeys</span><span>.</span><span>index</span><span>(</span><span>request_source_pubkey</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> target_index</span><span class="z-keyword"> =</span><span> ValidatorIndex</span><span>(</span><span>validator_pubkeys</span><span>.</span><span>index</span><span>(</span><span>request_target_pubkey</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> source_validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>source_index</span><span>]</span></span> <span class="giallo-l"><span> target_validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>target_index</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify source withdrawal credentials</span></span> <span class="giallo-l"><span> has_correct_credential</span><span class="z-keyword"> =</span><span> has_execution_withdrawal_credential</span><span>(</span><span>source_validator</span><span>)</span></span> <span class="giallo-l"><span> is_correct_source_address</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> source_validator</span><span>.</span><span>withdrawal_credentials</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span class="z-keyword"> ==</span><span> consolidation_request</span><span>.</span><span>source_address</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> (</span><span>has_correct_credential</span><span class="z-keyword"> and</span><span> is_correct_source_address</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that target has compounding withdrawal credentials</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> has_compounding_withdrawal_credential</span><span>(</span><span>target_validator</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify the source and the target are active</span></span> <span class="giallo-l"><span> current_epoch</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_active_validator</span><span>(</span><span>source_validator</span><span>,</span><span> current_epoch</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_active_validator</span><span>(</span><span>target_validator</span><span>,</span><span> current_epoch</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify exits for source and target have not been initiated</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> source_validator</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> !=</span><span class="z-constant"> FAR_FUTURE_EPOCH</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> target_validator</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> !=</span><span class="z-constant"> FAR_FUTURE_EPOCH</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify the source has been active long enough</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> current_epoch</span><span class="z-keyword"> &lt;</span><span> source_validator</span><span>.</span><span>activation_epoch</span><span class="z-keyword"> +</span><span class="z-constant"> SHARD_COMMITTEE_PERIOD</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify the source has no pending withdrawals in the queue</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> get_pending_balance_to_withdraw</span><span>(</span><span>state</span><span>,</span><span> source_index</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in EIPXXXX]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that the consolidating balance will</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> end up as active balance, not as excess balance</span></span> <span class="giallo-l"><span> target_balance_after_consolidation</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> get_pending_balance_to_consolidate</span><span>(</span><span>state</span><span>,</span><span> target_index</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> source_validator</span><span>.</span><span>effective_balance</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> state</span><span>.</span><span>balances</span><span>[</span><span>target_index</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> target_balance_after_consolidation</span><span class="z-keyword"> &gt;</span><span> get_max_effective_balance</span><span>(</span><span>target_validator</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initiate source validator exit and append pending consolidation</span></span> <span class="giallo-l"><span> source_validator</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> =</span><span> compute_consolidation_epoch_and_update_churn</span><span>(</span></span> <span class="giallo-l"><span> state</span><span>,</span><span> source_validator</span><span>.</span><span>effective_balance</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> source_validator</span><span>.</span><span>withdrawable_epoch</span><span class="z-keyword"> =</span><span> Epoch</span><span>(</span></span> <span class="giallo-l"><span> source_validator</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> +</span><span class="z-constant"> MIN_VALIDATOR_WITHDRAWABILITY_DELAY</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>pending_consolidations</span><span>.</span><span>append</span><span>(</span></span> <span class="giallo-l"><span> PendingConsolidation</span><span>(</span><span class="z-variable">source_index</span><span class="z-keyword">=</span><span>source_index</span><span>,</span><span class="z-variable"> target_index</span><span class="z-keyword">=</span><span>target_index</span><span>)</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="iterating-over-pending-consolidations">Iterating over pending consolidations</h3> <p>The new design introduces an iteration over pending consolidations which increases complexity of consolidation processing.</p> <p>This is done to handle the case when there are multiple consolidations with the same target and each of them doesn't exceed the max effective balance while all of them together do.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>test_single_consolidation_request_at_max_eb</li> <li>test_no_pending_consolidations_exceeding_max_eb</li> <li>test_single_pending_consolidation_exceeding_max_eb</li> <li>test_multiple_pending_consolidations_at_max_eb</li> <li>test_multiple_pending_consolidations_exceeding_max_eb</li> <li>test_exceeding_max_eb_with_the_target_balance_but_not_eb</li> <li>test_exceeding_max_eb_with_the_source_eb_but_not_the_balance</li> <li>test_multiple_pending_consolidations_exceeding_max_eb_with_the_source_eb_but_not_the_balance</li> </ul> <p>All of the above test cases are implemented <a href="https://wg-eips.ritovision.com/8071/./assets/test_process_consolidation_request.py">here</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>When consolidation request results in max effective balance exceeded, it is cancelled on the Consensus Layer, neither request fee nor transaction gas cost are refunded in this case.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson Toni Wahrstätterhttps://github.com/nerolation Francesco D'Amatohttps://github.com/fradamt Ben Adamshttps://github.com/benaadams Maria Inês Silvahttps://github.com/misilva73 https://wg-eips.ritovision.com/8062/

Improve stake consolidation and fairness by imposing a "sweep" withdrawal fee for `0x01` validators set to 0.05% of the withdrawn amount.

<h2 id="abstract">Abstract</h2> <p>A fee is proposed on the partial "sweep" withdrawal of validators using <code>0x01</code> credentials, to improve stake consolidation and fairness. Ethereum's fast finality roadmap hinges on staking service providers migrating from <code>0x01</code> validators to <code>0x02</code> compounding validators. One roadblock is that <code>0x01</code> validators receive free-of-charge partial skimming withdrawals for balances exceeding 32 ETH, which consume protocol resources that are not accounted for. To address this, a 0.05% fee is imposed on the partial <code>0x01</code> sweep using a minimal modification to <code>process_withdrawals()</code>, applying the new constant <code>WITHDRAWAL_FEE_FRACTION = 2000</code>.</p> <h2 id="motivation">Motivation</h2> <p>The roadmap for fast finality hinges on stake consolidation, where staking service providers (SSPs) transition from running 32-ETH validators with <code>0x01</code> credentials to compounding validators with <code>0x02</code> credentials. A roadblock to this transition is that <code>0x01</code> validators have been designed with close-to-ideal capital efficiency and free-of-charge partial withdrawals for balances exceeding 32 ETH (the "sweep" function). When factoring in switching costs, the incentives do not favor stake consolidation. At the same time, sweep withdrawals take up resources on both the consensus layer (CL) and execution layer (EL) that are not paid for. It is unsuitable to give <code>0x01</code> validators an accounting advantage over <code>0x02</code> validators when Ethereum's roadmap hinges on stakers consolidating their stake in <code>0x02</code> validators.</p> <p>To improve consolidation while upholding fairness, this EIP accounts for the resource load of the <code>0x01</code> partial withdrawal sweep by imposing a small withdrawal fee for it. The proposed fee is 0.05% of the withdrawn amount, imposed via <code>WITHDRAWAL_FEE_FRACTION = 2000</code>. Since the average sweep withdrawal credits around 0.0235 ETH, the average expected fee per withdrawal is $0.0235;\mathrm{ETH} \times 0.0005 = 11,750;\mathrm{Gwei}$. The total expected fee over one year for a validator is 0.00048 ETH, corresponding to around $2 at the current ETH price. An SSP running 50,000 <code>0x01</code> validators (slightly below 5% of the stake) would thus need to pay around $100,000 per year in withdrawal fees.</p> <p>The fee approximates the EL workload imposed by the sweep, calibrated against the average base fee over the last year (4.53 gwei). The withdrawal incurs equivalent to around 2204 gas (not accounting for CL work), implying a fee of $2204 \times 4.53 = 9,984;\mathrm{Gwei}$ (albeit, the base fee has been lower in recent months).</p> <p>The fee is taken out on the CL as a percentage, since a fixed fee could produce extreme outcomes if the number of <code>0x01</code> validators were to be drastically reduced due to consolidation. In such a scenario, the sweep will hit validators more frequently, and the fee will thus be taken out more frequently. Since validators then would also withdraw a lower balance each time, a percentage fee on the withdrawal keeps the burden on stakers fixed. The existing logic is kept intact to minimize complexity. As a result, a validator's balance will dip just below 32 ETH after skimming (as also happens when receiving a penalty just after skimming).</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>WITHDRAWAL_FEE_FRACTION</code></td><td><code>2000</code></td></tr> </tbody></table> <h3 id="functions">Functions</h3> <p>In <code>process_withdrawals()</code>, take out a fee for skimmed <code>0x01</code> validators that did not perform a full exit, burning it on the CL:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_withdrawals</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> payload</span><span>:</span><span> ExecutionPayload</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> In this existing for-loop, calculate a fee before decreasing the balance</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> w</span><span class="z-keyword"> in</span><span> expected_withdrawals</span><span>:</span></span> <span class="giallo-l"><span> vi</span><span class="z-keyword"> =</span><span> w</span><span>.</span><span>validator_index</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> has_compounding_withdrawal_credential</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>[</span><span>vi</span><span>]</span><span>)</span><span class="z-keyword"> and</span><span> w</span><span>.</span><span>amount</span><span class="z-keyword"> !=</span><span> state</span><span>.</span><span>balances</span><span>[</span><span>vi</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span> w</span><span>.</span><span>amount</span><span class="z-keyword"> //</span><span class="z-constant"> WITHDRAWAL_FEE_FRACTION</span></span> <span class="giallo-l"><span> decrease_balance</span><span>(</span><span>state</span><span>,</span><span> vi</span><span>,</span><span> w</span><span>.</span><span>amount</span><span class="z-keyword"> +</span><span> fee</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="fast-finality">Fast finality</h3> <p>Fast finality is best realized through a reduction to the active validator set voting each round. Two paths have been envisioned. In one path referred to as Orbit SSF, the active set rotates in a weighted fashion, such that large consolidated validators always are active, and smaller validators are active less frequently. In another path, there is a fixed number of validator seats, with only the largest validators (e.g., the top 8,192) granted a seat. Both paths require consolidation to achieve a desirable stake weight and optimal performance.</p> <h3 id="level-of-the-proposed-fee">Level of the proposed fee</h3> <p>The cost per validator per year under 3% CL yield becomes $32 \times 0.03 / 2000 = 0.00048$ ETH, corresponding to around $2 at a price of $4,167 per ETH. Table 1 summarizes outcomes under different numbers of validators. A solo staker running one <code>0x01</code> is unlikely to consider the $2 fee enough to tip the scale either way. A staking service provider (SSP) running 50,000 <code>0x01</code> validators (slightly below 5% of the stake) has at least a moderate incentive since the cost then is $100,000. Under perfect competition, the SSP will not be able to pass on this cost to their customers. The outcome under a higher fee is outlined in the Alternative specifications section.</p> <table><thead><tr><th>Validators (stake %)</th><th style="text-align: right">Cost (ETH/year)</th><th style="text-align: right">Cost (USD/year)</th></tr></thead><tbody> <tr><td>1 (~0.0001%)</td><td style="text-align: right">0.00048</td><td style="text-align: right">$2</td></tr> <tr><td>100 (~0.01%)</td><td style="text-align: right">0.048</td><td style="text-align: right">$200</td></tr> <tr><td>10,000 (~1%)</td><td style="text-align: right">4.8</td><td style="text-align: right">$20,000</td></tr> <tr><td>50,000 (~5%)</td><td style="text-align: right">24</td><td style="text-align: right">$100,000</td></tr> <tr><td>100,000 (~10%)</td><td style="text-align: right">48</td><td style="text-align: right">$200,000</td></tr> </tbody></table> <p><strong>Table 1.</strong> Cost to stakers under the proposed withdrawal fee.</p> <p>The switching cost may still be greater than the yearly fee for an SSP. Some smart contracts requiring <code>0x01</code> credentials may be frozen and others may require a full exit and entry, with associated opportunity costs. However, once the recurring fee is in place and there is a commitment from the protocol to phase out <code>0x01</code> validators for SSPs—potentially even raising the fee until such an outcome has been realized—then the switch will have to be done <em>eventually</em>. Ignoring other potential benefits of <code>0x01</code> validators, a more accurate comparison is thus between the recurring fee and the capital cost for financing the switch, which of course is lower.</p> <h3 id="gas-accounting">Gas accounting</h3> <p>The gas cost accounting is as follows:</p> <ul> <li>500 gas – cold touch of an account known to have no code (as specified in <a href="https://wg-eips.ritovision.com/2780/">EIP-2780</a>),</li> <li>1000 gas – one account-leaf write in the account trie (as specified in <a href="https://wg-eips.ritovision.com/2780/">EIP-2780</a>),</li> <li>704 gas – an <a href="https://wg-eips.ritovision.com/4895/">EIP-4895</a> withdrawal {index: uint64, validator_index: uint64, address: bytes20, amount: uint64}, consisting of $8 + 8 + 20 + 8 = 44$ bytes, priced analogously to calldata at 16 gas/byte.</li> </ul> <p>It can be noted that we are not with this accounting charging for the CL work that <code>0x01</code> validators impose due to the sweep. We are neither charging <code>0x02</code> validators for the CL work of EL-triggered partial withdrawals via <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a>, but they are charged more extensively on the EL for triggering the withdrawal. Further note that <code>2048</code>-ETH validators are exempted in the specification from the sweep withdrawal fee, to avoid harming consolidation, and as an acknowledgement that <code>2048</code> ETH is the maximum stake that the protocol currently is designed to handle.</p> <h3 id="capital-efficiency-and-opportunity-cost">Capital efficiency and opportunity cost</h3> <p>Besides free withdrawals, another benefit of <code>0x01</code> validators is the capital efficiency. A compounding <code>0x02</code> validator will on average have 0.75 ETH sitting idle, not counting toward the effective balance (EB). This is due to the current hysteresis design, where a validator that gradually increases its balance will hold between 0.25 to 1.25 more ETH than their EB. A <code>0x01</code> validator will on average have just $0.0235/2 = 0.01175$ ETH idle, and are thus much more capital-efficient, particularly when the compounding <code>0x02</code> validator holds a moderate balance overall.</p> <p>Figure 1 illustrates the change in yield relative to a baseline with a neutral EB design, where, as the balance compounds, it is on average equal to the EB. The blue line is the yield of compounding <code>0x02</code> validators, which receive a lower yield due to the on average 0.75 ETH lower EB than the balance. The green circles are the yield that skimming 32-ETH and 2048-ETH validators receive. The orange line is the fee imposed on <code>0x01</code> validators proposed in the main specification. As evident, this fee does not fully offset the loss due to yield drag for <code>0x02</code> validators at validator balances below around 1,000 ETH.</p> <p><img src="https://wg-eips.ritovision.com/8062/./assets/1.png" alt="Figure 1" /></p> <p><strong>Figure 1.</strong> Relative change in staking yield due to differences in capital efficiency of different validator configurations. The proposed fee is shown in orange.</p> <p><a href="https://wg-eips.ritovision.com/8068/">EIP-8068</a> addresses differences in capital efficiency between <code>0x01</code> and <code>0x02</code> validators with a neutral EB design, where the hysteresis threshold raises the EB at +0.5. This effectively shifts the blue line, positioning all compounding validators at the black line.</p> <p>If EIP-8068 is not included in the same hardfork as this EIP, we could instead raise the withdrawal fee to compensate. The alternative specification below therefore outlines a higher fee. This will however not address the other concern addressed by EIP-8068: a <code>0x02</code> validator can leverage the hysteresis and make a partial withdrawal once having reached 33 ETH EB, such that they only need to hold 32.75 ETH while keeping 33 ETH EB. This concern can, on the other hand, also be addressed on its own for minimal complexity, as outlined in the alternative specification of EIP-8068.</p> <h3 id="alternative-specification">Alternative specification</h3> <p>If EIP-8068 is not included in the same hardfork as this EIP, it is reasonable to compensate for the lower capital efficiency of <code>0x02</code> validators by setting a higher withdrawal fee. This way, stakers will be less likely to remain on their <code>0x01</code> validators just for the better capital efficiency. Figure 2 shows three different alternative fees with red lines. The white squares illustrate equal capital efficiency between a <code>0x01</code> validator under the proposed fee and a <code>0x02</code> validator at some specific validator balance.</p> <p><img src="https://wg-eips.ritovision.com/8062/./assets/2.png" alt="Figure 2" /></p> <p><strong>Figure 2.</strong> Relative change in staking yield due to differences in capital efficiency of different validator configurations. The main proposed fee is shown in orange, and alternative fees are shown in red.</p> <p>The main option shown by the full red line is to raise the fee from 0.05% to 0.5%, setting <code>WITHDRAWAL_FEE_FRACTION = 200</code>. This means that a 32-ETH <code>0x01</code> validator will have approximately the same capital efficiency as a 128-ETH <code>0x02</code> validator. A stronger option is to impose a 1% fee as shown by the dashed red line, setting <code>WITHDRAWAL_FEE_FRACTION = 100</code>. Under this option, consolidating to a <code>0x02</code> validator will always at least be neutral, if the staker runs more than one <code>0x01</code> validator. A less forceful option is shown by the red dotted line, instead setting <code>WITHDRAWAL_FEE_FRACTION = 400</code>.</p> <p>Table 2 outlines the cost to stakers under the primary alternative specification with <code>WITHDRAWAL_FEE_FRACTION = 200</code>. Stakers then pay an additional $20 per validator. That means that an SSP running 5% of the stake would take a loss of around one million dollars per year, representing a much stronger incentive to consolidate.</p> <table><thead><tr><th>Validators (stake %)</th><th style="text-align: right">Cost (ETH/year)</th><th style="text-align: right">Cost (USD/year)</th></tr></thead><tbody> <tr><td>1 (~0.0001%)</td><td style="text-align: right">0.0048</td><td style="text-align: right">$20</td></tr> <tr><td>100 (~0.01%)</td><td style="text-align: right">0.48</td><td style="text-align: right">$2k</td></tr> <tr><td>10k (~1%)</td><td style="text-align: right">48</td><td style="text-align: right">$200k</td></tr> <tr><td>50k (~5%)</td><td style="text-align: right">240</td><td style="text-align: right">$1M</td></tr> <tr><td>100k (~10%)</td><td style="text-align: right">480</td><td style="text-align: right">$2M</td></tr> </tbody></table> <p><strong>Table 2.</strong> Cost to stakers under the alternative higher withdrawal fee of 0.5% (<code>WITHDRAWAL_FEE_FRACTION = 200</code>).</p> <h2 id="security-considerations">Security Considerations</h2> <p>To the best of the authors' knowledge, there are no security risks associated with the proposed fee.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson https://wg-eips.ritovision.com/8068/

Make the effective balance calculation neutral so that 0x01 and 0x02 validators receive the same yield, thus facilitating consolidation.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a neutral effective balance (EB) design to ensure <code>0x01</code> (skimming) and <code>0x02</code> (compounding) validators receive equal yields. Currently, validators that compound their balance have poor capital efficiency and lower yields as their idle balance (not contributing to EB) is 0.75 ETH, significantly higher than that of skimming validators at near-zero. This disincentivizes stake consolidation critical to Ethereum's fast finality roadmap. Additionally, the current hysteresis rules allow <code>0x02</code> validators to game the hysteresis by keeping their balance below the EB. The increased profitability at lower balances could further harm consolidation. This proposal sets the EB hysteresis upward threshold to the neutral +0.5 and the downward threshold to +0.25. To prevent gaming after operations like partial withdrawals, the EB is reset to the floor of the balance, and a one-time <code>temporary_upward_threshold</code> set. This threshold is derived from an integral equation that ensures the average idle balance is zero as the validator's balance compounds up to the next integer.</p> <h2 id="motivation">Motivation</h2> <p>The roadmap for fast finality hinges on stake consolidation, where staking service providers (SSPs) transition from running 32-ETH validators with <code>0x01</code> credentials to compounding validators with <code>0x02</code> credentials. A roadblock to this transition is that <code>0x01</code> validators have close-to-ideal capital efficiency, whereas <code>0x02</code> validators have poor capital efficiency during compounding. Furthermore, the optimal configuration for a <code>0x02</code> validator is to reduce its balance to 32.75 ETH and prevent it from compounding further. These incentives may lead Ethereum's fast-finality roadmap to be delayed. To prevent this, a neutral effective balance calculation is proposed, that sees all validator configurations earn the same CL yield.</p> <p>A <code>0x02</code> validator that compounds its balance $b$ as intended will on average have 0.75 ETH of its balance not counting toward its effective balance (EB, or $E$ in equations). Specifically, with the current EB step bands, the idle remainder $r=b-E \in[0.25, 1.25)$ and $\bar{r}=(0.25+1.25)/2=0.75$. A <code>0x01</code> validator operating at 32 ETH has a much lower idle remainder, on average half the withdrawal sweep of $0.0235/2 = 0.01175$ ETH. A 32-ETH <code>0x01</code> validator will therefore earn around 2.3% more CL yield than a compounding <code>0x02</code> validator that grows from 32.25 ETH to 34.25 ETH over around two years.</p> <p>A separate issue is that <code>0x02</code> validators can make a partial withdrawal down to 32.75 ETH when having any EB &gt;33 ETH, leveraging the hysteresis to retain a 33 ETH EB. The surplus capital can then be deployed to increase the staking yield, running multiple 32.75-ETH validators. Assuming a 3% CL yield, recurring partial withdrawals deployed at 33 ETH to bring down the balance to 32.75 ETH, and ignoring the exit queue capital drag, the approach is more profitable than running skimming 2048-ETH validators under current base fees.</p> <p>To uphold fairness while not disrupting the current operation of <code>0x01</code> validators, the following changes are made:</p> <ul> <li>The upward EB step from $E$ to $E+1$ is imposed at $E + 0.5$. During regular upward compounding, the EB is thus set as the balance rounded to the nearest integer. This leads a compounding <code>0x02</code> validator to on average have a $E=b$, just like a 32-ETH <code>0x01</code> validator.</li> <li>The downward step to $E$ is imposed at $E+0.25$ ($E_{+1}-0.75$).</li> <li>Partial withdrawals are prevented from gaming the protocol. The EB calculation is designed such that each partial withdrawal is treated neutrally: $E=b$. To achieve this, the following takes place after every partial withdrawal at epoch boundaries: <ul> <li>The EB is initiated to the integer floor of the balance: $E = \text{EB}(b_0) = \lfloor b_0 \rfloor$.</li> <li>A new field <code>temporary_upward_threshold</code> ($t$) is stored in the beacon state.</li> <li>This threshold is computed as $t = E + \frac{1+(b_0-E)^2}{2}$, derived from the integral equation that stipulates that the validator will on average have $E=b$ when it smoothly grows its balance up until the next integer (see the Rationale).</li> <li>To increase the EB, the balance must satisfy both the regular upward threshold <em>and</em> the <code>temporary_upward_threshold</code>, after which <code>temporary_upward_threshold</code> is reset to <code>0</code>.</li> </ul> </li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <p>Change two existing constants:</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>HYSTERESIS_DOWNWARD_MULTIPLIER</code></td><td><code>3</code></td></tr> <tr><td><code>HYSTERESIS_UPWARD_MULTIPLIER</code></td><td><code>2</code></td></tr> </tbody></table> <h3 id="containers">Containers</h3> <p>Two new fields are added to the state:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconState</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> temporary_upward_threshold</span><span>:</span><span> List</span><span>[</span><span>Gwei</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> reset_eb_flags</span><span>:</span><span> List</span><span>[</span><span>boolean</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span></code></pre> <p>On upgrade, both lists are initialized to length <code>len(state.validators)</code> with <code>0</code> and <code>False</code> respectively.</p> <h3 id="functions">Functions</h3> <p>A new helper is added for re-initializing EB and the <code>temporary_upward_threshold</code> for validators that have been marked for EB reset; this helper is invoked during epoch processing.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> initiate_effective_balance_and_threshold</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> index</span><span>:</span><span> ValidatorIndex</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> v</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span></span> <span class="giallo-l"><span> balance</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>balances</span><span>[</span><span>index</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> v</span><span>.</span><span>effective_balance</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>balance</span><span class="z-keyword"> -</span><span> balance</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span><span>,</span><span> get_max_effective_balance</span><span>(</span><span>v</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> =</span><span> (</span><span class="z-constant">EFFECTIVE_BALANCE_INCREMENT</span><span class="z-keyword"> +</span><span> (</span><span>balance</span><span class="z-keyword"> -</span><span> v</span><span>.</span><span>effective_balance</span><span>)</span><span class="z-keyword">**</span><span class="z-constant">2</span><span class="z-keyword"> //</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>temporary_upward_threshold</span><span>[</span><span>index</span><span>]</span><span class="z-keyword"> =</span><span> v</span><span>.</span><span>effective_balance</span><span class="z-keyword"> +</span><span> offset</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>reset_eb_flags</span><span>[</span><span>index</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span></code></pre> <p>The existing <code>process_effective_balance_updates()</code> is modified to call the new helper before updating the EB, and so that the EB update accounts for the <code>temporary_upward_threshold</code>. We show here the whole function for completeness:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_effective_balance_updates</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Update effective balances with hysteresis</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> index</span><span>,</span><span> validator</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> balance</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>balances</span><span>[</span><span>index</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> HYSTERESIS_INCREMENT</span><span class="z-keyword"> =</span><span> uint64</span><span>(</span><span class="z-constant">EFFECTIVE_BALANCE_INCREMENT</span><span class="z-keyword"> //</span><span class="z-constant"> HYSTERESIS_QUOTIENT</span><span>)</span></span> <span class="giallo-l"><span class="z-constant"> DOWNWARD_THRESHOLD</span><span class="z-keyword"> =</span><span class="z-constant"> HYSTERESIS_INCREMENT</span><span class="z-keyword"> *</span><span class="z-constant"> HYSTERESIS_DOWNWARD_MULTIPLIER</span></span> <span class="giallo-l"><span class="z-constant"> UPWARD_THRESHOLD</span><span class="z-keyword"> =</span><span class="z-constant"> HYSTERESIS_INCREMENT</span><span class="z-keyword"> *</span><span class="z-constant"> HYSTERESIS_UPWARD_MULTIPLIER</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>reset_eb_flags</span><span>[</span><span>index</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> initiate_effective_balance_and_threshold</span><span>(</span><span>state</span><span>,</span><span> ValidatorIndex</span><span>(</span><span>index</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> continue</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Then, adjust the existing if-clause to account for the temporary_upward_threshold</span></span> <span class="giallo-l"><span> max_effective_balance</span><span class="z-keyword"> =</span><span> get_max_effective_balance</span><span>(</span><span>validator</span><span>)</span><span> </span></span> <span class="giallo-l"><span> balance_floor</span><span class="z-keyword"> =</span><span> balance</span><span class="z-keyword"> -</span><span> balance</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> balance</span><span class="z-keyword"> +</span><span class="z-constant"> DOWNWARD_THRESHOLD</span><span class="z-keyword"> &lt;</span><span> validator</span><span>.</span><span>effective_balance</span><span>:</span></span> <span class="giallo-l"><span> validator</span><span>.</span><span>effective_balance</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>balance_floor</span><span>,</span><span> max_effective_balance</span><span>)</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>temporary_upward_threshold</span><span>[</span><span>index</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> (</span><span>validator</span><span>.</span><span>effective_balance</span><span class="z-keyword"> +</span><span class="z-constant"> UPWARD_THRESHOLD</span><span class="z-keyword"> &lt;</span><span> balance</span><span> </span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> balance</span><span class="z-keyword"> &gt;=</span><span> state</span><span>.</span><span>temporary_upward_threshold</span><span>[</span><span>index</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> new_eb</span><span class="z-keyword"> =</span><span> balance_floor</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> balance</span><span class="z-keyword"> -</span><span> balance_floor</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span><span class="z-keyword"> //</span><span class="z-constant"> 2</span><span>:</span></span> <span class="giallo-l"><span> new_eb</span><span class="z-keyword"> =</span><span> balance_floor</span><span class="z-keyword"> +</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span></span> <span class="giallo-l"><span> validator</span><span>.</span><span>effective_balance</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>new_eb</span><span>,</span><span> max_effective_balance</span><span>)</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>temporary_upward_threshold</span><span>[</span><span>index</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span></code></pre> <p>When processing partial withdrawal, the flag for reseting the EB is set.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_withdrawals</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> payload</span><span>:</span><span> ExecutionPayload</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> withdrawal</span><span class="z-keyword"> in</span><span> expected_withdrawals</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> After this existing line</span></span> <span class="giallo-l"><span> decrease_balance</span><span>(</span><span>state</span><span>,</span><span> withdrawal</span><span>.</span><span>validator_index</span><span>,</span><span> withdrawal</span><span>.</span><span>amount</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Add a new if-clause and append withdrawals for which we reset the EB</span></span> <span class="giallo-l"><span> v</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>withdrawal</span><span>.</span><span>validator_index</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> v</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> ==</span><span class="z-constant"> FAR_FUTURE_EPOCH</span><span class="z-keyword"> and</span><span> has_compounding_withdrawal_credential</span><span>(</span><span>v</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>reset_eb_flags</span><span>[</span><span>withdrawal</span><span>.</span><span>validator_index</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="relative-change-in-staking-yield">Relative change in staking yield</h3> <p>The figure shows the impact of the current EB bands and hysteresis design on validator yields for different validator configuations. The relative change in staking yield is plotted against a baseline 0 which corresponds to what compounding <code>0x02</code> validators would earn if $E=b$, as in the neutral effective balance design. Note that these are relative changes, so a validator at -0.01 under a CL yield of 3% would earn $0.99 \times 3 = 2.97$% in yield.</p> <p><img src="https://wg-eips.ritovision.com/8068/./assets/1.png" alt="Figure 1" /></p> <p>The blue line is compounding <code>0x02</code> validators, which on average will have 0.75 ETH not counting against their EB. A staker that runs a <code>0x02</code> validator instead of a <code>0x01</code> validator then earns $100\times0.75/b$% lower staking yield. For example, at 32.25 ETH, that difference works out to 2.33%.</p> <p>The red lines capture <code>0x02</code> validators that repeatedly withdraw down to the downward hysteresis threshold at $-0.25$ relative to an integer EB, thus achieving a surplus 0.25 EB relative to their actual balance. They let the balance grow until it is optimal to withdraw it, accounting for a partial withdrawal costing 84500 gas. So for example, starting at 32.75 ETH and with a 0.5 gwei base fee, that works out to making the withdrawal at around 32.80 ETH. The staker then earns 0.56% more staking yield than the baseline, factoring in a 4.5 days delay between when the withdrawn ETH stops earning yield and when it is available at the EL (dashed red line). This delay accounts for a 256 epoch withdrawal eligibility period and an average wait time until the sweep hits of 3.4 days (at a hypothetical future 770 000 active validators). Without the delay, that figure is 0.60%. When the base is 0 and there is a 4.5 days delay, the validator instead earns 0.72% more staking yield (full red line).</p> <p>The green circles are sweeped <code>0x01</code> validators. They earn slightly less than the baseline due to the accruing balance in excess of 32 ETH and 2048 ETH not counting toward the EB, and being delayed by around 3.4 days. (in this specific example where the delay )</p> <p>This comparison could be nuanced further by potentially accounting for a deposit delay, but the ETH does not necessarily need to be deposited directly into the staking contract to bring value to its holder. Another nuance is that a slashing is driven by EB and not validator balance.</p> <h3 id="equation-for-the-temporary-upward-threshold">Equation for the temporary upward threshold</h3> <p>To prevent gaming after a partial withdrawal, the EB is first reset to $E = \lfloor b_0 \rfloor$, where $b_0$ is the new balance. This creates an initial idle remainder $r_0 = b_0 - E$.</p> <p>A <code>temporary_upward_threshold</code> ($t$) is then set to ensure the <em>average</em> idle balance is zero as the validator's balance compounds from $b_0$ to the next integer, $E+1$.</p> <p>This threshold $t$ is calculated to solve the "zero-area" problem: the positive idle balance accumulated while $\text{EB}=E$ (from $b_0$ to $t$) must exactly cancel the negative idle balance accumulated while $\text{EB}=E+1$ (from $t$ to $E+1$). This is expressed by the integral equation:</p> <p>$\int_{b_0}^{t}(b-E) db + \int_{t}^{E+1}(b-(E+1)) db = 0.$</p> <p>Solving for $t$ yields the formula used in the specification:</p> <p>$t = E + \frac{1+r_0^2}{2},$</p> <p>where $r_0 = b_0 - E$.</p> <h3 id="alternative-specifications">Alternative specifications</h3> <h4 id="simple-fix-of-eb-gaming-under-current-bands">Simple fix of EB gaming under current bands</h4> <p>An alternative minimal specification is to only fix the gaming incentive, and instead compensate for the lower yield of <code>0x02</code> validators by increasing the withdrawal fee in <a href="https://wg-eips.ritovision.com/8062/">EIP-8062</a>. Only the partial withdrawal is adjusted. For this specification, only the <code>pending_eb_resets</code> need to be stored in the <code>BeaconState</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconState</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> pending_eb_resets</span><span>:</span><span> List</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> PENDING_PARTIAL_WITHDRAWALS_LIMIT</span><span>]</span></span></code></pre> <p>Append the validator index to <code>pending_eb_resets</code> in <code>process_withdrawals()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_withdrawals</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> payload</span><span>:</span><span> ExecutionPayload</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> withdrawal</span><span class="z-keyword"> in</span><span> expected_withdrawals</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> After this existing line</span></span> <span class="giallo-l"><span> decrease_balance</span><span>(</span><span>state</span><span>,</span><span> withdrawal</span><span>.</span><span>validator_index</span><span>,</span><span> withdrawal</span><span>.</span><span>amount</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Add a new if-clause and append withdrawals for which we reset the EB</span></span> <span class="giallo-l"><span> v</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>withdrawal</span><span>.</span><span>validator_index</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> v</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> ==</span><span class="z-constant"> FAR_FUTURE_EPOCH</span><span class="z-keyword"> and</span><span> has_compounding_withdrawal_credential</span><span>(</span><span>v</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>pending_eb_resets</span><span>.</span><span>append</span><span>(</span><span>withdrawal</span><span>.</span><span>validator_index</span><span>)</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>Modify <code>process_effective_balance_updates()</code> to reset the effective balance upon a partial withdrawal. The balance is never allowed to increase during the reset.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_effective_balance_updates</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Apply EB resets for executed withdrawals</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>pending_eb_resets</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>validators</span><span>[</span><span>i</span><span>]</span><span>.</span><span>effective_balance</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>balances</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> -</span><span> state</span><span>.</span><span>balances</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span><span>,</span></span> <span class="giallo-l"><span> get_max_effective_balance</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>[</span><span>i</span><span>]</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>validators</span><span>[</span><span>i</span><span>]</span><span>.</span><span>effective_balance</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>pending_eb_resets</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>This EIP would trigger a mass upward change of EBs at the specific hardfork boundary. The effect of this should be analyzed furher.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Carlos Perezhttps://github.com/CPerezz Wei Han Nghttps://github.com/weiihann Guillaume Ballethttps://github.com/gballet https://wg-eips.ritovision.com/8058/

Reduces gas costs for deploying duplicate contract bytecode via access-list based mechanism

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a gas discount for contract deployments when the bytecode being deployed already exists in the state. By leveraging EIP-2930 access lists, any contract address included in the access list automatically contributes its code hash to a deduplication check. When the deployed bytecode matches an existing code hash from the access list, the deployment avoids paying <code>GAS_CODE_DEPOSIT * L</code> costs since clients already store the bytecode and only need to link the new account to the existing code hash.</p> <p>This EIP becomes particularly relevant with the adoption of EIP-8037, which increases <code>GAS_CODE_DEPOSIT</code> from 200 to 1,900 gas per byte. Under EIP-8037, deploying a 24kB contract would cost approximately 46.6M gas for code deposit alone, making the deduplication discount economically significant for applications that deploy identical bytecode multiple times.</p> <h2 id="motivation">Motivation</h2> <p>Currently, deploying duplicate bytecode costs the same as deploying new bytecode, even though execution clients don't store duplicated code in their databases. When the same bytecode is deployed multiple times, clients store only one copy and have multiple accounts point to the same code hash. Under EIP-8037's proposed gas costs, deploying a 24kB contract costs approximately 46.6M gas for code deposit alone (<code>1,900 × 24,576</code>). This charge is unfair for duplicate deployments where no additional storage is consumed.</p> <p>A naive "check if code exists in database" approach would break consensus because different nodes have different database contents due to mostly Sync-mode differences:</p> <ul> <li>Full-sync nodes: Retain all historical code, including from reverted/reorged transactions</li> <li>Snap-sync nodes: initially, only store code referenced in the pivot state tries, and those accumulated past the start of the sync</li> </ul> <p>Empirical analysis reveals that approximately 27,869 bytecodes existed in full-synced node databases with no live account pointing to them (as of the Cancun fork). A database lookup <code>CodeExists(hash)</code> would yield different results on different nodes, causing different gas costs and breaking consensus.</p> <p>This proposal solves the problem by making deduplication checks implicit and deterministic through access lists, ensuring all nodes compute identical gas costs regardless of their database state. (Notice here that even if fully-synced clients have more codes, there are no accounts whose codeHash actually is referencing them. Thus, users can't profit from such discounts which keeps consensus safe).</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="implicit-deduplication-via-access-lists">Implicit Deduplication via Access Lists</h3> <p>This proposal leverages the existing EIP-2930 access list structure without any modifications. No new fields or protocol changes are required.</p> <h3 id="codehash-access-set-construction">CodeHash Access-Set Construction</h3> <p>Before transaction execution begins, build a set <code>W</code> (the "CodeHash Access-Set") as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>W = { codeHash(a) | a ∈ accessList, a exists in state, a has code }</span></span></code></pre> <p>Where:</p> <ul> <li><code>W</code> is built from state at the <strong>start</strong> of transaction execution (before any state changes)</li> <li><strong>All</strong> addresses in the access list are checked - if they exist in state and have deployed code, their code hash is added to <code>W</code></li> <li>Empty accounts or accounts with no code do not contribute to <code>W</code></li> </ul> <h3 id="contract-creation-gas-accounting">Contract Creation Gas Accounting</h3> <p>When a contract creation transaction or opcode (<code>CREATE</code>/<code>CREATE2</code>) successfully completes and returns bytecode <code>B</code> of length <code>L</code>, compute <code>H = keccak256(B)</code> and apply the following gas charges:</p> <p><strong>Deduplication check:</strong></p> <ul> <li>If <code>H ∉ W</code>: Bytecode is new <ul> <li>Charge <code>GAS_CODE_DEPOSIT * L</code></li> <li>Persist bytecode <code>B</code> under hash <code>H</code></li> <li>Link the new account's <code>codeHash</code> to <code>H</code></li> </ul> </li> <li>Otherwise, link the new account's <code>codeHash</code> to the existing code hash <code>H</code></li> </ul> <p><strong>Gas costs:</strong></p> <ul> <li>The cost of reading <code>codeHash</code> for access-listed addresses is already covered by EIP-2929/2930 access costs (intrinsic access-list cost and cold→warm state access charges).</li> <li>No additional gas cost is introduced for the deduplication check itself.</li> </ul> <h3 id="implementation-pseudocode">Implementation Pseudocode</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Before transaction execution:</span></span> <span class="giallo-l"><span>W</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">for</span><span class="z-support"> tuple</span><span class="z-keyword"> in</span><span> tx</span><span>.</span><span>access_list</span><span>:</span></span> <span class="giallo-l"><span> warm</span><span>(</span><span class="z-support">tuple</span><span>.</span><span>address</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> per EIP-2930/EIP-2929 rules</span></span> <span class="giallo-l"><span> acc</span><span class="z-keyword"> =</span><span> load_account</span><span>(</span><span class="z-support">tuple</span><span>.</span><span>address</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> acc</span><span> exists</span><span class="z-keyword"> and</span><span> acc</span><span>.</span><span>code</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span> empty</span><span>:</span></span> <span class="giallo-l"><span> W</span><span>.</span><span>add</span><span>(</span><span>acc</span><span>.</span><span>codeHash</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> On successful CREATE/CREATE2:</span></span> <span class="giallo-l"><span>H</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>B</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span> H</span><span class="z-keyword"> in</span><span> W</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Duplicate: no deposit gas</span></span> <span class="giallo-l"><span> link_codehash</span><span>(</span><span>new_account</span><span>,</span><span> H</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New bytecode: charge and persist</span></span> <span class="giallo-l"><span> charge</span><span>(</span><span class="z-constant">GAS_CODE_DEPOSIT</span><span class="z-keyword"> *</span><span class="z-support"> len</span><span>(</span><span>B</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> persist_code</span><span>(</span><span>H</span><span>,</span><span> B</span><span>)</span></span> <span class="giallo-l"><span> link_codehash</span><span>(</span><span>new_account</span><span>,</span><span> H</span><span>)</span></span></code></pre><h3 id="same-block-deployments">Same-Block Deployments</h3> <p>Sequential transaction execution ensures that a deployment storing new code makes it visible to later transactions in the same block:</p> <ol> <li> <p>Transaction <code>T_A</code> deploys bytecode <code>B</code> at address <code>X</code></p> <ul> <li>Pays full <code>GAS_CODE_DEPOSIT * L</code> (no prior contract has this bytecode)</li> <li>Code is stored under hash <code>H = keccak256(B)</code></li> </ul> </li> <li> <p>Later transaction <code>T_B</code> in the same block deploys the same bytecode <code>B</code>:</p> <ul> <li><code>T_B</code> includes address <code>X</code> in its access list</li> <li>When <code>T_B</code> executes, <code>W</code> is built from the current state (including <code>T_A</code>'s changes)</li> <li>Since <code>X</code> now exists and is in the access list, <code>W</code> contains <code>H</code></li> <li><code>T_B</code>'s deployment gets the discount</li> </ul> </li> </ol> <blockquote> <p>While this only tries to formalize the behavior, it's important to remark that this kind of behavior is complex. As it requires control over tx ordering in order to abuse. Builders can't modify the access list as it is already signed with the transaction. Nevertheless, this could happen, thus is formalized here.</p> </blockquote> <h3 id="edge-case-simultaneous-new-deployments">Edge Case: Simultaneous New Deployments</h3> <p>If two transactions in the same block both deploy identical new bytecode and neither references an existing contract with that bytecode in their access lists, both will pay full <code>GAS_CODE_DEPOSIT * L</code>.</p> <p><strong>Example:</strong></p> <ul> <li>Transaction <code>T_A</code> deploys bytecode <code>B</code> producing code hash <code>0xCA</code> at address <code>X</code></li> <li>Transaction <code>T_B</code> (later in same block) also deploys bytecode <code>B</code> producing code hash <code>0xCA</code> at address <code>Y</code></li> <li>If <code>T_B</code>'s access list does NOT include address <code>X</code>, then <code>T_B</code> pays full deposit cost</li> <li>Deduplication only occurs when the deploying address is included in the access list</li> </ul> <p>This is acceptable because:</p> <ul> <li>The first deployment cannot be known at transaction construction time</li> <li>Deduplication requires implicit opt-in via access list</li> <li>This scenario is extremely rare in practice</li> <li>The complexity of special handling is not worth the minimal benefit</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-access-list-based-deduplication">Why Access-List Based Deduplication?</h3> <p>The access-list approach provides several critical properties:</p> <ol> <li> <p>Deterministic behavior: The result depends only on the transaction's access list and current state, not on local database contents. All nodes compute the same gas cost.</p> </li> <li> <p>No reverse index requirement: Unlike other approaches, this doesn't require maintaining a <code>codeHash → [accounts]</code> reverse index, which would add significant complexity and storage overhead.</p> </li> <li> <p>Leverages existing infrastructure: Builds on EIP-2930 access lists and EIP-2929 access costs, requiring minimal protocol changes.</p> </li> <li> <p>Implicit optimization: Any address included in the access list automatically contributes to deduplication. This provides automatic gas optimization without requiring explicit flags or special handling.</p> </li> <li> <p>Avoids chain split risks: Since no new transaction structure is introduced, there's no risk of nodes rejecting transactions with unknown fields. The same transaction format works before and after the fork, with only the gas accounting rules changing at fork activation.</p> </li> <li> <p>Forward compatibility: All nodes enforce identical behavior. Wallets can add addresses to access lists to optimize gas, but this doesn't change transaction validity.</p> </li> <li> <p>Avoid having a code-root for state: At this point, clients handle code storage on their own ways. They don't have any consensus on the deployed existing codes (besides that all of the ones referenced in account's codehash fields exist). Changing this seems a lot more complex and unnecessary.</p> </li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal requires a scheduled network upgrade but is designed to be forward-compatible with existing transactions.</p> <p><strong>Transaction compatibility:</strong></p> <ul> <li>No changes to transaction structure - uses existing EIP-2930 access lists</li> <li>Existing transactions with access lists automatically benefit from deduplication post-fork</li> <li>Transactions without access lists behave identically to current behavior (no deduplication discount)</li> </ul> <p><strong>Wallet and tooling updates:</strong></p> <ul> <li>RPC methods like <code>eth_estimateGas</code> SHOULD account for potential deduplication discounts when access lists are present</li> <li>Wallets MAY provide UI for users to add addresses to access lists for deduplication</li> <li>Transaction builders MAY automatically detect duplicate deployments and include relevant addresses in access lists</li> </ul> <p><strong>Node implementation:</strong></p> <ul> <li>No changes to state trie structure or database schema required</li> <li>No changes to transaction parsing or RLP encoding</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <h3 id="example-transaction">Example Transaction</h3> <p>Deploying a contract with the same bytecode as the contract at <code>0x1234...5678</code>:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">from</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xabcd...ef00</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">to</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">data</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x608060405234801561001...</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">accessList</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">address</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1234567890123456789012345678901234567890</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">storageKeys</span><span class="z-support">&quot;</span><span>:</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>If the deployed bytecode hash matches <code>codeHash(0x1234...5678)</code> (which is automatically checked because the address is in the access list), the deployment receives the deduplication discount.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="gas-cost-accuracy">Gas Cost Accuracy</h3> <p>The deduplication mechanism ensures that gas costs accurately reflect actual resource consumption. Duplicate deployments don't consume additional storage, so they shouldn't pay storage costs.</p> <h3 id="denial-of-service">Denial of Service</h3> <p>The access-list mechanism prevents DoS attacks because:</p> <ul> <li>The cost of reading <code>codeHash</code> is already covered by EIP-2929/2930</li> <li>No additional state lookups or database queries are required</li> <li>The deduplication check is O(1) (set membership test)</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-22T00:00:00+00:00 2026-02-11T14:49:28+00:00 Maria Silvahttps://github.com/misilva73 https://wg-eips.ritovision.com/8059/

Gas parameters and variables are increased to a factor of `REBASE_FACTOR` to reduce rounding errors without major changes to the EVM

<h2 id="abstract">Abstract</h2> <p>This proposal rebases Ethereum’s gas unit to a factor of <code>REBASE_FACTOR</code> to enable high-precision metering without introducing fractional gas. All gas-related parameters and variables are increased to a factor of <code>REBASE_FACTOR</code>. This reduces rounding errors that arise when repricing EVM operations and future-proofs gas costs as hardware improves and state access remains costly, while avoiding major changes in the internal logic of the EVM.</p> <h2 id="motivation">Motivation</h2> <p>Currently, most EVM compute operations (<code>ADD</code>, <code>SUB</code>, <code>MUL</code>, etc.) are significantly underpriced when compared with state operations (<code>SSTORE</code>, <code>SLOAD</code>, <code>CREATE</code>, etc.). There are two factors contributing to this mismatch. On one hand, client optimizations and hardware improvements have made pure compute operations more efficient. On the other hand, with the growing size of the Ethereum state, the performance of I/O operations touching this larger state has been deteriorating. Both of these trends are expected to continue, further worsening this mismatch.</p> <p>There are a couple of proposals to reduce the cost of compute operations (<a href="https://wg-eips.ritovision.com/7904/">EIP-7904</a>) and increase the cost of state operations (<a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>, <a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a>, and <a href="https://wg-eips.ritovision.com/8038/">EIP-8038</a>). However, given the current level of mismatch between these operations, there is an inherent trade-off in the anchor we use to reprice these operations.</p> <p>If we make compute operations cheaper, we will introduce rounding errors, with most compute operations costing 1, when they should cost a fraction of that. These rounding errors impact scalability because we can now fit fewer of these cheaper operations in any given block. However, if we price all operations so that the fastest opcode is assigned 1 gas, we would need to make all other operations significantly more expensive, including both compute and state operations. Such a level of price increases would severely reduce throughput at current block limits.</p> <p>To illustrate this point, let's focus on the pure compute operations. As compute operations impact only block execution time, the chosen anchor will induce a specific million gas per second rate on all compute opcodes. For instance, if we anchor on <code>EcRecover</code> at the current price (3000 gas units), this induces a rate of 175Mgas/s, based on the execution time estimated for this opcode on <a href="../07904/assets/gas-cost-estimator-report.pdf">EIP-7904's empirical analysis</a>. The following plot shows the average rounding errors of compute operations for different anchors, using the same execution time estimates from EIP-7904.</p> <p><img src="https://wg-eips.ritovision.com/8059/./assets/round_error_by_anchor.png" alt="round_error_by_anchor" /></p> <p>As we can see, with an anchor of 50Mgas/s (which would result in a gas limit of 100Mgas, assuming a 2-second block execution limit), we would get an average rounding error of 59.3%. This means that we could be 59.3% cheaper on average per opcode if we didn't have to round to integer gas units. Only after a 400Mgas/s anchor do we get to reasonably low rounding errors. Without fractional gas, which would introduce further complexity to the EVM gas calculation, this level of Mgas/s anchor requires a major rebase of the gas model, where all opcodes become significantly more expensive, and both the transaction-level and block-level gas limits increase by the same factor.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th style="text-align: center"><strong>Parameter</strong></th><th style="text-align: center"><strong>Value</strong></th></tr></thead><tbody> <tr><td style="text-align: center"><code>REBASE_FACTOR</code></td><td style="text-align: center">1000</td></tr> </tbody></table> <p>This proposal introduces a gas rebase such that all gas-related parameters and variables are increased by a factor of <code>REBASE_FACTOR</code>.</p> <p>At fork boundary, <code>calculate_base_fee_per_gas</code> is updated so that both <code>parent_gas_used</code> and <code>parent_base_fee_per_gas</code> are also scaled by a factor of <code>REBASE_FACTOR</code>.</p> <h2 id="rationale">Rationale</h2> <p>A rebase factor of 1000 has two advantages:</p> <ol> <li>It is large enough to completely remove rounding errors for compute operations now and to be future-proof. As we can see from the motivation, an anchor of 400Mgas/s would be enough to reduce these errors. Assuming a 2-second block execution time, this results in a block limit of 800M gas units, which requires an increase of 22x over the current 36M block limit.</li> <li>It makes reasoning about the new gas unit simpler. Block limits and targets move from million units to billion units, while gas costs move from units to thousand units.</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Increasing the cost of state access operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.</p> <p>In addition, the increase in units in <code>gasLimit</code> and <code>gasUsed</code> will increase the size of the RLP representation the block header by 2 bytes. More analysis is needed to assess the bandwidth impacts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Adamshttps://github.com/benaadams Toni Wahrstätterhttps://github.com/nerolation Maria Inês Silvahttps://github.com/misilva73 Amirul Ashrafhttps://github.com/asdacap https://wg-eips.ritovision.com/8057/

Multi‑block temporal locality discounts for state and account access

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a deterministic, multi-block discount for the first access to accounts and storage keys in a transaction. The discount depends on how many blocks have passed since the item was last accessed, decaying smoothly to zero over a fixed recent window. Intra-block warming semantics are unchanged - there is no warming across transactions within a block.</p> <p>The mechanism builds on block-level access lists (<a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a>), which are committed in prior blocks. This allows a newly synced node to correctly price the first block it validates without replaying historical execution.</p> <h2 id="motivation">Motivation</h2> <p>Current warm and cold access pricing correctly models client state costs in the <em>worst case</em> but leaves a predictable efficiency gap in the <em>common case</em>. Clients maintain short-lived in-memory caches of recently accessed accounts and storage slots to handle short reorgs and pipeline execution across blocks. These caches make accesses from recent blocks materially cheaper than fully cold loads, yet the gas model does not reflect this.</p> <p>As a result, Ethereum's gas schedule is conservative: it prices every "first access" as if it were completely cold, even though for most active contracts those lookups are served from hot caches or SSD pages still in memory. The gap between average and worst-case cost limits how far the block gas limit can safely rise-clients must size for the worst case even if most blocks are far cheaper in practice.</p> <p>We can adjust gas prices to surface this mechanical sympathy, rewarding patterns that align naturally with how hardware and clients already behave.</p> <p>This proposal narrows that gap in a deterministic and consensus-safe way. It introduces a smoothly decaying, per-item discount based solely on <em>publicly observable prior-block activity</em> recorded in block-level access lists (<a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a>). That achieves three effects:</p> <ol> <li><strong>Predictability at submission time</strong> - Unlike same-block or cross-transaction warming, discounts depend only on past blocks, so users, builders, and wallets can compute exact costs deterministically from on-chain data.</li> <li><strong>Behavioural alignment</strong> - The mechanism encourages natural temporal locality: dapps and operators who reuse state within a few blocks save gas, reflecting the real cost profile of client caching.</li> <li><strong>Improved L1 scalability</strong> - By reducing the <em>average</em> gas cost of realistic workloads without changing the <em>worst case</em>, 8057 effectively raises real execution throughput per gas, helping move toward the "Scale L1" goal of larger blocks and better hardware utilisation.</li> </ol> <p>Empirically, traces show that most hot contracts are touched repeatedly within a few blocks. A 32-block (≈6-minute) window captures the majority of these recurrences. In this regime, total gas usage per block can fall by several percent in steady state, freeing execution capacity without altering consensus rules or transaction semantics.</p> <p>In short, 8057 aligns Ethereum's gas economics with real execution cost, using already-available data (BALs) to make temporal locality explicit, deterministic, and beneficial.</p> <p>As the saving depends only on publicly observable prior-block activity, it is knowable at submission time. Unlike same-block effects, it is therefore behaviour-shaping rather than incidental. It nudges workloads that naturally cluster accesses to keep doing so, matching how clients amortise repeated recent accesses.</p> <p>This proposal is intentionally scoped to per-transaction warming and does not apply intra-block warming across transactions.</p> <h2 id="specification">Specification</h2> <h3 id="terminology-and-constants">Terminology and constants</h3> <table><thead><tr><th>Name</th><th>Description</th><th>Default</th></tr></thead><tbody> <tr><td><code>WINDOW_SIZE_BLOCKS</code></td><td>Number of recent blocks over which a discount may apply.</td><td><code>32</code></td></tr> <tr><td><code>CURRENT_BLOCK_NUMBER</code></td><td>The block number of the transaction being executed.</td><td>-</td></tr> <tr><td><code>LAST_ACCESS_BLOCK_NUMBER(item)</code></td><td>The most recent block number strictly less than <code>CURRENT_BLOCK_NUMBER</code> in which <code>item</code> was accessed by an executed transaction. If unknown or older than <code>WINDOW_SIZE_BLOCKS</code>, it is treated as not found.</td><td>-</td></tr> <tr><td><code>BLOCK_DISTANCE_IN_BLOCKS(item)</code></td><td>Defined as <code>CURRENT_BLOCK_NUMBER - LAST_ACCESS_BLOCK_NUMBER(item)</code> when the latter is found, else a value greater than <code>WINDOW_SIZE_BLOCKS</code>.</td><td>-</td></tr> </tbody></table> <p>Gas constants from existing behaviour:</p> <table><thead><tr><th>Name</th><th style="text-align: right">Value</th></tr></thead><tbody> <tr><td><code>SLOAD_WARM_GAS_COST</code></td><td style="text-align: right"><code>100</code></td></tr> <tr><td><code>SLOAD_COLD_SURCHARGE_GAS</code></td><td style="text-align: right"><code>2100</code></td></tr> <tr><td><code>ACCOUNT_WARM_GAS_COST</code></td><td style="text-align: right"><code>100</code></td></tr> <tr><td><code>ACCOUNT_COLD_SURCHARGE_GAS</code></td><td style="text-align: right"><code>2600</code></td></tr> </tbody></table> <p>Discount caps (this EIP treats maximum as full cold surcharge, minimum as zero):</p> <table><thead><tr><th>Name</th><th style="text-align: right">Value</th></tr></thead><tbody> <tr><td><code>DISCOUNT_MAX_SLOAD</code></td><td style="text-align: right"><code>SLOAD_COLD_SURCHARGE_GAS</code></td></tr> <tr><td><code>DISCOUNT_MIN_SLOAD</code></td><td style="text-align: right"><code>0</code></td></tr> <tr><td><code>DISCOUNT_MAX_ACCOUNT</code></td><td style="text-align: right"><code>ACCOUNT_COLD_SURCHARGE_GAS</code></td></tr> <tr><td><code>DISCOUNT_MIN_ACCOUNT</code></td><td style="text-align: right"><code>0</code></td></tr> </tbody></table> <p>This means the closest prior-block usage allows the first access in a transaction to be charged at warm cost, and the far edge of the window trends to the normal cold-plus-warm cost.</p> <h3 id="scope-of-operations">Scope of operations</h3> <p>This EIP applies the discount to the <strong>first access in a transaction</strong> of:</p> <ul> <li>Storage keys accessed by <code>SLOAD</code> and by any operation that first reads a slot as part of its semantics (for example, <code>SSTORE</code>'s read step).</li> <li>Account touches that incur the cold account access surcharge under the current gas schedule, including but not limited to: <code>BALANCE</code>, <code>EXTCODEHASH</code>, <code>EXTCODESIZE</code>, <code>EXTCODECOPY</code>, and the target account of <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code>.</li> </ul> <p>Writes are affected <strong>only</strong> to the extent they perform an initial read or account touch that would have been charged as cold. Write-specific costs and any refund semantics are unchanged.</p> <p>Precompiles remain unchanged and are always warm. Because they do not pay a cold surcharge, no discount is applied to precompile calls.</p> <p>Access lists per <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> remain effective and, when present, pre-warm the listed addresses and storage keys at the start of the transaction. For items that are pre-warmed by an access list, this temporal discount does not apply.</p> <h3 id="discount-function">Discount function</h3> <p>The discount decays smoothly with block distance, using a <strong>reversed Hermite smoothstep</strong> interpolation over the discount window.</p> <p><img src="https://wg-eips.ritovision.com/8057/./assets/gas_discount_percentage.png" alt="Gas discount percentage graph" /></p> <p>Mathematically:</p> <p>$x = \mathrm{clamp}\left( \frac{D - 1}{W - 1}, 0, 1 \right)$</p> <p>$f(D, W) = d_{\text{min}} + (d_{\text{max}} - d_{\text{min}}) \cdot \left( 1 - \left( 3x^2 - 2x^3 \right) \right)$</p> <p>where:</p> <ul> <li>$D$ = block distance in blocks</li> <li>$W$ = window size in blocks</li> <li>$d_{\text{min}}$, $d_{\text{max}}$ = minimum and maximum discounts</li> </ul> <p>This form maps:</p> <ul> <li>$D = 1$ → full discount $(f = d_{\text{max}})$</li> <li>$D = W$ → no discount $(f = d_{\text{min}})$</li> </ul> <p>Programmatic form</p> <p>Reference smoothstep helper:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> smoothstep</span><span>(</span><span class="z-variable z-parameter z-function">edge0</span><span>:</span><span class="z-support"> float</span><span>,</span><span class="z-variable z-parameter z-function"> edge1</span><span>:</span><span class="z-support"> float</span><span>,</span><span class="z-variable z-parameter z-function"> x</span><span>:</span><span class="z-support"> float</span><span>)</span><span> -&gt;</span><span class="z-support"> float</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Scale and clamp x to [0, 1], then apply cubic Hermite smoothstep.</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span> x</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">0.0</span><span>,</span><span class="z-support"> min</span><span>(</span><span class="z-constant">1.0</span><span>,</span><span> (</span><span>x</span><span class="z-keyword"> -</span><span> edge0</span><span>)</span><span class="z-keyword"> /</span><span> (</span><span>edge1</span><span class="z-keyword"> -</span><span> edge0</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> x</span><span class="z-keyword"> *</span><span> x</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">3.0</span><span class="z-keyword"> -</span><span class="z-constant"> 2.0</span><span class="z-keyword"> *</span><span> x</span><span>)</span></span></code></pre> <p>Calculation steps:</p> <ul> <li><code>NORMALIZED_DISTANCE = (BLOCK_DISTANCE_IN_BLOCKS - 1) / (WINDOW_SIZE_BLOCKS - 1)</code> clamped to <code>[0, 1]</code>. This maps distance <code>1</code> → <code>0</code> and distance <code>WINDOW_SIZE_BLOCKS</code> → <code>1</code>.</li> <li><code>SMOOTHSTEP_VALUE = smoothstep(0.0, 1.0, NORMALIZED_DISTANCE)</code></li> <li><code>DISCOUNT_FACTOR = 1.0 - SMOOTHSTEP_VALUE</code> (equals <code>1.0</code> at distance <code>1</code>, and <code>0.0</code> at distance <code>WINDOW_SIZE_BLOCKS</code>)</li> </ul> <p>For a given opcode family with parameters <code>DISCOUNT_MAX</code> and <code>DISCOUNT_MIN</code>, the integer discount applied to the <strong>cold surcharge</strong> is:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span class="z-constant"> BLOCK_DISTANCE_IN_BLOCKS</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 0</span><span class="z-keyword"> or</span><span class="z-constant"> BLOCK_DISTANCE_IN_BLOCKS</span><span class="z-keyword"> &gt;</span><span class="z-constant"> WINDOW_SIZE_BLOCKS</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_GAS</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> NORMALIZED_DISTANCE</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> 0.0</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> min</span><span>(</span><span class="z-constant">1.0</span><span>,</span><span> (</span><span class="z-constant">BLOCK_DISTANCE_IN_BLOCKS</span><span class="z-keyword"> -</span><span class="z-constant"> 1.0</span><span>)</span><span class="z-keyword"> /</span><span> (</span><span class="z-constant">WINDOW_SIZE_BLOCKS</span><span class="z-keyword"> -</span><span class="z-constant"> 1.0</span><span>)</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-constant"> SMOOTHSTEP_VALUE</span><span class="z-keyword"> =</span><span> smoothstep</span><span>(</span><span class="z-constant">0.0</span><span>,</span><span class="z-constant"> 1.0</span><span>,</span><span class="z-constant"> NORMALIZED_DISTANCE</span><span>)</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_FACTOR</span><span class="z-keyword"> =</span><span class="z-constant"> 1.0</span><span class="z-keyword"> -</span><span class="z-constant"> SMOOTHSTEP_VALUE</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_GAS</span><span class="z-keyword"> =</span><span class="z-constant"> DISCOUNT_MIN</span><span class="z-keyword"> +</span><span class="z-support"> round</span><span>(</span></span> <span class="giallo-l"><span> (</span><span class="z-constant">DISCOUNT_MAX</span><span class="z-keyword"> -</span><span class="z-constant"> DISCOUNT_MIN</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> DISCOUNT_FACTOR</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>All arithmetic must be implemented in <strong>integer space</strong> in consensus-critical code; floating point is shown here only for clarity. <code>round()</code> follows <em>round half up</em> semantics; any deterministic rule is acceptable if consistently applied across clients.</p> <p>This mechanism is a <strong>discount</strong>, not a refund. It reduces gas charged upfront for a cold surcharge; it does not emit a rebate and does not affect refund accounting or receipts.</p> <h3 id="charging-rules-per-transaction">Charging rules (per transaction)</h3> <p>For the first access to an <code>ITEM</code> <strong>within a transaction</strong>:</p> <ol> <li> <p>If <code>ITEM</code> is already warm in this transaction due to same-transaction rules or pre-warmed via a transaction access list, charge the warm cost defined today. No temporal discount applies.</p> </li> <li> <p>Otherwise compute <code>BLOCK_DISTANCE_IN_BLOCKS(ITEM)</code>. If <code>1 &lt;= BLOCK_DISTANCE_IN_BLOCKS(ITEM) &lt;= WINDOW_SIZE_BLOCKS</code>, apply the discount to the cold surcharge:</p> <ul> <li> <p>Storage read first access cost:</p> <ul> <li><code>SLOAD_FIRST_ACCESS_COST = SLOAD_WARM_GAS_COST + max(0, SLOAD_COLD_SURCHARGE_GAS - DISCOUNT_SLOAD(BLOCK_DISTANCE_IN_BLOCKS))</code></li> </ul> </li> <li> <p>Account-touch first access cost:</p> <ul> <li><code>ACCOUNT_FIRST_ACCESS_COST = ACCOUNT_WARM_GAS_COST + max(0, ACCOUNT_COLD_SURCHARGE_GAS - DISCOUNT_ACCOUNT(BLOCK_DISTANCE_IN_BLOCKS))</code></li> </ul> </li> </ul> </li> <li> <p>If <code>BLOCK_DISTANCE_IN_BLOCKS(ITEM) &gt; WINDOW_SIZE_BLOCKS</code> or not found, charge the unmodified cold surcharge plus the warm component as today.</p> </li> </ol> <p>Subsequent accesses to the same <code>ITEM</code> within the <strong>same transaction</strong> are warm as per existing rules. This EIP does not introduce block-level warming across transactions.</p> <h3 id="initial-sync-and-pricing-with-block-level-access-lists">Initial sync and pricing with block-level access lists</h3> <p>This EIP requires block-level access lists in blocks. Each block carries commitments to the sets of accounts and storage keys accessed during that block.</p> <p>A newly synced node can price the very first block it validates as follows:</p> <ol> <li>For a block to validate at <code>CURRENT_BLOCK_NUMBER</code>, gather the BALs for the previous <code>WINDOW_SIZE_BLOCKS</code> blocks.</li> <li>For each of those blocks, obtain the committed sets of accessed accounts and storage keys from the block body.</li> <li>Build a local index mapping each seen <code>ITEM</code> to the most recent block number in which it appears within that window. This becomes <code>LAST_ACCESS_BLOCK_NUMBER(ITEM)</code>.</li> <li>When validating <code>CURRENT_BLOCK_NUMBER</code>, for each first access to <code>ITEM</code>, compute <code>BLOCK_DISTANCE_IN_BLOCKS(ITEM) = CURRENT_BLOCK_NUMBER - LAST_ACCESS_BLOCK_NUMBER(ITEM)</code> when present, else treat as out-of-window. Apply the discount rules above.</li> </ol> <p>Reorgs longer than <code>WINDOW_SIZE_BLOCKS</code> fall back to the same procedure as initial resync. Items not present in the new canonical window are treated as cold.</p> <p>No execution of historical transactions is required to compute the discount at validation time. Stateless verifiers can price gas using the current block plus compact proofs that an item appears in one of the previous <code>WINDOW_SIZE_BLOCKS</code> access lists.</p> <h3 id="wallet-gas-estimation-guidance">Wallet gas estimation guidance</h3> <p>Wallets and RPC endpoints should not assume that a temporal discount will apply at submission, because the exact landing block is uncertain. General-purpose estimators should price as if no temporal discount applies.</p> <p>Operators who can predict landing with high confidence - for example via priority fees and private order flow - may account for the exact discount, but this is an advanced path and not the default.</p> <p>Motivated operators who can reliably land transactions in a specific block - for example via private order flow and appropriately set priority fees - may account for the exact discount. This is an advanced use case and should not be the default behaviour for general-purpose wallets.</p> <h3 id="implementation-guidance">Implementation guidance</h3> <p>Clients are expected to maintain a rolling in-memory index to avoid rescanning prior blocks for each block:</p> <ul> <li>Keep a ring buffer of <code>WINDOW_SIZE_BLOCKS</code> buckets, one per recent block. Each bucket stores first-touched accounts and first-touched storage keys for that block.</li> <li>Maintain two maps, <code>LAST_SEEN_ACCOUNT</code> and <code>LAST_SEEN_STORAGE_KEY</code>, which track the most recent block index within the window where each item was present. On block advance, drop the oldest bucket and delete items that only appeared there, or mark them as out-of-window.</li> <li>During execution, when an opcode is about to charge a cold surcharge for an item not yet warm in the current transaction, look up <code>BLOCK_DISTANCE_IN_BLOCKS</code> from the <code>LAST_SEEN_*</code> map and charge using the rules above. Then record first touches for the current block in the current bucket and update the maps.</li> </ul> <p>This design keeps memory bounded by <code>WINDOW_SIZE_BLOCKS</code> multiplied by the number of distinct first touches per block, which is itself bounded by the block gas limit divided by the minimum per-item cost.</p> <p>This is one practical approach; clients may also implement this via existing caches or by embedding and pruning block-distance hints in their state trie.</p> <h3 id="test-cases">Test cases</h3> <h3 id="example-parameters-and-results">Example parameters and results</h3> <p>Assume the following defaults:</p> <table><thead><tr><th>Name</th><th style="text-align: right">Value</th></tr></thead><tbody> <tr><td><code>WINDOW_SIZE_BLOCKS</code></td><td style="text-align: right"><code>32</code></td></tr> <tr><td><code>SLOAD_WARM_GAS_COST</code></td><td style="text-align: right"><code>100</code></td></tr> <tr><td><code>SLOAD_COLD_SURCHARGE_GAS</code></td><td style="text-align: right"><code>2100</code></td></tr> <tr><td><code>ACCOUNT_WARM_GAS_COST</code></td><td style="text-align: right"><code>100</code></td></tr> <tr><td><code>ACCOUNT_COLD_SURCHARGE_GAS</code></td><td style="text-align: right"><code>2600</code></td></tr> <tr><td><code>DISCOUNT_MAX_SLOAD</code></td><td style="text-align: right"><code>2100</code></td></tr> <tr><td><code>DISCOUNT_MIN_SLOAD</code></td><td style="text-align: right"><code>0</code></td></tr> <tr><td><code>DISCOUNT_MAX_ACCOUNT</code></td><td style="text-align: right"><code>2600</code></td></tr> <tr><td><code>DISCOUNT_MIN_ACCOUNT</code></td><td style="text-align: right"><code>0</code></td></tr> </tbody></table> <h4 id="example-first-storage-read-in-a-transaction">Example: first storage read in a transaction</h4> <table><thead><tr><th><code>BLOCK_DISTANCE_IN_BLOCKS</code></th><th style="text-align: right">Discount</th><th style="text-align: right">Charge</th><th>Notes</th></tr></thead><tbody> <tr><td><code>1</code></td><td style="text-align: right"><code>2100</code></td><td style="text-align: right"><code>100</code></td><td>Equal to warm</td></tr> <tr><td><code>8</code></td><td style="text-align: right"><code>1827</code></td><td style="text-align: right"><code>373</code></td><td>-</td></tr> <tr><td><code>16</code></td><td style="text-align: right"><code>1101</code></td><td style="text-align: right"><code>1099</code></td><td>Mid-window</td></tr> <tr><td><code>24</code></td><td style="text-align: right"><code>347</code></td><td style="text-align: right"><code>1853</code></td><td>-</td></tr> <tr><td><code>32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2200</code></td><td>Window edge</td></tr> <tr><td><code>&gt;32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2200</code></td><td>Fully cold</td></tr> </tbody></table> <h4 id="example-first-account-touch-in-a-transaction">Example: first account touch in a transaction</h4> <table><thead><tr><th><code>BLOCK_DISTANCE_IN_BLOCKS</code></th><th style="text-align: right">Discount</th><th style="text-align: right">Charge</th><th>Notes</th></tr></thead><tbody> <tr><td><code>1</code></td><td style="text-align: right"><code>2600</code></td><td style="text-align: right"><code>100</code></td><td>Equal to warm</td></tr> <tr><td><code>8</code></td><td style="text-align: right"><code>2262</code></td><td style="text-align: right"><code>438</code></td><td>-</td></tr> <tr><td><code>16</code></td><td style="text-align: right"><code>1363</code></td><td style="text-align: right"><code>1337</code></td><td>Mid-window</td></tr> <tr><td><code>24</code></td><td style="text-align: right"><code>430</code></td><td style="text-align: right"><code>2270</code></td><td>-</td></tr> <tr><td><code>32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2700</code></td><td>Window edge</td></tr> <tr><td><code>&gt;32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2700</code></td><td>Fully cold</td></tr> </tbody></table> <p>Exact integer results are determined by the reference implementation's rounding rule (<code>round_to_nearest</code>, half-up).</p> <h3 id="reference-implementation-python-integer-only">Reference implementation (Python, integer only)</h3> <p>This implementation is normative for rounding and scaling. It uses a power-of-two fixed-point scale so divisions by the scale are exact shifts in low-level implementations. All intermediates fit below 2**53 so a JavaScript client can mirror these steps without a big number library.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Gas constants</span></span> <span class="giallo-l"><span class="z-constant">SLOAD_WARM_GAS_COST</span><span class="z-keyword"> =</span><span class="z-constant"> 100</span></span> <span class="giallo-l"><span class="z-constant">SLOAD_COLD_SURCHARGE_GAS</span><span class="z-keyword"> =</span><span class="z-constant"> 2100</span></span> <span class="giallo-l"><span class="z-constant">ACCOUNT_WARM_GAS_COST</span><span class="z-keyword"> =</span><span class="z-constant"> 100</span></span> <span class="giallo-l"><span class="z-constant">ACCOUNT_COLD_SURCHARGE_GAS</span><span class="z-keyword"> =</span><span class="z-constant"> 2600</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Temporal discount parameters</span></span> <span class="giallo-l"><span class="z-constant">WINDOW_SIZE_BLOCKS</span><span class="z-keyword"> =</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span class="z-constant">DISCOUNT_MAX_SLOAD</span><span class="z-keyword"> =</span><span class="z-constant"> SLOAD_COLD_SURCHARGE_GAS</span></span> <span class="giallo-l"><span class="z-constant">DISCOUNT_MIN_SLOAD</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-constant">DISCOUNT_MAX_ACCOUNT</span><span class="z-keyword"> =</span><span class="z-constant"> ACCOUNT_COLD_SURCHARGE_GAS</span></span> <span class="giallo-l"><span class="z-constant">DISCOUNT_MIN_ACCOUNT</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Fixed-point scale (2^25 = 33,554,432)</span></span> <span class="giallo-l"><span class="z-constant">SCALE_FACTOR</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 25</span></span> <span class="giallo-l"><span class="z-constant">HALF_SCALE</span><span class="z-keyword"> =</span><span class="z-constant"> SCALE_FACTOR</span><span class="z-keyword"> &gt;&gt;</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> smooth_factor_scaled</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> window_blocks</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> WINDOW_SIZE_BLOCKS</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Returns round_to_nearest(SCALE_FACTOR * DISCOUNT_FACTOR) where:</span></span> <span class="giallo-l"><span class="z-string"> normalized_distance = (block_distance_in_blocks - 1) / (window_blocks - 1),</span></span> <span class="giallo-l"><span class="z-string"> clamped to [0, 1]</span></span> <span class="giallo-l"><span class="z-string"> smoothstep_value = normalized_distance^2 * (3 - 2 * normalized_distance)</span></span> <span class="giallo-l"><span class="z-string"> discount_factor = 1 - smoothstep_value</span></span> <span class="giallo-l"><span class="z-string"> The result is in [0, SCALE_FACTOR].</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_distance_in_blocks</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 0</span><span class="z-keyword"> or</span><span> block_distance_in_blocks</span><span class="z-keyword"> &gt;</span><span> window_blocks</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Use exact rational form to minimize scaling multiplications:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Let t = block_distance_in_blocks - 1, d = window_blocks - 1.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> discount_factor = (d^3 - 3*d*t^2 + 2*t^3) / d^3</span></span> <span class="giallo-l"><span> t</span><span class="z-keyword"> =</span><span> block_distance_in_blocks</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> d</span><span class="z-keyword"> =</span><span> window_blocks</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> d3</span><span class="z-keyword"> =</span><span> d</span><span class="z-keyword"> *</span><span> d</span><span class="z-keyword"> *</span><span> d</span></span> <span class="giallo-l"><span> t2</span><span class="z-keyword"> =</span><span> t</span><span class="z-keyword"> *</span><span> t</span></span> <span class="giallo-l"><span> t3</span><span class="z-keyword"> =</span><span> t2</span><span class="z-keyword"> *</span><span> t</span></span> <span class="giallo-l"><span> numerator</span><span class="z-keyword"> =</span><span> d3</span><span class="z-keyword"> -</span><span class="z-constant"> 3</span><span class="z-keyword"> *</span><span> d</span><span class="z-keyword"> *</span><span> t2</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span> t3</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Round half up</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span class="z-constant">SCALE_FACTOR</span><span class="z-keyword"> *</span><span> numerator</span><span class="z-keyword"> +</span><span> (</span><span>d3</span><span class="z-keyword"> //</span><span class="z-constant"> 2</span><span>)</span><span>)</span><span class="z-keyword"> //</span><span> d3</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> discount_gas_units</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> discount_max</span><span>:</span><span class="z-support"> int</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> discount_min</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Integer discount within the window using the smooth falloff.</span></span> <span class="giallo-l"><span class="z-string"> Returns an integer number of gas units to subtract from the cold surcharge.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_distance_in_blocks</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 0</span><span class="z-keyword"> or</span><span> block_distance_in_blocks</span><span class="z-keyword"> &gt;</span><span class="z-constant"> WINDOW_SIZE_BLOCKS</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> factor_scaled</span><span class="z-keyword"> =</span><span> smooth_factor_scaled</span><span>(</span><span>block_distance_in_blocks</span><span>,</span><span class="z-constant"> WINDOW_SIZE_BLOCKS</span><span>)</span></span> <span class="giallo-l"><span> span</span><span class="z-keyword"> =</span><span> discount_max</span><span class="z-keyword"> -</span><span> discount_min</span></span> <span class="giallo-l"><span> scaled</span><span class="z-keyword"> =</span><span> (</span><span>span</span><span class="z-keyword"> *</span><span> factor_scaled</span><span class="z-keyword"> +</span><span class="z-constant"> HALF_SCALE</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> SCALE_FACTOR</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> discount_min</span><span class="z-keyword"> +</span><span> scaled</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> sload_first_access_cost</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> disc</span><span class="z-keyword"> =</span><span> discount_gas_units</span><span>(</span><span>block_distance_in_blocks</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_MAX_SLOAD</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_MIN_SLOAD</span><span>)</span></span> <span class="giallo-l"><span> cold_part</span><span class="z-keyword"> =</span><span class="z-constant"> SLOAD_COLD_SURCHARGE_GAS</span><span class="z-keyword"> -</span><span> disc</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> cold_part</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> cold_part</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> SLOAD_WARM_GAS_COST</span><span class="z-keyword"> +</span><span> cold_part</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> account_first_access_cost</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> disc</span><span class="z-keyword"> =</span><span> discount_gas_units</span><span>(</span><span>block_distance_in_blocks</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_MAX_ACCOUNT</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> DISCOUNT_MIN_ACCOUNT</span><span>)</span></span> <span class="giallo-l"><span> cold_part</span><span class="z-keyword"> =</span><span class="z-constant"> ACCOUNT_COLD_SURCHARGE_GAS</span><span class="z-keyword"> -</span><span> disc</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> cold_part</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> cold_part</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> ACCOUNT_WARM_GAS_COST</span><span class="z-keyword"> +</span><span> cold_part</span></span></code></pre> <p>Using lookup tables</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> SLOAD first access cost per block distance (1-32)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> WINDOW_SIZE_BLOCKS = 32</span></span> <span class="giallo-l"><span class="z-constant">SLOAD_FIRST_ACCESS_COST_LUT</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span class="z-constant"> 100</span><span>,</span><span class="z-constant"> 106</span><span>,</span><span class="z-constant"> 125</span><span>,</span><span class="z-constant"> 155</span><span>,</span><span class="z-constant"> 196</span><span>,</span><span class="z-constant"> 246</span><span>,</span><span class="z-constant"> 306</span><span>,</span><span class="z-constant"> 373</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 447</span><span>,</span><span class="z-constant"> 528</span><span>,</span><span class="z-constant"> 615</span><span>,</span><span class="z-constant"> 706</span><span>,</span><span class="z-constant"> 800</span><span>,</span><span class="z-constant"> 898</span><span>,</span><span class="z-constant"> 998</span><span>,</span><span class="z-constant"> 1099</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 1201</span><span>,</span><span class="z-constant"> 1302</span><span>,</span><span class="z-constant"> 1402</span><span>,</span><span class="z-constant"> 1500</span><span>,</span><span class="z-constant"> 1594</span><span>,</span><span class="z-constant"> 1685</span><span>,</span><span class="z-constant"> 1772</span><span>,</span><span class="z-constant"> 1853</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 1927</span><span>,</span><span class="z-constant"> 1994</span><span>,</span><span class="z-constant"> 2054</span><span>,</span><span class="z-constant"> 2104</span><span>,</span><span class="z-constant"> 2145</span><span>,</span><span class="z-constant"> 2175</span><span>,</span><span class="z-constant"> 2194</span><span>,</span><span class="z-constant"> 2200</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Account first access cost per block distance (1-32)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> WINDOW_SIZE_BLOCKS = 32</span></span> <span class="giallo-l"><span class="z-constant">ACCOUNT_FIRST_ACCESS_COST_LUT</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span class="z-constant"> 100</span><span>,</span><span class="z-constant"> 108</span><span>,</span><span class="z-constant"> 131</span><span>,</span><span class="z-constant"> 168</span><span>,</span><span class="z-constant"> 219</span><span>,</span><span class="z-constant"> 281</span><span>,</span><span class="z-constant"> 354</span><span>,</span><span class="z-constant"> 438</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 530</span><span>,</span><span class="z-constant"> 630</span><span>,</span><span class="z-constant"> 737</span><span>,</span><span class="z-constant"> 850</span><span>,</span><span class="z-constant"> 967</span><span>,</span><span class="z-constant"> 1088</span><span>,</span><span class="z-constant"> 1212</span><span>,</span><span class="z-constant"> 1337</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 1463</span><span>,</span><span class="z-constant"> 1588</span><span>,</span><span class="z-constant"> 1712</span><span>,</span><span class="z-constant"> 1833</span><span>,</span><span class="z-constant"> 1950</span><span>,</span><span class="z-constant"> 2063</span><span>,</span><span class="z-constant"> 2170</span><span>,</span><span class="z-constant"> 2270</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 2362</span><span>,</span><span class="z-constant"> 2446</span><span>,</span><span class="z-constant"> 2519</span><span>,</span><span class="z-constant"> 2581</span><span>,</span><span class="z-constant"> 2632</span><span>,</span><span class="z-constant"> 2669</span><span>,</span><span class="z-constant"> 2692</span><span>,</span><span class="z-constant"> 2700</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> sload_first_access_cost</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> 1</span><span class="z-keyword"> &lt;=</span><span> block_distance_in_blocks</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> SLOAD_FIRST_ACCESS_COST_LUT</span><span>[</span><span>block_distance_in_blocks</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 2200</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> fully cold</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> account_first_access_cost</span><span>(</span><span class="z-variable z-parameter z-function">block_distance_in_blocks</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> 1</span><span class="z-keyword"> &lt;=</span><span> block_distance_in_blocks</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> ACCOUNT_FIRST_ACCESS_COST_LUT</span><span>[</span><span>block_distance_in_blocks</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 2700</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> fully cold</span></span></code></pre><h2 id="rationale">Rationale</h2> <ul> <li>Determinism: discounts depend only on prior blocks, so users can predict costs at submission time. The block-level access lists in headers remove bootstrap ambiguity for new nodes. Intra-block dependent savings are inherently unknowable and non-actionable at submission, so they do not change behaviour; prior-block based savings do.</li> <li>Smooth curve: the chosen polynomial keeps strong incentive for very recent history and eases toward zero, aligning with how caches deliver benefit for temporal locality. Linear ramps are simpler but produce harsher edges.</li> <li>Window of 32: this captures longer-lived temporal locality without turning the feature into a long-term subsidy, and keeps proof and index sizes small.</li> <li>Discount not refund: reduces upfront charge only; does not change refund semantics or receipts.</li> <li>No correlation: simple to implement and reason about. The model is explicitly about last-access distance, not frequency.</li> </ul> <p>Builder rotation and similar operational concerns are out of scope for this EIP.</p> <h3 id="behavioural-effects">Behavioural effects</h3> <p>The smoothstep curve over 32 blocks is gentle. Discount remains close to maximum for roughly the first 12 to 16 blocks and decays toward zero near the far edge of the window.</p> <h4 id="storage-slot-sload-first-access-pricing">Storage slot (SLOAD) first-access pricing</h4> <p>(warm = 100, cold surcharge = 2100, window = 32)</p> <table><thead><tr><th><code>BLOCK_DISTANCE_IN_BLOCKS</code></th><th style="text-align: right">Discount</th><th style="text-align: right">Charge</th><th>Notes</th></tr></thead><tbody> <tr><td><code>1</code></td><td style="text-align: right"><code>2100</code></td><td style="text-align: right"><code>100</code></td><td>fully warm equivalent</td></tr> <tr><td><code>4</code></td><td style="text-align: right"><code>2045</code></td><td style="text-align: right"><code>155</code></td><td>almost full discount</td></tr> <tr><td><code>8</code></td><td style="text-align: right"><code>1827</code></td><td style="text-align: right"><code>373</code></td><td></td></tr> <tr><td><code>12</code></td><td style="text-align: right"><code>1494</code></td><td style="text-align: right"><code>706</code></td><td></td></tr> <tr><td><code>16</code></td><td style="text-align: right"><code>1101</code></td><td style="text-align: right"><code>1099</code></td><td>midpoint of window</td></tr> <tr><td><code>18</code></td><td style="text-align: right"><code>898</code></td><td style="text-align: right"><code>1302</code></td><td></td></tr> <tr><td><code>20</code></td><td style="text-align: right"><code>700</code></td><td style="text-align: right"><code>1500</code></td><td></td></tr> <tr><td><code>24</code></td><td style="text-align: right"><code>347</code></td><td style="text-align: right"><code>1853</code></td><td></td></tr> <tr><td><code>28</code></td><td style="text-align: right"><code>96</code></td><td style="text-align: right"><code>2104</code></td><td>near-cold</td></tr> <tr><td><code>32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2200</code></td><td>window edge</td></tr> <tr><td><code>&gt;32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2200</code></td><td>fully cold access</td></tr> </tbody></table> <h4 id="account-access-first-access-pricing">Account access first-access pricing</h4> <p>(warm = 100, cold surcharge = 2600, window = 32)</p> <table><thead><tr><th><code>BLOCK_DISTANCE_IN_BLOCKS</code></th><th style="text-align: right">Discount</th><th style="text-align: right">Charge</th><th>Notes</th></tr></thead><tbody> <tr><td><code>1</code></td><td style="text-align: right"><code>2600</code></td><td style="text-align: right"><code>100</code></td><td>fully warm equivalent</td></tr> <tr><td><code>4</code></td><td style="text-align: right"><code>2532</code></td><td style="text-align: right"><code>168</code></td><td>almost full discount</td></tr> <tr><td><code>8</code></td><td style="text-align: right"><code>2262</code></td><td style="text-align: right"><code>438</code></td><td></td></tr> <tr><td><code>12</code></td><td style="text-align: right"><code>1850</code></td><td style="text-align: right"><code>850</code></td><td></td></tr> <tr><td><code>16</code></td><td style="text-align: right"><code>1363</code></td><td style="text-align: right"><code>1337</code></td><td>midpoint of window</td></tr> <tr><td><code>18</code></td><td style="text-align: right"><code>1112</code></td><td style="text-align: right"><code>1588</code></td><td></td></tr> <tr><td><code>20</code></td><td style="text-align: right"><code>867</code></td><td style="text-align: right"><code>1833</code></td><td></td></tr> <tr><td><code>24</code></td><td style="text-align: right"><code>430</code></td><td style="text-align: right"><code>2270</code></td><td></td></tr> <tr><td><code>28</code></td><td style="text-align: right"><code>119</code></td><td style="text-align: right"><code>2581</code></td><td>near-cold</td></tr> <tr><td><code>32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2700</code></td><td>window edge</td></tr> <tr><td><code>&gt;32</code></td><td style="text-align: right"><code>0</code></td><td style="text-align: right"><code>2700</code></td><td>fully cold access</td></tr> </tbody></table> <h4 id="observations">Observations</h4> <ul> <li>Accesses 1-6 blocks apart remain effectively warm, typically under 300-400 gas total.</li> <li>Around 16 blocks (≈3.2 minutes), costs reach roughly half the cold surcharge.</li> <li>By 28-32 blocks (≈5.5-6.4 minutes, one finalisation epoch), costs are nearly cold again.</li> <li>The transition is smooth and monotone; there are no cliffs or discontinuities to game.</li> <li>Both account and storage families charge exactly the warm rate for items accessed in the immediately preceding block.</li> </ul> <p>As the discount depends only on <strong>prior blocks</strong>, users and dapps can plan around it. Unlike same-block effects, these savings are predictable: they are visible before submission and can be incorporated into automation or fee-scheduling logic.</p> <p>If an operator wants to maintain most of the discount while sending as few transactions as possible, a practical cadence for items touched repeatedly is:</p> <ul> <li>Maintain about <strong>80 percent</strong> of the maximum discount by ensuring the item is touched again within <strong>8-9 blocks</strong> (around two minutes).</li> <li>Maintain about <strong>50 percent</strong> of the maximum discount by touching again within <strong>16 blocks</strong> (half an epoch).</li> <li>Beyond roughly <strong>28 blocks</strong>, the discount fades almost entirely; by <strong>32 blocks</strong>, the access is fully cold again.</li> </ul> <p>In short, a <strong>maintenance touch every 8-12 blocks</strong> is an efficient balance: high retained discount with modest transaction frequency. Applications seeking tighter control-such as bridges, keepers, or batching relayers-can choose shorter cadences, while ordinary usage patterns will keep frequently accessed state warm naturally.</p> <p>The <strong>smooth decay curve</strong> is important. It means missing the ideal block due to a temporary spike in gas prices or unexpected congestion doesn't abruptly forfeit the entire discount-costs rise gradually, not cliff-edge. This avoids brittle strategies that depend on exact timing and makes the mechanism more forgiving in volatile network conditions.</p> <p>From a UX standpoint, humans are unlikely to act precisely within these timeframes, but automated systems can. Many popular contract surfaces-AMM reserves, token balances, or oracle feeds-stay warm simply through organic activity, letting users benefit indirectly.</p> <p>Each account or storage key's discount remains <strong>independent</strong>. Repeated touches within the window only update the item's last-access block; they do not stack or correlate across different items.</p> <h4 id="coordinated-multi-eoa-warm-up-behaviour">Coordinated multi-EOA warm-up behaviour</h4> <p>Because the temporal discount depends only on <strong>prior-block access</strong>, a coordinated actor controlling multiple EOAs or contracts can sequence transactions to capture the maximum discount. For example, a lightweight "warm-up" transaction from one EOA in block <code>N</code> can touch a set of storage keys or accounts, allowing one or more follow-up transactions in block <code>N+1</code> to execute those same accesses at <strong>warm-equivalent cost</strong>.</p> <p>This <strong>inter-block pipelining</strong> remains predictable, verifiable, and legitimate. It does not distort consensus or introduce hidden state; it simply rewards actors who cluster related work in adjacent blocks. The discount gained is bounded by the cold surcharge itself, while the overhead of coordination, additional priority fees, and builder inclusion uncertainty all limit how aggressively this pattern can be used. In practice, it is most relevant for highly automated systems-keepers, rollup bridges, or arbitrage bundles-that already coordinate sequencing across blocks.</p> <p>With the <strong>32-block window</strong>, the value of pipelining falls off much faster. Missing a single block only slightly reduces the discount because of the smooth decay curve, but missing several in a row quickly erodes it. That makes warm-ups more predictable yet self-limiting: actors can't cheaply "bank" state heat far ahead, only maintain it across a short epoch-length horizon.</p> <p>Builders and MEV searchers may still find minor advantage in chaining related operations across consecutive blocks, but this behaviour is <strong>constructive</strong>: it improves temporal locality in state access and lowers aggregate load on clients. The overall effect is a gentle nudge toward efficient state reuse, not a new coordination game.</p> <p>If desired, protocol parameters could trim the incentive surface further-for example, by setting <code>DISCOUNT_MAX_*</code> slightly below the full cold surcharge so that even <code>D = 1</code> accesses remain marginally above the intra-transaction warm price. This specification treats that as optional tuning rather than a security necessity, accepting the small and predictable incentive as a reasonable trade-off for encouraging block-to-block efficiency.</p> <h3 id="relationship-to-block-level-warming-proposals">Relationship to block-level warming proposals</h3> <p>This EIP does not introduce intra-block warming across transactions. If a block-level warming proposal is active, its semantics are unchanged. The temporal discount defined here applies only to the first access to an item in a transaction based on prior-block history.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP changes gas charging and therefore requires a hard fork. It only decreases or equalises costs for affected opcodes and does not introduce new failure modes for existing contracts. Warm and cold cost upper bounds do not increase.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li> <p><strong>Determinism and consensus safety:</strong> All discounts are derived from <em>previously committed block data</em>. No client-local or probabilistic state (like caches or heuristics) affects consensus. Any node-stateless or fully synced-can price gas deterministically using the current block and the prior <code>WINDOW_SIZE_BLOCKS</code> access-list commitments. This preserves verifiability and supports stateless validation with compact proofs referencing recent blocks only.</p> </li> <li> <p><strong>Index growth and memory bounds:</strong> Clients must maintain a rolling index of recently accessed items. With a 32-block window, memory use scales with the number of distinct first-accessed items per block-bounded by the block gas limit divided by the minimum per-item cost. This fits comfortably within existing cache budgets, and entries naturally expire as blocks advance.</p> </li> <li> <p><strong>Reorg handling:</strong> Reorgs shorter than the window are cheap to recompute: nodes rebuild the index from the new canonical access lists. Longer reorgs fall back to initial resync behaviour. No historical transaction replay is required. Because discounts depend on committed data only, there is no ambiguity or consensus divergence across reorgs.</p> </li> <li> <p><strong>Abuse and incentive surface:</strong> The design intentionally makes "warm-up" transactions unprofitable. Since the maximum discount equals the cold surcharge, warming a slot in block <em>N</em> and using it in <em>N+1</em> costs slightly <em>more</em> than a single cold access (e.g. <code>2200 + 100 &gt; 2200</code>). Thus there is no economic gain from spamming to maintain heat. The smooth decay curve further discourages exact-block timing games: adjacent blocks differ by only a handful of gas units at small distances.</p> </li> <li> <p><strong>Economic neutrality:</strong> The mechanism reduces <em>average</em> per-access cost but leaves <em>worst-case</em> costs unchanged. Builders and block producers still target the same gas limit under EIP-1559, so total basefee burn and priority-fee dynamics remain stable. The network simply fits more real execution into the same gas target, improving efficiency without altering incentives for congestion or inclusion.</p> </li> <li> <p><strong>Stateless compatibility:</strong> Earlier multi-block warming ideas were considered incompatible with stateless validation because pricing depended on uncommitted or ephemeral state. By tying discounts to BAL commitments, this proposal makes the pricing rule provable and verifiable. Stateless verifiers need only one compact proof of inclusion in a recent BAL-no historical execution replay, no private cache dependency.</p> </li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Renaud Duboishttps://github.com/rdubois-crypto Simon Massonhttps://github.com/simonmasson Antonio Sansohttps://github.com/asanso Marius van der Wijdenhttps://github.com/mariusvanderwijden Kevaundray Wedderburnhttps://github.com/kevaundray Zhenfei Zhanghttps://github.com/zhenfeizhang Nicolas Consignyhttps://github.com/nconsigny https://wg-eips.ritovision.com/8052/

Proposal to add a precompiled contract that performs signature verifications using the Falcon signature scheme.

<h2 id="abstract">Abstract</h2> <p>This proposal creates a precompiled contract that performs signature verifications using the Falcon-512 signature scheme by given parameters of the message hash, signature, and public key. This allows any EVM chain -- principally Ethereum roll-ups -- to integrate this precompiled contract easily.</p> <p>The signature scheme can be instantiated in two version:</p> <ul> <li>Falcon, the standard signature scheme, fully compliant with the algorithm recommended by the NIST,</li> <li>An EVM-friendly version where the hash function is efficiently computed in the Ethereum Virtual Machine.</li> </ul> <p>Three precompiled contracts are specified (formerly called <code>ETH_HASH_TO_POINT</code> / <code>HASH_TO_POINT_ETH</code> in drafts):</p> <ul> <li><code>FALCON_HASH_TO_POINT_SHAKE256</code> — NIST-compliant Hash-to-Point using SHAKE256.</li> <li><code>FALCON_HASH_TO_POINT_KECCAKPRNG</code> — EVM-friendly Hash-to-Point using a Keccak-based XOF/PRNG.</li> <li><code>FALCON_CORE</code> — the core algorithm of Falcon, that verifies the signature from the obtained (HashToPoint) challenge.</li> </ul> <h2 id="motivation">Motivation</h2> <p>Quantum computers pose a long-term risk to classical cryptographic algorithms. In particular, signature algorithms based on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) such as secp256k1, are widely used in Ethereum and threaten by quantum algorithms. This exposes potentially on-chain assets and critical infrastructure to quantum adversaries.</p> <p>Integrating post-quantum signature schemes is crucial to future-proof Ethereum and other EVM-based environments. It shall be noted that infrastructure for post-quantum signatures should be deployed <em>before</em> quantum adversaries are known to be practical because it takes on the order of years for existing applications to integrate.</p> <p>Falcon, a lattice-based scheme standardized by NIST, offers high security against both classical and quantum adversaries. Its compact signature size (666 bytes for Falcon-512) and its efficient verification algorithm make it well-suited for blockchain applications, where gas usage and transaction throughput are critical considerations.</p> <!-- When the public key is also stored together with the signature, it leads to 666 + 896 = 1562 bytes. Using the recovery mode, it can be reduced to 1292 + 32 = 1324 bytes. --> <!-- For Falcon, σ=666 (40 bytes of salt, ~626 bytes for s2) pk = 896, TOTAL=1562 For FalconRec, σ=1292 (40 bytes of salt, ~626 bytes for s1, ~626 bytes for s2), pk = 32, TOTAL=1324 --> <p>In the context of the Ethereum Virtual Machine, a precompile for Keccak256 hash function is already available, making Falcon verification much faster when instantiated with an extendable output function derived from Keccak than with SHAKE256, as specified in NIST submission. This EIP specifies a split of the signature verification into two sub procedures:</p> <ul> <li><code>FALCON_HASH_TO_POINT_SHAKE256</code> or <code>FALCON_HASH_TO_POINT_KECCAKPRNG</code>, instantiated with a different extendable Output Function: the first with SHAKE256 (as recommended by NIST), the second with Keccak-PRNG (a version that is more efficient when computed in the EVM). In the future, it is possible to define it for SNARK/STARK circuits. An appropriated hash function choice reduces drastically the circuit size and the proving time in the context of ZK applications.</li> <li><code>FALCON_CORE</code>, that does not require any hash computation. This sub-algorithm follows the NIST recommendation so that: <ul> <li>using the SHAKE256 <code>FALCON_HASH_TO_POINT_SHAKE256</code>, the signature is fully compliant with the NIST standard,</li> <li>using the KeccakPRNG <code>FALCON_HASH_TO_POINT_KECCAKPRNG</code>, the verification can be efficient even in the EVM.</li> </ul> </li> </ul> <p>Using this separation, two important features are provided: one version being fully compliant with the NIST specification, the other deviating from the standard in order to reduce the gas cost, and opening up to possible computations of Falcon signature ZK proofs.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Falcon can be instantiated with polynomials of degree $512$ or $1024$, leading to a different security level. Falcon-512 is chosen, leading to a security level equivalent to RSA2048. This setting leads to the following size for signatures and keys:</p> <table><thead><tr><th>Parameter</th><th>Falcon</th></tr></thead><tbody> <tr><td><strong>n</strong> (lattice dimension)</td><td><code>512</code></td></tr> <tr><td><strong>q</strong> (modulus)</td><td><code>12289</code></td></tr> <tr><td>Padded signature size</td><td><code>666</code> bytes</td></tr> <tr><td>Public Key size</td><td><code>896</code> bytes</td></tr> <tr><td>Private key size</td><td><code>1281</code> bytes</td></tr> </tbody></table> <p>From a high level, a signature verification can be decomposed in two steps:</p> <ul> <li>The <strong>challenge computation</strong>, that involves the message and the salt, and computes a challenge polynomial using a XOF (instantiated with SHAKE256 and a Keccak-base PRNG here),</li> <li>The <strong>core algorithm</strong>, that compute polynomial arithmetic (with the challenge, the public key and the signature), and finally verify the shortness of the full signature $(s_1,s_2)$.</li> </ul> <p>The following pseudo-code highlights how these two algorithms are involved in a Falcon verification, and how the modularity of the challenge computation opens up to two version of Falcon:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> falcon512_verify</span><span>(</span><span class="z-variable z-parameter z-function">message</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> pubkey</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verify a Falcon Signature following NIST standard</span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> message (bytes): The message to sign.</span></span> <span class="giallo-l"><span class="z-string"> signature (666 bytes): The signature containing 40 bytes of salt and 626 bytes of compressed signature.</span></span> <span class="giallo-l"><span class="z-string"> pubkey (bytes): The Falcon public key.</span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> bool: True if the signature is valid, False otherwise.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Compute the Hash To Point Challenge (see 3.1.)</span></span> <span class="giallo-l"><span> challenge</span><span class="z-keyword"> =</span><span> HASH_TO_POINT</span><span>(</span><span>message</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Verify Falcon Core Algorithm (see 3.2.)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> FALCON_CORE</span><span>(</span><span>signature</span><span>,</span><span> pubkey</span><span>,</span><span> challenge</span><span>)</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> ethfalcon512_verify</span><span>(</span><span class="z-variable z-parameter z-function">message</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> pubkey</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verify a Falcon Signature (EVM-friendly mode)</span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> message (bytes): The message to sign.</span></span> <span class="giallo-l"><span class="z-string"> signature (666 bytes): The signature containing 40 bytes of salt and 626 bytes of compressed signature.</span></span> <span class="giallo-l"><span class="z-string"> pubkey (bytes): The Falcon public key.</span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> bool: True if the signature is valid, False otherwise.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Compute the Hash To Point Challenge (see 3.1.)</span></span> <span class="giallo-l"><span> challenge</span><span class="z-keyword"> =</span><span> ETH_HASH_TO_POINT</span><span>(</span><span>message</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Verify Falcon Core Algorithm (see 3.2.)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> FALCON_CORE</span><span>(</span><span>signature</span><span>,</span><span> pubkey</span><span>,</span><span> challenge</span><span>)</span></span></code></pre> <p>The functions <code>falcon512_verify</code> and <code>ethfalcon512_verify</code> call the precompiles specified in the next sections: <code>FALCON_HASH_TO_POINT_SHAKE256</code>, <code>FALCON_HASH_TO_POINT_KECCAKPRNG</code> and <code>FALCON_CORE</code>.</p> <h3 id="hash-to-point-challenge-normative">Hash-to-Point challenge (normative)</h3> <ol> <li><strong>Parse Input Data:</strong> Check the byte sizes and then extract the message and the signature. The parsed signature is a tuple of values $(r, s_2)$. $r$ is denoted as the salt and contains bytes, and $s_2$ is denoted as the signature vector, a vector of elements mod $q$.</li> <li><strong>Verify Well-formedness:</strong> Verify that the signature contains a 40-byte salt $r$.</li> </ol> <!-- See the `Required Checks in Verification` section for more details. --> <ol start="3"> <li><strong>Compute the challenge $c$:</strong> the challenge is obtained from hash-to-point on the salt $r$ of the signature and the message. The output $c$ is a polynomial of degree 512, stored in 896 bytes. The hash-to-point function computes extendable Output from a hash Function (XOF). This EIP provides two instantiations of a XOF: <ul> <li> <p>SHAKE256 is the XOF provided in NIST submission, a sponge construction derived from SHA256. Extracting bytes using SHAKE256 calls the <code>Keccak_f</code> permutation:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> SHAKE256_init</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> create</span><span> an</span><span> empty</span><span> sponge</span><span> state</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> SHAKE256_inject</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> absorb</span><span> into</span><span> Keccak</span><span> sponge</span><span> state</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> SHAKE256_flip</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> pad</span><span class="z-support"> input</span><span class="z-keyword"> and</span><span> finalize</span><span> sponge</span></span> <span class="giallo-l"><span> (</span><span>no</span><span> fixed</span><span class="z-keyword">-</span><span>length</span><span> digest</span><span> yet</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> SHAKE256_extract</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>,</span><span class="z-variable z-parameter z-function"> length</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> output</span><span>.</span><span>size</span><span class="z-keyword"> &lt;</span><span> length</span><span>:</span></span> <span class="giallo-l"><span> block</span><span class="z-keyword"> =</span><span> Keccak_f</span><span>(</span><span>state</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> apply permutation</span></span> <span class="giallo-l"><span> output</span><span>.</span><span>append</span><span>(</span><span>state_part</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> take r-bit &quot;rate&quot; portion</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> first</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">length</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-support"> bytes</span><span> of</span><span> output</span></span></code></pre> <p>While this construction is standardized, it is expensive when computed in the Ethereum Virtual Machine because <code>Keccak_f</code> has no EVM opcode.</p> </li> <li> <p>Keccak-PRNG is a XOF that is build from a counter-mode PRNG based on Keccak256. Generating new chunks of bytes requires an incrementing counter.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> KeccakPRNG_init</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> create</span><span> an</span><span> empty</span><span> buffer</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> KeccakPRNG_inject</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> buffer</span><span>.</span><span>append</span><span>(</span><span>data</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> KeccakPRNG_flip</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state</span><span class="z-keyword"> =</span><span> Keccak256</span><span>(</span><span>buffer</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> fixed 32-byte state</span></span> <span class="giallo-l"><span> counter</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> KeccakPRNG_extract</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>,</span><span class="z-variable z-parameter z-function"> length</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> counter</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> output</span><span>.</span><span>size</span><span class="z-keyword"> &lt;</span><span> length</span><span>:</span></span> <span class="giallo-l"><span> block</span><span class="z-keyword"> =</span><span> Keccak256</span><span>(</span><span>state</span><span class="z-invalid z-illegal"> ||</span><span> counter</span><span>)</span></span> <span class="giallo-l"><span> output</span><span>.</span><span>append</span><span>(</span><span>block</span><span>)</span></span> <span class="giallo-l"><span> counter</span><span class="z-keyword"> =</span><span> counter</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> first</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">length</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-support"> bytes</span><span> of</span><span> output</span></span></code></pre> <p>Precompile of <code>Keccak256</code> are available in the Ethereum Virtual Machine, making this XOF very efficient in the EVM.</p> </li> </ul> </li> </ol> <p>Using one of the XOFs above (SHAKE256 or Keccak-PRNG), it is possible to instantiate two (precompiles) algorithms for hashing into points:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> FALCON_HASH_TO_POINT_SHAKE256</span><span>(</span><span class="z-variable z-parameter z-function">message</span><span>:</span><span> bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Compute the Hash To Point Falcon Challenge.</span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> message (bytes32): The original message (hash).</span></span> <span class="giallo-l"><span class="z-string"> signature (666 bytes): containing:</span></span> <span class="giallo-l"><span class="z-string"> - r (40 bytes): The salt.</span></span> <span class="giallo-l"><span class="z-string"> - s (626 bytes): The compressed signature vector.</span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> c: The Hash To Point polynomial challenge as a vector.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Constants</span></span> <span class="giallo-l"><span> q</span><span class="z-keyword"> =</span><span class="z-constant"> 12289</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon modulus</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 1: Parse Input Data</span></span> <span class="giallo-l"><span> r</span><span>,</span><span> s2_compressed</span><span class="z-keyword"> =</span><span> signature</span><span>[</span><span>:</span><span class="z-constant">40</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">40</span><span>:</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract salt and compressed signature vector</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 2: Verify Well-formedness</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_signature_format</span><span>(</span><span>s2_compressed</span><span>,</span><span> pubkey</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 3: Compute the challenge vector HashToPoint(r || message)</span></span> <span class="giallo-l"><span> c</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>n</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> SHAKE256_init</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> SHAKE256_inject</span><span>(</span><span>r</span><span class="z-keyword">+</span><span>message</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> i</span><span class="z-keyword"> &lt;</span><span> n</span><span> do</span></span> <span class="giallo-l"><span> t</span><span class="z-keyword"> =</span><span> SHAKE256_extract</span><span>(</span><span class="z-constant">2</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> t</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 61445</span><span> then</span></span> <span class="giallo-l"><span> c_i</span><span class="z-keyword"> =</span><span> t</span><span> mod</span><span> q</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span> i</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> c</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> FALCON_HASH_TO_POINT_KECCAKPRNG</span><span>(</span><span class="z-variable z-parameter z-function">message</span><span>:</span><span> bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Compute the Hash To Point Falcon Challenge using Keccak-PRNG.</span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> message (bytes32): The original message (hash).</span></span> <span class="giallo-l"><span class="z-string"> signature (666 bytes): containing:</span></span> <span class="giallo-l"><span class="z-string"> - r (40 bytes): The salt.</span></span> <span class="giallo-l"><span class="z-string"> - s (626 bytes): The compressed signature vector.</span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> c: The Hash To Point polynomial challenge as a vector.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Constants</span></span> <span class="giallo-l"><span> q</span><span class="z-keyword"> =</span><span class="z-constant"> 12289</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon modulus</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 1: Parse Input Data</span></span> <span class="giallo-l"><span> r</span><span>,</span><span> s2_compressed</span><span class="z-keyword"> =</span><span> signature</span><span>[</span><span>:</span><span class="z-constant">40</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">40</span><span>:</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract salt and compressed signature vector</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 2: Verify Well-formedness</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_signature_format</span><span>(</span><span>s2_compressed</span><span>,</span><span> pubkey</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 3: Compute the challenge vector HashToPoint(r || message)</span></span> <span class="giallo-l"><span> c</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>n</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> KeccakPRNG_init</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> KeccakPRNG_inject</span><span>(</span><span>r</span><span class="z-keyword">+</span><span>message</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> i</span><span class="z-keyword"> &lt;</span><span> n</span><span> do</span></span> <span class="giallo-l"><span> t</span><span class="z-keyword"> =</span><span> KeccakPRNG_extract</span><span>(</span><span class="z-constant">2</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> t</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 61445</span><span> then</span></span> <span class="giallo-l"><span> c_i</span><span class="z-keyword"> =</span><span> t</span><span> mod</span><span> q</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span> i</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> c</span></span></code></pre><h4 id="encoding-of-the-challenge-polynomial-c-896-bytes-normative">Encoding of the challenge polynomial <code>c</code> (896 bytes, normative)</h4> <ul> <li>Domain: degree-512 polynomial with coefficients in <code>[0, q)</code>, <code>q = 12289</code>.</li> <li>Order: coefficients are serialized in index order <code>c[0], c[1], …, c[511]</code>.</li> <li>Bit-packing: each coefficient is a 14-bit <strong>big-endian</strong> unsigned integer. Concatenate all 512 encodings into a bitstring of exactly <strong>896 bytes</strong>. Consumers MUST reject encodings that are not exactly 896 bytes.</li> </ul> <h3 id="core-algorithm">Core algorithm</h3> <ol> <li><strong>Parse Input Data:</strong> Check the byte sizes and then extract the public key, the Hash To Point Challenge and the signature. <ul> <li>The parsed public key $h$, interpreted as a vector of elements mod $q$,</li> <li>The parsed signature $(r, s_2)$. $r$ is denoted as the salt and $s_2$ is denoted as the signature vector, made of elements mod $q$.</li> </ul> </li> <li><strong>Verify Well-formedness:</strong> Verify that the signature, Hash To Point Challenge and public key have the correct number of elements and is canonical.</li> </ol> <!-- See the `Required Checks in Verification` section for more details. --> <ol start="3"> <li> <p><strong>Compute $s_1$ from $s_2$ and $h$.</strong> $s_1 = c - h * s_2$ where:</p> <ul> <li>$c$ is the Hash To Point challenge,</li> <li>$h$ is the public key, represented in the ntt domain</li> <li>$s_2$ is the signature vector.</li> </ul> <blockquote> <p>Note: since $h$ and $s_2$ are polynomials, the operation $*$ is the polynomial multiplication and can be sped up using the Number Theoretic Transform (NTT).</p> </blockquote> </li> <li> <p><strong>Check $L^2$ norm Bound:</strong> Verify that the signature is <em>short</em> by checking the following equation: $$ ||(s_1, s_2) ||_2^2 &lt; \lfloor\beta^2\rfloor$$ where $\beta^2$ is the acceptance bound. For Falcon-512, it is $\lfloor\beta^2\rfloor = 34034726$.</p> </li> </ol> <p>The following code illustrates Falcon core algorithm:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> FALCON_CORE</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> h</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> challenge</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verify Falcon Core Algorithm</span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> - signature (666 bytes): containing:</span></span> <span class="giallo-l"><span class="z-string"> - r (40 bytes): The salt.</span></span> <span class="giallo-l"><span class="z-string"> - s (626 bytes): The compressed signature vector.</span></span> <span class="giallo-l"><span class="z-string"> - h (bytes): The Falcon public key in the ntt domain, computed as h=ntt(pubkey) externally.</span></span> <span class="giallo-l"><span class="z-string"> - challenge (bytes): The Falcon Hash To Point Challenge.</span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> bool: True if the signature is valid, False otherwise.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Constants</span></span> <span class="giallo-l"><span> q</span><span class="z-keyword"> =</span><span class="z-constant"> 12289</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon modulus</span></span> <span class="giallo-l"><span class="z-constant"> ACCEPTANCE_BOUND</span><span class="z-keyword"> =</span><span class="z-constant"> 34034726</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon-512 acceptance bound</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 1: Parse Input Data</span></span> <span class="giallo-l"><span> r</span><span>,</span><span> s2_compressed</span><span class="z-keyword"> =</span><span> signature</span><span>[</span><span>:</span><span class="z-constant">40</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">40</span><span>:</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extract salt and compressed signature vector</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 2: Verify Well-formedness</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_signature_format</span><span>(</span><span>s2_compressed</span><span>,</span><span> pubkey</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 3: Decompress Signature Vector</span></span> <span class="giallo-l"><span> s2</span><span class="z-keyword"> =</span><span> decompress</span><span>(</span><span>s2_compressed</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Convert compressed signature to full form</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> s2</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Reject invalid encodings </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 4: Convert to Evaluation domain (NTT)</span></span> <span class="giallo-l"><span> s2_ntt</span><span class="z-keyword"> =</span><span> ntt</span><span>(</span><span>s2</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 5: Compute the Verification Equation</span></span> <span class="giallo-l"><span> tmp_ntt</span><span class="z-keyword"> =</span><span> hadamard_product</span><span>(</span><span>s2_ntt</span><span>,</span><span> h</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Element-wise product</span></span> <span class="giallo-l"><span> tmp</span><span class="z-keyword"> =</span><span> intt</span><span>(</span><span>tmp_ntt</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Convert back to coefficient form (INTT)</span></span> <span class="giallo-l"><span> s1</span><span class="z-keyword"> =</span><span> challenge</span><span class="z-keyword"> -</span><span> tmp</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 6: Normalize s1 coefficients to be in the range [-q/2, q/2]</span></span> <span class="giallo-l"><span> s1</span><span class="z-keyword"> =</span><span> normalize_coefficients</span><span>(</span><span>s1</span><span>,</span><span> q</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 7: Compute Norm Bound Check</span></span> <span class="giallo-l"><span> s1_squared</span><span class="z-keyword"> =</span><span> square_each_element</span><span>(</span><span>s1</span><span>)</span></span> <span class="giallo-l"><span> s2_squared</span><span class="z-keyword"> =</span><span> square_each_element</span><span>(</span><span>s2</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> total_norm</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>s1_squared</span><span>)</span><span class="z-keyword"> +</span><span class="z-support"> sum</span><span>(</span><span>s2_squared</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Step 8: Compare with Acceptance Bound</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> To ensure signature is short</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> total_norm</span><span class="z-keyword"> &lt;</span><span class="z-constant"> ACCEPTANCE_BOUND</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon-512: β² = 34,034,726</span></span></code></pre><h3 id="required-checks-in-falcon-verification">Required Checks in Falcon Verification</h3> <p>The following requirements MUST be checked by the precompiled contract to verify signature components are valid:</p> <p><strong>Raw Input data</strong></p> <ul> <li>Verify that the message is 32-bytes long,</li> <li>Verify that the public key is 896-bytes long,</li> <li>Verify that the signature is 666-bytes long.</li> </ul> <p><strong>Parsed Input data</strong></p> <ul> <li>Verify that the public key consists of 512 elements, where each element is between $[0, q-1]$,</li> <li>Verify that the signature vector in the signature consists of 512 elements, where each element is between $[0, q-1]$,</li> <li>Verify that the salt in the signature is 40-bytes long.</li> </ul> <p><strong>Gas burning on error</strong> if one of the above condition is not met then all the gas supplied along with a CALL or STATICCALL is burned. it shall also be burned if an error happens during decompression (incorrect encodings).</p> <h3 id="precompiled-contract-specification">Precompiled Contract Specification</h3> <p>The precompiled contracts are proposed with the following input and outputs, which are big-endian values:</p> <h4 id="falcon-hash-to-point-shake256"><code>FALCON_HASH_TO_POINT_SHAKE256</code></h4> <p><strong>Input</strong></p> <ul> <li>32 bytes: message hash <code>m</code>,</li> <li>666 bytes: salt <code>r</code> (40 bytes), Falcon-512 compressed signature <code>s2_compressed</code> (626 bytes) concatenated: <code>r || s2_compressed</code>.</li> </ul> <p><strong>Output</strong></p> <ul> <li>896 bytes: packed challenge polynomial <code>c</code> (see §3.1 encoding)</li> </ul> <h4 id="falcon-hash-to-point-keccakprng"><code>FALCON_HASH_TO_POINT_KECCAKPRNG</code></h4> <p>Same I/O as §4.1, but the XOF is Keccak-PRNG. The construction is normative and MUST define: state initialization, domain-separation (if any), counter width and endianness, and block concatenation order.</p> <h4 id="falcon-core"><code>FALCON_CORE</code></h4> <ul> <li><strong>Input data</strong> <ul> <li>666 bytes for Falcon-512 signature</li> <li>896 bytes for Falcon-512 public key</li> <li>896 bytes for the Hash To Point Challenge</li> </ul> </li> <li><strong>Output data</strong>: <ul> <li>If the core algorithm process succeeds, it returns 1 in 32 bytes format.</li> <li>If the core algorithm process fails, it does not return any output data.</li> </ul> </li> </ul> <h4 id="error-cases">Error Cases</h4> <ul> <li>Invalid input length (not compliant to described input)</li> <li>Invalid field element encoding (≥ q)</li> <li>Invalid signature decompression</li> </ul> <p>Note that a well-formed but invalid signature does not produce an error, but <code>FALCON_CORE</code> invalidates the signature (and it does not return any output data).</p> <h4 id="precompiled-contract-gas-usage">Precompiled Contract Gas Usage</h4> <p>The cost of the <strong>FALCON_HASH_TO_POINT_SHAKE256</strong> and <strong>FALCON_HASH_TO_POINT_KECCAKPRNG</strong> is set to 1000 gas.</p> <p>The cost of <strong>FALCON_CORE</strong> is set to 2000 gas.</p> <p>Thus, the total cost of the signature is 3000 gas.</p> <h2 id="rationale">Rationale</h2> <p>The Falcon signature scheme was selected as a NIST-standardized post-quantum cryptographic algorithm due to its strong security guarantees and efficiency.</p> <p>Falcon is a signature algorithm build from lattice-based cryptography. Specifically, its hardness relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is believed to be hard for both classical and quantum computers.</p> <p>Falcon offers several advantages over traditional cryptographic signatures such as secp256k1 and secp256r1:</p> <ul> <li><strong>Efficiency</strong>: Falcon is highly optimized for constrained environments, offering small signature sizes (666 bytes for Falcon-512) and fast verification time. This makes it well-suited for Ethereum, where gas costs and computational efficiency are critical factors.</li> <li><strong>NIST Standardization</strong>: Falcon was selected as part of NIST Post-Quantum Cryptography Standardization process, ensuring that it meets rigorous security and performance criteria.</li> <li><strong>Enabling Future-Proof Smart Contracts</strong>: With the integration of Falcon, Ethereum roll-ups and smart contract applications can start adopting quantum-secure schemes that remain secure even when we have quantum computers.</li> <li><strong>Compatibility with Existing EVM Designs</strong>: While Falcon operates on fundamentally different cryptographic assumptions than elliptic curves, its verification process can be efficiently implemented as a precompiled contract with similar APIs to classical signature schemes like secp256r1.</li> </ul> <p>Given the increasing urgency of transitioning to quantum-resistant cryptographic primitives or even having them ready in the event that research into quantum computers speeds up.</p> <h3 id="gas-cost-explanations">Gas cost explanations</h3> <p>The cost of the <strong>HASH_TO_POINT</strong> and <strong>HASH_TO_POINT_ETH</strong> functions is dominated by the call to the underlying hash function. It represents in average 35 calls to the hash function. Taking linearly the cost of keccak256, and avoiding the context switching it represents 1000 gas.</p> <p>The cost of <strong>FALCON_CORE</strong> function is dominated by performing 2 NTTs and 1 inverse NTT. One of these NTTs is for the public key and can be precomputed so that the contract requires to perform only 1 NTT and 1 inverse NTT. An estimation of the cost is given by 2000 gas.</p> <p>The cost is interpolated using rule of thumb from SUPERCOPS signatures benchmark results.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>In compliance with <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>, the necessary parameters and structure for its integration are provided. <code>ALG_TYPE = 0xFA</code> uniquely identifies Falcon-512 transactions, set MAX_SIZE = 667 bytes to accommodate the fixed-length signature_info container (comprising a 1-byte version tag and a 666-byte Falcon signature), and recommend a <code>GAS_PENALTY</code> of approximately <code>3000</code> gas subject to benchmarking. The verification function follows the EIP-7932 model, parsing the signature_info, recovering the corresponding Falcon public key, verifying the signature against the transaction payload hash, and deriving the signer's Ethereum address as the last 20 bytes of keccak256(pubkey). This definition ensures that Falcon-512 can be cleanly adopted within the <code>AlgorithmicTransaction</code> container specified by EIP-7932.</p> <p>As per <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>, this EIP defines two Falcon algorithm types:</p> <ul> <li><code>ALG_TYPE = 0xFA</code> — Falcon-512 with SHAKE256 H2P</li> <li><code>ALG_TYPE = 0xFB</code> — Falcon-512 with Keccak-PRNG H2P</li> </ul> <p><strong>Container and sizes.</strong> The <code>signature_info</code> container omits any pubkey hash; the public key is recovered by <code>verify(...)</code> and the 7932 sig-recover precompile derives the address as <code>keccak(ALG_TYPE || pubkey)[12:]</code>. Therefore:</p> <ul> <li><code>MAX_SIZE = 667</code> bytes (1-byte <code>ALG_TYPE</code> + 666-byte Falcon compressed signature).</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>signature_info</span><span class="z-keyword"> =</span><span> Container</span><span>[</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0xFA Falcon-512 (SHAKE H2P), 0xFB Falcon-512 (Keccak H2P)</span></span> <span class="giallo-l"><span> version</span><span>:</span><span> uint8</span><span>,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Falcon-512 signature (compressed). If an implementation produces a shorter form, it MUST be left-padded to 666 bytes.</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> ByteVector</span><span>[</span><span class="z-constant">666</span><span>]</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>In the format of <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>:</p> <ul> <li> <p>For the NIST-compliant version:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>verify</span><span>(</span><span>signature_info</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span> payload_hash</span><span>:</span><span> Hash32</span><span>)</span><span class="z-invalid z-illegal"> -&gt;</span><span> ExecutionAddress</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature_info</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 699</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">667</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> version</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">FA</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> lookup_pubkey</span><span>(</span><span>pubkey_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> falcon512_verify</span><span>(</span><span>pubkey</span><span>,</span><span> signature</span><span>,</span><span> payload_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionAddress</span><span>(</span><span>keccak256</span><span>(</span><span>pubkey</span><span>)</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span>)</span></span></code></pre></li> <li> <p>For the EVM-friendly version:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>verify</span><span>(</span><span>signature_info</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span> payload_hash</span><span>:</span><span> Hash32</span><span>)</span><span class="z-invalid z-illegal"> -&gt;</span><span> ExecutionAddress</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature_info</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 699</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">667</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> version</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">FB</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> lookup_pubkey</span><span>(</span><span>pubkey_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> ethfalcon512_verify</span><span>(</span><span>pubkey</span><span>,</span><span> signature</span><span>,</span><span> payload_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionAddress</span><span>(</span><span>keccak256</span><span>(</span><span>pubkey</span><span>)</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span>)</span></span></code></pre></li> </ul> <h3 id="addresses">Addresses</h3> <!-- TODO: backward compatibility --> <p><strong>TBD by ACD.</strong> Final precompile addresses will be selected within the EIP-managed range of <a href="https://wg-eips.ritovision.com/1352/">EIP-1352</a>, explicitly <strong>avoiding <code>0x0100–0x01FF</code> reserved for RIPs</strong> by <a href="https://wg-eips.ritovision.com/7587/">EIP-7587</a>.</p> <h2 id="test-cases">Test Cases</h2> <p>A set of test vectors for verifying implementations is located in a separate file (to be provided for each opcode). For the NIST compliant version, KATs are reproduced for HashToPoint (with a provided salt <code>r</code>) as well as for the compressed signature vector s2 (with a provided <code>HashToPoint</code> input). Note that <code>s2</code> is not padded with zeroes, leading to a maximum size of 626 bytes.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>An implementation is provided by the NIST. An implementation of the EVM-friendly version ETHFALCON is provided by ZKNOX.</p> <p><strong>TODO: We can modify geth to include falcon-512 as a reference. (Similar to secp256r1 signature verification)</strong></p> <h2 id="security-considerations">Security Considerations</h2> <p>The derivation path to obtain the private key from the seed is (tbd). Hash-to-Point functions MUST follow the specified XOFs byte-for-byte; domain separation and padding are normative.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-17T00:00:00+00:00 2026-02-11T14:49:28+00:00 Maria Silvahttps://github.com/misilva73 https://wg-eips.ritovision.com/8053/

Adds `milli-gas` as the EVM’s internal gas accounting unit, reducing rounding errors without impacting UX

<h2 id="abstract">Abstract</h2> <p>This proposal introduces the <code>milli-gas</code> counter as the EVM's internal gas accounting. Gas costs are defined in <code>milli_gas</code> and internal EVM gas accounting is entirely carried out in <code>milli_gas</code>. At the end of transaction execution, <code>milli_gas</code> is rounded up to <code>gas</code>. Gas limits and transaction fees are still computed and verified using the current <code>gas_used</code> counter. This new counter enables a more precise accounting of cheap compute without impacting UX.</p> <h2 id="motivation">Motivation</h2> <p>Currently, most EVM compute operations (<code>ADD</code>, <code>SUB</code>, <code>MUL</code>, etc.) are significantly underpriced when compared with state operations (<code>SSTORE</code>, <code>SLOAD</code>, <code>CREATE</code>, etc.). There are two factors contributing to this mismatch. On one hand, client optimizations and hardware improvements have made pure compute operations more efficient. On the other hand, with the growing size of the Ethereum state, the performance of I/O operations touching this larger state has been deteriorating. Both of these trends are expected to continue, further worsening this mismatch.</p> <p>There are a couple of proposals to reduce the cost of compute operations (<a href="https://wg-eips.ritovision.com/7904/">EIP-7904</a>) and increase the cost of state operations (<a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>, <a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a>, and <a href="https://wg-eips.ritovision.com/8038/">EIP-8038</a>). However, given the current level of mismatch between these operations, there is an inherent trade-off in the anchor we use to reprice these operations.</p> <p>If we make compute operations cheaper, we will introduce rounding errors, with most compute operations costing 1, when they should cost a fraction of that. These rounding errors impact scalability because we can now fit fewer of these cheaper operations in any given block. However, if we price all operations so that the fastest opcode is assigned 1 gas, we would need to make all other operations significantly more expensive, including both compute and state operations. Making everything more expensive would require a rebase on the concept of gas units to users, thus impacting UX.</p> <p>To illustrate this point, let's focus on the pure compute operations. As compute operations impact only block execution time, the chosen anchor will induce a specific million gas per second rate on all compute opcodes. For instance, if we anchor on <code>EcRecover</code> at the current price (3000 gas units), this induces a rate of 175Mgas/s, based on the execution time estimated for this opcode on <a href="../07904/assets/gas-cost-estimator-report.pdf">EIP-7904's empirical analysis</a>. The following plot shows the average rounding errors of compute operations for different anchors, using the same execution time estimates from EIP-7904.</p> <p><img src="https://wg-eips.ritovision.com/8053/./assets/round_error_by_anchor.png" alt="round_error_by_anchor" /></p> <p>As we can see, with an anchor of 50Mgas/s (which would result in a gas limit of 100Mgas, assuming a 2-second block execution limit), we would get an average rounding error of 59.3%. This means that we could be 59.3% cheaper on average per opcode if we didn't have to round to integer gas units. Only after a 400Mgas/s anchor do we get to reasonably low rounding errors. However, this level of Mgas/s would require a major rebase of the gas model, where all opcodes become significantly more expensive, and both the transaction-level and block-level gas limits increase by a factor of 100.</p> <p>The way around this trade-off is to allow cheap opcodes to have fractional gas costs, thus avoiding both the scalability limits introduced by rounding errors and the significant UX change of increasing gas costs and limits 100x.</p> <p>A similar argument was made in <a href="https://wg-eips.ritovision.com/2045/">EIP-2045</a>, which served as inspiration to this proposal.</p> <h2 id="specification">Specification</h2> <p>This proposal introduces a new <code>Uint</code> counter to the EVM, <code>milli_gas_left</code>. Gas costs are defined in <code>milli_gas</code> and internal EVM gas accounting is entirely carried out in <code>milli_gas</code>.</p> <p>Transaction fees, transaction gas limits, and block gas limits are still computed and verified using the current <code>gas_used</code> counter. There are no changes to blob gas accounting, refunds, or call data gas accounting.</p> <h3 id="evm-environment">EVM environment</h3> <p>The current <code>gas_left</code> variable from the internal state of the EVM is replaced by <code>milli_gas_left</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Evm</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">The internal state of the virtual machine.</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span> pc</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> stack</span><span>:</span><span> List</span><span>[</span><span>U256</span><span>]</span></span> <span class="giallo-l"><span> memory</span><span>:</span><span class="z-support"> bytearray</span></span> <span class="giallo-l"><span> code</span><span>:</span><span> Bytes</span></span> <span class="giallo-l"><span> milli_gas_left</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> valid_jump_destinations</span><span>:</span><span> Set</span><span>[</span><span>Uint</span><span>]</span></span> <span class="giallo-l"><span> logs</span><span>:</span><span> Tuple</span><span>[</span><span>Log</span><span>,</span><span class="z-constant"> ...</span><span>]</span></span> <span class="giallo-l"><span> refund_counter</span><span>:</span><span class="z-support"> int</span></span> <span class="giallo-l"><span> running</span><span>:</span><span class="z-support"> bool</span></span> <span class="giallo-l"><span> message</span><span>:</span><span> Message</span></span> <span class="giallo-l"><span> output</span><span>:</span><span> Bytes</span></span> <span class="giallo-l"><span> accounts_to_delete</span><span>:</span><span> Set</span><span>[</span><span>Address</span><span>]</span></span> <span class="giallo-l"><span> return_data</span><span>:</span><span> Bytes</span></span> <span class="giallo-l"><span> error</span><span>:</span><span> Optional</span><span>[</span><span>EthereumException</span><span>]</span></span> <span class="giallo-l"><span> accessed_addresses</span><span>:</span><span> Set</span><span>[</span><span>Address</span><span>]</span></span> <span class="giallo-l"><span> accessed_storage_keys</span><span>:</span><span> Set</span><span>[</span><span>Tuple</span><span>[</span><span>Address</span><span>,</span><span> Bytes32</span><span>]</span><span>]</span></span></code></pre> <p>All references to <code>evm.gas_left</code> are replaced by <code>evm.milli_gas_left</code>.</p> <h3 id="end-of-transaction-conversion">End-of-transaction conversion</h3> <p>At the end of each transaction execution, the gas left in the transaction output is updated to</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx_output</span><span>.</span><span>gas_left</span><span class="z-keyword"> =</span><span> ceil</span><span>(</span><span>evm</span><span>.</span><span>milli_gas_left</span><span class="z-keyword"> /</span><span class="z-constant"> 1000</span><span>)</span></span></code></pre> <p>At the same time, after the transaction is executed, <code>evm.milli_gas_used</code> is rounded up to <code>evm.gas_used = ceil(evm.milli_gas_used / 1000)</code>.</p> <h3 id="opcode-costs">Opcode costs</h3> <p>Opcode gas parameters as defined in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/abd7612d2f4d6fcd9f628330f38884b300f0d89f/src/ethereum/forks/osaka/vm/gas.py">Ethereum Execution Client Specifications</a> that are not updated at the same time or after the introduction of this proposal, are increased by 1000x:</p> <p><code>GAS_PARAM = GAS_PARAM * 1000</code></p> <h3 id="gas-opcode"><code>GAS</code> opcode</h3> <p>The <code>GAS</code> opcode reports the available gas in <code>milli-gas</code> units.</p> <h3 id="call-opcodes"><code>*CALL</code> opcodes</h3> <p><code>*CALL</code> opcodes receive the amount of gas to send to the sub context to execute in <code>gas</code>. <code>gas</code> is converted to <code>milli-gas</code> at the start of the call's execution:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> STACK</span></span> <span class="giallo-l"><span>gas</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span>pop</span><span>(</span><span>evm</span><span>.</span><span>stack</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 1000</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="new-counter-vs-new-variable-type">New counter vs. new variable type</h3> <p>A possible approach to allow for fractional gas would be to change the variable type of all gas-related variables from an integer to a float or a base fractional. Although simple in concept, the implementation of such a change in the EVM is not trivial. In addition, introducing fractional variables would make moving to a zkEVM significantly more complex.</p> <p>Thus, introducing a new counter is the option that least disrupts the current EVM implementation, while allowing for expressive gas costs.</p> <h3 id="rounding-at-transaction-level">Rounding at transaction-level</h3> <p>With the introduction of a new counter, there are two levels at which we could convert <code>milli_gas</code> to <code>gas</code>: at the transaction level or the block level. Conversion at the block level results in the fewest rounding errors in block utilization. However, it requires a bigger change to implement, as <code>milli_gas</code> will need to be used when computing transaction fees and limits, and <code>milli_gas</code> will need to be incorporated in the block environment.</p> <p>The question is whether a conversion at the transaction level is sufficient to reduce rounding errors. To estimate this, we extracted the opcode counts per transaction for 1000 mainnet blocks and computed the new gas prices of all compute operations assuming an anchor of 50Mgas/s and the estimated execution times from <a href="../07904/assets/gas-cost-estimator-report.pdf">EIP-7904's empirical analysis</a>. With this repricing, the fastest opcode (<code>JUMPDEST</code>) would be priced at 90 milli-gas units (i.e., 0.09 gas units). We also assumed that the non-compute operations and precompiles would have the same price, and we excluded any other transaction costs, such as intrinsic costs and calldata.</p> <p>Then, we computed the rounding error of each transaction, assuming a conversion at both the transaction and opcode levels. The opcode-level conversion is equivalent to not using fractional gas and rounding all opcodes to an integer. The following plot shows the distribution for both errors. The x-axis is on a logarithmic scale.</p> <p><img src="https://wg-eips.ritovision.com/8053/./assets/round_err_tx.png" alt="round_error_by_anchor" /></p> <p>In this sample of 1000 blocks, a transaction-level conversion has already successfully reduced the rounding errors from an average of 4% to 0.05% per transaction.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Deployed bytecode that compares <code>gas_left</code> to constants or that uses explicit gas-limited calls will suddenly forward 1000× less gas, causing unexpected reverts or logic flip. Further analysis on how widespread this behavior is required.</p> <h2 id="security-considerations">Security Considerations</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francesco D'Amatohttps://github.com/fradamt Anders Elowssonhttps://github.com/anderselowsson https://wg-eips.ritovision.com/8061/

Increase the exit and consolidation churn and create a separate consolidation churn limit parameter.

<h2 id="abstract">Abstract</h2> <p>This EIP roughly doubles the consolidation churn, as well as quadrupling the exit churn and restoring its proportionality to total stake (though maintaining the existing cap on activations). The choice of parameters balances maintaining a sufficiently long weak subjectivity period (~7 days, roughly halving the current period) with achieving two goals: allowing for faster consolidation of the validator set, in turn accelerating the timeline to faster finality, and relieving exit queue congestion, improving staking liquidity.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/7514/">EIP-7514</a> introduced an activation cap of 8 validators per epoch (now 256 ETH per epoch) to prevent overly rapid validator set growth. <a href="https://wg-eips.ritovision.com/7251/">EIP-7251</a> extended this cap to exits, to make room for the newly introduced consolidation operations, without increasing the weak subjectivity period. However, the fixed cap prevents the exit churn limit from being proportional to total stake, which, all else being equal, leads to longer queues as stake grows. Moreover, the <code>CHURN_LIMIT_QUOTIENT</code> is set quite conservatively in the first place, requiring more than 3 months for 1/3 of the validator set to exit, a time which is now be more than doubled due to the cap. Recent episodes have stressed for more headroom to improve liquidity and staking user experience, as the exit queue has stretched beyond forty days as a consequence of the mass exit of Kiln validators. Long queues degrade user experience, and slow operator response to market or operational events. They also reduce the network’s ability to reconfigure stake more quickly after adverse events, for example to regain finality by having a large amount of stake exit (a double-edged sword, as preventing double finality is the reason these queues exist in the first place, as discussed in the security section). Finally, centralized forms of staking are those that (in relative terms) benefit the most from a lack of liquidity today, as they have the ability to issue a liquid staking token, maintain liquidity reserves or more generally build products that get around the limitations of the protocol.</p> <p>The conservative setting of the <code>CHURN_LIMIT_QUOTIENT</code> affects consolidations as well. Increasing the consolidation churn limit can shorten the path to a smaller validator set and, in turn, the path to a protocol with much faster finality. Under today’s parameters, even the best-case timelines are long: using only activations and exits, fully saturated around the clock, shrinking the roughly 32M ETH of 0x01 stake would take on the order of ~1.5 years; a fully saturated consolidation queue would still take ~1.3 years. Moreover, deposit capacity is also needed for new stake and is thus far from guaranteed to be available for consolidations, as evidenced by the recent inflow of &gt; 1M ETH, fully occupying the queue for ~20 days.</p> <p>The EIP proposes to address these issues by:</p> <ul> <li>removing the cap on exits, restoring the proportionality of exit churn limit to total stake</li> <li>increasing the churn limit on exits</li> <li>introducing a separate consolidation churn limit, since there is no more "excess churn" from having an exit cap, and increase it compared to the current (implicitly defined) one. This also lets us more independently adjust it in the future, for example to increase it if we want to allow for faster consolidation of the validator set or decrease it when this process has already run its course.</li> </ul> <p>The EIP does <em>not</em> propose to lift the cap on the deposit churn, as part of the motivation for introducing it in <a href="https://wg-eips.ritovision.com/7514/">EIP-7514</a> still holds today: though <em>active validator set</em> growth is mostly solved by <a href="https://wg-eips.ritovision.com/7251/">EIP-7251</a>, the <em>validator array in the BeaconState</em> (including inactive validators) is very large and still growing, and too rapid <em>stake</em> growth continues to be a concern as well.</p> <h2 id="specification">Specification</h2> <p>The <code>CHURN_LIMIT_QUOTIENT</code> is halved, from <code>2**16</code> to <code>2**15</code>, and fully dedicated to activations and exits. However, the cap on activations introduced in <a href="https://wg-eips.ritovision.com/7514/">EIP-7514</a> is maintained via <code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code>, while exits are freed from this cap. Consolidations now have their own dedicated churn, determined by <code>CONSOLIDATION_CHURN_LIMIT_QUOTIENT</code>. This is set here to <code>2**16</code>, so that consolidations are allocated half as much churn as activations and exits combined, and a third of the total churn. Finally, <code>compute_weak_subjectivity_period</code> is adjusted to account for the asymmetry between exit and activation churn: a unit of exit churn has twice the weak subjectivity effect ($\frac{4}{3}$) of a unit of activation churn $\frac{2}{3}$, and a unit of consolidation churn has an effect equivalent to the sum of the other two ($2$).</p> <h3 id="configuration">Configuration</h3> <p><code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code> replaces the existing <code>MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT</code>, also <code>256</code>, as the cap now only applies to activations. We introduce the new <code>CONSOLIDATION_CHURN_LIMIT_QUOTIENT</code> and update the <code>CHURN_LIMIT_QUOTIENT</code>.</p> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>CHURN_LIMIT_QUOTIENT_GLOAS</code></td><td><code>uint64(2**15)</code> (= 32,768)</td></tr> <tr><td><code>CONSOLIDATION_CHURN_LIMIT_QUOTIENT</code></td><td><code>uint64(2**16)</code> (= 65,536)</td></tr> <tr><td><code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code></td><td><code>uint64(2**8)</code> (=256)</td></tr> </tbody></table> <h3 id="churn-computations">Churn computations</h3> <p>Due to the intended asymmetry in activation and exit churn, we replace <code>get_activation_exit_churn_limit</code> with <code>get_activation_churn_limit</code>, capped at <code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code>, and <code>get_exit_churn_limit</code>, uncapped. <code>get_consolidation_churn_limit</code> uses the new <code>CONSOLIDATION_CHURN_LIMIT_QUOTIENT</code>, without either a minimum or a maximum value.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_activation_churn_limit</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> Gwei</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Per-epoch churn limit for activations, rounded to EFFECTIVE_BALANCE_INCREMENT.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> churn</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA</span><span>,</span></span> <span class="giallo-l"><span> get_total_active_balance</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> CHURN_LIMIT_QUOTIENT_GLOAS</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> churn</span><span class="z-keyword"> =</span><span> churn</span><span class="z-keyword"> -</span><span> churn</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> min</span><span>(</span><span class="z-constant">MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</span><span>,</span><span> churn</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_exit_churn_limit</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> Gwei</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Per-epoch churn limit for activations, rounded to EFFECTIVE_BALANCE_INCREMENT.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> churn</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA</span><span>,</span></span> <span class="giallo-l"><span> get_total_active_balance</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> CHURN_LIMIT_QUOTIENT_GLOAS</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> churn</span><span class="z-keyword"> -</span><span> churn</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_consolidation_churn_limit</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> Gwei</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Per-epoch churn limit for consolidations (EIP-7521), rounded to EFFECTIVE_BALANCE_INCREMENT.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> churn</span><span class="z-keyword"> =</span><span> get_total_active_balance</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> CONSOLIDATION_CHURN_LIMIT_QUOTIENT</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> churn</span><span class="z-keyword"> -</span><span> churn</span><span class="z-keyword"> %</span><span class="z-constant"> EFFECTIVE_BALANCE_INCREMENT</span></span></code></pre> <p>In <code>compute_weak_subjectivity_period</code> we only replace <code>delta = get_balance_churn_limit(state)</code> with an explicit calculation taking into account the different weak subjectivity effect of each type of operation.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_weak_subjectivity_period</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> uint64</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Returns the weak subjectivity period for the current ``state``.</span></span> <span class="giallo-l"><span class="z-string"> This computation takes into account the effect of validator set churn, </span></span> <span class="giallo-l"><span class="z-string"> bounded by the three churn_limit functions used below.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> t</span><span class="z-keyword"> =</span><span> get_total_active_balance</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span> delta</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span> get_exit_churn_limit</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 3</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> effect of exit churn</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> get_activation_churn_limit</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 3</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> effect of activation churn</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> get_consolidation_churn_limit</span><span>(</span><span>state</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> effect of consolidation churn</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> epochs_for_validator_set_churn</span><span class="z-keyword"> =</span><span class="z-constant"> SAFETY_DECAY</span><span class="z-keyword"> *</span><span> t</span><span class="z-keyword"> //</span><span> (</span><span class="z-constant">2</span><span class="z-keyword"> *</span><span> delta</span><span class="z-keyword"> *</span><span class="z-constant"> 100</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> MIN_VALIDATOR_WITHDRAWABILITY_DELAY</span><span class="z-keyword"> +</span><span> epochs_for_validator_set_churn</span></span></code></pre><h3 id="deposit-processing">Deposit processing</h3> <p>The only modification is replacing <code>get_activation_exit_churn_limit</code> with <code>get_activation_churn_limit</code>, maintaing the current cap on deposit churn respects, while removing the cap from exits. This reverts to the pre-Electra status quo, when activations were capped but exits were not.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_pending_deposits</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> next_epoch</span><span class="z-keyword"> =</span><span> Epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP-8061]</span></span> <span class="giallo-l"><span> available_for_processing</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>deposit_balance_to_consume</span><span class="z-keyword"> +</span><span> get_activation_churn_limit</span><span>(</span></span> <span class="giallo-l"><span> state</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> processed_amount</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> next_deposit_index</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> deposits_to_postpone</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> is_churn_limit_reached</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> finalized_slot</span><span class="z-keyword"> =</span><span> compute_start_slot_at_epoch</span><span>(</span><span>state</span><span>.</span><span>finalized_checkpoint</span><span>.</span><span>epoch</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> deposit</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>pending_deposits</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Do not process deposit requests if Eth1 bridge deposits are not yet applied.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Is deposit request</span></span> <span class="giallo-l"><span> deposit</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;</span><span class="z-constant"> GENESIS_SLOT</span></span> <span class="giallo-l"><span class="z-keyword"> and</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> There are pending Eth1 bridge deposits</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>eth1_deposit_index</span><span class="z-keyword"> &lt;</span><span> state</span><span>.</span><span>deposit_requests_start_index</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check if deposit has been finalized, otherwise, stop processing.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> deposit</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;</span><span> finalized_slot</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check if number of processed deposits has not reached the limit, otherwise, stop processing.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> next_deposit_index</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> MAX_PENDING_DEPOSITS_PER_EPOCH</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Read validator state</span></span> <span class="giallo-l"><span> is_validator_exited</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> is_validator_withdrawn</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> validator_pubkeys</span><span class="z-keyword"> =</span><span> [</span><span>v</span><span>.</span><span>pubkey</span><span class="z-keyword"> for</span><span> v</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>validators</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> deposit</span><span>.</span><span>pubkey</span><span class="z-keyword"> in</span><span> validator_pubkeys</span><span>:</span></span> <span class="giallo-l"><span> validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>ValidatorIndex</span><span>(</span><span>validator_pubkeys</span><span>.</span><span>index</span><span>(</span><span>deposit</span><span>.</span><span>pubkey</span><span>)</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> is_validator_exited</span><span class="z-keyword"> =</span><span> validator</span><span>.</span><span>exit_epoch</span><span class="z-keyword"> &lt;</span><span class="z-constant"> FAR_FUTURE_EPOCH</span></span> <span class="giallo-l"><span> is_validator_withdrawn</span><span class="z-keyword"> =</span><span> validator</span><span>.</span><span>withdrawable_epoch</span><span class="z-keyword"> &lt;</span><span> next_epoch</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_validator_withdrawn</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Deposited balance will never become active. Increase balance but do not consume churn</span></span> <span class="giallo-l"><span> apply_pending_deposit</span><span>(</span><span>state</span><span>,</span><span> deposit</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> is_validator_exited</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validator is exiting, postpone the deposit until after withdrawable epoch</span></span> <span class="giallo-l"><span> deposits_to_postpone</span><span>.</span><span>append</span><span>(</span><span>deposit</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check if deposit fits in the churn, otherwise, do no more deposit processing in this epoch.</span></span> <span class="giallo-l"><span> is_churn_limit_reached</span><span class="z-keyword"> =</span><span> processed_amount</span><span class="z-keyword"> +</span><span> deposit</span><span>.</span><span>amount</span><span class="z-keyword"> &gt;</span><span> available_for_processing</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_churn_limit_reached</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Consume churn and apply deposit.</span></span> <span class="giallo-l"><span> processed_amount</span><span class="z-keyword"> +=</span><span> deposit</span><span>.</span><span>amount</span></span> <span class="giallo-l"><span> apply_pending_deposit</span><span>(</span><span>state</span><span>,</span><span> deposit</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Regardless of how the deposit was handled, we move on in the queue.</span></span> <span class="giallo-l"><span> next_deposit_index</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>pending_deposits</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>pending_deposits</span><span>[</span><span>next_deposit_index</span><span>:</span><span>]</span><span class="z-keyword"> +</span><span> deposits_to_postpone</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Accumulate churn only if the churn limit has been hit.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_churn_limit_reached</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>deposit_balance_to_consume</span><span class="z-keyword"> =</span><span> available_for_processing</span><span class="z-keyword"> -</span><span> processed_amount</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>deposit_balance_to_consume</span><span class="z-keyword"> =</span><span> Gwei</span><span>(</span><span class="z-constant">0</span><span>)</span></span></code></pre><h3 id="exit-processing">Exit processing</h3> <p>We replace <code>get_activation_exit_churn_limit</code> with <code>get_exit_churn_limit</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_exit_epoch_and_update_churn</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> exit_balance</span><span>:</span><span> Gwei</span><span>)</span><span> -&gt;</span><span> Epoch</span><span>:</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>earliest_exit_epoch</span><span>,</span></span> <span class="giallo-l"><span> compute_activation_exit_epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP-8061]</span></span> <span class="giallo-l"><span> per_epoch_churn</span><span class="z-keyword"> =</span><span> get_exit_churn_limit</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New epoch for exits.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> &lt;</span><span> earliest_exit_epoch</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> per_epoch_churn</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>exit_balance_to_consume</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Exit doesn&#39;t fit in the current earliest epoch.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> exit_balance</span><span class="z-keyword"> &gt;</span><span> exit_balance_to_consume</span><span>:</span></span> <span class="giallo-l"><span> balance_to_process</span><span class="z-keyword"> =</span><span> exit_balance</span><span class="z-keyword"> -</span><span> exit_balance_to_consume</span></span> <span class="giallo-l"><span> additional_epochs</span><span class="z-keyword"> =</span><span> (</span><span>balance_to_process</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> //</span><span> per_epoch_churn</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> +=</span><span> additional_epochs</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> +=</span><span> additional_epochs</span><span class="z-keyword"> *</span><span> per_epoch_churn</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Consume the balance and update state variables.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_balance_to_consume</span><span class="z-keyword"> =</span><span> exit_balance_to_consume</span><span class="z-keyword"> -</span><span> exit_balance</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> =</span><span> earliest_exit_epoch</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>earliest_exit_epoch</span></span></code></pre><h2 id="rationale">Rationale</h2> <ul> <li><strong>Independent parameters:</strong> a separate churn consolidation is easy to independently tune, in particular adjusted upward if we want to speed up the consolidation process further, and later downward, when the primary wave of validator set consolidation has already happened and the consolidation operation becomes less crucial.</li> <li><strong>Scaling with stake</strong>: the exit churn regains proportionality to the total stake, and the consolidation churn maintains it.</li> <li><strong>Preserving the activation cap</strong>: the activation churn limit maintains the cap from <a href="https://wg-eips.ritovision.com/7514/">EIP-7514</a></li> <li><strong>Balancing security and functionality</strong>: the exit churn limit is increased by ~4x compared to the current cap, and exactly 2x compared to previous uncapped version, while the consolidation churn limit is increased by ~2x. Activations remain capped at the existing limit. As we see later in more detail, accounting for the asymmetric impact of exits and activations on safety degradation, this results in a decrease of the weak subjectivity period from ~15.7 days to ~7 days (see detailed calculations below), or ~6 days if we were to later remove the activation cap, in either case still on the order of a week. Moreover, were consolidations to be removed later, the weak subjectivity period would go up to ~11 days, or ~8.4 days without the activation cap.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="weak-subjectivity-period">Weak subjectivity period</h3> <p>Let <code>MIN_VALIDATOR_WITHDRAWABILITY_DELAY = 256</code> epochs, and let $S$ denote the total stake, $E$ the exit churn per epoch, $A$ the activation churn per epoch, and $C$ the consolidation churn per epoch. Each unit of exit churn contributes to a safety degradation (measured in ETH, as the churn) of $\frac{4}{3}$, whereas the safety degradation from activations is only $\frac{2}{3}$ per unit. Finally, it is $2$ per unit for consolidations, as a consolidation is the equivalent of an exit and an activation.</p> <p>The formula to compute the weak subjectivity period (in epochs) for a 10% safety decay target (exactly corresponding to <code>compute_weak_subjectivity_period</code>) then is:</p> <p>$\text{WS}_{\text{epochs}} = 256 + \frac{0.1 \cdot S}{\frac{4}{3} \cdot E + \frac{2}{3} \cdot A + 2 \cdot C}$</p> <p>The churn limits of the current protocol, assuming a total stake $S = 36M$ ETH (approximately the stake at the time of writing) are:</p> <ul> <li>$A = E = \min(256, S/2^{16}) = 256$ ETH (capped)</li> <li>$C = S/2^{16} - A \approx 293$ ETH</li> </ul> <p>The weak subjectivity period is then:</p> <p>$\text{WS}_{\text{epochs}} \approx 3533$</p> <p>$\Rightarrow\ \textbf{WS} \approx \mathbf{15.7\ \text{days}}$</p> <p>In days, it is $\text{WS}_{\text{epochs}} / 225$.</p> <p>Under this EIP, and assuming a total stake $S = 36M$ ETH:</p> <ul> <li>$E = S/2^{15} \approx 1098$ ETH</li> <li>$A = \min(256, S/2^{15}) = 256$ ETH (capped)</li> <li>$C = S/2^{16} \approx 549$ ETH</li> </ul> <p>The weak subjectivity period is then:</p> <p>$\text{WS}_{\text{epochs}} \approx 1573$</p> <p>$\Rightarrow\ \textbf{WS} \approx \mathbf{7.0\ \text{days}}$</p> <p>Other possible future scenarios are:</p> <ul> <li>Activation cap removed: $\textbf{WS} \approx \mathbf{6.0\ \text{days}}$ ($\text{WS}_{\text{epochs}} \approx 1348$)</li> <li>Consolidations disabled: $\textbf{WS} \approx \mathbf{10.9\ \text{days}}$ ($\text{WS}_{\text{epochs}} \approx 2457$)</li> <li>Consolidations disabled and activation cap removed: $\textbf{WS} \approx \mathbf{8.4\ \text{days}}$ ($\text{WS}_{\text{epochs}} \approx 1894$)</li> </ul> <p>Note that removing the activation cap only reduces the weak subjectivity period by one day, and leaves it on the order of a week. The current parameters might then also be considered acceptable in a future where it is decided to remove the activation cap.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francesco D'Amatohttps://github.com/fradamt Barnabas Busahttps://github.com/barnabasbusa https://wg-eips.ritovision.com/8045/

Modify proposer selection to exclude slashed validators, improving network resilience and performance after mass slashings

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a modification to the beacon chain proposer selection process to exclude slashed validators from being selected as proposers.</p> <h2 id="motivation">Motivation</h2> <p>Currently, slashed validators can still be selected as proposers, though their blocks are considered invalid by the state transition function, resulting in missed slots. This is in particular problematic after a mass slashing event, at which point there can be a long period with degraded chain performance, until all slashed validators are exited. If mass slashing also comes with general network disruption, the missed slots can also significantly complicate the recovery process. This change filters out slashed validators during proposer selection, reducing disruption and increasing resilience in such scenarios.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <p>The <code>get_beacon_proposer_indices</code> function in the consensus specifications is modified to exclude slashed validators from the proposer selection process, effectively going from considering all active validators to all active and unslashed validators.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_beacon_proposer_indices</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> epoch</span><span>:</span><span> Epoch</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> Vector</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Return the proposer indices for the given ``epoch``.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Modified to exclude slashed validators</span></span> <span class="giallo-l"><span> indices</span><span class="z-keyword"> =</span><span> [</span><span>i</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span> get_active_validator_indices</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>)</span><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>i</span><span>]</span><span>.</span><span>slashed</span><span>]</span></span> <span class="giallo-l"><span> seed</span><span class="z-keyword"> =</span><span> get_seed</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>,</span><span class="z-constant"> DOMAIN_BEACON_PROPOSER</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> compute_proposer_indices</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>,</span><span> seed</span><span>,</span><span> indices</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="why-exclude-slashed-validators">Why exclude slashed validators?</h3> <p>Slashed validators are already prevented from successfully proposing blocks through the state transition validation. The <code>process_block</code> function checks that the proposer is not slashed, and blocks from slashed proposers are considered invalid. Therefore, selecting slashed validators as proposers serves no purpose and only results in missed slots.</p> <h3 id="design-decision-upfront-filtering">Design decision: upfront filtering</h3> <p>The chosen approach is to simply filter out slashed validators from the candidate pool, before doing any shuffling computation. An alternative design would be to still use the whole active validator set as the candidate pool, and then only filter out slashed validators once their index has been selected by the shuffle. The exact selection is not identical, but it achieves the same goal, i.e., a balance-weighted selection from the set of active-and-unslashed validators. The complexity is low in either design.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases should verify that:</p> <ol> <li>Slashed validators are not selected as proposers</li> <li>A complete <code>proposer_lookahead</code> is generated even in the presence of slashed validators</li> <li>Slashings do not affect the existing <code>proposer_lookahead</code></li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>Slashed validators are already prevented from successfully proposing blocks through the state transition validation, for good reason, as they are considered to be unreliable participants (malicious or faulty). However, they have historically still been eligible to be selected as proposers in order to ensure stability of the proposer selection mechanism, because excluding them would have severely impacted the stability of the proposer selection mechanism. In fact, any slashing processed on chain would have caused the sequence of future proposers to completely change, even within the lookahead window. However, with <a href="https://wg-eips.ritovision.com/7917/">EIP-7917</a>, the proposer selection is fixed in advance by storing in the Beacon state, so it would not be affected by slashings processed after the fact.</p> <h3 id="impact-on-proposer-selection-distribution">Impact on proposer selection distribution</h3> <p>This change does not affect the randomness or fairness of proposer selection among non-slashed validators. The selection algorithm remains the same, with the only difference being that slashed validators are excluded from the candidate pool.</p> <h3 id="mass-slashing-scenarios">Mass slashing scenarios</h3> <p>During mass slashing events, this change is purely beneficial to the resilience of the network, as well as to general quality of service. Instead of having many slashed validators selected as proposers (resulting in many missed slots), the network will continue to operate normally with only non-slashed validators being selected.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson https://wg-eips.ritovision.com/8046/

Ensure IL transactions that offer a higher ranking fee than competing transactions are included in the block. Burn the marginal ranking fee.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a uniform price auction over inclusion lists (UPIL), which ranks transactions by their offered ranking fee per gas. When the block is full, no transaction is allowed to displace an inclusion-list (IL) transaction that passes regular inclusion criteria and offers a higher ranking fee per gas. All included transactions pay a uniform inclusion price, equal to the highest ranking fee offered by any valid IL transaction excluded from the block, and this fee is burned. UPIL achieves strong censorship resistance by not allowing builders to circumvent propagated ILs when the block is full. This is particularly valuable for time-sensitive transactions and promotes fairness while preventing cheap block-stuffing under a multidimensional fee market. UPIL is specified to run on top of FOCIL (<a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a>), but can be deployed on top of any IL mechanism.</p> <h2 id="motivation">Motivation</h2> <p>Censorship resistance (CR) is a key property of decentralized blockchains. To ensure that transactions cannot be censored by the entity building the block (denoted "builder" in this EIP, which may sometimes be the proposer), a mechanism called fork-choice enforced inclusion lists (FOCIL) has been proposed in <a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a>. A set of includers propagate inclusion lists (ILs), and the attesters uphold that the transactions in the ILs are included in the block via the fork-choice. There is no mechanism for ranking transactions in the ILs, and therefore not viable to uphold CR when the block is full. If IL transactions must be prioritized under full blocks, the builder could simply integrate with includers to propagate ILs containing the transactions it wishes to include in the block.</p> <p>To uphold CR also under full blocks, it is necessary to have a framework for which transactions to include and exclude. This EIP specifies a uniform price auction over inclusion lists (UPIL), which ranks transactions by their offered <code>ranking_fee_per_gas</code>, derived from their specified <code>max_ranking_fee_per_gas</code>. If a block is full, no transaction is allowed to displace an IL transaction with a higher <code>ranking_fee_per_gas</code>, as long as the displaced IL transaction passes regular inclusion criteria. All included transactions pay the "marginal" ranking fee, corresponding to the highest ranking fee offered by a valid IL transaction excluded from the block, and this fee is burned. If no IL transaction was excluded, the marginal ranking fee is <code>0</code>. In essence, the existing base fee prices inter-block contention, while UPIL is an auction mechanism that relies on ILs to impose a secondary base fee that prices intra-block contention.</p> <p>Ethereum is currently pursuing scaling by tracking gas consumption across separate resources, allowing each resource to be consumed at its maximum capacity. With a multidimensional approach, it can become cheaper to "stuff the block" such that it is full in any dimension by creating "dummy transactions" that only consume one specific resource. This degrades the CR of FOCIL, since builders can ignore ILs in full blocks. In the multidimensional <a href="https://wg-eips.ritovision.com/7706/">EIP-7706</a> and <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>, the degradation of CR can become rather pronounced. Base fees are set individually per resource and may become very low, depending on whether reserve prices in the style of <a href="https://wg-eips.ritovision.com/7918/">EIP-7918</a> are adopted or not. Furthermore, if the builder varies which resource that is full across blocks, there is no longer an exponentially increasing cost to keep a transaction censored block after block.</p> <p>The strong CR of UPIL is particularly suitable under a multidimensional fee market, but can be beneficial under any fee market. Some transactions are time-sensitive: what matters is inclusion within a set time frame. Sometimes, that time frame consists of just a few or a single block. UPIL guarantees inclusion in the next block for a transaction offering a sufficient ranking fee, assuming includers and attesters do their duties. This puts includers and the builder on a more equal footing. Furthermore, the lack of ranking in FOCIL gives builders an incentive to amass private transactions to facilitate low-cost temporary censorship, which could negatively affect the public mempool. However, both FOCIL and UPIL also have properties that strengthen the public mempool.</p> <h2 id="specification">Specification</h2> <h3 id="new-transaction-format-and-ranking-fee">New transaction format and ranking fee</h3> <p>A new field <code>max_ranking_fee_per_gas</code> is added to a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction with <code>TransactionType</code> = <code>RANK_TX_TYPE</code>. The <code>TransactionPayload</code> for this transaction is:</p> <p>&lt;-- TODO --&gt;</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-keyword"> TODO</span><span class="z-comment">: To be defined after scheduling this EIP relative to EIP-7999 and EIP-8011, etc.</span></span></code></pre> <p>The ranking is performed on the <code>ranking_fee_per_gas</code>, corresponding to the maximum ranking fee that the transactor was willing to pay under the current base fee. Older transaction formats use their entire headroom for their offered ranking fee, whereas the new format can cap the ranking fee using the <code>max_ranking_fee_per_gas</code> field.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_max_fee</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_legacy</span><span>(</span><span>tx</span><span>.</span><span>type</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>gas_price</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>max_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_ranking_fee</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> ranking_fee_per_gas</span><span class="z-keyword"> =</span><span> get_max_fee</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> -</span><span> block</span><span>.</span><span>base_fee_per_gas</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The new RANK_TX_TYPE can set a cap to the offered ranking fee</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> RANK_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> min</span><span>(</span><span>tx</span><span>.</span><span>max_ranking_fee_per_gas</span><span>,</span><span> ranking_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ranking_fee_per_gas</span></span></code></pre> <p>The ranking fee does not impose ordering constraints within the block, and only governs inclusion. The alternative specifications section discusses the options that exist for computing the <code>ranking_fee_per_gas</code> in various transaction formats, including the option to not implement a new transaction format at all.</p> <h3 id="transaction-processing">Transaction processing</h3> <p>The builder specifies in the block body the <code>marginal_ranking_fee_per_gas</code> that all transactions must pay. The full <code>inclusion_fee_per_gas</code> corresponding to <code>base_fee_per_gas + marginal_ranking_fee_per_gas</code> is covered before the priority fee. A valid transaction must have <code>max_fee_per_gas &gt;= inclusion_fee_per_gas</code> and <code>RANK_TX_TYPE</code> transactions must also have <code>max_ranking_fee_per_gas &gt;= marginal_ranking_fee_per_gas</code>. Thus, under <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, transaction processing is changed as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">for</span><span> unnormalized_transaction</span><span class="z-keyword"> in</span><span> transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> After this existing check...</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..check that the transactor is willing to pay the marginal ranking fee</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> transaction</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> RANK_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>marginal_ranking_fee_per_gas</span><span class="z-keyword"> &lt;=</span><span> transaction</span><span>.</span><span>max_ranking_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..derive the inclusion fee per gas and perform checks</span></span> <span class="giallo-l"><span> inclusion_fee_per_gas</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>base_fee_per_gas</span><span class="z-keyword"> +</span><span> block</span><span>.</span><span>marginal_ranking_fee_per_gas</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> inclusion_fee_per_gas</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..cap the priority fee by the inclusion fee instead of the base fee</span></span> <span class="giallo-l"><span> priority_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>transaction</span><span>.</span><span>max_priority_fee_per_gas</span><span>,</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> -</span><span> inclusion_fee_per_gas</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..and adjust the line calculating the effective gas price</span></span> <span class="giallo-l"><span> effective_gas_price</span><span class="z-keyword"> =</span><span> priority_fee_per_gas</span><span class="z-keyword"> +</span><span> inclusion_fee_per_gas</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>The inclusion fee is never distributed and thus burned. Note that legacy transactions are assigned <code>max_fee_per_gas = gas_price</code> and <code>max_priority_fee_per_gas = gas_price</code> as part of a prior normalization step. The existing assert statement</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> block</span><span>.</span><span>base_fee_per_gas</span></span></code></pre> <p>is redundant and is removed.</p> <h3 id="altered-focil-post-execution-inclusion-check">Altered FOCIL post-execution inclusion check</h3> <p>The post-execution inclusion check of <a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a> is altered as outlined in the figure. Orange squares represent the original FOCIL checks, where "No" always leads to jumping to the next transaction. Blue squares are the checks added in UPIL that account for ranking. The first black square of step (1) contains only peripheral modifications that do not alter the intended outcome of the inclusion check.</p> <p><img src="https://wg-eips.ritovision.com/8046/./assets/1.png" alt="Figure 1" /></p> <p>The <code>ranking_fee_per_gas</code> is first computed for each transaction <code>X</code> in the block via <code>get_ranking_fee(X, B)</code>. Then, for each transaction <code>T</code> in ILs, the check performs three steps.</p> <hr /> <p>The original step (1)</p> <blockquote> <p>(1) Check whether <code>T</code> is present in <code>B</code>. If <code>T</code> is present, then jump to the next transaction, else continue with next step.</p> </blockquote> <p>is replaced with the following:</p> <p>(1) If <code>T</code> is present in <code>B</code>, or <code>get_max_fee(T) &lt; block.base_fee_per_gas</code>, or <code>T</code> fails static validity, then skip <code>T</code> and jump to the next IL transaction, else continue to the next step.</p> <hr /> <p>The original step (2):</p> <blockquote> <p>(2) Check whether <code>B</code> has enough remaining gas to execute <code>T</code>. If <code>T.gas</code> &gt; <code>gas_left</code>, then jump to the next transaction, else continue with next step.</p> </blockquote> <p>is replaced with the following:</p> <p>(2a) Check whether <code>B</code> has enough remaining gas to execute <code>T</code>: <code>gas_left &gt;= T.gas_limit</code>. If so, continue to (3a); otherwise, continue to (2b) potentially followed by (3b).</p> <p>(2b) Check whether <code>B</code> would have had enough remaining gas to execute <code>T</code>, if <code>T</code> was included together with only higher-ranked transactions in <code>B</code>. First compute <code>T.ranking_fee_per_gas = get_ranking_fee(T, B)</code> and then compute <code>gas_ranked_left(T)</code> as the remaining gas after subtracting the <code>gas_used</code> of all transactions of the block with a higher <code>ranking_fee_per_gas</code> than <code>T</code> from <code>B.gas_limit</code>. For transactions with the same <code>ranking_fee_per_gas</code>, included transactions in <code>B</code> are considered higher-ranked than not-included IL transactions. If <code>gas_ranked_left(T) &gt;= T.gas_limit</code>, continue to (3b); otherwise jump to the next IL transaction.</p> <hr /> <p>The original step (3):</p> <blockquote> <p>(3) Validate <code>T</code> against <code>S</code> by checking the nonce and balance of <code>T.origin</code>.</p> </blockquote> <p>is replaced with the following:</p> <p>(3a) Validate <code>T</code> against <code>S</code> by checking the nonce and balance of <code>T.origin</code>.</p> <p>(3b) Validate <code>T</code> against <code>S</code> by checking the nonce of <code>T.origin</code>. Further validate <code>T</code> against the balance of the origin account by applying the standard pre-execution fundability check to a conservative balance that ignores all increases and counts all decreases to <code>T.origin</code> at the completion of each executed transaction of the block. Intermediate increases or decreases during the execution of a transaction are not tracked in isolation.</p> <p>Step (3a) and (3b) conclude as previously:</p> <blockquote> <p>If <code>T</code> is invalid, then continue to the next transaction.</p> <p>If <code>T</code> is valid, terminate process and return an <code>INCLUSION_LIST_UNSATISFIED</code> error.</p> </blockquote> <h3 id="check-on-the-marginal-ranking-fee">Check on the marginal ranking fee</h3> <p>Attesters review excluded IL transactions to confirm that the <code>marginal_ranking_fee_per_gas</code> was set correctly by the builder. If step (2b) indicates that the transaction was outranked, then, before continuing with the next transaction, the transaction is also checked against step (3b), as indicated by a dashed line in the figure. The highest <code>ranking_fee_per_gas</code> among outranked IL transactions from (2b) that pass the valid inclusion check of (3b) must equal <code>marginal_ranking_fee_per_gas</code>. If no outranked IL transaction passes (3b), the <code>marginal_ranking_fee_per_gas</code> must be <code>0</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="updated-inclusion-check">Updated inclusion check</h3> <h4 id="conservative-balance">Conservative balance</h4> <p>The reason for using a conservative balance in (3b) when validating <code>T</code> is to avoid the circular dependencies that can emerge when a transaction is made executable by a lower-ranked transaction. Consider three transactions <code>A</code>, <code>B</code>, and <code>C</code> ranked as <code>A&gt;B&gt;C</code>. Without a conservative balance, <code>A</code> might be funded only if <code>B</code> is included in the block. For example, transaction <code>B</code> might fund <code>A</code>, so without <code>B</code>, <code>A</code> cannot be included, and without <code>A</code>, <code>B</code> cannot be included due to having a lower ranking. There is not enough gas to include both <code>A</code> and <code>B</code>. Including neither and instead including <code>C</code> also fails because the left out <code>B</code> was higher ranked.</p> <p>It is not necessary that <code>B</code> directly funds <code>A</code>. It might very well be the case that <code>B</code> just changes the state such that a higher-ranked transaction <code>X</code> funds <code>A</code>, something that <code>X</code> would not do unless <code>B</code> was run beforehand.</p> <p>It should be noted in (3b) that the transactor is in control of decreases to its ETH balance. Within a block, ETH leaves <code>T.origin</code> only via the transactor’s own signed transactions (value transfers and gas payments) or contracts it has explicitly authorized; the builder cannot manufacture debits. If the transactor’s own debits make <code>T</code> unfundable, and these are included in the block—even if lower-ranked—exclusion is acceptable as a consequence of choices made. After all, the transactor controls the relative order of its own transactions via nonces. Thus, ranking is neither considered for debits nor for credits: debits count regardless of rank, and credits do not count at all.</p> <h4 id="retained-focil-check-in-non-full-blocks">Retained FOCIL check in non-full blocks</h4> <p>The regular FOCIL check is retained in non-full blocks to take advantage of its operational simplicity and since the conservative balance check of UPIL is unnecessarily lenient to the builder whenever an excluded IL transaction would have fit and is funded during processing of the prior transactions in the block. The circular dependencies from the previous subsection do not apply in FOCIL since there is no requirement for transactions in the IL to be included in the block if a transaction outside of the IL uses up the gas. Once (2a) confirms slack, the builder was clearly able to include any existing funding transaction in the block and still include <code>T</code>, so skipping <code>T</code> is an IL violation. UPIL could otherwise also be implemented completely without the old FOCIL checks, to reduce code surface. This corresponds to removing the orange boxes in the figure, retaining the blue boxes.</p> <h4 id="compute-requirements-for-2b-and-3b">Compute requirements for (2b) and (3b)</h4> <p>The new conditions can be checked efficiently by clients.</p> <p>In step (2b), validators can generate a list of the transactions in the block post-execution, sorted according to <code>ranking_fee_per_gas</code>, with an associated list of the cumulative gas consumption. The check for each transaction then only requires keying into the list and extracting the associated gas consumption.</p> <p>For step (3b), the preprocessing consists of tracking a limited set of account-balance-changes during transaction processing. Before processing the block, the client builds an observation set <code>E</code> of <code>T.origin</code> balances for excluded IL transactions. After processing each transaction, it updates <code>E</code>, accounting for all decreases to <code>T.origin</code> balances but ignoring increases. If a block-level access list (BAL) is available that tracks all balance changes, the overall task is further simplified.</p> <p>The check on the <code>marginal_ranking_fee_per_gas</code> (dashed line in the figure) is also trivial. For example, all outranked IL transactions that are otherwise validly includable can have their <code>ranking_fee_per_gas</code> added to an array. After all IL transactions have been reviewed, the maximum entry of this array must equal the specified <code>marginal_ranking_fee_per_gas</code>. If the array is empty, the <code>marginal_ranking_fee_per_gas</code> must instead be <code>0</code>.</p> <h3 id="auction-design">Auction design</h3> <p>The uniform price auction design allows transactors to signal intent (to overcome censorship if the block is full), without actually having to pay more than necessary. A transactor may not know beforehand if they will be censored, and may not wish to pay a very high fee for no reason. There are similarities to the current base fee model. Everyone specifies their willingness to pay, but pays the same minimum fee for inclusion, and this fee is burned. The combination of intents and fairness is attractive. A key difference is that the base fee is a clearing fee tracking contention for blockspace at the inter-block level, whereas the marginal ranking fee is a clearing fee tracking contention for blockspace at the intra-block level (locally for each block).</p> <p>In essence, Ethereum’s current fee mechanism combines a uniform-price base fee that clears congestion across blocks with a first-price priority fee allocating space within each block. What UPIL does is to expand the uniform-price component to the intra-block level by introducing a marginal ranking fee that all included transactions pay equally. Inclusion will thus be governed primarily by protocol-defined uniform clearing (assuming transactions are surfaced in ILs).</p> <p>The <code>max_ranking_fee_per_gas</code> is expected to be set rather low under normal circumstances. Most transactors will not be willing to pay excessively to be included in full blocks, and can instead wait for the next block. However, since the next block will have a 12.5% higher base fee, most transactors will at a minimum set <code>max_ranking_fee_per_gas</code> to 12.5% of the current base fee. The increase in burned fees extracted from transactors in full blocks will be offset by a decrease in priority fees, since the builder no longer controls which transactions that are included (furthermore, includers may also receive other fees, as discussed in the section on includer rewards). The ranking fee will also help with clearing in a fair manner under congestion during sudden spikes in transaction demand. All transactions included in the same block will pay the same ranking fee, with transactions willing to pay the most during a sudden spike included in the first available block. This is arguably an improvement to the UX for Ethereum's users.</p> <p>The reason for burning the marginal ranking fee instead of paying it out to includers is that includers otherwise could have an incentive to engineer artificial congestion in order to raise the fee. This is not trivial, requiring many separate entities to agree to withhold transaction inclusion for consecutive blocks. Various configurations for how to reward includers for their work are outlined in a subsequent section, including the option to distribute the marginal ranking fee to them.</p> <p>The builder may sometimes, via its private orderflow or late-arriving transactions, have some ability to raise the <code>marginal_ranking_fee_per_gas</code> by including transactions that outrank IL transactions. But a builder that raises the marginal ranking fee will also inadvertently reduce the priority-fee headroom for all transactions, since the inclusion fee is subtracted from the max fee before calculating the capped priority fee for all transactions in the block.</p> <h3 id="multidimensional-upil">Multidimensional UPIL</h3> <p>If there are multiple resources, <code>gas_ranked_left(T)</code> is a vector. Using the notation of <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>, all <em>conditional</em> resources must then be checked against the corresponding gas limits specified by the analyzed transaction. Transactions that consume any <em>deconditional</em> resource are not subject to the UPIL post-execution check, and insufficient capacity in an <em>unconditional</em> resource is never a valid reason to exclude an IL transaction.</p> <p>Thus, under multidimensional UPIL, the transaction is checked against <code>gas_ranked_left(T)</code> over the conditional resources only, in both (2a) and (2b). However, given the strong CR of UPIL, it would be perfectly feasible to classify calldata as conditional instead of using the unconditional classification of <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>.</p> <h3 id="censorship-resistance-under-focil-and-upil">Censorship resistance under FOCIL and UPIL</h3> <p>This subsection offers a comparison of the censorship resistance achieved under FOCIL and UPIL. The premise is a builder seeking to censor a transaction under different fee market designs. We begin by rudimentarily quantifying the cost $C_i$ of censoring a transaction in block $i$ ($i=0$ for the first censored block) as:</p> <p>$C_i = g_df_b (1+r)^i + g_df_r + m(i, f_r).$</p> <p>In this equation, $g_d$ is the gas that the builder must pay by creating so-called "dummy transactions" to fill the block, $f_b$ is the base fee for that gas, $r$ is the rate by which the base fee increases in full blocks (i.e., 12.5%), $f_r$ is the <code>ranking_fee_per_gas</code> of the censored transaction, and $m(i, f_r)$ is the MEV (including priority fees) forgone when forced to exclude pending transactions with a lower ranking than the censored transaction for block $i$ (the opportunity cost).</p> <h4 id="multidimensional-fee-market">Multidimensional fee market</h4> <p>Under a multidimensional fee market envisioned in <a href="https://wg-eips.ritovision.com/7706/">EIP-7706</a> and <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>, the base fee is set individually per resource to maximize utilization of blockspace. As noted in <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>, the base fee may therefore sometimes become very low for a resource, meaning that the cost of generating dummy transactions to fill the block also becomes very low. In a potential multidimensional FOCIL, it is then only necessary that one resource used by a transaction is filled to censor that transaction. Furthermore, while the base fee will increase for the resource that was filled with dummy transactions, the base fees of all other resources will not. These base fees will instead vary based on gas consumed by regular transactions included in the block. The builder can potentially vary which resource it fills the block for, to keep any base fee from exploding during prolonged censorship. Define $\mathbf{f_b}$ as the vector of base fees. The outcome for FOCIL and UPIL respectively is:</p> <p><strong>FOCIL:</strong> The cost of censorship for the first block is $C_0 = g_d\min(\mathbf{f_b})$, and thus $C_0 \to 0$ if $\min(\mathbf{f_b}) \to 0$. The cost can potentially be kept close to 0 even under continued censorship, depending on the distribution of the equilibrium base fees under no censorship and the fee elasticities of demand.</p> <ul> <li>There is no ranking fee (thus $g_df_r \to 0$) and there is no opportunity cost because the builder can always include lower-ranked transactions when it fills the block (thus $m(i, f_r) \to 0$).</li> <li>The builder can switch between resources it fills, thus potentially keeping its overall costs contained even under continued censorship. This depends on prevailing fee elasticities and equilibrium base fees under no censorship.</li> <li>If there is just one base fee that is low initially, then that base fee will rise (albeit from a low starting point), if the builder does not assume the opportunity cost $m(i, f_r)$ of excluding other transactions. Fee elasticities are relevant also in this case, because the rise in a single base fee should moderately reduce demand for all other resources as the transactor reviews the total cost.</li> </ul> <p><strong>UPIL:</strong> The cost of censorship for the first block is $C_0 = g_d\min(\mathbf{f_b}) + g_df_r + m(i, f_r)$, and thus $C_0 = g_df_r + m(i, f_r)$ if $\min(\mathbf{f_b}) \to 0$. This cost can be hundreds or thousands of times higher than whatever ranking fee the censored transaction specifies, and it rises with continued censorship due to the opportunity cost of keeping all pending transactions with a lower ranking fee that consume the filled resource out of the block.</p> <ul> <li>If the transactor specifies a ranking fee $f_r$ that exceeds the ranking fee of existing transactions in the mempool, the censoring builder will need to create dummy transactions up to the entire gas limit of the resource it is targeting. This can be specified as $g_d = g_l-g_r(T)$, where $g_r(T)$ is the gas already consumed by the censored transaction. Thus, the censoring builder must pay $f_r(g_l-g_r(T))$. To censor a transaction consuming 100k gas when the gas limit is 60M in the filled resource, the builder must pay $(60-0.1)/0.1 = 599$ times more than what the transactor was willing to pay for inclusion. As the gas limit expands, the relative cost of censorship increases. It should here be noted that the transactor will not need to pay its high offered ranking fee if it is indeed censored, and would after censorship concludes only pay according to the <code>marginal_ranking_fee_per_gas</code> of the subsequent block.</li> <li>The opportunity cost from censorship is also higher under UPIL than FOCIL, since no pending transaction with a ranking fee $f'_r&lt;f_r$ that consumes the filled resource can be included if the censored transaction is excluded.</li> </ul> <h4 id="current-fee-market">Current fee market</h4> <p>We now discuss the situation under the current fee market with a single base fee (ignoring the blob resource). In this case, the base fee term of the previous equation does not vanish. If the builder does not use the "slow transaction" strategies outlined in the next subsection, the outcome for FOCIL and UPIL respectively is:</p> <p><strong>FOCIL:</strong> The builder must cover the base fees: $g_df_b(1+r)^i$ of block $i$. The required amount of purchased gas $g_d$ will in the average case be $g_d=g_l/2$. However, there will be many instances where pending transactions in the public mempool or via private orderflow consume more than $g_l/2$. Censorship for one or two blocks can therefore be inexpensive even if pending transactions do not completely fill the block. The $(1+r)^i$ term grows by 12.5% per block, doubling in six blocks, and pending transactions are quickly depleted. Therefore, censorship becomes costly rather quickly: FOCIL ensures that transactions are included within a limited number of blocks if includers do their duties, but not in the first few blocks.</p> <p><strong>UPIL:</strong> The builder must cover the base fee, the ranking fee, and forego pending transactions, thus suffering a cost of $g_df_b(1+r)^i + g_df_r + m(i, f_r)$. The required gas $g_d$ is higher than in FOCIL, and—just as for the multidimensional fee market—potentially the full gas limit, because the builder cannot rely on pending transactions with a lower ranking fee for block stuffing. Due to the $g_df_r$ term, the cost for censoring a transaction for a single block can easily become a thousand times higher than whatever the transactor was willing to pay for inclusion, just as under the multidimensional fee market.</p> <h4 id="current-fee-market-with-slow-transactions">Current fee market with "slow transactions"</h4> <p>Note the importance of pending transactions for sidestepping the ILs in FOCIL: the cost for covering base fees when filling the block provides the CR. A strategy the builder could use to reduce the cost of censorship over a few blocks is to amass "slow transactions" through private orderflow—transactions that do not have to execute immediately. These are transactions for which the transactor is willing to substitute speed for some other benefit, predominantly rebated fees, but potentially also convenience or MEV protection. The builder (or realistically a MEV-protecting RPC endpoint) guarantees (trustfully) inclusion within some set time frame, and that the total cost for the transactor will be below the cost that would have been incurred given the base fee at the time that the tx is sent to the builder. The concept can be integrated as:</p> <p>$C_i = g_df_b ((1+r)^i-s) + g_df_r + m(i, f_r).$</p> <p>Here, $s$ represents the cost reduction factor relative to the initial base fee. This models a scenario where the builder has stored and promised to include blockspace-filling transactions at a fixed discount. If the rebate to transactors for slow transactions is 10%, then $s=0.9$, with the cost of censoring the first block in FOCIL reduced by 90%. Such a strategy can thus be useful for censoring a couple of blocks in a row. After around 5 blocks or less, $(1+r)^i - s &gt; 1$, meaning that the cost is the same as the cost of censoring the first block without slow transactions. Since the supply of slow transactions would likely be limited, the strategy cannot be applied too often.</p> <p>Slow transactions must be propagated privately to remain useful, and reach their full economic potential by contributing to censorship. When the value in sidestepping ILs exceeds the costs of facilitating slow transactions, the proportion of transactions propagated p2p may thus fall. On the other hand, the transactions that indeed are propagated p2p are upon IL listing guaranteed inclusion in non-full blocks, and therefore do not need to pay priority fees. The effect of FOCIL on the public mempool may therefore be negative or positive depending on the demand for censorship from builders. Alternatively, the protocol could facilitate "trustless slow transactions" by letting builders sponsor transactions offering a max fee below the prevailing base fee, for example by charging the base fee jointly for all transactions at the end of the block.</p> <p>Under UPIL, slow transactions do not contribute meaningfully to censorship due to the $g_df_r + m(i, f_r)$ terms, and there is furthermore no rationale for paying a priority fee upon listing, further strengthening the public mempool.</p> <h4 id="multidimensional-gas-metering">Multidimensional gas metering</h4> <p>Under multidimensional gas metering in <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a>, the situation is closer to the current fee market than the multidimensional fee market. There is still just one base fee, so the cost of censoring a transaction for a sustained period rises exponentially. Censorship may become slightly cheaper than currently, due to the equilibrium reduction in the base fee with a maintained slack in the block relative to the most consumed resource. On the other hand, utilization of slow transactions may become slightly less efficient.</p> <p>In the current fee market, half the gas limit $g_l/2$ is consumed in the average block. Transactors spend $f_bg_l/2$ on average and the cost of censoring a block via dummy transactions is also $f_bg_l/2$. Under multidimensional gas metering, $g_l/2$ is consumed on average individually for the most used resource. Transactors however consume the higher $xg_l/2$ amount of gas on average over all resources, while the gas required for censorship remains at $g_l/2$ (filling up the most consumed resource). Here $x$ corresponds to the scaling factor achieved when gas of different resources can be consumed in parallel, a scaling factor that might end up in the range 2-4. Keeping demand and $g_l$ fixed, the base fee $f_b$ will fall, reducing the cost $f_bg_l/2$ of censoring a block in the average case. Had we instead simply increased the gas limit, CR would have been affected differently, because then the cost of censorship would also have increased according to the increase in $g_l$, such that the censoring builder would have needed to purchase more dummy transactions in the average case.</p> <h4 id="transaction-inclusion-and-mev">Transaction inclusion and MEV</h4> <p>In FOCIL, including an existing transaction is always possible without raising the inclusion fee, regardless of whether this means that an IL transaction must be excluded or not. In UPIL, if the block is full, including an existing transaction over an IL transaction willing to pay more is treated as censorship. Ostensibly, MEV and censorship are not separate topics: in many scenarios, censorship is also MEV. To displace the IL transaction offering the lowest ranking fee among IL transactions in the block, the new transaction must pay at least the ranking fee offered by that IL transaction.</p> <p>Since the builder cannot freely decide which of the pending transactions to include in UPIL, it might not be able to extract all MEV from pending transactions that it could have in FOCIL. It lacks the ability to exclude IL transactions at will from full blocks. Once a transaction is in an IL, its inclusion is guaranteed if it is willing to pay at least the same as the smallest offer by other transactions that go into the block. This levels the playing field between includers and the builder, giving the includer the opportunity to offer real inclusion guarantees to transactors. In FOCIL, the <em>protocol</em> offers real inclusion guarantees, <em>eventually</em>. In UPIL, the <em>includer</em> offers real inclusion guarantees, <em>immediately</em>.</p> <p>Some includers might charge transactors for their services in FOCIL, but the value of the provided services is further strengthened in UPIL. MEV might thus shift from the builder to includers in the form of fees for listing the transaction. A transaction listed by an IL has no need to pay a priority fee for inclusion. Indeed, we may even see "IL-builders" that collate full ILs as a service both in FOCIL and UPIL. Some MEV will also shift to the protocol in the form of burned ranking fees. It is natural to then consider what options the builder has, to retain some power over transaction inclusion. It may of course try to bribe includers to not list transactions. A problem for a builder trying to stay competitive is that this requires bribing all includers, and that any includer remaining faithful to its duties can earn a greater reward from transactors when others take the bribe, particularly in UPIL.</p> <p>There are nuances to the design that need careful consideration before adoption. Something to be attentive to is the effect of burning the marginal ranking fee, given that avoiding the burn is not a zero-sum outcome for builders and includers. This is further discussed in the next section.</p> <h3 id="alternative-specifications-for-rewarding-includers">Alternative specifications for rewarding includers</h3> <p>Transactors might wish to reward includers in both FOCIL and UPIL for surfacing their transaction in an IL. They may recognize that the space in each IL is limited, meaning includers sometimes need to prioritize between available transactions. They might also fear that builders could bribe includers to not fulfill their duties, so that the builder can exclude unwanted transactions. As discussed previously, UPIL strengthens the position of includers, giving them in some sense equal power to the builder in deciding which transactions enter the block. For this reason, the case for rewarding includers is also stronger: an IL transaction does not require a priority fee to be included, even in full blocks—it must be included if it offers a higher ranking fee than competing transactions.</p> <h4 id="out-of-protocol-inclusion-fees">Out-of-protocol inclusion fees</h4> <p>If there is no in-protocol reward mechanism, individual staking service providers might start offering (trustfully) to list transactions in their next assigned IL slot, against a small fee. We might also see public orderflow of includable transactions offering a certain reward for inclusion, with includers and transactors coming to agreement via a third-party software. This can improve the UX, but also has the potential to become a centralization vector.</p> <h4 id="in-protocol-inclusion-fee-sources">In-protocol inclusion fee sources</h4> <p>It is possible that the protocol can be of direct assistance. Three fee sources will first be reviewed, and relevant distribution mechanisms then explored.</p> <p><strong>Includer fee:</strong> One example is to allow transactions to specify an includer fee via a new field <code>max_includer_fee_per_gas</code>. To split the <code>max_includer_fee_per_gas</code> and the <code>max_priority_fee_per_gas</code> when they are capped by the <code>max_fee_per_gas</code>, the "aggregate-cap-divide" method outlined in the "pay-as-you-bid" subsection is the recommended approach. Alternatively, it is possible to distribute only the includer fee or the priority fee, depending on if the transaction was listed in an IL or not, and never both. The builder must then specify whether each transaction originated from an IL or not (at the transaction or IL level), and attesters vote against the block if the builder fails to make such an assignment when they observed the transaction in a timely IL.</p> <p><strong>Priority fee:</strong> It is possible to instead let the includers receive the priority fee if they list a transaction. The builder will have no choice but to include a transaction once it is listed by an includer, and the priority fee then serves little purpose. From the transactor's perspective, giving a priority fee to the builder for an IL transaction is a wasteful expenditure. Once again, with this option the builder must specify whether each transaction originated from an IL or not.</p> <p><strong>Marginal ranking fee:</strong> The marginal ranking fee can be distributed to includers instead of being burned. As discussed previously, one potential downside of this is the increase in rewards for engineering contention—in collaboration with builders—by first withholding transactions, and then releasing all transactions in the same block.</p> <p>The question is whether includers will be able to engineer such contention, given the coordination problem at hand: withholding transactions over several slots, with several slots' includers working together, where anyone breaking the cartel could reap higher rewards from transactors paying includers for their services. Transactors might also end up setting lower ranking fees if such an approach becomes systematic, and most ranking fees will likely anyway be in the region of 12.5% of the base fee. Finally, we do not see builders coordinating to bring down the base fee in order to reap higher priority fees today (at the same time, the control over the priority fee is indirect, and they do not directly attain the base fee).</p> <p>A potential benefit of distributing the marginal ranking fee to includers is that if the builder wishes to bribe includers to avoid contention (in order to bring up priority fees), then includers taking such a bribe would miss out on rewards for that contention (in addition to any rewards they may already miss out on from includer priority fees).</p> <h4 id="mechanisms-for-distributing-inclusion-fees-in-protocol">Mechanisms for distributing inclusion fees in-protocol</h4> <p>Four options for how to distribute the fee from any of the three in-protocol inclusion fee sources listed in the previous section will now be reviewed:</p> <p><strong>(1) Keyed distribution:</strong> Let transactors set one or several keys, with each key linking to one includer (i.e., validator ID) or to many includers (e.g., enabling all validators of an SSP to associate one key to all its validators). The protocol can then ensure that the rewards are distributed only to validators represented by a key, if it listed the transaction. This means that transactions shared with an includer privately still can use an in-protocol fee distribution without risking dilution. Options (2)-(4) below can be applied when the transactor does not provide a key or when the keyed includer(s) failed to list the transaction.</p> <p><strong>(2) Individual distribution:</strong> Split the fee between all includers listing a transaction. All includers then have an incentive to list a transaction, with the incentive being stronger if other includers have ignored it. It may however lead to unnecessary duplicate listings, since there is an incentive to list transactions even after they have been observed in another IL. It may also lead includers to integrate with builders to propagate the optimal IL by leveraging the builder's last look.</p> <p><strong>(3) Seniority distribution:</strong> Use a "seniority waterfall" rule. The transaction hash is combined with includer validator IDs to assign an order of seniority by which each includer has the right to the full includer fee. If a transaction's senior includer lists it, there is no purpose for a less senior includer to also list it. The idea is to promote a broader coverage while maintaining fairness. The mechanism will however not remove all duplicates, as a more senior includer will still list a transaction already listed by a less senior includer. It is straightforward to combine (1) with (3), by giving keyed includers the highest seniority, with remaining includers assigned a seniority based on the transaction hash. This could also prevent transaction hash grinding in the case when some senior includers are more reliable than others. Under the priority fee redistribution rule, the builder is in essence appended to the waterfall, having the lowest seniority.</p> <p>To further reduce duplicates, a potential extension could allow includers to stagger their inclusion list so that they first broadcast transactions they are the most senior includer for, and then append the list with transactions they are less senior for or that arrive late. This can also increase the includer's expected value (EV) since an early broadcast increases margins and the late broadcast allows for better coverage. Another way to increase EV under this rule is to combine it with (4) below. Each partial list must have timeliness observed in isolation, and the rules for IL equivocation must be amended to allow append operations.</p> <p><strong>(4) Collective distribution:</strong> Distribute the includer fee collectively to all includers. There is then no need to keep track of who propagated which transaction in which IL. It also serves to promote independence of includers. Builders cannot help includers to extract a relatively higher proportion of the ranking fee by constructing an optimal IL for them from their last look. Includers are further encouraged to facilitate as broad coverage as possible, given that there are no incentives to propagate a (high-paying) transaction if one of the other includers already propagates it. This means that some includers can pivot to propagating their ILs early, while others observe and select late or missed transactions.</p> <p>A downside is that includers are not incentivized individually to do a good job, and gain individually only 1/<code>IL_COMMITTEE_SIZE</code> of any ranking fee of a transaction they uniquely include. The point however is that the collective distribution alters the meaning of "doing a good job", aligning protocol design goals with includer incentives.</p> <p>Builders may try to bribe includers to not include transactions. If an includer will receive 1/<code>IL_COMMITTEE_SIZE</code> of any collective rewards for <em>not</em> including a transaction that eventually is not surfaced by any IL, then they may elect to leave it out to preserve space for other transactions. However, the builder would then also forego a sum corresponding to the entire collective rewards by paying out such bribes to the includers. In the setup where the priority fee is distributed to includers if they surface a transaction, the builder would thus need to forego the entire priority fee it stands to receive.</p> <p>However, due to the gradual construction of the aggregate IL, the builder can offer higher bribes than 1/<code>IL_COMMITTEE_SIZE</code> to the last remaining includers, to keep some transactions not yet included out of the IL aggregate. The last remaining includer that spots a late transaction might be able to choose between including it to receive 1/<code>IL_COMMITTEE_SIZE</code> of the priority fee, or to receive 1/2 of a conditional priority fee as a bribe to not include it.</p> <h3 id="alternative-specifications-for-the-auction-and-transaction-format">Alternative specifications for the auction and transaction format</h3> <h4 id="omit-the-new-transaction-format-with-its-added-ranking-fee-field">Omit the new transaction format with its added ranking fee field</h4> <p>Existing transaction formats are ranked using <code>max_fee_per_gas</code>. This may be sufficiently expressive, with the new transaction type omitted. The benefit is that it simplifies the UX. Transactors may not care about how much they have to pay to specifically cover the <code>marginal_ranking_fee_per_gas</code>—they have already specified how much they are willing to pay for inclusion in total with the <code>max_fee_per_gas</code>. It also simplifies the developer experience, since we do not need to change the transaction format.</p> <p>A potential downside is that transactors cannot differentiate between how high contention fees they are willing to pay to cover the base fee and to cover the marginal ranking fee in full blocks. The builder has some control over the marginal ranking fee: if there are transactions outside of the ILs that are willing to pay a higher fee for inclusion than the IL transactions, then it may or may not elect to include those transactions. This influences the marginal ranking fee which is determined by the highest offered ranking fee of an excluded IL transaction. It is more difficult for the builder to control the base fee. Transactors wishing to limit their ranking fees, while at the same time giving ample room for the base fee to rise before inclusion, may therefore find that older transaction formats do not offer sufficient expressiveness.</p> <h4 id="pay-as-you-bid-auction">Pay-as-you-bid auction</h4> <p>Two alternative pay-as-you-bid auction designs will now be highlighted. The first is that transactors always pay their offered ranking fee upon inclusion. In this case, there is no risk that the includers or the builder engineer contention for blockspace to drive up the price, and the full ranking fee is distributed to includers instead of being burned, using the collective method previously described. The post-execution check stays the same as in the main specification, with the only difference that the check on outranked IL transactions concerning the <code>marginal_ranking_fee_per_gas</code> (dashed line in the figure) is removed.</p> <p>Transaction processing is altered to, e.g., facilitate payment to includers. The split between the specified <code>max_ranking_fee_per_gas</code> and <code>max_priority_fee_per_gas</code> can be done in two ways. Either the ranking fee takes precedence over the priority fee as previously, or the two are given equal precedence. In the first case, the same strategy as in the main specification can be used. In the second case, the two fees can first be summed into a single <code>max_payout_fee_per_gas</code>, and the capped <code>payout_fee_per_gas</code> then distributed proportionally to the size of the original max ranking/priority fees.</p> <p>Additionally, the builder is given the ability to set a <code>priority_fee_shift_per_gas</code> parameter for each transaction to allow transactions without a sufficient <code>ranking_fee_per_gas</code> to become eligible for inclusion in the block. We can envision a scenario where the builder otherwise integrates deeper with transactors to help them set the optimal ranking fee anyway. Such an integration could have detrimental effects on the builder competitive landscape, and it is therefore desirable to allow the builder—who has the last look when building blocks—to raise the ranking fee as it sees fit in a trustless manner. This means that many transactors will elect to just provide a priority fee, and that there is limited downside for transactors using older transaction types.</p> <p>If a transactor believes that the builder may leave their transactions out of the block, then it is still well served by providing a ranking fee and propagating the transaction publicly so that it can be surfaced by an IL. The builder needs to boost all transactions up to the ranking fee of the transaction it wishes to exclude from the block, and a modest ranking fee can therefore be sufficient to ensure inclusion. The spec shows the ranking fee taking precedence and omits some overflow checks:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">for</span><span> i</span><span>,</span><span> unnormalized_transaction</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>transactions</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> After this existing check...</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..Optionally shift a proportion of the priority fee over to the ranking fee</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> &lt;=</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span></span> <span class="giallo-l"><span> max_priority_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span><span class="z-keyword"> -</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..then fill in order of: base fee, ranking fee, priority fee</span></span> <span class="giallo-l"><span> max_shifted_ranking_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>max_ranking_fee_per_gas</span><span class="z-keyword"> +</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span> ranking_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>max_shifted_ranking_fee_per_gas</span><span>,</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> -</span><span> block</span><span>.</span><span>base_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span> inclusion_fee_per_gas</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>base_fee_per_gas</span><span class="z-keyword"> +</span><span> ranking_fee_per_gas</span></span> <span class="giallo-l"><span> priority_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>max_priority_fee_per_gas</span><span>,</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> -</span><span> inclusion_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span> effective_gas_price</span><span class="z-keyword"> =</span><span> inclusion_fee_per_gas</span><span class="z-keyword"> +</span><span> priority_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..after refunding the transactor as normal, the includer fee is computed</span></span> <span class="giallo-l"><span> includer_fee</span><span class="z-keyword"> =</span><span> gas_used</span><span class="z-keyword"> *</span><span> ranking_fee_per_gas</span><span class="z-keyword"> //</span><span class="z-constant"> IL_COMMITTEE_SIZE</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..balances of the `IL_COMMITTEE_SIZE` includers increased</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> j</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">IL_COMMITTEE_SIZE</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>block</span><span>.</span><span>includer</span><span>(</span><span>j</span><span>)</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> includer_fee</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..and the priority fee is distributed to the builder just as in EIP-1559</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>block</span><span>.</span><span>author</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> gas_used</span><span class="z-keyword"> *</span><span> priority_fee_per_gas</span></span></code></pre> <p>The consensus layer (CL) constructs a list of execution-layer (EL) payout addresses for the slot, ordered by IL committee index, and provides it to the EL via a new engine API call: <code>engine_setIncluderPayoutsV1</code>. For committee members with <code>0x00</code> credentials, the CL inserts the zero address <code>0x000...</code>, thus burning these rewards.</p> <h4 id="pay-as-you-bid-auction-using-only-priority-fee">Pay-as-you-bid auction using only priority fee</h4> <p>A second alternative is to let the priority fee act as a ranking fee in a pay-as-you-bid auction. The priority fee is distributed collectively to includers if it was surfaced by at least one inclusion list. Otherwise it is distributed to the builder. <em>Only</em> priority fees distributed to the includers count towards the transaction's ranking.</p> <p>The builder specifies whether an included transaction was surfaced by an IL via a bitfield <code>IL_transaction</code> in the payload body, of equal length to the number of transactions. For all transactions where <code>IL_transaction[i]=FALSE</code>, the attesters check that they are not in any observed timely ILs, and otherwise return <code>INCLUSION_LIST_UNSATISFIED</code>. For these transactions, the builder can also apply the <code>priority_fee_shift_per_gas</code> described in the previous subsection, which however here is the same for all transactions since none have an initial ranking fee. Under <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, transaction processing is changed as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">...</span></span> <span class="giallo-l"><span class="z-keyword">for</span><span> i</span><span>,</span><span> unnormalized_transaction</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>transactions</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Processing begins after this existing line</span></span> <span class="giallo-l"><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> gas_refund</span><span class="z-keyword"> *</span><span> effective_gas_price</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Redistribute priority fee</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span class="z-constant">IL_transaction</span><span>[</span><span>i</span><span>]</span><span class="z-keyword">==</span><span class="z-constant">TRUE</span><span>:</span></span> <span class="giallo-l"><span> ranking_fee_per_gas</span><span class="z-keyword"> =</span><span> priority_fee_per_gas</span></span> <span class="giallo-l"><span> priority_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span><span class="z-keyword"> &lt;=</span><span> priority_fee_per_gas</span></span> <span class="giallo-l"><span> ranking_fee_per_gas</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span></span> <span class="giallo-l"><span> priority_fee_per_gas</span><span class="z-keyword"> -=</span><span> block</span><span>.</span><span>priority_fee_shift_per_gas</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The fee given to each includer (small division remainder burned)</span></span> <span class="giallo-l"><span> includer_fee</span><span class="z-keyword"> =</span><span> gas_used</span><span class="z-keyword"> *</span><span> ranking_fee_per_gas</span><span class="z-keyword"> //</span><span class="z-constant"> IL_COMMITTEE_SIZE</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Increase the balances of the `IL_COMMITTEE_SIZE` includers </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> j</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">IL_COMMITTEE_SIZE</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>block</span><span>.</span><span>includer</span><span>(</span><span>j</span><span>)</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> includer_fee</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Proposer receives the priority fee</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>block</span><span>.</span><span>author</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> gas_used</span><span class="z-keyword"> *</span><span> priority_fee_per_gas</span></span></code></pre> <p>Payout to includers uses the same CL construction as in the previous subsection and the check on the <code>marginal_ranking_fee_per_gas</code> (dashed line in the figure) is once again removed.</p> <p>If the ranking was based on the priority fee paid to the builder, the builder could offer kickbacks, allowing transactors to achieve a high ranking for free. To prevent this, the ranking portion of the fee must be distributed to a wider set of validators or be burned. Any arbitrary fee split between the builder and includers when <code>IL_transaction[i]=FALSE</code> would likely prove suboptimal and encourage off-chain agreements and builder–includer integration to circumvent the intended mechanism.</p> <h4 id="allow-builder-to-shift-priority-fee-under-upil">Allow builder to shift priority fee under UPIL</h4> <p>The <code>priority_fee_shift_per_gas</code> could be used also in the main UPIL specification. The primary rationale is that transactions using older formats then also can be included when <code>marginal_ranking_fee_per_gas&gt;0</code>, by having the builder reallocate the priority fee. Another option is to simply charge all base fees and ranking fees jointly for all transactions at the end of the block, as previously discussed.</p> <h4 id="upil-batch-auctions">UPIL batch auctions</h4> <p>A more extensive modification of the protocol is to make use of the improved CR and pricing of intra-block contention to eliminate the slack in the block, targeting 100% of the gas limit to facilitate scaling. The base fee can in such an implementation either be removed entirely, or the price information obtained via the marginal ranking fee can be relied upon for appropriate increases to the base fee.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Transactions using the <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> or <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> transaction formats can with this change spend up to their entire <code>max_fee_per_gas</code> to cover the <code>marginal_ranking_fee_per_gas</code> in blocks with high contention. Previously, the <code>max_fee_per_gas</code> could only be consumed by the <code>base_fee_per_gas</code> (which grows slowly each block) or the <code>priority_fee_per_gas</code> (which can be explicitly capped). A user setting <code>max_fee_per_gas</code> to twice the current <code>base_fee_per_gas</code>, while using a negligible <code>priority_fee_per_gas</code>, may be surprised to see the entire <code>max_fee_per_gas</code> consumed directly in the next block. However, this also implies that contention was high, and that they may have needed to spend the entire <code>max_fee_per_gas</code> for inclusion a few blocks later anyway. Importantly, the total fee paid will never exceed the <code>max_fee_per_gas</code> the user originally authorized.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP does not allow the builder to control which transactions that go into the block, with implications on CR and MEV. To retain full control over the block's content, the builder would have to bribe includers to not surface unwanted transactions. A concern then is that the builder bribes includers to not surface transactions, such that it can build the most profitable block, by excluding unwanted transactions. However, even if all includers were to be willing to forgo their duty to uphold CR if there is a profit to be made, the profit from surfacing transactions in the IL against a fee would reasonably be higher than whatever bribe a competitive builder is able to pay; especially if some includers have already taken the bribe, making remaining IL space more valuable. The option otherwise remains to distribute the marginal ranking fee to includers.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Renaud Duboishttps://github.com/rdubois-crypto Simon Massonhttps://github.com/simonmasson https://wg-eips.ritovision.com/8051/

Precompiled contracts for FIPS-204 ML-DSA signature verification and an EVM-optimized variant

<h2 id="abstract">Abstract</h2> <p>This proposal adds precompiled contracts that perform signature verifications using the NIST module-lattice signature scheme. Two instantiations are supported:</p> <ul> <li><strong>ML-DSA</strong> — NIST-compliant version using SHAKE256 (FIPS-204),</li> <li><strong>ML-DSA-ETH</strong> — EVM-optimized version for cheaper on-chain verification: <ul> <li>Uses Keccak-based PRNG instead of SHAKE256 (leverages native KECCAK256 precompile)</li> <li>Stores public-key polynomial <code>t1</code> in the NTT domain to skip one NTT during verification (convertible to regular encoding offline)</li> </ul> </li> </ul> <p>Two precompile contracts are specified:</p> <ul> <li><code>VERIFY_MLDSA</code> — verifies a ML-DSA signature compliant to FIPS-204.</li> <li><code>VERIFY_MLDSA_ETH</code> — verifies a ML-DSA-ETH signature replacing SHAKE256 with a more efficient hash function, deviating from FIPS-204.</li> </ul> <h2 id="motivation">Motivation</h2> <p>Quantum computers pose a long-term risk to classical cryptographic algorithms. In particular, signature algorithms based on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) such as secp256k1, are widely used in Ethereum and threatened by quantum algorithms. This exposes potentially on-chain assets and critical infrastructure to quantum adversaries.</p> <p>Integrating post-quantum signature schemes is crucial to future-proof Ethereum and other EVM-based environments. It shall be noted that infrastructure for post-quantum signatures should be deployed before quantum adversaries are known to be practical because it takes on the order of years for existing applications to integrate.</p> <p>Dilithium, a lattice-based scheme standardized by NIST as FIPS-204, offers high security against both classical and quantum adversaries. As the main winner of the standardization, the scheme has been selected as the main alternative to elliptic curve signature algorithms, making it a serious option for Ethereum.</p> <p>While the signature size (2.4kB) and public key size (1.3kB) are larger than other post-quantum candidates such as Falcon FN-DSA, this scheme is more flexible in terms of parameters. It is thus possible to derive a zero-knowledge version of Dilithium, keeping the security of the scheme together with an efficient in-circuit verification. This EIP does not dig into the details of this instance.</p> <p>ML-DSA has a simpler signer algorithm than FN-DSA, making hardware implementation easier. Finally, ML-DSA is based on the same mathematical construction as Kyber, the Post-Quantum Key Exchange algorithm standardized by NIST as FIPS-203. All these properties make ML-DSA well-suited for blockchain applications.</p> <p>In the context of the Ethereum Virtual Machine, a precompile for Keccak256 hash function is already available, making ML-DSA verification much faster when instantiated with an extendable output function derived from Keccak than with SHAKE256, as specified in NIST submission. This EIP specifies two versions of ML-DSA enabling two important features: one version being fully compliant with the NIST specification, the other deviating in encodings to reduce the gas cost.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>The following specification provides two precompiled contracts:</p> <table><thead><tr><th><strong>Precompiled contract</strong></th><th><strong>1</strong></th><th><strong>2</strong></th></tr></thead><tbody> <tr><td><strong>Name</strong></td><td><code>VERIFY_MLDSA</code></td><td><code>VERIFY_MLDSA_ETH</code></td></tr> <tr><td><strong>Address</strong></td><td>0x12</td><td>0x13</td></tr> <tr><td><strong>Gas cost</strong></td><td>4500</td><td>4500</td></tr> </tbody></table> <p>While ML-DSA can be instantiated for three security levels: NIST level II, III and IV, this EIP only covers NIST level II, corresponding to 128 bits of security.</p> <p>For the two variants of ML-DSA of this EIP, the following parameters are fixed:</p> <ul> <li>Polynomial degree: <code>n = 256</code>,</li> <li>Field modulus: <code>q = 8380417</code>,</li> <li>Matrix dimensions: <code>k=4</code>, <code>l=4</code>,</li> <li>Bounds of rejection: <code>γ_1 = 2¹⁷</code>, <code>γ_2 = (q-1)/88</code>, <code>β = 78</code>,</li> <li>Additional parameters: <code>η = 2</code>, <code>τ = 39</code>, <code>d = 13</code>.</li> </ul> <p>These parameters strictly follow NIST. More precisely, <code>q</code>, <code>n</code>, <code>k</code>, <code>l</code> and <code>η</code> are chosen in order to ensure a hard MLWE related problem, and the remaining parameters are chosen for the hardness of MSIS as well as for the efficiency of the scheme. The parameter <code>β = τ * η = 78</code> is the norm bound used in the rejection condition <code>||z||_∞ &lt; γ_1 - β</code> for the ML-DSA-44 parameter set in FIPS-204.</p> <p>In terms of storage, ML-DSA public key can be derived by the verifier, making the overall public key of 1312 bytes. However, this increases the verifier cost, making the on-chain verification too expensive from a practical point of view. In this EIP, the verification algorithm takes the public key in raw format, meaning that the storage for the public key is:</p> <ul> <li>The full matrix <code>A_hat</code> of 16 384 bytes,</li> <li><code>tr</code> is stored in order to save one hash, with 32 bytes,</li> <li><code>t1</code> is stored in the NTT domain in order to save one NTT, with 4096 bytes.</li> </ul> <p>The overall storage for the <strong>public key</strong> is <strong>20512 bytes</strong>. The signature follows the same format as specified in FIPS-204: 32 bytes for <code>c_tilde</code>, 2304 bytes for the coefficients of <code>z</code>, and 84 bytes for <code>h</code>. In total, a <strong>signature</strong> requires <strong>2420 bytes</strong>.</p> <h3 id="sub-algorithms-of-ml-dsa">Sub-algorithms of ML-DSA</h3> <h4 id="number-theoretic-transform">Number Theoretic Transform</h4> <p>Polynomial arithmetic is computed efficiently using Number Theoretic Transform (NTT). Efficient polynomial multiplication can be implemented following the draft NTT EIP. NTT inverse cost is roughly the same as an NTT: $n\log(n)$ additions and $n/2 \log(n)$ multiplications over the field $\mathbb F_q$, where $q=8380417$ and $n=256$.</p> <h4 id="extendable-output-function">EXtendable Output Function</h4> <p>The verification algorithm requires an eXtendable Output Function (XOF) made from a hash function. This EIP provides two instantiations of a XOF:</p> <ul> <li>SHAKE256 is the XOF provided in NIST submission, a sponge construction derived from SHA256. Extracting bytes using SHAKE256 calls the <code>Keccak_f</code> permutation as described in Section 3.7 of FIPS-204. While this construction is standardized, it is expensive when computed in the Ethereum Virtual Machine because <code>Keccak_f</code> has no EVM opcode.</li> <li>Keccak-PRNG is a XOF that is build from a counter-mode PRNG based on Keccak256. Generating new chunks of bytes requires an incrementing counter, as described in NIST SP800-90A revision 1. This XOF has the same interface as SHAKE256, but requires a <code>flip()</code> function that initiate a counter to <code>0</code>. Then, the <code>squeeze</code> function outputs as many bytes as needed using a counter mode as specified in SP800-90A revision 1. A precompile of <code>Keccak256</code> is available in the Ethereum Virtual Machine, making this XOF very efficient in the EVM.</li> </ul> <h4 id="hints-in-ml-dsa">Hints in ML-DSA</h4> <p>ML-DSA requires some hint computation. More precisely, the function <code>use_hint</code> must be implemented following Algorithm 40 of FIPS-204. The output hint is a polynomial with coefficients in {0,1}. Another function <code>sum_hint</code> is required, and counts the number of non-zero values of the hint.</p> <h4 id="sample-in-ball-challenge">Sample In Ball Challenge</h4> <p>In ML-DSA, a challenge is computed using a XOF. This algorithm <code>sample_in_ball</code> outputs a polynomial with τ small coefficients (in {-1,1}). The values of the coefficients as well as the position in the coefficients list is obtained using the XOF, as specified in Algorithm 29 of FIPS-204.</p> <h3 id="ml-dsa-verification-algorithm">ML-DSA verification algorithm</h3> <p>Verifying a ML-DSA signature follows Algorithm 8 of FIPS-204, with <code>A_hat</code> of the public key stored in expanded format, and <code>t1</code> stored in the NTT domain.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> VERIFY_MLDSA</span><span>(</span><span class="z-variable z-parameter z-function">public_key</span><span>,</span><span class="z-variable z-parameter z-function"> message</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span> A_hat</span><span>,</span><span> tr</span><span>,</span><span> t1</span><span> are</span><span> decoded</span><span class="z-keyword"> from</span><span> public_key</span></span> <span class="giallo-l"><span> c_tilde</span><span>,</span><span> z</span><span>,</span><span> h</span><span> are</span><span> decoded</span><span class="z-keyword"> from</span><span> signature</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> h</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span> properly</span><span> encoded</span><span>,</span><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> μ</span><span class="z-keyword"> =</span><span> shake_256</span><span>(</span><span>tr</span><span class="z-keyword">+</span><span>message</span><span>)</span><span>.</span><span>extract</span><span>(</span><span class="z-constant">64</span><span>)</span></span> <span class="giallo-l"><span> c</span><span class="z-keyword"> =</span><span> sample_in_ball</span><span>(</span><span>c_tilde</span><span>,</span><span> τ</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> computed in the NTT domain</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> three NTTs for c and z, and t1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> one final inverse NTT.</span></span> <span class="giallo-l"><span> Az_minus_ct1</span><span class="z-keyword"> =</span><span> A_hat</span><span class="z-keyword"> *</span><span> z</span><span class="z-keyword"> -</span><span> c</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">2</span><span class="z-keyword">^</span><span>d</span><span class="z-keyword"> *</span><span> t1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> w_prime</span><span class="z-keyword"> =</span><span> h</span><span>.</span><span>use_hint</span><span>(</span><span>Az_minus_ct1</span><span>,</span><span class="z-constant"> 2</span><span class="z-keyword">*</span><span>γ_2</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> check_norm_bound</span><span>(</span><span>z</span><span>,</span><span> γ_1</span><span class="z-keyword"> -</span><span> β</span><span>)</span><span class="z-keyword"> and</span><span> c_tilde</span><span class="z-keyword"> ==</span><span> shake_256</span><span>(</span><span>μ</span><span class="z-keyword"> +</span><span> w_prime</span><span>)</span><span>.</span><span>extract</span><span>(</span><span class="z-constant">32</span><span>)</span></span></code></pre><h3 id="ml-dsa-eth-verification-algorithm">ML-DSA-ETH verification algorithm</h3> <p>The verification of ML-DSA-ETH signatures follows the same algorithm with another hash function, with two differences:</p> <ul> <li><code>t1</code> from the public key is stored in the NTT domain in order to save one NTT. The multiplication by <code>2^d</code> is also precomputed. Note that this change can be seen as a change of representation.</li> <li>A variant of <code>sample_in_ball</code> is defined using KeccakPRNG. The only difference from Algorithm 29 of FIPS-204 is that it requires a <code>flip()</code> between lines 3 and 4 so that it initializes the counter to <code>0</code> before starting squeezing. Note that this can be implemented in <code>absorb()</code> and <code>squeeze()</code> so that the same interface can be used as in SHAKE256.</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> VERIFY_MLDSA_ETH</span><span>(</span><span class="z-variable z-parameter z-function">public_key</span><span>,</span><span class="z-variable z-parameter z-function"> message</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span> A_hat</span><span>,</span><span> tr</span><span>,</span><span> t1</span><span> are</span><span> decoded</span><span class="z-keyword"> from</span><span> public_key</span></span> <span class="giallo-l"><span> c_tilde</span><span>,</span><span> z</span><span>,</span><span> h</span><span> are</span><span> decoded</span><span class="z-keyword"> from</span><span> signature</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> h</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span> properly</span><span> encoded</span><span>,</span><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> μ</span><span class="z-keyword"> =</span><span> keccak_prng</span><span>(</span><span>tr</span><span class="z-keyword">+</span><span>message</span><span>)</span><span>.</span><span>extract</span><span>(</span><span class="z-constant">64</span><span>)</span></span> <span class="giallo-l"><span> c</span><span class="z-keyword"> =</span><span> sample_in_ball_keccak_prng</span><span>(</span><span>c_tilde</span><span>,</span><span> τ</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> computed in the NTT domain</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> two NTTs for c and z</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> one final inverse NTT.</span></span> <span class="giallo-l"><span> Az_minus_ct1</span><span class="z-keyword"> =</span><span> A_hat</span><span class="z-keyword"> *</span><span> z</span><span class="z-keyword"> -</span><span> c</span><span class="z-keyword"> *</span><span> t1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> w_prime</span><span class="z-keyword"> =</span><span> h</span><span>.</span><span>use_hint</span><span>(</span><span>Az_minus_ct1</span><span>,</span><span class="z-constant"> 2</span><span class="z-keyword">*</span><span>γ_2</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> check_norm_bound</span><span>(</span><span>z</span><span>,</span><span> γ_1</span><span class="z-keyword"> -</span><span> β</span><span>)</span><span class="z-keyword"> and</span><span> c_tilde</span><span class="z-keyword"> ==</span><span> keccak_prng</span><span>(</span><span>μ</span><span class="z-keyword"> +</span><span> w_prime</span><span>)</span><span>.</span><span>extract</span><span>(</span><span class="z-constant">32</span><span>)</span></span></code></pre><h3 id="required-checks-in-ml-dsa-eth-verification">Required checks in ML-DSA(-ETH) verification</h3> <ul> <li>The hint <code>h</code> needs to be properly encoded. The malformation of the hint is specified in Algorithm 21 of FIPS-204.</li> <li>The element <code>z</code> must have a norm satisfying <code>||z||_∞ &lt; γ_1 - β</code>. The norm <code>||.||_∞</code> is defined page 6 of FIPS-204.</li> <li>The final hash output must be equal to the signature bytes <code>c_tilde</code>.</li> </ul> <h3 id="precompiled-contract-specification">Precompiled contract specification</h3> <h3 id="ml-dsa-precompiled-contract">ML-DSA precompiled contract</h3> <p>The precompiled contract VERIFY_MLDSA is proposed with the following input and outputs, which are big-endian values:</p> <ul> <li><strong>Input data</strong> <ul> <li>32 bytes for the message</li> <li>2420 bytes for ML-DSA signature</li> <li>20512 bytes for the ML-DSA expanded public key</li> </ul> </li> <li><strong>Output data</strong>: <ul> <li>If the algorithm process succeeds, it returns 1 in 32 bytes format.</li> <li>If the algorithm process fails, it returns 0 in 32 bytes format.</li> </ul> </li> </ul> <h4 id="error-cases">Error Cases</h4> <ul> <li>Insufficient gas has been provided.</li> <li>Invalid input length (not compliant to described input)</li> <li>Invalid field element encoding (≥ q)</li> <li>Invalid norm bound</li> <li>Invalid hint check</li> <li>Signature verification failure</li> </ul> <h3 id="ml-dsa-eth-precompiled-contract">ML-DSA-ETH precompiled contract</h3> <p>The precompiled contract VERIFY_MLDSA_ETH is proposed with the following input and outputs, which are big-endian values:</p> <ul> <li><strong>Input data</strong> <ul> <li>32 bytes for the message</li> <li>2420 bytes for ML-DSA-ETH signature</li> <li>20512 bytes for the ML-DSA-ETH expanded public key</li> </ul> </li> <li><strong>Output data</strong>: <ul> <li>If the algorithm process succeeds, it returns 1 in 32 bytes format.</li> <li>If the algorithm process fails, it returns 0 in 32 bytes format.</li> </ul> </li> </ul> <h4 id="error-cases-1">Error Cases</h4> <ul> <li>Insufficient gas has been provided.</li> <li>Invalid input length (not compliant to described input)</li> <li>Invalid field element encoding (≥ q)</li> <li>Invalid norm bound</li> <li>Invalid hint check</li> <li>Signature verification failure</li> </ul> <h3 id="precompiled-contract-gas-usage">Precompiled contract gas usage</h3> <p>The cost of the <strong>VERIFY_MLDSA</strong> and <strong>VERIFY_MLDSA_ETH</strong> functions is dominated by the call to the NTTs, and the required hash calls for sampling in the ball (and for μ and the final check). It represents in average 5 calls to the hash function. Taking linearly the cost of keccak256, and avoiding the context switching it represents 4500 gas.</p> <h3 id="compliance-with-eip-7932">Compliance with EIP-7932</h3> <p>In compliance with <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>, the necessary parameters and structure for its integration are provided. <code>ALG_TYPE = 0xD1</code> uniquely identifies ML-DSA transactions, set MAX_SIZE = 2441 bytes to accommodate the fixed-length signature_info container, and recommend a <code>GAS_PENALTY</code> of approximately <code>3000</code> gas subject to benchmarking. The verification function follows the <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a> model, parsing the signature_info, recovering the corresponding Dilithium public key, verifying the signature against the transaction payload hash, and deriving the signer's Ethereum address as the last 20 bytes of keccak256(pubkey). This definition ensures that ML-DSA can be cleanly adopted within the <code>AlgorithmicTransaction</code> container specified by <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>signature_info</span><span class="z-keyword"> =</span><span> Container</span><span>[</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0xD1 for ML-DSA (NIST-compliant version),</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0xD2 for ML-DSA-ETH (EVM-friendly version),</span></span> <span class="giallo-l"><span> version</span><span>:</span><span> uint8</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ML-DSA signature</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> ByteVector</span><span>[</span><span class="z-constant">2420</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> keccak256(pubkey)[12:]</span></span> <span class="giallo-l"><span> pubkey_hash</span><span>:</span><span> ByteVector</span><span>[</span><span class="z-constant">20</span><span>]</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>In the format of EIP-7932:</p> <ul> <li>For the NIST-compliant version:</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>verify</span><span>(</span><span>signature_info</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span> payload_hash</span><span>:</span><span> Hash32</span><span>)</span><span class="z-invalid z-illegal"> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature_info</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 2441</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">2421</span><span>]</span></span> <span class="giallo-l"><span> pubkey_hash</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">2421</span><span>:</span><span class="z-constant">2441</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> version</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">D1</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> lookup_pubkey</span><span>(</span><span>pubkey_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> VERIFY_MLDSA</span><span>(</span><span>pubkey</span><span>,</span><span> payload_hash</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> pubkey</span></span></code></pre> <ul> <li>For the EVM-friendly version:</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>verify</span><span>(</span><span>signature_info</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span> payload_hash</span><span>:</span><span> Hash32</span><span>)</span><span class="z-invalid z-illegal"> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature_info</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 2441</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">2421</span><span>]</span></span> <span class="giallo-l"><span> pubkey_hash</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">2421</span><span>:</span><span class="z-constant">2441</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> version</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">D2</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> lookup_pubkey</span><span>(</span><span>pubkey_hash</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> VERIFY_MLDSA_ETH</span><span>(</span><span>pubkey</span><span>,</span><span> payload_hash</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> pubkey</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The ML-DSA scheme was selected as a NIST-standardized post-quantum cryptographic algorithm due to its strong security guarantees and efficiency.</p> <p>ML-DSA is a signature algorithm build from lattice-based cryptography. Specifically, its hardness relies on the Short Integer Solution (SIS) problem and the Learning With Errors (LWE) problem, which is believed to be hard for both classical and quantum computers.</p> <p>ML-DSA (based on CRYSTALS-Dilithium) offers a strong balance between security, efficiency, and practicality compared to classical ECC and other post-quantum schemes. Its signature and key sizes remain reasonably small, making it practical for real-world deployments such as Ethereum blockchain. As the main winner of the NIST PQC standardization process, it benefits from a broad community consensus on its security, which is not yet the case for many alternatives. Moreover, its lattice-based structure allows flexible parameter tuning, making it easier to adapt for specialized contexts like zero-knowledge proofs. Schemes like Falcon (FN-DSA, another signature scheme built on top of lattice-based assumptions) have a more rigid parameterization, making zero-knowledge circuits larger, and thus proof computation more expensive.</p> <p>Given the increasing urgency of transitioning to quantum-resistant cryptographic primitives or even having them ready in the event that research into quantum computers speeds up.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>A set of test vectors for verifying implementations is located in a separate file (see explanations in <a href="https://wg-eips.ritovision.com/8051/assets/README/">this file</a>):</p> <ul> <li>The file <a href="https://wg-eips.ritovision.com/8051/./assets/mldsa_nist.rsp"><code>mldsa_nist.rsp</code></a> containing the NIST submission KAT file for security level II.</li> <li>The file <a href="https://wg-eips.ritovision.com/8051/./assets/mldsa_evm.rsp"><code>mldsa_evm.rsp</code></a> containing test vectors for the EVM-friendly version with the same format as NIST.</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>The reference implementation is the NIST submission code for ML-DSA. A reference implementation is provided by ZKNOX for the EVM-friendly version ML-DSA-ETH.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The derivation path to obtain the private key from the seed is (tbd).</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Maria Silvahttps://github.com/misilva73 Wei Han Nghttps://github.com/weiihann Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/8038/

Increases the gas cost of state-access operations to reflect Ethereum’s larger state

<h2 id="abstract">Abstract</h2> <p>This EIP updates the gas cost of state-access operations to reflect Ethereum's larger state and the consequent slowdown of these operations. It raises the base costs for <code>GAS_STORAGE_UPDATE</code>, <code>GAS_COLD_SLOAD</code>, and <code>GAS_COLD_ACCOUNT_ACCESS</code> and updates the access cost for <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code>. The design coordinates with <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>: before EIP-8032, parameters assume worst-case contract size; after EIP-8032, they assume worst-case up to <code>ACTIVATION_THRESHOLD</code>, with additional depth-based scaling beyond.</p> <h2 id="motivation">Motivation</h2> <p>The gas price of accessing state has not been updated for quite some time. <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> was included in the Berlin fork in March 2021 and raised the costs of state-accessing opcodes. Yet, since then, Ethereum's state has grown significantly, thus deteriorating the performance of these operations. This proposal further raises state access costs to better align them with the current performance of state access operations, in relation to other operations.</p> <p>Additionally, <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> have the same access cost as <code>BALANCE</code> and <code>EXTCODEHASH</code>. However, <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> require two database reads - first to load the account object (which includes the <code>nonce</code>, <code>balance</code>, <code>codeHash</code> and <code>storageRoot</code>), and second to collect the required information (the code size and bytecode respectively). Therefore, the access cost of <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> should be higher when compared with the other account read operations.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <p>Upon activation of this EIP, the following parameters of the gas model are renamed:</p> <table><thead><tr><th style="text-align: center"><strong>Parameter</strong></th><th style="text-align: center"><strong>New name</strong></th></tr></thead><tbody> <tr><td style="text-align: center"><code>GAS_STORAGE_UPDATE</code></td><td style="text-align: center"><code>GAS_COLD_STORAGE_WRITE</code></td></tr> <tr><td style="text-align: center"><code>GAS_COLD_SLOAD</code></td><td style="text-align: center"><code>GAS_COLD_STORAGE_ACCESS</code></td></tr> </tbody></table> <p>The following parameters of the gas model are updated:</p> <table><thead><tr><th style="text-align: center"><strong>Parameter</strong></th><th style="text-align: center"><strong>Current value</strong></th><th style="text-align: center"><strong>New value</strong></th><th style="text-align: center"><strong>Increase</strong></th><th style="text-align: center"><strong>Operations affected</strong></th></tr></thead><tbody> <tr><td style="text-align: center"><code>GAS_COLD_STORAGE_WRITE</code></td><td style="text-align: center">5,000</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>SSTORE</code></td></tr> <tr><td style="text-align: center"><code>GAS_COLD_STORAGE_ACCESS</code></td><td style="text-align: center">2,100</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>SSTORE</code> and <code>SLOAD</code></td></tr> <tr><td style="text-align: center"><code>GAS_COLD_ACCOUNT_ACCESS</code></td><td style="text-align: center">2,600</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>*CALL</code> opcodes, <code>BALANCE</code>, <code>SELFDESTRUCT</code> and <code>EXT*</code> opcodes</td></tr> <tr><td style="text-align: center"><code>GAS_WARM_ACCESS</code></td><td style="text-align: center">100</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>SSTORE</code>, <code>SLOAD</code>, <code>*CALL</code> opcodes, <code>BALANCE</code> and <code>EXT*</code> opcodes</td></tr> <tr><td style="text-align: center"><code>GAS_STORAGE_CLEAR_REFUND</code></td><td style="text-align: center">4,800</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>SSTORE</code></td></tr> <tr><td style="text-align: center"><code>ACCESS_LIST_STORAGE_KEY_COST</code></td><td style="text-align: center">1,900</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>SSTORE</code> and <code>SLOAD</code></td></tr> <tr><td style="text-align: center"><code>ACCESS_LIST_ADDRESS_COST</code></td><td style="text-align: center">2,400</td><td style="text-align: center">TBD</td><td style="text-align: center">TBD</td><td style="text-align: center"><code>*CALL</code> opcodes, <code>BALANCE</code>, <code>SELFDESTRUCT</code> and <code>EXT*</code> opcodes</td></tr> </tbody></table> <p>&lt;-- TODO --&gt;</p> <h3 id="ext-family-update"><code>EXT*</code> family update</h3> <p>Besides these parameter changes, the gas cost formula for <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> is updated to include an additional <code>GAS_WARM_ACCESS</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> address</span><span class="z-keyword"> in</span><span> evm</span><span>.</span><span>accessed_addresses</span><span>:</span></span> <span class="giallo-l"><span> access_gas_cost</span><span class="z-keyword"> =</span><span class="z-constant"> GAS_WARM_ACCESS</span><span class="z-keyword">*</span><span class="z-constant">2</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>accessed_addresses</span><span>.</span><span>add</span><span>(</span><span>address</span><span>)</span></span> <span class="giallo-l"><span> access_gas_cost</span><span class="z-keyword"> =</span><span class="z-constant"> GAS_COLD_ACCOUNT_ACCESS</span><span class="z-keyword"> +</span><span class="z-constant"> GAS_WARM_ACCESS</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="benchmarking">Benchmarking</h3> <p>This proposal does not yet have finalized numbers. To achieve this, we require stateful benchmarks, which are currently in development. Once we collect that data, we will set the final numbers.</p> <p>&lt;-- TODO --&gt;</p> <h3 id="special-case-for-extcodesize-and-extcodecopy">Special case for <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code></h3> <p>Differently from other account read operations, <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> make two reads to the database. The first read is the same, where the object of the target account is loaded. This object includes the account's <code>nonce</code>, <code>balance</code>, <code>codeHash</code> and <code>storageRoot</code>. Then, these operations do another read to collect either the code size or the bytecode of the account. This second read is to an already warmed account, and thus we propose to price it as <code>GAS_WARM_ACCESS</code> for consistency.</p> <h3 id="interaction-with-eip-8032">Interaction with <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a></h3> <p><a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a> proposes modifying the <code>SSTORE</code> cost formula to account for the storage size of a contract. This is a more accurate method for pricing storage writes. It allows writes to smaller contracts to be cheaper than writes to large contracts, which helps with scaling and is fairer to users. However, <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a> is not yet scheduled for inclusion in a fork, and, as such, this proposal considers two cases for setting the values of <code>GAS_COLD_STORAGE_WRITE</code> and <code>GAS_COLD_STORAGE_ACCESS</code>:</p> <ol> <li>Before <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>. In this case, we set the parameters assuming a worst-case contract size, which makes state-accessing operations more expensive, independently of the contract size.</li> <li>After <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>. In this case, we set the parameters assuming the worst-case until <code>ACTIVATION_THRESHOLD</code>, which is the parameter in <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a> that triggers the depth-based cost. This means that contract sizes below the threshold have the same access costs, while contracts above the threshold get exponentially more expensive with increasing size.</li> </ol> <h3 id="interaction-with-eip-2926">Interaction with <a href="https://wg-eips.ritovision.com/2926/">EIP-2926</a></h3> <p><a href="https://wg-eips.ritovision.com/2926/">EIP-2926</a> proposes to change how code is store in the state trie. One of the changes of this proposal is to include the code size as a new field in the account object (<code>codeSize</code>). With this change, the code size can be directly accessed with a single read to the database and thus <code>EXTCODESIZE</code> should maintain its previous cost formula, without including the additional <code>GAS_WARM_ACCESS</code>.</p> <h3 id="interaction-with-eip-7928">Interaction with <a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a></h3> <p><a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a> introduces Block-Level Access Lists, which enable parallel disk reads, parallel transaction validation, and executionless state updates through client optimizations. The initial benchmarks won't take into consideration these optimizations.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Wallet developers and node operators MUST update gas estimation handling to accommodate the new state access cost rules. Specifically:</p> <ul> <li>Wallets: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.</li> <li>Node Software: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation with the new state access cost values.</li> </ul> <p>Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Changing the cost of state access operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson Francesco D'Amatohttps://github.com/fradamt Maria Silvahttps://github.com/misilva73 https://wg-eips.ritovision.com/8075/

Track state bytes and target 250 MiB/day by dynamically adjusting the state gas cost. Exempt state from the gas limit to facilitate scaling.

<h2 id="abstract">Abstract</h2> <p>This EIP precisely caps state growth while at the same time facilitating between 50%-300% more non-state operations per block compared to when solely raising the state gas cost. The cap is achieved by tracking state creation and having a dedicated <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> style fee market mechanism set the cost, to target 250 MiB per day. To preserve the existing transaction format and EVM execution patterns, state is still priced in gas during transaction processing. The state creation gas cost is updated every block, adjusting slowly so that users can set reasonable gas limits. The byte-level harmonization of state creation operations provided by <a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a> is then still applied. To facilitate scaling, state creation and regular gas have separate limits, but a normalized aggregate gas is used when calculating the base fee.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum is currently focused on scaling the layer 1, with a rapid expansion of the block gas limit foreseen in the near-term from compute and memory optimization, as well as via headliner proposals <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a> and <a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a>. Unfortunately, if the gas cost for state creation is kept fixed, state would likely expand in line with an expanding gas limit. As client database sizes increase, degradation in performance is expected. <a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a> addresses state growth by harmonizing current state creation costs according to how many bytes they add to the state. It also increases the gas cost of state creation significantly, by between 3x and 9.5x per operation.</p> <p>It can be assumed that increased gas costs will somewhat keep state from expanding in line with the increased gas limit. However, since the price-elasticity of demand for state creation is unknown, it is impossible to say exactly what the effect would be. Users may not be particularly sensitive to the increased state gas costs and still continue to purchase state relative to other resources similar to present usage patterns, given that the overall base fee may also fall from the increased gas limit. This would have two effects:</p> <ol> <li>State would continue to expand by a higher rate than desired.</li> <li>Under equilibrium, well over 50% of all consumed gas may be spent on state. As further analyzed in the Rationale, a possible equilibrium outcome is 78.5% under current usage pattern and 64.7% even if users only create half as many state bytes for every gas they spend on other operations, relative to today. This impedes scaling under the current one-dimensional fee market, because state gas crowds out gas that can be used for other resources such as compute.</li> </ol> <p>To confidently target some specific state growth, it is necessary to dynamically vary the price of state creation according to its usage. The <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> mechanism is then particularly suitable. This proposal tracks <code>state_bytes_created</code> and <code>state_bytes_cleared</code> each block and keep a running counter of <code>excess_state_bytes</code>. When <code>state_bytes_created - state_bytes_cleared</code> exceeds the target, <code>excess_state_bytes</code> increases, resulting in an increase to the gas charged per state byte. Users should not need to attach excessive margins to the transaction gas limit without risking transactions failure, and the gas charged per state byte is thus set to vary very moderately between blocks, at 0.1% at the very most.</p> <p>To not impede scaling when a higher gas is charged per state byte, it is necessary to exempt state gas from the block gas limit. This is achieved by tracking the <code>regular_gas</code> and <code>state_gas</code> separately, having a separate limit for each. To ensure that the base fee still prices usage across all resources, the base fee update still operates on a normalized aggregate of both. Thus, the smooth shift in the gas charged per state byte can be understood as a separate control mechanism for pricing state <em>relative</em> to all other operations, facilitating good load-balancing over time. It is however not a mechanism that prices state creation in isolation—the base fee still applies to all resources.</p> <h2 id="specification">Specification</h2> <p>The full specification is available <a rel="external" href="https://github.com/ethereum/execution-specs/commit/d64f82b18db8c0ae35f3c56e1762ace9d83ba578">here</a>.</p> <h3 id="parameters">Parameters</h3> <p>Four constants have a similar role as in EIP-4844.</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>STATE_GAS_UPDATE_FRACTION</code></td><td><code>36_418_000</code></td></tr> <tr><td><code>TARGET_STATE_BYTES_PER_BLOCK</code></td><td><code>36_400</code></td></tr> <tr><td><code>MAX_STATE_BYTES_PER_BLOCK</code></td><td><code>2 * TARGET_STATE_BYTES_PER_BLOCK</code></td></tr> <tr><td><code>MIN_STATE_GAS_PER_BYTE</code></td><td><code>380</code></td></tr> </tbody></table> <p>The <code>STATE_GAS_UPDATE_FRACTION</code> is chosen so that a block that uses <code>MAX_STATE_BYTES_PER_BLOCK</code> can increase state_gas_per_byte by at most 0.1%. It was computed as <code>(MAX_STATE_BYTES_PER_BLOCK - TARGET_STATE_BYTES_PER_BLOCK) / ln(1.001)</code>, rounded to the nearest thousand.</p> <p>The number of bytes assigned to each state operation follows EIP-8037.</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>CREATE_BYTES</code></td><td><code>112</code></td></tr> <tr><td><code>CODE_DEPOSIT_BYTES</code></td><td><code>1</code></td></tr> <tr><td><code>NEW_ACCOUNT_BYTES</code></td><td><code>112</code></td></tr> <tr><td><code>STORAGE_SET_BYTES</code></td><td><code>32</code></td></tr> <tr><td><code>PER_EMPTY_ACCOUNT_BYTES</code></td><td><code>112</code></td></tr> <tr><td><code>PER_AUTH_BASE_BYTES</code></td><td><code>23</code></td></tr> </tbody></table> <h3 id="header-extension">Header extension</h3> <p>The current header encoding is extended with three new 64-bit unsigned integer fields.</p> <ul> <li><code>state_bytes_created</code> is the number of state bytes that were created in the current block.</li> <li><code>state_bytes_cleared</code> is the number of state bytes that were cleared in the current block.</li> <li><code>excess_state_bytes</code> is a running total of state bytes created in excess of the target, prior to the block. Blocks with above-target state bytes creation increase this value, blocks with below-target state bytes creation decrease it (bounded at 0).</li> </ul> <p>The header sequence of the new fields is <code>[..., TBD, state_bytes_created, state_bytes_cleared, excess_state_bytes]</code>.</p> <p>We also rename the <code>gas_used</code> field to <code>regular_gas_used</code>:</p> <ul> <li><code>regular_gas_used</code> is the regular gas used in the block, ignoring gas spent on state creation.</li> </ul> <h3 id="evm-gas-accounting">EVM gas accounting</h3> <p>During processing, the protocol tracks <code>regular_gas</code> and <code>state_gas</code> separately, and returns the aggregate <code>gas_used</code> accounting for refunds, similar to today. Furthermore, <code>regular_gas_used</code> (without refunds to satisfy <a href="https://wg-eips.ritovision.com/7778/">EIP-7778</a>) is returned to count against the block limit. Finally, the protocol also tracks <code>state_bytes_created</code> and <code>state_bytes_cleared</code>, allowing for a more accurate tracking of the <code>excess_state_bytes</code>. These are returned in the list <code>state_bytes(created, cleared)</code>.</p> <h3 id="computing-the-state-gas-per-byte">Computing the state gas per byte</h3> <p>The protocol keeps track of <code>excess_state_bytes</code>, and computes the <code>state_gas_per_byte</code> from that variable (referred to as <code>cost_per_state_byte</code> in EIP-8037). The same update mechanism as in EIP-4844 is applied.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_state_gas_per_byte</span><span>(</span><span class="z-variable z-parameter z-function">header</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_STATE_GAS_PER_BYTE</span><span>,</span></span> <span class="giallo-l"><span> header</span><span>.</span><span>excess_state_bytes</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> STATE_GAS_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>The <code>STATE_GAS_UPDATE_FRACTION</code> is set so that the maximum increase in <code>state_gas_per_byte</code> is 0.1%, when a block consumes <code>MAX_STATE_BYTES_PER_BLOCK</code>. The <code>state_gas_per_byte</code> has a floor of <code>MIN_STATE_GAS_PER_BYTE</code>, corresponding to EIP-8037 when scaled down to a 60M block gas limit. The <code>excess_state_bytes</code> are updated as in EIP-4844, but accounting for both created and cleared state bytes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_state_bytes</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>excess_state_bytes</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>state_bytes_created</span></span> <span class="giallo-l"><span> deficit</span><span class="z-keyword"> =</span><span class="z-constant"> TARGET_STATE_BYTES_PER_BLOCK</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>state_bytes_cleared</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> excess</span><span class="z-keyword"> &lt;</span><span> deficit</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> excess</span><span class="z-keyword"> -</span><span> deficit</span></span></code></pre><h3 id="updating-state-gas-costs-for-the-block">Updating state gas costs for the block</h3> <p>The block level gas cost for each state operation is computed as <code>GAS_STATE_OPERATION = STATE_OPERATION_BYTES * state_gas_per_byte</code>. For completeness, the function below specifies this for all operations:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> update_state_op_costs</span><span>(</span><span class="z-variable z-parameter z-function">state_gas_per_byte</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> GAS_CREATE</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> CREATE_BYTES</span></span> <span class="giallo-l"><span class="z-constant"> GAS_CODE_DEPOSIT</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> CODE_DEPOSIT_BYTES</span></span> <span class="giallo-l"><span class="z-constant"> GAS_NEW_ACCOUNT</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> NEW_ACCOUNT_BYTES</span></span> <span class="giallo-l"><span class="z-constant"> GAS_STORAGE_SET</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> STORAGE_SET_BYTES</span></span> <span class="giallo-l"><span class="z-constant"> PER_EMPTY_ACCOUNT_COST</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> PER_EMPTY_ACCOUNT_BYTES</span></span> <span class="giallo-l"><span class="z-constant"> PER_AUTH_BASE_COST</span><span class="z-keyword"> =</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span class="z-constant"> PER_AUTH_BASE_BYTES</span></span></code></pre><h3 id="base-fee-update-rule">Base fee update rule</h3> <p>The base fee is updated by aggregating the regular gas and "normalized state gas", where a net change of <code>MAX_STATE_BYTES_PER_BLOCK</code> corresponds to the block's gas limit, thus giving state gas the same range as regular gas. The change is still restricted to the range ±12.5%. When not conditioning against negative values, the <code>gas_used_delta</code> used in the base fee update can for the EIP-1559 mechanism thus be computed as:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span> normalized_state_gas_used</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>gas_limit</span><span class="z-keyword"> *</span><span> (</span><span>parent</span><span>.</span><span>state_bytes_created</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>state_bytes_cleared</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> MAX_STATE_BYTES_PER_BLOCK</span></span> <span class="giallo-l"><span> gas_used_delta</span><span class="z-keyword"> =</span><span> (</span><span>parent</span><span>.</span><span>regular_gas_used</span><span class="z-keyword"> +</span><span> normalized_state_gas_used</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>gas_limit</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 2</span></span></code></pre><h3 id="block-validation">Block validation</h3> <p>The transaction's <code>gas_used</code> is computed as the sum of <code>regular_gas</code> and <code>state_gas</code> and includes refunds, similar to how <code>gas_used</code> is applied today. The <code>regular_gas_used</code> is returned without refunds, which the <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> cumulative gas at the block level accounts for. We also keep track of the cumulative <code>state_bytes_created</code> and <code>state_bytes_cleared</code> in the vector <code>state_bytes</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check that the excess state bytes was updated correctly</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>header</span><span>.</span><span>excess_state_bytes</span><span class="z-keyword"> ==</span><span> calc_excess_state_bytes</span><span>(</span><span>block</span><span>.</span><span>parent</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute the per-block state_gas_per_byte and update state-op gas costs</span></span> <span class="giallo-l"><span> state_gas_per_byte</span><span class="z-keyword"> =</span><span> get_state_gas_per_byte</span><span>(</span><span>block</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"><span> update_state_op_costs</span><span>(</span><span>state_gas_per_byte</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> state_bytes_created</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> state_bytes_cleared</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> block</span><span>.</span><span>transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Transaction execution returns a gas_used vector and refund_vector</span></span> <span class="giallo-l"><span> gas_used</span><span>,</span><span> regular_gas_used</span><span>,</span><span> state_bytes</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>execute_transaction</span><span>(</span><span>transaction</span><span>,</span><span> effective_gas_price</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The gas refund stays the same, the transaction gas counter only counts regular gas without refunds</span></span> <span class="giallo-l"><span> gas_refund</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>gas_limit</span><span class="z-keyword"> -</span><span> gas_used</span></span> <span class="giallo-l"><span> cumulative_transaction_gas_used</span><span class="z-keyword"> +=</span><span> regular_gas_used</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Update the total state bytes created and cleared in the block</span></span> <span class="giallo-l"><span> state_bytes_created</span><span class="z-keyword"> +=</span><span> state_bytes</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> state_bytes_cleared</span><span class="z-keyword"> +=</span><span> state_bytes</span><span>[</span><span class="z-constant">1</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure the net state bytes created are within the per-block limit</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state_bytes_created</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> MAX_STATE_BYTES_PER_BLOCK</span><span class="z-keyword"> +</span><span> state_bytes_cleared</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure state_bytes_created and state_bytes_cleared matches header</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state_bytes_created</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>header</span><span>.</span><span>state_bytes_created</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state_bytes_cleared</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>header</span><span>.</span><span>state_bytes_cleared</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="potential-concerns-with-current-eip-8037">Potential concerns with current EIP-8037</h3> <p>EIP-8037 sets a fixed price of 1900 gas per byte, which can lead to a range of outcomes, depending on, e.g., the price-elasticity of demand for state creation. A specific concern is that since EIP-8037 counts state gas against the regular block gas limit, it may impede scaling, when users consume relatively more state gas at the higher gas per byte charged after the change. EIP-8037 assumes that users will spend 30% of all gas on state gas, just as today, even if the state gas per state byte is increased close to tenfold. This assumption may not hold.</p> <p>Ideally, an increase in the gas cost for state creation will lead users and developers to reduce usage of these operations, relative to other operations. As an example, some may opt to use an existing ETH address instead of creating a new one for each CEX withdrawal. However, given that state creation is a rather fundamental part of interacting with a blockchain, it is reasonable to suspect that many other usage patterns remain as today. Furthermore, an increase in the gas limit as Ethereum scales is associated with a general drop in the base fee. Thus, even if state creation becomes relatively more expensive than other operations, the reduced base fee may mean that users do not take notice to the extent that is desired.</p> <p>Assume that 30% of all consumed gas is state gas at 60M gas limit, producing 102 GiB in state growth per year (286 MiB/day). Then scale the L1 by $5x$ up to a 300M gas limit and increase the gas cost for state creation by $8.5x$ (using account creation in EIP-8037 as a reference point), while usage patterns do not change. The equilibrium outcome is then that $100 \times 0.3 \times 8.5 / (0.3 \times 8.5 + 0.7) = 78.5%$ of all gas is spent on state. Even though Ethereum scaled the gas limit by $5x$, the real achieved scaling is only $5 \times (1 - 0.785) / 0.7 = 1.54x$, and state growth is 157 GiB per year (440 MiB/day).</p> <p>The first example assumes no change in usage behavior and illustrates a general effect that might take place, but somewhat less pronounced. Assume instead that usage patterns indeed change, and that users create half as many state bytes for every gas they spend on other operations, in comparison to how they interact with Ethereum today. In this case, the equilibrium outcome is that $100 \times (0.3 \times 8.5 \times 0.5) / (0.3 \times 8.5 \times 0.5 + 0.7) = 64.7%$ of all gas is spent on state. When scaling the gas limit by $5x$, the real achieved scaling is $5 \times (1 - 0.647) / 0.7 = 2.52x$, and state growth is 129 GiB per year (363 MiB/day).</p> <p>Exempting state from the gas limit applied to regular gas—as proposed in this EIP—would produce a $7.14x$ in scaling (for non-state operations). We would thus achieve close to three times as much throughput as achieved in the example where users halve their state purchases relative to other operations (because they would still spend 64.7% of all available gas on state creation).</p> <h3 id="alternative-specifications">Alternative specifications</h3> <p>Alternative solutions would ideally adhere to the principles outlined in this EIP, specifically:</p> <ol> <li>It is necessary to exempt state from the aggregated regular gas limit, and assign state its own limit. Otherwise, as the gas cost for state is increased, the reduction in gas remaining for other operations will impede scaling.</li> <li>It is not possible to guarantee some specific state expansion just by altering gas costs, given that the price-elasticity of demand is unknown. For this reason, it is desirable to set the cost of state independently and according to its usage. At the same time, a fixed increase in the state gas cost will always help in reducing state consumption to some extent, but there is then also always a risk of overshooting.</li> </ol> <h4 id="multidimensional-subfee-market">Multidimensional subfee market</h4> <p>One variant is to expand the transaction format, using a separate <code>regular_gas_limit</code> and <code>state_byte_limit</code> while removing the current <code>gas_limit</code>. At the beginning of processing a transaction, the protocol computes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>gas_limit</span><span class="z-keyword"> =</span><span> regular_gas_limit</span><span class="z-keyword"> +</span><span> state_gas_per_byte</span><span class="z-keyword"> *</span><span> state_byte_limit</span></span></code></pre> <p>All further processing is applied as if the transaction had specified the computed <code>gas_limit</code> in the first place. This ensures that users do not need to risk having a transaction fail if the <code>state_gas_per_byte</code> drifts significantly between submission and execution, if they set a tight <code>gas_limit</code>. They simply specify how much regular gas they will use and how many state-bytes they will add, which then implies a certain <code>gas_limit</code> at execution time. The idea has certain similarities with the "aggregated gas" concept explored in <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>, but the separate fee here influences how much gas that a resource consumes, hence the name "Multidimensional subfee market". A benefit of the approach is that it offers perfect control over state growth while there is no fee-drift that can make a transaction fail. A downside is that the transaction format must be updated. It would be possible to move to a multidimensional subfee market at a later stage, after first implementing this proposal.</p> <h4 id="multidimensional-gas-metering">Multidimensional gas metering</h4> <p>It is possible to try to achieve the stated goals with multidimensional gas metering of <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a>. The difference between the proposal and the EIP-8011 mechanism is that the latter would not have a separate price for state. It uses the <code>max</code> of the gas consumption among resources for the base fee update. The base fee update may thus for example be set either from the <code>regular_gas</code> or the <code>state_gas</code>, depending on which that is used the most in the block. This means that there is less control over state growth due to the interaction between resources. When another resource consumes the most gas, it will also set the price for state. When state is the most consumed resource, it might raise the price for other resources to a level where scaling is impeded. These types of interactions can be optimized by careful tuning of limits, targets and gas costs, although whatever setting that is decided on may never be fully satisfactory. The benefit is that the gas cost set for state can be fixed, while state still is "exempted" from the regular gas limit, since it only influences the base fee in parallel via the <code>max</code> operation. Thus scaling is mostly preserved.</p> <p>Finally, it is possible to use the <code>max</code> of the gas consumption among resources for the base fee update, while still retaining the separate EIP-4844 mechanism for the <code>state_gas_per_byte</code>. This just represents another way to update the base fee, instead of the aggregation proposed here.</p> <h4 id="multidimensional-fee-market-with-aggregate-gas">Multidimensional fee market with aggregate gas</h4> <p>The multidimensional fee market with aggregate gas specified in <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a> could be applied without changing the transaction format. The gas cost for state creation is fixed and users set a single <code>gas_limit</code>. The fee for the gas for state creation is however completely separate in <code>fee_per_state_gas</code>, instead of being folded into the gas cost through conversion. Users set a <code>max_fee_per_gas</code> as today and the total fee they are willing to pay is computed as <code>max_fee = max_fee_per_gas * gas_limit</code>. This fee is compared with the fee determined during execution: <code>fee_per_state_gas * state_gas + base_fee_per_gas * regular_gas</code>. The benefit is that the gas cost cannot drift between transaction submission and execution, while the transaction format still stays the same. The downside is that if a users sets a tight <code>max_fee_per_gas</code>, then the builder cannot be sure before execution whether the fee covers the cost of the transaction. The user would need to set a more permissive <code>max_fee_per_gas</code> that covers the higher of <code>base_fee_per_gas</code> and <code>fee_per_state_gas</code> to provide full guarantees.</p> <h3 id="combination-with-multidimensional-gas-metering">Combination with multidimensional gas metering</h3> <p>This EIP works well with a broader adoption of full multidimensional gas metering, as proposed in EIP-8011, if we at the same time also adopt the EIP-8011 mechanism for updating the base fee, as suggested previously. We would then expand the <code>gas_used_per_resource</code> vector to track also the other resources in separation. State would still be treated differently in that it has its own <code>state_gas_per_byte</code> cost derived from the <code>excess_state_bytes</code>, whereas other resources are priced directly via the base fee. The metering approach of EIP-8011 is then applied to set the base fee. Given that state is increasingly becoming the major resource contraint (and thus pricing constraint) as we try to limit its usage, it is particularly beneficial that this EIP would allow the EIP-8011 metering to only be applied to the remaining resources. This is likely to benefit scaling further. Note further that the special treatment of the <code>code_deposit_gas</code> proposed in <a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a> would not be necessary with this proposal, because the constraint on state bytes per block is more moderate.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The gas consumed by state creation operations will slowly change so that state growth is maintained at a desirable level. The speed of that drift is tuned by adjusting the <code>STATE_GAS_UPDATE_FRACTION</code>. This constant must be set to a level where UX concerns are mitigated. Specifically, the main concern is that if a transaction sets a very tight <code>gas_limit</code> while consuming state bytes, then that <code>gas_limit</code> may be exceeded, if the <code>state_gas_per_byte</code> cost derived from the <code>excess_state_bytes</code> shifts between submission and execution. The transaction would thus fail. Wallets must first fetch the <code>excess_state_bytes</code> and compute <code>state_gas_per_byte</code>, just as for the <code>blob_base_fee</code> (and <code>base_fee</code>) today. They know how many <code>state_bytes</code> that are created from each op-code of the transaction via the constants inherited from EIP-8037, e.g., <code>NEW_ACCOUNT_BYTES = 112</code>. They then simply add a margin <code>m</code> when computing the <code>gas_limit</code> set for the transaction: <code>gas_limit = regular_gas_limit + state_bytes * state_gas_per_byte * m</code>. The margin is tuned to the variation in <code>state_gas_per_byte</code> that is expected before execution, at the upper limit. The wallet may of course add some margin to their estimate for the <code>regular_gas_limit</code> of other op-codes as well when computing the <code>gas_limit</code>. The difference to the alternative "Multidimensional subfee market" outlined previously is thus that the wallet does not send a <code>regular_gas_limit</code> and <code>state_bytes_limit</code> separately, and instead combine them in order to preserve the current transaction format.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Wallets must have a margin when they set the <code>gas_limit</code> so that the transaction does not fail.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-10-01T00:00:00+00:00 2026-02-11T14:49:29+00:00 Maria Silvahttps://github.com/misilva73 Carlos Perezhttps://github.com/CPerezz Jochem Brouwerhttps://github.com/jochem-brouwer Ansgar Dietrichshttps://github.com/adietrichs Łukasz Rozmejhttps://github.com/LukaszRozmej Anders Elowssonhttps://github.com/anderselowsson Francesco D'Amatohttps://github.com/fradamt https://wg-eips.ritovision.com/8037/

Harmonization, increase and separate metering of state creation gas costs to mitigate state growth and unblock scaling

<h2 id="abstract">Abstract</h2> <p>This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits. It dynamically sets the unit cost per new state byte at a given block gas limit, by targeting an average state growth of 100 GiB per year based on current network usage. It also introduces an independent metering for state creation costs, thus allowing for increased throughput and for larger contract deployments without being limited by the single transaction gas limit.</p> <h2 id="motivation">Motivation</h2> <p>State creation does not have a harmonized cost, with different methods incurring varied costs for creating the same size of new state. For instance, while contract deployment only costs 202 gas units per new byte created, new storage slots cost 625 gas units per new byte created. Also, deploying duplicated bytecode costs the same as deploying new bytecode, even though clients don't store duplicated code in the database. This proposal establishes a standard to harmonize all state creation operations.</p> <p>Additionally, state growth will become a bottleneck for scaling under higher block limits. As of May 2025, the current database size in a Geth node dedicated to state is ~340 GiB. After the increase in gas limit from 30M to 36M gas units, the median size of new state created each day doubled, from ~102 MiB to ~205 MiB. This results in an annual growth of ~73 GiB per year.</p> <p><img src="https://wg-eips.ritovision.com/8037/./assets/new_state_added.png" alt="new_state_added" /></p> <p>The relationship we are seeing in this example is not linear as expected. This is likely due to other factors impacting user behavior. However, all else being equal, we expect a proportional increase in the number of new states created as gas limits increase. At a 60M gas limit (and a proportional increase in new state per day of 1.7x), we would see a daily state growth of ~349 MiB and a yearly state growth of ~124 GiB. Similarly, at a 100M gas limit, the state would grow at a rate of ~553 MiB per day and 197 GiB per year. This level of state growth would give us less than 2.5 years until the size of the state database exceeds the threshold of 650 GiB, at which point nodes will begin experiencing a degradation in performance.</p> <h2 id="specification">Specification</h2> <h3 id="new-parameters">New parameters</h3> <table><thead><tr><th style="text-align: center"><strong>Parameter</strong></th><th style="text-align: center"><strong>Value</strong></th></tr></thead><tbody> <tr><td style="text-align: center"><code>TARGET_STATE_GROWTH_PER_YEAR</code></td><td style="text-align: center">100 × 1024^3 bytes</td></tr> <tr><td style="text-align: center"><code>CPSB_SIGNIFICANT_BITS</code></td><td style="text-align: center">5</td></tr> <tr><td style="text-align: center"><code>CPSB_OFFSET</code></td><td style="text-align: center">9578</td></tr> </tbody></table> <p>Besides these fixed parameters, this EIP introduces a dynamic variable that controls the cost per byte of state created for a given block gas limit. The variable is <code>cost_per_state_byte</code> and is calculated as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>raw</span><span class="z-keyword"> =</span><span> ceil</span><span>(</span><span>(</span><span>gas_limit</span><span class="z-keyword"> *</span><span class="z-constant"> 2_628_000</span><span>)</span><span class="z-keyword"> /</span><span> (</span><span class="z-constant">2</span><span class="z-keyword"> *</span><span class="z-constant"> TARGET_STATE_GROWTH_PER_YEAR</span><span>)</span><span>)</span></span> <span class="giallo-l"><span>shifted</span><span class="z-keyword"> =</span><span> raw</span><span class="z-keyword"> +</span><span class="z-constant"> CPSB_OFFSET</span></span> <span class="giallo-l"><span>shift</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>bit_length</span><span>(</span><span>shifted</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> CPSB_SIGNIFICANT_BITS</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span>cost_per_state_byte</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>(</span><span>(</span><span>shifted</span><span class="z-keyword"> &gt;&gt;</span><span> shift</span><span>)</span><span class="z-keyword"> &lt;&lt;</span><span> shift</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> CPSB_OFFSET</span><span>,</span><span class="z-constant"> 1</span><span>)</span></span></code></pre> <p>The raw value is the unquantized cost derived from targeting <code>TARGET_STATE_GROWTH_PER_YEAR</code> at 50% average gas utilization (see <a href="https://wg-eips.ritovision.com/8037/#deriving-the-cost-per-byte">Deriving the cost per byte</a>). Quantization retains the top <code>CPSB_SIGNIFICANT_BITS</code> significant bits after applying <code>CPSB_OFFSET</code>, producing a stepped function that avoids frequent small changes as the gas limit fluctuates (see <a href="https://wg-eips.ritovision.com/8037/#quantization-of-cost-per-state-byte">Quantization</a>).</p> <h3 id="parameter-changes">Parameter changes</h3> <p>Upon activation of this EIP, the following parameters of the gas model are updated. The "New State Gas" column shows the state gas cost (charged to the <code>state_gas</code> dimension), while the "New Regular Gas" column shows additional regular gas costs that accompany the state gas charge.</p> <table><thead><tr><th><strong>Parameter</strong></th><th><strong>Current</strong></th><th><strong>New State Gas</strong></th><th><strong>New Regular Gas</strong></th><th><strong>Operations affected</strong></th></tr></thead><tbody> <tr><td><code>GAS_CREATE</code></td><td>32,000</td><td>112 × <code>cpsb</code></td><td>9,000 (assuming same as <code>GAS_CALL_VALUE</code>)</td><td><code>CREATE</code>, <code>CREATE2</code>, contract creation txs</td></tr> <tr><td><code>GAS_CODE_DEPOSIT</code></td><td>200/byte</td><td><code>cpsb</code> per byte</td><td><code>6 × ceil(len/32)</code> (hash cost)</td><td><code>CREATE</code>, <code>CREATE2</code>, contract creation txs</td></tr> <tr><td><code>GAS_NEW_ACCOUNT</code></td><td>25,000</td><td>112 × <code>cpsb</code></td><td>0 (already has <code>GAS_CALL_VALUE</code> 9,000)</td><td><code>CALL*</code></td></tr> <tr><td><code>GAS_STORAGE_SET</code></td><td>20,000</td><td>32 × <code>cpsb</code></td><td>2,900 (<code>GAS_STORAGE_UPDATE - GAS_COLD_SLOAD</code>)</td><td><code>SSTORE</code></td></tr> <tr><td><code>PER_EMPTY_ACCOUNT_COST</code></td><td>25,000</td><td>112 × <code>cpsb</code></td><td>0 (included in <code>PER_AUTH_BASE_COST</code>)</td><td>EOA delegation</td></tr> <tr><td><code>PER_AUTH_BASE_COST</code></td><td>12,500</td><td>23 × <code>cpsb</code></td><td>7,500</td><td>EOA delegation</td></tr> </tbody></table> <p>Where <code>cpsb</code> = <code>cost_per_state_byte</code>. The values assigned to regular gas will be updated based on <a href="https://wg-eips.ritovision.com/8038/">EIP-8038</a>.</p> <p>&lt;-TODO-&gt;</p> <p>The <code>PER_AUTH_BASE_COST</code> regular gas of 7,500 is derived from <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>'s cost analysis, excluding the code deployment cost (now charged as state gas):</p> <ul> <li>Calldata cost: ~1,616 (101 bytes × 16)</li> <li>Recovering authority address (ecrecover): 3,000</li> <li>Reading nonce and code of authority (cold access): 2,600</li> <li>Storing values in already warm account: 200</li> <li><del>Code deployment cost: 4,600 (200 × 23)</del> → now in state gas</li> </ul> <p>Total regular gas: 1,616 + 3,000 + 2,600 + 200 ≈ 7,500</p> <p>In addition, <code>GAS_SELF_DESTRUCT_NEW_ACCOUNT</code> is removed and replaced by <code>GAS_NEW_ACCOUNT</code>.</p> <h3 id="multidimensional-metering-for-state-creation-costs">Multidimensional metering for state creation costs</h3> <p>Besides the parameter changes, this proposal introduces an independent metering for state creation costs. The specification is derived from <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a>. However, it only requires two dimensions, namely, <code>regular_gas</code> and <code>state_gas</code>. For state creation operations, the "new state costs" are charged to <code>state_gas</code>, while the "new regular costs" are charged to <code>regular_gas</code>. The costs of all other operations are also charged to <code>regular_gas</code>.</p> <p>At transaction level, the user pays for both <code>regular_gas</code> and <code>state_gas</code>. The total gas cost of a transaction is the sum of both dimensions. In addition, the transaction gas limit set in <a href="https://wg-eips.ritovision.com/7825/">EIP-7825</a> only applies to <code>regular_gas</code>, while <code>state_gas</code> is only capped by <code>tx.gas</code>.</p> <p>At the block level, only the gas used in the bottleneck resource is considered when checking if the block is full and when updating the base fee for the next block. This gives a new meaning to the block’s gas limit and the block’s gas target, which now corresponds to the maximum gas that can be metered in the bottleneck resource.</p> <h4 id="transaction-validation">Transaction validation</h4> <p>Before transaction execution, <code>calculate_intrinsic_cost</code> returns three values: <code>intrinsic_regular_gas</code>, <code>intrinsic_state_gas</code>, and <code>calldata_floor_gas_cost</code>. State gas components of intrinsic cost (e.g., account creation for contract deployment transactions, <a href="https://wg-eips.ritovision.com/2780/">EIP-2780</a> charges, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization charges) are included in <code>intrinsic_state_gas</code>. All other intrinsic costs (base transaction cost, calldata, access lists, authorization base costs) are included in <code>intrinsic_regular_gas</code>.</p> <p><code>validate_transaction</code> rejects transactions where:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-support">max</span><span>(</span><span>intrinsic_regular_gas</span><span>,</span><span> calldata_floor_gas_cost</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TX_MAX_GAS_LIMIT</span></span></code></pre> <p><code>validate_transaction</code> also returns <code>intrinsic_regular_gas</code>, <code>intrinsic_state_gas</code>, and <code>calldata_floor_gas_cost</code>.</p> <h4 id="transaction-level-gas-accounting-reservoir-model">Transaction-level gas accounting (reservoir model)</h4> <p>Since transactions have a single gas limit parameter (<code>tx.gas</code>), gas accounting is enforced through a <strong>reservoir model</strong>, in which <code>gas_left</code> and <code>state_gas_reservoir</code> are initialized as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>intrinsic_gas</span><span class="z-keyword"> =</span><span> intrinsic_regular_gas</span><span class="z-keyword"> +</span><span> intrinsic_state_gas</span></span> <span class="giallo-l"><span>execution_gas</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span> intrinsic_gas</span></span> <span class="giallo-l"><span>regular_gas_budget</span><span class="z-keyword"> =</span><span class="z-constant"> TX_MAX_GAS_LIMIT</span><span class="z-keyword"> -</span><span> intrinsic_regular_gas</span></span> <span class="giallo-l"><span>gas_left</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>regular_gas_budget</span><span>,</span><span> execution_gas</span><span>)</span></span> <span class="giallo-l"><span>state_gas_reservoir</span><span class="z-keyword"> =</span><span> execution_gas</span><span class="z-keyword"> -</span><span> gas_left</span></span></code></pre> <p>The <code>state_gas_reservoir</code> holds gas that exceeds the <a href="https://wg-eips.ritovision.com/7825/">EIP-7825</a>'s budget. The two counters operate as follows:</p> <ul> <li><strong>Regular gas</strong> charges deduct from <code>gas_left</code> only.</li> <li><strong>State gas</strong> charges deduct from <code>state_gas_reservoir</code> first; when the reservoir is exhausted, from <code>gas_left</code>.</li> <li>The <code>GAS</code> opcode returns <code>gas_left</code> only (excluding the reservoir).</li> <li>The reservoir is passed <strong>in full</strong> to child frames (no 63/64 rule). Unused reservoir is returned to the parent on child completion.</li> <li>On <strong>exceptional halt</strong>, both <code>gas_left</code> and <code>state_gas_reservoir</code> are set to zero (all gas consumed), consistent with existing EVM out-of-gas semantics. This is not applied to system transactions.</li> </ul> <p>The two counters are returned by the transaction output. Besides the two counters, the EVM also keeps track of <code>execution_state_gas_used</code> and <code>execution_regular_gas_used</code> during transaction execution. <code>state_gas</code> costs are added to <code>execution_state_gas_used</code> while <code>regular_gas</code> costs are added to <code>execution_regular_gas_used</code>. These two counters are also returned by the transaction output.</p> <h4 id="transaction-gas-used">Transaction gas used</h4> <p>At the end of transaction execution, the gas used before and after refunds is defined as:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx_gas_used_before_refund</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span> tx_output</span><span>.</span><span>gas_left</span><span class="z-keyword"> -</span><span> tx_output</span><span>.</span><span>state_gas_reservoir</span></span> <span class="giallo-l"><span>tx_gas_refund</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>tx_gas_used</span><span class="z-keyword"> //</span><span class="z-constant"> 5</span><span>,</span><span> tx_output</span><span>.</span><span>refund_counter</span><span>)</span></span> <span class="giallo-l"><span>tx_gas_used_after_refund</span><span class="z-keyword"> =</span><span> tx_gas_used</span><span class="z-keyword"> -</span><span> tx_gas_refund</span></span></code></pre> <p>The refund cap remains at 20% of gas used.</p> <h4 id="block-level-gas-accounting">Block-level gas accounting</h4> <p>At block level, instead of tracking a single <code>gas_used</code> counter, we keep track of two counters, one for <code>state_gas</code> and one for <code>regular_gas</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx_regular_gas</span><span class="z-keyword"> =</span><span> intrinsic_regular_gas</span><span class="z-keyword"> +</span><span> tx_output</span><span>.</span><span>execution_regular_gas_used</span></span> <span class="giallo-l"><span>tx_state_gas</span><span class="z-keyword"> =</span><span> intrinsic_state_gas</span><span class="z-keyword"> +</span><span> tx_output</span><span>.</span><span>execution_state_gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>block_output</span><span>.</span><span>block_regular_gas_used</span><span class="z-keyword"> +=</span><span class="z-support"> max</span><span>(</span><span>tx_regular_gas</span><span>,</span><span> calldata_floor_gas_cost</span><span>)</span></span> <span class="giallo-l"><span>block_output</span><span>.</span><span>block_state_gas_used</span><span class="z-keyword"> +=</span><span> tx_state_gas</span></span></code></pre> <p>The block header <code>gas_used</code> field is set to:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>gas_used</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>block_output</span><span>.</span><span>block_regular_gas_used</span><span>,</span><span> block_output</span><span>.</span><span>block_state_gas_used</span><span>)</span></span></code></pre> <p>The block validity condition uses this value:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> gas_used</span><span class="z-keyword"> &lt;=</span><span> block</span><span>.</span><span>gas_limit</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: too much gas used</span><span class="z-punctuation z-definition z-string">&#39;</span></span></code></pre> <p>The base fee update rule is also modified accordingly:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>gas_used_delta</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>gas_used</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>gas_target</span></span></code></pre><h3 id="sstore-refund-for-slot-restoration"><code>SSTORE</code> refund for slot restoration</h3> <p>When a storage slot is set to a non-zero value and then restored to zero within the same transaction (0→X→0 pattern), the following are refunded via <code>refund_counter</code>:</p> <ul> <li>State gas: <code>32 × cost_per_state_byte</code> (the state creation charge)</li> <li>Regular gas: <code>GAS_STORAGE_UPDATE - GAS_COLD_SLOAD - GAS_WARM_ACCESS</code> (2,800)</li> </ul> <p>The net cost after refund is <code>GAS_WARM_ACCESS</code> (100), consistent with pre-<a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a> <code>SSTORE</code> restoration behavior. Refunds use <code>refund_counter</code> rather than direct gas accounting decrements, so that reverted frames do not benefit from the refund.</p> <h3 id="revert-behavior-for-state-gas">Revert behavior for state gas</h3> <p>State gas charged for account creation (<code>CREATE</code>, <code>CALL</code> to new account, and EOA delegation) is consumed even if the frame reverts — state changes are rolled back but gas is not refunded. This is consistent with pre-<a href="https://wg-eips.ritovision.com/8037/">EIP-8037</a> behavior where <code>GAS_NEW_ACCOUNT</code> was consumed on revert.</p> <h4 id="eip-2780-authorizations"><a href="https://wg-eips.ritovision.com/2780/">EIP-2780</a> authorizations</h4> <p>For <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorizations, the intrinsic state gas assumes account creation for each authorization: <code>(112 + 23) × cost_per_state_byte</code> per authorization. When an authorization targets an existing account (no account creation needed), the <code>112 × cost_per_state_byte</code> portion is subtracted from <code>intrinsic_state_gas</code> during authorization processing, before state changes begin.</p> <h4 id="receipt-semantics">Receipt semantics</h4> <p>Receipt <code>cumulative_gas_used</code> tracks the cumulative sum of <code>tx_gas_used_after_refund</code> (post-refund, post-floor) across transactions, instead of the block's <code>gas_used</code>. This means <code>receipt[i].cumulative_gas_used - receipt[i-1].cumulative_gas_used</code> equals the gas paid by transaction <code>i</code>.</p> <h3 id="contract-deployment-cost-calculation">Contract deployment cost calculation</h3> <p>When a contract creation transaction or opcode (<code>CREATE</code>/<code>CREATE2</code>) is executed, gas is charged differently based on whether the deployment succeeds or fails. Given bytecode <code>B</code> (length <code>L</code>) returned by initcode and <code>H = keccak256(B)</code>:</p> <ol> <li><strong>When opcode execution starts:</strong> Always charge <code>GAS_CREATE</code></li> <li><strong>During initcode execution:</strong> Charge the actual gas consumed by the initcode execution</li> <li><strong>Success path</strong> (no error, not reverted, and <code>L ≤ MAX_CODE_SIZE</code>): <ul> <li>Charge <code>GAS_CODE_DEPOSIT * L</code> and persist <code>B</code> under <code>H</code>, then link <code>codeHash</code> to <code>H</code></li> <li>Charge <code>HASH_COST(L)</code> where <code>HASH_COST(L) = 6 × ceil(L / 32)</code> to compute <code>H</code></li> </ul> </li> <li><strong>Failure paths</strong> (REVERT, OOG/invalid during initcode, OOG during code deposit, or <code>L &gt; MAX_CODE_SIZE</code>): <ul> <li>Do NOT charge <code>GAS_CODE_DEPOSIT * L</code> or <code>HASH_COST(L)</code></li> <li>No code is stored; no <code>codeHash</code> is linked to the account</li> <li>The account remains unchanged or non-existent</li> </ul> </li> </ol> <p><strong>Important:</strong> The gas for code deposit (<code>GAS_CODE_DEPOSIT * L</code>) is checked before hash computation. This means that if a deployment runs out of gas, it will fail during the deposit gas check before the hash is computed. This maintains consistency with post-Homestead behavior where any deployment failure (including OOG) reverts all state changes - no account is created, and no gas is charged beyond <code>GAS_CREATE</code> and the actual initcode execution cost consumed.</p> <p><strong>Total gas formulas:</strong></p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SUCCESS_PATH_TOTAL_GAS =</span></span> <span class="giallo-l"><span> GAS_CREATE</span></span> <span class="giallo-l"><span> + initcode_execution_cost</span></span> <span class="giallo-l"><span> + (GAS_NEW_ACCOUNT if account is new else 0)</span></span> <span class="giallo-l"><span> + GAS_CODE_DEPOSIT * L</span></span> <span class="giallo-l"><span> + HASH_COST(L)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>FAILURE_PATH_TOTAL_GAS =</span></span> <span class="giallo-l"><span> GAS_CREATE</span></span> <span class="giallo-l"><span> + initcode_execution_cost</span></span></code></pre><h3 id="create-vs-create2"><code>CREATE</code> vs <code>CREATE2</code></h3> <p><code>CREATE2</code> already charges for hashing the init code when deriving the address. That cost remains unchanged. The bytecode hash (<code>keccak256(B)</code>) must be computed on success to store the code, incurring <code>HASH_COST(L)</code> as specified above.</p> <h2 id="rationale">Rationale</h2> <h3 id="deriving-the-cost-per-byte">Deriving the cost per byte</h3> <p>The variable <code>cost_per_state_byte</code> is a dynamic parameter that depends on the block gas limit. The idea is to have a cost that scales as the block gas limit increases, thus avoiding excessive state growth. To compute this variable, we target a specific state growth per year, which we set to 100 GiB. Then, we assume this growth rate is achieved at an average gas utilization.</p> <p>With multidimensional metering, blocks can be filled up to 50% of the target for both regular gas and state gas. Thus, we consider that on average, blocks can use half of the entire available gas in the block for state creation. This leads to a total of <code>(gas_limit/2) * 7200 * 365</code> gas units used for state creation in a year. Dividing this by the target state growth per year gives us the cost per byte of state created.</p> <h3 id="quantization-of-cost-per-state-byte">Quantization of <code>cost_per_state_byte</code></h3> <p>Without quantization, <code>cost_per_state_byte</code> changes by 1 for every ~81,715 change in gas limit, which is 0.13% of the current block gas limit of 60M gas units. This creates unnecessary churn for tooling and gas estimation, since the cost can change almost every block even when the gas limit is relatively stable.</p> <p>The quantization scheme retains the top 5 significant bits of <code>(raw + CPSB_OFFSET)</code>, zeroes the remaining bits, then subtracts <code>CPSB_OFFSET</code>. This is equivalent to binary floating-point rounding: each power-of-2 band has exactly 16 distinct levels, and the step size doubles at each band boundary while remaining perfectly uniform within a band.</p> <p>The offset (<code>CPSB_OFFSET = 9578</code>) shifts quantization boundaries away from common gas limit targets. It was chosen by brute-force search over 0–10000 to maximize the minimum distance from any quantization boundary to gas limits from 100M to 1000M (in 50M increments). This prevents <code>cost_per_state_byte</code> from flipping between adjacent values due to small gas limit fluctuations near popular targets. The following table shows the resulting boundary distances:</p> <table><thead><tr><th style="text-align: center">Gas Limit</th><th style="text-align: center"><code>cost_per_state_byte</code></th><th style="text-align: center">Distance to boundary</th><th style="text-align: center">Blocks to boundary</th></tr></thead><tbody> <tr><td style="text-align: center">100M</td><td style="text-align: center">1,174</td><td style="text-align: center">4.15%</td><td style="text-align: center">42.5</td></tr> <tr><td style="text-align: center">150M</td><td style="text-align: center">1,686</td><td style="text-align: center">8.21%</td><td style="text-align: center">84.0</td></tr> <tr><td style="text-align: center">200M</td><td style="text-align: center">2,198</td><td style="text-align: center">10.24%</td><td style="text-align: center">104.8</td></tr> <tr><td style="text-align: center">250M</td><td style="text-align: center">2,710</td><td style="text-align: center">5.28%</td><td style="text-align: center">54.1</td></tr> <tr><td style="text-align: center">300M</td><td style="text-align: center">3,222</td><td style="text-align: center">1.68%</td><td style="text-align: center">17.2</td></tr> <tr><td style="text-align: center">350M</td><td style="text-align: center">4,246</td><td style="text-align: center">0.89%</td><td style="text-align: center">9.1</td></tr> <tr><td style="text-align: center">400M</td><td style="text-align: center">4,758</td><td style="text-align: center">2.82%</td><td style="text-align: center">28.9</td></tr> <tr><td style="text-align: center">450M</td><td style="text-align: center">5,270</td><td style="text-align: center">4.32%</td><td style="text-align: center">44.2</td></tr> <tr><td style="text-align: center">500M</td><td style="text-align: center">5,782</td><td style="text-align: center">2.85%</td><td style="text-align: center">29.2</td></tr> <tr><td style="text-align: center">550M</td><td style="text-align: center">6,294</td><td style="text-align: center">1.10%</td><td style="text-align: center">11.3</td></tr> <tr><td style="text-align: center">600M</td><td style="text-align: center">6,806</td><td style="text-align: center">6.63%</td><td style="text-align: center">67.8</td></tr> <tr><td style="text-align: center">650M</td><td style="text-align: center">7,830</td><td style="text-align: center">1.58%</td><td style="text-align: center">16.1</td></tr> <tr><td style="text-align: center">700M</td><td style="text-align: center">7,830</td><td style="text-align: center">3.35%</td><td style="text-align: center">34.3</td></tr> <tr><td style="text-align: center">750M</td><td style="text-align: center">8,854</td><td style="text-align: center">3.54%</td><td style="text-align: center">36.3</td></tr> <tr><td style="text-align: center">800M</td><td style="text-align: center">8,854</td><td style="text-align: center">0.89%</td><td style="text-align: center">9.1</td></tr> <tr><td style="text-align: center">850M</td><td style="text-align: center">9,878</td><td style="text-align: center">4.80%</td><td style="text-align: center">49.1</td></tr> <tr><td style="text-align: center">900M</td><td style="text-align: center">10,902</td><td style="text-align: center">1.02%</td><td style="text-align: center">10.5</td></tr> <tr><td style="text-align: center">950M</td><td style="text-align: center">10,902</td><td style="text-align: center">2.57%</td><td style="text-align: center">26.4</td></tr> <tr><td style="text-align: center">1000M</td><td style="text-align: center">11,926</td><td style="text-align: center">2.55%</td><td style="text-align: center">26.2</td></tr> </tbody></table> <p>The worst-case minimum distance is 0.89% of the gas limit (at 350M and 800M). Since the gas limit can deviate from its parent by at most 1/1024, <code>cost_per_state_byte</code> remains stable for at least ~9 consecutive blocks of same-direction gas limit changes at any gas limit in the 100M–1000M range (in 50M increments).</p> <h3 id="harmonization-across-state-creation">Harmonization across state creation</h3> <p>With the current pricing, the gas cost of creating 1 byte of state varies depending on the method used. The following table shows the various methods and their gas cost per byte. The calculation ignores the transaction intrinsic cost (21k gas units) and the costs of additional opcodes and scaffolding needed to execute such a transaction.</p> <table><thead><tr><th>Method</th><th>What is written</th><th>Intrinsic gas</th><th>Bytes → state</th><th>Gas / byte</th></tr></thead><tbody> <tr><td>Deploy 24kB contract (<a href="https://wg-eips.ritovision.com/170/">EIP-170</a> limit)</td><td>Runtime code + account trie node</td><td>32,000 CREATE + 200 × 24,576 code deposit = 4,947,200 gas</td><td>24,688 B</td><td>~200 gas</td></tr> <tr><td>Fund fresh EOA with 1 wei</td><td>Updated account leaf</td><td>25,000 new account</td><td>~112 B</td><td>~223 gas</td></tr> <tr><td>Add delegate flag to funded EOA (<a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>)</td><td>23 B (0xef0100‖address) + updated account leaf</td><td>25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata - 7,823 refund = ~31,300 gas</td><td>~135 B</td><td>~232 gas</td></tr> <tr><td><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization to empty address</td><td>23 B (0xef0100‖address) + updated account leaf</td><td>25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata = 39,116 gas</td><td>~135 B</td><td>~289 gas</td></tr> <tr><td>Fill new storage slots (SSTORE 0→x)</td><td>Slot in storage trie</td><td>20,000 gas/slot</td><td>32 B</td><td>625 gas</td></tr> </tbody></table> <p>To harmonize costs, we first set the gas cost of a single state byte, <code>cost_per_state_byte</code>, as explained above. This is a dynamic parameter that depends on the block gas limit. Now that we have a standardized cost per byte, we can derive the various costs parameters by multiplying the unit cost by the increase in bytes any given operation creates in the database (i.e., 32 bytes per slot, 112 bytes per account and 23 bytes per authorization).</p> <p>Note that the fixed cost <code>GAS_CREATE</code> for contract deployments assumes the same cost as a new account creation.</p> <h3 id="multidimensional-metering">Multidimensional metering</h3> <p>This proposal is consistent with <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a>. However, it only requires two dimensions, namely, <code>regular_gas</code> and <code>state_gas</code>. If <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a> is not implemented, a two-dimensional version of <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a> is still required.</p> <h4 id="eip-7825-limit-on-contract-size">EIP-7825 limit on contract size</h4> <p><a href="https://wg-eips.ritovision.com/7825/">EIP-7825</a> introduces <code>TX_MAX_GAS_LIMIT</code> (16.7M) as the maximum gas for a single transaction, in particular stipulating <code>tx.gas &lt; TX_MAX_GAS_LIMIT</code>as a validity condition. Were we to continue enforcing this validity condition, with a block limit of 100M gas units, this proposal would limit the maximum contract size that can be deployed to roughly 9.9kB ($\frac{16,777,216 - 21,000 - 5,000,000 - 112 \times 1174}{1174} = 9'902$). This maximum size would only decrease as we increase the gas limit and the <code>cost_per_state_byte</code>.</p> <p>To solve this issue, we only apply this gas limit to regular gas, not state gas. Doing so does not weaken the intended scaling effect of <a href="https://wg-eips.ritovision.com/7825/">EIP-7825</a>, because regular gas meters all resources that benefit from parallelization. In particular, state growth does not: growing the state always requires writing to disk, a parallelizable operation, but crucially this part of the cost of a state growth operation has to be metered in regular gas, not state gas. In other words, any operation that grows the state should consume both regular gas and state gas, and the regular gas should fully account for all costs other than the long term effect of growing the state.</p> <p>However, we cannot statically enforce a regular gas consumption of <code>TX_MAX_GAS_LIMIT</code>, while still allowing a higher state gas consumption, because transactions only have a single gas limit parameter, <code>tx.gas</code>. This is solved through a <strong>reservoir model</strong>: at transaction start, execution gas is split into <code>gas_left</code> (capped at <code>TX_MAX_GAS_LIMIT - intrinsic_regular_gas</code>) and a <code>state_gas_reservoir</code> (the overflow). State gas charges draw from the reservoir first, then from <code>gas_left</code> when the reservoir is empty. Regular gas charges draw from <code>gas_left</code> only. Exceeding the regular gas budget behaves identically to running out of gas — no special error is needed.</p> <h4 id="higher-throughput">Higher throughput</h4> <p>Another advantage of metering contract creation separately is that increasing the cost of state creation operation in line with the block limit will not affect the available gas for other operations. This allows for higher throughput, as explained in the original multidimensional gas metering introduced in <a href="https://wg-eips.ritovision.com/8011/">EIP-8011</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically:</p> <ul> <li>Wallets: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.</li> <li>Node Software: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation with the new floor cost values.</li> </ul> <p>Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p> <h3 id="estimated-price-impacts-at-various-block-gas-limits">Estimated price impacts at various block gas limits</h3> <p>Users and dApp developers will experience an increase in transaction costs associated with creating a new state. The next table summarizes the state creation costs for common operations at different block gas limits.</p> <table><thead><tr><th style="text-align: center">Case</th><th style="text-align: center">cost_per_state_byte</th><th>Cost of a new account</th><th>Cost increase</th><th>Cost of a new slot</th><th>Cost increase</th><th>24kB contract deployment</th><th>Cost increase</th></tr></thead><tbody> <tr><td style="text-align: center">Current cost</td><td style="text-align: center">NA</td><td>25,000</td><td>NA</td><td>20,000</td><td>NA</td><td>4,947,200</td><td>NA</td></tr> <tr><td style="text-align: center">Proposed cost at 60M block limit</td><td style="text-align: center">662</td><td>74,144</td><td>3</td><td>24,084</td><td>1</td><td>16,357,064</td><td>3</td></tr> <tr><td style="text-align: center">Proposed cost at 100M block limit</td><td style="text-align: center">1,174</td><td>131,488</td><td>5</td><td>40,468</td><td>2</td><td>28,997,320</td><td>6</td></tr> <tr><td style="text-align: center">Proposed cost at 200M block limit</td><td style="text-align: center">2,198</td><td>246,176</td><td>10</td><td>73,236</td><td>4</td><td>54,277,832</td><td>11</td></tr> <tr><td style="text-align: center">Proposed cost at 300M block limit</td><td style="text-align: center">3,222</td><td>360,864</td><td>14</td><td>106,004</td><td>5</td><td>79,558,344</td><td>16</td></tr> </tbody></table> <p>We should note that as the block limit increases, the base fee is expected to reduce due to the higher capacity of the network. This reduction in base fee will offset, in part, the costs from state creation operations. Some analysis is needed to quantify this effect.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Increasing the cost of state creation operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.</p> <h3 id="mispricing-with-respect-to-eth-transfers">Mispricing with respect to ETH transfers</h3> <p>One potential concern is the cost of creating a new account (<code>112 × cost_per_state_byte</code> gas units, e.g., 131,488 at a 100M gas limit), compared to transferring ETH to a fresh account (21,000 gas units). With this mismatch, users wishing to create new account are incentivized to first send a normal transaction (costing 21k) to this account to create it, thus avoiding the <code>GAS_NEW_ACCOUNT</code> charge.</p> <p><a href="https://wg-eips.ritovision.com/2780/">EIP-2780</a> solves this mispricing by adding a new component to the intrinsic gas cost of transactions. If a non-create transaction has value &gt; 0 and targets a non-existent account, the <code>GAS_NEW_ACCOUNT</code> is added to intrinsic cost.</p> <h3 id="added-complexity-in-block-building">Added complexity in block building</h3> <p>Optimal block construction becomes more complex, since builders must now balance resource usage across multiple dimensions rather than a single gas metric. Sophisticated builders may gain an advantage by applying advanced optimization techniques, raising concerns about further builder centralization. However, practical heuristics (e.g., greedily filling blocks until one resource dimension saturates) remain effective for most use cases. These heuristics limit centralization pressure by keeping block construction feasible for local and less sophisticated builders.</p> <h3 id="testing-requirements-for-increasing-block-limits">Testing requirements for increasing block limits</h3> <p>With a dynamic cost per byte, every time the block gas limit is increased, clients and testing frameworks need to test for backward compatibility issues. This changes the testing framework for increasing the block limit. A way to mitigate this is to introduce a max cost per byte and do the analysis once on the impact of this max cost.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-09-29T00:00:00+00:00 2026-02-11T14:49:28+00:00 Guillaume Ballethttps://github.com/gballet Carlos Perezhttps://github.com/CPerezz Matan Prasmahttps://github.com/KanExtension Wei Han Nghttps://github.com/weiihann https://wg-eips.ritovision.com/8032/

Makes `SSTORE` gas cost scale with a contract's storage size to discourage state bloat.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a mechanism to dynamically price SSTORE operations based on the storage size of a contract. A new optional <code>storage_count</code> field is added to the account RLP, which tracks the number of storage slots it owns. The gas cost for SSTORE will be augmented by a factor that grows exponentially with this <code>storage_count</code> field, but only after it crosses a predefined activation threshold. This change aims to align the cost of state growth with the long-term burden it places on the network, thereby disincentivizing state bloat.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum's state size is a growing concern, as it directly impacts node synchronization times, hardware requirements, and overall network health. The current gas model for storage operations does not fully account for the long-term cost of maintaining state indefinitely. As a result, it remains economically viable to deploy contracts with large storage footprints (“state bloat”), which can be exploited for low-cost data anchoring or spam. This imposes a negative externality on all network participants, who must store and process this data indefinitely.</p> <p>In practice, the computational and I/O costs of creating and updating storage slots scale with the number of storage slots a contract owns. However, the current gas pricing model does not meaningfully increase with storage size. This discrepancy underprices workloads for contracts with very large state and slows down state root computation.</p> <p>This proposal aims to address the state growth problem by creating a direct economic link between the size of a contract's storage and the cost to expand it further. By progressively increasing the price of SSTORE operations in proportion to how much storage a contract already owns, storage write costs become more aligned with the actual work clients perform. Contracts that contribute disproportionately to state growth will face rising costs for additional writes, while small and medium-sized contracts remain unaffected. This mechanism creates a market-based incentive for developers to use onchain storage efficiently, helping mitigate unsustainable state growth over time.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="constants-and-parameters">Constants and parameters</h3> <table><thead><tr><th>Name</th><th style="text-align: center">Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td style="text-align: center">TBD</td><td>Fork activation timestamp</td></tr> <tr><td><code>LIN_FACTOR</code></td><td style="text-align: center">TBD</td><td>Linear gas cost factor</td></tr> <tr><td><code>ACTIVATION_THRESHOLD</code></td><td style="text-align: center">TBD</td><td>Activation threshold, chosen to be at ~8GB of data.</td></tr> <tr><td><code>TRANSITION_REGISTRY_ADDRESS</code></td><td style="text-align: center">TBD</td><td>The address of system contract that holds the information of account transition</td></tr> <tr><td><code>TRANSITION_SLOTS_PER_BLOCK</code></td><td style="text-align: center">TBD</td><td>The number of storage slots to iterate per block during the transition process</td></tr> <tr><td><code>TRANSITION_MAX_ACCOUNTS</code></td><td style="text-align: center">TBD</td><td>The number of accounts to iterate per block during the transition process</td></tr> </tbody></table> <p>&lt;-- TODO --&gt;</p> <h3 id="new-account-field">New account field</h3> <p>Account RLP descriptors receive an optional <code>storage_count</code> field, corresponding to the current number of storage slots it contains.</p> <h3 id="account-transition">Account transition</h3> <p>At <code>FORK_TIMESTAMP</code>, the transition is activated.</p> <p>The transition process involves reading all accounts and count the number of storage slots for accounts with non-empty storage root hashes, which in turn populates the <code>storage_count</code> field in the account.</p> <p>The progress of the transition is stored at system contract at <code>TRANSITION_REGISTRY_ADDRESS</code>.</p> <p>Storage layout at <code>TRANSITION_REGISTRY_ADDRESS</code>:</p> <ul> <li>slot <code>0x00</code>: <code>cursor_account_hash</code> (32-byte account hash)</li> <li>slot <code>0x01</code>: <code>cursor_slot_hash</code> (32-byte slot hash)</li> <li>slot <code>0x02</code>: <code>cursor_accum</code> (uint256 count of non-zero slots seen for the current account)</li> </ul> <p>At the <strong>end</strong> of each block, the client performs up to <code>TRANSITION_SLOTS_PER_BLOCK</code> storage slot iterations, possibly spanning one account or multiple accounts:</p> <ol> <li> <p><strong>Select account</strong><br /> If <code>cursor_account_hash == 0x00…00</code>, set it to the smallest account hash that is present in the state trie. Otherwise, continue with <code>cursor_account_hash</code>.</p> </li> <li> <p><strong>Iterate storage slots</strong><br /> If the current account at <code>cursor_account_hash</code> has a non-empty <code>storageRootHash</code>, visit storage slots of this account in ascending lexicographic order of <code>slot hash</code>, starting <strong>strictly after</strong> <code>cursor_slot_hash</code> (or from the beginning if <code>cursor_slot_hash == 0x00…00</code>).</p> <ul> <li>Increment <code>cursor_accum</code> slot for every slot hash seen</li> <li>Stop when either: <ul> <li><code>TRANSITION_SLOTS_PER_BLOCK</code> slots have been processed, or</li> <li>there are no more storage slots for the account.</li> </ul> </li> </ul> </li> <li> <p><strong>Finalize account (if exhausted)</strong><br /> If all storage slots for <code>cursor_account_hash</code> have been visited, set <code>storage_count(cursor_account)</code> to <code>cursor_accum</code> in the account object.</p> <p>If <code>TRANSITION_MAX_ACCOUNTS</code> accounts are iterated, then stop iterating.</p> <ul> <li>Else: <ul> <li>Advance to the next account:<br /> <code>cursor_account_hash</code> = next account hash that is present in the state trie</li> <li>Reset per-account cursors:<br /> <code>cursor_slot_hash = 0x00…00</code>, <code>cursor_accum = 0</code></li> </ul> </li> </ul> </li> <li> <p><strong>Persist</strong><br /> If either <code>TRANSITION_SLOTS_PER_BLOCK</code> or <code>TRANSITION_MAX_ACCOUNTS</code> is reached, write <code>cursor_account_hash</code>, <code>cursor_slot_hash</code>, and <code>cursor_accum</code> to the registry in the post-state of the block.</p> </li> <li> <p><strong>Completion</strong><br /> The transition is complete when there is no further account present in the trie, with an account hash that is lexicographically greater than the current <code>cursor_account_hash</code>.</p> </li> </ol> <p>The account hashes and slot hashes are iterated in ascending lexicographical order.</p> <p>Transition reference: <a href="https://wg-eips.ritovision.com/7612/">EIP-7612</a></p> <h4 id="reorg-semantics">Reorg semantics</h4> <p>Chain reorganizations require <strong>no special handling</strong> beyond normal block re-execution. The mechanism is reorg-safe.</p> <p><code>storage_count</code> updates and the transition cursors (<code>cursor_account_hash</code>, <code>cursor_slot_hash</code>, <code>cursor_accum</code>) are ordinary state writes committed in the post-state of each block at <code>TRANSITION_REGISTRY_ADDRESS</code>. On a reorg, these values revert to those of the new canonical ancestor and are re-derived by re-executing blocks.</p> <h3 id="account-update-rules">Account update rules</h3> <p>After executing all transactions in a block, clients MUST update <code>storage_count</code> for affected accounts as follows:</p> <ul> <li>Let <code>old := storage_count(A)</code> in the block-prestate (treat as <code>0</code> if absent).</li> <li>Let <code>new</code> be the true count of non-zero slots for <code>A</code> in the post-block state.</li> <li>Set <code>storage_count(A) := new</code>.</li> </ul> <p>To compute <code>new</code> efficiently without scanning all storage every block, clients MUST apply net deltas derived from slots whose values changed relative to the block-prestate:</p> <p>For each storage slot <code>k</code> of account <code>A</code> that was written at least once in the block:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_storage_delta</span><span>(</span><span class="z-variable z-parameter z-function">prestate_value</span><span>,</span><span class="z-variable z-parameter z-function"> poststate_value</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Calculate the storage slot delta based on pre-state and post-state values.</span></span> <span class="giallo-l"><span class="z-string"> </span></span> <span class="giallo-l"><span class="z-string"> Args:</span></span> <span class="giallo-l"><span class="z-string"> prestate_value: Pre-state value of the storage slot</span></span> <span class="giallo-l"><span class="z-string"> poststate_value: Post-state value of the storage slot</span></span> <span class="giallo-l"><span class="z-string"> </span></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> int: Delta value (+1, -1, or 0)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> prestate_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> poststate_value</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 1</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Slot created: empty to non-empty</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> prestate_value</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> poststate_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-keyword"> -</span><span class="z-constant">1</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Slot deleted: non-empty to empty</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> No change in slot occupancy</span></span></code></pre> <p>During a transition, the transition is advanced <em>first</em> before applying the storage deltas, but <em>after</em> executing all transactions, so the gas costs of a contract that is sweeped by the iterator in this block are only applied for the <em>next</em> block. Update semantics when a transition is occurring:</p> <ul> <li>For accounts that have been iterated (i.e. <code>cursor_account_hash</code> &gt; <code>acc_hash</code> ), all storage deltas are applied.</li> <li>For accounts that have not been iterated at all (i.e. <code>acc_hash</code> &gt; <code>cursor_account_hash</code>), none of the storage deltas are applied.</li> <li>For the account currently being iterated (i.e. <code>cursor_account_hash</code> == <code>acc_hash</code>), storage deltas are applied only to the slots that have already been accounted for (i.e. <code>cursor_slot_hash</code> &gt; <code>slot_hash</code>).</li> </ul> <h3 id="sstore-gas-cost-changes">SSTORE gas cost changes</h3> <p>For each contract account <code>A</code>, define <code>S_pre(A)</code> as the value of <code>storage_count(A)</code> in the parent state of the block being executed (pre-state).</p> <p>For all <code>SSTORE</code>s in the block, implementations MUST use <code>S_pre(A)</code> when computing the gas cost for <code>SSTORE</code>. This value MUST NOT change within the block, regardless of any writes to <code>A</code> during the block.</p> <p>If <code>storage_count(A)</code> is absent at block start, clients MUST treat <code>S_pre(A) = 0</code>.</p> <blockquote> <p>Rationale: holding <code>S_pre(A)</code> constant within the block keeps gas estimation stable and independent of transaction ordering.</p> </blockquote> <p>The gas cost of an <code>SSTORE</code> is computed as such:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>constant_sstore_gas</span><span>(</span><span>addr</span><span>,</span><span> slot</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> LIN_FACTOR</span><span class="z-keyword"> *</span><span> ceil_log16</span><span>(</span><span>S_pre</span><span>(</span><span>addr</span><span>)</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> ACTIVATION_THRESHOLD</span></span></code></pre><h3 id="impact-on-state-size">Impact on state size</h3> <p><code>storage_count</code> is RLP-encoded as a minimal-length big-endian byte string (no leading zeros). The per-account overhead is therefore small and not a fixed 32 byte number. The field is present only for accounts with a non-empty storage root hash. If <code>storage_count == 0</code>, the field may be omitted.</p> <p><strong>Per-account overhead</strong></p> <ul> <li>Payload length <code>L = bytes_required(storage_count)</code>: <ul> <li><code>L = 0</code> for <code>0</code> (field may be omitted entirely)</li> <li><code>L = 1</code> for <code>1 … 255</code></li> <li><code>L = 2</code> for <code>256 … 65,535</code></li> <li><code>L = 3</code> for <code>65,536 … 16,777,215</code></li> <li><code>L = 4</code> for <code>16,777,216 … 4,294,967,295</code> (≈ 4.29B)</li> </ul> </li> <li><strong>+1 byte</strong> RLP string prefix (since <code>L ≤ 55</code>)</li> <li><strong>+ up to 1 byte</strong> for the account-list prefix growth (only if the list’s total payload crosses a size boundary)</li> </ul> <p>For context, at block ~23,000,000 the largest contract has about <strong>80M</strong> storage slots. Even at that scale (<code>L = 4</code>), the per-account addition remains <strong>≤ 6 bytes</strong>.</p> <p>If we pessimistically assume <strong>23,000,000</strong> contract accounts each carry <code>storage_count</code> and each incurs the worst-case <strong>6 bytes</strong>, the upper bound is:</p> <ul> <li><code>23,000,000 × 6 = 138,000,000</code> bytes ≈ <strong>138 MB</strong></li> </ul> <p>This is a conservative upper bound. In practice, most contracts have far fewer slots (<code>L ≤ 1–3</code>), so a typical addition is 2–4 bytes per contract. Therefore, the net impact on state size is negligible.</p> <h2 id="rationale">Rationale</h2> <p>The intent is to create friction when growing the state size of a contract, thus limiting the number of such contracts. Going over the limit, some contract developers might want to use another contract to start fresh, which comes at the cost of paying for contract creation, and for any call into the previous instance of the contract.</p> <p><code>ACTIVATION_THRESHOLD</code> is chosen to not penalize the contracts that are large, but do provide useful value. The idea is to disincentivize spam contracts that grow larger than useful contracts, the latter being legitimately big due to the value they bring to their users and the wider ecosystem. This means that this constant could be increased as the state grows.</p> <p><code>TRANSITION_MAX_ACCOUNTS</code> bounds how many accounts may be finalized (i.e. have their <code>storage_count</code> written) per block during the transition. This prevents excessive write operations per block, reducing write amplification and avoiding large database compactions and associated performance degradation. It complements <code>TRANSITION_SLOTS_PER_BLOCK</code>, which limits how many <strong>storage slots</strong> are scanned per block in line with the minimal hardware recommendations. In short, <code>TRANSITION_SLOTS_PER_BLOCK</code> bounds read operations, while <code>TRANSITION_MAX_ACCOUNTS</code> bounds write operations.</p> <h3 id="comparison-with-depth-based-pricing">Comparison with depth-based pricing</h3> <p>The largest contract observed (XEN) sits around depth 9, meaning its relevant storage keys share a 9-nibble (~4.5 bytes) prefix along their MPT paths. Because the storage key into the trie is <code>keccak256(slot_key)</code>, an attacker can easily calculate the inputs offchain to find hashes and populate all contracts such that they pay the same cost as XEN.</p> <h3 id="why-is-a-transition-needed">Why is a transition needed?</h3> <p>If counting began only at <code>FORK_TIMESTAMP</code>, every existing contract would start with an implicit <code>storage_count = 0</code> and accrue counts only from <em>new</em> writes. While spammy contracts would quickly accumulate writes and thus incur penalties, this would still misprice the workloads we intend to regulate: large pre-fork contracts would continue paying unscaled base costs until they rewrote a substantial portion of their historical slots. During that period, gas pricing would understate their actual storage footprint.</p> <p>A deterministic, in-protocol transition avoids this. By iterating existing storage under consensus rules and progressively populating each account’s <code>storage_count</code> in the state, we ensure that storage-size-based pricing reflects reality for <em>all</em> contracts—regardless of whether they write again after the fork. Persisting cursor progress under the state root also makes the process reorg-safe and client-agnostic.</p> <p><strong>Alternative (pre-fork background counting by clients)</strong></p> <ul> <li><strong>Idea:</strong> Clients begin counting slots before <code>FORK_TIMESTAMP</code>. At activation, they only need to write the final counts into the state for a fixed number of accounts.</li> <li><strong>Pros:</strong> Reduces post-fork iteration work, much faster convergence at fork time since iterating all accounts is faster than all storage slots.</li> <li><strong>Cons:</strong> Late upgraders, snap-syncing nodes, or nodes that were offline cannot reconstruct pre-fork counts deterministically. This approach has to be coordinated so that all users upgrade their nodes and must finish counting prior to the fork activation. Reorgs have to be handled explicitly too.</li> </ul> <h3 id="compatibility-with-verkle-binary-unified-tree">Compatibility with Verkle/Binary unified tree</h3> <p>In the current two-layer MPT, a write to contract storage accesses an account path and then a storage path, and the cost a client pays in trie updates and database reads/writes correlates with how deep the storage trie becomes over time.</p> <p>Under a unified tree, the per-write computational and I/O cost of <code>SSTORE</code> no longer tracks an account’s total number of storage slots. The path length is set by the global tree’s branching factor and height, and by the overall distribution of state keys, not by a single account’s footprint. As a result, progressive pricing based on an account’s slot count can become misaligned with the actual work once a unified tree ships.</p> <h3 id="compatibility-with-eip-2926">Compatibility with EIP-2926</h3> <p>Because <a href="https://wg-eips.ritovision.com/2926/">EIP-2926</a> also requires an account transition to chunkify the bytecode and additional fields, scheduling both EIPs in the same fork enables a single, combined transition. This removes duplicated work, reduces client complexity and the number of tree transitions in the future.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found. Making the <code>storage_count</code> field optional ensures that the default count is 0, which means that contract will not be affected by the gas increase before they have been reached by the iterator sweep.</p> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically, RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation when encountering an <code>SSTORE</code>.</p> <p>Users and wallets can maintain their usual workflows without modification, as RPC updates will handle these changes.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-09-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lawliet Chanhttps://github.com/lawliet-chan https://wg-eips.ritovision.com/8099/

A protocol that prevents MEV attacks by constraining transaction ordering through blind sequencing and two-phase block execution.

<h2 id="abstract">Abstract</h2> <p>This proposal introduces the MEVless protocol, a novel approach to prevent Maximum Extractable Value (MEV) attacks by implementing blind transaction sequencing. The core principle of MEVless is to prevent validators from seeing transaction content during the ordering phase, thereby eliminating the fundamental prerequisite for MEV attacks. The protocol separates block production into two phases: sequencing blocks that order transactions based on transaction hashes without revealing transaction content, and execution blocks that execute transactions in the predetermined order. This design eliminates the ability of miners and validators to perform MEV attacks such as sandwich attacks and front-running by removing their access to transaction content during the critical ordering phase.</p> <h2 id="motivation">Motivation</h2> <p>MEV attacks, particularly sandwich attacks and front-running, represent a significant threat to blockchain ecosystems, especially in DeFi applications. The fundamental prerequisite for MEV attacks is that validators can see transaction content before ordering, which allows them to:</p> <ol> <li><strong>Sandwich Attacks</strong>: Insert buy and sell transactions around user transactions to manipulate prices and extract value</li> <li><strong>Front-running</strong>: Execute similar transactions before users to capture arbitrage opportunities</li> <li><strong>Back-running</strong>: Execute transactions after users to benefit from price movements</li> </ol> <p>Unlike legitimate arbitrage activities that provide liquidity, these attacks are purely extractive and harmful to the ecosystem. They reduce user confidence, increase transaction costs, and can lead to significant financial losses for users.</p> <p>Current solutions have limitations:</p> <ul> <li><strong>Encrypted Mempools</strong>: High computational overhead for encryption/decryption</li> <li><strong>Private Mempools</strong>: Centralized and not fully decentralized, use trustful instead of trustless.</li> <li><strong>PBS (Proposer-Builder Separation)</strong>: Still allows builders to see transaction content and becoming more and more centralized.</li> </ul> <p>The MEVless protocol addresses these issues by fundamentally changing how transactions are ordered, making it impossible for miners to perform MEV attacks while maintaining decentralization and efficiency. By eliminating MEV attacks at the protocol level, DeFi developers can focus on building innovative financial products and user experiences without constantly worrying about MEV protection mechanisms, leading to faster development cycles and more robust applications.</p> <h2 id="specification">Specification</h2> <h3 id="protocol-overview">Protocol Overview</h3> <p>The MEVless protocol operates on a two-phase block system:</p> <ol> <li><strong>Sequencing Blocks</strong>: Order transactions based on transaction hashes and prepayment amounts without revealing transaction content. Sequencing blocks interval can be shorter than execution blocks.</li> <li><strong>Execution Blocks</strong>: Execute transactions in the predetermined order from sequencing blocks</li> </ol> <h3 id="block-types">Block Types</h3> <h4 id="sequencing-blocks">Sequencing Blocks</h4> <ul> <li><strong>Purpose</strong>: Order transactions and collect prepayments</li> <li><strong>Frequency</strong>: Every odd-numbered block height</li> <li><strong>Operations</strong>: <ul> <li>Receive transaction hashes from users</li> <li>Collect prepayments (gas fees + optional tips)</li> <li>Order transactions by prepayment amount (highest first)</li> <li>Publish ordered transaction sequence as commitment</li> <li>Store transaction hashes in block</li> </ul> </li> </ul> <h4 id="execution-blocks">Execution Blocks</h4> <ul> <li><strong>Purpose</strong>: Execute transactions in predetermined order</li> <li><strong>Frequency</strong>: Every even-numbered block height</li> <li><strong>Operations</strong>: <ul> <li>Receive transaction content from users</li> <li>Verify transaction content matches committed hashes</li> <li>Execute transactions in predetermined order</li> </ul> </li> </ul> <h3 id="transaction-flow">Transaction Flow</h3> <h4 id="phase-1-transaction-submission-and-sequencing">Phase 1: Transaction Submission and Sequencing</h4> <ol> <li>User creates transaction and calculates transaction hash</li> <li>User sends transaction hash to the network with prepayment: <ul> <li><strong>Base Gas Fee</strong>: Fixed fee for hash storage and sequencing computation</li> <li><strong>Optional Tip</strong>: Additional payment for priority in sequencing</li> </ul> </li> <li>Network validates user has sufficient balance for prepayment</li> <li>Network orders transaction hashes by total prepayment amount (descending)</li> <li>Network deducts prepayment from user account</li> <li>Network publishes ordered transaction sequence as commitment</li> <li>Network stores transaction hashes in sequencing block</li> </ol> <p><img src="https://wg-eips.ritovision.com/8099/./assets/MEVless.png" alt="MEVless Protocol Flow" /> <em>MEVless Protocol Transaction Flow</em></p> <h4 id="phase-2-transaction-content-submission-and-execution">Phase 2: Transaction Content Submission and Execution</h4> <ol> <li>User monitors network for their transaction hash commitment</li> <li>User submits actual transaction content(including the remaining gasfee) to network</li> <li>Network receives transaction content during execution block</li> <li>Network verifies transaction content matches committed hash</li> <li>Network executes transactions in predetermined order, deduct the remaining fee and 50% of the actual difference between gasUsed and gaslimit for tax ( prevent the gasLimit much more than gasUsed so that validators can entire the whole block to get MEV)</li> </ol> <h3 id="gas-economics">Gas Economics</h3> <h4 id="prepayment-structure">Prepayment Structure</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Total Prepayment = Base Gas Fee + Optional Tip</span></span></code></pre> <ul> <li><strong>Base Gas Fee</strong>: Fixed cost for hash storage and sequencing computation</li> <li><strong>Optional Tip</strong>: Variable amount for priority in transaction ordering</li> </ul> <h4 id="gas-cost-calculation">Gas Cost Calculation</h4> <ul> <li><strong>Sequencing Phase</strong>: Minimal gas cost for hash operations</li> <li><strong>Execution Phase</strong>: Standard gas cost for transaction execution</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-blind-sequencing">Why Blind Sequencing?</h3> <p>Blind sequencing eliminates the root cause of MEV attacks by preventing miners from seeing transaction content during the critical ordering phase. This approach is more efficient than encryption-based solutions and more decentralized than private mempool approaches.</p> <h3 id="why-two-phase-blocks">Why Two-Phase Blocks?</h3> <p>Separating sequencing and execution allows for:</p> <ul> <li><strong>Efficient Ordering</strong>: Hash-based ordering is computationally lightweight</li> <li><strong>Network Efficiency</strong>: Small hash data reduces bandwidth requirements</li> <li><strong>Commitment Mechanism</strong>: Public ordering commitment prevents manipulation</li> </ul> <h3 id="why-random-block-production-is-critical">Why Random Block Production is Critical?</h3> <p>Random block production is essential to prevent speculative MEV attacks. When block producers cannot predict when they will be selected to produce blocks, they cannot reliably perform speculative MEV attacks because:</p> <ul> <li><strong>Unpredictable Selection</strong>: Attackers cannot know if they will be the next block producer</li> <li><strong>Economic Risk</strong>: Speculative transactions require prepayments that are lost if the attacker is not selected</li> <li><strong>Decentralization Amplification</strong>: More validators mean lower individual selection probability, increasing attack costs exponentially</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This protocol will add some RPC methods to support the two-phase block system:</p> <ul> <li><strong>eth_sendTxHash</strong>: Users submit transaction hashes instead of full transactions</li> <li><strong>eth_getTxSequence</strong>: Returns the ordered transaction sequence that is committed</li> </ul> <h2 id="test-cases">Test Cases</h2> <h3 id="basic-transaction-flow">Basic Transaction Flow</h3> <ol> <li>User submits transaction hash with prepayment</li> <li>Network orders transaction by prepayment amount</li> <li>User submits transaction content</li> <li>Network executes transaction in predetermined order</li> </ol> <h3 id="mev-attack-prevention">MEV Attack Prevention</h3> <ol> <li>Attacker submits transaction hash for sandwich attack</li> <li>Network orders transaction without revealing content</li> <li>Attacker cannot see victim transaction content during ordering</li> <li>Attack fails due to lack of transaction visibility</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>The MEVless protocol requires a consensus mechanism with unpredictable block production to prevent speculative MEV attacks. Without unpredictable block production, block producers can perform cost-free speculative MEV attacks by submitting transaction hashes and then deciding whether to submit their transaction content based on other users' transaction content, thus performing cost-free speculative MEV attacks. Since the prepayment ultimately goes to the block producer themselves, predictable block production allows them to recover their prepayment costs through block fees, making MEV attacks economically viable. Random block production forces attackers to pay prepayments for speculative transactions without knowing if they will be selected to produce the next block, making the prepayment cost real rather than recoverable through block fees, thus making such attacks economically unviable. The anti-MEV effectiveness increases exponentially with network decentralization - more validators mean lower individual selection probability, making attacks economically unviable.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-09-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Kemptonhttps://github.com/SirSpudlington https://wg-eips.ritovision.com/8030/

Adds an EIP-7932 algorithm type for P256 support of type `0x0`

<h2 id="abstract">Abstract</h2> <p>This EIP adds a new <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a> algorithm of type <code>0x0</code> for supporting P256 signatures.</p> <h2 id="motivation">Motivation</h2> <p>P256 (a.k.a secp256r1) is a widely-used NIST standardized algorithm that already has a presence within the Ethereum codebase. This makes it a great algorithm to write test cases against implementations of <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>.</p> <h2 id="specification">Specification</h2> <p>This EIP defines a new <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a> algorithmic type with the following parameters:</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>ALG_TYPE</code></td><td><code>Bytes1(0x0)</code></td></tr> <tr><td><code>SIZE</code></td><td><code>129</code></td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>N</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> gas_cost</span><span>(</span><span class="z-variable z-parameter z-function">signing_data</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Uint64</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is the precompile cost from [EIP-7951](./07951.md) with 3000 gas</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> subtracted (the cost of the secp256k1 precompile)</span></span> <span class="giallo-l"><span class="z-constant"> BASE_GAS</span><span class="z-keyword"> =</span><span> Uint64</span><span>(</span><span class="z-constant">3900</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calculate extra overhead for keccak256 hashing</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> BASE_GAS</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> minimum_word_size</span><span class="z-keyword"> =</span><span> (</span><span class="z-support">len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> BASE_GAS</span><span class="z-keyword"> +</span><span> Uint64</span><span>(</span><span class="z-constant">30</span><span class="z-keyword"> +</span><span> (</span><span class="z-constant">6</span><span class="z-keyword"> *</span><span> minimum_word_size</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span class="z-keyword"> |</span><span> Error</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This function is a noop as there is no</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> exposed function defined in [EIP-7951](./07951.md)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verify</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> signing_data</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span class="z-keyword"> |</span><span> Error</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Hash if non-standard size</span></span> <span class="giallo-l"><span> signing_data</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>signing_data</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ignore initial alg_type byte</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> (</span><span>r</span><span>,</span><span> s</span><span>,</span><span> x</span><span>,</span><span> y</span><span>)</span><span class="z-keyword"> =</span><span> (</span><span>signature</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">64</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">64</span><span>:</span><span class="z-constant">96</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">96</span><span>:</span><span class="z-constant">128</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is similar to [EIP-2](./00002.md)&#39;s malleability verification.</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>s</span><span class="z-keyword"> &lt;=</span><span> N</span><span class="z-keyword">/</span><span class="z-constant">2</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is defined in [P256Verify Function](#p256verify-function)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>P256Verify</span><span>(</span><span>signing_data</span><span>,</span><span> r</span><span>,</span><span> s</span><span>,</span><span> x</span><span>,</span><span> y</span><span>)</span><span class="z-keyword"> ==</span><span> Bytes</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0x0000000000000000000000000000000000000000000000000000000000000001</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> x</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span class="z-keyword"> +</span><span> y</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span></code></pre><h3 id="p256verify-function"><code>P256Verify</code> Function</h3> <p>The <code>P256Verify</code> function is the logic of the precompile defined in <a href="https://wg-eips.ritovision.com/7951/">EIP-7951</a>, the only exception is that this function MUST NOT charge any gas.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-p256">Why P256?</h3> <p>P256 or secp256r1, is used globally but (more importantly) has an existing implementation in all execution clients. This allows easy implementation of a known-safe algorithm, which is perfect for a test algorithm.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <!-- TODO --> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-09-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Kevaundray Wedderburnhttps://github.com/kevaundray Justin Drakehttps://github.com/JustinDrakejustin@ethereum.org https://wg-eips.ritovision.com/8025/

Introducing optional execution proofs on the consensus layer

<h2 id="abstract">Abstract</h2> <p>Optional execution proofs allow beacon nodes to verify the validity of the execution payload within a beacon block without running an execution layer client. The execution proofs are sent over the consensus layer's peer-to-peer network.</p> <h2 id="motivation">Motivation</h2> <p>Optional execution proofs reduce the hardware and bandwidth requirements that are needed for an attester to verify a beacon block. Moreover, the cost to verify to a block no longer grows with the gas limit.</p> <p>Since these are optional, protocol upgrades cannot be based on the improvements in this EIP. This EIP allows us to safely test execution proofs without making it explicitly consensus critical.</p> <h2 id="specification">Specification</h2> <p>This is a consensus layer change only.</p> <p>Validators will now be able to enable two new modes:</p> <ul> <li>zkEVM Proof generating</li> <li>Stateless validation</li> </ul> <p>When a proof generating node receives a beacon block, they will create the necessary proofs for the execution payload in the block and re-propagate them on the specified subnets.</p> <p>When a stateless validating node receives a beacon block, they will check to see if they have already received a valid execution proof for that execution payload from the specified subnet.</p> <p>The detailed specifications are in the consensus-specs repository.</p> <p>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 and RFC 8174.</p> <h2 id="rationale">Rationale</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is backwards compatible and does not require a hardfork.</p> <h2 id="test-cases">Test Cases</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="security-considerations">Security Considerations</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Caymanhttps://github.com/wemeetagain https://wg-eips.ritovision.com/8016/

SSZ type for forward-compatible unions

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md">Simple Serialize (SSZ)</a> type to represent unions with forward-compatible Merkleization: A given field is always assigned the same stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> across all type options.</p> <h2 id="motivation">Motivation</h2> <p>Certain types, e.g., transactions, allow multiple variants carving out slightly different feature sets. Merkleization equivalence is still desirable, as it allows verifiers to check common fields across variants. These types should still efficiently deserialize into one of their possible variants corresponding to its known tree shape. In programming languages, this is typically achieved by tagged unions.</p> <p>If multiple versions of an SSZ container coexist at the same time, for example to represent transaction types, the same field may be assigned to a different gindex in each version. This unnecessarily complicates verifiers and introduces a maintenance burden, as the verifier has to be kept up to date with version specific field to gindex map.</p> <p>Compatible unions allow only type options to be used that provide stable gindex assignment across all of them.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="compatibleunion-selector-type"><code>CompatibleUnion({selector: type})</code></h3> <p>A new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#composite-types">SSZ composite type</a> is defined:</p> <ul> <li><strong>compatible union</strong>: union type containing one of the given subtypes with compatible Merkleization <ul> <li>notation <code>CompatibleUnion({selector: type})</code>, e.g. <code>CompatibleUnion({1: Square, 2: Circle})</code></li> </ul> </li> </ul> <p>Compatible unions are always considered <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#variable-size-and-fixed-size">"variable-size"</a>, even when all type options share the same fixed length.</p> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#default-values">default value</a> is defined as:</p> <table><thead><tr><th>Type</th><th>Default Value</th></tr></thead><tbody> <tr><td><code>CompatibleUnion({selector: type})</code></td><td>n/a (error)</td></tr> </tbody></table> <p>The following types are considered <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#illegal-types">illegal</a>:</p> <ul> <li><code>CompatibleUnion({})</code> without any type options are illegal.</li> <li><code>CompatibleUnion({selector: type})</code> with a selector outside <code>uint8(1)</code> through <code>uint8(127)</code> are illegal.</li> <li><code>CompatibleUnion({selector: type})</code> with a type option that has incompatible Merkleization with another type option are illegal.</li> </ul> <h4 id="compatible-merkleization">Compatible Merkleization</h4> <ul> <li>Types are compatible with themselves.</li> <li><code>byte</code> is compatible with <code>uint8</code> and vice versa.</li> <li><code>Bitlist[N]</code> are compatible if they share the same capacity <code>N</code>.</li> <li><code>Bitvector[N]</code> are compatible if they share the same capacity <code>N</code>.</li> <li><code>List[type, N]</code> are compatible if <code>type</code> is compatible and they share the same capacity <code>N</code>.</li> <li><code>Vector[type, N]</code> are compatible if <code>type</code> is compatible and they share the same capacity <code>N</code>.</li> <li><a href="https://wg-eips.ritovision.com/7916/"><code>ProgressiveList[type]</code></a> are compatible if <code>type</code> is compatible.</li> <li><code>Container</code> are compatible if they share the same field names in the same order, and all field types are compatible.</li> <li><a href="https://wg-eips.ritovision.com/7495/"><code>ProgressiveContainer(active_fields)</code></a> are compatible if all <code>1</code> entries in both type's <code>active_fields</code> correspond to fields with shared names and compatible types, and no other field name is shared across both types.</li> <li><code>CompatibleUnion</code> are compatible with each other if all type options across both <code>CompatibleUnion</code> are compatible.</li> <li>All other types are incompatible.</li> </ul> <h4 id="serialization">Serialization</h4> <p>A <code>value</code> as <code>CompatibleUnion({selector: type})</code> has properties <code>value.data</code> with the contained value, and <code>value.selector</code> which indexes the selected type option.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">return</span><span> value</span><span>.</span><span>selector</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">1</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span class="z-keyword"> +</span><span> serialize</span><span>(</span><span>value</span><span>.</span><span>data</span><span>)</span></span></code></pre><h4 id="deserialization">Deserialization</h4> <p>The deserialization logic is updated:</p> <ul> <li>In the case of compatible unions, the first byte of the deserialization scope is deserialized as type selector, the remainder of the scope is deserialized as the selected type.</li> </ul> <p>The following invalid input needs to be hardened against:</p> <ul> <li>An out-of-bounds type selector in a <code>CompatibleUnion</code></li> <li>Incomplete data (less than 1 byte for selector)</li> <li>Corrupted or malformed serialized data</li> <li>Invalid serialization of inner types (delegated to inner type deserialization)</li> </ul> <h4 id="json-mapping">JSON mapping</h4> <p>The canonical <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#json-mapping">JSON mapping</a> is updated:</p> <table><thead><tr><th>SSZ</th><th>JSON</th><th>Example</th></tr></thead><tbody> <tr><td><code>CompatibleUnion({selector: type})</code></td><td>selector-object</td><td><code>{ "selector": string, "data": type }</code></td></tr> </tbody></table> <p><code>CompatibleUnion</code> is encoded as an object with a <code>selector</code> and <code>data</code> field, where the contents of <code>data</code> change according to the selector.</p> <h4 id="merkleization">Merkleization</h4> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#merkleization">SSZ Merkleization specification</a> is extended with a helper function:</p> <ul> <li><code>mix_in_selector</code>: Given a Merkle root <code>root</code> and a type selector <code>selector</code> (<code>"uint8"</code> serialization) return <code>hash(root, selector)</code>.</li> </ul> <p>The Merkleization definitions are extended.</p> <ul> <li><code>mix_in_selector(hash_tree_root(value.data), value.selector)</code> if <code>value</code> is of compatible union type.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-are-compatibleunion-selectors-limited-to-1-127">Why are <code>CompatibleUnion</code> selectors limited to <code>1 ... 127</code>?</h3> <p>Reserving <code>0</code> prevents issues with incomplete initialization, and can possibly be used in a future EIP to denote optionality.</p> <p>Reserving selectors above <code>127</code> (i.e., highest bit is set) enables future backwards compatible extensions.</p> <p>The range <code>1 ... 127</code> is sufficient to satisfy current demand.</p> <h3 id="why-not-field-collections">Why not field collections?</h3> <p>An alternative design was explored where the <code>active_fields</code> bitvector was emitted. While that works in principle, it becomes very inefficient to parse when <code>ProgressiveContainer</code> are nested, as the parser cannot immediately determine the overall tree shape. Further, the bitvector makes every single nesting layer variable-length, adding a lot of overhead to the serialized format.</p> <p>With <code>CompatibleUnion</code>, a tag is emitted that tells the parser early on what to expect, including for nested fields.</p> <p>Note that wrapping a field in a <code>CompatibleUnion</code> is not a backwards compatible operation. However, new options can be introduced, and existing options dropped, without breaking verifiers. Therefore, <code>CompatibleUnion</code> has to be introduced early on wherever future design extensions are anticipated, even when only a single type option is used.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>CompatibleUnion({selector: type})</code> is an alternative to an <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#composite-types">earlier union proposal</a>. However, it has only been used in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/specs/_deprecated/sharding/beacon-chain.md">deprecated specifications</a>. Portal network also uses a union concept for network types, but does not use <code>hash_tree_root</code> on them, and could transition to the new compatible union proposal with a new networking version.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li><code>ethereum/remerkleable</code> contains static tests in <code>test_impl.py</code> and <code>test_typing.py</code>.</li> <li><code>ethereum/consensus-specs</code> releases contain random tests in <code>tests/general/phase0/ssz_generic</code>, generated according to a format defined in <code>tests/format/ssz_generic</code>.</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>See <code>ethereum/remerkleable</code>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>For <code>CompatibleUnion({selector: type})</code>, the <code>selector</code> mix-in guarantees a unique <code>hash_tree_root</code> if multiple type options refer to the same Merkle tree shape, or also if multiple type options solely differ in the element type of a <code>List[type, N]</code> or <a href="https://wg-eips.ritovision.com/7916/"><code>ProgressiveList[type]</code></a> field (as the <code>hash_tree_root</code> of any empty list does not depend on the <code>type</code>). Without the <code>selector</code>, such cases would either have to be defined as illegal types, or handled by the application logic (e.g., by mixing it into the signing root, or by encoding the element type into a different field).</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Maria Silvahttps://github.com/misilva73 Davide Crapishttps://github.com/dcrapis Anders Elowssonhttps://github.com/anderselowsson Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/8011/

Gas accounting by EVM resource, increasing throughput and improving resource usage controls, with minimal changes to the protocol and UX

<h2 id="abstract">Abstract</h2> <p>This proposal introduces multidimensional gas metering, changing the way we account for gas used at the block level. This enables Ethereum to increase throughput and better control excessive resource usage, with minimal changes to the protocol and the UX. During transaction execution, gas is metered for each resource dimension, such as compute and state. At the transaction level, everything remains unchanged. A transaction still pays fees according to the sum of gas used across all resources and still has a single gas limit imposed on this same sum. However, at the block level, only the gas used in the bottleneck resource is considered when checking if the block is full and when updating the base fee for the next block. This gives a new meaning to the block's gas limit and the block's gas target, which now corresponds to the maximum gas that can be metered in the bottleneck resource.</p> <h2 id="motivation">Motivation</h2> <p>This proposal separates <em>transaction pricing</em> (i.e., the way of measuring consumption of resources by transactions) from <em>block metering</em> (i.e., the way of controlling resource limits and ensure that blocks do not overload the network). More concretely, it introduces a multidimensional metering scheme that accounts for the different EVM resources while keeping the pricing model unchanged.</p> <p>There are four main benefits of the proposal:</p> <ol> <li>Throughput gains: By decoupling resource limits, blocks can carry transactions that stress distinct resources simultaneously, improving packing efficiency.</li> <li>Finer-grained control over excessive resource usage: metering gas costs independently for each resource allows us to tailor each operation's gas cost to the actual resource limits.</li> <li>Keeps UX identical: users still specify one <code>gas_limit</code> and see one <code>gas_used</code> value.</li> <li>Simplicity: This simpler metering change lays the groundwork for eventual multidimensional pricing (such as <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>) without disrupting the current fee market and with minimal protocol changes.</li> </ol> <h2 id="specification">Specification</h2> <h3 id="operation-gas-costs">Operation gas costs</h3> <p>Under the multidimensional metering model, EVM operations are assigned a cost vector whose components correspond to their gas cost on each resource dimension. Each cost has 6 dimensions: <code>gas_cost_vector = (compute_cost, access_cost, size_cost, memory_cost, state_cost, history_cost)</code>.</p> <h4 id="pure-compute-operations">Pure compute operations</h4> <p>The operations listed in <a href="https://wg-eips.ritovision.com/8011/assets/compute_ops/">compute_ops</a> are assigned a <code>gas_cost_vector</code> equal to <code>(gas_cost, 0, 0, 0, 0, 0)</code>, where <code>gas_cost</code> is the operation's gas cost.</p> <h4 id="compute-and-memory-operations">Compute and memory operations</h4> <p>The operations listed in <a href="https://wg-eips.ritovision.com/8011/assets/compute_mem_ops/">compute_mem_ops</a> are assigned a <code>gas_cost_vector</code> equal to <code>(compute_cost, 0, 0, memory_cost, 0, 0)</code>, where <code>memory_cost</code> is the operation's memory expansion cost (as defined by the function <a rel="external" href="https://github.com/ethereum/execution-specs/blob/91824145ef62da61803edf9a764fd8f3662794c0/src/ethereum/osaka/vm/gas.py#L167"><code>calculate_gas_extend_memory</code></a>) and <code>compute_cost</code> is the operation's gas cost minus its memory expansion cost.</p> <h4 id="state-operations">State operations</h4> <p>The assignment of a <code>gas_cost_vector</code> to the operations listed in <a href="https://wg-eips.ritovision.com/8011/assets/state_ops/">state_ops</a> is TBD, pending benchmarks. &lt;-- TODO --&gt;</p> <h4 id="log-operations">LOG operations</h4> <p>The assignment of a <code>gas_cost_vector</code> to the operations listed in <a href="https://wg-eips.ritovision.com/8011/assets/log_ops/">log_ops</a> is TBD, pending benchmarks. &lt;-- TODO --&gt;</p> <h3 id="intrinsic-gas-costs">Intrinsic gas costs</h3> <p>Under the multidimensional metering model, each transaction's intrinsic cost (as defined by the function <a rel="external" href="https://github.com/ethereum/execution-specs/blob/91824145ef62da61803edf9a764fd8f3662794c0/src/ethereum/osaka/transactions.py#L571"><code>calculate_intrinsic_cost</code></a>) is also assigned 6-dimensional <code>gas_cost_vector</code>. The breakdown of cost by resource dimension is TBD, pending benchmarks.</p> <p>&lt;-- TODO --&gt;</p> <h3 id="gas-accounting">Gas accounting</h3> <p>Besides replacing the single gas cost with a 6-dimensional cost vector, the gas accounting during block execution also changes. Instead of keeping track of a single total of gas used, the EVM stores a 6-dimensional vector with how much gas units was spent on each resource until that point in the execution.</p> <p>After executing the ith EVM operation of a transaction, say <code>OP_i</code>, with a cost vector <code>gas_cost_vector_i = (compute_cost_i, access_cost_i, size_cost_i, memory_cost_i, state_cost_i, history_cost_i)</code>, the following variables are updated:</p> <ul> <li>Remaining available gas for the transaction: <ul> <li><code>gas = gas - sum(compute_cost_i, access_cost_i, size_cost_i, memory_cost_i, state_cost_i, history_cost_i)</code></li> </ul> </li> <li>Total used gas by the transaction so far: <ul> <li><code>gas_used = gas_used + sum(compute_cost_i, access_cost_i, size_cost_i, memory_cost_i, state_cost_i, history_cost_i)</code></li> </ul> </li> <li>Used gas vector by the transaction so far: <ul> <li><code>gas_used_vector = (compute_gas_used + compute_cost_i, access_gas_used + access_cost_i, size_gas_used + size_cost_i, memory_gas_used + memory_cost_i, state_gas_used + state_cost_i, history_gas_used + history_cost_i)</code></li> </ul> </li> </ul> <p>At the transaction level, everything remains the same. A transaction still has the same one-dimensional <code>gas_limit</code>. The transaction's out-of-gas condition is still defined as <code>gas_used &lt;= gas_limit</code>. Additionally, the transaction's fee is also computed with <code>gas_used</code>.</p> <p>The key change is the introduction of <code>gas_used_vector</code> as a new variable that tracks the gas used by each resource at the transaction level. This variable is returned by the <code>execute_transaction</code> function, in addition to <code>gas_used</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> execute_transaction</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> transaction</span><span>:</span><span> NormalizedTransaction</span><span>,</span><span class="z-variable z-parameter z-function"> effective_gas_price</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span> tuple</span><span>[</span><span class="z-support">int</span><span>,</span><span class="z-support"> list</span><span>]</span><span>:</span><span class="z-keyword"> pass</span></span></code></pre><h3 id="block-header-extension">Block header extension</h3> <p>The current header encoding is extended with a new 64-bit unsigned integer field named <code>max_gas_metered</code>. This integer corresponds to the total gas units used by the bottleneck resource, i.e., the resource with the largest used gas in the block. This variable is computed as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_block_max_gas_metered</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> transactions</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>transactions</span><span>(</span><span>block</span><span>)</span></span> <span class="giallo-l"><span> block_gas_used_vector</span><span class="z-keyword"> =</span><span> array</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> transaction</span><span class="z-keyword"> in</span><span> transactions</span><span>:</span></span> <span class="giallo-l"><span> gas_used</span><span>,</span><span> gas_used_vector</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>execute_transaction</span><span>(</span><span>transaction</span><span>,</span><span> effective_gas_price</span><span>)</span></span> <span class="giallo-l"><span> block_gas_used_vector</span><span class="z-keyword"> +=</span><span> gas_used_vector</span></span> <span class="giallo-l"><span> max_gas_metered</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>block_gas_used_vector</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> max_gas_metered</span></span></code></pre> <p>The header sequence with the new field is <code>[..., parent_beacon_block_root, requests_hash, max_gas_metered]</code>.</p> <h3 id="block-validity-condition">Block validity condition</h3> <p>The block validity conditions are modified to replace <code>block.gas_used</code> with <code>block.max_gas_metered</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> block</span><span>.</span><span>max_gas_metered</span><span class="z-keyword"> &lt;=</span><span> block</span><span>.</span><span>gas_limit</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: too much gas used</span><span class="z-punctuation z-definition z-string">&#39;</span></span></code></pre><h3 id="base-fee-update-rule">Base fee update rule</h3> <p>The block validity conditions are modified to replace <code>parent.gas_used</code> with <code>parent.max_gas_metered</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>gas_used_delta</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>max_gas_metered</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>gas_target</span></span></code></pre> <p>This change is compatible with the various transaction variants, such as <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>, or <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-are-we-choosing-this-resource-split">Why are we choosing this resource split?</h3> <p>Ethereum’s slot-based structure introduces a strict temporal constraint: all attestations must be processed, aggregated, and propagated within a single slot. This fact makes time a fundamental resource. To maintain network health, validators must execute blocks, validate them, and gossip attestations quickly enough to avoid missed slots and penalties.</p> <p>Each type of resource contributes differently to this bottleneck:</p> <ul> <li>Execution time affects how quickly validators can process blocks and produce attestations.</li> <li>Data size influences how long it takes to propagate blocks and blobs across the peer-to-peer network.</li> <li>Memory usage determines how efficiently nodes can handle concurrent workloads without triggering garbage collection or cache eviction. It also affects the minimum hardware requirements that proposers and attesters must meet to fulfill their responsibilities.</li> <li>State growth impacts long-term scalability and database performance, especially for archival and full nodes.</li> </ul> <p>In addition, changes in the slot (e.g., Enshrined Proposer-Builder Separation) and changes in the execution model (e.g., Block-level Access Lists) will change how the different resources interact and how they impact the available slot time. Thus, we want to track as many relevant resources as possible in order to allow for future changes to the protocol that may impact resource contribution.</p> <p>For these reasons, the proposal splits the resources into the following broad categories:</p> <ol> <li><strong>Block Execution Time</strong>: Captures how long it takes to process a block on a single node. This includes: <ul> <li>Compute: CPU time spent on each operation.</li> <li>State Access: Time or count of disk I/O operations when accessing the trie (e.g., <code>SLOAD</code>/<code>SSTORE</code>).</li> </ul> </li> <li><strong>Block Upload/Download Time</strong>: Captures how data size affects network transmission: <ul> <li>Block size (call data + transaction &amp; block metadata)</li> </ul> </li> <li><strong>Short-term Memory</strong>: Reflects short-term memory allocation during execution, i.e., RAM usage</li> <li><strong>Long-term Storage</strong>: Tracks persistent changes to disk usage. There are two dimensions here: <ul> <li>State Growth: Delta in disk size of the state trie before and after execution.</li> <li>History Growth: Delta in disk space used for historical receipts, logs, etc.</li> </ul> </li> </ol> <p>Note that we are not considering the blob resource (which is part of the Block Upload/Download Time) as it is already priced independently.</p> <p>Based on previous empirical analysis, state growth represented a significant portion of the gas used in Ethereum blocks, accounting for 30.2% of all gas consumed between blocks 22000000 and 22005000. The second resource with the most gas used was compute (26.8%), followed by state access (21.9%). History growth and data had a less relevant contribution, accounting for 9.9% and 6.9% of all the gas used, respectively. Note that the data component in this analysis did not consider blobs.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards-compatible and requires a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="worst-case-blocks-and-excessive-resource-usage">Worst-case blocks and excessive resource usage</h3> <p>A concern about metering resources independently is the potential of creating worst-case blocks that put too much pressure on EVM resources. Thus, the cost vectors of each EVM operation need to be carefully set up to avoid this scenario. To this end, we will perform comprehensive benchmarks to measure the resource utilization of each operation and set the gas cost vector accordingly.</p> <p>Additionally, state and history growth are not constrained at the block level, but over longer time frames. Increased aggregate gas usage from this proposal may be associated with increase state-growth, assuming that relative gas consumption across resources is not altered significantly under equilibrium. To keep the long-run consumption in check, the gas cost of operations contributing to state and history growth would thus need to be increased.</p> <h3 id="base-fee-manipulation">Base fee manipulation</h3> <p>Builders can manipulate the base fee by selectively including or excluding transactions to change the block's <code>max_gas_metered</code>. This behavior is already possible with EIP-1559. Yet, multidimensional gas metering compute the base fee on the bottleneck resource instead of the total gas consumed. This allows for blocks that yield the same total fees but with different <code>max_gas_metered</code> values. The extent of this concern is limited by the incentives to maximize fee revenue. While the expected gains of base fee manipulation are smaller than execution rewards, we won't observe these attacks.</p> <h3 id="added-complexity-in-block-building">Added complexity in block building</h3> <p>Optimal block construction becomes more complex, since builders must now balance resource usage across multiple dimensions rather than a single gas metric. Sophisticated builders may gain an advantage by applying advanced optimization techniques, raising concerns about further builder centralization. However, practical heuristics (e.g., greedily filling blocks until one resource dimension saturates) remain effective for most use cases. These heuristics limit centralization pressure by keeping block construction feasible for local and less sophisticated builders.</p> <h3 id="censorship-resistance">Censorship resistance</h3> <p>This EIP makes it cheaper to fill the block to censor transactions under FOCIL in <a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a> (as also noted in <a href="https://wg-eips.ritovision.com/7999/">EIP-7999</a>). Specifically, it can be cheaper for a builder to create dummy transaction consuming only one resource to fill the block, taking advantage of the lower base fee under equilibrium. However, given that all resources have the same base fee in this proposal, and that the builder must still fill the block up to the gas limit for at least one resource, the degradation in censorship resistance is fairly moderate, and mainly related to the potentially reduced base fee under equilibrium.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Potuzhttps://github.com/potuz https://wg-eips.ritovision.com/8012/

Reutilizes the consolidation request contract to pass general messages from the EL to the CL.

<h2 id="abstract">Abstract</h2> <p>This EIP redefines the field <code>target_pubkey</code> from consolidations requests into a general array of 48 bytes that can be interpreted separately by the consensus layer.</p> <h2 id="motivation">Motivation</h2> <p>The current contract to send consolidation requests is not optimized in that the exact same contract, with the exact same calldata and engine API, can be used to transmit more general messages from the EL to the CL without changes on the EL side. In particular, avoiding any cross layer coordination in the event of an CL hard fork.</p> <p>As a possible application, we could use the same contract to allow any existing validator to become a builder as in <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a>.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <h4 id="consensus-layer">Consensus Layer</h4> <table><thead><tr><th>NAME</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>MAGIC_PREFIX</code></td><td><code>0xEF0A11</code></td><td>3 byte prefix to all generalized consolidation requests</td></tr> </tbody></table> <h3 id="execution-layer">Execution Layer</h3> <p>No changes are expected</p> <h3 id="consensus-layer-1">Consensus Layer</h3> <p>This EIP does not establish any changes on the consensus layer, but rather standardizes how consolidation requests are to be treated in the future. When receiving a <code>ConsolidationRequest</code> type object on the consensus layer, the <code>target_pubkey</code> field is to be treated differently. If it coincides with the BLS publick key of an existing active validator in the beacon chain, then it is to be interpreted as such. Otherwise, the 48 bytes are to be interpreted as a concatenation of the following fields</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>|MAGIC_PREFIX | CALL_TYPE | ARG_NUMBER | ARG1 | ARG2 | ARG3 | ARG4 | ARG5 |</span></span></code></pre> <p>Where <code>MAGIC_PREFIX</code> is the 3 byte constant that prefixes all generalized consolidation requests. <code>CALL_TYPE</code> are 4 bytes to be interpretted as a little Endian <code>uint32</code> and identifies the function type. <code>ARG_NUMBER</code> is a 1 byte to be interpretted as a <code>uint8</code> that encodes the number of arguments that are being passed to the generalized consolidation request handler. And each <code>ARG1, ARG2, ARG3, ARG4, ARG5</code> are all interpretted as little Endian <code>uint64</code>.</p> <p>For each addition of a new <code>CALL_TYPE</code>, the consensus layer must add a handler appropriately called from within <code>process_consolidation_requests</code>.</p> <h3 id="engine-api">Engine API</h3> <p>No changes needed.</p> <h2 id="rationale">Rationale</h2> <p>The proposed reinterpretation of the existing contract enables new implementations in the consensus layer without requireing a hard fork in the execution layer.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is fully backwards compatible.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No known security impacts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Terencehttps://github.com/terencechain https://wg-eips.ritovision.com/8015/

Remove legacy `deposits` and `eth1_data` fields from `BeaconBlockBody` after EIP-6110 finalization

<h2 id="abstract">Abstract</h2> <p>This EIP removes the legacy <code>deposits</code> and <code>eth1_data</code> fields from the <code>BeaconBlockBody</code> structure after <a href="https://wg-eips.ritovision.com/6110/">EIP-6110</a> has been fully finalized. These fields become obsolete once all validators have transitioned to the new in-protocol deposit processing mechanism introduced in EIP-6110.</p> <h2 id="motivation">Motivation</h2> <p>EIP-6110 introduced in-protocol deposit processing by moving validator deposits to the execution layer as part of the EIP-7685 request framework. This change eliminated the need for the consensus layer's proposer voting mechanism for deposits. However, during the transition period, both the legacy deposit mechanism (using <code>deposits</code> and <code>eth1_data</code> fields) and the new mechanism coexist to ensure smooth migration.</p> <p>Once EIP-6110 has been fully finalized and the transition period is complete (when <code>state.eth1_deposit_index == state.deposit_requests_start_index</code>), the legacy deposit fields become permanently unused and can be safely removed. This cleanup provides several benefits:</p> <ul> <li><strong>Simplified validation</strong>: Removes deprecated validation logic and code paths</li> <li><strong>Improved maintainability</strong>: Eliminates technical debt from the transition period</li> </ul> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <h3 id="consensus-layer">Consensus Layer</h3> <h4 id="activation-conditions">Activation Conditions</h4> <p>This EIP SHALL only be activated when both of the following conditions are met:</p> <ol> <li>EIP-6110 has been fully finalized: <code>state.eth1_deposit_index == state.deposit_requests_start_index</code></li> <li>EIP-7732 is in effect</li> </ol> <h4 id="beaconblockbody-modifications">BeaconBlockBody Modifications</h4> <p>The <code>BeaconBlockBody</code> container is modified to remove the following fields:</p> <p><strong>Removed fields:</strong></p> <ul> <li><code>deposits: List[Deposit, MAX_DEPOSITS]</code></li> <li><code>eth1_data: Eth1Data</code></li> </ul> <p>The updated <code>BeaconBlockBody</code> structure becomes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconBlockBody</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> randao_reveal</span><span>:</span><span> BLSSignature</span></span> <span class="giallo-l"><span> graffiti</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> proposer_slashings</span><span>:</span><span> List</span><span>[</span><span>ProposerSlashing</span><span>,</span><span class="z-constant"> MAX_PROPOSER_SLASHINGS</span><span>]</span></span> <span class="giallo-l"><span> attester_slashings</span><span>:</span><span> List</span><span>[</span><span>AttesterSlashing</span><span>,</span><span class="z-constant"> MAX_ATTESTER_SLASHINGS_ELECTRA</span><span>]</span></span> <span class="giallo-l"><span> attestations</span><span>:</span><span> List</span><span>[</span><span>Attestation</span><span>,</span><span class="z-constant"> MAX_ATTESTATIONS_ELECTRA</span><span>]</span></span> <span class="giallo-l"><span> voluntary_exits</span><span>:</span><span> List</span><span>[</span><span>SignedVoluntaryExit</span><span>,</span><span class="z-constant"> MAX_VOLUNTARY_EXITS</span><span>]</span></span> <span class="giallo-l"><span> sync_aggregate</span><span>:</span><span> SyncAggregate</span></span> <span class="giallo-l"><span> bls_to_execution_changes</span><span>:</span><span> List</span><span>[</span><span>SignedBLSToExecutionChange</span><span>,</span><span class="z-constant"> MAX_BLS_TO_EXECUTION_CHANGES</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> From EIP-7732</span></span> <span class="giallo-l"><span> signed_execution_payload_header</span><span>:</span><span> SignedExecutionPayloadHeader</span></span> <span class="giallo-l"><span> payload_attestations</span><span>:</span><span> List</span><span>[</span><span>PayloadAttestation</span><span>,</span><span class="z-constant"> MAX_PAYLOAD_ATTESTATIONS</span><span>]</span></span></code></pre><h4 id="validation-changes">Validation Changes</h4> <p><strong>Block processing modifications:</strong></p> <ol> <li>Remove <code>process_eth1_data()</code> function calls from block processing</li> <li>Remove <code>process_deposits()</code> function calls from block processing</li> <li>Remove eth1_data voting validation logic</li> <li>Remove legacy deposit validation logic</li> </ol> <p><strong>State transition modifications:</strong></p> <ol> <li>Remove eth1_data related fields from state transition functions</li> <li>Remove legacy deposit processing from <code>process_operations()</code></li> </ol> <h4 id="beaconstate-cleanup">BeaconState Cleanup</h4> <p>The following fields become unused after activation and MAY be removed in future updates:</p> <ul> <li><code>eth1_data: Eth1Data</code></li> <li><code>eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]</code></li> <li><code>eth1_deposit_index: uint64</code></li> </ul> <p>Note: These fields are kept for historical state root verification but are no longer actively used.</p> <h2 id="rationale">Rationale</h2> <h3 id="timing-of-removal">Timing of Removal</h3> <p>The fields are removed after EIP-6110 finalization to ensure:</p> <ul> <li>All pending deposits from the legacy system have been processed</li> <li>No validator can be affected by the removal</li> <li>The transition is complete and irreversible</li> <li>State consistency is maintained across all honest nodes</li> </ul> <h3 id="dependency-on-eip-7732">Dependency on EIP-7732</h3> <p>This EIP requires EIP-7732 because:</p> <ul> <li>EIP-7732 already modified the <code>BeaconBlockBody</code> structure significantly</li> <li>It provides the architectural foundation for simplified block bodies</li> <li>The timing aligns with the broader consensus layer improvements</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h2 id="security-considerations">Security Considerations</h2> <p>The removal of legacy fields poses minimal security risk because:</p> <ul> <li>The fields are already unused after EIP-6110 finalization</li> <li>All deposits are processed through the new EIP-6110 mechanism</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Greg Colvinhttps://github.com/gcolvin Alex Beregszaszihttps://github.com/axic Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/8013/

Relative jump and call instructions with a signed immediate encoding the jump destination

<h2 id="abstract">Abstract</h2> <p>Five new EVM jump instructions are introduced (<code>RJUMP</code>, <code>RJUMPI</code>, <code>RJUMPV</code>, <code>RJUMPSUB</code>, and <code>RJUMPSUBV</code>) which encode destinations as signed immediate values. These can be useful in almost all <code>JUMP</code> and <code>JUMPI</code> use cases and offer improvements in cost, performance, and static analysis.</p> <h2 id="motivation">Motivation</h2> <p>A recurring discussion topic is that the EVM only has a mechanism for dynamic jumps. They provide a very flexible architecture with only 2 (!) instructions. This flexibility comes at a cost however: it makes analysis of code more complicated, often intractable, and it also (partially) resulted in the need to have the <code>JUMPDEST</code> marker.</p> <p>In a great many cases control flow is actually static and there is no need for any dynamic behaviour, though not every use case can be solved by static jumps.</p> <p>There are various ways to reduce the need for dynamic jumps, some examples:</p> <ol> <li>With native support for functions / subroutines</li> <li>A "return to caller" instruction -- a form of subroutine return</li> <li>A "switch-case" table with dynamic indexing</li> </ol> <p>This proposal introduces a minimal feature set - including the above - to allow compilers to use <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPSUB</code> exclusively.</p> <p>This functionality does not preclude the EVM from introducing other forms of control flow later on. <code>RJUMP</code>/<code>RJUMPI</code> can efficiently co-exists with a higher-level declaration of functions, where static relative jumps should be used for intra-function control flow. This functionality also does not preclude the use of legacy code.</p> <p>The main benefit of these instruction is reduced gas cost (both at deploy and execution time), better performance and better static analysis properties.</p> <h2 id="specification">Specification</h2> <p>We introduce five new instructions, each taking either a two-byte relative offset or else a table of offsets as immediate arguments.</p> <ol> <li>relative jump: <ul> <li><code>RJUMP (0xe0) relative_offset</code> <ul> <li>sets the <code>PC</code> to <code>PC_post_instruction + relative_offset</code>, where</li> <li><code>relative_offset</code> is encoded as a 16-bit <strong>signed</strong> (two's-complement) big-endian value.</li> </ul> </li> </ul> </li> <li>conditional relative jump: <ul> <li><code>RJUMPI (0xe1) relative_offset</code> <ul> <li>pops a value (<code>condition</code>) from the stack, and</li> <li>sets the <code>PC</code> to <code>PC_post_instruction + ((condition == 0) ? 0 : relative_offset)</code>.</li> </ul> </li> </ul> </li> <li>relative jump via jump table: <ul> <li><code>RJUMPV (0xe2) max_index relative_offset+</code> <ul> <li>pops a value (<code>case</code>) from the stack, and</li> <li>sets the <code>PC</code> to <code>PC_post_instruction + ((case &gt; max_index) ? 0 : relative_offset[case])</code>.</li> </ul> </li> </ul> </li> <li>relative jump to subroutine: <ul> <li><code>RJUMPSUB (0xe3) relative_offset</code> <ul> <li>pushes <code>PC_post_instruction</code> to the <code>return stack,</code> and</li> <li>sets the <code>PC</code> to <code>PC_post_instruction + relative_offset</code>, an <code>ENTERSUB</code>, as if with <code>CALLSUB</code>.</li> </ul> </li> </ul> </li> <li>relative jump to subroutine via jump table: <ul> <li>`RJUMPSUBV (0xe4) max_index relative_offset+ <ul> <li>pops a value (<code>case</code>) from the stack,</li> <li>pushes <code>PC_post_instruction</code> to the <code>return stack</code>, and</li> <li>sets the <code>PC</code> to <code>PC_post_instruction + ((case &gt; max_index) ? 0 : relative_offset[case])</code>, an <code>ENTERSUB</code>, as if with <code>CALLSUB</code>.</li> </ul> </li> </ul> </li> </ol> <p>Note that the destination of the <code>RJUMPSUB</code> and <code>RJUMPSUBV</code> opcodes MUST be an <code>ENTERSUB</code> and control is returned to a calling <code>RJUMPSUB</code> / <code>RJUMPSUBV</code> via <code>RETURNSUB</code> (See <a href="https://wg-eips.ritovision.com/7979/">EIP-7979</a>) -- these two forms of jump provide immediate access to the underlying "return-to-caller" mechanism of the <code>CALLSUB</code> instruction.</p> <p>The immediate argument <code>relative_offset</code> is encoded as a 16-bit <strong>signed</strong> (two's-complement) big-endian value. Under <code>PC_post_instruction</code> we mean the <code>PC</code> position after the entire immediate value.</p> <p>The immediate encoding of <code>RJUMPV</code> and <code>RjUMPSUBV</code> are more special: the unsigned 8-bit <code>max_index</code> value determines the maximum index in the jump table. The number of <code>relative_offset</code> values following is <code>max_index+1</code>. This allows table sizes up to 256. The encoding of <code>RJUMPV</code> must have at least one <code>relative_offset</code> and thus it will take at minimum 4 bytes. Furthermore, the <code>case &gt; max_index</code> condition falling through means that in many use cases, one would place the <em>default</em> path following the <code>RJUMPV</code> instruction. An interesting feature is that <code>RJUMPV 0 relative_offset</code> is an inverted-<code>RJUMPI</code>, which can be used in many cases instead of <code>ISZERO RJUMPI relative_offset</code>.</p> <p>We also extend the validation algorithm of <a href="https://wg-eips.ritovision.com/7979/">EIP-7979</a> to verify that every <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code>/<code>RJUMPSUB</code>/<code>RJUMPSUBV</code> has a <code>relative_offset</code> pointing to an instruction. This means it cannot point to an immediate data of <code>PUSHn</code>/<code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> and cannot point outside of code bounds. Further, <em>all and only</em> <code>RJUMPSUB</code> and <code>RJUMPSUBV</code> MUST have a <code>relative offset</code> pointing to an `ENTERSUB, whereas the others are allowed to point to a JUMPDEST, but are not required to.</p> <h3 id="costs">Costs</h3> <p>The immediate destinations are checked during jumpdest analysis and need not be checked again, so the cost of these instructions can be less than their dynamic counterparts. We recommend that</p> <ul> <li><code>RJUMP</code> should be 2,</li> <li><code>RJUMPI</code> and <code>RJUMPV</code> should be 4. and</li> <li><code>RJUMPSUB</code> and <code>RJUMPSUBV</code> should be 5.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="relative-addressing">Relative addressing</h3> <p>We chose relative addressing in order to support code which is relocatable. This also means a code snippet can be injected. A technique seen used prior to this EIP to achieve the same goal was to inject code like <code>PUSHn PC ADD JUMPI</code>.</p> <p>We do not see any significant downside to relative addressing and it allows us to also deprecate the <code>PC</code> instruction.</p> <h3 id="immediate-size">Immediate size</h3> <p>The signed 16-bit immediate means that the largest jump distance possible is 32767. In the case the bytecode at <code>PC=0</code> starts with an <code>RJUMP</code>, it will be possible to jump as far as <code>PC=32770</code>.</p> <p>Given <code>MAX_CODE_SIZE = 24576</code> (in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a>) and <code>MAX_INITCODE_SIZE = 49152</code> (in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>), we think the 16-bit immediate is large enough.</p> <p>A version with an 8-bit immediate would only allow moving <code>PC</code> backward by 125 or forward by 127 bytes. While that seems to be a good enough distance for many for-loops, it is likely not good enough for cross-function jumps, and since the 16-bit immediate is the same size as what a dynamic jump would take in such cases (3 bytes: <code>JUMP PUSH1 n</code>), we think having less instructions is better.</p> <p>Should there be a need to have immediate encodings of other size (such as 8-bits, 24-bits or 32-bits), it would be possible to introduce new opcodes, similarly to how multiple <code>PUSH</code> instructions exist.</p> <h3 id="pushn-jump-sequences"><code>PUSHn JUMP</code> sequences</h3> <p>If we chose absolute addressing, then <code>RJUMP</code> could be viewed similar to the sequence <code>PUSHn JUMP</code> (and <code>RJUMPI</code> similar to <code>PUSHn JUMPI</code>). In that case one could argue that instead of introducing a new instruction, such sequences should get a discount, because EVMs could optimise them.</p> <p>We think this is a bad direction to go, and we leave defining the semantics of existing <code>PUSHn JUMP</code> sequences to EIP-7979 and do not attempt to optimize their gas cost here.</p> <ol> <li>It further complicates the already complex rules of gas calculation.</li> <li>And it either requires a consensus defined internal representation for EVM code, or forces EVM implementations to do optimisations on their own.</li> </ol> <p>Both of these are risky. Furthermore we think that EVM implementations should be free to chose what optimisations they apply, and the savings do not need to be passed down at all cost.</p> <p>Additionally it requires a potentially significant change to the current implementations which depend on a streaming one-by-one execution without a lookahead.</p> <h3 id="lack-of-jumpdest">Lack of <code>JUMPDEST</code></h3> <p><code>JUMPDEST</code> serves two purposes:</p> <ol> <li>To efficiently partition code -- this can be useful for pre-calculating total gas usage for a given <em>block</em> (i.e. instructions between <code>JUMPDEST</code>s), and for JIT/AOT translation.</li> <li>To explicitly show valid locations (otherwise any non-data location would be valid).</li> </ol> <p>This functionality is not needed for static jumps, as the analysers can easily tell destinations from the static jump immediates during jumpdest-analysis.</p> <p>There are two benefits here:</p> <ol> <li>Not wasting a byte for a <code>JUMPDEST</code> also means a saving of 200 gas during deployment, for each jump destination.</li> <li>Saving an extra 1 gas per jump during execution, given <code>JUMPDEST</code> itself cost 1 gas and is "executed" during jumping.</li> </ol> <h3 id="rjumpv-and-rjumpsubv-fallback-cases"><code>RJUMPV</code> and <code>RJUMPSUBV</code> fallback cases</h3> <p>If no match is found (i.e. the <em>default</em> case) in the <code>RJUMPV</code> or <code>RJUMPSUBV</code> instructions execution will continue without branching. This allows for gaps in the arguments to be filled with <code>0</code>s, and a choice of implementation by the programmer. Alternate options would include exceptional aborts in case of no match.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="validation">Validation</h3> <h4 id="valid-cases">Valid cases</h4> <ul> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with <code>JUMPDEST</code> as target <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with instruction other than <code>JUMPDEST</code> as target <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li><code>RJUMPV</code> / <code>RJUMPSUBV</code> with various valid table sizes from 1 to 256</li> <li><code>RJUMP</code> as a final instruction in code section</li> </ul> <h4 id="invalid-cases">Invalid cases</h4> <ul> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with truncated immediate</li> <li><code>RJUMPI</code>/<code>RJUMPV</code> as a final instruction in code section</li> <li><code>RJUMPSUB</code> / <code>RJUMPSUBV</code> target not <code>ENTERSUB</code></li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> / <code>RJUMPSUB</code> / <code>RJUMPSUBV</code> target outside of code section bounds</li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> / <code>RJUMPSUB</code> / <code>RJUMPSUBV</code> target push data</li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> / <code>RJUMPSUB</code> / <code>RJUMPSUBV</code> target another <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> immediate argument</li> </ul> <h3 id="execution">Execution</h3> <ul> <li> <p><code>RJUMP</code></p> <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li> <p><code>RJUMPI</code></p> <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code> <ul> <li><code>condition</code> equals <code>0</code></li> <li><code>condition</code> does not equal <code>0</code></li> </ul> </li> </ul> </li> <li> <p><code>RJUMPV 0 relative_offset</code></p> <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> </ul> </li> <li> <p><code>RJUMPV</code> with table containing positive, negative, <code>0</code> offsets</p> <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> <li><code>case</code> outside of table bounds (<code>case &gt; max_index</code>, fallback case)</li> <li><code>case</code> &gt; 255</li> </ul> </li> <li> <p><code>RJUMPSUB</code></p> <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li> <p><code>RJUMPSUBV 0 relative_offset</code></p> <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> </ul> </li> <li> <p><code>RJUMPSUBV</code> with table containing positive, negative, <code>0</code> offsets</p> <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> <li><code>case</code> outside of table bounds (<code>case &gt; max_index</code>, fallback case)</li> <li><code>case</code> &gt; 255</li> </ul> </li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Adding new instructions with immediate arguments should be carefully considered when implementing the validation algorithm.</p> <p>Static relative jump execution does not require runtime check of the jump destination. It greatly reduces execution cost. Therefore the gas cost of the new instructions can also be significantly reduced.</p> <p>The <code>RJUMPV</code>and <code>RJUMPSUBV</code> instruction relative offset tables can have up to 256 one-byte entries, so reading an offset cannot be a potential DoS attack surface.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francisco Giordanohttps://github.com/frangio Charles Cooperhttps://github.com/charles-cooper Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/8024/

Introduce additional instructions for manipulating the stack which allow accessing the stack at higher depths

<h2 id="abstract">Abstract</h2> <p>Currently, <code>SWAP*</code> and <code>DUP*</code> instructions are limited to a stack depth of 16. Introduce three new instructions, <code>SWAPN</code>, <code>DUPN</code> and <code>EXCHANGE</code> which lift this limitation and allow accessing the stack at higher depths.</p> <h2 id="motivation">Motivation</h2> <p>While the stack is 1024 items deep, easy access is only possible for the top 16 items. Supporting more local variables is possible via manually keeping them in memory or through a "stack to memory elevation" in a compiler. This can result in complex and inefficient code.</p> <p>Furthermore, implementing higher level constructs, such as functions, on top of EVM will result in a list of input and output parameters as well as an instruction offset to return to.</p> <p>The number of these arguments (or stack items) can easily exceed 16 and thus will require extra care from a compiler to lay them out in a way that all of them are still accessible.</p> <p>Lastly, swapping items besides the 1st and Nth items in the stack is very important for compilers implementing stack scheduling algorithms (the analog of register allocation for stack machines), which try to minimize stack traffic given a set of variables and usage analysis.</p> <p>Introducing <code>SWAPN</code>, <code>DUPN</code>, and <code>EXCHANGE</code> will provide an option to compilers to simplify accessing deep stack items.</p> <h2 id="specification">Specification</h2> <p>We introduce three new instructions:</p> <ul> <li><code>DUPN</code> (<code>0xe6</code>)</li> <li><code>SWAPN</code> (<code>0xe7</code>)</li> <li><code>EXCHANGE</code> (<code>0xe8</code>)</li> </ul> <p>Each instruction carries one or two immediate operands. Informally, using 1-based indexing, the semantics are:</p> <ul> <li><code>DUPN n</code>: The <code>n</code>'th stack item is duplicated at the top of the stack.</li> <li><code>SWAPN n</code>: The <code>n + 1</code>'th stack item is swapped with the top of the stack.</li> <li><code>EXCHANGE n m</code>: The <code>n + 1</code>'th stack item is swapped with the <code>m + 1</code>'th stack item.</li> </ul> <p>Formally, when <code>code[pc]</code> is one of these opcodes, the VM executes as follows:</p> <ul> <li><code>DUPN</code>: <ol> <li>Charge 3 gas.</li> <li>Let <code>x = code[pc + 1]</code>.</li> <li>If <code>90 &lt; x &lt; 128</code>, halt with exceptional failure.</li> <li>Let <code>n = decode_single(x)</code>.</li> <li>If <code>n &gt; len(stack)</code>, halt with exceptional failure.</li> <li>Push <code>stack[top - n + 1]</code> on the stack.</li> <li>Set <code>pc = pc + 2</code>.</li> </ol> </li> <li><code>SWAPN</code>: <ol> <li>Charge 3 gas.</li> <li>Let <code>x = code[pc + 1]</code>.</li> <li>If <code>90 &lt; x &lt; 128</code>, halt with exceptional failure.</li> <li>Let <code>n = decode_single(x)</code>.</li> <li>If <code>n + 1 &gt; len(stack)</code>, halt with exceptional failure.</li> <li>Swap <code>stack[top - n]</code> and <code>stack[top]</code>.</li> <li>Set <code>pc = pc + 2</code>.</li> </ol> </li> <li><code>EXCHANGE</code>: <ol> <li>Charge 3 gas.</li> <li>Let <code>x = code[pc + 1]</code>.</li> <li>If <code>79 &lt; x &lt; 128</code>, halt with exceptional failure.</li> <li>Let <code>n, m = decode_pair(x)</code>.</li> <li>If <code>m + 1 &gt; len(stack)</code>, halt with exceptional failure.</li> <li>Swap <code>stack[top - n]</code> and <code>stack[top - m]</code>.</li> <li>Set <code>pc = pc + 2</code>.</li> </ol> </li> </ul> <p><code>code[pc + 1]</code> evaluates to <code>0</code> if beyond the end of the code, matching <code>PUSH</code> behavior.</p> <p><code>top</code> denotes the index of the value at the top of the stack.</p> <p><code>JUMPDEST</code> analysis is unchanged. In particular, if <code>code[i]</code> is at an instruction boundary and is one of these opcodes, and <code>code[i + 1]</code> is <code>0x5b</code> (<code>JUMPDEST</code>), then <code>code[i + 1]</code> is a valid jump target. Note that in this case the execution of <code>code[i]</code> would halt at step 2 above (because <code>x = code[i + 1] = 0x5b = 91</code>). Disassemblers must decode such <code>code[i]</code> as <code>INVALID</code> (or <code>INVALID_DUPN</code>, etc.) and <code>code[i + 1]</code> as <code>JUMPDEST</code>.</p> <p>The auxiliary functions <code>decode_single</code> and <code>decode_pair</code> are defined by the following Python code:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> decode_single</span><span>(</span><span class="z-variable z-parameter z-function">x</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 0</span><span class="z-keyword"> &lt;=</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 90</span><span class="z-keyword"> or</span><span class="z-constant"> 128</span><span class="z-keyword"> &lt;=</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 255</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 90</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> x</span><span class="z-keyword"> +</span><span class="z-constant"> 17</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> x</span><span class="z-keyword"> -</span><span class="z-constant"> 20</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> decode_pair</span><span>(</span><span class="z-variable z-parameter z-function">x</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span> tuple</span><span>[</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 0</span><span class="z-keyword"> &lt;=</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 79</span><span class="z-keyword"> or</span><span class="z-constant"> 128</span><span class="z-keyword"> &lt;=</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 255</span></span> <span class="giallo-l"><span> k</span><span class="z-keyword"> =</span><span> x</span><span class="z-keyword"> if</span><span> x</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 79</span><span class="z-keyword"> else</span><span> x</span><span class="z-keyword"> -</span><span class="z-constant"> 48</span></span> <span class="giallo-l"><span> q</span><span>,</span><span> r</span><span class="z-keyword"> =</span><span class="z-support"> divmod</span><span>(</span><span>k</span><span>,</span><span class="z-constant"> 16</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> q</span><span class="z-keyword"> &lt;</span><span> r</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> q</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>,</span><span> r</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> r</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 29</span><span class="z-keyword"> -</span><span> q</span></span></code></pre> <p>Assemblers and compilers must emit a 1-byte immediate after each of these opcodes that decodes to the required <code>n, m</code> operands. For reference, this can be done by <code>encode_single</code> and <code>encode_pair</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> encode_single</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 17</span><span class="z-keyword"> &lt;=</span><span> n</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 235</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> n</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 107</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> n</span><span class="z-keyword"> -</span><span class="z-constant"> 17</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> n</span><span class="z-keyword"> +</span><span class="z-constant"> 20</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> encode_pair</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> m</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 1</span><span class="z-keyword"> &lt;=</span><span> n</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 13</span><span class="z-keyword"> and</span><span> n</span><span class="z-keyword"> &lt;</span><span> m</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 29</span><span class="z-keyword"> and</span><span> n</span><span class="z-keyword"> +</span><span> m</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 30</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> m</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 16</span><span>:</span></span> <span class="giallo-l"><span> q</span><span>,</span><span> r</span><span class="z-keyword"> =</span><span> n</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>,</span><span> m</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> q</span><span>,</span><span> r</span><span class="z-keyword"> =</span><span class="z-constant"> 29</span><span class="z-keyword"> -</span><span> m</span><span>,</span><span> n</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> k</span><span class="z-keyword"> =</span><span class="z-constant"> 16</span><span class="z-keyword"> *</span><span> q</span><span class="z-keyword"> +</span><span> r</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> k</span><span class="z-keyword"> if</span><span> k</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 79</span><span class="z-keyword"> else</span><span> k</span><span class="z-keyword"> +</span><span class="z-constant"> 48</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="use-of-an-immediate-operand">Use of an immediate operand</h3> <p>Allowing dynamic selection of the arguments to swap or dup could be used to prevent static analysis of the contents of the stack. Since static analysis is an important tool for security auditors we want to do what we can to make their jobs easier. Hence, the operands require an immediate operand that is not dynamic in nature.</p> <h3 id="disallowed-immediate-range">Disallowed immediate range</h3> <p>A property the EVM has is that it's not possible to jump to the middle of an instruction. In order to guarantee this property, the immediate operands of <code>PUSH*</code> instructions are masked from jumpdest analysis so that the occurrence of <code>0x5b</code> in them is not mistaken for a <code>JUMPDEST</code> instruction, which should be considered a valid jump target elsewhere.</p> <p>The new instructions in this EIP preserve this property without changing jumpdest analysis by making it invalid for their immediates to contain <code>0x5b</code>, in addition to <code>0x60</code> to <code>0x7f</code> (<code>PUSH1</code> to <code>PUSH32</code>) since those would cause the subsequent instructions to be masked.</p> <p>The alternative, changing jumpdest analysis to introduce new masked opcodes, would create a backwards incompatibility if done without bytecode versioning (EOF). Consider the bytecode sequence <code>e6 5b</code> that decodes to <code>INVALID JUMPDEST</code> prior to this EIP, and thus contains a valid jump target. If an instruction <code>DUPN x</code> were introduced with encoding <code>e6 {x}</code> (opcode immediately followed by operand), and jumpdest analysis changed to mask the operand to <code>e6</code>, the same bytecode sequence <code>e6 5b</code> would then decode to <code>DUPN 0x5b</code>. As a result of the upgrade, <code>e6</code> would become an invalid jump target, breaking contracts that include this sequence. The opposite can happen with push opcodes, for example, <code>e6 60 5b</code> would transform from <code>INVALID PUSH1 0x5b</code> to <code>DUPN 0x60 JUMPDEST</code>, creating a new valid jump target. Furthermore, this may have a cascading effect on arbitrarily many subsequent instructions.</p> <p>Since the EVM doesn't offer a dedicated section for data, arbitrary data may be embedded in code and serve as immutable data storage accessed via <code>CODECOPY</code>. Therefore, we must assume that arbitrary byte sequences may be found in contracts that have been deployed or are included in transactions yet to be published on chain.</p> <p>This EIP is designed to uphold the following backwards compatibility guarantee: every possible execution trace on a given bytecode that does not attempt to execute an undefined opcode must continue to produce the same effect after the introduction of an instruction. No new <code>JUMPDEST</code>s must be created in a given bytecode by the introduction of an instruction and none may be removed.</p> <p>This encoding can be reused in future instructions with immediate operands, although it is not necessary if the range of the operand naturally does not include the bytes <code>0x5b</code> (<code>JUMPDEST</code>) or <code>0x60</code> (<code>PUSH1</code>) to <code>0x7f</code> (<code>PUSH32</code>), in which case masking is not necessary.</p> <h3 id="exchange-immediate"><code>EXCHANGE</code> immediate</h3> <p>A previous formulation of <code>EXCHANGE</code> allowed swapping stack elements only if they were within some distance. As a result, it would be possible to swap the elements at indices 30 and 29, but not possible to move an element from index 30 to 2 with a single instruction. The current formulation prioritizes the latter, on the assumption that it is more valuable to move elements closer to the top of the stack than it is to rearrange elements deeper in the stack.</p> <p>In addition, the exact formulation was chosen to make <code>decode_pair</code> a simple function using only basic arithmetic, bitwise operations (division by 16), and few branches. A small trade-off in the number of addressable pairs was made to reduce the number of necessary branches; this implies some of the immediate range is not allocated, and it could be used to add a dozen more addressable pairs at the cost of more decoding complexity, potentially in a future network upgrade.</p> <p>Finally, note that the operands in the assembly instruction <code>EXCHANGE n m</code> appear "off by one", i.e. it operates on the stack elements at depths <code>n + 1</code> and <code>m + 1</code>. These offsets were chosen to match the <code>SWAP</code> and <code>SWAPN</code> opcodes such that <code>EXCHANGE n m</code> has an effect equivalent to the sequence <code>SWAP{n} SWAP{m} SWAP{n}</code>.</p> <h3 id="size-of-immediate-operand">Size of immediate operand</h3> <p>For <code>DUPN</code> and <code>SWAPN</code> a 16-bit size was considered to accommodate the full stack space of 1024 items, however:</p> <ol> <li>that would require an additional restriction/check (<code>n &lt; 1024</code>)</li> <li>the 256 depth is a large improvement over the current 16 and the overhead of an extra byte would make it less useful</li> </ol> <p>Similarly for <code>EXCHANGE</code>, the proposed scheme allows addressing of 30 items.</p> <h3 id="gas-cost">Gas cost</h3> <p>The gas cost for these operations is the same as for existing <code>DUP*</code> and <code>SWAP*</code> instructions, because they are just implemented as pointer swaps and immediate decoding is negligible.</p> <h3 id="exchange-vs-swapn"><code>EXCHANGE</code> vs <code>SWAPN</code></h3> <p>As mentioned before, <code>EXCHANGE</code> is important to compilers implementing stack scheduling algorithms. Specifically, in the case that a stack item is scheduled to be consumed deeper in the stack (for instance, the 3rd item in the stack needs to be moved into 2nd position in order to be consumed by the next operation), that currently takes three instructions, <code>SWAP2 SWAP3 SWAP2</code>. However, in the EVM implementation, the implementation is just a pointer swap, so it could be implemented in a single instruction at no extra runtime cost to the client.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This has no effect on contracts that would never attempt to execute the opcodes allocated by this EIP. The jump targets of existing contracts are preserved.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="assembly-disassembly">Assembly/Disassembly</h3> <ul> <li><code>e600</code> is <code>[DUPN 17]</code></li> <li><code>e780</code> is <code>[SWAPN 108]</code></li> <li><code>e6005b</code> is <code>[DUPN 17, JUMPDEST]</code></li> <li><code>e75b</code> is <code>[INVALID_SWAPN, JUMPDEST]</code></li> <li><code>e6605b</code> is <code>[INVALID_DUPN, PUSH1 0x5b]</code></li> <li><code>e7610000</code> is <code>[INVALID_SWAPN, PUSH2 0x0000]</code></li> <li><code>e65f</code> is <code>[INVALID_DUPN, PUSH0]</code></li> <li><code>e812</code> is <code>[EXCHANGE 2 3]</code></li> <li><code>e8d0</code> is <code>[EXCHANGE 1 19]</code></li> <li><code>e850</code> is <code>[INVALID_EXCHANGE, POP]</code></li> </ul> <h3 id="execution">Execution</h3> <ul> <li><code>60016000808080808080808080808080808080e600</code> results in 18 stack items, the top of the stack valued 1, the bottom of the stack valued 1, the rest valued 0 <ul> <li><code>60016000808080808080808080808080808080e6</code> at the end of the code is equivalent to above</li> </ul> </li> <li><code>600160008080808080808080808080808080806002e700</code> results in 18 stack items, the top of the stack valued 1, the bottom of the stack valued 2, the rest valued 0 <ul> <li><code>600160008080808080808080808080808080806002e7</code> at the end of the code is equivalent to above</li> </ul> </li> <li><code>600060016002e801</code> results in 3 stack items, from top to bottom: [2, 0, 1]</li> <li><code>600060006000600060006000600060006000600060006000600060006000600060006000600060006000600060006000600060006000600060016002e8</code> results in 30 stack items, the top of the stack valued 2, the bottom of the stack valued 1, the rest valued 0</li> <li><code>e75b</code> reverts</li> <li><code>600456e65b</code> executes successfully (<code>PUSH 04 JUMP INVALID_DUPN JUMPDEST</code>)</li> <li><code>600060006000e80115</code> results in 3 stack items, the top of the stack valued 1, the rest valued 0</li> <li><code>6000808080808080808080808080808080e600</code> results in exceptional halt</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>The authors are not aware of any additional risks introduced here. The EVM stack is fixed at 1024 items and most implementations keep that in memory at all times. This change will increase the number of stack items accessible via single instruction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7999/

Let transactions specify one aggregate `max_fee` budget for all resources, unify fee markets, normalize gas, and generalize EIP-7918.

<h2 id="abstract">Abstract</h2> <p>A unified multidimensional fee market is introduced, where each transaction specifies the maximum amount of ETH it is willing to pay for inclusion using a single <code>max_fee</code>. Upon inclusion, the protocol ensures that the transaction is able to pay the gas for all dimensions, treating the <code>max_fee</code> as fungible across resources. This enables a more efficient use of capital, and enshrines the same representation that users have when they interact with Ethereum. The fee market is further unified in terms of a single update fraction under a single fee update mechanism, generalized reserve pricing, and a gas normalization that retains current percentage ranges while keeping the price stable whenever a gas limit changes. Calldata is proposed as the first resource to be added, with avenues for facilitating gas fungibility for EVM resources considered for further expansion.</p> <h2 id="motivation">Motivation</h2> <p>A multidimensional fee market enables precise control over resource consumption. It allows <em>the market</em> to fairly price resources according to targets and limits deemed safe by developers, and it allows resources to be consumed at maximum capacity within these limits. Directly expanding the current fee market design to the multidimensional setting can however have negative effects on the user experience (UX) and on economic efficiency. Users are forced to set a <code>max_fee_per_gas</code> for each resource, where a too low allocation in any dimension can render the transaction ineligible.</p> <p>This EIP leverages the natural fungibility of the user's fee budget by letting users set a single unified <code>max_fee</code>. Instead of using non-fungible per-resource budgets, the single ETH budget can then be allocated dynamically to cover costs wherever they arise, ensuring a more efficient use of capital. Users will be able to specify a lower <code>max_fee</code> than the implied aggregate maximum unless all base fees are perfectly correlated (which reduces to the current design), because they do not need to buffer for spurious price movements in a single resource dimension.</p> <p>Ethereum's current fee market has "tech debt" in that two separate mechanisms are used: one for regular gas (<a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>) and the other for blob gas (<a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>). The proposal unifies the fee market under the preferred EIP-4844 design. That design allows for exact control over long-run resource consumption. In a multidimensional setting with individual base fees, we can then for example achieve precise control over state growth, while accommodating temporary spikes. Excess gas of EIP-4844 is further normalized relative to the limit, allowing for a single update fraction across resources that retains current percentage ranges while keeping the price stable if any gas limit changes.</p> <p>Calldata is added first, to speed up worst-case payload propagation and expand available EVM gas—without compromising gas introspection. A method for facilitating gas aggregation across resources within the EVM is outlined as an avenue for preserving backward compatibility when expanding further. The logic of EIP-7918 is integrated into the multidimensional setting to ensure that calldata has a higher cost per byte than blob data.</p> <h2 id="specification">Specification</h2> <p>The specification inherits its logic from <a href="https://wg-eips.ritovision.com/7706/">EIP-7706</a>, incorporating the changes necessary for facilitating one aggregate fee, a multidimensional <a href="https://wg-eips.ritovision.com/7918/">EIP-7918</a> logic, a systematic approach to <a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a>, and a stable gas normalization function, etc.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th style="text-align: left">Constant</th><th style="text-align: left">Value</th><th style="text-align: left">Description</th></tr></thead><tbody> <tr><td style="text-align: left"><code>MULTIDIM_TX_TYPE</code></td><td style="text-align: left"><code>TBD</code> <!-- TODO --></td><td style="text-align: left">Identifier for the new transaction type</td></tr> <tr><td style="text-align: left"><code>EVM_LIMIT_TARGET_RATIO</code></td><td style="text-align: left"><code>2</code></td><td style="text-align: left">Ratio of EVM gas target to EVM gas limit</td></tr> <tr><td style="text-align: left"><code>CALLDATA_GAS_PER_TOKEN</code></td><td style="text-align: left"><code>4</code></td><td style="text-align: left">Gas cost per token for calldata</td></tr> <tr><td style="text-align: left"><code>TOKENS_PER_NONZERO_BYTE</code></td><td style="text-align: left"><code>4</code></td><td style="text-align: left">Tokens per non-zero byte of calldata</td></tr> <tr><td style="text-align: left"><code>CALLDATA_GAS_LIMIT_RATIO</code></td><td style="text-align: left"><code>4</code></td><td style="text-align: left">Ratio of calldata limit to gas limit</td></tr> <tr><td style="text-align: left"><code>CALLDATA_LIMIT_TARGET_RATIO</code></td><td style="text-align: left"><code>4</code></td><td style="text-align: left">Ratio of calldata target to calldata limit</td></tr> <tr><td style="text-align: left"><code>GAS_RESERVE_FACTOR</code></td><td style="text-align: left"><code>[0, 16, 12]</code></td><td style="text-align: left">Factor by which the base fee can be below the baseline</td></tr> <tr><td style="text-align: left"><code>GAS_RESERVE_INDEX</code></td><td style="text-align: left"><code>[0, 0, 1]</code></td><td style="text-align: left">Index of the base fee to compare against</td></tr> <tr><td style="text-align: left"><code>MIN_BASE_FEE_PER_GAS</code></td><td style="text-align: left"><code>1</code></td><td style="text-align: left">Minimum base fee per gas unit</td></tr> <tr><td style="text-align: left"><code>GAS_NORMALIZATION_FACTOR</code></td><td style="text-align: left"><code>10**9</code></td><td style="text-align: left">Normalization factor for the delta excess gas</td></tr> <tr><td style="text-align: left"><code>BASE_FEE_UPDATE_FRACTION</code></td><td style="text-align: left"><code>4_245_093_508</code></td><td style="text-align: left">≈ <code>GAS_NORMALIZATION_FACTOR / (2 * ln(1.125))</code></td></tr> </tbody></table> <h3 id="new-transaction-type">New transaction type</h3> <p>Upon activation of this EIP via hard fork, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> = <code>MULTIDIM_TX_TYPE</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, gas_limit, to, value, data, access_list, blob_versioned_hashes, max_fee, max_priority_fee_per_gas, y_parity, r, s]</span></span></code></pre> <p>We require <code>max_fee</code> to be a scalar integer from <code>0</code> to <code>2**128-1</code> and <code>max_priority_fee_per_gas</code> to be a list of integers from <code>0</code> to <code>2**64-1</code>, either of length 1 or with the same length as the number of resources (initially 3). The <code>gas_limit</code> is initially specified only for the main EVM gas, since other limits can be inferred from the transaction. To facilitate further expansion, the Python spec uses a list with a single element at index 0. Each added integer will range from <code>0</code> to <code>2**64-1</code>.</p> <p>The intrinsic cost of the new transaction is inherited from EIP-4844, except that the calldata gas cost (16 per non-zero byte, 4 per zero byte) is removed.</p> <h3 id="block-processing-and-transaction-fees">Block processing and transaction fees</h3> <p>Helpers for vector operations:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> all_less_or_equal</span><span>(</span><span class="z-variable z-parameter z-function">v1</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> v2</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> all</span><span>(</span><span>x</span><span class="z-keyword"> &lt;=</span><span> y</span><span class="z-keyword"> for</span><span> x</span><span>,</span><span> y</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>v1</span><span>,</span><span> v2</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> vector_add</span><span>(</span><span class="z-variable z-parameter z-function">v1</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> v2</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>)</span><span> -&gt;</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>x</span><span class="z-keyword">+</span><span>y</span><span class="z-keyword"> for</span><span> x</span><span>,</span><span> y</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>v1</span><span>,</span><span> v2</span><span>)</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> vector_mul</span><span>(</span><span class="z-variable z-parameter z-function">v1</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> v2</span><span>:</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>)</span><span> -&gt;</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>x</span><span class="z-keyword">*</span><span>y</span><span class="z-keyword"> for</span><span> x</span><span>,</span><span> y</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>v1</span><span>,</span><span> v2</span><span>)</span><span>]</span></span></code></pre> <p>Helper functions for computing scalar max fees/priority fees for all transaction types:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_max_fee</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> MULTIDIM_TX_TYPE</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New tx type already has a max_fee</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>max_fee</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Account for blobs in blob txs</span></span> <span class="giallo-l"><span> blob_gas</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_PER_BLOB</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword">*</span><span>tx</span><span>.</span><span>gas_limit</span><span class="z-keyword"> +</span><span> tx</span><span>.</span><span>max_fee_per_blob_gas</span><span class="z-keyword">*</span><span>blob_gas</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> is_eip_1559</span><span>(</span><span>tx</span><span>.</span><span>type</span><span>)</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-1559 txs have no blobs</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>gas_limit</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Legacy transactions have a gasprice</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tx</span><span>.</span><span>gasprice</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>gas_limit</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_priority_fee</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>,</span><span class="z-variable z-parameter z-function"> gas</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> base_fees</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> remaining_fee</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Precalculate total gas and fees for non-blob resources</span></span> <span class="giallo-l"><span> tip_indices</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 2</span><span>]</span></span> <span class="giallo-l"><span> tgas</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span> tip_indices</span><span>)</span></span> <span class="giallo-l"><span> tfee</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> *</span><span> base_fees</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span> tip_indices</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> MULTIDIM_TX_TYPE</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New tx type: Single tip or full vector of tips</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>max_priority_fee_per_gas</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span> tmax_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>max_fee</span><span class="z-keyword"> -</span><span> gas</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> *</span><span> base_fees</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ignore blobs (as now)</span></span> <span class="giallo-l"><span> tpriority_fee</span><span class="z-keyword"> =</span><span> tmax_fee</span><span class="z-keyword"> -</span><span> tfee</span><span class="z-keyword"> if</span><span> tmax_fee</span><span class="z-keyword"> &gt;</span><span> tfee</span><span class="z-keyword"> else</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_priority_fee</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>tx</span><span>.</span><span>max_priority_fee_per_gas</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> *</span><span> tgas</span><span>,</span><span> tpriority_fee</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> max_priority_fee</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>vector_mul</span><span>(</span><span>tx</span><span>.</span><span>max_priority_fee_per_gas</span><span>,</span><span> gas</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> min</span><span>(</span><span>max_priority_fee</span><span>,</span><span> remaining_fee</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_legacy</span><span>(</span><span>tx</span><span>.</span><span>type</span><span>)</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Legacy tx: The remainder after base fees paid</span></span> <span class="giallo-l"><span> tmax_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gasprice</span><span class="z-keyword"> *</span><span> tgas</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tmax_fee</span><span class="z-keyword"> -</span><span> tfee</span><span class="z-keyword"> if</span><span> tmax_fee</span><span class="z-keyword"> &gt;</span><span> tfee</span><span class="z-keyword"> else</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-1559 or Blob tx</span></span> <span class="giallo-l"><span> tmax_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> *</span><span> tgas</span></span> <span class="giallo-l"><span> tpriority_fee</span><span class="z-keyword"> =</span><span> tmax_fee</span><span class="z-keyword"> -</span><span> tfee</span><span class="z-keyword"> if</span><span> tmax_fee</span><span class="z-keyword"> &gt;</span><span> tfee</span><span class="z-keyword"> else</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_priority_fee</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>tx</span><span>.</span><span>max_priority_fee_per_gas</span><span class="z-keyword"> *</span><span> tgas</span><span>,</span><span> tpriority_fee</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Clamp since blobs reduce the shared max_fee budget</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> min</span><span>(</span><span>max_priority_fee</span><span>,</span><span> remaining_fee</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> max_priority_fee</span></span></code></pre> <p>The calldata resource pricing under this EIP follows previous gas per byte constants but deprecates the floor pricing specified in <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_calldata_gas</span><span>(</span><span class="z-variable z-parameter z-function">calldata</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> tokens</span><span class="z-keyword"> =</span><span> calldata</span><span>.</span><span>count</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> +</span><span> (</span><span class="z-support">len</span><span>(</span><span>calldata</span><span>)</span><span class="z-keyword"> -</span><span> calldata</span><span>.</span><span>count</span><span>(</span><span class="z-constant">0</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> TOKENS_PER_NONZERO_BYTE</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tokens</span><span class="z-keyword"> *</span><span class="z-constant"> CALLDATA_GAS_PER_TOKEN</span></span></code></pre> <p>The helper for calculating gas limits from EIP-7706 is adjusted to subtract calldata gas from the gas limit of old transactions:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_gas_limits</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> calldata_gas</span><span class="z-keyword"> =</span><span> get_calldata_gas</span><span>(</span><span>tx</span><span>.</span><span>data</span><span>)</span></span> <span class="giallo-l"><span> blob_gas</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span class="z-support">getattr</span><span>(</span><span>tx</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">blob_versioned_hashes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span> [</span><span>]</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_PER_BLOB</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> MULTIDIM_TX_TYPE</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> We use tx.gas_limit as is for new tx type</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>tx</span><span>.</span><span>gas_limit</span><span>,</span><span> blob_gas</span><span>,</span><span> calldata_gas</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Partition old tx.gas_limit into its execution and calldata components.</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>tx</span><span>.</span><span>gas_limit</span><span class="z-keyword"> &gt;=</span><span> calldata_gas</span><span>)</span><span> </span></span> <span class="giallo-l"><span> execution_gas</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas_limit</span><span class="z-keyword"> -</span><span> calldata_gas</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>execution_gas</span><span>,</span><span> blob_gas</span><span>,</span><span> calldata_gas</span><span>]</span></span></code></pre> <p>The calculation for the <em>required</em> <code>max_fee</code> to process the transaction is done in a separate function for easy future expansion:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_required_max_fee</span><span>(</span><span class="z-variable z-parameter z-function">base_fees</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> tx_gas_limits</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> sum</span><span>(</span><span>vector_mul</span><span>(</span><span>base_fees</span><span>,</span><span> tx_gas_limits</span><span>)</span><span>)</span></span></code></pre> <p><strong>At the start of processing a block</strong>:</p> <ul> <li>initialize a vector <code>gas_used_so_far</code> to <code>[0, 0, 0]</code>,</li> <li>derive the base fee <code>base_fees = get_block_base_fees(block.parent)</code>.</li> </ul> <p><strong>At the start of processing a transaction</strong>:</p> <ul> <li>Derive basic properties of the tx: <ul> <li><code>max_fee = get_max_fee(tx)</code>,</li> <li><code>tx_gas_limits = get_gas_limits(tx)</code>.</li> <li><code>max_base = get_required_max_fee(base_fees, tx_gas_limits)</code></li> </ul> </li> <li>Require that <ul> <li><code>all_less_or_equal(vector_add(gas_used_so_far, tx_gas_limits), gas_limits)</code>. The block's <code>gas_limits</code> are defined in the next subsection.</li> <li><code>max_base &lt;= max_fee</code></li> </ul> </li> <li>Compute the fees to deduct initially: <ul> <li><code>max_priority_fee = get_priority_fee(tx, tx_gas_limits, base_fees, max_fee - max_base)</code></li> <li><code>fee_to_deduct = max_base + max_priority_fee</code></li> </ul> </li> <li>Deduct <code>fee_to_deduct</code> wei from the sender, which we define as the address recovered from the transaction’s signature.</li> </ul> <p><strong>At the end of processing a transaction</strong>:</p> <ul> <li>Compute <code>tx_gas_consumed</code> as a three-item vector, where the first item is the amount of execution gas actually consumed, and the second and third items are the blob and calldata gas amounts, which are equal to their limits from <code>tx_gas_limits</code>.</li> <li>Burn <code>base_fee_paid = sum(vector_mul(base_fees, tx_gas_consumed))</code>.</li> <li>Transfer to the coinbase <code>priority_fee_paid = get_priority_fee(tx, tx_gas_consumed, base_fees, fee_to_deduct - base_fee_paid)</code></li> <li>Refund the sender <code>fee_to_deduct - base_fee_paid - priority_fee_paid</code>.</li> <li>Update <code>gas_used_so_far = vector_add(gas_used_so_far, tx_gas_consumed)</code>.</li> </ul> <p><strong>At the end of processing a block</strong>:</p> <ul> <li>Require each element of <code>block.gas_used</code> (a vector field in the header) to equal the corresponding element in <code>gas_used_so_far</code>.</li> </ul> <h3 id="block-structure">Block structure</h3> <p>The <code>BlockHeader</code> is updated to remove the <code>blob_gas_used</code>, <code>gas_used</code>, <code>base_fee_per_gas</code>, <code>gas_limit</code> and <code>excess_blob_gas</code> fields, and the following new fields are added, all of the <code>[int, int, int]</code> type: <code>gas_limits</code>, <code>gas_used</code>, <code>excess_gas</code>. The header sequence of the new fields is <code>[..., withdrawals_root, gas_limits, gas_used, excess_gas]</code>.</p> <p>We define the <code>gas_limits</code></p> <ul> <li><code>gas_limits[0]</code> follows the existing adjustment formula based on the parent <code>gas_limits[0]</code>.</li> <li><code>gas_limits[1]</code> must equal <code>blobSchedule.max * GAS_PER_BLOB</code></li> <li><code>gas_limits[2]</code> must equal <code>gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO</code>.</li> </ul> <p>and the <code>gas_targets</code></p> <ul> <li><code>gas_targets[0]</code> must equal <code>gas_limits[0] // EVM_LIMIT_TARGET_RATIO</code>.</li> <li><code>gas_targets[1]</code> must equal <code>blobSchedule.target * GAS_PER_BLOB</code>.</li> <li><code>gas_targets[2]</code> must equal <code>gas_limits[2] // CALLDATA_LIMIT_TARGET_RATIO</code>.</li> </ul> <p>The blobSchedule for referencing target and max blobs was introduced in <a href="https://wg-eips.ritovision.com/7840/">EIP-7840</a>.</p> <h3 id="gas-accounting">Gas accounting</h3> <p>We incorporate EIP-7918 to establish a dynamic reserve price for blob and calldata gas. When the market price for a resource drops below its reserve price, the mechanism for reducing its <code>excess_gas</code> (and thus lowering its base fee) is disabled. This leads the base fee to rise with usage until it meets the reserve price.</p> <p>We normalize the running excess gas so that all resources operate at the same scale with the same <code>BASE_FEE_UPDATE_FRACTION</code>, which also provides a smoother response when any limit is adjusted. Division by <code>gas_limits[i]</code> upholds the same price changes stipulated in EIP-4844 and <a href="https://wg-eips.ritovision.com/7691/">EIP-7691</a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> base_fees</span><span class="z-keyword"> =</span><span> get_block_base_fees</span><span>(</span><span>parent</span><span>)</span></span> <span class="giallo-l"><span> limits</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>gas_limits</span></span> <span class="giallo-l"><span> targets</span><span class="z-keyword"> =</span><span> get_block_gas_targets</span><span>(</span><span>parent</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-support">len</span><span>(</span><span>parent</span><span>.</span><span>excess_gas</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-constant">GAS_RESERVE_FACTOR</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> base_fees</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_RESERVE_FACTOR</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> &lt;</span><span> base_fees</span><span>[</span><span class="z-constant">GAS_RESERVE_INDEX</span><span>[</span><span>i</span><span>]</span><span>]</span><span>)</span><span>:</span><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-7918 path. Excess gas rises with usage (up to limit), but cannot fall.</span></span> <span class="giallo-l"><span> delta</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>gas_used</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> *</span><span> (</span><span>limits</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> -</span><span> targets</span><span>[</span><span>i</span><span>]</span><span>)</span><span class="z-keyword"> //</span><span> limits</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>excess_gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> +</span><span> delta</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_NORMALIZATION_FACTOR</span><span class="z-keyword"> //</span><span> limits</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Regular path. Excess gas rises and falls with usage as normal</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>gas_used</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> &gt;=</span><span> targets</span><span>[</span><span>i</span><span>]</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Add</span></span> <span class="giallo-l"><span> delta</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>gas_used</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> -</span><span> targets</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>excess_gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> +</span><span> delta</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_NORMALIZATION_FACTOR</span><span class="z-keyword"> //</span><span> limits</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ..or subtract</span></span> <span class="giallo-l"><span> delta</span><span class="z-keyword"> =</span><span> targets</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>gas_used</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span> deltan</span><span class="z-keyword"> =</span><span> delta</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_NORMALIZATION_FACTOR</span><span class="z-keyword"> //</span><span> limits</span><span>[</span><span>i</span><span>]</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>excess_gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> &lt;</span><span> deltan</span><span class="z-keyword"> else</span><span> parent</span><span>.</span><span>excess_gas</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> -</span><span> deltan</span></span> <span class="giallo-l"><span> new_excess</span><span>.</span><span>append</span><span>(</span><span>excess</span><span>)</span><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> new_excess</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_block_base_fees</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span></span> <span class="giallo-l"><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_BASE_FEE_PER_GAS</span><span>,</span></span> <span class="giallo-l"><span> excess</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> BASE_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> excess</span><span class="z-keyword"> in</span><span> parent</span><span>.</span><span>excess_gas</span></span> <span class="giallo-l"><span> ]</span></span></code></pre><h3 id="calldatabasefee-instruction">CALLDATABASEFEE instruction</h3> <p>We add a <code>CALLDATABASEFEE (0x4b)</code> instruction that returns the calldata base fee of the current block, following the same principles as specified in <a href="https://wg-eips.ritovision.com/7516/">EIP-7516</a> for the blob base fee.</p> <table><thead><tr><th>Op</th><th>Input</th><th>Output</th><th>Cost</th></tr></thead><tbody> <tr><td>0x4b</td><td>0</td><td>1</td><td>2</td></tr> </tbody></table> <h3 id="censorship-resistance">Censorship resistance</h3> <p>In EIP-7805, <em>includers</em> propose inclusion-list (IL) transactions that the block builder must include, subject to rules evaluated post-execution once remaining capacity is known. We define three resource types based on these rules:</p> <ul> <li><em>Conditional resource</em> – An IL transaction consuming this resource <em>must be included</em> if the block has sufficient remaining capacity. If such a transaction is excluded, the block should not be accepted, unless the available space (<code>gas_limit[i] - gas_used[i]</code>) for at least one of its required conditional resources was insufficient to fit the transaction.</li> <li><em>Unconditional resource</em> – An IL transaction consuming this resource <em>must be included</em> as long as sufficient capacity remains for all <em>conditional</em> resources it also uses. A lack of available capacity in the unconditional resource itself is <em>not</em> a valid reason for exclusion.</li> <li><em>Deconditional resource</em> – An IL transaction consuming this resource <em>can always be excluded</em>, regardless of available capacity. For this reason, there is no incentive for includers to list such a transaction.</li> </ul> <p>If EIP-7805 is implemented, it must: (i) continue to treat EVM gas as a conditional resource; (ii) continue to treat blob gas as a deconditional resource; (iii) treat calldata gas as an unconditional resource. Any transaction listed in an IL that consumes calldata and is excluded from the block, despite there being sufficient capacity in all conditional resources it uses, MUST produce an <code>INVALID_INCLUSION_LIST</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-go-multidimensional">Why go multidimensional?</h3> <p>Many Ethereum resources such as blobs, calldata, access, and compute are in limited supply each block, constrained by the need to, e.g., timely propagate data or run computations. Upholding the constraints on all these resources via a single meta-resource—"gas"—limits developers' ability to control both supply <em>and</em> demand. By going multidimensional, developers gain a more fine-grained control over the supply of each resource, preventing one from encroaching on the allotment for another. Resources can then be consumed at maximum capacity within each specified target and limit. With separate base fees for each resource, the market can come to an agreement on the appropriate price that leads to consumption at maximum capacity, given a specific user demand and aforementioned constraints on its supply. A multidimensional fee market is thus inherently a tool for scaling Ethereum.</p> <h3 id="user-experience">User experience</h3> <p>Ethereum currently uses <code>max_fee_per_gas</code> for EVM gas and <code>max_fee_per_blob_gas</code> for blob gas. A direct expansion of this approach is proposed in EIP-7706, with a vector of fees per gas for each resource. This may be considered unfortunate from a UX perspective, given that the vector will expand with expanding dimensionality. Our casual users tend to be moderately confused already by a single <code>max_fee_per_gas</code>. Most do not primarily think in terms of the individual prices for the resources that the transaction will consume. They think in terms of how much ETH they need to pay for their transactions (or in terms of dollars/fiat). A unified <code>max_fee</code> is in this context an improvement to UX. A unified <code>max_fee_per_gas</code> is possible, but might cause confusion in that the required gas price will differ from the base fees when using several resources—and thus also differ between transactions using different proportions of the resources.</p> <p>When it comes to the priority fee, the optimal UX between using <code>max_priority_fee</code> and <code>max_priority_fee_per_gas</code> is a bit more nuanced. We decided to use <code>max_priority_fee_per_gas</code>. Ethereum already today unifies the priority fee for blob gas and regular gas under a single <code>max_priority_fee_per_gas</code>. It is thus natural to retain this representation, if only for removing friction for wallets. Furthermore, the priority fee should be determined from actual gas usage and not the gas limit. This is however perfectly possible when using <code>max_priority_fee</code> as well, because the max priority fee can be treated as proportional to the limit during processing, thus falling if less gas is consumed.</p> <p>Retaining <code>max_priority_fee_per_gas</code> can be considered slightly safer for users, in that they will never risk manually submitting a <code>max_priority_fee</code> for an old transaction type. Advanced users may wish to specify one priority fee per resource, to granularly pay according to usage when consuming below the gas limit. This ability was therefore preserved as an optional vector-based priority fee.</p> <h3 id="economic-efficiency">Economic efficiency</h3> <p>Besides UX, resource-specific fee limits can also be unfortunate at a deeper economic level. Once a user has specified a <code>gas_limit</code> for any non-deterministic dimension, potentially with the assistance of their wallets, multiple separate <code>max_fee_per_gas</code> could exclude transactions that specify a sufficient aggregate fee, due to a drift in relative levels of the base fees.</p> <p>Consider a multidimensional transaction with a <code>gas_limit</code> vector $\mathbf{l} = (l_1, l_2,\dots, l_n)$, a <code>max_fee_per_gas</code> vector $\mathbf{f} = (f_1, f_2, \dots, f_n)$, and a <code>max_priority_fee_per_gas</code> vector $\mathbf{p} = (p_1, p_2, \dots, p_n)$. The consumed gas of the transaction is denoted $\mathbf{g} = (g_1, g_2, \dots, g_n)$, and the vector of base fees is denoted $\mathbf{b} = (b_1, b_2, \dots, b_n)$. The realized priority fee, after ensuring a sufficient base fee, is then</p> <p>$p{\prime}_i = \min(p_i, f_i-b_i)$</p> <p>for all resources $i$. Assume that when the transaction is submitted, the user specifies a <code>max_fee_per_gas</code> vector $\mathbf{f}$ such that all entries individually satisfy all base fee $\mathbf{b}$ criteria</p> <p>$f_i \ge b_i \quad \text{for all resources } i.$</p> <p>The gas limits also satisfy the actual gas consumption</p> <p>$l_i \ge g_i \quad \text{for all resources } i.$</p> <p>The <code>max_priority_fee_per_gas</code> vector $\mathbf{p}$ is also considered sufficient by many proposers, when they jointly weigh the reward against competing transactions using a weight vector $\mathbf{w}$, considering contention across relevant resources:</p> <p>$\sum p{\prime}_i g_i \ge \sum w_i g_i.$</p> <p>While not evaluated in the existing EIP, the base fees $\mathbf{b}$ could also be satisfied in aggregate against the max fees:</p> <p>$\sum f_i l_i \ge \sum b_i l_i.$</p> <p>Now assume that the base fee for any of the resources rapidly rises before the transaction is included, such that it becomes higher than the <code>max_fee_per_gas</code> in that dimension. In this scenario, the transaction can no longer be included. This may happen, even though the <em>aggregate</em> fees that the user is offering to pay, $\sum f_i l_i$, remain at a level above the aggregate fees that the protocol demands to execute it, $\sum b_i l_i$, just as initially. The aggregate priority fees may still also satisfy the proposer. The welfare loss consists of a user, a proposer, and a protocol willing to process a transaction, hamstrung by rigidity in the protocol design.</p> <p>The analysis leads to the following conclusions, all of which apply with increasing emphasis the higher the dimensionality:</p> <ol> <li>The UX would be simplified by one aggregate ETH fee.</li> <li>The protocol would be best served by taking a single aggregate ETH fee from the user.</li> <li>The proposer already considers the aggregate impact when making its inclusion decision.</li> </ol> <p>Thus, the proposal is that the user specifies a single ETH <code>max_fee</code>. The protocol first ensures that the <code>max_fee</code> $F$ covers the base fee across gas limits in all dimensions, $F &gt; \sum b_i l_i$, and finally charges the minimum aggregate fee possible. The total fee paid to the protocol is thus the same as in the original multidimensional fee market design. The design is future-proof in that additional dimensions easily are incorporated, retaining the single <code>max_fee</code>.</p> <h3 id="priority-fee">Priority fee</h3> <p>Considerations for the priority fee were already outlined in the UX section. Here, we first expand on why a vector <code>max_priority_fee_per_gas</code> <em>can</em> be beneficial to some users for fine-grained control, but not to most. The user has full control over the priority fee with a single input, as long as gas usage is deterministic across all resources. This input can be either <code>max_priority_fee</code> or <code>max_priority_fee_per_gas</code>—they are equivalent under deterministic gas usage. They are furthermore equivalent under any circumstances if the protocol makes sure to scale the <code>max_priority_fee</code> according to realized gas usage <em>relative</em> to the specified limit. Otherwise, the <code>max_priority_fee</code> will not be reduced when a transaction uses less gas than the limit (this is more often a drawback than a benefit for the user).</p> <p>The priority fee a user wishes to provide per gas for a resource depends on the (likelihood of) contention across this resource. We can thus expect it to differ between resources. It follows from the principle of degrees of freedom that to gain full control over the transaction's priority fee, a user needs a separate parameter for each independent variable. When gas usage is non-deterministic in one resource—as today—the user needs two priority fees to achieve full granularity. When gas usage is non-deterministic in two resources (and their non-deterministic usage is not perfectly correlated), the user needs three priority fees, etc.</p> <p>It should here be noted that the required priority fee per gas for some resource cannot be directly ascertained from the priority fee per gas that has been stipulated for that resource in recent transactions. Assume that there are 10 resource and each transaction includes a vector stipulating <code>max_priority_fee_per_gas</code> for each. The builder will in its inclusion decision operate on the aggregate, and its requirements across dimensions can thus only be inferred, not observed directly. This means that per-resource estimates of required priority fees are not trivial, and most may still prefer the simplicity of a single one.</p> <h3 id="unified-gas-accounting-normalization-and-reserve-pricing-mechanism">Unified gas accounting, normalization, and reserve pricing mechanism</h3> <p>Ethereum currently uses two separate fee mechanisms, one for execution gas (EIP-1559) and one for blob gas (EIP-4844). This EIP unifies these mechanisms under the EIP-4844 standard, similar to EIP-7706 but with a few additions. We normalize the excess gas delta by dividing by the gas limit in <code>calc_excess_gas</code>, thus enabling all resources to operate under the same <code>BASE_FEE_UPDATE_FRACTION</code> while also keeping each fee fixed during a hard fork whenever a limit changes.</p> <p>The reserve pricing mechanism from EIP-7918 is also generalized such that it can be applied to any resource, using another resource as an anchor. The mechanism imposes that if the base fee multiplied by <code>GAS_RESERVE_FACTOR</code> is less than the anchor base fee, the base fee cannot fall any further. Calldata uses blob data as an anchor to ensure that we do not charge less for calldata than blob data (see the separate section on the calldata resource for further details).</p> <h3 id="wallet-fee-estimation-logic">Wallet fee estimation logic</h3> <p>To suggest a <code>max_fee</code>, the wallet first simulates the transaction to obtain an estimate of the required limit(s) $\mathbf{l}$. It then queries the network for the current vector of base fees $\mathbf{b}$. The expected total fee is $\sum b_i l_i$. The wallet recommends a <code>max_fee</code> that consists of this expected total cost plus a single buffer to account for aggregate volatility in base fees before the transaction is included. To suggest a <code>max_priority_fee_per_gas</code>, the wallet analyzes recent blocks to determine the priority fees that ensure timely inclusion. It focuses on priority fees paid by recently included transactions consuming a similar distribution of resources, as well as overall network contention.</p> <h3 id="block-building">Block building</h3> <p>Historical data show that around 90% of blocks are below the gas limit. It is only when blocks are full that the builder is constrained in its block construction (disregarding timing games). Furthermore, a multidimensional knapsack problem only manifests in the event that a block is simultaneously full in multiple dimensions. Ignoring blobs, this is expected to be rare with the proposal, since calldata is assigned a limit four times above the target, which is already set higher than current consumption. The calldata limit is thus unlikely to be reached frequently. The blob dimension is a special case, in that this dimension already exists today, and the number of blob-carrying transactions is fairly low. Generally, the impact on revenue from sophisticated packing algorithms will likely be dwarfed by more significant MEV factors such as transaction ordering and private order flow.</p> <h3 id="the-calldata-resource">The calldata resource</h3> <h4 id="byte-sizes">Byte sizes</h4> <p>Calldata is separated into its own resource. With the proposed constants, at 60M execution gas, each block will on average contain <code>60M/(CALLDATA_GAS_LIMIT_RATIO * CALLDATA_LIMIT_TARGET_RATIO) = 3.75M</code> gas of calldata. Focusing on non-zero bytes that cannot be Snappy-compressed, this gas corresponds to around <code>3.75M/16 = 234kB</code>. The average block size has been around <code>90kB</code> at a 36M gas limit, which would expand to <code>150kB</code> at a 60M gas limit if the proportion of calldata in the block remains the same. Using basic assumptions, this proposal thus increases the amount of calldata that will be consumed by over 50%, from <code>150kB</code> to <code>234kB</code> at 60M gas. As pointed out in EIP-7706, this will serve to decrease the cost of calldata for our users.</p> <p>The limit is <code>60M/CALLDATA_GAS_LIMIT_RATIO = 15M</code> gas of calldata, corresponding to around <code>15M/16 = 938kB</code>. This is well below the limit under the current specification incorporating EIP‑7623, which is <code>60M/40 = 1.5MB</code> at 60M gas. Since calldata gas is also no longer accounted for as execution gas, the implied "aggregate" gas limit expands to <code>75M</code> gas, without materially affecting the maximum workload in terms of execution. In conclusion, the separation of calldata into its own resource increases calldata throughput while reducing costs. It furthermore facilitates scaling by allowing for faster payload propagation in the worst case and keeping all EVM gas available for other operations.</p> <h4 id="censorship-resistance-1">Censorship resistance</h4> <p>For censorship resistance (CR) purposes, under the currently proposed CR implementation EIP-7805, builders must include all transactions surfaced in any of the <code>16</code> inclusion lists (ILs) of each slot (each up to <code>8KiB</code>). However, if the block is full, builders can ignore the ILs, to not incentivize them to influence includers for MEV purposes.</p> <p>When resources have separate limits, the block is treated as "full" already when any single conditional resource reaches its limit. Transactions that use that resource can then be excluded, even if they were surfaced by an IL. This makes it potentially cheaper to "stuff the block" to censor transactions. Specifically, a builder can create dummy transactions consuming a single resource to fill that dimension, ensuring that the block is treated as "full" when evaluating IL transactions. When resources have separate base fees, the builder may target a resource with a lower base fee, at a cost of roughly $b_i \cdot \Delta g_i$, where $\Delta g_i$ is the additional gas in resource $i$ required to reach its limit.</p> <p>The good news is that calldata has properties allowing the builder to extract MEV while at the same time unconditionally adhering to its gas limit under EIP-7805. This means that this EIP does not impede censorship resistance. Specifically, in the case where all ILs are filled with disjoint transactions, the aggregate size of included transactions can still be at most <code>8KiB*16 = 131kB</code>. This leaves at the very minimum <code>938kB - 131kB = 807kB</code> of calldata for the builder to use as it sees fit when extracting MEV, which is sufficient according to the usage patterns we know.</p> <p>Accordingly, calldata is treated as an "unconditional" resource, as defined in the specification. An includer MUST therefore signal <code>INVALID_INCLUSION_LIST</code> if—and only if—a calldata‑using IL transaction is omitted despite sufficient capacity remaining in all conditional resources it uses. When considering expansion into further resources with tighter conditional limits, it may be necessary to adopt a version of FOCIL with ranked transactions (FOCILR).</p> <h4 id="reserve-price">Reserve price</h4> <p>An EIP-7918 reserve price is used for calldata just as for blobs. This ensures that the equilibrium price does not fall to levels where the fee market update mechanism stops working satisfactorily. Furthermore, the expiry window for blobs is much shorter than the planned rolling expiry window for calldata, making a modest relative reserve price motivated from a resource preservation perspective. Finally, without a reserve price on calldata, it could become cheaper than blob data (particularly below the blob reserve price), and thus a rational choice for L2s.</p> <p>The latter rationale also motivates the specific parameterization chosen. The EIP-7918 reserve price per byte for calldata is set 1/3 above the price per byte for blob data. This is achieved by tying the EIP-7918 if clause to the <em>blob base fee</em>. The gas per byte is 16 for calldata and 1 for blob data, and the price floor is triggered when <code>base_fees[1] &gt; GAS_RESERVE_FACTOR[2] * base_fees[2]</code>. Given <code>GAS_RESERVE_FACTOR[2] = 12</code>, the EIP-7918 condition activates when the blob base fee is more than <code>12</code> times higher than the calldata base fee, at which point calldata costs less than <code>16/12 = 1+1/3</code> of the blob price per byte. The calldata base fee is then imposed to not fall further.</p> <h4 id="relationship-to-previous-eips-and-other-resources">Relationship to previous EIPs and other resources</h4> <p>We acknowledge that calldata already has been limited by EIP-7623, with further repricings proposed in <a href="https://wg-eips.ritovision.com/7976/">EIP-7976</a>. These EIPs limit worst-case block sizes by metering and conditionally pricing calldata at the transaction level as opposed to at the block level, having the calldata price vary with a transaction's execution usage. This may lead to secondary markets if users wish to combine different transactions to take advantage of the "rebate" on calldata when consumed together with EVM gas. Treating calldata as a separate resource with a price based on block usage would allow for a more precise control over usage, and transactors would not need to interact with a secondary market to achieve the best price.</p> <p>Given that the EIP-7623 design already achieves calldata moderation, it must be remembered that an individual fee market for calldata would merely be a first step toward a multidimensional fee market. Calldata is not an endgame. It is likely best to transition over several hard forks, and the options available at the present must then be considered, which leads to a focus on calldata. Another present consideration is block level access lists (BALs) and their interaction.</p> <p>A resource such as state is more attractive to separate than calldata. We could achieve exact control over state growth, while allowing temporary spikes many times above current gas limits. However, an expansion into other resources requires a multidimensional gas repricing, which has currently not yet been completed. The next section will further discuss remaining complexities of multidimensional EVM gas, and the strategies available for overcoming them.</p> <h3 id="expansion-paths-for-multiple-evm-resources">Expansion paths for multiple EVM resources</h3> <p>This EIP has been designed to facilitate a future expansion into multiple EVM resources. We conclude by outlining the challenges inherent to such an expansion, and the different paths that it can take.</p> <h4 id="evm-without-gas-observability">EVM without gas observability</h4> <p>One long-term vision for the EVM is to move away from gas observability. This is one of the features of EOF (<a href="https://wg-eips.ritovision.com/7692/">EIP-7692</a>), e.g., through revamped <code>CALL</code> instructions in <a href="https://wg-eips.ritovision.com/7069/">EIP-7069</a> such as <code>EXTCALL</code>. The new calls no longer accept a gas stipend as an input parameter, and the EVM instead makes available some reasonable fraction of all gas across dimensions (e.g., 63/64). Legitimate use cases previously handled via gas observability are then instead taken over by, e.g., the <code>PAY</code> opcode <a href="https://wg-eips.ritovision.com/5920/">EIP-5920</a>.</p> <p>For compatibility with legacy code, the EVM can in this scenario reinterpret legacy subcalls with a gas parameter by forwarding the same fraction of the caller’s remaining budget in each resource dimension. Concretely, if the call stipulates $g_c$ and the aggregate remaining EVM-gas budget is $g_a$, the callee receives, for each EVM resource with remaining budget $g_r$, the amount $\bigl\lfloor g_r \cdot \min!\bigl(1,\tfrac{g_c}{g_a}\bigr) \bigr\rfloor$. For completeness, the <code>GAS</code> opcode could likewise return, e.g., $g_a$ (the per-call aggregate remaining budget at this point across all resource dimensions). Note, however, that reinterpreting legacy calls and <code>GAS</code> in this way can still change the behavior of contracts that rely on precise gas observability or gas-capped subcalls, and such contracts may break.</p> <h4 id="evm-that-retains-gas-observability">EVM that retains gas observability</h4> <p>It is possible to expand into multiple EVM resource dimensions without breaking existing contracts that rely on gas observability. By treating gas as <em>fungible across resources</em> (just as today), a single budget can be forwarded and counted toward any resource that consumes it. It should be noted that old contracts may still break due to repricing of the resources they use; indeed, a gas repricing effort is currently underway in Ethereum that likely will cause such breakage. But this may be treated as a separate concern.</p> <h4 id="transaction-types-under-multiple-evm-resources-with-non-deterministic-limits">Transaction types under multiple EVM resources with non-deterministic limits</h4> <p>A key difference between the new and old transaction types is that the old transaction types set only one limit, whereas the new can set several. When adding deterministic resources such as calldata, this is not a concern, because consumption of this resource can be deducted from the user-specified limit as a pre-processing step. But once there is more than one non-deterministic resource—as can be the case when EVM gas is separated into several resources—things get slightly more complicated. If we wish to ensure that old transaction types still can function properly under these circumstances, we must apply the single limit to multiple non-deterministic resources. The following subsections will outline how this can be achieved by aggregating the gas of these separate resources during EVM processing.</p> <p>The new transaction type can supply several limits, making expansion into multiple EVM resources more straightforward. However, it turns out that we may also wish to retain the ability of the new transaction type to set a single limit for EVM gas. The reason is that the single limit and aggregate processing facilitates backward compatibility for contracts that rely on gas observability. As previously noted, these contracts must be able to supply subcalls with an aggregate gas stipend, to be counted against any EVM resource. Furthermore, there is an inherent simplicity of the single limit that is not to be discounted.</p> <p>In all considered approaches below, the number of non-deterministic EVM resources still increases at the <em>block level</em>. To retain the ability to reject a transaction that may require more gas for a resource than its associated block limit, it becomes necessary to alter the check on <code>gas_used_so_far</code>. Specifically, when a transaction stipulates only the main EVM gas limit, then this limit must be conservatively counted toward all underspecified dimensions of <code>gas_used_so_far</code> before the limit check:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span class="z-support"> len</span><span>(</span><span>tx_gas_limits</span><span>)</span><span class="z-keyword"> ==</span><span class="z-support"> len</span><span>(</span><span>gas_used_so_far</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Same check as previously</span></span> <span class="giallo-l"><span> all_less_or_equal</span><span>(</span><span>vector_add</span><span>(</span><span>gas_used_so_far</span><span>,</span><span> tx_gas_limits</span><span>)</span><span>,</span><span> gas_limits</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The joint EVM gas limit is expanded to cover all block resources</span></span> <span class="giallo-l"><span> tx_gas_limits_exp</span><span class="z-keyword"> =</span><span> [</span><span>tx_gas_limits</span><span>[</span><span class="z-constant">0</span><span>]</span><span>]</span><span class="z-keyword"> *</span><span class="z-support"> len</span><span>(</span><span>gas_limits</span><span>)</span></span> <span class="giallo-l"><span> tx_gas_limits_exp</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span> tx_gas_limits_exp</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-keyword"> =</span><span> tx_gas_limits</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span> tx_gas_limits</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"><span> all_less_or_equal</span><span>(</span><span>vector_add</span><span>(</span><span>gas_used_so_far</span><span>,</span><span> tx_gas_limits_exp</span><span>)</span><span>,</span><span> gas_limits</span><span>)</span></span></code></pre><h4 id="multidimensional-gas-metering">Multidimensional gas metering</h4> <p>An existing proposal by Inês Silva and Crapis is <em>Multidimensional gas metering</em> (not yet submitted as an EIP), which prices gas in one dimension, but applies limits at the block level across several dimensions when updating the (single) EVM base fee. The EVM will thus track multidimensional gas consumption, but perform the limit check on the aggregate, which is also passed on in subcalls. The proposed EIP could be combined with Multidimensional gas metering, for example by using a single EVM gas and calculating metered block gas usage separately, before submitting the outcome as a single resource dimension to the revamped <code>calc_excess_gas()</code>.</p> <h4 id="multidimensional-fee-market-with-aggregate-evm-gas">Multidimensional fee market with aggregate EVM gas</h4> <p>To promote full resource utilization while maintaining backward compatibility for subcalls and old transaction formats, we could instead use <em>separate</em> gas prices for each EVM resource, while retaining within the EVM the ability to <em>aggregate the gas</em> consumption across resources. We refer to this as a <em>Multidimensional fee market with aggregate gas</em>. In the fully aggregated scenario, the user stipulates a single <code>gas_limit</code> for EVM gas, and the protocol must make sure that the <code>max_fee</code> covers the maximum possible fee, from consuming <code>gas_limit</code> of the EVM resource that has the most expensive base fee. Execution is then fully backward compatible, and the EVM operates the same way as with Multidimensional gas metering.</p> <p>The downside is that the user must stipulate an unnecessarily high <code>max_fee</code> allocation, if the most expensive resource is not used. We present three options for alleviating this. The first two options transfer to the block producer the responsibility to ensure that the <code>max_fee</code> indeed covers a transaction's fees determined post-execution. The third option instead enables the transactor to alternatively provide better guarantees in the form of full gas limits.</p> <p><em>Option 1:</em> Invalidate a block when the post-transaction check shows that the total fee for a transaction exceeded <code>max_fee</code>. We could either completely remove the pre-execution check <code>max_fee &gt;= get_required_max_fee(base_fees, tx_gas_limits)</code>, or only check for deterministic resources in addition to EVM gas across the cheapest EVM resource. During processing, there would still be an aggregated check against the transaction's gas limit, which is the sender's responsibility. In extension, the block's gas limit is already safeguarded pre-execution by conservatively counting <code>tx_gas_limits_exp</code> against it, as outlined in the previous subsection.</p> <p>Note that the inclusion guarantees of EIP-7805 will not apply to the transactions where the <code>max_fee</code> does not cover the worst-case pre-execution check. These transactions are to be ignored when validating the block post-execution.</p> <p><em>Option 2:</em> Give the block producer the ability and responsibility to supply any missing funds as part of the post-transaction check. This could potentially rely on staked builders currently envisioned in <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a>, albeit it would be more intuitive to use execution layer balances for this purpose. Another alternative is to charge a block-based base fee at the end of processing a block rather than per transaction, as has been discussed in the past. This naturally extends to a multidimensional setting. Note that (2) reverts to (1) upon failure of the builder to ensure the base fees are covered.</p> <p><em>Option 3:</em> Give the transactor the ability to provide limits for all dimensions, if they so wish. The pre-execution check can then be more fine-grained, inheriting the higher capital efficiency previously outlined. This is a hybrid design, where the transactor can choose the option most suitable to their needs if they use the new transaction type. This option will be discussed in more detail in the next subsection. Note that (3) can be combined with (1) if desirable.</p> <h4 id="multidimensional-fee-market-with-hybrid-evm-gas">Multidimensional fee market with hybrid EVM gas</h4> <p>In a <em>Multidimensional fee market with hybrid EVM gas</em>, the user has separate options:</p> <ol> <li>Provide a single gas limit for the EVM resources. The EVM can then operate as in the aggregate gas model, after the initial restrictive fee allocation check.</li> <li>Provide a gas limit for each EVM resource. Capital efficiency is then preserved. The EVM operates without gas observability as previously outlined, with the gas parameter of old subcalls converted to a multidimensional counterpart. The transaction is during processing checked against its multiple limits, as opposed to the aggregate.</li> </ol> <p>It is further possible to give the user the freedom to stipulate <em>some</em> EVM gas limits, but not all. The user can for example set the gas limit to 0 for any resource it knows that it will not use, instead of not setting a gas limit for that resource. The aggregation then takes place only across resources without an individual stipulated limit, reducing the required <code>max_fee</code> allocation while preserving full/a higher level of backward compatibility. These features come at a cost of somewhat increased complexity.</p> <h4 id="specification-for-aggregate-and-hybrid-evm-gas">Specification for aggregate and hybrid EVM gas</h4> <p>For the hybrid model, the <code>get_gas_limits()</code> function must be updated to alternatively return multiple EVM gas limits, in the case the user stipulates the full list.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_gas_limits</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>type</span><span class="z-keyword"> ==</span><span class="z-constant"> MULTIDIM_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>gas_limit</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>tx</span><span>.</span><span>gas_limit</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> blob_gas</span><span>,</span><span> calldata_gas</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>tx</span><span>.</span><span>gas_limit</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> blob_gas</span><span>,</span><span> calldata_gas</span><span>]</span><span class="z-keyword"> +</span><span> tx</span><span>.</span><span>gas_limit</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>For the aggregate model, the <code>get_required_max_fee()</code> must be updated such that the protocol applies the worst-case EVM base fees across the EVM gas. The new constant <code>EVM_INDICES</code> specifies the EVM resource indices. Note that <code>TX_BASE_COST</code> is treated as a deterministic component of the EVM gas to reduce required capital allocation. Note that even when pursuing Options 1-2 for aggregate gas, the aggregation step is still applied in consideration of EIP-7805.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_required_max_fee</span><span>(</span><span class="z-variable z-parameter z-function">base_fees</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> tx_gas_limits</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Fully specified gas limits, apply baseline pattern</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>base_fees</span><span>)</span><span class="z-keyword"> ==</span><span class="z-support"> len</span><span>(</span><span>tx_gas_limits</span><span>)</span><span>:</span><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> sum</span><span>(</span><span>vector_mul</span><span>(</span><span>base_fees</span><span>,</span><span> tx_gas_limits</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Otherwise: 1. TX_BASE_COST is treated deterministically (assumed resource 0)</span></span> <span class="giallo-l"><span> determ_evm_cost</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-keyword"> *</span><span> base_fees</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>tx_gas_limits</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> TX_BASE_COST</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Limit MUST cover TX_BASE_COST.</span></span> <span class="giallo-l"><span> variable_evm_limit</span><span class="z-keyword"> =</span><span> tx_gas_limits</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> -</span><span class="z-constant"> TX_BASE_COST</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Determine EVM cost based on most expensive resource</span></span> <span class="giallo-l"><span> max_evm_base_fee</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>base_fees</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-constant"> EVM_INDICES</span><span>)</span></span> <span class="giallo-l"><span> evm_cost</span><span class="z-keyword"> =</span><span> determ_evm_cost</span><span class="z-keyword"> +</span><span> variable_evm_limit</span><span class="z-keyword"> *</span><span> max_evm_base_fee</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 3. Return total EVM cost + blob cost + calldata cost</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> evm_cost</span><span class="z-keyword"> +</span><span> base_fees</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword">*</span><span>tx_gas_limits</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> +</span><span> base_fees</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-keyword">*</span><span>tx_gas_limits</span><span>[</span><span class="z-constant">2</span><span>]</span></span></code></pre> <p>For the hybrid model, the line stipulating <code>tip_indices</code> in <code>get_max_priority_fee()</code> must be updated to include all new EVM resources <code>tip_indices = [2] + EVM_INDICES</code>. It is also feasible to adjust the functioning of legacy transactions, to let them tip only according to the headroom between the EVM resource with the highest base fee and the <code>gasprice</code>. The aim would be to prevent them from having to pay an excessive tip when the <code>gasprice</code> was set high merely to cover for the EVM resource with the highest base fee (of which they use little). The tip would then be calculated as the premium above the highest EVM resource base fee.</p> <p>To allow transactors to specify <em>some</em> limits, the <code>tx.gas_limit</code> list must instead have a nested format, where <code>gas_limit[0]</code> is the aggregate limit for unspecified EVM resources, and <code>[index, limit]</code> pairs then follow: <code>tx.gas_limit = [aggregate, [[index, limit], [index, limit],...]]</code>. The protocol then computes the required max fee from resources with both specified and unspecified limits. The maximum base fee among the resources with unspecified limits is in this case multiplied with the aggregate, and this fee is summed together with the fees of specified limits.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The <code>max_fee_per_gas</code> of the EIP-1559 and EIP-4844 transaction types are converted to a <code>max_fee</code> by multiplication with the stipulated gas limit(s). The converted EIP-4844 transactions will no longer adhere to the individual <code>max_fee_per_gas</code> and <code>max_fee_per_blob_gas</code>, but instead to the aggregated <code>max_fee</code>. This is a deliberate choice since previous individual checks have lower economic efficiency to no clear benefit, but it should nevertheless be noted by transactors. The priority fee retains the same functionality as previously. The old <code>gasprice</code> can be used both for the <code>max_fee</code> and <code>max_priority_fee_per_gas</code>. The <code>gas_limit</code> is finally derived deterministically. The section on expansion paths outlined how old transactions can retain functionality as we expand into several non-deterministic EVM resources.</p> <p>Backward compatibility for contracts that rely on gas introspection can be resolved by giving users the ability to rely on aggregated EVM gas, while still potentially pricing EVM resources separately. Wallets must be updated to handle multidimensional gas accounting with several base fees.</p> <h2 id="security-considerations">Security Considerations</h2> <p>One concern is the risk of increasing builder centralization due to increased revenue from sophisticated packing algorithms. While the builder is constrained in its block construction when blocks are full, it is only when several limits are reached at the same time that packing complexity markedly changes from today. Given that around 90% of blocks are below the gas limit, and the calldata limit is set to be very permissive, we argue that this will happen very rarely.</p> <p>One reason for using <code>max_priority_fee_per_gas</code> instead of <code>max_priority_fee</code> is to establish the priority fee as always having a non-aggregate representation. We could possibly otherwise imagine a scenario where a user in the old transaction format manually submits an aggregate <code>max_fee</code> and <code>max_priority_fee</code>, causing loss of funds.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francisco Giordanohttps://github.com/frangio https://wg-eips.ritovision.com/7997/

A minimal `CREATE2` factory shared by EVM chains.

<h2 id="abstract">Abstract</h2> <p>A minimal <code>CREATE2</code> factory is inserted as a system contract in the precompile range, to enable deterministic deployments at identical addresses across EVM chains. This benefits developer experience, user experience, and security, in particular for multi-chain and cross-chain applications, including account abstraction.</p> <h2 id="motivation">Motivation</h2> <p>There are now a large number of EVM chains where users want to transact and developers want to deploy applications, and we can expect this number to continue to grow in line with Ethereum's rollup-centric roadmap and the general adoption of programmable blockchains.</p> <p>Most applications support multiple chains and aspire to support as many as possible, and their developers widely prefer to deploy contracts at identical addresses across all chains, a setup which we will call <em>multi-chain deterministic deployment</em>.</p> <p>This kind of deployment reduces the number of addresses that must be distributed to use the application, so that it no longer scales with the number of supported chains. This simplification has many benefits throughout the stack: interfaces and SDKs need to embed and trust fewer addresses, and other contracts that depend on them can be implemented without chain-specific customization (which in turn makes them amenable to multi-chain deployment).</p> <p>This kind of deployment is also highly desirable and important for account abstraction. Without it, a user's smart contract accounts are deployed at different addresses on different chains, and each account is tied to a single chain. This limitation is difficult to explain to users and has caused loss of funds. If smart contract accounts cannot be multi-chain like EOAs, they offer downgraded UX and are more prone to error.</p> <p>There is currently no native or fully robust way to perform multi-chain deterministic deployments. While <code>CREATE2</code> enables deterministic deployments, the created address is computed from that of the contract that invokes the instruction, so a <em>factory</em> that is itself multi-chain is required for bootstrapping. Four workarounds are currently known to deploy such a factory, each with their own issues:</p> <ol> <li>A keyless transaction is crafted using Nick's method that can be posted permissionlessly to new chains. For this to work, the chain must support legacy transactions without <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> replay protection, and the fixed gas price and gas limit must be sufficiently high, but not so high as to exceed the limits of the chain.</li> <li>Private keys held by some party are used to sign creation transactions for each chain as needed. This creates a dependency on that party, does not provide a hard guarantee that the factory will be available on every chain, and can also irreversibly fail if transactions are not properly parameterized.</li> <li>A private key is intentionally leaked so that any party can permissionlessly create an <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> signed delegation and deploy a factory from the leaked account. While this approach improves on the previous two, its reliance on ECDSA keys makes it non-quantum-resistant, and will fail once chains stop supporting ECDSA keys. Additionally, it requires EIP-7702, an orthogonal feature which is not guaranteed to spread to all chains; for example, those chains that tackle account abstraction through other means have no use for it, and arguably weaker ecosystem pressure to implement it (compared to other EIPs) given that it is a feature not directly used by applications (which instead access AA capabilities through an abstraction like <a href="https://wg-eips.ritovision.com/5792/">EIP-5792</a>). Lastly, there is a possibility that a future upgrade allows EIP-7702 delegations to become permanent, which breaks this scheme.</li> <li>Factories already deployed on other chains (by any of the previous methods) are inserted in a new chain at genesis or via a hard fork. This has not been widely adopted by chains, despite the standardization efforts of RIP-7740. Since these factories are applications deployed by users through normal means, this kind of hardcoding of accounts may be seen by chain developers as too intrusive.</li> </ol> <p>This EIP aims to coordinate a widely available multi-chain <code>CREATE2</code> factory without the above downsides by placing a factory in the precompile range.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <ul> <li><code>FACTORY_ADDRESS</code> = <code>0x12</code></li> </ul> <h3 id="factory-contract">Factory Contract</h3> <p>Upon activation of this EIP, the account at <code>FACTORY_ADDRESS</code> becomes a contract that, when called, invokes the <code>CREATE2</code> instruction (<a href="https://wg-eips.ritovision.com/1014/">EIP-1014</a>) with a salt equal to the first 32 bytes of the call's input data, init code equal to the remaining data, and value equal to the call's value. If input data is smaller than 32 bytes, the call reverts with empty return data. If creation fails (<code>CREATE2</code> outputs <code>0</code>), the call reverts with return data equal to that of the creation frame.</p> <p>Specifically, the code of <code>FACTORY_ADDRESS</code> is set to <code>60203610602f5760003560203603806020600037600034f5806026573d600060003e3d6000fd5b60005260206000f35b60006000fd</code>. This code implements the specification above and corresponds to the following assembly:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>#pragma target &quot;constantinople&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Input: salt (32 bytes) || initcode (variable size)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Verify input is at least 32 bytes long.</span></span> <span class="giallo-l"><span>push 32</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>lt</span></span> <span class="giallo-l"><span>jumpi @throw</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Load salt.</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Compute initcodesize = calldatasize - 32.</span></span> <span class="giallo-l"><span>push 32</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>sub</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Copy initcode to memory at position 0.</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push 32</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>calldatacopy</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Invoke create2 with salt and initcode, forwarding all callvalue.</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span>create2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Check if create2 produced nonzero.</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push @success</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; Fallthrough if zero, and revert with identical returndata.</span></span> <span class="giallo-l"><span>returndatasize</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>returndatacopy</span></span> <span class="giallo-l"><span>returndatasize</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>revert</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>;; On success, return the created address.</span></span> <span class="giallo-l"><span>success:</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push 32</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>throw:</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>push 0</span></span> <span class="giallo-l"><span>revert</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="precompile-range-system-contract">Precompile-range system contract</h3> <p>Unlike previous system contracts, this factory cannot be deployed using a normal transaction because, as explained in the Motivation section, that transaction could not be guaranteed to be valid on other chains. Since the purpose of this factory is to be available in all EVM chains that a contract could be deployed to, an irregular insertion of the code into a special address seems necessary.</p> <p>The address <code>0x12</code> (<code>0x0000000000000000000000000000000000000012</code>) is chosen as the next lowest address after currently accepted precompiles, on the assumption that other EVM chains would have reserved this range for future Ethereum precompiles.</p> <h3 id="input-validation">Input validation</h3> <p>The factory reverts if the input is smaller than 32 bytes, the minimum size that contains the salt, to provide an explicit error when the factory is not correctly invoked.</p> <h3 id="no-frontrunning-protection">No frontrunning protection</h3> <p>As explained in the Security Considerations, deployments using this factory can potentially be frontrun.</p> <p>A different factory could avoid this issue if it invokes <code>CREATE2</code> with a salt computed from the caller address in combination with the caller-provided salt input. This prevents frontrunning, but makes deployments permissioned to a deployer account, without the ability to recover permissionless deployments across chains because of the bootstrapping problem this EIP is itself meant to solve.</p> <p>A factory could also support both permissioned and permissionless deployments by making the mechanism opt-in. However, the addition of this complexity to an otherwise very simple contract was deemed unnecessary, since once the bootstrapping problem is solved, further factories with a more comprehensive set of features and security measures can be deterministically deployed across chains. We expect this to be the case.</p> <h3 id="not-a-new-transaction-type">Not a new transaction type</h3> <p>An alternative approach would consist of a new creation transaction type where the address of the created contract is computed in a way independent of the transaction origin. A system contract was considered a simpler approach that will be more robust to changes in the base layer in the future or across chains.</p> <h3 id="constantinople-target-avoidance-of-push0">Constantinople target, avoidance of <code>PUSH0</code></h3> <p>The system contract is written to avoid the use of newer opcodes such as <code>PUSH0</code> to make it viable to be adopted by chains that don't yet support them, decoupling the decision to adopt this EIP from that of adopting other EIPs.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>FACTORY_ADDRESS</code> must not be used by other precompiles or predeploys upon activation of this EIP on a chain. The constant must be chosen to minimize likelihood that this happens.</p> <h2 id="test-cases">Test Cases</h2> <!-- TODO --> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="frontrunnable-deployments">Frontrunnable deployments</h3> <p>The deployment of contracts that read the environment (<code>ORIGIN</code>, <code>NUMBER</code>, etc.) may be frontrun and created with attacker-chosen parameters. It's recommended to use this factory to deploy fully deterministic contracts only.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-08-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alberto La Roccahttps://github.com/71104 Aryaethnhttps://github.com/aryaethn https://wg-eips.ritovision.com/7998/

Transforms Ethereum’s `randao_reveal` into a per-slot BLS-based VRF by signing the previous epoch’s mix and current slot.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a modification to the data signed by a block proposer for the <code>randao_reveal</code>. The current <code>randao_reveal</code> is a BLS signature over the current epoch number, which is predictable. This proposal incorporates the RANDAO mix of the previous epoch and the current slot number into the signed data. This change transforms the <code>randao_reveal</code> into a Verifiable Random Function (VRF), making it unpredictable across epochs even for the revealer itself. This enhancement strengthens Ethereum's native randomness source and enables protocols such as Single Secret Leader Election (SSLE).</p> <h2 id="motivation">Motivation</h2> <p>This change creates a secure, per-slot VRF output from the proposer, with several benefits:</p> <ol> <li>it <strong>paves the way for secret proposer election</strong>, which would in turn reduce MEV and completely eliminate the well-known RANDAO bias attack vector;</li> <li>it supports other proposals like <a href="https://wg-eips.ritovision.com/7956/">EIP-7956</a> that rely on a source of verifiable randomness.</li> </ol> <p>Using a BLS signature as a VRF is sound under the Computational Diffie-Hellman (CDH) assumption, rather than Decisional Diffie-Hellman. The BLS verification process inherently proves the correctness of the VRF output without requiring a separate proof.</p> <h2 id="specification">Specification</h2> <p>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 <a rel="external" href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a> and <a rel="external" href="https://www.rfc-editor.org/rfc/rfc8174">RFC 8174</a>.</p> <p>The gist of the change is in <code>process_randao</code>, which now uses the RANDAO mix of the previous epoch and the current slot number to seed the <code>randao_reveal</code> signature. We are introducing a new SSZ-serializable container called <code>RandaoRevealSeed</code> containing that information.</p> <h3 id="new-ssz-container">New SSZ Container</h3> <p>A new SSZ <code>Container</code> is introduced to serve as the message for the <code>randao_reveal</code> signature post-fork.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RandaoRevealSeed</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> previous_mix</span><span>:</span><span> Bytes32</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> last RANDAO mix of the previous epoch</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> current slot number</span></span></code></pre><h3 id="modified-process-randao">Modified <code>process_randao</code></h3> <p>The block processing function <code>process_randao</code> in the beacon state transition is modified.</p> <p>Let <code>FORK_EPOCH</code> be the epoch of the network upgrade.</p> <p>The logic for verifying <code>body.randao_reveal</code> within <code>process_randao</code> is updated as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_randao</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> body</span><span>:</span><span> BeaconBlockBody</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> epoch</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify RANDAO reveal</span></span> <span class="giallo-l"><span> proposer</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>get_beacon_proposer_index</span><span>(</span><span>state</span><span>)</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> epoch</span><span class="z-keyword"> &lt;</span><span class="z-constant"> FORK_EPOCH</span><span>:</span></span> <span class="giallo-l"><span> signing_root</span><span class="z-keyword"> =</span><span> compute_signing_root</span><span>(</span><span>epoch</span><span>,</span><span> get_domain</span><span>(</span><span>state</span><span>,</span><span class="z-constant"> DOMAIN_RANDAO</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> previous_epoch</span><span class="z-keyword"> =</span><span> get_previous_epoch</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span> previous_mix</span><span class="z-keyword"> =</span><span> get_randao_mix</span><span>(</span><span>state</span><span>,</span><span> previous_epoch</span><span>)</span></span> <span class="giallo-l"><span> seed</span><span class="z-keyword"> =</span><span> RandaoRevealSeed</span><span>(</span><span>previous_mix</span><span>,</span><span> state</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span> signing_root</span><span class="z-keyword"> =</span><span> compute_signing_root</span><span>(</span><span>seed</span><span>,</span><span> get_domain</span><span>(</span><span>state</span><span>,</span><span class="z-constant"> DOMAIN_RANDAO</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> bls</span><span>.</span><span>Verify</span><span>(</span><span>proposer</span><span>.</span><span>pubkey</span><span>,</span><span> signing_root</span><span>,</span><span> body</span><span>.</span><span>randao_reveal</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Mix in RANDAO reveal</span></span> <span class="giallo-l"><span> mix</span><span class="z-keyword"> =</span><span> xor</span><span>(</span><span>get_randao_mix</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>)</span><span>,</span><span class="z-support"> hash</span><span>(</span><span>body</span><span>.</span><span>randao_reveal</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>randao_mixes</span><span>[</span><span>epoch</span><span class="z-keyword"> %</span><span class="z-constant"> EPOCHS_PER_HISTORICAL_VECTOR</span><span>]</span><span class="z-keyword"> =</span><span> mix</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="choice-of-vrf-input">Choice of VRF Input</h3> <p>The <code>randao_reveal</code> is effectively transformed into <code>VRF(sk, message)</code> where the <code>message</code> is the SSZ serialization of the <code>RandaoRevealSeed</code> container.</p> <ul> <li><code>previous_mix</code>: Including the RANDAO mix from the previous epoch (<code>previous_mix</code>) is the core of this proposal. Since the previous epoch's final mix is not known until the end of that epoch, a proposer cannot compute their <code>randao_reveal</code> of future epochs, beforehand.</li> <li><code>slot</code>: Including the current <code>slot</code> number ensures that the <code>randao_reveal</code> is unique for each slot and unpredictable to other validators. Without it, a validator chosen to propose multiple times in an epoch would produce the same reveal, which is undesirable for protocols that require unique randomness per instance, such as SSLE.</li> </ul> <h3 id="alternatives-considered">Alternatives Considered</h3> <p>We considered adding the <em>latest</em> RANDAO mix rather than that from the previous epoch so that we could obtain per-slot unpredictability, but that would cause fork ambiguity in the future if <code>randao_reveal</code> is used to implement SSLE.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade (i.e., a hard fork).</p> <p>Blocks produced after the <code>FORK_EPOCH</code> that do not use the new <code>RandaoRevealSeed</code> structure for the <code>randao_reveal</code> signature SHALL be considered invalid. Pre-fork blocks remain valid under the old rules.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="vrf-security">VRF Security</h3> <p>The security of the BLS signature scheme as a VRF relies on the Computational Diffie-Hellman (CDH) assumption in the target group. This is a standard cryptographic assumption. The output of the signature (a uniformly distributed G2 point in compressed format) can be treated as a pseudorandom number.</p> <h3 id="grinding">Grinding</h3> <p>The value of <code>randao_reveal</code> is deterministic and cannot be manipulated. It will be verified with the public BLS key of the validator, so it must be calculated using the corresponding private key. There are no grindable elements.</p> <h3 id="slot-by-slot-unpredictability">Slot-by-slot Unpredictability</h3> <p>Including the slot number is superfluous at the moment because it does not make the VRF slot-by-slot unpredictable to the revealer, only to other validators. But it will become critical in the future if and when we decide to implement secret proposer election and/or EIP-7956.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-06-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Kemptonhttps://github.com/SirSpudlington https://wg-eips.ritovision.com/7980/

Adds an EIP-7932 algorithm type for Ed25519 support of type `0x0`

<h2 id="abstract">Abstract</h2> <p>This EIP adds a new <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a> algorithm of type <code>0x0</code> for supporting Ed25519 signatures.</p> <h2 id="motivation">Motivation</h2> <p>Ed25519 is one of the most widely used forms of Elliptic Curve Cryptography and is one of the defaults for SSH keys, this makes it a good contender to be able to sign transactions with. It also provides an algorithm to write test cases against during the implementation phase of <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>.</p> <h2 id="specification">Specification</h2> <p>This EIP defines a new <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a> algorithmic type with the following parameters:</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>ALG_TYPE</code></td><td><code>Bytes1(0x0)</code></td></tr> <tr><td><code>GAS_PENALTY</code></td><td><code>1000</code></td></tr> <tr><td><code>MAX_SIZE</code></td><td><code>96</code></td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verify</span><span>(</span><span class="z-variable z-parameter z-function">signature_info</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> payload_hash</span><span>:</span><span> Hash32</span><span>)</span><span> -&gt;</span><span> ExecutionAddress</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span class="z-support">len</span><span>(</span><span>signature_info</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 96</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span>:</span><span class="z-constant">64</span><span>]</span></span> <span class="giallo-l"><span> public_key</span><span class="z-keyword"> =</span><span> signature_info</span><span>[</span><span class="z-constant">64</span><span>:</span><span>]</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is the `Verify` function described in [RFC 8032 Section 5.1.7](https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.7),</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This MUST be processed as raw `Ed25519` and not `Ed25519ctx` or `Ed25519ph`</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>ed25519_verify</span><span>(</span><span>signature</span><span>,</span><span> public_key</span><span>,</span><span> payload_hash</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> keccak256</span><span>(</span><span>public_key</span><span>)</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">20</span><span>:</span><span>]</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="additional-1000-gas-penalty">Additional 1000 gas penalty</h3> <p>The gas penalty discourages people from attempting to migrate off current secp256k1 accounts, and also covers the additional overhead (in regards to hashing) that the ed25519 curve applies.</p> <h3 id="why-ed25519">Why Ed25519?</h3> <p>Ed25519 has significant tooling backing it, this makes it a good candidate for using as a "dummy" algorithm. This allows it to be an algorithm for client teams to easily test <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>.</p> <p>It may also be useful for signing in Hardware security modules in server environments designed for serving as <a href="https://wg-eips.ritovision.com/4337/">ERC-4337</a> bundlers. It may also improve interoperability with other components such as TPM chips.</p> <h3 id="appending-the-public-key-to-the-signature">Appending the public key to the signature</h3> <p>Currently, without changing the algorithm itself, it is impossible to efficiently recover the public key from a signature and message.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <!-- TODO --> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-06-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7976/

Increase the calldata floor cost to 15/60 gas per byte to reduce maximum block size

<h2 id="abstract">Abstract</h2> <p>This EIP proposes an adjustment to calldata pricing by raising the floor cost from 10/40 to 15/60 gas per zero/non-zero calldata byte. This reduces the worst-case block size by ~33% with minimal impact.</p> <h2 id="motivation">Motivation</h2> <p>While <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> successfully reduced the maximum possible block size by introducing a floor cost of 10/40 gas per byte for data-heavy transactions, continued increases in gas limit demands further optimization. The current floor cost still permits relatively large data-heavy payloads that contribute to block size variance.</p> <p>By increasing the floor cost to 15/60 gas per byte, this proposal aims to:</p> <ul> <li>Further reduce the maximum possible block size for data-heavy transactions</li> <li>Create additional headroom for potential block gas limit increases</li> <li>Maintain the same exemption for transactions with significant EVM computation</li> <li>Have minimal impact on users</li> </ul> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>STANDARD_TOKEN_COST</code></td><td><code>4</code></td></tr> <tr><td><code>TOTAL_COST_FLOOR_PER_TOKEN</code></td><td><code>15</code></td></tr> </tbody></table> <p>Let <code>tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4</code>.</p> <p>Let <code>isContractCreation</code> be a boolean indicating the respective event.</p> <p>Let <code>execution_gas_used</code> be the gas used for EVM execution with the gas refund subtracted.</p> <p>Let <code>INITCODE_WORD_COST</code> be 2 as defined in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>.</p> <p>The formula for determining the gas used per transaction changes from <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>'s implementation to:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> isContractCreation</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">32000</span><span class="z-keyword"> +</span><span class="z-constant"> INITCODE_WORD_COST</span><span class="z-keyword"> *</span><span> words</span><span>(</span><span>calldata</span><span>)</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Any transaction with a gas limit below <code>21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata</code> or below its intrinsic gas cost (take the maximum of these two calculations) is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where <code>gasUsed</code> will be below this floor price, but the floor price needs to be reserved in the transaction gas limit.</p> <h2 id="rationale">Rationale</h2> <p>With <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>'s implementation, data-heavy transactions cost 10/40 gas per zero/non-zero byte, reducing the maximum possible EL payload size to approximately 1.07 MB (<code>45s_000_000/40</code>). This EIP further reduces this to approximately 0.72 MB (<code>45_000_000/60</code>) for non zero bytes and maintains proportional costs for non-zero bytes.</p> <p>By increasing calldata costs from 10/40 to 15/60 gas per byte for data-heavy transactions, this EIP provides:</p> <ul> <li><strong>Enhanced block size reduction</strong>: Maximum data-heavy payload size drops by ~33%.</li> <li><strong>Maintained user experience</strong>: Regular users engaging in DeFi, token transfers, and other EVM-heavy operations remain unaffected</li> <li><strong>Better blob incentivization</strong>: Higher calldata costs further encourage migration to blob usage for data availability</li> </ul> <p>The floor cost mechanism ensures that transactions involving significant EVM computation continue to pay the standard 4/16 gas per byte for calldata, preserving the user experience for regular Ethereum operations.</p> <p>Analyzing the block range 20644414 - 23272414 (Sept. 2024 - Sept. 2025), 1.5% of all transactions would have been affected.</p> <p>An empirical analysis summarizing the impact of this EIP can be found in <a href="https://wg-eips.ritovision.com/7976/assets/eip7976_empirical_analysis/">this</a> report.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically:</p> <ol> <li> <p><strong>Wallets</strong>: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the updated <code>TOTAL_COST_FLOOR_PER_TOKEN</code> parameter of 15. Failure to do so could result in underestimating gas, leading to failed transactions.</p> </li> <li> <p><strong>Node Software</strong>: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation with the new floor cost values.</p> </li> </ol> <p>Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p> <h2 id="test-cases">Test Cases</h2> <p>Testing for this EIP should verify the correct application of the new calldata cost floor of 15/60 gas per zero/non-zero byte:</p> <ol> <li><strong>Data-heavy transactions</strong>: Verify transactions with minimal EVM execution pay the floor cost of 15 gas per calldata token</li> <li><strong>EVM-heavy transactions</strong>: Confirm transactions with significant computation continue using standard 4/16 gas per byte</li> <li><strong>Edge cases</strong>: Test transactions at the boundary where execution gas equals or exceeds the floor cost</li> <li><strong>Gas estimation</strong>: Validate that <code>eth_estimateGas</code> correctly accounts for the new <code>TOTAL_COST_FLOOR_PER_TOKEN</code> value</li> <li><strong>Invalid transactions</strong>: Ensure transactions with insufficient gas limits are properly rejected</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>As the maximum possible block size is further reduced compared to <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>, no additional security concerns are introduced beyond those already addressed in the original proposal.</p> <p>The same transaction bundling considerations from <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> apply:</p> <ol> <li>Transaction bundling was already possible and remains so</li> <li>Bundling does not compromise the block size reduction objectives</li> <li>Practical limitations (trust, coordination) continue to limit widespread bundling</li> </ol> <p>The increased floor cost strengthens the incentive structure for appropriate data availability method selection without introducing new attack vectors.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-06-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper Maria Silvahttps://github.com/misilva73 Ben Adamshttps://github.com/benaadams https://wg-eips.ritovision.com/7973/

Introduce warm account writes, decreasing the cost of writing to an account after the first write.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces warm metering for account writes. Namely, if one of the account fields (<code>nonce</code>, <code>value</code>, <code>codehash</code>) is changed more than once in a transaction, the later writes are cheaper, since the state root update only happens once.</p> <h2 id="motivation">Motivation</h2> <p>Updating the state root is one of the most expensive parts of block construction. Currently, multiple writes to storage are subject to a net gas metering, which reduces the cost of a storage write after the first write. However, updates to the account are subject to the same cost every time.</p> <p>This means that, for example, making multiple WETH transfers to an account in a single transaction gets successfully cheaper as the cold access cost is amortized over the remaining accesses. At the same time, the same discount does not occur when making multiple native ETH transfers. This discourages people from using native ETH transfers, and unfairly penalizes potential future opcodes that involve value transfer, like <code>PAY</code> and <code>GAS2ETH</code>.</p> <p>This EIP brings the gas cost of the account update more in line with the actual execution cost. Multiple writes within a transaction can be batched, meaning that, after the first write, the cost of updating the state root does not need to be charged again.</p> <h2 id="specification">Specification</h2> <p>The parameters <code>GAS_CALL_VALUE</code> and <code>GAS_STORAGE_UPDATE</code> are removed, and the following parameters are introduced:</p> <table><thead><tr><th style="text-align: center"><strong>Parameter</strong></th><th style="text-align: center"><strong>Value</strong></th><th style="text-align: center"><strong>Description</strong></th></tr></thead><tbody> <tr><td style="text-align: center"><code>GAS_COLD_STORAGE_WRITE</code></td><td style="text-align: center">TBD</td><td style="text-align: center">Cost of a single update to the storage trie</td></tr> <tr><td style="text-align: center"><code>GAS_COLD_ACCOUNT_WRITE</code></td><td style="text-align: center">TBD</td><td style="text-align: center">Cost of a single update to the account trie</td></tr> <tr><td style="text-align: center"><code>GAS_WARM_WRITE</code></td><td style="text-align: center">TBD</td><td style="text-align: center">Cost of a warm update to a trie (i.e. does not trigger a new state root calculation)</td></tr> </tbody></table> <p>&lt;-- TODO --&gt;</p> <p>On the account-updating opcodes <code>CREATE</code>, <code>CREATE2</code>, and <code>*CALL</code>, instead of charging <code>GAS_CALL_VALUE</code>:</p> <ul> <li><code>GAS_COLD_ACCOUNT_WRITE</code> is charged if the account fields <strong>are equal</strong> to the transaction start values (i.e., they have not yet been updated by the transaction), or</li> <li><code>GAS_WARM_WRITE</code> is charged if the account fields <strong>are not equal</strong> to the transaction start values (i.e., they have already been updated before by the transaction).</li> </ul> <p><code>SSTORE</code> is also subjected to warm account metering. That is, this EIP splits the cost of <code>SSTORE</code> into two components, the cost to update the account tuple, and the cost to update the state trie. Note that if the state trie has already been updated once in a transaction, the account tuple is already dirty, and so we can amortize the cost of updating the account tuple again. Thus, the gas cost of <code>SSTORE</code> and its refund logic is updated to:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> get original_value and current_value</span></span> <span class="giallo-l"><span>state</span><span class="z-keyword"> =</span><span> evm</span><span>.</span><span>message</span><span>.</span><span>block_env</span><span>.</span><span>state</span></span> <span class="giallo-l"><span>original_value</span><span class="z-keyword"> =</span><span> get_storage_original</span><span>(</span></span> <span class="giallo-l"><span> state</span><span>,</span><span> evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>,</span><span> key</span></span> <span class="giallo-l"><span>)</span></span> <span class="giallo-l"><span>current_value</span><span class="z-keyword"> =</span><span> get_storage</span><span>(</span><span>state</span><span>,</span><span> evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>,</span><span> key</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> get account info</span></span> <span class="giallo-l"><span>original_account</span><span class="z-keyword"> =</span><span> get_account_original</span><span>(</span><span>evm</span><span>.</span><span>message</span><span>.</span><span>block_env</span><span>.</span><span>state</span><span>,</span><span> evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>)</span></span> <span class="giallo-l"><span>account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>evm</span><span>.</span><span>message</span><span>.</span><span>block_env</span><span>.</span><span>state</span><span>,</span><span> evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> initialize gas cost</span></span> <span class="giallo-l"><span>gas_cost</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Charge account write cost</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span> account</span><span class="z-keyword"> !=</span><span> original_account</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_WARM_WRITE</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_COLD_ACCOUNT_WRITE</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Charge slot-specific costs</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span> (</span><span>evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>,</span><span> key</span><span>)</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> evm</span><span>.</span><span>accessed_storage_keys</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>accessed_storage_keys</span><span>.</span><span>add</span><span>(</span><span>(</span><span>evm</span><span>.</span><span>message</span><span>.</span><span>current_target</span><span>,</span><span> key</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_COLD_SLOAD</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">if</span><span> original_value</span><span class="z-keyword"> ==</span><span> current_value</span><span class="z-keyword"> and</span><span> current_value</span><span class="z-keyword"> !=</span><span> new_value</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> original_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_STORAGE_SET</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_COLD_STORAGE_WRITE</span><span class="z-keyword"> -</span><span class="z-constant"> GAS_COLD_SLOAD</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_WARM_ACCESS</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Refund Counter Calculation</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span> current_value</span><span class="z-keyword"> !=</span><span> new_value</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> original_value</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> current_value</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> new_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Storage is cleared for the first time in the transaction</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>refund_counter</span><span class="z-keyword"> +=</span><span class="z-support"> int</span><span>(</span><span class="z-constant">GAS_STORAGE_CLEAR_REFUND</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> original_value</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> current_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Gas refund issued earlier to be reversed</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>refund_counter</span><span class="z-keyword"> -=</span><span class="z-support"> int</span><span>(</span><span class="z-constant">GAS_STORAGE_CLEAR_REFUND</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> original_value</span><span class="z-keyword"> ==</span><span> new_value</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Storage slot being restored to its original value</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> original_value</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Slot was originally empty and was SET earlier</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>refund_counter</span><span class="z-keyword"> +=</span><span class="z-support"> int</span><span>(</span><span class="z-constant">GAS_STORAGE_SET</span><span class="z-keyword"> -</span><span class="z-constant"> GAS_WARM_ACCESS</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Slot was originally non-empty and was UPDATED earlier</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>refund_counter</span><span class="z-keyword"> +=</span><span class="z-support"> int</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> GAS_COLD_STORAGE_WRITE</span><span class="z-keyword"> -</span><span class="z-constant"> GAS_COLD_SLOAD</span><span class="z-keyword"> -</span><span class="z-constant"> GAS_WARM_ACCESS</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Refund account writting cost (only if cold)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> account</span><span class="z-keyword"> ==</span><span> original_account</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>refund_counter</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_COLD_ACCOUNT_WRITE</span></span> <span class="giallo-l"></span></code></pre> <p>For compatibility with <a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a> and parallel execution, if the accessed account shows updates in the Block-Level Access List (BAL) in a transaction indexed before the current transaction, then the values to compare against are taken from this entry instead of the account trie.</p> <h2 id="rationale">Rationale</h2> <p>An account is represented within Ethereum as a tuple <code>(nonce, balance, storage_root, codehash)</code>. The account is a leaf of a Merkle Patricia Tree (MPT), while the <code>storage_root</code> is itself the root of the account's MPT key-value store. An update to the account's storage requires updating two MPTs (the account's <code>storage_root</code>, as well as the global state root). Meanwhile, updating the other fields in an account requires updating only one MPT.</p> <p>This proposal clarifies the cost of updating state by introducing the <code>*_WRITE</code> parameters. It also separates the cost of a storage state root update (<code>GAS_COLD_STORAGE_ACCESS</code>) and the cost of an account state root update (<code>GAS_COLD_ACCOUNT_ACCESS</code>). This parametrization allows us to apply warm costing to account updates. When the same account is updated multiple times in the same transaction, the state root calculation can be batched and all updates can be done in the same calculation. Therefore, the cost of making more updates to an already updated account is not the same as the first update.</p> <h3 id="benchmarking">Benchmarking</h3> <p>This proposal does not yet have finalized numbers. To achieve this, we require stateful benchmarks, which are currently in development. Once we collect that data, we will set the final numbers.</p> <p>&lt;– TODO –&gt;</p> <h3 id="net-metering">Net metering</h3> <p>Net metering (i.e., issuing a refund if the final value at the end of the transaction is equal to the transaction start, à la <code>SSTORE</code>) was considered, but not added for simplicity.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Wallet developers and node operators MUST update gas estimation handling to accommodate the new account access cost rules. Specifically:</p> <ul> <li>Wallets: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in overestimating gas, leading to potential attacks vectors.</li> <li>Node Software: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation with the new cost values.</li> </ul> <p>Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Decreasing the cost of account access operations could introduce new attack vectors. More analysis is needed to understand the potential effects on various dApps and user behaviors.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-06-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper Ben Adamshttps://github.com/benaadams Maria Silvahttps://github.com/misilva73 Jochem Brouwerhttps://github.com/jochem-brouwer https://wg-eips.ritovision.com/7971/

Decrease costs for TLOAD and TSTORE with a transaction-global limit

<h2 id="abstract">Abstract</h2> <p>This EIP proposes to reduce the gas costs for transient storage operations (<code>TLOAD</code> and <code>TSTORE</code>) by implementing constant pricing. To prevent denial-of-service attacks through excessive memory allocation, a transaction-global limit on transient storage slots is introduced. This approach provides lower costs for common use cases while maintaining security against resource exhaustion attacks.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a> introduced transient storage with gas costs equivalent to warm storage operations (100 gas). The current pricing model presents several limitations:</p> <ol> <li>Reentrancy Protection Cost: At 100 gas per operation, implementing reentrancy locks by default remains expensive enough to discourage universal adoption at the language level, leaving contracts vulnerable to one of the most common attack vectors.</li> <li>Underutilization: The high cost is still punishing to developers who wish to use transient storage for other legitimate use cases such as temporary approvals, callback metadata, and cross-frame communication within transactions.</li> <li>Pricing Inconsistency: Transient storage fundamentally requires fewer resources than persistent storage (no disk I/O, no state root updates), yet is priced identically to warm storage operations.</li> </ol> <p>This EIP addresses these issues by implementing constant, lower pricing for transient storage operations while introducing a transaction-global limit to prevent denial-of-service attacks. It also makes the cost of warm storage cheaper. This provides lower costs and enables broader adoption of transient storage, while also providing hard resource limits for clients.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <p>This EIP introduces the following parameters:</p> <table><thead><tr><th style="text-align: left">Constant</th><th style="text-align: left">Value</th><th style="text-align: left">Description</th></tr></thead><tbody> <tr><td style="text-align: left"><code>GAS_TLOAD</code></td><td style="text-align: left">5</td><td style="text-align: left">Gas cost of <code>TLOAD</code></td></tr> <tr><td style="text-align: left"><code>GAS_TSTORE</code></td><td style="text-align: left">12</td><td style="text-align: left">Gas cost of <code>TSTORE</code></td></tr> <tr><td style="text-align: left"><code>MAX_TRANSIENT_SLOTS</code></td><td style="text-align: left">131072</td><td style="text-align: left">The maximum number of transient slots allowed in a single transaction</td></tr> <tr><td style="text-align: left"><code>GAS_TSTORE_ALLOCATE</code></td><td style="text-align: left">24</td><td style="text-align: left">Cost of additional allocated slots</td></tr> </tbody></table> <h3 id="gas-cost-changes">Gas Cost Changes</h3> <ol> <li>The gas cost for <code>TLOAD</code> (opcode <code>0x5c</code>) is reduced from <code>GAS_WARM_ACCESS</code> (100) to <code>GAS_TLOAD</code>.</li> <li>The base gas cost for <code>TSTORE</code> (opcode <code>0x5d</code>) is reduced from <code>GAS_WARM_ACCESS</code> (100) to <code>GAS_TSTORE</code>.</li> </ol> <h3 id="transaction-global-transient-storage-limit">Transaction-Global Transient Storage Limit</h3> <p>A transaction-global counter tracks the number of unique transient storage slots written across all contracts during transaction execution:</p> <ol> <li>At the beginning of each transaction, initialize a counter <code>transient_slots_used</code> to 0.</li> <li>When <code>TSTORE</code> is executed: <ul> <li>If the slot has not been written to during this transaction (across any contract), increment <code>transient_slots_used</code>.</li> <li>If <code>transient_slots_used</code> exceeds <code>MAX_TRANSIENT_SLOTS</code>, the transaction MUST exceptionally halt.</li> </ul> </li> <li>The counter persists across all message calls in the transaction.</li> <li>The counter is reset to 0 at the end of the transaction.</li> </ol> <h3 id="implementation-note">Implementation Note</h3> <p>Implementations MUST track transient storage allocated across all contracts. A slot is considered unique based on the tuple <code>(contract_address, storage_key)</code>. Writing to the same slot multiple times within a transaction does not generally increment the counter after the first write (unless the slot gets deallocated with a revert).</p> <h2 id="rationale">Rationale</h2> <h3 id="constant-pricing-with-hard-limit">Constant Pricing with Hard Limit</h3> <p>This EIP implements constant pricing with a hard limit for several reasons:</p> <ol> <li>A hard limit provides guarantees on the total resource consumption which are easier to reason about for clients, rather than needing to perform a calculation as a function of current gas limits to find out what total memory consumption could be.</li> <li>Common use cases (e.g., reentrancy locks using 1-2 slots) are not penalized for worst case resource usage (like in DOS attacks).</li> <li>Clients can safely pre-reserve all memory which could be used by transient storage up-front at the beginning of a transaction.</li> </ol> <h3 id="gas-cost-selection">Gas Cost Selection</h3> <ul> <li><code>GAS_TLOAD</code> (5 gas): Transient storage reads require only memory access without disk I/O.</li> <li><code>GAS_TSTORE</code> (12 gas): Transient storage writes require memory allocation and journaling for revert support.</li> <li><code>GAS_TSTORE_ALLOCATE</code> (24 gas): Writes to fresh slots require memory allocation, which is more expensive than writing to an existing slot.</li> </ul> <p><code>TSTORE</code> currently has a fixed cost. However, writing to fresh slots requires memory allocation, which is more expensive than writing to an existing slot. Therefore, we may consider introducing charging more for the first slot allocation through the parameter <code>GAS_TSTORE_ALLOCATE</code>. However, we would also need to introduce a mechanism to check for the first slot allocation versus subsequent allocations.</p> <h4 id="benchmarking">Benchmarking</h4> <p>This proposal does not yet have finalized numbers. To achieve this, we require benchmarks on the transient memory operations, which are currently in development. Once we collect that data, we will set the final numbers. We will also use this to understand whether the difference in performance justifies pricing new slot allocations differently.</p> <p>We should note that warm storage loads from cache are expected to have similar performance characteristics to transient storage reads. Therefore, the final parameters should be consistent with <a href="https://wg-eips.ritovision.com/8038/">EIP-8038</a>.</p> <p>&lt;– TODO –&gt;</p> <h3 id="hard-limit-selection">Hard Limit Selection</h3> <p><code>MAX_TRANSIENT_SLOTS</code> of 131072 allows:</p> <ul> <li>Sufficient slots for typical user applications</li> <li>Memory usage bounded to approximately 8 MB per transaction (131072 slots * 64 bytes), which prevents OOM-based denial-of-service attacks</li> </ul> <h3 id="design-alternatives-considered">Design Alternatives Considered</h3> <ol> <li>Per-Contract Limits: Increased complexity in reasoning about resource consumption based on the shape of the call stack.</li> <li>Superlinear Pricing: Adds complexity, and still punishes "common" (non-DOS) use cases.</li> <li>No Limit: May allow memory-based DOS attack if transaction-level gas limits change, or if pricing changes in the future.</li> </ol> <p>The benefit of a hard limit is that the resource consumption is bounded predictably even in the presence of other parameter changes in the protocol.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known issues, besides the gas cost of existing operations being cheaper.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>This reference implementation includes the mechanism to price <code>TSTORE</code> depending on whether the slot was previously allocated.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Pseudo-code for transaction execution with global transient storage limit</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">GAS_TLOAD</span><span class="z-keyword"> =</span><span class="z-constant"> 5</span></span> <span class="giallo-l"><span class="z-constant">GAS_TSTORE</span><span class="z-keyword"> =</span><span class="z-constant"> 12</span></span> <span class="giallo-l"><span class="z-constant">GAS_TSTORE_ALLOCATE</span><span class="z-keyword"> =</span><span class="z-constant"> 24</span></span> <span class="giallo-l"><span class="z-constant">MAX_TRANSIENT_SLOTS</span><span class="z-keyword"> =</span><span class="z-constant"> 131072</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> TransactionContext</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-support"> __init__</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>transient_storage</span><span class="z-keyword"> =</span><span> {</span><span>}</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> (address, key) -&gt; value</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>unique_slots</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> set of (address, key) tuples</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>transient_slots_used</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> tload</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes32</span><span>)</span><span> -&gt;</span><span> Bytes32</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Charge gas</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>charge_gas</span><span>(</span><span class="z-constant">GAS_TLOAD</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Return value or zero</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> self</span><span>.</span><span>transient_storage</span><span>.</span><span>get</span><span>(</span><span>(</span><span>address</span><span>,</span><span> key</span><span>)</span><span>,</span><span> Bytes32</span><span>(</span><span class="z-constant">0</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> tstore</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>:</span><span> Bytes32</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Charge gas</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>charge_gas</span><span>(</span><span class="z-constant">GAS_TSTORE</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check if this is a new unique slot</span></span> <span class="giallo-l"><span> slot_id</span><span class="z-keyword"> =</span><span> (</span><span>address</span><span>,</span><span> key</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> slot_id</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span class="z-variable z-language"> self</span><span>.</span><span>unique_slots</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>charge_gas</span><span>(</span><span class="z-constant">GAS_TSTORE_ALLOCATE</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>unique_slots</span><span>.</span><span>add</span><span>(</span><span>slot_id</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check limit</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span>unique_slots</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> MAX_TRANSIENT_SLOTS</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> ExceptionalHalt</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">Transient storage limit exceeded</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Store value</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>transient_storage</span><span>[</span><span>slot_id</span><span>]</span><span class="z-keyword"> =</span><span> value</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>With <code>MAX_TRANSIENT_SLOTS</code> = 131072, maximum memory allocation is bounded to 8 MB per transaction (131072 * 64 bytes). Compared to limits under current pricing (100 gas), a 60M gas transaction can allocate up to 600,000 slots (38.4 MB). This EIP reduces the maximum allocated amount by 79%.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-06-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Giulio Rebuffohttps://github.com/Giulio2002 Ben Adamshttps://github.com/benaadams https://wg-eips.ritovision.com/7954/

Raise the maximum contract code size from 24KiB to 32KiB and initcode size from 48KiB to 64KiB.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes to raise the maximum allowed size for contract code deployed on Ethereum from 24,576 bytes to 32,768 bytes.</p> <h2 id="motivation">Motivation</h2> <p>The current 24KiB contract size limit can be restrictive for complex contracts and applications. Increasing the limit to 32KiB allows for more feature-rich contracts while maintaining reasonable constraints on block and state growth.</p> <h2 id="specification">Specification</h2> <ol> <li>Update the <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> contract code size limit of 24KiB (<code>0x6000</code> bytes) to 32KiB (<code>0x8000</code> bytes).</li> <li>Update the <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> initcode size limit of 48KiB (<code>0xC000</code> bytes) to 64KiB (<code>0x10000</code> bytes).</li> </ol> <h2 id="rationale">Rationale</h2> <ul> <li><strong>Developer Flexibility:</strong> Enables more complex contracts and features.</li> <li><strong>Backward Compatibility:</strong> Existing contracts are unaffected.</li> <li><strong>Simplicity:</strong> Only the size limit is changed, with no other protocol modifications.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and must be activated via a network upgrade (hard fork). Contracts larger than 24KiB, up to 32KiB, will be deployable after activation.</p> <h2 id="security-considerations">Security Considerations</h2> <p>A higher contract size limit may marginally increase the risk of denial-of-service attacks via large contracts, but the new limit remains conservative.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-05-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/7960/

Extend EOF container's types section with an extra type parameter.

<h2 id="abstract">Abstract</h2> <p>This EIP extends the definition of <code>types_section</code> in EOF format (<a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>) with an additional <code>type</code> parameter.</p> <h2 id="motivation">Motivation</h2> <p>An additional <code>type</code> parameter allows the EOF EVM interpreter to identify the "type" of a code section. This allows the interpreter to "interpret" each code section differently, allowing EOF function calls to, for example, invoke pure EVM64 code or even later support RISC-V.</p> <h2 id="specification">Specification</h2> <p><code>types_section</code>, as defined in EIP-3540, is changed to be of the following format <code>(type, reserved, inputs, outputs, max_stack_increase)</code>. <code>type</code> is <code>uint8</code>, <code>reserved</code> is 24 bits, and <code>inputs</code>, <code>outputs</code>, <code>max_stack_increase</code> are defined as <code>uint8</code>, <code>uint8</code>, <code>uint16</code> respectively, the same as before. The only valid <code>type</code> defined in this EIP is <code>0x01</code>. Additional EIPs may be defined for other code section <code>type</code>s.</p> <p><code>version</code>, as defined in EIP-3540, is changed to <code>0x02</code>, to avoid the backward compatibility issue if a third-party chain already deployed EOF in production.</p> <p>In EOF container, the following validation rules are added:</p> <ul> <li>If a <code>type</code> in <code>types_section</code> is not of a known type, then the validation fails.</li> <li><code>reserved</code> in <code>types_section</code> must be all zeros.</li> </ul> <h2 id="rationale">Rationale</h2> <p>The new <code>type</code> parameter allows a contract to "dispatch" to different variants of the interpreter to better suit its need.</p> <ul> <li>The portion of the code where it mainly interacts with Ethereum addresses, balances, storages may run "normal" EVM.</li> <li>The portion of the code that is computationally heavy may run faster EVM64, but loses the ability to directly interact with Ethereum addresses and balances.</li> </ul> <p>Allowing this <code>type</code> to be defined for each code section ensures that a contract remains concise -- it can quickly switch between its computational needs and system/runtime needs.</p> <p><code>reserved</code> is added to <code>types_section</code> to maintain the proper padding. Each item in <code>types_section</code> is now 64 bits in total.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As we know, EOF, including EIP-3540, was extremely close to being deployed before it was decided to withdraw from Fusaka. To avoid the issue that some third-party chains have already deployed EOF in production (given the state of EOF we can consider this to be likely), we bump <code>version</code> of EOF to <code>0x02</code>. <code>0x01</code> is now invalid.</p> <p>No other backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>To be added.</p> <!-- TODO --> <h2 id="reference-implementation">Reference Implementation</h2> <p>To be added.</p> <!-- TODO --> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-05-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/7961/

Define "pure" EVM64 mode, as an EOF code section.

<h2 id="abstract">Abstract</h2> <p>An EOF-only specification for EVM64 instruction set. This defines a separate "EVM64" type for EOF code section in addition to "regular EVM". The interpreter then enters EVM64 mode when entering the code section. This EIP is an alternative to <a href="https://wg-eips.ritovision.com/7937/">EIP-7937</a>.</p> <h2 id="motivation">Motivation</h2> <p>EIP-7937 has maximum compatibility with existing EVM. It implements EVM64 simply as a group of additional opcodes (using a prefix opcode). This EIP defines an alternative method, using EOF container's code section. It has its pros and cons. The code size will obviously become shorter, due to not needing multibyte opcodes any more. On the other hand, interop with EVM system calls become more difficult because it cannot be done in an EVM64 code section. The advantages and disadvantages are discussed further in the Rationale section.</p> <h2 id="specification">Specification</h2> <p>Define <code>0x02</code> as an allowed <code>type</code> in <code>types_section</code>, as defined in EIP-7960. This denotes an EVM64 code section.</p> <h3 id="eof-function-execution">EOF function execution</h3> <p>When entering an EOF code section (either at the beginning of the contract call, or through <code>CALLF</code>), it enters "pure EVM64 mode". Unless defined below, no other opcodes are allowed. Those opcodes all only operate on the least significant 64-bit, in little endian.</p> <p>During EOF validation, the validation function should enforce that only allowed opcodes exist.</p> <h3 id="gas-cost-constants">Gas cost constants</h3> <p>We define the following gas cost constants:</p> <ul> <li><code>G_BASE64</code>: 1</li> <li><code>G_VERYLOW64</code>: 2</li> <li><code>G_LOW64</code>: 3</li> <li><code>G_MID64</code>: 5</li> <li><code>G_HIGH64</code>: 7</li> <li><code>G_EXP64_STATIC</code>: 5</li> <li><code>G_EXP64_DYNAMIC</code>: 25</li> <li><code>G_RJUMPIV64</code>: 3</li> </ul> <h3 id="arithmetic-opcodes">Arithmetic opcodes</h3> <p>The 64-bit mode arithmetic opcodes are defined the same as non-64-bit mode, except that they only operate on the least significant 64-bits. In the below definition, <code>a</code>, <code>b</code>, <code>N</code> is <code>a mod 2^64</code>, <code>b mod 2^64</code> and <code>N mod 2^64</code>.</p> <ul> <li>ADD (<code>01</code>) and SUB (<code>03</code>): <code>a op b mod 2^64</code>, gas cost <code>G_VERYLOW64</code>.</li> <li>MUL (<code>02</code>), DIV (<code>04</code>), SDIV (<code>05</code>), MOD (<code>06</code>), SMOD (<code>07</code>), SIGNEXTEND (<code>0B</code>): <code>a op b mod 2^64</code>, gas cost <code>G_LOW64</code>.</li> <li>ADDMOD (<code>08</code>), MULMOD (<code>09</code>): <code>a op b % N mod 2^64</code>, gas cost <code>G_MID64</code>.</li> <li>EXP (<code>0A</code>): <code>a EXP b mod 2^64</code>, gas cost <code>static_gas = G_EXP64_STATIC, dynamic_gas = G_EXP64_DYNAMIC * exponent_byte_size</code>.</li> </ul> <h3 id="comparison-and-bitwise-opcodes">Comparison and bitwise opcodes</h3> <p>The 64-bit mode comparison and bitwise opcodes are defined the same as non-64-bit mode, except that they only operate on the least significant 64 bits.</p> <ul> <li>LT (<code>10</code>), GT (<code>11</code>), SLT (<code>12</code>), SGT (<code>13</code>), EQ (<code>14</code>), AND (<code>16</code>), OR (<code>17</code>), XOR (<code>18</code>): <code>a op b mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> <li>ISZERO (<code>15</code>), NOT (<code>19</code>): <code>op a mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> <li>SHL (<code>1B</code>), SHR (<code>1C</code>), SAR (<code>1D</code>): <code>a op N mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> <li>BYTE (<code>1A</code>) is defined as <code>(x &gt;&gt; i * 8) &amp; 0xFF</code>. Note that the definition is changed from big endian to little endian.</li> </ul> <h3 id="memory-opcodes">Memory opcodes</h3> <p><code>MLOAD64</code> (0x51) will load a 64-bits integer in little endian onto the stack. <code>MSTORE64</code> (0x52) will read an 64-bits integer from the stack, and store it to memory in little endian.</p> <p>The gas cost for both opcodes is <code>G_VERYLOW64</code>. The memory resizing costs count as 8 bytes.</p> <p><code>MSTORE8</code> is available in EVM64 mode, and its gas cost is the same as in "normal" EVM.</p> <h3 id="stack-opcodes">Stack opcodes</h3> <p><code>PUSH0</code> (0x5f) to <code>PUSH8</code> (0x67) follows 0-byte to 8-byte literal. The literal is read little endian and pushed onto the stack. The gas cost for them is <code>G_VERYLOW64</code>.</p> <p><code>POP</code>, <code>SWAPn</code> and <code>DUPn</code> are available in EVM64 mode, and their gas costs are the same as in "normal" EVM.</p> <h3 id="other-opcodes">Other opcodes</h3> <p>Contract opcodes <code>RETURN</code>, <code>REVERT</code>, <code>INVALID</code> are available in EVM64 mode. Their behaviors, including gas costs, are unchanged. However, for all stack items, only the least significant 64 bits are read.</p> <p><code>CALLF</code>, <code>RETF</code>, <code>RJUMP</code> are available in EVM64 mode. Their behaviors, including gas costs, are unchanged.</p> <p>For flow operations RJUMPI and RJUMPV, the 64-bit mode has following changes:</p> <ul> <li>For <code>RJUMPI64</code> (0xe1), the condition popped from stack is only read for the last 64 bits. Gas cost is <code>G_RJUMPIV64</code>.</li> <li>For <code>RJUMPV64</code> (0xe2), the case popped from stack is only read for the last 64 bits. Gas cost is <code>G_RJUMPIV64</code>.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="stack-behavior">Stack behavior</h3> <p>"Pure" in "pure EVM64" refers to the fact that all opcodes in EVM64 mode only operate on the least significant 64 bits. In this specification, we don't specifically define 64-bit stack. As far as this EIP is concerned, stack is still 256-bit. However, because they only operate on the least significant 64 bits. The most significant 192 bits becomes unobservable as long as the interpreter is in an EVM64 code section. Thus an EVM interpreter can optimize EVM64 execution as follows:</p> <ul> <li>When entering EVM64 code section, truncate <code>inputs</code> to 64 bits.</li> <li>Use 64-bit stack during EVM64 execution.</li> <li>When exiting EVM64 code section, prepend <code>0</code> to <code>outputs</code> to make it 256 bits.</li> </ul> <h3 id="discussions">Discussions</h3> <p>This alternative definition (compared with EIP-7937) has the advantage that the code size is now shorter (because no multibyte opcodes are needed). It however will only work with EOF contract but not "legacy" EVM. The interaction between EVM64 and "system calls" (those calls that read Ethereum block values, addresses, balances and storages) will be more difficult. It's not "seamless" like EIP-7937 where one can enter/exit 64-bit mode at ease. Depending on how the 64-bit optimization works out, this may be an advantage or a disadvantage.</p> <p>The memory is, as usual, still shared during the entire execution. So in EVM64, the contract can always use the memory to push/fetch data.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <!-- TODO: Add test cases and reference implementation --> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion. <!-- TODO --></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-05-27T00:00:00+00:00 2026-02-11T14:49:28+00:00 Carl Beekhuizenhttps://github.com/carlbeek Ulaş Erdoğanhttps://github.com/ulerdogan Doğan Alpaslanhttps://github.com/doganalpaslan https://wg-eips.ritovision.com/7951/

Add precompiled contract for secp256r1 ECDSA signature verification with proper security checks

<h2 id="abstract">Abstract</h2> <p>Add functionality to efficiently perform ECDSA signature verification over the secp256r1 elliptic curve (also known as P-256 or prime256v1). This precompile enables native support for signatures generated by modern secure hardware including Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices.</p> <p>This specification addresses critical security issues discovered in RIP-7212 while maintaining full interface compatibility with existing Layer 2 implementations.</p> <h2 id="motivation">Motivation</h2> <p>The secp256r1 elliptic curve is a NIST-standardized curve widely supported in modern secure hardware and authentication systems. Adding native support for secp256r1 signature verification to Ethereum enables several important use cases that are currently impossible or prohibitively expensive.</p> <p>Modern secure hardware devices, including Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn authenticators, use secp256r1 for key storage and signing operations. Native secp256r1 support enables sophisticated account abstraction patterns like device-native signing, multi-factor authentication, and simplified key management - ultimately reducing friction for mainstream adoption through familiar authentication flows.</p> <p>The secp256r1 curve is already widely supported across blockchain networks and protocols, including Layer 2 networks, enterprise blockchains, and interoperability protocols. This broad compatibility enables seamless integration with existing infrastructure while maintaining security through hardware-backed signing capabilities.</p> <p>This EIP supersedes RIP-7212 by implementing the same functionality with the same interface, but without the vulnerability.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="precompile">Precompile</h3> <p>We introduce <code>P256VERIFY</code> a precompile at the address <code>0x100</code> which performs ECDSA signature verification over the secp256r1 curve with a gas cost of <code>6900</code> gas</p> <h3 id="curve-parameters">Curve Parameters</h3> <p>The secp256r1 curve is fully defined by the following set of parameters:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>Curve equation: y^2 = x^3 + ax + b (mod p)</span></span> <span class="giallo-l"><span>Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc</span></span> <span class="giallo-l"><span>Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b</span></span> <span class="giallo-l"><span>Base point G:</span></span> <span class="giallo-l"><span> Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296</span></span> <span class="giallo-l"><span> Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5</span></span> <span class="giallo-l"><span>Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551</span></span> <span class="giallo-l"><span>Cofactor = h = 0x1</span></span></code></pre> <p>These parameters are standardized by NIST in SP 800-186<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup>.</p> <h3 id="fields-and-groups">Fields and Groups</h3> <p>The field Fp is defined as the finite field of size <code>p</code> with elements represented as integers between 0 and p-1 (both inclusive).</p> <p>The group G is defined as a set of Fp pairs (points) <code>(x,y)</code> such that either <code>(x,y)</code> is <code>(0,0)</code> (representing the point at infinity) or <code>x,y</code> satisfy the curve equation <code>y^2 = x^3 + ax + b (mod p)</code>.</p> <h3 id="points-and-encoding">Points and Encoding</h3> <h4 id="field-elements-encoding">Field Elements Encoding</h4> <p>A base field element (Fp) is encoded as <code>32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer <strong>must</strong> be less than the field modulus <code>p</code>.</p> <h4 id="encoding-of-points-in-g">Encoding of Points in G</h4> <p>Points in G are encoded as byte concatenation of the respective encodings of the <code>x</code> and <code>y</code> coordinates. Total encoding length for a G point is thus <code>64</code> bytes.</p> <h4 id="point-of-infinity-encoding">Point of Infinity Encoding</h4> <p>For secp256r1, the point with coordinates <code>(0, 0)</code> (zeroes in Fp) is <em>not</em> on the curve, so a sequence of <code>64</code> zero bytes is used by convention to encode the point of infinity.</p> <h4 id="encoding-of-scalars">Encoding of Scalars</h4> <p>A scalar is encoded as <code>32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer is <strong>not</strong> required to be less than or equal to the subgroup order <code>n</code>.</p> <h4 id="behavior-on-invalid-inputs">Behavior on Invalid Inputs</h4> <p>On inputs that cannot be valid encodings of field elements or points, the precompile <em>must</em> return `` (failure).</p> <h3 id="abi-for-p256verify-operation">ABI for <code>P256VERIFY</code> Operation</h3> <h4 id="input">Input</h4> <p><code>P256VERIFY</code> call expects <code>160</code> bytes as input that is interpreted as byte concatenation of:</p> <ul> <li><code>32</code> bytes: message hash <code>h</code></li> <li><code>32</code> bytes: signature component <code>r</code></li> <li><code>32</code> bytes: signature component <code>s</code></li> <li><code>32</code> bytes: public key x-coordinate <code>qx</code></li> <li><code>32</code> bytes: public key y-coordinate <code>qy</code></li> </ul> <h4 id="output">Output</h4> <p>Output is <code>32</code> bytes on successful verification and <code>0</code> bytes on failure:</p> <ul> <li><code>0x0000000000000000000000000000000000000000000000000000000000000001</code> for valid signatures</li> <li>`` for invalid signatures or invalid inputs</li> </ul> <h4 id="input-validation">Input Validation</h4> <p>The precompile MUST perform the following validation checks and return `` (failure) if any check fails:</p> <ol> <li><strong>Input length</strong>: Input MUST be exactly <code>160</code> bytes</li> <li><strong>Signature component bounds</strong>: Both <code>r</code> and <code>s</code> MUST satisfy <code>0 &lt; r &lt; n</code> and <code>0 &lt; s &lt; n</code></li> <li><strong>Public key bounds</strong>: Both <code>qx</code> and <code>qy</code> MUST satisfy <code>0 ≤ qx &lt; p</code> and <code>0 ≤ qy &lt; p</code></li> <li><strong>Point validity</strong>: The point <code>(qx, qy)</code> MUST satisfy the curve equation <code>qy^2 ≡ qx^3 + a*qx + b (mod p)</code></li> <li><strong>Point not at infinity</strong>: The point <code>(qx, qy)</code> MUST NOT be the point at infinity (represented as <code>(0, 0)</code>)</li> </ol> <h4 id="signature-verification-algorithm">Signature Verification Algorithm</h4> <p>The verification algorithm follows these steps:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span># Input validation (as specified above)</span></span> <span class="giallo-l"><span>if input_length != 160:</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"><span>if not (0 &lt; r &lt; n and 0 &lt; s &lt; n):</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"><span>if not (0 ≤ qx &lt; p and 0 ≤ qy &lt; p):</span></span> <span class="giallo-l"><span> return </span></span> <span class="giallo-l"><span>if qy^2 ≢ qx^3 + a*qx + b (mod p):</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"><span>if (qx, qy) == (0, 0):</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Signature verification</span></span> <span class="giallo-l"><span>s1 = s^(-1) (mod n)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Recover the random point used during signing</span></span> <span class="giallo-l"><span>R&#39; = (h * s1) * G + (r * s1) * (qx, qy)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Check for point at infinity</span></span> <span class="giallo-l"><span>if R&#39; is the point at infinity:</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Extract x-coordinate from r</span></span> <span class="giallo-l"><span>r&#39; = R&#39;.x</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Compare with modular reduction</span></span> <span class="giallo-l"><span>if r&#39; ≡ r (mod n):</span></span> <span class="giallo-l"><span> return 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>else:</span></span> <span class="giallo-l"><span> return </span></span></code></pre><h4 id="error-cases">Error Cases</h4> <ul> <li>Invalid input length (not exactly 160 bytes)</li> <li>Invalid field element encoding (≥ field modulus)</li> <li>Invalid signature component bounds (r or s not in range (0, n))</li> <li>Invalid public key (point at infinity or not on curve)</li> <li>Signature verification failure</li> </ul> <h3 id="gas-schedule">Gas Schedule</h3> <h4 id="p256verify-operation"><code>P256VERIFY</code> operation</h4> <p><code>6900</code> gas</p> <p>This cost is based on benchmarking against the existing <code>ECRECOVER</code> precompile (<code>3000</code> gas). During benchmarks we found that the actual cost of R1 verification was significantly slower than the <code>ECRECOVER</code> precompile and the decision was made to increase the gas cost to <code>6900</code> gas.</p> <h4 id="gas-burning-on-error">Gas Burning on Error</h4> <p>The precompile MUST NOT revert under any circumstances. Invalid inputs or verification failures MUST return `` and consume the same amount of gas had verification succeeded.</p> <h2 id="rationale">Rationale</h2> <h3 id="security-fixes">Security Fixes</h3> <p>This specification addresses two critical vulnerabilities in RIP-7212:</p> <ol> <li> <p><strong>Point-at-infinity check</strong>: The original RIP-7212 failed to check if the recovered point R' is the point at infinity. This could lead to non-deterministic behavior where the verification result depends on the underlying implementation's handling of infinity points, potentially causing consensus failures.</p> </li> <li> <p><strong>Modular comparison</strong>: The original comparison <code>r' == r</code> should be <code>r' ≡ r (mod n)</code> to handle cases where the x-coordinate of R' exceeds the curve order n. This ensures mathematically correct verification according to ECDSA standards.</p> </li> </ol> <h3 id="verification-vs-recovery">Verification vs Recovery</h3> <p>This specification uses signature verification rather than public key recovery (like <code>ECRECOVER</code>) because:</p> <ul> <li>Most secp256r1 implementations in hardware and software verify signatures directly</li> <li>The NIST FIPS 186-5 standard[^2] specifies verification, not recovery</li> <li>Verification is more efficient than recovery for this curve</li> <li>Existing hardware implementations provide verification interfaces</li> </ul> <h3 id="gas-cost-justification">Gas Cost Justification</h3> <p>The 6900 gas cost does not maintain compatibility with L2s, but it matches closer the benchmarks of actual implementations.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP maintains full interface compatibility with RIP-7212 implementations deployed on Layer 2 networks. The same contract bytecode that works with RIP-7212 will work with this specification.</p> <p>The security fixes are transparent to correctly implemented callers - they only affect edge cases that should have failed verification anyway. No existing valid use cases are broken.</p> <h3 id="interface-compatibility">Interface Compatibility</h3> <p>The precompile maintains a similar interface as RIP-7212 to ensure compatibility with existing Layer 2 deployments:</p> <ul> <li>Same address: <code>0x100</code></li> <li>Same input format: 160 bytes</li> <li>Same output format: 32 bytes</li> <li>Different gas cost: 3450 gas vs 6900 gas</li> <li>Same return values</li> </ul> <h2 id="test-cases">Test Cases</h2> <p>A set of test vectors for verifying implementations is located in a separate <a href="https://wg-eips.ritovision.com/7951/./assets/test-vectors.json">file</a>.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>A reference implementation is not supplied due to the ubiquity of secp256r1, if however a reference is needed, the NIST specification in FIPS 186-5[^2]</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="cryptographic-security">Cryptographic Security</h3> <p>The secp256r1 curve provides approximately 128 bits of security, equivalent to secp256k1 already in use in Ethereum. The curve parameters are standardized by NIST SP 800-186<sup class="footnote-reference" id="fr-1-2"><a href="#fn-1">1</a></sup> and have undergone extensive cryptographic analysis by the wider cryptographic community in addition to this curve being deployed to several L2s in the form of RIP-7212.</p> <h3 id="malleability">Malleability</h3> <p>Unlike secp256k1 ECDSA signatures, secp256r1 ECDSA signatures are not required to be non-malleable per NIST FIPS 186-5 standard [^2]. Applications requiring non-malleability should implement additional checks at the application layer.</p> <h3 id="side-channel-resistance">Side-Channel Resistance</h3> <p>We explicitly state that this precompile <strong>IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-1"> <p>Chen, L., Moody, D., Regenscheid, A., Randall, K., &amp; Robinson, A. (2023). <span style="font-style: italic;">Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</span> (Nos. 800–186). National Institute of Standards and Technology. https://doi.org/<a href="https://doi.org/10.6028/NIST.SP.800-186">10.6028/NIST.SP.800-186</a>[^2]: National Institute of Standards and Technology. (2023). <span style="font-style: italic;">Digital Signature Standard (DSS)</span> (Nos. 186–5). National Institute of Standards and Technology. https://doi.org/<a href="https://doi.org/10.6028/NIST.FIPS.186-5">10.6028/NIST.FIPS.186-5</a> <a href="#fr-1-1">↩</a> <a href="#fr-1-2">↩2</a></p> </li> </ol> </section> 2025-05-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/7957/

EVM Object Format support for EVM64

<h2 id="abstract">Abstract</h2> <p>This EIP defines EOF support for EVM64 with its additional code validation rules and <code>RJUMPI</code>, <code>RJUMPV</code> opcodes.</p> <h2 id="motivation">Motivation</h2> <p>EOF defines a stricter code validation rule to improve efficiency. Due to EVM64 using multibyte opcode (the mode opcode <code>C0</code>), a small adaptation is needed. This EIP also additionally defines a 64-bit mode <code>RJUMPI</code> and <code>RJUMPV</code> to be 64-bit.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>We define the following gas cost constant:</p> <table><thead><tr><th>Name</th><th>Gas</th></tr></thead><tbody> <tr><td><code>G_RJUMPIV64</code></td><td><code>3</code></td></tr> </tbody></table> <p>At EOF contract creation time as defined in <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>, if the opcode <code>C0</code> is encountered and it is not part of PUSH opcode's data, then the interpreter MUST validate that:</p> <ul> <li>The next opcode exists.</li> <li>The next opcode is <code>RJUMPI64</code>, <code>RJUMPV64</code>, or one of the core 64-bit opcode defined in <a href="https://wg-eips.ritovision.com/7937/">EIP-7937</a> minus <code>JUMP64</code> and <code>JUMPI64</code>.</li> </ul> <p>For flow operations RJUMPI and RJUMPV, the 64-bit mode has following changes:</p> <ul> <li>For <code>RJUMPI64</code> (0xc0e1), the condition popped from stack is only read for the last 64 bits. Gas cost is <code>G_RJUMPIV64</code>.</li> <li>For <code>RJUMPV64</code> (0xc0e2), the case popped from stack is only read for the last 64 bits. Gas cost is <code>G_RJUMPIV64</code>.</li> </ul> <p>Note that:</p> <ul> <li><code>RJUMP</code> is automatically in 64-bit mode because it does not read or write the stack.</li> </ul> <h2 id="rationale">Rationale</h2> <p>For detailed rationale discussion, please see the core EVM64 definition <a href="https://wg-eips.ritovision.com/7937/">EIP-7937</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>To be added.</p> <!-- TODO --> <h2 id="reference-implementation">Reference Implementation</h2> <p>To be added.</p> <!-- TODO --> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-05-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/7958/

Little endian opcodes `BYTE64`, `MLOAD64`, `MSTORE64`, and `PUSH*64` for EVM64

<h2 id="abstract">Abstract</h2> <p>This EIP defines additional little endian opcodes that can be deployed alongside <a href="https://wg-eips.ritovision.com/7937/">EIP-7937</a>.</p> <h2 id="motivation">Motivation</h2> <p>The core EIP that defines EVM64 (EIP-7937) is endianness-independent. This EIP defines those additional opcodes that must expose endianness. They are the bitwise opcode <code>BYTE64</code>, memory opcodes <code>MLOAD64</code> and <code>MSTORE64</code>, and stack opcodes <code>PUSH*64</code>.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>We define the following gas cost constant:</p> <ul> <li><code>G_VERYLOW64</code>: 2</li> </ul> <h3 id="byte64"><code>BYTE64</code></h3> <p><code>BYTE64</code> (0xc01a) is defined as <code>(x &gt;&gt; i * 8) &amp; 0xFF</code>. Note that the definition is changed from big endian to little endian.</p> <p>The gas cost is <code>G_VERYLOW64</code>.</p> <h3 id="mload64-and-mstore64"><code>MLOAD64</code> and <code>MSTORE64</code></h3> <p><code>MLOAD64</code> (0xc051) will load a 64-bit integer in little endian onto the stack. <code>MSTORE64</code> (0xc052) will read an 64-bit integer from the stack, and store it to memory in little endian.</p> <p>The gas cost for both opcodes is <code>G_VERYLOW64</code>. The memory resizing costs count as 8 bytes.</p> <p>As an example, <code>[0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]</code> is an array of 8 bytes (64 bits). Calling <code>MLOAD64</code> to load this 8-byte value to stack will read it in little endian, resulting in 64-bit integer <code>0x0807060504030201</code>. 64-bit mode always operate on only the least significant 64 bits. When another 256-bit opcodes encounter this value on stack, it will be <code>0x00..00 0807060504030201</code>. Calling <code>MSTORE64</code> to store this value to memory will result in the array <code>[0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]</code>.</p> <h3 id="push-64"><code>PUSH*64</code></h3> <p><code>PUSH2_64</code> (0xc061) to <code>PUSH8_64</code> (0xc067) follows 2-byte to 8-byte literal. The literal is read little endian and pushed onto the stack.</p> <p>The gas cost for them is <code>G_VERYLOW64</code>.</p> <p>As an example, <code>0xc0 0x67 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08</code> will result in a stack with single value <code>0x00..00 0807060504030201</code>.</p> <h2 id="rationale">Rationale</h2> <p>For detailed rationale discussion, please see the core EVM64 definition <a href="https://wg-eips.ritovision.com/7937/">EIP-7937</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>To be added.</p> <!-- TODO --> <h2 id="reference-implementation">Reference Implementation</h2> <p>To be added.</p> <!-- TODO --> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-05-24T00:00:00+00:00 2026-02-11T14:49:28+00:00 Aryaethnhttps://github.com/aryaethn https://wg-eips.ritovision.com/7956/

Decreasing MEV attacks by forcing a deterministic transaction ordering via block-level randomness.

<h2 id="abstract">Abstract</h2> <p>Proposers and builders can currently permute pending transactions arbitrarily, enabling reorder‑driven MEV. This EIP introduces a consensus rule that sorts all transactions inside a block by XOR‑ing each transaction hash with fresh slot randomness. The randomness is unknown until the slot starts, so the order is deterministic once known but unpredictable beforehand. The mechanism <strong>significantly reduces reorder‑based MEV</strong>; latency‑driven back‑running, censorship, and other classes of MEV remain and should be mitigated through complementary techniques (encrypted mempools, reputation, PBS marketplaces, etc.).</p> <h2 id="motivation">Motivation</h2> <p>Unrestricted ordering is the key enabler of sandwich and classic front‑running attacks. Deterministic ordering collapses these vectors to latency racing and information asymmetry. Clear candidate‑set and bundle semantics preserve fee markets while removing the need for trusted sequencers. Academic works shows deterministic ordering drives sandwich profits toward zero.</p> <h3 id="references">References</h3> <ul> <li> <p>Julia Ofoegbu, “Maximal Extractable Value (MEV): A Tale As Old As Time,” Medium (2024).</p> </li> <li> <p>J. Qian et al., “Deterministic Transaction Ordering Without Trusted Sequencers,” arXiv:2411.03327 v1 (2024).</p> </li> <li> <p>“Shutter Network Introduces Plan for First Encrypted Mempool on Ethereum,” GlobeNewswire, 13 Feb 2025.</p> </li> </ul> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="slot-randomness-r">Slot Randomness <code>R</code></h3> <p>We define our randomness <code>R</code> as the <code>randao_reveal</code> of the each slot, after <a href="https://wg-eips.ritovision.com/7998/">EIP-7998</a>, since this EIP provides slot-by-slot randomness for <code>randao_reveal</code> (only predictable for the builder). This provides enough randomness for our purpose of reducing MEV attacks by MEV bots.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>R = body.randao_reveal[0:32] : bytes32</span></span></code></pre><h3 id="builder-flow">Builder Flow</h3> <ol> <li><strong>Candidate‑set selection</strong> – Builders <strong>MAY</strong> choose <strong>any subset</strong> of the mempool based on priority fees, side agreements, or policy. Transactions not chosen are ignored.</li> <li><strong>Canonical sorting</strong> – Sort the chosen set by primary key <code>H(tx) ⊕ R</code> ascending, then secondary key <code>H(tx)</code> ascending, in case of collision on the primary key.</li> <li><strong>Gas‑limit packing</strong> – Append items in order until adding the next would exceed the block gas <strong>limit</strong>.</li> <li><strong>Bundles (optional cross‑address atomicity)</strong></li> </ol> <ul> <li> <p><strong>Definition</strong> – A bundle is a user‑signed list of fully‑signed transactions. Each <code>child_tx_rlp</code> is the canonical <strong>signed</strong> RLP encoding, including signature fields <code>(v, r, s)</code>. The bundle begins with a <em>fee‑payment</em> transaction that covers gas and builder tip for the entire bundle.</p> </li> <li> <p><strong>Hashing / sort key</strong> – Treat the bundle as a <em>virtual transaction</em> with key <code>H(concat(child_tx_rlps))</code>, where:</p> <ul> <li><code>child_tx_rlps[i]</code> <strong>MUST</strong> be the exact bytes that will later appear in the block body for that transaction, i.e. the <em>canonical RLP of the fully‑signed transaction</em> per <a href="https://wg-eips.ritovision.com/2718/">EIP‑2718</a> / <a href="https://wg-eips.ritovision.com/155/">EIP‑155</a> rules (for typed transactions the leading <em>type byte</em> and length prefix are included).</li> <li>Implementations <strong>MUST NOT</strong> strip or normalise the signature fields <code>(v,r,s)</code>; those 65 bytes are hashed as‑is so every participant derives an identical bundle key.</li> <li>The concatenation order is the author‑declared execution order of the child transactions.</li> </ul> </li> <li> <p><strong>Gas accounting</strong> – Bundle gas is the <strong>sum of the <code>gasLimit</code> fields</strong> of all child transactions. Builders use that sum when evaluating step 3.</p> </li> <li> <p><strong>Fit‑or‑skip rule</strong> – If the bundle (fee‑payment + children) would exceed the remaining gas limit, the bundle is skipped atomically.</p> </li> </ul> <ol start="5"> <li><strong>Fee dynamics</strong> – Priority fees influence membership in the candidate set (step 1) but <strong>never</strong> override the canonical order once a tx or bundle is selected.</li> </ol> <p>Here is a pseudocode for the above flow:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// Inputs</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// mempool : All pending txs &amp; user-signed bundles visible to the builder</span></span> <span class="giallo-l"><span>// R : 32-byte slot randomness supplied by randao_reveal</span></span> <span class="giallo-l"><span>// BLOCK_GAS_LIMIT : Max gas allowed in the block</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// Helper functions</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>function HASH(obj) → bytes32 // Keccak-256 of the byte sequence</span></span> <span class="giallo-l"><span>function PRIMARY_KEY(h, R) → bytes32 // h XOR R (bit-wise)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function bundleGas(bundle): // sum of gasLimit of children</span></span> <span class="giallo-l"><span> total ← 0</span></span> <span class="giallo-l"><span> for childTx in bundle.children:</span></span> <span class="giallo-l"><span> total ← total + childTx.gasLimit</span></span> <span class="giallo-l"><span> return total</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// 0. Candidate-set selection (builder policy / side deals / fee filter)</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>candidates ← pickSubsetFrom(mempool) // ANY subset is allowed</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// 1. Compute canonical keys &amp; gas cost for every candidate</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>for item in candidates:</span></span> <span class="giallo-l"><span> if item.type == &quot;single_tx&quot;:</span></span> <span class="giallo-l"><span> item.gasCost ← item.gasLimit</span></span> <span class="giallo-l"><span> baseHash ← HASH(item.RLP) // canonical signed RLP (EIP-2718)</span></span> <span class="giallo-l"><span> else if item.type == &quot;bundle&quot;:</span></span> <span class="giallo-l"><span> concatRlps ← CONCAT(item.child_rlps) // fee-tx + children in author order</span></span> <span class="giallo-l"><span> item.gasCost ← bundleGas(item)</span></span> <span class="giallo-l"><span> baseHash ← HASH(concatRlps)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> item.primaryKey ← PRIMARY_KEY(baseHash, R)</span></span> <span class="giallo-l"><span> item.secondaryKey ← baseHash</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// 2. Canonical sorting (primaryKey asc, then secondaryKey asc)</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>sort(candidates, by = (primaryKey ASC, secondaryKey ASC))</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// 3. Gas-limit packing with fit-or-skip for bundles</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>blockList ← empty list</span></span> <span class="giallo-l"><span>gasUsed ← 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>for item in candidates:</span></span> <span class="giallo-l"><span> if gasUsed + item.gasCost &gt; BLOCK_GAS_LIMIT:</span></span> <span class="giallo-l"><span> continue // skip whole tx or bundle atomically</span></span> <span class="giallo-l"><span> append(blockList, item)</span></span> <span class="giallo-l"><span> gasUsed ← gasUsed + item.gasCost</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>// 4. Output — assemble block body &amp; header field</span></span> <span class="giallo-l"><span>//---------------------------------------------------------------------</span></span> <span class="giallo-l"><span>block.randomness ← R // bytes16 in the payload header</span></span> <span class="giallo-l"><span>block.txOrderingVersion ← 1</span></span> <span class="giallo-l"><span>block.body ← flatten(blockList) // bundles explode into children</span></span> <span class="giallo-l"><span>return block</span></span></code></pre><h3 id="consensus-rule">Consensus Rule</h3> <p>A block is <strong>invalid</strong> if the executed list deviates from the canonical order derived from its <code>randomness</code> and the included transactions/bundles. Verification is objective; fork‑choice remains unchanged.</p> <h3 id="performance">Performance</h3> <p>Sorting ≤ 1 500 transactions remains <code>O(n log n)</code> (&lt; 1 ms), on today's hardware.</p> <h3 id="deployment">Deployment</h3> <h4 id="added-parameters">Added Parameters</h4> <ul> <li><code>randomness</code>: Specified in the specification.</li> <li><code>txOrderingVersion = 1</code> flag: To be compatible with the existing consensus rule and adding compatibility for future rules if needed.</li> </ul> <h4 id="fork-parameters">Fork Parameters</h4> <ul> <li><code>ORDERING_FORK_EPOCH</code>: Beacon‑chain epoch at which execution clients start to recognise the new fields <code>randomness</code> and <code>txOrderingVersion</code>.</li> <li><code>ORDERING_TRANSITION_EPOCHS</code> window activate the rule: 64 epochs (~13.6 h). Length of the transition window during which blocks with either ordering version are accepted.</li> </ul> <p>Both parameters are constants in the fork config and may be tuned during test‑net experiments.</p> <h4 id="activation-flow">Activation Flow</h4> <ol> <li> <p>Consensus‑layer upgrade — Beacon‑chain fork at <code>ORDERING_FORK_EPOCH</code> activates <strong><code>EL‑VRF‑exposure</code></strong> (companion EIP) and begins populating the <code>vrf_output_proposer</code> field. Execution clients receiving the <code>ExecutePayload</code> after this epoch expect a non‑zero <code>randomness</code> field.</p> </li> <li> <p>Execution‑layer handshake — Builders and proposers include the new <code>randomness</code> and <code>txOrderingVersion</code> fields in Engine API <code>engine_newPayloadV3</code> calls. Legacy nodes that have not upgraded will reject the payload, causing a natural chain split and economic incentive to upgrade.</p> </li> <li> <p>Transition window — For <code>ORDERING_TRANSITION_EPOCHS</code> after <code>ORDERING_FORK_EPOCH</code>, clients accept:</p> </li> </ol> <ul> <li> <p>Version 0 blocks — <code>txOrderingVersion</code> == 0; no randomness; legacy ordering.</p> </li> <li> <p>Version 1 blocks — <code>txOrderingVersion</code> == 1; valid randomness; canonical ordering enforced. During this period proposers are encouraged (but not forced) to adopt version 1 so that fee markets and MEV supply chains have time to adjust.</p> </li> </ul> <ol start="4"> <li>Finalisation — At <code>ORDERING_FORK_EPOCH</code> + <code>ORDERING_TRANSITION_EPOCHS</code> the consensus rule changes: blocks MUST set <code>txOrderingVersion == 1</code> and pass canonical‑order validation. A version‑0 block after this point is treated as invalid and will not be considered by fork‑choice.</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="why-randomness-driven-ordering">Why randomness‑driven ordering?</h3> <ul> <li> <p>Objective &amp; Verifiable – Using a function of on‑chain randomness (R) and a transaction’s own hash gives every validator an identical, cheap check on order validity.</p> </li> <li> <p>Unpredictable Until Slot Start – The XOR of slot‑level RANDAO and the proposer’s VRF output ensures that neither users nor builders can know the final sort key before the slot begins, closing the classic front‑run window.</p> </li> <li> <p>Minimal Surface Area – A single 16‑byte field in the execution payload plus a hash operation keeps consensus changes small and auditable.</p> </li> </ul> <h3 id="why-xor-as-the-mixing-function">Why XOR as the mixing function?</h3> <ul> <li> <p>XOR is associative, fast, and requires no extra cryptographic assumptions beyond SHA‑2 already used for H(tx).</p> </li> <li> <p>Any bias in one entropy component (e.g., RANDAO) is negated unless the attacker also controls the VRF output.</p> </li> </ul> <h3 id="why-allow-builders-to-curate-the-candidate-set-first">Why allow builders to curate the candidate set first?</h3> <ul> <li> <p>Preserves fee‑market incentives: high‑tip transactions still rise to the top of inclusion competition.</p> </li> <li> <p>Avoids forced inclusion of low‑value spam that could bloat blocks if the entire mempool were blindly sorted.</p> </li> </ul> <h3 id="why-a-secondary-key-h-tx-for-tie-breaking">Why a secondary key H(tx) for tie‑breaking?</h3> <ul> <li> <p>Guarantees total order with negligible extra cost.</p> </li> <li> <p>Leverages a value already known to every node; no extra field is needed.</p> </li> </ul> <h3 id="why-optional-bundles-instead-of-implicit-nonce-chain-folding">Why optional bundles instead of implicit nonce‑chain folding?</h3> <ul> <li> <p>Cross‑address atomicity (e.g., borrower + lender tx pair) cannot be expressed via nonce order alone.</p> </li> <li> <p>Requiring an explicit fee‑payment transaction embeds pricing for the externality a bundle imposes on ordering neutrality.</p> </li> </ul> <h3 id="why-the-fit-or-skip-bundle-rule">Why the "fit‑or‑skip" bundle rule?</h3> <ul> <li> <p>Ensures all clients compute the same gas impact, preventing divergent execution.</p> </li> <li> <p>Avoids partial bundle execution, which would undermine user intent.</p> </li> </ul> <h3 id="why-the-version-flag-transition-window">Why the version flag + transition window?</h3> <ul> <li> <p>Prevents accidental consensus splits by giving node operators a grace period.</p> </li> <li> <p>Mirrors previous successful hard forks (e.g., London’s BASE_FEE activation sequence).</p> </li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <ul> <li><strong>Old nodes</strong> — Execution clients that ignore the new fields will treat version‑1 blocks as malformed and fork away. The short transition window gives operators time to upgrade.</li> <li><strong>Light clients</strong> — No additional work; they track headers chosen by upgraded full nodes.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <h3 id="randomness-bias-randao-manipulation">Randomness Bias &amp; RANDAO Manipulation</h3> <ul> <li> <p><em>Single‑validator bias</em> – A block proposer can not change its <code>randao_reveal</code> output after EIP-7998, only predictable to him.</p> </li> <li> <p><em>Coalition bias</em> – Multiple consecutive‑slot proposers could attempt to influence RANDAO by withholding signatures, but the protocol already slashes equivocation and missed attestations. The cost rises exponentially with coalition size, and the added VRF entropy further randomizes <code>R</code>.</p> </li> <li> <p><em>Forkable bias</em> – Re‑org attempts longer than depth 1 must overcome the usual consensus finality thresholds. Because <code>R</code> is embedded in the execution payload, any fork conflicts are objectively detectable by all nodes.</p> </li> </ul> <p>Conclusion: Collusion attacks are economically unattractive; the mixed entropy from RANDAO and VRF provides strong unpredictability guarantees.</p> <h3 id="hash-grinding">Hash Grinding</h3> <p>New signatures are required only when <code>calldata</code> changes, but attacks must begin <strong>after</strong> block is built. Propagation delays and inclusion fees sharply limit profitable grinding to high‑value trades.</p> <h3 id="tie-collisions">Tie Collisions</h3> <p>Secondary key <code>H(tx)</code> guarantees total order; collision probability (<code>2^{-256}</code>) is negligible.</p> <h3 id="bundle-gas-consistency">Bundle Gas Consistency</h3> <p>Explicit summation rule ensures every client computes identical gas usage for bundles, preventing divergent validation.</p> <h3 id="residual-mev-vectors">Residual MEV Vectors</h3> <ul> <li> <p><em>Back‑running &amp; latency</em> – Persist.</p> </li> <li> <p><em>Builder discretion</em> – Builders may censor or selectively include transactions while forming the candidate set; exactly like the current status of Ethereum.</p> </li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-04-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mingfei Zhanghttps://github.com/Mart1i1nmingfei.zh@outlook.com Rujia Lirujia@tsinghua.edu.cn Xueqian Luxueqian.lu@bitheart.org Sisi Duanduansisi@tsinghua.edu.cn https://wg-eips.ritovision.com/7942/

A reorg-resilient solution for Ethereum

<h2 id="abstract">Abstract</h2> <p>This EIP proposes Available Attestation (AA), a protocol enhancement to make Ethereum PoS resilient against reorganization attacks. The proposal introduces a stability criterion for blocks based on attestation quorums, requiring that a block must include at least one-third of validators' attestations from the previous slot to be considered stable. The proposal includes three main changes: (1) modifying the parent selection rule to require AA from the previous slot, (2) replacing HLMD-GHOST with a Longest Stable Chain fork choice rule, and (3) adding a reference field to recent unstable blocks to preserve transaction continuity. These changes collectively prevent Byzantine validators from successfully executing reorganization attacks in synchronous networks while maintaining safety and liveness properties in partially synchronous networks. A full technical analysis is available in our <a href="https://wg-eips.ritovision.com/7942/./assets/available-attestation-paper.pdf">companion paper</a> accepted to USENIX Security 2025.</p> <h2 id="motivation">Motivation</h2> <p>We find that all known effective attacks on Ethereum PoS belong to reorganization attacks, although they emphasize different types of adversarial strategies. According to how the canonical chain is manipulated by the adversary, we classify known attacks into two categories: attacks from <em>changing block weight</em> and attacks from <em>filtering block tree</em>. The attacks from changing block weight refer to the strategy where Byzantine validators modify the <em>weight</em> of their proposed blocks to make their fork eventually become the canonical chain. Meanwhile, the attacks from filtering block tree do not change the block weight. Instead, these attacks make honest validators prune the canonical chain. This is often achieved by changing the <em>state</em> of honest validators. We summarize these malicious reorganization attacks in the following table.</p> <table><thead><tr><th><strong>attack type</strong></th><th><strong>scheme</strong></th><th><strong>timing assumption</strong></th><th><strong>mitigation solution</strong></th><th><strong>limitation</strong></th></tr></thead><tbody> <tr><td>changing block weight</td><td>ex-ante reorg</td><td>synchrony</td><td>proposer boosting v1</td><td>cause sandwich reorg</td></tr> <tr><td></td><td>balancing attack</td><td>synchrony</td><td>proposer boosting v1</td><td>cause sandwich reorg</td></tr> <tr><td></td><td>sandwich reorg</td><td>synchrony</td><td>proposer boosting v2⋆</td><td>cannot fully prevent</td></tr> <tr><td>filtering block tree</td><td>bouncing attack</td><td>partial synchrony†</td><td>safe-slots</td><td>cannot fully prevent</td></tr> <tr><td></td><td>unrealized justification reorg</td><td>synchrony</td><td>Capella upgrade</td><td>cause staircase attack</td></tr> <tr><td></td><td>justification withholding reorg</td><td>synchrony</td><td>Capella upgrade</td><td>cause staircase attack</td></tr> <tr><td></td><td>staircase attack</td><td>synchrony</td><td>Deneb upgrade</td><td>cannot fully prevent</td></tr> </tbody></table> <p>⋆ Proposer boosting parameter decreases from 0.7 to 0.4.<br /> † The attack is conducted after the network is synchronous.</p> <p>In response to these vulnerabilities, mitigation approaches have been proposed from both academia and industry. They are often designed in an ad-hoc way, addressing one issue at a time. Without formal proof, these mitigation approaches may create new issues. For instance, to mitigate the ex-ante reorg attack and balancing attack, Ethereum implements the <em>proposer boosting</em> mechanism. By temporarily adjusting the weight of the block in the current slot, the forks created by the adversary will not become the canonical chain. However, this mitigation approach introduces new issues. A so-called <em>sandwich reorg attack</em> was later proposed, exploiting proposer boosting to create a reorg attack. The sandwich reorg attack is a variant of ex-ante reorg attacks where two Byzantine proposers collude to make the blocks by honest validators orphaned. Additionally, many known mitigation solutions lack formal analysis or introduce additional assumptions, e.g., by assuming that the ratio of stake controlled by the adversary is no more than 20%. Therefore, our approach aims to provide a provably secure and efficient solution that is resilient to reorg attacks in Ethereum PoS.</p> <h2 id="specification">Specification</h2> <h3 id="overview">Overview</h3> <p>We provide a lightweight yet efficient solution for Ethereum PoS which is:</p> <ol> <li>reorg resilient in a synchronous network;</li> <li>safe and live in a partially synchronous network;</li> <li>easy to implement and deploy.</li> </ol> <p>We introduce AA, an approach inspired by conventional BFT protocols from <em>weak quorum</em> of attestations. Namely, consider a system with $N$ validators, among which at most $f$ are faulty. If $f+1$ validators vote for a block $b$ in slot $t$, at least one honest validator has validated $b$. The $f+1$ attestations become a <em>proof</em> of the availability of $b$. We use $AA_t$ to denote a block with $f+1$ attestations in slot $t$.</p> <p>Putting the concept of weak quorums in the context of Ethereum PoS, we define AA as a mechanism that checks <em>whether a block includes matching attestations from at least one-third of validators</em> (For simplicity, we assume that all validators attest in every slot in this section). In particular, if $b$ is a block for slot $t$, its child must include attestations for $b$ from at least one-third of validators in slot $t$. We use the notion of <em>stable block</em> to describe this scenario.</p> <h3 id="definition">Definition</h3> <p>Formally, we give the following definitions for AA:</p> <ul> <li> <p>(AA) We use $AA_t$ to denote a block that receives more than one-third of attestations voting for it in slot $t$.</p> </li> <li> <p>(Stable block) <em>A block $b$ proposed in slot $t$ is a stable block if the parent of block $b$ is $AA_{t-1}$</em></p> </li> <li> <p>(Unstable block) <em>Block $b$ is an unstable block if $b$ is not a stable block.</em></p> </li> <li> <p>(Stable chain) <em>The chain $c$ is a stable chain if the leaf block of $c$ is a stable block.</em></p> </li> </ul> <p>In practice, the validators are divided into 32 disjoint committees randomly. Since the committees are sampled pseudorandomly, the number of Byzantine validators in each committee can be approximated by a binomial distribution. We use $f$ as the number of total Byzantine validators and $f'$ as the expected number of Byzantine validators in each committee.</p> <ul> <li>We use $\vartheta$ to denote a threshold on the number of Byzantine validators in each committee and $p$ as the desirable failure probability (i.e., the probability that the number of Byzantine validators in a committee is greater than $\vartheta$).</li> </ul> <p>Given the desired value $p$, the value of $\vartheta$ can be calculated using $\vartheta = \lfloor\mu + \sigma \cdot \Phi^{-1}(1 - p)\rfloor,$ where $\mu = f'$, $\sigma^2 = f'(1 - f/n)$, and $\Phi^{-1}$ is the inverse of the cumulative distribution function of the normal distribution. We show some concrete examples of the ratio of Byzantine validators in a committee.</p> <table><thead><tr><th>n \ p</th><th>10⁻⁶</th><th>10⁻⁷</th><th>10⁻⁸</th><th>10⁻⁹</th></tr></thead><tbody> <tr><td>2¹⁴</td><td>0.4316</td><td>0.4414</td><td>0.4492</td><td>0.4570</td></tr> <tr><td>2¹⁶</td><td>0.3828</td><td>0.3872</td><td>0.3916</td><td>0.3955</td></tr> <tr><td>2¹⁸</td><td>0.3580</td><td>0.3603</td><td>0.3625</td><td>0.3645</td></tr> <tr><td>2²⁰</td><td>0.3457</td><td>0.3468</td><td>0.3479</td><td>0.3489</td></tr> </tbody></table> <p>Ethereum now has approximately $2^{20}$ validators. The maximum desirable probability $10^{-6}$ means that the protocol fails once every $10^{6}$ slots, i.e., 138 days. If the desirable failure probability is $10^{-9}$, malicious reorganization occurs once every 380 years. We can then draw the following conclusion:</p> <p><strong>For a large $n$, the ratio of Byzantine validators is closer to $f/n$. In this way, we can simply set $\vartheta$ as one-third of the committee size.</strong></p> <h3 id="protocol-changes">Protocol Changes</h3> <p>We make four main changes:</p> <ol> <li> <p><strong>Modify the selection rule of parent.</strong> As mentioned in the overview, we require that a block $b$ in slot $t$ must include $\vartheta+1$ attestations to prove that the parent of block $b$ is a valid output in slot $t-1$. Therefore, the parent of block $b$ is the $AA_{t-1}$. Such a block is a stable block. If no $AA_{t-1}$ exists, the parent of block $b$ is the output of the fork choice rule. Such a block is an unstable block.</p> </li> <li> <p><strong>Replace HLMD-GHOST with Longest Stable Chain fork choice rule.</strong> We replace the HLMD GHOST with the longest chain as the fork choice rule. Our longest chain fork choice rule is very simple: it outputs the head of the chain with the most stable blocks. In case of a tie, the longest chain fork choice rule chooses the chain such that the leaf block has the largest slot number.</p> </li> <li> <p><strong>Blocks carry a reference <code>unstable_root</code> to recent unstable blocks to preserve transaction continuity.</strong> We additionally include a field <code>unstable_root</code> in a block b. Each proposer sets its <code>unstable_root</code> field as the hash of an unstable block. If there is no such unstable block, set <code>unstable_root</code> as None. The transactions in the unstable blocks should not conflict with the transactions in the longest chain. The transactions in <code>unstable_root</code> can also be finalized once block b (that includes <code>unstable_root</code>) is finalized.</p> </li> <li> <p><strong>Simplify the filtering rule and the justification process.</strong> We simplify the filtering rule as it only considers the chain that justifies the last justified checkpoint. Additionally, the justification process only updates when a chain crosses the epoch boundary.</p> </li> </ol> <h3 id="pseudocode">Pseudocode</h3> <p>The modifications are based on validator and fork-choice.</p> <h4 id="modification-1">Modification 1</h4> <p>For the validator behavior specification (validator in consensus-specs):</p> <p>To propose, the validator selects a <code>BeaconBlock</code>, <code>parent</code> using this process:</p> <ol> <li>Compute AA blocks at the start of slot. Let <code>aa</code> be the later AA block and <code>aa_root</code> be the root of <code>aa</code>. Set <code>parent_root = aa_root</code>.</li> <li>If no AA block exists, compute fork choice's view of the head at the start of <code>slot</code>, after running <code>on_tick</code> and applying any queued attestations from <code>slot - 1</code>. Set <code>parent_root = get_head(store)</code>.</li> <li>Let <code>parent</code> be the block with <code>parent_root</code>.</li> </ol> <h4 id="modification-2">Modification 2</h4> <p>For the fork choice specification (fork_choice in consensus-specs):</p> <p>Add a class called <code>chain</code> to manage the stable chains.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Chain</span><span>(</span><span class="z-support">object</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> leaf</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> length</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> justified_checkpoint</span><span>:</span><span> Checkpoint</span></span></code></pre> <p>Add chains in <code>store</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Store</span><span>(</span><span class="z-support">object</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> chains</span><span>:</span><span> Set</span><span>[</span><span>Chain</span><span>]</span></span></code></pre> <p>Modify <code>get_head</code></p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_head</span><span>(</span><span class="z-variable z-parameter z-function">store</span><span>:</span><span> Store</span><span>)</span><span> -&gt;</span><span> Root</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Get filtered block tree that only includes viable branches</span></span> <span class="giallo-l"><span> chains</span><span class="z-keyword"> =</span><span> get_filtered_block_tree</span><span>(</span><span>store</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Execute the longest stable chain fork choice</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> max</span><span>(</span><span>chains</span><span>,</span><span class="z-variable"> key</span><span class="z-keyword">=</span><span class="z-storage z-type">lambda</span><span class="z-variable z-parameter z-function"> c</span><span>:</span><span> c</span><span>.</span><span>length</span><span>)</span><span>.</span><span>leaf</span></span></code></pre><h4 id="modification-3">Modification 3</h4> <p>For the validator behavior specification (validator in consensus-specs):</p> <p>Modify <code>Preparing for a BeaconBlock</code></p> <p>To construct a <code>BeaconBlockBody</code>, a <code>block</code> (<code>BeaconBlock</code>) is defined with the necessary context for a block proposal:</p> <h5 id="unstable-root">unstable_root</h5> <p>Set <code>block.unstable_root</code> as the hash of the latest unstable block if such block exists. If none exists, set <code>block.unstable_root = None</code>. The transactions in <code>unstable_root</code> must not conflict with the stable chain and will be finalized once <code>block</code> is finalized.</p> <h4 id="modification-4">Modification 4</h4> <p>For the fork choice specification (fork_choice in consensus-specs):</p> <p>Modify <code>get_filtered_block_tree</code>. Only consider the chain that justifies the latest justified checkpoint.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_filtered_block_tree</span><span>(</span><span class="z-variable z-parameter z-function">store</span><span>:</span><span> Store</span><span>)</span><span> -&gt;</span><span> List</span><span>[</span><span>Chain</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> chains</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> chain</span><span class="z-keyword"> in</span><span> store</span><span>.</span><span>chains</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_equal</span><span>(</span><span>store</span><span>.</span><span>justified_checkpoint</span><span>.</span><span>root</span><span>,</span><span> chain</span><span>.</span><span>justified_checkpoint</span><span>.</span><span>root</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> chains</span><span>.</span><span>append</span><span>(</span><span>chain</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> chains</span></span></code></pre> <p>Remove the fields <code>unrealized_justified_checkpoint</code> and <code>unrealized_finalized_checkpoint</code>. Remove <code>compute_pulled_up_tip</code>, i.e., remove the justification and finalization process that occurs during an epoch. The <code>justified_checkpoint</code> field of a chain is only updated when crossing an epoch boundary.</p> <h2 id="rationale">Rationale</h2> <p>The reason why our approach is reorg resilient is that the AA mechanism <em>prevents</em> Byzantine validators from creating conflicting branches. As summarized in the table, there are two strategies for Byzantine validators: (1) Byzantine validators directly propose a block conflicting with the canonical chain and (2) Byzantine validators propose a block that extends the canonical chain and delay releasing the block. Neither of these strategies works anymore after AA is implemented. For the first type, only the leaf blocks in the block tree can be the output of the fork choice rule. If a Byzantine validator tries to create a block $b_1$ that extends a block $b_0$ that is not a leaf block, $b_0$ will receive no attestations from honest validators. Thus, block $b_1$ is an unstable block. For the second type, our approach ensures that if Byzantine validators withhold at least two stable blocks, one of them must have already been observed by <em>all</em> honest validators (see Lemma 2 in our paper for details).</p> <p>Now it becomes clear why we use the <em>longest chain</em> rule to replace the HLMD-GHOST rule. Informally, as the HLMD-GHOST rule determines the canonical chain based on the weight of the blocks, and the weight is determined by the number of attestations, the HLMD-GHOST rule cannot prevent adversaries from withholding their attestations.</p> <p>Our modified protocol can achieve the safety and liveness properties of the consensus protocol. Safety still holds since we do not modify Casper, the finality gadget protocol. Liveness is achieved after GST mainly because our protocol is reorg resilient in a synchronous network. As all honest validators consider the blocks proposed by honest validators to be part of the longest chain, their attestations will be considered valid by all honest validators, so eventually some block is finalized.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The proposal modifies the fork choice logic and attestation format, which may not be compatible with existing clients. A hard fork or protocol version flag will be required for deployment.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li><strong>Resilience to reorg attacks</strong>: The protocol is provably resilient to all known forms of reorg attacks in synchronous networks.</li> <li><strong>No new attack surfaces</strong>: The protocol avoids introducing new message types or unnecessary overhead.</li> <li><strong>Safe and live</strong>: Maintains standard safety and liveness in partially synchronous networks.</li> </ul> <p>A full formal proof of correctness and evaluation over 16,384 validators is provided in the <a href="https://wg-eips.ritovision.com/7942/./assets/available-attestation-paper.pdf">companion paper</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-04-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vectorizedhttps://github.com/Vectorized Georgios Konstantopouloshttps://github.com/gakonst Jochem Brouwerhttps://github.com/jochem-brouwer Ben Adamshttps://github.com/benaadams Giulio Rebuffohttps://github.com/Giulio2002 https://wg-eips.ritovision.com/7939/

Opcode to count the number of leading zero bits in a 256-bit word

<h2 id="abstract">Abstract</h2> <p>Introduce a new opcode, <code>CLZ(x)</code>, which pops <code>x</code> from the stack and pushes the number of leading zero bits in <code>x</code> to the stack. If <code>x</code> is zero, pushes 256.</p> <h2 id="motivation">Motivation</h2> <p>Count leading zeros (CLZ) is a native opcode in many processor architectures (even in RISC architectures like ARM).</p> <p>It is a basic building block used in math operations, byte operations, compression algorithms, data structures:</p> <ul> <li>lnWad</li> <li>powWad</li> <li>lambertW0Wad</li> <li>sqrt</li> <li>cbrt</li> <li>byte string comparisons</li> <li>generalized calldata compression/decompression</li> <li>bitmaps (for finding the next/previous set/unset bit)</li> <li>post quantum signature schemes</li> </ul> <p>Adding a <code>CLZ</code> opcode will:</p> <ul> <li>Lead to cheaper compute.</li> <li>Lead to cheaper ZK proving costs. The fastest known Solidity implementation uses several dynamic bitwise right shifts <code>shr</code>, which are very expensive to prove. In SP1 rv32im, a 32-bit right shift costs 1.6x more than a 32-bit mul.</li> <li>Lead to smaller bytecode size. The fastest known Solidity implementation contains several large constants and is often inlined for performance.</li> </ul> <h2 id="specification">Specification</h2> <p>A new opcode is introduced: <code>CLZ</code> (<code>0x1e</code>).</p> <ul> <li>Pops 1 value from the stack.</li> <li>Pushes a value to the stack, according to the following code:</li> </ul> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-comment">///</span><span class="z-storage z-type"> @dev</span><span class="z-comment"> Count leading zeros.</span></span> <span class="giallo-l"><span class="z-comment">///</span><span class="z-comment"> Returns the number of zeros preceding the most significant one bit.</span></span> <span class="giallo-l"><span class="z-comment">///</span><span class="z-comment"> If `x` is zero, returns 256.</span></span> <span class="giallo-l"><span class="z-comment">///</span><span class="z-comment"> This is the fastest known `CLZ` implementation in Solidity and uses about 184 gas.</span></span> <span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-support">uint256</span><span class="z-variable"> x</span><span>)</span><span class="z-storage z-type"> internal</span><span class="z-storage z-type"> pure</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">uint256</span><span class="z-variable"> r</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-comment"> ///</span><span class="z-comment"> @solidity memory-safe-assembly</span></span> <span class="giallo-l"><span class="z-keyword"> assembly</span><span> {</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> shl</span><span>(</span><span class="z-constant">7</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span class="z-constant">0xffffffffffffffffffffffffffffffff</span><span>,</span><span> x</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> or</span><span>(</span><span>r</span><span>,</span><span class="z-entity z-name"> shl</span><span>(</span><span class="z-constant">6</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span class="z-constant">0xffffffffffffffff</span><span>,</span><span class="z-entity z-name"> shr</span><span>(</span><span>r</span><span>,</span><span> x</span><span>)</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> or</span><span>(</span><span>r</span><span>,</span><span class="z-entity z-name"> shl</span><span>(</span><span class="z-constant">5</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span class="z-constant">0xffffffff</span><span>,</span><span class="z-entity z-name"> shr</span><span>(</span><span>r</span><span>,</span><span> x</span><span>)</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> or</span><span>(</span><span>r</span><span>,</span><span class="z-entity z-name"> shl</span><span>(</span><span class="z-constant">4</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span class="z-constant">0xffff</span><span>,</span><span class="z-entity z-name"> shr</span><span>(</span><span>r</span><span>,</span><span> x</span><span>)</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> or</span><span>(</span><span>r</span><span>,</span><span class="z-entity z-name"> shl</span><span>(</span><span class="z-constant">3</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span class="z-constant">0xff</span><span>,</span><span class="z-entity z-name"> shr</span><span>(</span><span>r</span><span>,</span><span> x</span><span>)</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> forgefmt: disable-next-item</span></span> <span class="giallo-l"><span> r </span><span class="z-keyword">:=</span><span class="z-entity z-name"> add</span><span>(</span><span class="z-entity z-name">xor</span><span>(</span><span>r</span><span>,</span><span class="z-entity z-name"> byte</span><span>(</span><span class="z-entity z-name">and</span><span>(</span><span class="z-constant">0x1f</span><span>,</span><span class="z-entity z-name"> shr</span><span>(</span><span class="z-entity z-name">shr</span><span>(</span><span>r</span><span>,</span><span> x</span><span>)</span><span>,</span><span class="z-constant"> 0x8421084210842108cc6318c6db6d54be</span><span>)</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 0xf8f9f9faf9fdfafbf9fdfcfdfafbfcfef9fafdfafcfcfbfefafafcfbffffffff</span><span>)</span><span>)</span><span>,</span><span class="z-entity z-name"> iszero</span><span>(</span><span>x</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Or in Python,</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-parameter z-function">x</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Returns the number of zeros preceding the most significant one bit.</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> x</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span class="z-support"> ValueError</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">clz is undefined for negative numbers</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> x</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span class="z-support"> ValueError</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">clz is undefined for numbers larger than 2**256 - 1</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> x</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 256</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Convert to binary string and remove any &#39;0b&#39; prefix.</span></span> <span class="giallo-l"><span> bin_str</span><span class="z-keyword"> =</span><span class="z-support"> bin</span><span>(</span><span>x</span><span>)</span><span>.</span><span>replace</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">0b</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 256</span><span class="z-keyword"> -</span><span class="z-support"> len</span><span>(</span><span>bin_str</span><span>)</span></span></code></pre> <p>Or in C++,</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-storage">inline</span><span class="z-storage z-type"> uint32_t</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-variable"> x</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> r </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">!</span><span>(</span><span>x </span><span class="z-keyword">&amp;</span><span class="z-keyword"> 0x</span><span class="z-constant">FFFF0000</span><span>)</span><span>)</span><span> {</span><span> r </span><span class="z-keyword">+=</span><span class="z-constant"> 16</span><span>;</span><span> x </span><span class="z-keyword">&lt;&lt;=</span><span class="z-constant"> 16</span><span>;</span><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">!</span><span>(</span><span>x </span><span class="z-keyword">&amp;</span><span class="z-keyword"> 0x</span><span class="z-constant">FF000000</span><span>)</span><span>)</span><span> {</span><span> r </span><span class="z-keyword">+=</span><span class="z-constant"> 8</span><span>;</span><span> x </span><span class="z-keyword">&lt;&lt;=</span><span class="z-constant"> 8</span><span>;</span><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">!</span><span>(</span><span>x </span><span class="z-keyword">&amp;</span><span class="z-keyword"> 0x</span><span class="z-constant">F0000000</span><span>)</span><span>)</span><span> {</span><span> r </span><span class="z-keyword">+=</span><span class="z-constant"> 4</span><span>;</span><span> x </span><span class="z-keyword">&lt;&lt;=</span><span class="z-constant"> 4</span><span>;</span><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">!</span><span>(</span><span>x </span><span class="z-keyword">&amp;</span><span class="z-keyword"> 0x</span><span class="z-constant">C0000000</span><span>)</span><span>)</span><span> {</span><span> r </span><span class="z-keyword">+=</span><span class="z-constant"> 2</span><span>;</span><span> x </span><span class="z-keyword">&lt;&lt;=</span><span class="z-constant"> 2</span><span>;</span><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">!</span><span>(</span><span>x </span><span class="z-keyword">&amp;</span><span class="z-keyword"> 0x</span><span class="z-constant">80000000</span><span>)</span><span>)</span><span> {</span><span> r </span><span class="z-keyword">+=</span><span class="z-constant"> 1</span><span>;</span><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> r</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> `x` is a uint256 bit number represented with 8 uint32 limbs.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> This implementation is optimized for SP1 proving via rv32im.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> For regular compute, it performs similarly to `ADD`.</span></span> <span class="giallo-l"><span class="z-storage">inline</span><span class="z-storage z-type"> uint32_t</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-variable"> x</span><span>[</span><span class="z-constant">8</span><span>]</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">7</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">7</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">6</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 32</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">6</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">5</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 64</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">5</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">4</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 96</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">4</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">3</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 128</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">3</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 160</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">2</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 192</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">1</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> return</span><span class="z-constant"> 224</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span class="z-variable z-other">x</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 256</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The cost of the opcode is 5, matching MUL (raised from 3 to avoid under-pricing DoS risk).</p> <h2 id="rationale">Rationale</h2> <h3 id="the-special-0-case">The special 0 case</h3> <p>256 is the smallest number after 255. Returning a small number allows the result to be compared with minimal additional bytecode.</p> <p>For byte scanning operations, one can get the number of bytes to be skipped for a zero word by simply computing <code>256 &gt;&gt; 3</code>, which gives 32.</p> <h3 id="preference-over-ctz-count-trailing-zeros">Preference over <code>CTZ</code> (count trailing zeros)</h3> <p>Computing the least significant bit can be easily implemented with <code>CLZ</code> by isolating the smallest bit via <code>x &amp; -x</code>.</p> <p>However, it is not possible to implement <code>CLZ</code> with <code>CTZ</code>.</p> <h3 id="gas-cost">Gas cost</h3> <p>We have benchmarked the <code>CLZ</code> implementation against the <code>ADD</code> implementation in the intx library. <code>CLZ</code> uses approximately the same amount of compute cycles as <code>ADD</code>.</p> <p>The SP1 rv32im optimized variant uses less compute cycles than <code>ADD</code>, in the average and worst cases.</p> <p>In SP1 rv32im, a 256-bit <code>CLZ</code> is cheaper to prove than <code>ADD</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a new opcode not present prior.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0x000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000100</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0x4000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH32 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>CLZ</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x00000000000000000000000000000000000000000000000000000000000000ff</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p><code>CLZ</code> is a stateless opcode that has a low worst-case constant cost in memory usage, compute and proving costs. It is therefore safe from being exploited for denial of service attacks.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-04-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/7937/

Multibyte opcodes for 64-bit arithmetic, comparison, bitwise and flow operations in EVM.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces multibyte opcodes prefixed by <code>C0</code> for 64-bit arithmetic (<code>C001</code>-<code>C00B</code>), comparison (<code>C010</code>-<code>C015</code>), bitwise (<code>C016</code>-<code>C019</code>) and flow (<code>C056</code> and <code>C057</code>) operations.</p> <h2 id="motivation">Motivation</h2> <p>Not all computations in EVM can utilize the full 256-bit integer width. It can therefore be beneficial to have a "64-bit mode" to avoid unnecessary cycles. This EIP uses a "prefix" opcode <code>C0</code>, essentially forming multibyte opcodes to avoid polluting the EVM opcode space too much.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="prefix-opcode-behavior">Prefix opcode behavior</h3> <p>This EIP uses the prefix opcode <code>C0</code>, and it only occupies this single EVM opcode space. Upon the interpreter encountering opcode <code>C0</code>, it MUST continue to seek the next byte in code. It then executes things in "64-bit mode", based on the second byte, described below. If the execution is successful, then the interpreter MUST increase <code>PC</code> by 2 (instead of 1).</p> <p>If the second byte is not a valid 64-bit mode operation, then the interpreter MUST OOG.</p> <h3 id="general-64-bit-mode-behavior">General 64-bit mode behavior</h3> <p>In 64-bit mode, all operations only work on the least significant 64-bit of each stack value. The most significant 192-bit is discarded. When a result value is pushed back onto the stack, then it MUST ensures that observable effects will see that the most significant 192-bit is zero. Note that here it's not necessary for an interpreter to reset the most significant 192-bit to zero every time -- if the next opcode is still in 64-bit mode, then the most significant 192-bit is still unobservable. We discuss the full details in the "rationale" section. The interpreter only needs to reproduce the full 256-bit value upon entering non-64-bit mode. If the full computational heavy part can be written in pure 64-bit mode, then this can result in noticeable performance gain.</p> <h3 id="gas-cost-constants">Gas cost constants</h3> <p>We define the following gas cost constants:</p> <ul> <li><code>G_BASE64</code>: 1</li> <li><code>G_VERYLOW64</code>: 2</li> <li><code>G_LOW64</code>: 3</li> <li><code>G_MID64</code>: 5</li> <li><code>G_HIGH64</code>: 7</li> <li><code>G_EXP64_STATIC</code>: 5</li> <li><code>G_EXP64_DYNAMIC</code>: 25</li> </ul> <h3 id="arithmetic-opcodes">Arithmetic opcodes</h3> <p>The 64-bit mode arithmetic opcodes are defined the same as non-64-bit mode, except that it only operates on the least significant 64-bits. In the below definition, <code>a</code>, <code>b</code>, <code>N</code> is <code>a mod 2^64</code>, <code>b mod 2^64</code> and <code>N mod 2^64</code>.</p> <ul> <li>ADD (<code>C001</code>) and SUB (<code>C003</code>): <code>a op b mod 2^64</code>, gas cost <code>G_VERYLOW64</code>.</li> <li>MUL (<code>C002</code>), DIV (<code>C004</code>), SDIV (<code>C005</code>), MOD (<code>C006</code>), SMOD (<code>C007</code>), SIGNEXTEND (<code>C00B</code>): <code>a op b mod 2^64</code>, gas cost <code>G_LOW64</code>.</li> <li>ADDMOD (<code>C008</code>), MULMOD (<code>C009</code>): <code>a op b % N mod 2^64</code>, gas cost <code>G_MID64</code>.</li> <li>EXP (<code>C00A</code>): <code>a EXP b mod 2^64</code>, gas cost <code>static_gas = G_EXP64_STATIC, dynamic_gas = G_EXP64_DYNAMIC * exponent_byte_size</code>.</li> </ul> <h3 id="comparison-and-bitwise-opcodes">Comparison and bitwise opcodes</h3> <p>The 64-bit mode comparison and bitwise opcodes are defined the same as non-64-bit mode, except that they only operates on the least significant 64 bits.</p> <ul> <li>LT (<code>C010</code>), GT (<code>C011</code>), SLT (<code>C012</code>), SGT (<code>C013</code>), EQ (<code>C014</code>), AND (<code>C016</code>), OR (<code>C017</code>), XOR (<code>C018</code>): <code>a op b mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> <li>ISZERO (<code>C015</code>), NOT (<code>C019</code>): <code>op a mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> <li>SHL (<code>C01B</code>), SHR (<code>C01C</code>), SAR (<code>C01D</code>): <code>a op N mod 2^64</code>, gas cost <code>G_VERYLOW64</code></li> </ul> <p>Note that:</p> <ul> <li>64-bit EQ (<code>C014</code>) may return true for two different integers because it'll only compare the least significant 64 bits.</li> <li>64-bit ISZERO (<code>C015</code>) may return true for non-zero 256-bit integers as long as the last 64 bits are zero.</li> <li>BYTE (<code>1A</code>) does not have 64-bit mode because it affects endianness.</li> </ul> <h3 id="jump-jumpi">JUMP, JUMPI</h3> <p>For flow operations JUMP and JUMPI, the behavior is as follows:</p> <ul> <li><code>JUMP</code> (<code>C056</code>) will only read the last 64 bits from the stack value. The rest 192 bits are discarded without reading. Gas cost is <code>G_MID64</code>.</li> <li><code>JUMPI</code> (<code>C057</code>) will only read the last 64 bits from the stack as destination, and the condition check will only read the last 64 bits. Gas cost is <code>G_HIGH64</code>.</li> <li>In <code>JUMPDEST</code> validation phrase, <code>C0</code> is considered a standalone "mode" opcode and if the next byte followed is <code>JUMPDEST</code>, it continues to mark a valid <code>JUMPDEST</code> destination. Note that because there's no 64-bit <code>JUMPDEST</code>, during execution, <code>C0 JUMPDEST</code> would result in OOG.</li> </ul> <h2 id="rationale">Rationale</h2> <p>When a smart contract uses the 64-bit mode, it's expected that once entered, it will want to stay in 64-bit mode, and only exit to non-64-bit mode when the computationally intensive function is finished. This EIP is designed particularly with this fact in mind.</p> <p>All 64-bit opcodes only operates on the 64-bit value. It totally discards the rest 192 bits. The interpreter only needs to ensure that when it exits into non-64-bit mode and next time when a value result is read, that value has the first 192 bits reset to zero. The EVM interpreter can therefore use a typed stack for optimization:</p> <pre class="giallo z-code"><code data-lang="haskell"><span class="giallo-l"><span class="z-keyword">type</span><span class="z-storage z-type"> StackItem</span><span class="z-keyword"> =</span><span class="z-storage z-type"> Value</span><span class="z-storage z-type"> U256</span><span class="z-keyword"> |</span><span class="z-storage z-type"> Value64</span><span class="z-storage z-type"> U64</span></span></code></pre> <p>The typed stack can also be implemented as a bitmap for memory alignment.</p> <p>For all inputs of 64-bit opcodes, it will either read in a <code>Value</code>, when it'll only take the last 64 bits, or a <code>Value64</code>, which is what is needed. It then always outputs a <code>Value64</code>. After exiting into non-64-bit mode and upon a <code>Value64</code> is read, the interpreter then translate the value back to 256-bit <code>Value</code> by extending the first 192 bits with zero.</p> <p>The 64-bit mode does not contain any opcodes which depends on the value's endianness, therefore <code>Value64</code> can also be stored in the optimal endianness of the architecture.</p> <p>The 64-bit mode will not save any memory usage.</p> <h3 id="discussions">Discussions</h3> <h4 id="prefix-modes-opcodes">Prefix (modes) opcodes</h4> <p>This EIP also recommends that we reserve <code>C0</code>-<code>CF</code> for prefix (modes) opcodes. For example, an additional modes OVERFLOW can be envisioned that changes the behavior of arithmetic opcodes from wrapping to overflow OOG, which can help to reduce, for example, the extra cycles needed for <code>SafeMath</code>.</p> <h4 id="optimization-assumptions">Optimization assumptions</h4> <p>This EIP assumes that the majority of EVM implementations target native little-endian 64-bit architectures (like <code>x86_64</code>, <code>arm64</code> and <code>riscv64</code>). A 256-bit stack item is stored efficiently internally as 4 items of 64-bit unsigned integer <code>[u64; 4]</code>. This EIP works best, in terms of optimizations, for those implementations. The opcodes simply operates on the last <code>u64</code>, instead of the whole <code>[u64; 4]</code>. There are basically no other changes.</p> <h4 id="endianness">Endianness</h4> <p>In 64-bit mode, the principle of the specification is that the endianness should be kept strictly as an implementation detail. There should not be any opcodes that depends on endian. This is important, because on the one hand, we must enable easy and fast interop for 64-bit and non-64-bit opcodes. On the other hand, the interpreter should be able to do optimizations internally whether it uses little or big endian.</p> <p>Due to the issue of endianness, this EIP currently does not contain 64-bit mode <code>BYTE64</code>, memory opcodes <code>MLOAD64</code> and <code>MSTORE64</code>, and stack push opcodes <code>PUSH*64</code> (<code>PUSH1</code> to <code>PUSH8</code>).</p> <p>It is possible to extend EVM64 where "64-bit mode" is instead defined as "little-endian 64-bit mode", which can be separately discussed and specified:</p> <ul> <li><code>BYTE64</code> will be little-endian, so instead of <code>(x &gt;&gt; (248 - i * 8)) &amp; 0xFF</code>, it will be <code>(x &gt;&gt; i * 8) &amp; 0xFF</code>.</li> <li><code>MLOAD64</code> and <code>MSTORE64</code> loads and store little-endian 64-bit values in memory.</li> <li><code>PUSH*64</code> (<code>PUSH1</code> to <code>PUSH8</code>) accepts literal little-endian bytes.</li> </ul> <p>In specification there is no issue with the design, but this can bring significant confusions to developers. So the author advise caution.</p> <h4 id="pop-dup-swap"><code>POP</code>, <code>DUP*</code>, <code>SWAP*</code></h4> <p>There is no explicit 64-bit mode for stack operations:</p> <ul> <li><code>POP</code> is "automatically 64-bit" because it only removes values from the stack.</li> <li><code>DUP*</code> and <code>SWAP*</code> will copy or swap stack items optimized for 64-bit as is. They are kept optimized, so there's no need for separate 64-bit mode for those opcodes.</li> </ul> <h4 id="drawbacks">Drawbacks</h4> <p>Known drawbacks and tradeoffs of 64-bit mode includes:</p> <ul> <li>The binary size will become larger. This is apparent as previously the opcode is single byte, but now it is two bytes. Each byte costs an additional 200 gas to deposit. However, 64-bit mode opcodes are (generally) cheaper, which gives developers sufficient incentives to utilize it (at most 200 calls and the cumulative gas costs will be cheaper).</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new (prefix) opcode <code>C0</code>. <code>C0</code> was previously an invalid opcode that has little usage, and thus the backward compatibility issues are minimal.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases are organized as <code>[stack_item_1, stack_item_2] C0 opcode =&gt; [result_stack_item_1, result_stack_item_2]</code>.</p> <ul> <li><code>[ff00000000000000 000000000000000 0000000000000ff 000000000000001, ff0000000000000 000000000000000 0000000000000ff f0000000000000f] C0 SHR =&gt; [&lt;0&gt; 780000000000007]</code></li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>To be added.</p> <h2 id="security-considerations">Security Considerations</h2> <p>To be added.</p> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-04-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Giulio Rebuffohttps://github.com/Giulio2002 Ben Adamshttps://github.com/benaadams Storm Slivkoffhttps://github.com/sslivkoff https://wg-eips.ritovision.com/7934/

Introduce a protocol-level cap on the maximum RLP-encoded block size to 10 MiB, including a 2 MiB margin for beacon block size.

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB to account for beacon block sizes.</p> <h2 id="motivation">Motivation</h2> <p>Currently, Ethereum does not enforce a strict upper limit on the encoded size of blocks. This lack of constraint can result in:</p> <ol> <li><strong>Network Instability</strong>: Extremely large blocks slow down propagation and increase the risk of temporary forks and reorgs.</li> <li><strong>DoS Risks</strong>: Malicious actors could generate exceptionally large blocks to disrupt network performance.</li> </ol> <p>Additionally, blocks exceeding 10 MiB are not propagated by the consensus layer's (CL) gossip protocol, potentially causing network fragmentation or denial-of-service (DoS) conditions.</p> <p>By imposing a protocol-level limit on the RLP-encoded block size, Ethereum can ensure enhanced resilience against targeted attacks on block validation times. Adding an additional margin of 2MiB explicitly accommodates beacon block sizes, ensuring compatibility across network components.</p> <h2 id="specification">Specification</h2> <h3 id="block-size-cap">Block Size Cap</h3> <ul> <li>Introduce constants: <ul> <li><code>MAX_BLOCK_SIZE</code> set to <strong>10 MiB (10,485,760 bytes)</strong></li> <li><code>SAFETY_MARGIN</code> set to <strong>2MiB (2,097,152 bytes)</strong></li> <li><code>MAX_RLP_BLOCK_SIZE</code> calculated as <code>MAX_BLOCK_SIZE - MARGIN</code></li> </ul> </li> <li>Any RLP-encoded block exceeding <code>MAX_RLP_BLOCK_SIZE</code> must be considered invalid.</li> </ul> <p>Thus add the following check to the Ethereum protocol:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">MAX_BLOCK_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 10_485_760</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 10 MiB</span></span> <span class="giallo-l"><span class="z-constant">SAFETY_MARGIN</span><span class="z-keyword"> =</span><span class="z-constant"> 2_097_152</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2 MiB</span></span> <span class="giallo-l"><span class="z-constant">MAX_RLP_BLOCK_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> MAX_BLOCK_SIZE</span><span class="z-keyword"> -</span><span class="z-constant"> SAFETY_MARGIN</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> if true, the block is invalid and should be rejected/not get built</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> exceed_max_rlp_block_size</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> len</span><span>(</span><span>rlp</span><span>.</span><span>encode</span><span>(</span><span>block</span><span>)</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> MAX_RLP_BLOCK_SIZE</span></span></code></pre><h3 id="changes-to-protocol-behavior">Changes to Protocol Behavior</h3> <ol> <li><strong>Block Creation</strong>: Validators must ensure the total RLP-encoded size of any produced block does not exceed <code>MAX_RLP_BLOCK_SIZE</code>.</li> <li><strong>Block Validation</strong>: Nodes must reject blocks whose RLP-encoded size exceeds <code>MAX_RLP_BLOCK_SIZE</code>.</li> </ol> <h3 id="protocol-adjustment">Protocol Adjustment</h3> <ul> <li>All Ethereum client implementations must integrate this size check as part of block validation and propagation.</li> <li>This limit applies independently of gas-related metrics.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-10-mib">Why 10 MiB?</h3> <p>A cap of 10 MiB aligns with the gossip protocol constraint in Ethereum's consensus layer (CL). An additional 2MiB margin explicitly accounts for beacon block sizes, ensuring compatibility and consistent block propagation across the network. Blocks significantly larger than 10 MiB will not be broadcast by the CL, potentially leading to network fragmentation or denial-of-service scenarios.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is <strong>not backward-compatible</strong> with any blocks larger than the newly specified size limit. Validators and miners will need to ensure their block construction logic strictly respects this limit.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Restricting maximum block size provides inherent protection against deliberate oversized-block attacks.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-04-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Kemptonhttps://github.com/SirSpudlington https://wg-eips.ritovision.com/7932/

Introduces a precompile and registry for handling alternative signature algorithms

<h2 id="abstract">Abstract</h2> <p>This EIP:</p> <ul> <li>Creates a unified registry &amp; standardized interface for introducing additional signature algorithms for the use of deriving account addresses.</li> <li>Introduces a precompile at address <code>SIGRECOVER_PRECOMPILE_ADDRESS</code> for decoding these newly introduced algorithms.</li> </ul> <h2 id="motivation">Motivation</h2> <p>As quantum computers become more advanced, several new post-quantum (PQ) algorithms have been designed. These algorithms all have certain drawbacks, such as large key sizes (&gt;1KiB), large signature sizes, or long verification times. These issues make them more expensive to compute and store than the currently used secp256k1 curve.</p> <p>This EIP allows the use of many algorithms by introducing an algorithm registry that can be used via a single interface.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Unless explicitly noted, integer encoding MUST be in big-endian format.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>SIGRECOVER_PRECOMPILE_ADDRESS</code></td><td><code>Bytes20(0x12)</code></td></tr> <tr><td><code>SIGRECOVER_PRECOMPILE_BASE_GAS</code></td><td><code>3000</code></td></tr> </tbody></table> <h3 id="algorithm-specification">Algorithm specification</h3> <p>New algorithms beyond the <code>secp256k1</code> algorithm specified in this EIP MUST be specified via a distinct EIP.</p> <p>Each type of algorithm MUST specify the following fields:</p> <pre class="giallo z-code"><code data-lang="rust"><span class="giallo-l"><span class="z-storage z-type">trait</span><span class="z-entity z-name"> Algorithm</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The algorithm type byte</span></span> <span class="giallo-l"><span class="z-constant"> ALG_TYPE</span><span class="z-keyword">:</span><span class="z-variable z-other"> uint8</span><span>,</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The size of signatures. Signatures MUST be padded</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> to this size to be valid. Note that this does include</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> the ALG_TYPE byte prefix</span></span> <span class="giallo-l"><span class="z-constant"> SIZE</span><span class="z-keyword">:</span><span class="z-variable z-other"> uint32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Get the gas cost of signing this data. This</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> SHOULD include a reasonable minimum and MUST</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> be relative to secp256k1, i.e. 0 gas is secp256k1.</span></span> <span class="giallo-l"><span class="z-keyword"> fn</span><span class="z-entity z-name"> gas_cost</span><span>(</span><span class="z-variable z-other">signing_data</span><span class="z-keyword">:</span><span class="z-entity z-name"> Bytes</span><span>)</span><span class="z-keyword"> -&gt;</span><span class="z-entity z-name"> Uint64</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Check whether the signature is valid. For some</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> algorithms, this may be a no-op. This function</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> will always be called before `verify`.</span></span> <span class="giallo-l"><span class="z-keyword"> fn</span><span class="z-entity z-name"> validate</span><span>(</span><span class="z-variable z-other">signature</span><span class="z-keyword">:</span><span class="z-entity z-name"> Bytes</span><span>)</span><span class="z-keyword"> -&gt;</span><span class="z-entity z-name"> None</span><span class="z-keyword"> |</span><span class="z-entity z-name"> Error</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Take the signature and signing_data and return the</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> public key of the signer.</span></span> <span class="giallo-l"><span class="z-keyword"> fn</span><span class="z-entity z-name"> verify</span><span>(</span><span class="z-variable z-other">signature</span><span class="z-keyword">:</span><span class="z-entity z-name"> Bytes</span><span>,</span><span class="z-variable z-other"> signing_data</span><span class="z-keyword">:</span><span class="z-entity z-name"> Bytes</span><span>)</span><span class="z-keyword"> -&gt;</span><span class="z-entity z-name"> Bytes</span><span class="z-keyword"> |</span><span class="z-entity z-name"> Error</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Specifications MUST include some form of security analysis on the provided algorithm and basic benchmarks justifying gas costs. Additionally, specifications MUST address malleability issues that may arise from specified algorithms.</p> <p>An example of this specification can be found <a href="https://wg-eips.ritovision.com/7932/assets/template-eip/">here</a>.</p> <h3 id="deriving-address-from-public-keys">Deriving address from public keys</h3> <p>The function below MUST be used when deriving an address from a public key:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> pubkey_to_address</span><span>(</span><span class="z-variable z-parameter z-function">public_key</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> algorithm_id</span><span>:</span><span> uint8</span><span>)</span><span> -&gt;</span><span> ExecutionAddress</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> algorithm_id</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">FF</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compatibility shim to ensure backwards compatibility</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionAddress</span><span>(</span><span>keccak</span><span>(</span><span>public_key</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span><span>)</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> with `||` being binary concatenation</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ExecutionAddress</span><span>(</span><span>keccak</span><span>(</span><span>algorithm_id</span><span class="z-invalid z-illegal"> ||</span><span> public_key</span><span>)</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span>)</span></span></code></pre><h3 id="algorithm-registry">Algorithm Registry</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> AlgorithmEntry</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ALG_TYPE</span><span>:</span><span> uint8</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> SIZE</span><span>:</span><span> uint32</span><span>,</span></span> <span class="giallo-l"><span> gas_cost</span><span>:</span><span> Callable</span><span>[</span><span>[</span><span>Bytes</span><span>]</span><span>,</span><span> uint64</span><span>]</span><span>,</span></span> <span class="giallo-l"><span> validate</span><span>:</span><span> Callable</span><span>[</span><span>[</span><span>Bytes</span><span>]</span><span>,</span><span class="z-constant"> None</span><span class="z-keyword"> |</span><span> Error</span><span>]</span><span>,</span></span> <span class="giallo-l"><span> verify</span><span>:</span><span> Callable</span><span>[</span><span>[</span><span>Bytes</span><span>,</span><span> Bytes</span><span>]</span><span>,</span><span> Bytes</span><span class="z-keyword"> |</span><span> Error</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>algorithm_registry</span><span>:</span><span> Dict</span><span>[</span><span>uint8</span><span>,</span><span> AlgorithmEntry</span><span>]</span></span></code></pre> <p>This EIP uses the <code>algorithm_registry</code> object to signify algorithms that have been included within a hard fork.</p> <p>A living EIP MAY be created on finalization of this EIP to track currently active algorithms across forks.</p> <p>The algorithm type is reserved <code>0xFE</code> as invalid / missing.</p> <h3 id="helper-functions">Helper functions</h3> <p>The following helper functions are defined for convenience:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_penalty</span><span>(</span><span class="z-variable z-parameter z-function">algorithm</span><span>:</span><span> uint8</span><span>,</span><span class="z-variable z-parameter z-function"> signing_data</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> uint</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> algorithm</span><span class="z-keyword"> in</span><span> algorithm_registry</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> algorithm</span><span class="z-keyword"> =</span><span> algorithm_registry</span><span>[</span><span>algorithm</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> algorithm</span><span>.</span><span>gas_cost</span><span>(</span><span>signing_data</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_signature</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> Bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> in</span><span> algorithm_registry</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> algorithm</span><span class="z-keyword"> =</span><span> algorithm_registry</span><span>[</span><span>signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> algorithm</span><span>.</span><span>validate</span><span>(</span><span>signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This function cannot be called without prior calling `validate_signature(signature)`</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verify_signature</span><span>(</span><span class="z-variable z-parameter z-function">signing_data</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span> algorithm</span><span class="z-keyword"> =</span><span> algorithm_registry</span><span>[</span><span>signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> algorithm</span><span>.</span><span>verify</span><span>(</span><span>signature</span><span>,</span><span> signing_data</span><span>)</span></span></code></pre><h3 id="secp256k1-algorithm"><code>secp256k1</code> algorithm</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">ALG_TYPE</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">FF</span></span> <span class="giallo-l"><span class="z-constant">SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 66</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">SECP256K1_SIGNATURE_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> SIZE</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> secp256k1_unpack</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> ByteVector</span><span>[</span><span class="z-constant">SECP256K1_SIGNATURE_SIZE</span><span>]</span><span>)</span><span> -&gt;</span><span> tuple</span><span>[</span><span>uint256</span><span>,</span><span> uint256</span><span>,</span><span> uint8</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> r</span><span class="z-keyword"> =</span><span> uint256</span><span>.</span><span>from_bytes</span><span>(</span><span>signature</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> s</span><span class="z-keyword"> =</span><span> uint256</span><span>.</span><span>from_bytes</span><span>(</span><span>signature</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">64</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> y_parity</span><span class="z-keyword"> =</span><span> signature</span><span>[</span><span class="z-constant">64</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>r</span><span>,</span><span> s</span><span>,</span><span> y_parity</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> secp256k1_validate</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> ByteVector</span><span>[</span><span class="z-constant">SECP256K1_SIGNATURE_SIZE</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> SECP256K1N</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141</span></span> <span class="giallo-l"><span> r</span><span>,</span><span> s</span><span>,</span><span> y_parity</span><span class="z-keyword"> =</span><span> secp256k1_unpack</span><span>(</span><span>signature</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 0</span><span class="z-keyword"> &lt;</span><span> r</span><span class="z-keyword"> &lt;</span><span class="z-constant"> SECP256K1N</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> 0</span><span class="z-keyword"> &lt;</span><span> s</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> SECP256K1N</span><span class="z-keyword"> //</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> y_parity</span><span class="z-keyword"> in</span><span> (</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> gas_cost</span><span>(</span><span class="z-variable z-parameter z-function">signing_data</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Uint64</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is an adaptation from the KECCAK256 opcode</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Uint64</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> minimum_word_size</span><span class="z-keyword"> =</span><span> (</span><span class="z-support">len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Uint64</span><span>(</span><span class="z-constant">30</span><span class="z-keyword"> +</span><span> (</span><span class="z-constant">6</span><span class="z-keyword"> *</span><span> minimum_word_size</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span class="z-keyword"> |</span><span> Error</span><span>:</span></span> <span class="giallo-l"><span> secp256k1_validate</span><span>(</span><span>signature</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verify</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> signing_data</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span class="z-keyword"> |</span><span> Error</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Another compatibility shim to ensure passing a 32 byte hash still works.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>signing_data</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span> signing_data</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>signing_data</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> ecdsa</span><span class="z-keyword"> =</span><span> ECDSA</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> recover_sig</span><span class="z-keyword"> =</span><span> ecdsa</span><span>.</span><span>ecdsa_recoverable_deserialize</span><span>(</span><span>signature</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">65</span><span>]</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">65</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> public_key</span><span class="z-keyword"> =</span><span> PublicKey</span><span>(</span><span>ecdsa</span><span>.</span><span>ecdsa_recover</span><span>(</span><span>signing_data</span><span>,</span><span> recover_sig</span><span>,</span><span class="z-variable"> raw</span><span class="z-keyword">=</span><span class="z-constant">True</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> uncompressed</span><span class="z-keyword"> =</span><span> public_key</span><span>.</span><span>serialize</span><span>(</span><span class="z-variable">compressed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> uncompressed</span></span></code></pre><h3 id="sigrecover-precompile"><code>sigrecover</code> precompile</h3> <p>This EIP also introduces a new precompile located at <code>SIGRECOVER_PRECOMPILE_ADDRESS</code>.</p> <p>This precompile MUST charge <code>SIGRECOVER_PRECOMPILE_BASE_GAS</code> static gas before executing.</p> <p>The precompile MUST output the 20-byte address of the signer provided left padded to 32 bytes. Callers MUST assume all zero bytes as a failure. On failure, the precompile MUST return 32 <code>0x00</code> bytes.</p> <p>The precompile is defined as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> sigrecover_precompile</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> input</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> in</span><span> algorithm_registry</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> size</span><span class="z-keyword"> =</span><span> algorithm_registry</span><span>[</span><span class="z-support">input</span><span>[</span><span class="z-constant">0</span><span>]</span><span>]</span><span>.</span><span class="z-constant">SIZE</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span class="z-keyword"> &gt;</span><span> size</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span>:</span><span>size</span><span>]</span></span> <span class="giallo-l"><span> signing_data</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span>size</span><span>:</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> charge_gas</span><span>(</span><span>calculate_penalty</span><span>(</span><span class="z-support">input</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> signing_data</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Run validate/verify function</span></span> <span class="giallo-l"><span> validate_signature</span><span>(</span><span>signature</span><span>)</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> verify_signature</span><span>(</span><span>signing_data</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Return address left-padded to 32 bytes</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span class="z-storage z-type">b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> *</span><span class="z-constant"> 12</span><span>)</span><span class="z-keyword"> +</span><span> pubkey_to_address</span><span>(</span><span>pubkey</span><span>,</span><span class="z-support"> input</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="erc-4337-interoperability">ERC-4337 interoperability</h3> <p>While initial drafts of this EIP were competing with ERC-4337, current versions of this EIP support it via the sigrecover precompile. This allows any ERC-4337 implementation to have the same signature verification logic and address derivation logic for any given private key. This also works agnostic of whatever algorithm derives the address.</p> <h3 id="precompile-over-native-evm-code">Precompile over native EVM code</h3> <p>Having a precompile allows non-EVM processes, i.e. transaction level signature verification, to access the registry <em>without</em> having to call into the EVM.</p> <h3 id="opaque-signature-type">Opaque <code>signature</code> type</h3> <p>As each algorithm has unique properties, e.g. supporting signature recovery and key sizes, the object needs to hold every permutation of every possible signature and potentially additional recovery information. A bytearray of an algorithm-defined size would be able to achieve this goal.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>EIP-7932 does not modify any existing logic and does not pose any backwards compatibility issues.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for the <code>sigrecover</code> precompile may be found in the <a href="https://wg-eips.ritovision.com/7932/./assets/precompile_test_cases.py">precompile_test_cases.py</a> file.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Allowing more ways to derive addresses for a single account may decrease overall security for that specific account. However, this is partially mitigated by the increase in processing power required to trial all algorithms. Even still, adding additional algorithms may need further discussion to ensure that the security of the network would not be compromised.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Toni Wahrstätterhttps://github.com/nerolation Dankrad Feisthttps://github.com/dankrad Francesco D`Amatohttps://github.com/fradamt Jochem Brouwerhttps://github.com/jochem-brouwer Ignacio Hagopianhttps://github.com/jsign https://wg-eips.ritovision.com/7928/

Enforced block access lists with state locations and post-transaction state diffs

<h2 id="abstract">Abstract</h2> <p>This EIP introduces Block-Level Access Lists (BALs) that record all accounts and storage locations accessed during block execution, along with their post-execution values. BALs enable parallel disk reads, parallel transaction validation, parallel state root computation and executionless state updates.</p> <h2 id="motivation">Motivation</h2> <p>Transaction execution cannot be parallelized without knowing in advance which addresses and storage slots will be accessed. While <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> introduced optional transaction access lists, they are not enforced.</p> <p>This proposal enforces access lists at the block level, enabling:</p> <ul> <li>Parallel disk reads and transaction execution</li> <li>Parallel post-state root calculation</li> <li>State reconstruction without executing transactions</li> <li>Reduced execution time to <code>parallel IO + parallel EVM</code></li> </ul> <h2 id="specification">Specification</h2> <h3 id="block-structure-modification">Block Structure Modification</h3> <p>We introduce a new field to the block header, <code>block_access_list_hash</code>, which contains the Keccak-256 hash of the RLP-encoded block access list. When no state changes are present, this field is the hash of an empty RLP list <code>0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347</code>, i.e. <code>keccak256(rlp.encode([]))</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Header</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Existing fields</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> block_access_list_hash</span><span>:</span><span> Hash32</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>rlp</span><span>.</span><span>encode</span><span>(</span><span>block_access_list</span><span>)</span><span>)</span></span></code></pre> <p>The <code>BlockAccessList</code> is not included in the block body. The EL stores BALs separately and transmits them as a field in the <code>ExecutionPayload</code> via the engine API. The BAL is RLP-encoded as a list of <code>AccountChanges</code>. When no state changes are present, this field is the empty RLP list <code>0xc0</code>, i.e. <code>rlp.encode([])</code>.</p> <h3 id="rlp-data-structures">RLP Data Structures</h3> <p>BALs use RLP encoding following the pattern: <code>address -&gt; field -&gt; block_access_index -&gt; change</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Type aliases for RLP encoding</span></span> <span class="giallo-l"><span>Address</span><span class="z-keyword"> =</span><span> bytes20</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 20-byte Ethereum address</span></span> <span class="giallo-l"><span>StorageKey</span><span class="z-keyword"> =</span><span> uint256</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Storage slot key</span></span> <span class="giallo-l"><span>StorageValue</span><span class="z-keyword"> =</span><span> uint256</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Storage value</span></span> <span class="giallo-l"><span>Bytecode</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Variable-length contract bytecode</span></span> <span class="giallo-l"><span>BlockAccessIndex</span><span class="z-keyword"> =</span><span> uint16</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Block access index (0 for pre-execution, 1..n for transactions, n+1 for post-execution)</span></span> <span class="giallo-l"><span>Balance</span><span class="z-keyword"> =</span><span> uint256</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Post-transaction balance in wei</span></span> <span class="giallo-l"><span>Nonce</span><span class="z-keyword"> =</span><span> uint64</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Account nonce</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Core change structures (RLP encoded as lists)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> StorageChange: [block_access_index, new_value]</span></span> <span class="giallo-l"><span>StorageChange</span><span class="z-keyword"> =</span><span> [</span><span>BlockAccessIndex</span><span>,</span><span> StorageValue</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> BalanceChange: [block_access_index, post_balance]</span></span> <span class="giallo-l"><span>BalanceChange</span><span class="z-keyword"> =</span><span> [</span><span>BlockAccessIndex</span><span>,</span><span> Balance</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> NonceChange: [block_access_index, new_nonce]</span></span> <span class="giallo-l"><span>NonceChange</span><span class="z-keyword"> =</span><span> [</span><span>BlockAccessIndex</span><span>,</span><span> Nonce</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> CodeChange: [block_access_index, new_code]</span></span> <span class="giallo-l"><span>CodeChange</span><span class="z-keyword"> =</span><span> [</span><span>BlockAccessIndex</span><span>,</span><span> Bytecode</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> SlotChanges: [slot, [changes]]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> All changes to a single storage slot</span></span> <span class="giallo-l"><span>SlotChanges</span><span class="z-keyword"> =</span><span> [</span><span>StorageKey</span><span>,</span><span> List</span><span>[</span><span>StorageChange</span><span>]</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> AccountChanges: [address, storage_changes, storage_reads, balance_changes, nonce_changes, code_changes]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> All changes for a single account, grouped by field type</span></span> <span class="giallo-l"><span>AccountChanges</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span> Address</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> address</span></span> <span class="giallo-l"><span> List</span><span>[</span><span>SlotChanges</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes (slot -&gt; [block_access_index -&gt; new_value])</span></span> <span class="giallo-l"><span> List</span><span>[</span><span>StorageKey</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads (read-only storage keys)</span></span> <span class="giallo-l"><span> List</span><span>[</span><span>BalanceChange</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes ([block_access_index -&gt; post_balance])</span></span> <span class="giallo-l"><span> List</span><span>[</span><span>NonceChange</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes ([block_access_index -&gt; new_nonce])</span></span> <span class="giallo-l"><span> List</span><span>[</span><span>CodeChange</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes ([block_access_index -&gt; new_code])</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> BlockAccessList: List of AccountChanges</span></span> <span class="giallo-l"><span>BlockAccessList</span><span class="z-keyword"> =</span><span> List</span><span>[</span><span>AccountChanges</span><span>]</span></span></code></pre><h3 id="scope-and-inclusion">Scope and Inclusion</h3> <p><strong><code>BlockAccessList</code></strong> is the set of all addresses accessed during block execution.</p> <p>It <strong>MUST</strong> include:</p> <ul> <li> <p>Addresses with state changes (storage, balance, nonce, or code).</p> </li> <li> <p>Addresses accessed without state changes, including:</p> <ul> <li>Targets of <code>BALANCE</code>, <code>EXTCODESIZE</code>, <code>EXTCODECOPY</code>, <code>EXTCODEHASH</code> opcodes</li> <li>Targets of <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code> (even if they revert; see <a href="https://wg-eips.ritovision.com/7928/#gas-validation-before-state-access">Gas Validation Before State Access</a> for inclusion conditions)</li> <li>Target addresses of <code>CREATE</code>/<code>CREATE2</code> if the target account is accessed</li> <li>Deployed contract addresses from calls with initcode to empty addresses (e.g., calling <code>0x0</code> with initcode)</li> <li>Transaction sender and recipient addresses (even for zero-value transfers)</li> <li>COINBASE address if the block contains transactions or withdrawals to the COINBASE address</li> <li>Beneficiary addresses for <code>SELFDESTRUCT</code></li> <li>System contract addresses accessed during pre/post-execution; the system caller address, <code>SYSTEM_ADDRESS</code> (<code>0xfffffffffffffffffffffffffffffffffffffffe</code>), MUST NOT be included unless it experiences state access itself</li> <li>Withdrawal recipient addresses, regardless of whether the withdrawal amount is non-zero</li> <li>Precompiled contracts when called or accessed</li> </ul> </li> </ul> <p>Addresses with no state changes <strong>MUST</strong> still be present with empty change lists.</p> <p>Entries from an <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> access list <strong>MUST NOT</strong> be included automatically. Only addresses and storage slots that are actually touched or changed during execution are recorded.</p> <h3 id="gas-validation-before-state-access">Gas Validation Before State Access</h3> <p>State-accessing opcodes perform gas validation in two phases:</p> <ul> <li><strong>Pre-state validation</strong>: Gas costs determinable without state access (memory expansion, base opcode cost, warm/cold access cost)</li> <li><strong>Post-state validation</strong>: Gas costs requiring state access (account existence, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation resolution)</li> </ul> <p>Pre-state validation MUST pass before any state access occurs. If pre-state validation fails, the target resource (address or storage slot) is never accessed and MUST NOT be included in the BAL.</p> <p>Once pre-state validation passes, the target is accessed and included in the BAL. Post-state costs are then calculated; their order is implementation-defined since the target has already been accessed.</p> <p>The following table specifies pre-state validation costs in addition to the base opcode cost (gas constants as defined in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>):</p> <table><thead><tr><th>Instruction</th><th>Pre-state Validation</th></tr></thead><tbody> <tr><td><code>BALANCE</code></td><td><code>access_cost</code></td></tr> <tr><td><code>SELFBALANCE</code></td><td>None (accesses current contract, always warm)</td></tr> <tr><td><code>EXTCODESIZE</code></td><td><code>access_cost</code></td></tr> <tr><td><code>EXTCODEHASH</code></td><td><code>access_cost</code></td></tr> <tr><td><code>EXTCODECOPY</code></td><td><code>access_cost</code> + <code>memory_expansion</code></td></tr> <tr><td><code>CALL</code></td><td><code>access_cost</code> + <code>memory_expansion</code> + <code>GAS_CALL_VALUE</code> (if value &gt; 0)</td></tr> <tr><td><code>CALLCODE</code></td><td><code>access_cost</code> + <code>memory_expansion</code> + <code>GAS_CALL_VALUE</code> (if value &gt; 0)</td></tr> <tr><td><code>DELEGATECALL</code></td><td><code>access_cost</code> + <code>memory_expansion</code></td></tr> <tr><td><code>STATICCALL</code></td><td><code>access_cost</code> + <code>memory_expansion</code></td></tr> <tr><td><code>CREATE</code></td><td><code>memory_expansion</code> + <code>INITCODE_WORD_COST</code> + <code>GAS_CREATE</code></td></tr> <tr><td><code>CREATE2</code></td><td><code>memory_expansion</code> + <code>INITCODE_WORD_COST</code> + <code>GAS_KECCAK256_WORD</code> + <code>GAS_CREATE</code></td></tr> <tr><td><code>SLOAD</code></td><td><code>access_cost</code></td></tr> <tr><td><code>SSTORE</code></td><td>More than <code>GAS_CALL_STIPEND</code> available</td></tr> <tr><td><code>SELFDESTRUCT</code></td><td><code>GAS_SELF_DESTRUCT</code> + <code>access_cost</code></td></tr> </tbody></table> <p>Where:</p> <ul> <li><code>access_cost</code>: For account-accessing opcodes: <code>COLD_ACCOUNT_ACCESS_COST</code> if cold, <code>WARM_STORAGE_READ_COST</code> if warm. For storage-accessing opcodes (<code>SLOAD</code>): <code>COLD_SLOAD_COST</code> if cold, <code>WARM_STORAGE_READ_COST</code> if warm.</li> <li><code>memory_expansion</code>: Gas cost to expand memory for input/output regions</li> </ul> <p>Post-state costs (e.g., <code>GAS_NEW_ACCOUNT</code> for calls to empty accounts, <code>GAS_SELF_DESTRUCT_NEW_ACCOUNT</code> if beneficiary does not exist) do not affect BAL inclusion since the target has already been accessed.</p> <h4 id="eip-7702-delegation">EIP-7702 Delegation</h4> <p>When a call target has an <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation, the target is accessed to resolve the delegation. If a delegation exists, the delegated address requires its own <code>access_cost</code> check before being accessed. If this check fails, the delegated address MUST NOT appear in the BAL, though the original call target is included (having been accessed to resolve the delegation).</p> <p>Note: Delegated accounts cannot be empty, so <code>GAS_NEW_ACCOUNT</code> never applies when resolving delegations.</p> <h4 id="sstore">SSTORE</h4> <p><code>SSTORE</code> performs an implicit read of the current storage value for gas calculation. The <code>GAS_CALL_STIPEND</code> check prevents this state access when operating within the call stipend. If <code>SSTORE</code> fails this check, the storage slot MUST NOT appear in <code>storage_reads</code> or <code>storage_changes</code>.</p> <h3 id="ordering-and-determinism">Ordering and Determinism</h3> <p>The following ordering rules <strong>MUST</strong> apply:</p> <ul> <li><strong>Accounts</strong>: Lexicographic by address</li> <li><strong>storage_changes</strong>: Slots lexicographic by storage key; within each slot, changes by block access index (ascending)</li> <li><strong>storage_reads</strong>: Lexicographic by storage key</li> <li><strong>balance_changes, nonce_changes, code_changes</strong>: By block access index (ascending)</li> </ul> <h3 id="blockaccessindex-assignment">BlockAccessIndex Assignment</h3> <p><code>BlockAccessIndex</code> values <strong>MUST</strong> be assigned as follows:</p> <ul> <li><code>0</code> for <strong>pre‑execution</strong> system contract calls.</li> <li><code>1 … n</code> for transactions (in block order).</li> <li><code>n + 1</code> for <strong>post‑execution</strong> system contract calls.</li> </ul> <h3 id="recording-semantics-by-change-type">Recording Semantics by Change Type</h3> <h4 id="storage">Storage</h4> <ul> <li> <p><strong>Writes include:</strong></p> <ul> <li>Any value change (post‑value ≠ pre‑value).</li> <li><strong>Zeroing</strong> a slot (pre‑value exists, post‑value is zero).</li> </ul> </li> <li> <p><strong>Reads include:</strong></p> <ul> <li>Slots accessed via <code>SLOAD</code> that are not written.</li> <li>Slots written with unchanged values (i.e., <code>SSTORE</code> where post-value equals pre-value, also known as "no-op writes").</li> </ul> </li> </ul> <p>Note: Implementations MUST check the pre-transaction value to correctly distinguish between actual writes and no-op writes.</p> <h4 id="balance-balance-changes">Balance (<code>balance_changes</code>)</h4> <p>Record <strong>post‑transaction</strong> balances (<code>uint256</code>) for:</p> <ul> <li>Transaction <strong>senders</strong> (gas + value).</li> <li>Transaction <strong>recipients</strong> (only if <code>value &gt; 0</code>).</li> <li>CALL/CALLCODE <strong>senders</strong> (value).</li> <li>CALL/CALLCODE <strong>recipients</strong> (only if <code>value &gt; 0</code>).</li> <li>CREATE/CREATE2 recipients (only if <code>value &gt; 0</code>).</li> <li><strong>COINBASE</strong> (rewards + fees).</li> <li><strong>SELFDESTRUCT/SENDALL</strong> beneficiaries.</li> <li><strong>Withdrawal recipients</strong> (system withdrawals, <a href="https://wg-eips.ritovision.com/4895/">EIP-4895</a>).</li> </ul> <p>For unaltered account balances:</p> <p>If an account’s balance changes during a transaction, but its post-transaction balance is equal to its pre-transaction balance, then the change <strong>MUST NOT</strong> be recorded in <code>balance_changes</code>. The sender and recipient address <strong>MUST</strong> be included in <code>AccountChanges</code>.</p> <p>The following special cases require addresses to be included with empty changes if no other state changes occur:</p> <ul> <li>Zero-value transfer recipients</li> <li>Calling a same-transaction SELFDESTRUCT on an address that had a zero pre-transaction balance</li> </ul> <p>Zero-value block reward recipients <strong>MUST NOT</strong> trigger a balance change in the block access list and <strong>MUST NOT</strong> cause the recipient address to be included as a read (e.g. without changes). Zero-value block reward recipients <strong>MUST</strong> only be included with a balance change in blocks where the reward is greater than zero.</p> <h4 id="code">Code</h4> <p>Track <strong>post‑transaction runtime bytecode</strong> for deployed or modified contracts, and <strong>delegation indicators</strong> for successful delegations as defined in <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>.</p> <h4 id="nonce">Nonce</h4> <p>Record <strong>post‑transaction nonces</strong> for:</p> <ul> <li>EOA senders.</li> <li>Contracts that performed a successful <code>CREATE</code> or <code>CREATE2</code>.</li> <li>Deployed contracts.</li> <li><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorities.</li> </ul> <h3 id="edge-cases-normative">Edge Cases (Normative)</h3> <ul> <li><strong>COINBASE / Fee Recipient:</strong> The COINBASE address <strong>MUST</strong> be included if it experiences any state change. It <strong>MUST NOT</strong> be included for blocks with no transactions, provided there are no other state changes (e.g., from <a href="https://wg-eips.ritovision.com/4895/">EIP-4895</a> withdrawals). If the COINBASE reward is zero, the COINBASE address <strong>MUST</strong> be included as a <em>read</em>.</li> <li><strong>Precompiled contracts:</strong> Precompiles <strong>MUST</strong> be included when accessed. If a precompile receives value, it is recorded with a balance change. Otherwise, it is included with empty change lists.</li> <li><strong>SENDALL:</strong> For positive-value selfdestructs, the sender and beneficiary are recorded with a balance change.</li> <li><strong>SELFDESTRUCT (in-transaction):</strong> Accounts destroyed within a transaction <strong>MUST</strong> be included in <code>AccountChanges</code> without nonce or code changes. However, if the account had a positive balance pre-transaction, the balance change to zero <strong>MUST</strong> be recorded. Storage keys within the self-destructed contracts that were modified or read <strong>MUST</strong> be included as a <code>storage_reads</code> entry.</li> <li><strong>Accessed but unchanged:</strong> Include the address with empty changes (e.g., targets of <code>EXTCODEHASH</code>, <code>EXTCODESIZE</code>, <code>BALANCE</code>, <code>STATICCALL</code>, etc.).</li> <li><strong>Zero‑value transfers / Unchanged balance in transaction:</strong> Include the address; omit from <code>balance_changes</code>.</li> <li><strong>Gas refunds:</strong> Record the <strong>final</strong> balance of the sender after each transaction.</li> <li><strong>Block rewards:</strong> Record the <strong>final</strong> balance of the fee recipient after each transaction.</li> <li><strong>Exceptional halts:</strong> Record the <strong>final</strong> nonce and balance of the sender, and the <strong>final</strong> balance of the fee recipient after each transaction. State changes from the reverted call are discarded, but all accessed addresses <strong>MUST</strong> be included. If no changes remain, addresses are included with empty lists; if storage was read, the corresponding keys <strong>MUST</strong> appear in <code>storage_reads</code>.</li> <li><strong>Pre‑execution system contract calls:</strong> All state changes <strong>MUST</strong> use <code>block_access_index = 0</code>.</li> <li><strong>Post‑execution system contract calls:</strong> All state changes <strong>MUST</strong> use <code>block_access_index = len(transactions) + 1</code>.</li> <li><strong>EIP-7702 Delegations:</strong> The authority address <strong>MUST</strong> be included with nonce and code changes after any successful delegation set, update, or clear. If authorization fails after the authority address has been loaded and added to <code>accessed_addresses</code> (per <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>), it <strong>MUST</strong> still be included with an empty change set; if authorization fails before the authority is loaded, it <strong>MUST NOT</strong> be included. The delegation target <strong>MUST NOT</strong> be included during delegation creation or modification and MUST only be included once it is actually loaded as an execution target (e.g., via <code>CALL</code>/<code>CALLCODE</code>/<code>DELEGATECALL</code>/<code>STATICCALL</code> under authority execution).</li> <li><strong>EIP‑4895 (Consensus layer withdrawals):</strong> Recipients are recorded with their final balance after the withdrawal.</li> <li><strong>EIP‑2935 (block hash):</strong> Record system contract storage diffs of the <strong>single</strong> updated storage slot in the ring buffer.</li> <li><strong>EIP‑4788 (beacon root):</strong> Record system contract storage diffs of the <strong>two</strong> updated storage slots in the ring buffer.</li> <li><strong>EIP‑7002 (withdrawals):</strong> Record system contract storage diffs of storage slots <strong>0–3</strong> (4 slots) after the dequeuing call.</li> <li><strong>EIP‑7251 (consolidations):</strong> Record system contract storage diffs of storage slots <strong>0–3</strong> (4 slots) after the dequeuing call.</li> </ul> <h3 id="engine-api">Engine API</h3> <p>The Engine API is extended with new structures and methods to support block-level access lists:</p> <p><strong>ExecutionPayloadV4</strong> extends ExecutionPayloadV3 with:</p> <ul> <li><code>blockAccessList</code>: RLP-encoded block access list</li> </ul> <p><strong>engine_newPayloadV5</strong> validates execution payloads:</p> <ul> <li>Accepts <code>ExecutionPayloadV4</code> structure</li> <li>Validates that computed access list matches provided <code>blockAccessList</code></li> <li>Returns <code>INVALID</code> if access list is malformed or doesn't match</li> </ul> <p><strong>engine_getPayloadV6</strong> builds execution payloads:</p> <ul> <li>Returns <code>ExecutionPayloadV4</code> structure</li> <li>Collects all account accesses and state changes during transaction execution</li> <li>Populates <code>blockAccessList</code> field with RLP-encoded access list</li> </ul> <p><strong>Block processing flow:</strong></p> <p>When processing a block:</p> <ol> <li>The EL receives the BAL in the ExecutionPayload</li> <li>The EL computes <code>block_access_list_hash = keccak256(blockAccessList)</code> and includes it in the block header</li> <li>The EL executes the block and generates the actual BAL</li> <li>If the generated BAL doesn't match the provided BAL, the block is invalid (the hash in the header would be wrong)</li> </ol> <p>The execution layer provides the RLP-encoded <code>blockAccessList</code> to the consensus layer via the Engine API. The consensus layer then computes the SSZ <code>hash_tree_root</code> for storage in the <code>ExecutionPayload</code>.</p> <p><strong>Retrieval methods</strong> for historical BALs:</p> <ul> <li><code>engine_getPayloadBodiesByHashV2</code>: Returns <code>ExecutionPayloadBodyV2</code> objects containing transactions, withdrawals, and <code>blockAccessList</code></li> <li><code>engine_getPayloadBodiesByRangeV2</code>: Returns <code>ExecutionPayloadBodyV2</code> objects containing transactions, withdrawals, and <code>blockAccessList</code></li> </ul> <p>The <code>blockAccessList</code> field contains the RLP-encoded BAL or <code>null</code> for pre-Amsterdam blocks or when data has been pruned.</p> <p>The EL MUST retain BALs for at least the duration of the weak subjectivity period (<code>=3533 epochs</code>) to support synchronization with re-execution after being offline for less than the WSP.</p> <h3 id="state-transition-function">State Transition Function</h3> <p>The state transition function must validate that the provided BAL matches the actual state accesses:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">execution_payload</span><span>,</span><span class="z-variable z-parameter z-function"> block_header</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1. Compute hash from received BAL and set in header</span></span> <span class="giallo-l"><span> block_header</span><span>.</span><span>block_access_list_hash</span><span class="z-keyword"> =</span><span> keccak</span><span>(</span><span>execution_payload</span><span>.</span><span>blockAccessList</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2. Execute block and collect actual accesses</span></span> <span class="giallo-l"><span> actual_bal</span><span class="z-keyword"> =</span><span> execute_and_collect_accesses</span><span>(</span><span>execution_payload</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 3. Verify actual execution matches provided BAL</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If this fails, the block is invalid (the hash in the header would be wrong)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> rlp</span><span>.</span><span>encode</span><span>(</span><span>actual_bal</span><span>)</span><span class="z-keyword"> ==</span><span> execution_payload</span><span>.</span><span>blockAccessList</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> execute_and_collect_accesses</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Execute block and collect all state accesses into BAL format</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span> accesses</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pre-execution system contracts (block_access_index = 0)</span></span> <span class="giallo-l"><span> track_system_contracts_pre</span><span>(</span><span>block</span><span>,</span><span> accesses</span><span>,</span><span class="z-variable"> block_access_index</span><span class="z-keyword">=</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Execute transactions (block_access_index = 1..n)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>block</span><span>.</span><span>transactions</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> execute_transaction</span><span>(</span><span>tx</span><span>)</span></span> <span class="giallo-l"><span> track_state_changes</span><span>(</span><span>tx</span><span>,</span><span> accesses</span><span>,</span><span class="z-variable"> block_access_index</span><span class="z-keyword">=</span><span>i</span><span class="z-keyword">+</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Withdrawals and post-execution (block_access_index = len(txs) + 1)</span></span> <span class="giallo-l"><span> post_index</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>block</span><span>.</span><span>transactions</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> withdrawal</span><span class="z-keyword"> in</span><span> block</span><span>.</span><span>withdrawals</span><span>:</span></span> <span class="giallo-l"><span> apply_withdrawal</span><span>(</span><span>withdrawal</span><span>)</span></span> <span class="giallo-l"><span> track_balance_change</span><span>(</span><span>withdrawal</span><span>.</span><span>address</span><span>,</span><span> accesses</span><span>,</span><span> post_index</span><span>)</span></span> <span class="giallo-l"><span> track_system_contracts_post</span><span>(</span><span>block</span><span>,</span><span> accesses</span><span>,</span><span> post_index</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Convert to BAL format and sort</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> build_bal</span><span>(</span><span>accesses</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> track_state_changes</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>,</span><span class="z-variable z-parameter z-function"> accesses</span><span>,</span><span class="z-variable z-parameter z-function"> block_access_index</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Track all state changes from a transaction</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> addr</span><span class="z-keyword"> in</span><span> get_touched_addresses</span><span>(</span><span>tx</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> addr</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> accesses</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span class="z-keyword"> =</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span><span> {</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> slot -&gt; [(index, value)]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">storage_reads</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span><span class="z-support"> set</span><span>(</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">balance_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span><span> [</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">nonce_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span><span> [</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">code_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track storage changes</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> slot</span><span>,</span><span> value</span><span class="z-keyword"> in</span><span> get_storage_writes</span><span>(</span><span>addr</span><span>)</span><span>.</span><span>items</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> slot</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>[</span><span>slot</span><span>]</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>[</span><span>slot</span><span>]</span><span>.</span><span>append</span><span>(</span><span>(</span><span>block_access_index</span><span>,</span><span> value</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track reads (slots accessed but not written)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> slot</span><span class="z-keyword"> in</span><span> get_storage_reads</span><span>(</span><span>addr</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> slot</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_reads</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>.</span><span>add</span><span>(</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track balance, nonce, code changes</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> balance_changed</span><span>(</span><span>addr</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">balance_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>.</span><span>append</span><span>(</span><span>(</span><span>block_access_index</span><span>,</span><span> get_balance</span><span>(</span><span>addr</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> nonce_changed</span><span>(</span><span>addr</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">nonce_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>.</span><span>append</span><span>(</span><span>(</span><span>block_access_index</span><span>,</span><span> get_nonce</span><span>(</span><span>addr</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> code_changed</span><span>(</span><span>addr</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> accesses</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">code_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>.</span><span>append</span><span>(</span><span>(</span><span>block_access_index</span><span>,</span><span> get_code</span><span>(</span><span>addr</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> build_bal</span><span>(</span><span class="z-variable z-parameter z-function">accesses</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Convert collected accesses to BAL format</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span> bal</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> addr</span><span class="z-keyword"> in</span><span class="z-support"> sorted</span><span>(</span><span>accesses</span><span>.</span><span>keys</span><span>(</span><span>)</span><span>)</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Sort addresses lexicographically</span></span> <span class="giallo-l"><span> data</span><span class="z-keyword"> =</span><span> accesses</span><span>[</span><span>addr</span><span>]</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Format storage changes: [slot, [[index, value], ...]]</span></span> <span class="giallo-l"><span> storage_changes</span><span class="z-keyword"> =</span><span> [</span><span>[</span><span>slot</span><span>,</span><span class="z-support"> sorted</span><span>(</span><span>changes</span><span>)</span><span>]</span><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> slot</span><span>,</span><span> changes</span><span class="z-keyword"> in</span><span class="z-support"> sorted</span><span>(</span><span>data</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_writes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>.</span><span>items</span><span>(</span><span>)</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Account entry: [address, storage_changes, reads, balance_changes, nonce_changes, code_changes]</span></span> <span class="giallo-l"><span> bal</span><span>.</span><span>append</span><span>(</span><span>[</span></span> <span class="giallo-l"><span> addr</span><span>,</span></span> <span class="giallo-l"><span> storage_changes</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> sorted</span><span>(</span><span class="z-support">list</span><span>(</span><span>data</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">storage_reads</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>)</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> sorted</span><span>(</span><span>data</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">balance_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> sorted</span><span>(</span><span>data</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">nonce_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> sorted</span><span>(</span><span>data</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">code_changes</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> ]</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> bal</span></span></code></pre> <p>The BAL MUST be complete and accurate. Missing or spurious entries invalidate the block. Spurious entries MAY be detected by validating BAL indices, which MUST never be higher than <code>len(transactions) + 1</code>.</p> <p>Clients MAY invalidate immediately if any transaction exceeds declared state.</p> <p>Clients MUST store BALs separately from blocks and make them available via the engine API.</p> <h3 id="concrete-example">Concrete Example</h3> <p>Example block:</p> <p><strong>Pre-execution:</strong></p> <ul> <li>EIP-2935: Store parent hash at block hash contract (<code>0x0000F90827F1C53a10cb7A02335B175320002935</code>)</li> <li>EIP-7002: Omitted for simplicity.</li> </ul> <p><strong>Transactions:</strong></p> <ol> <li>Alice (0xaaaa...) sends 1 ETH to Bob (0xbbbb...), checks balance of 0x2222...</li> <li>Charlie (0xcccc...) calls factory (0xffff...) deploying contract at 0xdddd...</li> </ol> <p><strong>Post-execution:</strong></p> <ul> <li>Withdrawal of 100 ETH to Eve (0xabcd...)</li> <li>EIP-7002 and EIP-7251 omitted for simplicity.</li> </ul> <p>Note: Pre-execution system contract uses block_access_index = 0. Post-execution withdrawal uses block_access_index = 3 (len(transactions) + 1)</p> <p>Resulting BAL (RLP structure):</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>[</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Addresses are sorted lexicographically</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0x0000F90827F1C53a10cb7A02335B175320002935 (Block hash contract)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">0000F90827F1C53a10cb7A02335B175320002935</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span class="z-storage z-type">b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x00</span><span class="z-string">...</span><span class="z-constant">\x0f</span><span class="z-constant">\xa0</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span> [</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">...</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>]</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> slot, [[block_access_index, parent_hash]]</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0x2222... (Address checked by Alice)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">2222</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes (no change, just checked)</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xaaaa... (Alice - sender tx 0)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">aaaa</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span class="z-invalid z-illegal">29a241a</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes: [[block_access_index, post_balance]]</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 10</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes: [[block_access_index, new_nonce]]</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xabcd... (Eve - withdrawal recipient)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">abcd</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">3</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span class="z-invalid z-illegal">5f5e100</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes: 100 ETH withdrawal</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xbbbb... (Bob - recipient tx 0)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">bbbb</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span>b9aca00</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes: +1 ETH</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xcccc... (Charlie - sender tx 1)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">cccc</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span>bc16d67</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes: after gas</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-constant"> 5</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xdddd... (Deployed contract)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">dddd</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes: new contract nonce</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x60</span><span class="z-constant">\x80</span><span class="z-constant">\x60</span><span class="z-constant">\x40</span><span class="z-string">...</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes: deployed bytecode</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xeeee... (COINBASE)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">eeee</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span class="z-invalid z-illegal">05f5e1</span><span>]</span><span>,</span><span> [</span><span class="z-constant">2</span><span>,</span><span class="z-invalid z-illegal"> 0x</span><span class="z-constant">...</span><span class="z-invalid z-illegal">0bebc2</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes: after tx fees</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> AccountChanges for 0xffff... (Factory contract)</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">ffff</span><span class="z-constant">...</span><span>,</span></span> <span class="giallo-l"><span> [</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_changes</span></span> <span class="giallo-l"><span> [</span><span class="z-storage z-type">b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x00</span><span class="z-string">...</span><span class="z-constant">\x01</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x00</span><span class="z-string">...</span><span class="z-constant">\xdd</span><span class="z-constant">\xdd</span><span class="z-string">...</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>]</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> slot 1, deployed address</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> storage_reads</span></span> <span class="giallo-l"><span> [</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> balance_changes</span></span> <span class="giallo-l"><span> [</span><span>[</span><span class="z-constant">2</span><span>,</span><span class="z-constant"> 5</span><span>]</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce_changes: after CREATE</span></span> <span class="giallo-l"><span> [</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> code_changes</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>RLP-encoded and compressed: ~400-500 bytes.</p> <h2 id="rationale">Rationale</h2> <h3 id="bal-design-choice">BAL Design Choice</h3> <p>This design variant was chosen for several key reasons:</p> <ol> <li> <p><strong>Size vs parallelization</strong>: BALs include all accessed addresses (even unchanged) for complete parallel IO and execution.</p> </li> <li> <p><strong>Storage values for writes</strong>: Post-execution values enable state reconstruction during sync without individual proofs against state root.</p> </li> <li> <p><strong>Overhead analysis</strong>: Historical data shows ~70 KiB average BAL size.</p> </li> <li> <p><strong>Transaction independence</strong>: 60-80% of transactions access disjoint storage slots, enabling effective parallelization. The remaining 20-40% can be parallelized by having post-transaction state diffs.</p> </li> <li> <p><strong>RLP encoding</strong>: Native Ethereum encoding format, maintains compatibility with existing infrastructure.</p> </li> </ol> <h3 id="bal-size-considerations-60m-block-gas-limit">BAL Size Considerations (60m block gas limit)</h3> <p><strong>Average BAL size</strong>: ~72.4 KiB (compressed)</p> <ul> <li>Storage writes: ~29.2 KiB (40.3%)</li> <li>Storage reads: ~18.7 KiB (25.8%)</li> <li>Balance diffs: ~6.7 KiB (9.2%)</li> <li>Nonce diffs: ~1.1 KiB (1.5%)</li> <li>Code diffs: ~1.2 KiB (1.6%)</li> <li>Account addresses (with diffs): ~7.7 KiB (10.7%)</li> <li>Touched-only addresses: ~3.5 KiB (4.8%)</li> <li>RLP encoding overhead: ~4.4 KiB (6.1%)</li> </ul> <p>Smaller than current worst-case calldata blocks.</p> <p>An empirical analysis has been done <a href="https://wg-eips.ritovision.com/7928/assets/bal_size_analysis/">here</a>. An updated analysis for a 60 million block gas limit can be found <a href="https://wg-eips.ritovision.com/7928/assets/bal_size_analysis_60m/">here</a>.</p> <h3 id="asynchronous-validation">Asynchronous Validation</h3> <p>BAL verification occurs alongside parallel IO and EVM operations without delaying block processing.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal requires changes to the block structure and engine API that are not backwards compatible and require a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="validation-overhead">Validation Overhead</h3> <p>Validating access lists and balance diffs adds validation overhead but is essential to prevent acceptance of invalid blocks.</p> <h3 id="block-size">Block Size</h3> <p>Increased block size impacts propagation but overhead (~70 KiB average) is reasonable for performance gains.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-27T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper Qi Zhouhttps://github.com/qizhou https://wg-eips.ritovision.com/7923/

Linearize Memory Costing and replace the current quadratic formula with a page-based cost model.

<h2 id="abstract">Abstract</h2> <p>This EIP replaces the quadratic memory model in the EVM with a linear, page-based costing model. Memory is virtually addressable. Page allocation is included in the cost model. After applying this EIP, memory limits are invariant to the state of the message call stack.</p> <h2 id="motivation">Motivation</h2> <p>The EVM currently uses a quadratic pricing model for its memory. This was originally put in place to defend against DoS attacks. However, the memory model has several drawbacks.</p> <ol> <li>It is anachronistic. Even at a gas limit of 30 million gas, users can only use 3MB of memory in a message call (and that burns all gas). Since the quadratic term for memory expansion starts kicking in at 724 bytes, users use much less memory in practice. To use even 64KB of memory -- the amount of memory available to a PC from the early 80's -- costs 14336 gas!</li> <li>The quadratic model makes it difficult to reason about how much memory a transaction can allocate. It requires solving an optimization problem which involves computing how many message calls are available to recurse into based on the call stack limit (and, post <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>, the 63/64ths rule), and then maximizing the memory used per message call.</li> <li>The quadratic model makes it impossible for high-level smart contracts languages to get the benefits of virtual memory. Most modern programming languages maintain what is known as the "heap" and the "call stack". The heap is used to allocate objects which live past the lifetime of their current function frame, whereas the call stack is used to allocate objects which live in the current function frames. Importantly, the call stack starts at the top of memory and grows down, while the heap starts at the bottom of memory and grows up, thus the language implementation does not need to worry about the two regions of memory interfering with each other. This is a feature which is enabled by virtual, paged memory, which has been present in operating systems since the early 90's. However, smart contract languages like Vyper and Solidity are not able to implement this, leading to inefficiencies in their memory models.</li> </ol> <p>This EIP proposes a linear costing model which more closely reflects the hardware of today, which is hierarchical ("hot" memory is much faster to access than "cold" memory), and virtually addressed (memory does not need to be allocated contiguously, but is rather served "on-demand" by the operating system).</p> <p>First, some preliminaries. A page is 4096 bytes on most architectures. Given a memory address, its page is simple to compute by masking out the rightmost 12 bits.</p> <p>There are two factors which contribute to "cold" memory (i.e. not-recently-used) being slower: CPU cache and TLB (Translation Lookaside Buffer) cache. The CPU cache is a least-recently-used memory cache, which is significantly faster than fetching all the way from RAM. The TLB is usually some hash table which maps virtual pages (used by the user) to physical pages in RAM. "Thrashing", or accessing a lot of different memory addresses, does two things: it pushes memory out of the hot cache and into cold memory, and it pushes pages out of the TLB cache. For this reason, it is worth limiting the amount of memory that is available to a transaction to memory which can be held in the hot set.</p> <p>This EIP uses a virtual addressing scheme so that memory pages are not allocated until they are actually accessed.</p> <p>Notably, the data structures used for costing memory do not need to be part of the memory implementation itself, which suggests an elegant implementation using the POSIX <code>mmap</code> syscall (or, its counterpart on Windows, <code>VirtualAlloc</code>).</p> <p>The implementation can be approached in two ways. The first way is to implement the virtual addressing "manually". This is intended for systems without <code>mmap</code> or a virtual addressing capability. The implementation needs to maintain a map from <code>map[page_id -&gt; char[4096]]</code>, where <code>page_id</code> is an integer, computed as <code>memory_address &gt;&gt; 12</code>. (On reads or writes which cross page boundaries, the implementation needs to load both pages and combine the result of the read or write across both pages).</p> <p>The other implementation is easier, for systems with <code>mmap</code> or a similar facility. To hold the actual data of the memory, the implementation <code>mmap</code>s a <code>2**32</code> byte region of memory. Then, memory operations can be implemented simply as reads or writes against this buffer. (With an anonymous <code>mmap</code>, the operating system will not allocate the entire buffer up-front, rather, it will allocate pages "on demand", as they are touched). The <code>pages</code> map is still necessary, but it doesn't hold any data, it is just to track which pages have been allocated, for pricing purposes. In this implementation, there are two data structures: <code>memory char[2**32]</code> and <code>allocated_pages set[page_id]</code>. The <code>memory</code> data structure is only used for memory reads and writes. The <code>allocated_pages</code> is only used for gas costing.</p> <h2 id="specification">Specification</h2> <p>Consider the following constants:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">ALLOCATE_PAGE_COST</span><span class="z-keyword"> =</span><span class="z-constant"> 100</span></span> <span class="giallo-l"><span class="z-constant">PAGE_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 4096</span></span> <span class="giallo-l"><span class="z-constant">MAXIMUM_MEMORY_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 64</span><span class="z-keyword"> *</span><span class="z-constant"> 1024</span><span class="z-keyword"> *</span><span class="z-constant"> 1024</span></span></code></pre> <p>The memory costing algorithm is changed as follows:</p> <ol> <li>For each page touched by an instruction, charge <code>ALLOCATE_PAGE_COST</code> gas if it has not been touched before in this message call, except for page 0 which is free.</li> <li>The base gas cost for all memory instructions, e.g. <code>MLOAD</code> and <code>MSTORE</code>, remains the same, at 3.</li> <li>The linear and quadratic terms in the memory expansion cost are removed.</li> </ol> <p>The behavior of <code>msize</code> remains the same. It returns the maximum byte touched by any memory instruction, rounded up by 32.</p> <p>Memory addresses are restricted to 32-bits. If an address is larger than <code>2**32 - 1</code>, an exceptional halt should be raised.</p> <p>A transaction-global memory limit is imposed. If the number of pages allocated in a transaction exceeds <code>MAXIMUM_MEMORY_SIZE // PAGE_SIZE</code> (i.e., 16384), an exceptional halt should be raised.</p> <h2 id="rationale">Rationale</h2> <p>Benchmarks were performed on a 2019-era CPU, with the ability to <code>keccak256</code> around 256MB/s, giving it a gas-to-ns ratio of 20 ns per 1 gas (given that <code>keccak256</code> costs 6 gas per 32 bytes). The following benchmarks were performed:</p> <ul> <li>Time to allocate a fresh page: 1-2us</li> <li>Time to randomly read a byte from a 2MB range: 1.8ns</li> <li>Time to randomly read a byte from a 32MB range: 7ns</li> <li>Time to randomly read a byte from a 4GB range: 40ns</li> <li>Time to update a hashmap with 512 items: 8ns</li> <li>Time to update a hashmap with 8192 items: 9ns</li> <li>Time to update a hashmap with 5mm items: 108ns</li> <li>Time to execute the <code>mmap</code> syscall: 230ns</li> </ul> <p>These suggest the following prices:</p> <ul> <li>100 gas to allocate a page</li> </ul> <p>Note that the cost to execute <code>mmap</code> (~11 gas) is already well-paid for by the base cost of the CALL series of instructions (100 gas). For the same reason, page 0 is free, since the CALL overhead already pays for the initial page allocation. This also improves backwards compatibility, since it keeps the cost for any access within the first page either the same as or lower than current pricing.</p> <p>There is a desire among client implementations to be able to enforce global limits separately from the gas limit due to DoS reasons. For example, RPC providers may be designed to allow many concurrent <code>eth_call</code> computations with a much higher gas limit than on mainnet. Not implicitly tying the memory limit to the gas limit results in one less vector for misconfiguration. That is not to say that in the future, a clean formula cannot be created which allows the memory limit to scale with future hardware improvements (e.g., proportional to the sqrt of the gas limit), but to limit the scope of things that need to be reasoned about for this EIP, the hard limit is introduced.</p> <p>The hard limit is specified as a transaction-global limit rather than a message-call limit. That is, a reasonable alternative could be to limit the number of pages that can be allocated in a given message call, e.g., to 2MB, but it doesn't significantly improve implementation complexity.</p> <p>On keeping the semantics of <code>MSIZE</code> the same: With users expected to use the full address space instead of growing it linearly, the rationale for keeping <code>MSIZE</code> semantics the same is to avoid breaking backwards compatibility with existing contracts which expect it to grow linearly. New contracts taking advantage of the new virtual addressing scheme should not rely on <code>MSIZE</code> for memory allocation.</p> <p>A hard limit of <code>2**32</code> bytes was imposed on the addressing. This makes it simpler for modern 64-bit computers to allocate that much virtual address space, given that clients run on a diverse set of operating systems and architectures which have different virtual memory limits per process. This could be revisited in the future, for instance if gas limits or client memory sizes substantially increase.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Addressed in Security Considerations section. No backwards compatibility is broken, although some contracts that previously ran out of gas may now successfully complete.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="reference-implementation">Reference Implementation</h2> <p>A ~60-line reference implementation is provided below. It is implemented as a patch against the <code>py-evm</code> codebase at commit ethereum/py-evm@fec63b8c4b9dad9fcb1022c48c863bdd584820c6. (This is a reference implementation, it does not, for example, contain fork choice rules).</p> <pre class="giallo z-code"><code data-lang="diff"><span class="giallo-l"><span class="z-meta z-diff z-header">diff --git a/eth/vm/computation.py b/eth/vm/computation.py</span></span> <span class="giallo-l"><span>index bf34fbee..db85aee7 100644</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-from-file">---</span><span class="z-meta z-diff z-header z-from-file"> a/eth/vm/computation.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-to-file">+++</span><span class="z-meta z-diff z-header z-to-file"> b/eth/vm/computation.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -454,34 +454,40</span><span class="z-meta z-diff z-range"> @@</span><span> class BaseComputation(ComputationAPI, Configurable):</span></span> <span class="giallo-l"><span> validate_uint256(start_position, title=&quot;Memory start position&quot;)</span></span> <span class="giallo-l"><span> validate_uint256(size, title=&quot;Memory size&quot;)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> before_size = ceil32(len(self._memory))</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> after_size = ceil32(start_position + size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> before_cost = memory_gas_cost(before_size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> after_cost = memory_gas_cost(after_size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> if self.logger.show_debug2:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self.logger.debug2(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> f&quot;MEMORY: size ({before_size} -&gt; {after_size}) | &quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> f&quot;cost ({before_cost} -&gt; {after_cost})&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> if size:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> if before_cost &lt; after_cost:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> gas_fee = after_cost - before_cost</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._gas_meter.consume_gas(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> gas_fee,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> reason=&quot; &quot;.join(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> (</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> &quot;Expanding memory&quot;,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> str(before_size),</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> &quot;-&gt;&quot;,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> str(after_size),</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> ),</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._memory.extend(start_position, size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if size == 0:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> ALLOCATE_PAGE_COST = 100</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> LOWER_BITS = 12 # bits ignored for page calculations</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> PAGE_SIZE = 4096</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> assert 2**LOWER_BITS == PAGE_SIZE # sanity check</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> MAXIMUM_MEMORY_SIZE = 64 * 1024 * 1024</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> TRANSACTION_MAX_PAGES = MAXIMUM_MEMORY_SIZE // PAGE_SIZE</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> end_position = start_position + size - 1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> start_page = start_position &gt;&gt; LOWER_BITS</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> end_page = end_position &gt;&gt; LOWER_BITS</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> for page in range(start_page, end_page + 1):</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if page not in self._memory.pages:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if self.transaction_context.num_pages &gt;= TRANSACTION_MAX_PAGES:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> raise VMError(&quot;Out Of Memory&quot;)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.transaction_context.num_pages += 1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> reason = f&quot;Allocating page {hex(page &lt;&lt; LOWER_BITS)}&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self._gas_meter.consume_gas(ALLOCATE_PAGE_COST, reason)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self._memory.pages[page] = True</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def memory_write(self, start_position: int, size: int, value: bytes) -&gt; None:</span></span> <span class="giallo-l"><span> return self._memory.write(start_position, size, value)</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header">diff --git a/eth/vm/forks/frontier/computation.py b/eth/vm/forks/frontier/computation.py</span></span> <span class="giallo-l"><span>index 51666ae0..443f82b5 100644</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-from-file">---</span><span class="z-meta z-diff z-header z-from-file"> a/eth/vm/forks/frontier/computation.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-to-file">+++</span><span class="z-meta z-diff z-header z-to-file"> b/eth/vm/forks/frontier/computation.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -29,6 +29,7</span><span class="z-meta z-diff z-range"> @@</span><span> from eth.exceptions import (</span></span> <span class="giallo-l"><span> InsufficientFunds,</span></span> <span class="giallo-l"><span> OutOfGas,</span></span> <span class="giallo-l"><span> StackDepthLimit,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> VMError,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> from eth.vm.computation import (</span></span> <span class="giallo-l"><span> BaseComputation,</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -87,12 +88,21</span><span class="z-meta z-diff z-range"> @@</span><span> class FrontierComputation(BaseComputation):</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> state.touch_account(message.storage_address)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> computation = cls.apply_computation(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> state,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> message,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> transaction_context,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> parent_computation=parent_computation,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> # implement transaction-global memory limit</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> num_pages_anchor = transaction_context.num_pages</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> try:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> computation = cls.apply_computation(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> state,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> message,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> transaction_context,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> parent_computation=parent_computation,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> finally:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> # &quot;deallocate&quot; all the pages allocated in the child computation</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> # sanity check an invariant:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> allocated_pages = len(computation._memory.pages)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> assert transaction_context.num_pages == num_pages_anchor + allocated pages</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> transaction_context.num_pages = num_pages_anchor</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if computation.is_error:</span></span> <span class="giallo-l"><span> state.revert(snapshot)</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header">diff --git a/eth/vm/logic/memory.py b/eth/vm/logic/memory.py</span></span> <span class="giallo-l"><span>index 806dbd8b..247b3c74 100644</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-from-file">---</span><span class="z-meta z-diff z-header z-from-file"> a/eth/vm/logic/memory.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-to-file">+++</span><span class="z-meta z-diff z-header z-to-file"> b/eth/vm/logic/memory.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -43,7 +43,7</span><span class="z-meta z-diff z-range"> @@</span><span> def mload(computation: ComputationAPI) -&gt; None:</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def msize(computation: ComputationAPI) -&gt; None:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> computation.stack_push_int(len(computation._memory))</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> computation.stack_push_int(computation._memory.msize)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def mcopy(computation: ComputationAPI) -&gt; None:</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header">diff --git a/eth/vm/memory.py b/eth/vm/memory.py</span></span> <span class="giallo-l"><span>index 2ccfd090..9002b559 100644</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-from-file">---</span><span class="z-meta z-diff z-header z-from-file"> a/eth/vm/memory.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-to-file">+++</span><span class="z-meta z-diff z-header z-to-file"> b/eth/vm/memory.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -1,8 +1,11</span><span class="z-meta z-diff z-range"> @@</span></span> <span class="giallo-l"><span> import logging</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted">import mmap</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span> from eth._utils.numeric import (</span></span> <span class="giallo-l"><span> ceil32,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted">from eth.exceptions import VMError</span></span> <span class="giallo-l"><span> from eth.abc import (</span></span> <span class="giallo-l"><span> MemoryAPI,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -13,52 +16,48</span><span class="z-meta z-diff z-range"> @@</span><span> from eth.validation import (</span></span> <span class="giallo-l"><span> validate_uint256,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> class Memory(MemoryAPI):</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> __slots__ = [&quot;_bytes&quot;]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> __slots__ = (&quot;pages&quot;, &quot;msize&quot;)</span></span> <span class="giallo-l"><span> logger = logging.getLogger(&quot;eth.vm.memory.Memory&quot;)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def __init__(self) -&gt; None:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._bytes = bytearray()</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.memview = mmap.mmap(-1, 2**32, flags=mmap.MAP_PRIVATE | mmap.MAP_ANONYMOUS)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.pages = {0: True} # page 0 is free (per spec)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.msize = 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def extend(self, start_position: int, size: int) -&gt; None:</span></span> <span class="giallo-l"><span> if size == 0:</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> new_size = ceil32(start_position + size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> if new_size &lt;= len(self):</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if start_position + size &gt; self.msize:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.msize = ceil32(start_position + size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> def write(self, start_position: int, size: int, value: bytes) -&gt; None:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if size == 0:</span></span> <span class="giallo-l"><span> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> size_to_extend = new_size - len(self)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> try:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._bytes.extend(bytearray(size_to_extend))</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> except BufferError:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # we can&#39;t extend the buffer (which might involve relocating it) if a</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # memoryview (which stores a pointer into the buffer) has been created by</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # read() and not released. Callers of read() will never try to write to the</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # buffer so we&#39;re not missing anything by making a new buffer and forgetting</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # about the old one. We&#39;re keeping too much memory around but this is still</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> # a net savings over having read() return a new bytes() object every time.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._bytes = self._bytes + bytearray(size_to_extend)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> def __len__(self) -&gt; int:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> return len(self._bytes)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> if start_position + size &gt;= 2**32:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> raise VMError(&quot;Non 32-bit address&quot;)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> def write(self, start_position: int, size: int, value: bytes) -&gt; None:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> if size:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> validate_uint256(start_position)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> validate_uint256(size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> validate_is_bytes(value)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> validate_length(value, length=size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> validate_lte(start_position + size, maximum=len(self))</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> validate_uint256(start_position)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> validate_uint256(size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> validate_is_bytes(value)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> validate_length(value, length=size)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> end_position = start_position + size</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> self._bytes[start_position : start_position + len(value)] = value</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.memview[start_position : end_position] = value</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> # unused</span></span> <span class="giallo-l"><span> def read(self, start_position: int, size: int) -&gt; memoryview:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> return memoryview(self._bytes)[start_position : start_position + size]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> return memoryview(self.memview)[start_position : start_position + size]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def read_bytes(self, start_position: int, size: int) -&gt; bytes:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> return bytes(self._bytes[start_position : start_position + size])</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> return bytes(self.memview[start_position : start_position + size])</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> def copy(self, destination: int, source: int, length: int) -&gt; None:</span></span> <span class="giallo-l"><span> if length == 0:</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -69,5 +68,5</span><span class="z-meta z-diff z-range"> @@</span><span> class Memory(MemoryAPI):</span></span> <span class="giallo-l"><span> validate_uint256(length)</span></span> <span class="giallo-l"><span> validate_lte(max(destination, source) + length, maximum=len(self))</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> buf = memoryview(self._bytes)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> buf = memoryview(self.memview)</span></span> <span class="giallo-l"><span> buf[destination : destination + length] = buf[source : source + length]</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header">diff --git a/eth/vm/transaction_context.py b/eth/vm/transaction_context.py</span></span> <span class="giallo-l"><span>index 79b570e9..5943f897 100644</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-from-file">---</span><span class="z-meta z-diff z-header z-from-file"> a/eth/vm/transaction_context.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-header z-to-file">+++</span><span class="z-meta z-diff z-header z-to-file"> b/eth/vm/transaction_context.py</span></span> <span class="giallo-l"><span class="z-meta z-diff z-range">@@</span><span class="z-meta z-diff z-range"> -36,6 +36,9</span><span class="z-meta z-diff z-range"> @@</span><span> class BaseTransactionContext(TransactionContextAPI):</span></span> <span class="giallo-l"><span> # post-cancun</span></span> <span class="giallo-l"><span> self._blob_versioned_hashes = blob_versioned_hashes or []</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> # eip-7923</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> self.num_pages = 0</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span></span> <span class="giallo-l"><span> def get_next_log_counter(self) -&gt; int:</span></span> <span class="giallo-l"><span> return next(self._log_counter)</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>There are two primary security considerations regarding this EIP.</p> <p>One, does it break existing contracts? That is, do existing contracts depend on memory being restricted?</p> <p>Outside of gas costing, existing contracts may simply execute to completion rather than running out of gas.</p> <p>Two, does this enable memory-based DoS attacks against clients?</p> <p>This requires a maximum-memory usage analysis. Based on a gas limit today of 30mm gas, recursively calling a contract that allocates 256KB of memory in each call stack can allocate 54MB of total memory, which is not substantially different than the 64MB limit proposed in this EIP. Note that the transaction-global memory limit proposed in this EIP provides a useful invariant, which is that future changes to call stack limits will not affect the total amount of memory that can be allocated in a given transaction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/7921/

All `JUMPDEST` bytes become valid `JUMPDEST`

<h2 id="abstract">Abstract</h2> <p>Allow <code>JUMP</code> and <code>JUMPI</code> to arrive at any byte matching <code>JUMPDEST</code> (<code>0x5b</code>), even if that byte is an immediate argument.</p> <h2 id="motivation">Motivation</h2> <p>Immediate arguments are opcode parameters supplied within the code rather than the stack. Currently determining the validity of a <code>JUMPDEST</code> requires determining which bytes are immediate arguments to other opcodes, such as <code>PUSH1</code>. This presents several problems:</p> <ol> <li>Codesize is a linear DoS vector because code must be preprocessed to determine <code>JUMPDEST</code> validity.</li> <li>New opcodes with immediate arguments cannot be safely adopted.</li> <li><code>CODECOPY</code> data spans can invalidate subsequent <code>JUMPDEST</code>.</li> </ol> <p>The rationale for this <code>JUMPDEST</code> validity check is to prevent unintended code execution. However, almost all <code>JUMP</code> and <code>JUMPI</code> target constant destinations. Removing this check allows larger programs and better opcodes. Therefore, the cost of this safety check outweighs the benefit.</p> <h2 id="specification">Specification</h2> <p>When activated, all <code>0x5b</code> bytes are valid <code>JUMPDEST</code> for <code>JUMPI</code> and <code>JUMP</code> opcodes.</p> <h2 id="rationale">Rationale</h2> <p>Removing the check solves several problems while reducing EVM complexity.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Code previously only had one interpretation for disassembly. With this change, a <code>JUMPDEST</code> located inside an immediate argument can cause multiple disassembly interpretations. Usually the interpretations will converge after a few bytes but the length of such a dispute can be unbounded. <code>CODECOPY</code> data has always been difficult to identify. It is recommended that disassemblers provide all possible interpretations in their output in order to reveal possible underhanded functionality.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Current contracts performing dynamic jumps may gain new unintended functionality if it is possible to jump to an immediate argument containing <code>JUMPDEST</code>. It is expected that very few contracts will become vulnerable in this way. Most smart contract programming languages do not even allow dynamic jumps, and of those that do, few will have <code>JUMPDEST</code> in an accessible immediate argument. Therefore it is expected that few contracts will become vulnerable, and for many of them the newly possible codepaths will contain invalid opcodes. A static analysis tool should be developed and made publicly available to test if a contract might become vulnerable, and the program should be run for all current contracts in order to notify projects about potential security issues. Affected programs will have ample time to migrate.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 lightclienthttps://github.com/lightclient https://wg-eips.ritovision.com/7912/

Add additional SWAP and DUP operations for deeper stack access

<h2 id="abstract">Abstract</h2> <p>Add <code>SWAP17</code>-<code>SWAP24</code>, <code>DUP17</code> - <code>DUP24</code>, <code>SWAPN</code>, <code>DUPN</code>, and <code>EXCHANGE</code> instructions. The arbitrary depth operations must be preceded by <code>PUSH1</code> instructions defining operands.</p> <h2 id="motivation">Motivation</h2> <p>Due to the nature of some compilers, deeper stack access is a desirable VM feature. Previous attempts either required code versioning, like the EVM Object Format (EOF), or caused the behavior of some deployed contracts to change, due to the interpretation of new immediates.</p> <p>This is a pragmatic approach to introducing the desired functionality. It reuses instruction semantics that have been historically agreed on, instead of new, complex encodings and containers.</p> <h2 id="specification">Specification</h2> <p>Let <code>top - N</code> be the <code>N</code>th most recently pushed value on the stack, and <code>top - 0</code> be the most recent.</p> <p>If any of the following instructions reference a stack element beyond the current length of the stack, causing a stack underflow, abort with an exceptional halt.</p> <h3 id="constant-swapxx-and-dupxx">Constant <code>SWAPXX</code> and <code>DUPXX</code></h3> <p>Add the following new instructions:</p> <ul> <li><code>SWAP17</code>, <code>SWAP18</code>, ..., <code>SWAP24</code>: <code>0xb0</code>, <code>0xb1</code>, ..., <code>0xb7</code>.</li> <li><code>DUP17</code>, <code>DUP18</code>, ..., <code>DUP24</code>: <code>0xb8</code>, <code>0xba</code>, ..., <code>0xbf</code>.</li> </ul> <p>Let <code>SWAPXX</code> and <code>DUPXX</code> refer to the static instructions defined above. <code>XX</code> is defined as the stack element they are referencing.</p> <p>The operation <code>SWAPXX</code> swaps the top element with the <code>top-XX</code> element. The operation <code>DUPXX</code> duplicates the <code>top-XX</code> element and pushes the copy to the top of the stack.</p> <h3 id="swapn-and-dupn"><code>SWAPN</code> and <code>DUPN</code></h3> <p>Add the following new instructions:</p> <ul> <li><code>SWAPN</code>: <code>0xc0</code>.</li> <li><code>DUPN</code>: <code>0xc1</code>.</li> </ul> <p>Both operations take a single argument from the stack, <code>N</code>. This argument must be provided by a <code>PUSH1</code> operation immediately preceding the <code>SWAPN</code> and <code>DUPN</code> instructions. Failure to follow this calling convention will result in an out-of-gas error. If <code>N</code> is zero, fail with out-of-gas error.</p> <p><code>SWAPN</code> pops <code>N</code> from the stack and swaps the new top stack element with the <code>top-N</code> stack element.</p> <p><code>DUPN</code> pops <code>N</code> from the stack and push on a copy of the <code>top-N-1</code> stack element.</p> <h3 id="exchange"><code>EXCHANGE</code></h3> <p>Add the following new instruction:</p> <ul> <li><code>EXCHANGE</code>: <code>0xc2</code>.</li> </ul> <p>The <code>EXCHANGE</code> instruction takes a single argument from the stack <code>X</code> and deconstructs it into two operands, <code>N</code> and <code>M</code>. <code>N</code> is <code>X &gt;&gt; 4</code> and <code>M</code> is <code>X &amp; 0x0F</code>. The argument <code>X</code> must be provided by a <code>PUSH2</code> operation immediately preceding the <code>EXCHANGE</code> instruction. Failure to follow this calling convention will result in an out-of-gas error. If either <code>N</code> or <code>M</code> are zero, fail with out-of-gas error.</p> <p><code>EXCHANGE</code> pops <code>X</code> from the stack and will swap the stack element at index <code>N-1</code> with the stack element at <code>M-1</code>.</p> <h3 id="gas-costs">Gas costs</h3> <p>All operations cost <code>3</code> gas. Preceding push operations are charged separately according to the gas schedule.</p> <h2 id="rationale">Rationale</h2> <h3 id="constant-and-dynamic-swaps-and-dups">Constant and Dynamic <code>SWAP</code>s and <code>DUP</code>s</h3> <p>The main trade off between using the constant <code>SWAPXX</code> or <code>DUPXX</code> instructions versus the dynamic <code>SWAPN</code> or <code>DUPN</code> instructions is that the dynamic instructions require an additional two bytes in the form of a preceding <code>PUSH1</code> operation, whereas the constant versions require no additional bytes.</p> <h3 id="one-indexed-exchange">One indexed <code>EXCHANGE</code></h3> <p>Since <code>SWAP1</code> and <code>DUP1</code> operate on the top of the stack, it seems fitting that <code>EXCHANGE(1, 2)</code> operate on the <code>top</code> and <code>top-1</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>When verifying the preceding <code>PUSH</code> operations, client implementers must ensure that the preceding bytes are not part of a longer segment of push data (e.g. <code>0x6301026001b0</code> should error). This can be done efficiently by checking if <code>pc-2</code> is a valid jump destination. If it is, then the <code>PUSH</code> instruction will have been executed as expected.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson Ben Adamshttps://github.com/benaadams Francesco D'Amatohttps://github.com/fradamt https://wg-eips.ritovision.com/7918/

Imposes that the price of GAS_PER_BLOB blob gas is greater than the price of BLOB_BASE_COST execution gas.

<h2 id="abstract">Abstract</h2> <p>This EIP assigns a reserve price <code>BLOB_BASE_COST * base_fee_per_gas</code> to blobs by introducing an <code>if</code>-clause in <code>calc_excess_blob_gas()</code>. Specifically, when the reserve price is higher than <code>GAS_PER_BLOB * base_fee_per_blob_gas</code>, the function will not subtract <code>target_blob_gas</code> from <code>excess_blob_gas</code>, causing <code>excess_blob_gas</code> to increase according to <code>blob_gas_used</code>, while keeping the per-block maximum increase unchanged. The proposal ensures that the blob fee market can function properly and that blob consumers pay at least a relevant fraction of the market rate for the compute they request from nodes.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum uses a dynamic pricing auction to set the blob base fee, lowering the fee if less gas is consumed than <code>target_blob_gas = GAS_PER_BLOB * blobSchedule.target</code> and raising the fee if more gas is consumed. Such an auction can function well when the blob base fee represents the price signal, allowing the mechanism to control the real price for blob consumers. However, when execution costs dominate, the price signal is lost. The blob base fee then no longer represents a significant component of the total cost facing the consumer, and the protocol can no longer rely on the blob base fee to control the equilibrium quantity of blobs consumed.</p> <p>The current mechanism can therefore end up repeatedly lowering the blob base fee until it eventually settles at 1 wei. A change in the blob base fee of 10% may under such circumstances shift the total cost of utilizing blobspace by just 0.0000001%. Whenever demand picks up, over an hour of near-full blocks is required to restore a market-clearing equilibrium fee, with the mechanism intermittently resorting to a first-price auction, considered a worse UX by blob consumers. The resulting spikiness in resource consumption is suboptimal for scaling blobspace. To alleviate this, the proposal imposes a reserve price that reflects execution costs, through a simple <code>if</code>-clause in <code>calc_excess_blob_gas()</code>.</p> <p>The reserve price also fulfills a second function. Nodes must cryptographically verify KZG <code>proofs</code> to ensure that associated <code>commitments</code> correspond to provided blobs. This process is computationally expensive. It seems desirable to ensure that blob consumers pay at least some fraction of the market rate for the compute they impose on nodes. In this context, the execution base fee reflects how in-demand nodes' compute services are at the time that blob consumers request them.</p> <p>By applying the reserve price to the blob base fee, the proposal jointly ensures that:</p> <ol> <li>The blob base fee update mechanism can function properly, by establishing a reserve price which is significant relative to L1 execution costs of blob consumers.</li> <li>Blob consumers pay at least a relevant fraction of the market rate for the compute they request from nodes, with any additional fees for data determined independently in the blob fee market.</li> </ol> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>BLOB_BASE_COST</code></td><td><code>2**13</code></td></tr> </tbody></table> <h3 id="functions">Functions</h3> <p>An <code>if</code>-clause is added to <code>calc_excess_blob_gas()</code> from <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>. The function no longer subtracts <code>target_blob_gas</code> when updating <code>excess_blob_gas</code> if the price of a <code>blob</code> is below the price of <code>BLOB_BASE_COST</code> execution gas. The <code>blobSchedule</code> for referencing target and max blobs was introduced in <a href="https://wg-eips.ritovision.com/7840/">EIP-7840</a>. The current block's <code>blobSchedule</code> is used during processing. Thus, in the first block after a fork—when calculating <code>base_fee_per_blob_gas</code> via <code>get_base_fee_per_blob_gas(parent)</code>—<code>fake_exponential()</code> must use the <em>new</em> <code>blobSchedule.baseFeeUpdateFraction</code>. Likewise, the <em>new</em> <code>blobSchedule.max</code> and <code>blobSchedule.target</code> must be used in <code>calc_excess_blob_gas()</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> target_blob_gas</span><span class="z-keyword"> =</span><span class="z-constant"> GAS_PER_BLOB</span><span class="z-keyword"> *</span><span> blobSchedule</span><span>.</span><span>target</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> &lt;</span><span> target_blob_gas</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> BLOB_BASE_COST</span><span class="z-keyword"> *</span><span> parent</span><span>.</span><span>base_fee_per_gas</span><span class="z-keyword"> &gt;</span><span class="z-constant"> GAS_PER_BLOB</span><span class="z-keyword"> *</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>parent</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> *</span><span> (</span><span>blobSchedule</span><span>.</span><span>max</span><span class="z-keyword"> -</span><span> blobSchedule</span><span>.</span><span>target</span><span>)</span><span class="z-keyword"> //</span><span> blobSchedule</span><span>.</span><span>max</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> -</span><span> target_blob_gas</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="fee-inelasticity-and-reserve-price">Fee-inelasticity and reserve price</h3> <p>This proposal alleviates idiosyncrasies in the blob base fee auction. When a rollup's costs are dominated by execution costs for the blob-carrying transactions, ZK proof verification, or priority fees, the protocol can no longer rely on the blob base fee to control the equilibrium quantity of blobs consumed. The fee update mechanism is unaware of the full price of the goods that it regulates the price for and therefore fails to converge on equilibrium in a timely manner.</p> <p>We can express a simple real demand function for blobspace as</p> <p>$Q(b + c).$</p> <p>It maps the quantity of blobs demanded $Q$ to the blob base fee $b$ and the user's execution costs, expressed "per blob gas", $c$:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>c</span><span class="z-keyword"> =</span><span> execution_cost</span><span class="z-keyword"> *</span><span> base_fee_per_gas</span><span class="z-keyword"> /</span><span class="z-constant"> GAS_PER_BLOB</span></span></code></pre> <p>According to the <em>law of demand</em>, the lower the price $b+c$, the higher the demand. From the perspective of the blob base fee update mechanism, $c$ is fixed. If $c&gt;0$, the demand curve will therefore have an "inelasticity horizon", beyond which further reductions in $b$ no longer increase $Q$:</p> <p>$\lim_{b \to 0} Q(b + c) = Q(c).$</p> <p>In essence, the demand curve becomes a vertical line, where changes to the blob base fee $b$ no longer affect demand. Figure 1 illustrates this, with real demand curves (black to red) computed under four different execution base fees when purchasing two blobs. The hypothetical organic demand is illustrated in black. Any demand curve where execution costs are positive ($c&gt;0$) eventually becomes vertical as the blob base fee falls. The protocol also uses a long-run perfectly inelastic supply curve (vertical blue line). Therefore, relatively small shifts in organic demand or the execution base fee (arrows) can lead to dramatic shifts in the equilibrium blob base fee. Importantly, the blob base fee will simply fall to the boundary of 1 wei whenever the execution cost is too high for consumers to achieve equilibrium formation at <code>target_blob_gas</code>.</p> <p><img src="https://wg-eips.ritovision.com/7918/./assets/1.png" alt="Figure 1" /></p> <p><strong>Figure 1.</strong> Hypothetical real demand for blobspace under different execution base fees (black to red lines). When execution cost dominates, the real demand curve becomes inelastic and parallel to the supply curve, leading the equilibrium fee to change dramatically even with small shifts in the demand curve (arrows). The proposal imposes that the equilibrium (square) forms on the edges of the upper-left quadrant, at the intersection between the target supply curve and demand or along the dashed line representing possible reserve price equilibria accounting for execution costs.</p> <p>To improve the fee update mechanism, a reserve price is specified below which $b$ cannot be reduced. Specifically, we define a constant <code>BLOB_BASE_COST</code> and in <code>calc_excess_blob_gas</code> do not subtract <code>target_blob_gas</code> if:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">BLOB_BASE_COST</span><span class="z-keyword"> *</span><span> base_fee_per_gas</span><span class="z-keyword"> &gt;</span><span class="z-constant"> GAS_PER_BLOB</span><span class="z-keyword"> *</span><span> base_fee_per_blob_gas</span></span></code></pre> <p>This means that the reserve blob base fee becomes <code>BLOB_BASE_COST * base_fee_per_gas / GAS_PER_BLOB</code> and that the ratio between the reserve price for the blob base fee and the execution base fee is fixed to: <code>BLOB_BASE_COST / GAS_PER_BLOB</code>. This ratio is <code>1/16</code> with the proposed constant.</p> <p>The blob fee's share of the total price will with the reserve price always be at least <code>BLOB_BASE_COST / (BLOB_BASE_COST + execution_cost)</code>. This is why the equilibrium under the reserve price (dashed line in Figure 1) is situated a constant fraction below the black organic demand curve formed under a zero execution base fee. The equilibrium (squares) must then form somewhere along the edge of the upper-left quadrant, bounded by the blue supply curve and the dashed curve representing possible reserve price equilibria under real demand.</p> <p>The demand curve could potentially be somewhat inelastic even under zero execution costs. This would however just be another reason to move forward with this proposal. Regardless of the exact shape of the demand curve—which of course will remain unknown and can vary going forward—the proposal is based on something tangible affecting blob consumers. This makes it a justified neutral bound on the blob base fee.</p> <h3 id="blob-kzg-proof-verification-cost">Blob KZG proof verification cost</h3> <p>EIP-4844 introduced the first phase of Ethereum's data availability sampling (DAS) roadmap. Validators on the consensus layer (CL) verify that the KZG <code>commitments</code> in the payload correspond to the provided <code>blobs</code> by cryptographically verifying the accompanying KZG <code>proofs</code>. Execution layer (EL) nodes must also validate the <code>tx_payload_body</code> and verify the wrapped data (blobs, commitments, and proofs) for every blob entering a node's tx pool. The computational requirements for verifying a KZG proof for an entire blob are slightly higher than those for verifying a KZG proof for a single point on that blob; the latter is the specific operation covered by the <code>POINT_EVALUATION_PRECOMPILE_GAS</code> (50000) charged to smart contracts.</p> <p><a href="https://wg-eips.ritovision.com/7594/">EIP-7594</a> introduces PeerDAS. It changes the compute requirements due to the reliance on blob cells and their individual proofs. The exact specification is not yet fully settled, but this is a rough guideline:</p> <ul> <li>EL nodes batch-verify <code>CELLS_PER_EXT_BLOB</code> (128) cell proofs for each blob before including a tx carrying that blob in their tx pool. This verification (e.g., using <code>verify_cell_kzg_proof_batch</code>) is roughly 15 times more expensive than the compute associated with a single <code>POINT_EVALUATION_PRECOMPILE_GAS</code>.</li> <li>Full nodes verify 4 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified (also applicable below).</li> <li>Supernodes verify 128 custodied columns, each column containing one cell from all blobs referenced in the payload.</li> <li>Validators between full nodes and supernodes will custody between 4-128 columns.</li> <li>Nodes peer-sample <code>SAMPLES_PER_SLOT</code> (8) columns each slot (in addition to custodied columns).</li> </ul> <p>The ability on the CL to jointly process cell proofs of a column (from all blobs) through batching reduces the compute time spent per blob as the number of blobs increases. It is further possible to batch all columns jointly or to parallelize the processing across columns. When accounting for the prospect of parallelization for the CL, it is however worth remembering that the point evaluation proof verification performed by rollups using the precompile also lends itself to parallelization. This means that a comparison between the point evaluation and the sequential processing of blobs (batched per column) is still relevant (because <em>both</em> could be parallelized).</p> <p>Figure 2 shows verification time per blob divided by the measured execution time of a single point evaluation operation (performed by the <code>VerifyKZGProof</code> precompile) for various configurations. The figure indicates that blobs under the current Fusaka PeerDAS specification will subject nodes to rather heavy compute requirements—when compared to the single point evaluation proof verification that a smart contract is charged <code>POINT_EVALUATION_PRECOMPILE_GAS</code> for. A full node would for example do the EL mempool verification for all blobs propagated p2p (15x), sample 8 columns (2x at 32 blobs when batching columns sequentially), and custody 4 designated columns (1x). How to price the KZG proof verification is however a complex question given the varying contexts in which it is performed. The proposed constant <code>BLOB_BASE_COST</code> is indicated by a green line in Figure 2. It is relatively moderate in comparison with the compute costs imposed on nodes.</p> <p><img src="https://wg-eips.ritovision.com/7918/./assets/2.png" alt="Figure 2" /></p> <p><strong>Figure 2.</strong> Verification time per blob relative to one point evaluation on an Apple M2 Max with 12 cores. The EL mempool verification (red) takes 15 times longer in the worst case, regardless of the blob target. The per-blob verification time of columns depends on the number of custodied/sampled columns and falls with an increase in the blob target due to speed-ups from processing all cells of a column jointly. The constant <code>BLOB_BASE_COST</code> is relatively moderate in comparison with the compute costs that blobs impose on nodes.</p> <h3 id="designing-for-the-future">Designing for the future</h3> <p>The price of storing a fixed amount of data has fallen over the last 80 years. Technological progress generally brings down the unit cost of data services, following Nielsen’s law and Moore’s law. The ETH-denominated price per blob should likewise fall as Ethereum increases blob throughput. This effect is reinforced because a higher aggregate ETH-denominated blob revenue (which is distributed to ETH token holders via the burn) increases the fiat-denominated value of the ETH token, ceteris paribus. There is thus an upper bound on the blob base fee—a bound that falls as Ethereum scales. The same reflexivity applies to the execution base fee.</p> <p>In this light, the proposal can be understood as a design for the future. Fixed thresholds not relating to blob quantity or the execution fee may not be sustainable. In a scenario where Ethereum sells more blobs per block, the equilibrium blob base fee should ideally have a relatively lower floor. Any fixed threshold (not relating to the execution base fee or blob quantity) would need to be gradually readjusted to retain the same relative impact.</p> <p>If Ethereum increases blob throughput by several orders of magnitude but does <em>not</em> scale blockspace, such that the execution base fee remains high, the reserve price of <code>BLOB_BASE_COST</code> execution gas would however still become too high. At 1000 blobs and 30M execution gas per block, Ethereum would derive just over 1/5th (21.5%) of its income from blob gas even when blobs are strictly sold at the reserve price. This implies a too high <code>BLOB_BASE_COST</code>, but 1000 blobs and 30M execution gas is not the trajectory that Ethereum currently is on. If Ethereum scales blockspace and blobspace roughly in synchrony, it is reasonable to expect that the reserve price remains at the desired level.</p> <h3 id="delayed-response-during-a-quick-rise-in-execution-fees">Delayed response during a quick rise in execution fees</h3> <p>When the <code>if</code> statement concludes that Ethereum operates in the execution-fee-led pricing regime, the blob base fee rises in accordance with <code>blob_gas_used * (max - target) // max</code>, without subtracting <code>target_blob_gas</code>. This is an intuitive way to return to the blob-fee-led pricing regime, retaining the same maximum fee increase while not allowing for a decrease. If the execution base fee rises quickly, there may be a few blocks before the blob base fee catches up (during which <code>target_blob_gas</code> will never be subtracted). This is arguably not an issue, and the smooth response in the blob base fee under these circumstances may even be seen as a benefit.</p> <h3 id="empirical-analysis">Empirical analysis</h3> <p>Figures 3-4 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. The proposed reserve fee is applied directly to the original data, without accounting for its potential effect on the equilibrium fee. The equilibrium blob base fee would in reality rise from the threshold level once demand at this fee is above target supply. EIP-7918 imposes the maximum of the two curves, indicated in darker colors.</p> <p><img src="https://wg-eips.ritovision.com/7918/./assets/3.png" alt="Figure 3" /></p> <p><strong>Figure 3.</strong> Blob base fee evolution with the current fee market (black) and the proposed reserve fee (blue), during three weeks of November 2024 when the average execution base fee was around 16 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p> <p><img src="https://wg-eips.ritovision.com/7918/./assets/4.png" alt="Figure 4" /></p> <p><strong>Figure 4.</strong> Blob base fee evolution with the current fee market (black) and the proposed reserve fee (blue), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p> <p>Figure 5 shows histograms for observed fees and the maximum of the two curves for the four-month period from November 2024 (start of Figure 3's data period) through March 2025 (end of Figure 4's data period), corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 21 with mirror-reflected edges.</p> <p><img src="https://wg-eips.ritovision.com/7918/./assets/5.png" alt="Figure 5" /></p> <p><strong>Figure 5.</strong> Histogram of the blob base fee when there is no threshold or when applying EIP-7918 (dashed combination of the darker black and blue curves from previous figures), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The blob base fee will settle at a level where a blob costs at least <code>BLOB_BASE_COST</code> execution gas. To the best of the authors' knowledge, there are no security risks associated with this.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Zsolt Felföldihttps://github.com/zsfelfoldi Caymanhttps://github.com/wemeetagain Etan Kisslinghttps://github.com/etan-status https://wg-eips.ritovision.com/7916/

SSZ types for efficiently hashing short lists

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new Merkle tree shape for <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md">Simple Serialize (SSZ)</a> types that results in fewer hashes when only a small number of leaves is used. The new tree shape grows progressively with increased leaf count and no longer has a bounded capacity. It also offers forward compatibility: a given chunk index is always assigned the same stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> regardless of leaf count.</p> <p>New types are defined to use the progressive Merkle tree shape: <code>ProgressiveList[type]</code> and <code>ProgressiveBitlist</code>. These new types represent lists of arbitrary length with stable merkleization, reducing hashing overhead for small lists and avoiding arbitrary capacity limits.</p> <h2 id="motivation">Motivation</h2> <p>Current SSZ <code>List[type, N]</code> types require a predefined capacity <code>N</code>, which leads to several issues:</p> <ul> <li>Inefficient hashing: Lists often contain far fewer elements than their maximum capacity (e.g., <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#custom-types"><code>Transaction</code></a>), resulting in unnecessary zero-padding and dozens of extra hash computations. This is exacerbated when nesting <code>List[type, N]</code>, e.g., in a design where each of up to <code>X</code> transactions has up to <code>Y</code> access lists, each with up to <code>Z</code> storage slots.</li> <li>Arbitrary Limits: The capacity <code>N</code> is often chosen arbitrarily (e.g., <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#execution"><code>MAX_BYTES_PER_TRANSACTION</code></a>, <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#execution"><code>MAX_TRANSACTIONS_PER_PAYLOAD</code></a>) and set to artificially large values to anticipate future design space, which are not always correct.</li> <li>Unstable proofs: Modifying <code>N</code> across forks (e.g., <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#max-operations-per-block"><code>MAX_ATTESTER_SLASHINGS_ELECTRA</code></a>, <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#max-operations-per-block"><code>MAX_ATTESTATIONS_ELECTRA</code></a>) alters gindices, breaking downstream verifiers.</li> </ul> <p>The progressive Merkle tree shape addresses these by:</p> <ul> <li>Using a recursive tree structure that progressively grows to the actual leaf count with minimal overhead</li> <li>Dropping the notion of a maximum capacity, relying instead on practical limits, e.g., SSZ's 4 GB variable offset cap, network payload limits, gas limits, bounds on the number of signatures.</li> <li>Maintaining stable gindices for each element, ensuring provers remain valid as the leaf count changes.</li> </ul> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="progressive-merkle-tree">Progressive Merkle tree</h3> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#merkleization">SSZ Merkleization specification</a> is extended with a helper function:</p> <ul> <li><code>merkleize_progressive(chunks, num_leaves=1)</code>: Given ordered <code>BYTES_PER_CHUNK</code>-byte chunks: <ul> <li>The merkleization depends on the number of input chunks and is defined recursively: <ul> <li>If <code>len(chunks) == 0</code>: the root is a zero value, <code>Bytes32()</code>.</li> <li>Otherwise: compute the root using <code>hash(a, b)</code> <ul> <li><code>a</code>: Merkleize the first up to <code>num_leaves</code> chunks as a binary tree using <code>merkleize(chunks[:num_leaves], num_leaves)</code>.</li> <li><code>b</code>: Recursively merkleize chunks beyond <code>num_leaves</code> using <code>merkleize_progressive(chunks[num_leaves:], num_leaves * 4)</code>.</li> </ul> </li> </ul> </li> </ul> </li> </ul> <p>This results in a 0-terminated sequence of binary subtrees with increasing leaf count. The deepest subtree is padded with zeroed chunks (virtually for memory efficiency).</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> root</span></span> <span class="giallo-l"><span> /\</span></span> <span class="giallo-l"><span> / \</span></span> <span class="giallo-l"><span> 1: chunks[0 ..&lt; 1] /\</span></span> <span class="giallo-l"><span> / \</span></span> <span class="giallo-l"><span> 4: chunks[1 ..&lt; 5] /\</span></span> <span class="giallo-l"><span> / \</span></span> <span class="giallo-l"><span> 16: chunks[5 ..&lt; 21] /\</span></span> <span class="giallo-l"><span> / \</span></span> <span class="giallo-l"><span> 64: chunks[21 ..&lt; 85] 0</span></span></code></pre><table><thead><tr><th style="text-align: right">Depth</th><th style="text-align: right">Added chunks</th><th style="text-align: right">Total chunks</th><th style="text-align: right">Total capacity (bytes)</th></tr></thead><tbody> <tr><td style="text-align: right">0</td><td style="text-align: right">0</td><td style="text-align: right">0</td><td style="text-align: right">0</td></tr> <tr><td style="text-align: right">1</td><td style="text-align: right">1</td><td style="text-align: right">1</td><td style="text-align: right">32</td></tr> <tr><td style="text-align: right">2</td><td style="text-align: right">4</td><td style="text-align: right">5</td><td style="text-align: right">160</td></tr> <tr><td style="text-align: right">3</td><td style="text-align: right">16</td><td style="text-align: right">21</td><td style="text-align: right">672</td></tr> <tr><td style="text-align: right">4</td><td style="text-align: right">64</td><td style="text-align: right">85</td><td style="text-align: right">2'720</td></tr> <tr><td style="text-align: right">5</td><td style="text-align: right">256</td><td style="text-align: right">341</td><td style="text-align: right">10'912</td></tr> <tr><td style="text-align: right">6</td><td style="text-align: right">1'024</td><td style="text-align: right">1'365</td><td style="text-align: right">43'680</td></tr> <tr><td style="text-align: right">7</td><td style="text-align: right">4'096</td><td style="text-align: right">5'461</td><td style="text-align: right">174'752</td></tr> <tr><td style="text-align: right">8</td><td style="text-align: right">16'384</td><td style="text-align: right">21'845</td><td style="text-align: right">699'040</td></tr> <tr><td style="text-align: right">9</td><td style="text-align: right">65'536</td><td style="text-align: right">87'381</td><td style="text-align: right">2'796'192</td></tr> <tr><td style="text-align: right">10</td><td style="text-align: right">262'144</td><td style="text-align: right">349'525</td><td style="text-align: right">11'184'800</td></tr> <tr><td style="text-align: right">11</td><td style="text-align: right">1'048'576</td><td style="text-align: right">1'398'101</td><td style="text-align: right">44'739'232</td></tr> <tr><td style="text-align: right">12</td><td style="text-align: right">4'194'304</td><td style="text-align: right">5'592'405</td><td style="text-align: right">178'956'960</td></tr> <tr><td style="text-align: right">13</td><td style="text-align: right">16'777'216</td><td style="text-align: right">22'369'621</td><td style="text-align: right">715'827'872</td></tr> <tr><td style="text-align: right">14</td><td style="text-align: right">67'108'864</td><td style="text-align: right">89'478'485</td><td style="text-align: right">2'863'311'520</td></tr> <tr><td style="text-align: right">15</td><td style="text-align: right">268'435'456</td><td style="text-align: right">357'913'941</td><td style="text-align: right">11'453'246'112</td></tr> </tbody></table> <h3 id="progressivelist-type-and-progressivebitlist"><code>ProgressiveList[type]</code> and <code>ProgressiveBitlist</code></h3> <p>Two new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#composite-types">SSZ composite types</a> are defined:</p> <ul> <li><strong>progressive list</strong>: ordered variable-length homogeneous collection, without limit <ul> <li>notation <code>ProgressiveList[type]</code>, e.g. <code>ProgressiveList[uint64]</code></li> </ul> </li> <li><strong>progressive bitlist</strong>: ordered variable-length collection of <code>boolean</code> values, without limit <ul> <li>notation <code>ProgressiveBitlist</code></li> </ul> </li> </ul> <p>The new types are considered <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#variable-size-and-fixed-size">"variable-size"</a>.</p> <p>For convenience we <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#aliases">alias</a>:</p> <ul> <li><code>ProgressiveByteList</code> to <code>ProgressiveList[byte]</code></li> </ul> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#default-values">default value</a> is defined as:</p> <table><thead><tr><th>Type</th><th>Default Value</th></tr></thead><tbody> <tr><td><code>ProgressiveList[type]</code></td><td><code>[]</code></td></tr> <tr><td><code>ProgressiveBitlist</code></td><td><code>[]</code></td></tr> </tbody></table> <h4 id="serialization">Serialization</h4> <p>Serialization, deserialization, and JSON mapping of <code>ProgressiveBitlist</code> are identical to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#bitlistn"><code>Bitlist[N]</code></a>.</p> <p>Serialization, deserialization, and JSON mapping of <code>ProgressiveList[type]</code> are identical to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#vectors-containers-lists"><code>List[type, N]</code></a>.</p> <h4 id="merkleization">Merkleization</h4> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md#merkleization">Merkleization</a> definitions are extended.</p> <ul> <li><code>mix_in_length(merkleize_progressive(pack(value)), len(value))</code> if <code>value</code> is a progressive list of basic objects.</li> <li><code>mix_in_length(merkleize_progressive(pack_bits(value)), len(value))</code> if <code>value</code> is a progressive bitlist.</li> <li><code>mix_in_length(merkleize_progressive([hash_tree_root(element) for element in value]), len(value))</code> if <code>value</code> is a progressive list of composite objects.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-a-recursive-structure">Why a recursive structure?</h3> <ul> <li>Efficiency: Small lists use fewer hashes (e.g., a 3-item list in a 16-element subtree wastes fewer hashes than a 1024-element <code>List[type, N]</code>).</li> <li>Stability: Fixed subtree sizes ensure stable gindices, avoiding the need for dynamic depth adjustments or multiple queries.</li> <li>Scalability: Recursive subtrees allow arbitrary growth without a hardcoded limit, constrained only by practical limits (e.g., network payload limit, validation rules).</li> </ul> <h3 id="why-not-dynamic-depth">Why not dynamic depth?</h3> <p>Dynamic-depth Merkleization destabilizes gindices:</p> <ul> <li>Requires two-step queries (length then gindex), increasing latency and reorg risks.</li> <li>Complicates proofs with semantic lookups.</li> </ul> <p>Mixing in successor subtrees ensures predictable gindices and proof sizes.</p> <h3 id="why-not-fixed-capacity-lists">Why not fixed-capacity lists?</h3> <p><code>List[type, N]</code>:</p> <ul> <li>Imposes arbitrary limits, hindering scalability.</li> <li>Breaks stability when redefined.</li> <li>Wastes hashes with padding (e.g., 1024-element capacity for a 1-item list). (only log(N) wasted hashes)</li> </ul> <p><code>ProgressiveList[type]</code> offers a scalable, efficient alternative.</p> <h3 id="why-are-initial-leaf-count-and-scaling-factors-not-exposed-parameters">Why are initial leaf count and scaling factors not exposed parameters?</h3> <ul> <li>Simplicity: Fixed values (initial leaf count 1, scaling factor 4) provide a sensible default that balances efficiency and usability, aligning with SSZ’s goal of simplicity.</li> <li>Future Extensibility: If specific use cases demand different values, a future EIP could introduce parameterization. For now, fixed values reduce adoption barriers and align with the principle of "good enough" defaults.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The new SSZ types coexist with existing types without conflict and share their serialization logic.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li><code>ethereum/remerkleable</code> contains static tests in <code>test_impl.py</code> and <code>test_typing.py</code>.</li> <li><code>ethereum/consensus-specs</code> releases contain random tests in <code>tests/general/phase0/ssz_generic</code>, generated according to a format defined in <code>tests/format/ssz_generic</code>.</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>See <code>ethereum/remerkleable</code>.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Resource limits: The <code>uint32</code> limit for variable-length offsets essentially introduces a ~4GB cap when including a <code>ProgressiveList[type]</code> or <code>ProgressiveBitlist</code> within another complex type, but practical limits (e.g., 10MB libp2p messages) apply. Implementations SHOULD enforce context-specific bounds.</li> <li>Variable proof size: Recursive traversal may increase proof sizes for large indices, though logarithmic in list size due to the scaling factor.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-24T00:00:00+00:00 2026-02-11T14:49:28+00:00 Lin Oshitanihttps://github.com/linoscopelin@nethermind.io Justin Drakehttps://github.com/JustinDrakejustin@ethereum.org https://wg-eips.ritovision.com/7917/

Pre-calculate and store a deterministic proposer lookahead in the beacon state at the start of every epoch

<h2 id="abstract">Abstract</h2> <p>At the start of each epoch, pre-calculate and store in the <code>beacon_state</code> a deterministic <code>proposer_lookahead</code> for the next <code>MIN_SEED_LOOKAHEAD + 1</code> epochs.</p> <h2 id="motivation">Motivation</h2> <p>Unlike RANDAO seeds, which have a deterministic lookahead of at least <code>MIN_SEED_LOOKAHEAD == 1</code> epochs, the beacon proposer schedule of epoch <code>N + 1</code> is not fully predictable from the beacon state during epoch <code>N</code>. The reason is that, under certain edge cases, the effective balances (EBs) of active validators—themselves used as input for proposer election in epoch <code>N + 1</code>—can change within epoch <code>N</code>.</p> <p>Based preconfirmation protocols rely on a deterministic proposer schedule for smooth operations. Since the beacon genesis, slashings and penalties that accumulate to at least 1 ETH can change EBs of active validators and lead to an unpredictable proposer schedule despite the RANDAO seed being known ahead of time. The increase of MaxEB with <a href="https://wg-eips.ritovision.com/7251/">EIP-7251</a> increases effective balance unpredictability because rewards that accumulate to at least 1 ETH, validator consolidations, and deposits can grow EBs of active validators beyond 32 ETH.</p> <p>Besides fixing next-epoch proposer schedule non-determinism, this EIP makes it possible for the proposer schedule of the next epoch to be accessible to the application layer via the beacon root and a simple Merkle proof. This highly simplifies the implementation of on-chain components for based preconfirmation protocols.</p> <p>Introducing a fully deterministic lookahead fixes a long-standing beacon chain design oversight, as highlighted by Danny Ryan's comment below:</p> <p><img src="https://wg-eips.ritovision.com/7917/./assets/lookahead-comment.png" alt="Danny Ryan&#39;s comment on proposer lookahead" /></p> <p>With this change, it will no longer be possible for validators to grind effective balances to manipulate the proposer schedule of the next epoch, and the analysis of effective balance grinding will collapse from what is currently a subtle analysis of EB edge cases to a trivial security analysis. Finally, the proposer lookahead gives CL clients ahead-of-time visibility over the next proposer which may simplify implementations.</p> <h2 id="specification">Specification</h2> <p>The <code>BeaconState</code> container is extended with a <code>proposer_lookahead</code> field, which is a vector of validator indices covering the full visible lookahead period, starting from the beginning of the current epoch to the next <code>MIN_SEED_LOOKAHEAD</code> epochs.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconState</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> proposer_lookahead</span><span>:</span><span> Vector</span><span>[</span><span>ValidatorIndex</span><span>,</span><span> (</span><span class="z-constant">MIN_SEED_LOOKAHEAD</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span></span></code></pre> <p>For example, <code>proposer_lookahead[0]</code> is the validator index for the first proposer in the current epoch, <code>proposer_lookahead[SLOTS_PER_EPOCH + 4]</code> is the validator index for the fifth proposer in the next epoch, and so forth.</p> <p>The function <code>get_beacon_proposer_index</code> is modified to use the pre-calculated <code>proposer_lookahead</code> instead of calculating proposer indices on-demand.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_beacon_proposer_index</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> ValidatorIndex</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Return the beacon proposer index at the current slot.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>proposer_lookahead</span><span>[</span><span>state</span><span>.</span><span>slot</span><span class="z-keyword"> %</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span></span></code></pre> <p>At the epoch boundary, the <code>proposer_lookahead</code> is updated by shifting out the current epoch’s lookahead and appending the new one.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_epoch</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> process_proposer_lookahead</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_proposer_lookahead</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> last_epoch_start</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>state</span><span>.</span><span>proposer_lookahead</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> SLOTS_PER_EPOCH</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Shift out proposers in the first epoch</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>proposer_lookahead</span><span>[</span><span>:</span><span>last_epoch_start</span><span>]</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>proposer_lookahead</span><span>[</span><span class="z-constant">SLOTS_PER_EPOCH</span><span>:</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Fill in the last epoch with new proposer indices</span></span> <span class="giallo-l"><span> last_epoch_proposers</span><span class="z-keyword"> =</span><span> get_beacon_proposer_indices</span><span>(</span></span> <span class="giallo-l"><span> state</span><span>,</span><span> Epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> MIN_SEED_LOOKAHEAD</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>proposer_lookahead</span><span>[</span><span>last_epoch_start</span><span>:</span><span>]</span><span class="z-keyword"> =</span><span> last_epoch_proposers</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_beacon_proposer_indices</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> epoch</span><span>:</span><span> Epoch</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> Vector</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Return the proposer indices for the given ``epoch``.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> indices</span><span class="z-keyword"> =</span><span> get_active_validator_indices</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>)</span></span> <span class="giallo-l"><span> seed</span><span class="z-keyword"> =</span><span> get_seed</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>,</span><span class="z-constant"> DOMAIN_BEACON_PROPOSER</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> compute_proposer_indices</span><span>(</span><span>state</span><span>,</span><span> epoch</span><span>,</span><span> seed</span><span>,</span><span> indices</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_proposer_indices</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> epoch</span><span>:</span><span> Epoch</span><span>,</span><span class="z-variable z-parameter z-function"> seed</span><span>:</span><span> Bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> indices</span><span>:</span><span> Sequence</span><span>[</span><span>ValidatorIndex</span><span>]</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> Vector</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Return the proposer indices for the given ``epoch``.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> start_slot</span><span class="z-keyword"> =</span><span> compute_start_slot_at_epoch</span><span>(</span><span>epoch</span><span>)</span></span> <span class="giallo-l"><span> seeds</span><span class="z-keyword"> =</span><span> [</span><span class="z-support">hash</span><span>(</span><span>seed</span><span class="z-keyword"> +</span><span> uint_to_bytes</span><span>(</span><span>Slot</span><span>(</span><span>start_slot</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span>)</span><span>)</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">SLOTS_PER_EPOCH</span><span>)</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span><span>compute_proposer_index</span><span>(</span><span>state</span><span>,</span><span> indices</span><span>,</span><span> seed</span><span>)</span><span class="z-keyword"> for</span><span> seed</span><span class="z-keyword"> in</span><span> seeds</span><span>]</span></span></code></pre> <p>Furthermore, the first block after the fork will calculate all lookaheads for epochs up to <code>MIN_SEED_LOOKAHEAD</code> ahead and fill the <code>proposer_lookahead</code> field in the beacon state.</p> <p>See the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/cbaa0063979168a94a9c7821f366c6a221319c8e/specs/fulu/beacon-chain.md">updated beacon chain specs</a> in consensus-specs for more details.</p> <h2 id="rationale">Rationale</h2> <h3 id="considered-alternatives">Considered Alternatives</h3> <p>An alternative approach would be to cache the effective balances at the start of epoch <code>N</code> so it can be used to calculate the proposer lookahead at the start of epoch <code>N+MIN_SEED_LOOKAHEAD</code>. However, this approach would require additional footprint in the beacon state, and would not be able to provide the proposer lookahead to the EVM via the beacon root.</p> <h3 id="single-secret-leader-election-compatibility">Single Secret Leader Election Compatibility</h3> <p>In the future, we may introduce a Single Secret Leader Election (SSLE) mechanism in which only the selected validator knows their role until they propose a block. However, current SSLE designs still rely on a lookahead, albeit an encrypted one. In such designs, we could reuse the <code>proposer_lookahead</code> field by changing its type to something like <code>List[EncryptedValidatorIndex]</code>. And if a construction were to remove lookahead entirely, we could simply set <code>proposer_lookahead</code> to an empty list, meaning this wouldn’t be a blocker.</p> <p>That said, any such changes would introduce additional complexity around preconfirmation protocols, but that complexity arises regardless of this EIP. Furthermore, APS (Attester Proposer Separation) envisions more sophisticated (i.e., more DDoS‑resistant) execution proposers, reducing the need for SSLE.</p> <h3 id="added-computation-at-the-epoch-boundary">Added Computation at the Epoch Boundary</h3> <p>Before this EIP, consensus clients only needed to compute the current proposer’s index at each slot. With the changes introduced by this EIP, they must calculate the entire epoch’s proposer schedule at the start of each epoch. However, computing the proposer index is light, involving sampling validators until we reach a validator with sufficient effective balance to be selected as a proposer. Still, testing is needed to confirm that these additional calculations do not create performance bottlenecks in practice.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>See <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/cbaa0063979168a94a9c7821f366c6a221319c8e/tests/core/pyspec/eth2spec/test/fulu">the spec tests</a> in consensus-specs.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="malicious-lookahead-alteration">Malicious Lookahead Alteration</h3> <p>A critical consideration for any proposer election mechanism is preventing validators from manipulating lookahead to gain an unfair advantage. This proposal does not increase the chances of such attacks, as we do not alter the “RANDAO delay” used in the lookahead—the lookahead of epoch <code>N</code> is still determined by the RANDAO of epoch <code>N - MIN_SEED_LOOKAHEAD - 1</code> (which becomes available at the start of epoch <code>N - MIN_SEED_LOOKAHEAD</code>). The only difference is that it changes the “effective balances delay”: rather than using the effective balances (EB) at the start of epoch <code>N</code>, it now uses the EB at the start of epoch <code>N - MIN_SEED_LOOKAHEAD</code>.</p> <p>Furthermore, by aligning the RANDAO and effective balances in this way, the proposal removes any chance of validators adjusting their EB after seeing the RANDAO outcome, which is an attack vector to consider. No such attack has been found so far, but this change removes the possibility, hence simplifying the security analysis.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin Mike Neuderhttps://github.com/michaelneuder Mallesh Paihttps://github.com/Mmp610 https://wg-eips.ritovision.com/7922/

Update the validator exit process by dynamically adjusting the churn limit based on historical validator exits.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes updating Ethereum's validator exit churn calculation by dynamically adjusting the churn limit at the start of each 256-epoch period ("generation") based on historical validator exits. Specifically, the maximum churn allowed in each generation will adjust according to the unused churn from the past 16 generations. This approach reduces validator wait times during periods of high exit demand <em>without sacrificing network safety</em>.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum currently implements a fixed, rate-limited queue for validator exits to ensure the security and stability of the network. The exit queue ensures the economic security of transactions finalized by the validator set. Suppose a malicious validator could immediately exit the set without any delay. In that case, they may attempt to execute a double spend attack by publishing a block while withholding a conflicting block, which they release after their stake has exited the protocol. The slashing mechanism can no longer hold the malicious validator accountable, and two conflicting finalized transactions may exist (if the attacker has 1/3 of the total stake and successfully splits the 2/3 honest majority in half).</p> <p>The <code>CHURN_LIMIT_QUOTIENT=2^16</code> was selected according to the rough heuristic that it should take approximately one month for 10% of the stake to exit. With 1,053,742 validators, we have a churn limit of 16 exits per epoch. 225 epochs per day $\implies$ 3600 exits per day $\implies$ 108,000 exits per 30 days. Then 108,000/1,053,742 $\approx$ 0.10. We can interpret this as "<em>the economic security of a finalized transaction decreases by no more than 10% within one month</em>."</p> <p>Another way of understanding the 16 exits per epoch security model is that it encodes the following constraints around validator exits:</p> <ol> <li>at most 16 validators exit in the next one epoch, and</li> <li>at most 32 validators exit in the next two epochs, and</li> <li>at most 48 validators exit in the next three epochs, and ...</li> <li>at most 16 $\cdot$ n validators exit in the next n epochs.</li> </ol> <p>While these constraints are simple to understand, the fixed per-epoch churn limit can result in unnecessarily long validator withdrawal delays during periods of higher-than-average exit demand, such as during institutional liquidations or market events. We argue that we should choose a <em>single</em> constraint from the above set and implement that flexibly.</p> <p>We illustrate this with an example. With one million validators, the current protocol specifies that 16 validators may exit per epoch. Over two weeks, this corresponds to 50,400 exits. This translates directly to "no more than 5.04% of the validators (equiv. stake) can exit within two weeks." Now imagine that in the past 13 days, no validators have exited the protocol, and thus, none of the two-week churn limit has been used. If a large staking operator with 3% of the validator set (30,000 validators) seeks to withdraw immediately, they should be able to -- this doesn't violate the two-week limit of 5.04%. However, since only 16 exits can be processed per epoch moving forward, they are forced to wait 1875 epochs (equiv. 8.33 days).</p> <blockquote> <p><strong>Key observation:</strong> If we enable the protocol to <em>look backward</em> at the exit history, we no longer need the per-epoch limit <em>looking forward</em>.</p> </blockquote> <p>For example, say we chose the following constraint explicitly:</p> <blockquote> <p><strong>Proposed weak subjectivity constraint:</strong> <em>No more than 50,400 exits in two weeks.</em></p> </blockquote> <p>Then, we only need to ensure that the constraint is honored over every rolling two-week window without setting a hard cap on exits during every epoch. A dynamically adjusted churn limit based on historical validator exit data allows Ethereum to flexibly accommodate spikes in exit demand while <em>preserving the same security over every two-week window</em>. By tracking the unused churn capacity of recent generations (periods), we can safely increase the churn limit when the network consistently operates below capacity, significantly improving the validator exit experience.</p> <h2 id="specification">Specification</h2> <p>Since the validator exit process is complex, we start with the stack trace and a verbal description of the end-to-end process in Electra.</p> <ol> <li><code>initiate_validator_exit</code> – a validator signals their intent to exit, which is actuated by setting <code>validator.exit_epoch</code> and <code>validator.withdrawable_epoch</code> based on the output of <code>compute_exit_epoch_and_update_churn</code>.</li> <li><code>compute_exit_epoch_and_update_churn</code> – is used to determine the exit epoch of a validator. This function implements the exit queue in the following way: <ul> <li><code>get_balance_churn_limit</code> - returns the amount of withdrawable ETH per epoch by dividing the total active balance by 2**16.</li> <li>set <code>exit_balance_to_consume</code> to the churn available in the current furthest epoch where some exits will be processed.</li> <li>if <code>exit_balance &gt; exit_balance_to_consume</code>, then we calculate the number of extra epochs the exit consumes to set the final <code>exit_epoch</code>.</li> </ul> </li> </ol> <p>This EIP changes how the churn limit and exit epochs are calculated by examining the number of exits in the previous 14 generations.</p> <ol> <li><code>get_exit_churn_limit</code> – implements the new churn limit calculation by summing over historical generations. <ul> <li><code>per_epoch_exit_churn</code> is set using <code>get_activation_exit_churn_limit</code> as today by dividing the total stake by 2**16 and capping the result at 256 ETH. With today's numbers, this returns 256 ETH that can churn per epoch.</li> <li><code>per_generation_exit_churn</code> is set by multiplying the per epoch exit churn by 256 (the number of epochs in a generation). With today's numbers, this is 256 $\cdot$ 256 = 65536 ETH that can churn per generation.</li> <li><code>total_unused_exit_churn</code> is calculated by looping through the past generations and summing the amount of unused capacity, <code>per_generation_exit_churn - churn_usage</code>.</li> <li>The final returned value is capped at <code>per_epoch_exit_churn * 8</code>. With today's numbers, this max is 256 $\cdot$ 8 = 2048 ETH per epoch.</li> </ul> </li> <li><code>compute_exit_epoch_and_update_churn</code> – is modified to use <code>get_exit_churn_limit</code> and account for any churn consumed in the generation where the exit will be processed.</li> </ol> <h3 id="definitions">Definitions</h3> <ul> <li><strong>Generation</strong>: A period consisting of 256 epochs.</li> <li><strong>Historical Churn Vector</strong>: A fixed-size array (<code>exit_churn_vector</code>) that records the total amount of churned ETH in the previous 16 generations.</li> <li><strong>Unused Churn</strong>: The difference between the maximum possible churn and the actual churn that occurred within a generation.</li> </ul> <h3 id="preset">Preset</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>EPOCHS_PER_CHURN_GENERATION</code></td><td><code>uint64(2**8)</code> (= 256)</td><td>~27 hours</td></tr> <tr><td><code>GENERATIONS_PER_EXIT_CHURN_VECTOR</code></td><td><code>uint64(2**4)</code> (= 16)</td><td>~18 days</td></tr> <tr><td><code>GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</code></td><td><code>uint(2**1)</code> (= 2)</td><td></td></tr> <tr><td><code>EXIT_CHURN_SLACK_MULTIPLIER</code></td><td><code>uint(2**3)</code> (= 8)</td><td></td></tr> </tbody></table> <h3 id="new-state-variables">New State Variables</h3> <p>Add the following to the state:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>exit_churn_vector</span><span>:</span><span> Vector</span><span>[</span><span>uint64</span><span>,</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> total exited balance per generation for GENERATIONS_PER_EXIT_CHURN_VECTOR generations</span></span></code></pre><h3 id="initialization">Initialization</h3> <p>Upon activation of this EIP, initialize new variables:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Mark the churn of each generation as fully consumed</span></span> <span class="giallo-l"><span>state</span><span>.</span><span>exit_churn_vector</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">UINT64_MAX</span><span>]</span><span class="z-keyword"> *</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Update lookahead generations</span></span> <span class="giallo-l"><span>earliest_exit_epoch_generation</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span>current_epoch_generation</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span>lookahead_generation</span><span class="z-keyword"> =</span><span> current_epoch_generation</span><span class="z-keyword"> +</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</span></span> <span class="giallo-l"><span class="z-keyword">for</span><span> generation</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>current_epoch_generation</span><span>,</span><span> lookahead_generation</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> earliest_exit_epoch_generation</span><span class="z-keyword"> &lt;</span><span> generation</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_churn_vector</span><span>[</span><span>generation</span><span class="z-keyword"> %</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span><span>]</span><span class="z-keyword"> =</span><span> uint64</span><span>(</span><span class="z-constant">0</span><span>)</span></span></code></pre> <p><em>Design note:</em> Max out churn usage for the past generations as it is unknown; update the current and lookahead generations according to the <code>state.earliest_exit_epoch</code> generation.</p> <h3 id="new-functions">New Functions</h3> <h4 id="epoch-processing">Epoch Processing</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_historical_exit_churn_vector</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> current_epoch</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span> next_epoch</span><span class="z-keyword"> =</span><span> current_epoch</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> current_epoch_generation</span><span class="z-keyword"> =</span><span> current_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span> earliest_exit_epoch_generation</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> next_epoch_generation</span><span class="z-keyword"> =</span><span> next_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Update the vector if switching over to the next generation.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> next_epoch_generation</span><span class="z-keyword"> &gt;</span><span> current_epoch_generation</span><span>:</span></span> <span class="giallo-l"><span> lookahead_generation</span><span class="z-keyword"> =</span><span> next_epoch_generation</span><span class="z-keyword"> +</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</span></span> <span class="giallo-l"><span> lookahead_generation_index</span><span class="z-keyword"> =</span><span> lookahead_generation</span><span class="z-keyword"> %</span><span class="z-constant"> GENERATIONS_PER_HISTORICAL_CHURN_VECTOR</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> earliest_exit_epoch_generation</span><span class="z-keyword"> &lt;</span><span> lookahead_generation</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If earliest_exit_epoch is earlier than the lookahead generation,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> reset its churn usage to 0,</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_churn_vector</span><span>[</span><span>lookahead_generation_index</span><span>]</span><span class="z-keyword"> =</span><span> uint64</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> otherwise, mark the lookahead generation churn as fully consumed.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>historical_exit_churn_vector</span><span>[</span><span>lookahead_generation_index</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> UINT64_MAX</span></span></code></pre> <p><em>Design note</em>: This function resets the lookahead generation churn upon switching to the next generation. If <code>state.earliest_exit_epoch</code> falls into the generation earlier than the lookahead, the lookahead generation churn usage is reset. Otherwise, it is marked as fully used.</p> <h4 id="get-exit-churn-limit"><code>get_exit_churn_limit</code></h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_exit_churn_limit</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span> Gwei</span><span>:</span></span> <span class="giallo-l"><span> current_epoch</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>state</span><span>.</span><span>earliest_exit_epoch</span><span>,</span><span> compute_activation_exit_epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> per_epoch_exit_churn</span><span class="z-keyword"> =</span><span> get_activation_exit_churn_limit</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the earliest_exit_epoch generation is beyond the lookahead,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> don&#39;t use the slack.</span></span> <span class="giallo-l"><span> current_generation</span><span class="z-keyword"> =</span><span> current_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span> lookahead_generation</span><span class="z-keyword"> =</span><span> current_generation</span><span class="z-keyword"> +</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</span></span> <span class="giallo-l"><span> earliest_exit_epoch_generation</span><span class="z-keyword"> =</span><span> earliest_exit_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> earliest_exit_epoch_generation</span><span class="z-keyword"> &gt;</span><span> lookahead_generation</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> per_epoch_exit_churn</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute churn leftover from past generations.</span></span> <span class="giallo-l"><span> past_generations</span><span class="z-keyword"> =</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span><span class="z-keyword"> -</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> current_generation</span><span class="z-keyword"> &gt;</span><span> past_generations</span><span>:</span></span> <span class="giallo-l"><span> oldest_generation</span><span class="z-keyword"> =</span><span> current_generation</span><span class="z-keyword"> -</span><span> past_generations</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> oldest_generation</span><span class="z-keyword"> =</span><span> uint64</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> per_generation_exit_churn</span><span class="z-keyword"> =</span><span> per_epoch_exit_churn</span><span class="z-keyword"> *</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span> total_unused_exit_churn</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> generation</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>oldest_generation</span><span>,</span><span> current_generation</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> generation_index</span><span class="z-keyword"> =</span><span> generation</span><span class="z-keyword"> %</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span></span> <span class="giallo-l"><span> churn_usage</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>exit_churn_vector</span><span>[</span><span>generation_index</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> churn_usage</span><span class="z-keyword"> &lt;</span><span> per_generation_exit_churn</span><span>:</span></span> <span class="giallo-l"><span> total_unused_exit_churn</span><span class="z-keyword"> +=</span><span> per_generation_exit_churn</span><span class="z-keyword"> -</span><span> churn_usage</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Limit churn slack per epoch.</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> max</span><span>(</span><span>total_unused_exit_churn</span><span class="z-keyword"> +</span><span> per_epoch_exit_churn</span><span>,</span></span> <span class="giallo-l"><span> per_epoch_exit_churn</span><span class="z-keyword"> *</span><span class="z-constant"> EXIT_CHURN_SLACK_MULTIPLIER</span><span>)</span></span></code></pre> <p><em>Design note:</em> Given churn usage for past generations and current epoch churn size estimates the churn leftover from past generations. Caps the returned churn at <code>per_epoch_exit_churn * EXIT_CHURN_SLACK_MULTIPLIER</code>.</p> <h3 id="modified-functions">Modified Functions</h3> <p>Replace the existing <code>compute_exit_epoch_and_update_churn</code> function with this simplified MINSLACK-inspired version:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_exit_epoch_and_update_churn</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> exit_balance</span><span>:</span><span> Gwei</span><span>)</span><span> -&gt;</span><span> Epoch</span><span>:</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>state</span><span>.</span><span>earliest_exit_epoch</span><span>,</span><span> compute_activation_exit_epoch</span><span>(</span><span>get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Modified in [EIP-XXXX]</span></span> <span class="giallo-l"><span> per_epoch_churn</span><span class="z-keyword"> =</span><span> get_exit_churn_limit</span><span>(</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New epoch for exits.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> &lt;</span><span> earliest_exit_epoch</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> per_epoch_churn</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>exit_balance_to_consume</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Exit doesn&#39;t fit in the current earliest epoch.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> exit_balance</span><span class="z-keyword"> &gt;</span><span> exit_balance_to_consume</span><span>:</span></span> <span class="giallo-l"><span> balance_to_process</span><span class="z-keyword"> =</span><span> exit_balance</span><span class="z-keyword"> -</span><span> exit_balance_to_consume</span></span> <span class="giallo-l"><span> additional_epochs</span><span class="z-keyword"> =</span><span> (</span><span>balance_to_process</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> //</span><span> per_epoch_churn</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span class="z-keyword"> +=</span><span> additional_epochs</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span class="z-keyword"> +=</span><span> additional_epochs</span><span class="z-keyword"> *</span><span> per_epoch_churn</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Consume the balance and update state variables.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_balance_to_consume</span><span class="z-keyword"> =</span><span> exit_balance_to_consume</span><span class="z-keyword"> -</span><span> exit_balance</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> =</span><span> earliest_exit_epoch</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> New in [EIP-XXXX]</span></span> <span class="giallo-l"><span> current_epoch_generation</span><span class="z-keyword"> =</span><span> current_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span> exit_epoch_generation</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>earliest_exit_epoch</span><span class="z-keyword"> //</span><span class="z-constant"> EPOCHS_PER_CHURN_GENERATION</span></span> <span class="giallo-l"><span> current_generation_index</span><span class="z-keyword"> =</span><span> current_epoch_generation</span><span class="z-keyword"> %</span><span class="z-constant"> GENERATIONS_PER_HISTORICAL_CHURN_VECTOR</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Record churn usage only if exit falls into the lookahead period</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> and the exit epoch generation churn isn&#39;t fully used.</span></span> <span class="giallo-l"><span> lookahead_generation</span><span class="z-keyword"> =</span><span> current_epoch_generation</span><span class="z-keyword"> +</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_LOOKAHEAD</span></span> <span class="giallo-l"><span> exit_epoch_generation_index</span><span class="z-keyword"> =</span><span> exit_epoch_generation</span><span class="z-keyword"> %</span><span class="z-constant"> GENERATIONS_PER_EXIT_CHURN_VECTOR</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>exit_epoch_generation</span><span class="z-keyword"> &lt;=</span><span> lookahead_generation</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> state</span><span>.</span><span>historical_exit_churn_vector</span><span>[</span><span>exit_epoch_generation_index</span><span>]</span><span class="z-keyword"> &lt;</span><span class="z-constant"> UINT64_MAX</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>exit_churn_vector</span><span>[</span><span>exit_epoch_generation_index</span><span>]</span><span class="z-keyword"> +=</span><span> exit_balance</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>earliest_exit_epoch</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>As we described earlier, by computing unused churn from the previous 14 generations, the churn limit dynamically responds to actual validator behavior. This mechanism:</p> <ul> <li>Reduces validator waiting times during periods of congestion.</li> <li>Ensures security by restricting maximum churn limit increases.</li> <li>Simplifies implementation compared to more complex dynamic mechanisms.</li> </ul> <p>A generation length of 256 epochs (~27 hours) and a history of 14 generations (~16 days) balances responsiveness and stability, enabling Ethereum to adapt smoothly to sustained changes in validator exit behavior.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Validator exit constraints remain crucial for Ethereum's accountable safety. This proposal maintains the core safety guarantee by strictly limiting the increase of the churn limit.</li> <li>The maximum churn limit is capped at eight times the current fixed churn, ensuring safety assumptions hold even in worst-case scenarios.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0.</p> 2025-03-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anders Elowssonhttps://github.com/anderselowsson https://wg-eips.ritovision.com/7915/

Fee schedule accounting for the long-run average to quickly restore equilibrium under inelastic demand

<h2 id="abstract">Abstract</h2> <p>Reworks the excess blob gas update in <code>calc_excess_blob_gas()</code> so that the blob base fee rises relatively more during high gas usage than it falls during low usage whenever the current fee is below the long-run average. This establishes a smoothly adapting, neutral lower bound for the base fee. The exponential moving average (EMA) is computed in the linear domain and stored as a header variable.</p> <h2 id="motivation">Motivation</h2> <p>Demand for blobspace is fee-inelastic, leading to a blob base fee that may fluctuate excessively with minor shifts in aggregate demand. The lower end of the fee range of 1 wei is under current circumstances economically inconsequential, but can be reached after a period of blocks consuming fewer blobs than the target. During increases in demand, the existing fee mechanism requires sustained periods of near-full blocks to re-establish equilibrium. This exacerbates spikiness in resource consumption, which can hamper efficient scaling of throughput. Furthermore, users may intermittently need to compete in a first-price auction for inclusion, degrading UX. The appropriate fee range will inadvertently vary going forward due to changes in the ETH token price and circulating supply, as well as the protocol's ability to scale throughput. To remain neutral and future-proof, the operational range should be established relative to the long-run average fee, smoothly affecting the equilibrium quantity of blobs consumed. Thus, this EIP introduces a new fee update mechanism that accounts for the long-run average fee when responding to shifts in demand. This allows the protocol to quickly converge to desirable equilibria while also remaining neutral and future-proof.</p> <p><img src="https://wg-eips.ritovision.com/7915/./assets/1.png" alt="Figure 1" /></p> <p><strong>Figure 1.</strong> Response to various blob quantities for the proposed fee mechanism (green), the current mechanism (black), and the threshold mechanism of <a href="https://wg-eips.ritovision.com/7762/">EIP-7762</a> (red). The proposed mechanism smoothly converges to appropriate equilibria when demand shifts, establishing the fee relative to the long-run average base fee $\bar{f}_g$ (at 4 gwei in this example). The fee adapts faster when converging toward $\bar{f}_g$ from below than when diverging from it.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th><th>Short description</th></tr></thead><tbody> <tr><td><code>EMA_DECAY</code></td><td><code>2**18</code></td><td>Reciprocal of the EMA decay rate (per slot)</td></tr> <tr><td><code>MEAN_REVERSION_DEADBAND</code></td><td><code>64</code></td><td>Fee ratio at which mean reversion effect accelerates</td></tr> <tr><td><code>MEAN_REVERSION_FULLBAND</code></td><td><code>10**6</code></td><td>Fee ratio at which mean reversion effect stops increasing</td></tr> </tbody></table> <h3 id="functions">Functions</h3> <p>The function <code>calc_excess_blob_gas()</code> from <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> is updated. A mean reversion weight <code>w</code> is computed based on the ratio between the long-run base fee and the current base fee. The weight influences the excess gas update by smoothly increasing the gas used and decreasing the gas target as the current base fee falls below the long-run base fee (see Figure 2 below). The variable <code>Up</code> upsamples <code>w</code> to retain precision. Note that the function applies <code>integer_squareroot()</code>, which must be implemented at the execution layer; it is currently implemented at the consensus layer. Thresholding at <code>MEAN_REVERSION_FULLBAND</code> and strategic deployment of <code>Up</code> allows the mechanism to rely on the <code>uint64</code> type internally.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> &lt;</span><span class="z-constant"> TARGET_BLOB_GAS_PER_BLOCK</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute upsampled mean reversion weight w based on the EMA fee ratio</span></span> <span class="giallo-l"><span> Up</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">16</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>parent</span><span>)</span><span class="z-keyword"> &gt;</span><span> parent</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span>:</span></span> <span class="giallo-l"><span> w</span><span class="z-keyword"> =</span><span> Up</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span class="z-keyword"> //</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>parent</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> MEAN_REVERSION_FULLBAND</span><span>:</span></span> <span class="giallo-l"><span> ratio</span><span class="z-keyword"> =</span><span> Up</span><span class="z-keyword"> *</span><span class="z-constant"> MEAN_REVERSION_FULLBAND</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> ratio</span><span class="z-keyword"> =</span><span> Up</span><span class="z-keyword"> *</span><span> parent</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span class="z-keyword"> //</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>parent</span><span>)</span></span> <span class="giallo-l"><span> w</span><span class="z-keyword"> =</span><span> (</span><span>ratio</span><span class="z-keyword"> +</span><span> Up</span><span class="z-keyword"> *</span><span class="z-constant"> MEAN_REVERSION_DEADBAND</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span class="z-constant">MEAN_REVERSION_DEADBAND</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">3</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> w</span><span class="z-keyword"> =</span><span> integer_squareroot</span><span>(</span><span>w</span><span class="z-keyword"> *</span><span> Up</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Return excess blob gas based on adjusted gas usage and target under mean reversion</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> *</span><span> w</span><span class="z-keyword"> //</span><span> Up</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_BLOB_GAS_PER_BLOCK</span><span class="z-keyword"> *</span><span> Up</span><span class="z-keyword"> //</span><span> w</span></span></code></pre> <p>The exponential moving average (EMA) of the base fee is updated based on the previous block's <code>base_fee_per_blob_gas</code> and <code>base_fee_per_blob_gas_ema</code> in a new function:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_base_fee_per_blob_gas_ema</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span class="z-keyword"> +</span></span> <span class="giallo-l"><span> get_base_fee_per_blob_gas</span><span>(</span><span>parent</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> EMA_DECAY</span><span class="z-keyword"> -</span></span> <span class="giallo-l"><span> parent</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span class="z-keyword"> //</span><span class="z-constant"> EMA_DECAY</span></span></code></pre><h3 id="header-extension">Header extension</h3> <p>The current header encoding is extended with the <code>uint</code> field <code>base_fee_per_blob_gas_ema</code>. For the first post-fork block, <code>parent.base_fee_per_blob_gas_ema</code> is evaluated as <code>4*10**9</code> (4 gwei).</p> <h3 id="execution-layer-validation">Execution layer validation</h3> <p>The block validity conditions on the execution layer are extended to assert that <code>base_fee_per_blob_gas_ema</code> was correctly updated:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check that the base fee per blob gas EMA was updated correctly</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>header</span><span>.</span><span>base_fee_per_blob_gas_ema</span><span class="z-keyword"> ==</span><span> calc_base_fee_per_blob_gas_ema</span><span>(</span><span>block</span><span>.</span><span>parent</span><span>.</span><span>header</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="supply-and-demand">Supply and demand</h3> <p>Since the introduction of blobs, the reservation fee of the marginal consumer of blobs has periodically been very low. Whenever demand picks up, a sustained succession of near-full blocks is required to restore equilibrium, with the mechanism intermittently resorting to a first-price auction, considered a worse UX by blob consumers. The resulting spikiness in resource consumption is suboptimal for scaling blobspace. At a fundamental level, the issue is that Ethereum faces a fee-inelastic demand curve while operating a perfectly inelastic supply curve—with supply fixed at <code>TARGET_BLOB_GAS_PER_BLOCK</code>. When an equilibrium forms between fee-inelastic supply and demand curves, even a small shift in aggregate demand can lead to huge shifts in the equilibrium fee. This proposal smoothly increases the elasticity of the supply curve as it diverges from the long-run average, restricting the equilibrium fee from forming much below the average. Combined with the faster fee adjustments in the direction of the average, a desirable equilibrium can then quickly be established during temporary shifts in demand.</p> <p>Supply and demand are not fixed, and the appropriate equilibrium will inadvertently shift in the future due to changes in the ETH token price and circulating supply, as well as the protocol's ability to scale throughput. To remain neutral and future-proof, the pricing mechanism should therefore operate on a relative basis, ideally then anchored to the computed long-run average.</p> <p>When demand fails to meet supply, a producer can reduce the unit price or decrease the quantity supplied to re-establish equilibrium. If it sells unique goods but seeks to avoid inefficiencies from either idle capacity or excessive resource use, it can gradually reduce both, smoothly moving along its expansion path to attain the optimal equilibrium under the given demand curve. Ethereum can respond to <em>temporary downturns</em> in demand by gradually reducing both price <em>and</em> equilibrium throughput, smoothly reducing the number of consumed blobs at which the price remains fixed. This is achieved by adjusting the fee update to smoothly become less responsive to low gas usage, implicitly controlling output. Ethereum cannot respond to <em>sustained downturns</em> in demand by reducing throughput, because such a downturn could imply that circumstances have changed, and that the price is now <em>too high</em> (assuming the protocol remains neutral). To be clear, Ethereum reduces throughput already today during downturns in demand by thresholding at 1 wei. Any fixed threshold that prevents the price from falling further once reached reduces throughput by not allowing blocks with below-threshold gas usage to influence the future fee. However, an instant shift from a fixed response schedule to complete unresponsiveness under a below-target demand presumably does not reflect the protocol's blobspace production expansion path (see also Figure 1).</p> <h3 id="proposed-base-fee-update-schedule">Proposed base fee update schedule</h3> <p>The update schedule adheres to the following design principles:</p> <ul> <li>Remain neutral and future-proof concerning changes in supply and demand.</li> <li>Rely on the normal fee update schedule when the base fee is above or just slightly below the long-run average.</li> <li>Smoothly adjust the fee update to become less responsive to low gas usage and more responsive to high gas usage as the ratio $\bar{f}_g/f_g$ grows.</li> <li>When the price is relatively low ($f_g&lt;\bar{f}_g$), raise the fee quickly during a rise in demand and reduce it slowly during a fall in demand. In other words, add a mean reversion effect (this is closely related to the previous point).</li> <li>The fee update must vary smoothly with blob quantity at all applicable $\bar{f}_g/f_g$ ratios so that users or validators will not strategically include specific quantities of blobs in each block.</li> <li>Avoid extreme responses even if the ratio $\bar{f}_g/f_g$ diverges substantially.</li> </ul> <p>A mean reversion weight is first computed</p> <p>$$ w = \sqrt[8]{\frac{\bar{f}_g/f_g + D}{D+1}}, $$</p> <p>where $D$ is the constant <code>MEAN_REVERSION_DEADBAND</code>, set to 64. The eighth root can be computed by applying the existing (at the consensus layer) function <code>integer_squareroot()</code> three times. The update to the excess gas field $e_g$ for slot $n$ is then changed from</p> <p>$$ e_{g(n)} = e_{g(n-1)} + c_g - t_g $$</p> <p>to</p> <p>$$ e_{g(n)} = e_{g(n-1)} + c_gw - t_g/w. $$</p> <p>Figure 2 illustrates the resulting fee update schedule when applying the blob targets from Pectra. The further the fee falls below the average, the fewer blobs must be consumed for the fee to remain fixed. This eventually leads to equilibrium being established, even under low demand. The transition is gradual, allowing for a smooth response to shifts in demand. Note that the vertical blob spacing is kept smooth at all ratios, discouraging users or validators to strategically adapt intra-block consumption of blobs.</p> <p><img src="https://wg-eips.ritovision.com/7915/./assets/2.png" alt="Figure 2" /></p> <p><strong>Figure 2.</strong> Proposed blob fee update schedule across the $f_g/\bar{f}_g$ ratio under Pectra blob constants. When the ratio is around or above 1, the baseline fee update schedule is applied. When the fee falls below the average, fewer blobs must be consumed for the fee to remain fixed.</p> <p>The fee schedule is computed across the range <code>MEAN_REVERSION_FULLBAND = 10**6</code>. Thus, if the ratio in Figure 2 falls below $10^{-6}$, the schedule at $10^{-6}$ applies. This approach protects against exploding fee schedules, allows the fee to gradually fall further if no blobs at all are consumed, and protects against overflow due to high ratios (thus allowing for the smaller <code>uint64</code> in the <code>calc_excess_blob_gas()</code> function). Optionally, the operational region can also be bounded by adding a constant $c$ (set in the region of 1-2 blobs worth of gas) to the fee update schedule:</p> <p>$$ e_{g(n)} = e_{g(n-1)} + c_gw - t_g/w + c(w-1). $$</p> <p>The mechanism only applies mean reversion when $f_g &lt; \bar{f}_ g.$ While there can be benefits from mean reversion in both directions, the case when $f_g&lt;\bar{f}_ g$ is far more important to address. Furthermore, the update schedule from <a href="https://wg-eips.ritovision.com/7691/">EIP-7691</a>, applied when $f_g \geq \bar{f}_g$, already decreases more with 0 blobs than it increases with the maximum.</p> <p>A symmetrical update schedule at ratios around 1 was initially considered since the target from Pectra is not centered at <code>MAX_BLOB_GAS_PER_BLOCK/2</code>. However, a well-formed symmetrical fee update schedule will likely not achieve a <code>TARGET_BLOB_GAS_PER_BLOCK</code> throughput, even though it responds to a target gas consumption by keeping the fee fixed. The reason is that the fee update for blocks $x$ blobs above the target and $x$ blobs below the target will not be reciprocal. Equilibrium would therefore settle at slightly lower throughput than <code>TARGET_BLOB_GAS_PER_BLOCK</code>, at a slightly higher price than when relying on the assymetrical update schedule with an identical target. The proposed fee update schedule instead intermediately transitions to a symmetrical schedule as the fee ratio falls (see Figure 2).</p> <h3 id="computing-the-long-run-average-base-fee">Computing the long-run average base fee</h3> <p>An average of the base fee $\bar{f}_g$ is maintained in the header variable <code>base_fee_per_blob_gas_ema</code>, computed as an exponential moving average. Each slot, $\bar{f}_g$ is updated by taking</p> <p>$$ \bar{f}_ {g(n)} = \bar{f}_ {g(n-1)} + \frac{f_{g(n-1)} - \bar{f}_{g(n-1)}}{m}, $$</p> <p>where $m$ is a constant <code>EMA_DECAY=2**18</code>. This setting gives a half-life of around one month. If the <code>EMA_DECAY</code> is set slightly higher, the mechanism is guaranteed to influence blob pricing over the next few years. For example, initializing $\bar{f}_ g=4\times10^9$ (as proposed) and setting a half-life of four months (<code>EMA_DECAY=2**20</code>) ensures that $\bar{f}_ g&gt;5\times10^8$ one year after activation. If the proposed mechanism is included in a hard fork that also boosts throughput, this could be seen as a bonus, given the smooth floor operating a few orders of magnitude below $\bar{f}_ g$.</p> <p>Figure 3 shows how $\bar{f}_{g}$ would have evolved between November 2024 and March 2025, using $4\times10^9$ as a starting value. Note that the EMA fee could be allowed to fall below <code>EMA_DECAY</code> by subtracting at least 1 in each update step (this is however not part of the functionality in the specification).</p> <p>The EMA is computed in the linear domain to preserve additivity and maintain interpretability. Averaging in the log-domain across excess gas (akin to a geometric mean in the linear domain) would give undue influence to fine-grained fluctuations at lower fees. This would make changes at lower gas thresholds very influential, creating feedback loops that are hard to explain and reason about; especially since the threshold at 1 wei always will be fixed and gradually could come into play over the long run due to shifts in supply or demand. However, note that while it is strictly preferred to compute the EMA in the linear domain, it would be possible to convert back to the log-domain to store and apply an excess blob gas EMA. This option is described in the next subsection.</p> <p><img src="https://wg-eips.ritovision.com/7915/./assets/3.png" alt="Figure 3" /></p> <p><strong>Figure 3.</strong> Exponential moving average with the proposed settings applied to a few months of historical blob base fee data.</p> <h3 id="alternative-approach">Alternative approach</h3> <p>One alternative way to structure the adaptive mean reversion was referenced in the previous subsection and will be described here. It differs in that that the protocol would rely on and store a log-domain representation of <code>base_fee_per_blob_gas_ema</code>: <code>excess_blob_gas_ema</code>. The EMA computation would still be performed in the linear domain, but <code>get_base_fee_per_blob_gas()</code> and its inverse—relying on a new <code>fake_log()</code> function—would be applied during computations to first go to the linear domain and then return to the log-domain</p> <p>$$ \bar{e}_ {g(n)} = \log\Biggl[\exp\bigl(\bar{e}_ {g(n-1)}\bigr) + \frac{\exp\bigl(e_ {g(n-1)}\bigr) - \exp\bigl(\bar{e}_ {g(n-1)}\bigr)}{m}\Biggr]. $$</p> <p>The weight calculation in <code>calc_excess_blob_gas()</code> could then be performed in the log-domain, in principle:</p> <p>$$ w = \frac{\bar{e}_g-e_g + D}{D+1}, $$</p> <p>but where, e.g., $D$ would be adjusted according to relevant excess gas scaling for the applicable hard fork. The fee update schedule would become very similar with both approaches, and the choice thus mostly comes down to architectural preferences.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The blob base fee doubles during full blocks if the current fee is several orders of magnitude below the average. As a result, a single-block delay in inclusion results in users paying twice as much, potentially influencing inclusion and fee-market strategies. However, practical implications should be limited, given that this aggressive fee schedule only operates at fees well below the average.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ryo Hahttps://github.com/sopia19910sopia19910@gmail.com Khajiev Nizomjonhttps://github.com/khajievNnizom7812@gmail.com https://wg-eips.ritovision.com/7911/

Improving Ethereum scalability and privacy using Perceptron Trees to compress transaction data via ZKP.

<h2 id="abstract">Abstract</h2> <p>This project proposes a method to enhance scalability and privacy protection in the Ethereum network using a Perceptron Tree-based Zero-Knowledge Proof (ZKP) model. The Perceptron Tree, a hybrid model combining the strengths of decision trees and perceptron neural networks, provides a compressed representation for transaction relationships, facilitating efficient verification. It addresses specific drawbacks of existing zk-SNARK and zk-STARK methods, consolidating multiple transactions into a single proof to reduce gas fees and decrease on-chain verification load.</p> <h2 id="motivation">Motivation</h2> <p>The significant increase in blockchain transactions has resulted in scalability limitations and privacy issues. Existing ZKP methods effectively validate individual transactions but fall short in analyzing inter-transaction relationships while maintaining privacy.</p> <p>ZK-Rollups bundle multiple transactions off-chain into a single proof submitted to the Ethereum mainnet, improving throughput and reducing costs. However, current batching approaches verify transactions individually without leveraging inter-transaction patterns or relationships.</p> <p>Existing privacy solutions generate separate ZK proofs for each transaction, limiting ZKP's full potential. The proposed Perceptron Tree model overcomes these limitations by measuring the similarity among multiple transactions and compressing them into a unified proof, thus broadening ZKP applications.</p> <h2 id="specification">Specification</h2> <h3 id="1-tree-construction">1. Tree Construction</h3> <p>The system inputs a transaction dataset T = {x₁, x₂, ..., xₙ} to construct a recursive tree.</p> <ul> <li> <p>Each node classifies transaction data using a perceptron with a linear function:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>f(x) = step(Wₐ·a + Wᵦ·b + θ)</span></span></code></pre> <p>where the step function is defined as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>step(z) = {</span></span> <span class="giallo-l"><span> 1, if z ≥ 0</span></span> <span class="giallo-l"><span> 0, if z &lt; 0</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p><img src="https://wg-eips.ritovision.com/7911/./assets/20250319_203521.png" alt="Perceptron Tree ZKP Process" /></p> </li> <li> <p>Tree construction recursively partitions nodes based on conditions like homogeneity (isPure) or maximum depth (maxDepth).</p> <p><img src="https://wg-eips.ritovision.com/7911/./assets/20250319_203546.png" alt="Perceptron Tree ZKP Process" /></p> </li> </ul> <h3 id="2-relationship-similarity-calculation">2. Relationship Similarity Calculation</h3> <h4 id="path-similarity">Path Similarity</h4> <p>Measures similarity by the ratio of shared paths between two transactions within the tree:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>sim_path(xᵢ, xⱼ) = d/D</span></span></code></pre> <p>Where:</p> <ul> <li>d = length of shared path</li> <li>D = maximum depth of the tree</li> </ul> <p><img src="https://wg-eips.ritovision.com/7911/./assets/20250319_203429.png" alt="Path Similarity Example" /></p> <p>Example: If transactions x₁ and x₂ share only the root node (d=1) in a tree of depth 3, their similarity would be 1/3 ≈ 0.33.</p> <h4 id="vector-space-similarity">Vector Space Similarity</h4> <p>Uses cosine similarity calculated from the feature vectors of each transaction:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>sim_cos(xᵢ, xⱼ) = (xᵢ·xⱼ)/(‖xᵢ‖‖xⱼ‖)</span></span></code></pre> <p><img src="https://wg-eips.ritovision.com/7911/./assets/20250319_203500.png" alt="Vector Similarity Example" /></p> <p>Example: For vectors x₁ = [0.7, 0.8] and x₂ = [0.9, 0.4], the similarity is 0.91.</p> <h3 id="3-zkp-proof-generation">3. ZKP Proof Generation</h3> <p>The process follows five key steps:</p> <ol> <li> <p><strong>Construct Perceptron Tree</strong>: Build a tree based on transaction set T and train perceptrons at each node.</p> </li> <li> <p><strong>Calculate Node Commitments</strong>: Compute a commitment value Cₙ for each node n using weights Wₙ, bias bₙ, and hashes of left/right child nodes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Cₙ = H(Wₙ, bₙ, Cₗₑₜₜ, Cᵣᵢₑₕₜ)</span></span></code></pre></li> <li> <p><strong>Generate Path Proof</strong>: For a specific transaction xᵢ, demonstrate the classification path within the tree.</p> </li> <li> <p><strong>Prove Similarity Threshold</strong>: Prove that the similarity between two transactions xᵢ and xⱼ exceeds a predefined threshold θ.</p> </li> <li> <p><strong>Construct Final ZKP Proof</strong>: The final Zero-Knowledge Proof Π includes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Π = {Cᵣₒₒₜ, path(xᵢ), sim(xᵢ, xⱼ)}</span></span></code></pre> <p>Where Cᵣₒₒₜ is the root commitment, path(xᵢ) is the path proof of xᵢ, and sim(xᵢ, xⱼ) is the similarity proof between transactions.</p> </li> </ol> <p><img src="https://wg-eips.ritovision.com/7911/./assets/20250319_203626.png" alt="ZKP Generation Process" /></p> <h3 id="4-on-chain-verification">4. On-chain Verification</h3> <p>Smart contracts verify the submitted proof (Π) by checking:</p> <ul> <li> <p>The Cᵣₒₒₜ commitment matches the pre-registered tree root hash</p> </li> <li> <p>The transaction xᵢ is correctly classified along the provided path(xᵢ)</p> </li> <li> <p>The similarity between two transactions meets the predefined threshold θ</p> </li> </ul> <h2 id="rationale">Rationale</h2> <p>The Perceptron Tree-based ZKP model extends the capabilities of existing zero-knowledge proof techniques by incorporating transaction relationships into the proof structure. Traditional zk-SNARK and zk-STARK methods validate individual transactions but do not leverage inter-transaction similarity, which can lead to inefficiencies.</p> <p>By structuring transactions using a Perceptron Tree, this model enables compression of multiple transactions into a single proof, reducing gas fees and improving on-chain verification efficiency. The use of a perceptron-based decision structure ensures adaptability to various transaction patterns, making it a scalable solution for Ethereum.</p> <p>This proposal operates at the smart contract level, requiring no modifications to the existing Ethereum protocol or consensus algorithm. It can be implemented alongside existing transaction verification methods, allowing optional adoption without network upgrades.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li> <p><strong>Privacy Protection</strong>: Verifies transaction validity without revealing specific transaction details.</p> </li> <li> <p><strong>Tamper Resistance</strong>: Uses commitment values based on tree structures and weights to detect data tampering.</p> </li> <li> <p><strong>Replay Attack Prevention</strong>: Includes unique transaction IDs in proofs to avoid replay attacks.</p> </li> <li> <p><strong>Lightweight Verification</strong>: Ensures efficient, simple proof verification operations within smart contracts, minimizing gas fees.</p> </li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper Qi Zhouhttps://github.com/qizhou Matthttps://github.com/lightclient Dragan Rakitahttps://github.com/rakita https://wg-eips.ritovision.com/7907/

Increases the contract code size limit introduced in EIP-170 and adds gas metering to code loading

<h2 id="abstract">Abstract</h2> <p>This EIP increases the contract code size limit from 24KB (24576 bytes) introduced in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> to 64KB (65536 bytes), and adds gas metering for excess code loading. It introduces a gas cost of 2 gas per (32 byte) word for contract code exceeding 24KB, allowing deployment of contracts of any size while preventing DoS attacks through appropriate gas metering. Lastly, it also commensurately increases initcode size limit from 48KB, introduced in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>, to 128KB (131072 bytes).</p> <h2 id="motivation">Motivation</h2> <p>EIP-170 introduced a 24KB contract code size limit to prevent potential DoS attacks, as large contract code requires O(n) resource cost in terms of disk reads, VM preprocessing, and Merkle proof sizes, all of which are not directly compensated by gas fees. However, this limit restricts legitimate use cases for large contracts.</p> <p>This EIP proposes a gas-based solution that allows contracts of larger size while ensuring that users loading large contracts pay gas proportional to the additional resources they consume. This approach aligns with Ethereum's gas model philosophy of paying for the resources consumed. A new limit has been set at 64KB, so that raising the gas limit does not break assumptions in the p2p layer.</p> <p>Improving developer experience is the primary motivation for increasing the contract size limit. The current 24KB ceiling forces developers to split functionality across multiple contracts, introduce proxies or delegatecall-based indirection, and rely on architectural patterns like the Diamond Standard—even when those patterns aren't otherwise necessary. These workarounds can increase code complexity, deployment costs, and audit surface. By raising the limit, developers can keep more logic in a single contract, improving readability and lowering gas usage by avoiding unnecessary cross-contract calls. This also makes smart contract development more accessible to newer developers, who can move from idea to deployment without first learning advanced contract composition patterns.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>COLD_SLOAD_COST</code></td><td><code>2100</code></td><td>The cost charged for cold loading storage as defined by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</td></tr> <tr><td><code>WARM_STORAGE_READ_COST</code></td><td><code>100</code></td><td>The cost charged for loading warm storage as defined by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</td></tr> <tr><td><code>COLD_ACCOUNT_ACCESS_COST</code></td><td><code>2600</code></td><td>The cost charged for loading a cold account as defined by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</td></tr> <tr><td><code>GAS_PER_CODE_WORD</code></td><td><code>2</code></td><td>The cost charged per word of code loaded beyond the initial <code>24KB</code> amount.</td></tr> <tr><td><code>FORK_BLKNUM</code></td><td>TBD</td><td>The block number of the hard fork that this EIP is activated.</td></tr> </tbody></table> <p>The following values are updated:</p> <table><thead><tr><th>Name</th><th>Old Value</th><th>New Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>MAX_CODE_SIZE</code></td><td>24KB (<code>0x6000</code>)</td><td>64KB (<code>0x10000</code>)</td><td>The maximum size for code as set in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a></td></tr> <tr><td><code>MAX_INITCODE_SIZE</code></td><td>48KB (<code>0xc000</code>)</td><td>128KB (<code>0x20000</code>)</td><td>The maximum size for code as set in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>. Always set at <code>2 * MAX_CODE_SIZE</code></td></tr> </tbody></table> <h4 id="helpers">Helpers</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> ceil32</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>(</span><span>n</span><span class="z-keyword"> +</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 32</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> excess_code_size</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> max</span><span>(</span><span class="z-constant">0</span><span>,</span><span> n</span><span class="z-keyword"> -</span><span class="z-storage z-type"> 0x</span><span class="z-constant">6000</span><span>)</span></span></code></pre><h3 id="behavior">Behavior</h3> <ol> <li>Update the <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> introduced <code>MAX_CODE_SIZE</code> constant of 24KB (<code>0x6000</code> bytes) to 64KB (<code>0x10000</code> bytes).</li> <li>Introduces a new cold/warm state for contract code. Specifically, change the gas schedule of operations that load code, e.g. the opcodes <code>CALL</code>, <code>STATICCALL</code>, <code>DELEGATECALL</code>, <code>CALLCODE</code> and <code>EXTCODECOPY</code> are modified so that dynamic <code>EXCESS_CODE_COST= ceil32(excess_code_size(len(code))) * GAS_PER_CODE_WORD // 32</code> gas are added to the access cost if the code is cold. When the code is an <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation to another account, if target account code is cold add additional gas should be accounted. Warming of the contract code is subjected to the journaling and can be reverted similar to other state warming in <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>.</li> <li>Update the <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> introduced <code>MAX_INITCODE_SIZE</code> limit of 48KB (<code>0xc000</code> bytes) to 128KB (<code>0x10000</code> bytes).</li> <li>If a large contract is the entry point of a transaction, the cost calculated in (2) is charged before the execution and contract code is marked as warm. This fee is not calculated towards the initial gas fee. In case of out-of-gas halt, execution will stop and the balance will not be transferred.</li> <li>Empty code ( with <code>keccak("") = "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"</code>) is always considered warm.</li> </ol> <table><thead><tr><th>Contract</th><th>Gas changes (only opcodes that load code)</th><th>How?</th></tr></thead><tbody> <tr><td>Cold account and code</td><td>Add <code>COLD_SLOAD_COST=2100</code>, <code>EXCESS_CODE_COST</code>, and <code>COLD_ACCOUNT_ACCESS_COST=2600</code></td><td>Contract not in access list nor accessed prior in the txn</td></tr> <tr><td>Warm account and cold code</td><td>Add <code>COLD_SLOAD_COST=2100</code>, <code>EXCESS_CODE_COST</code>, and <code>WARM_STORAGE_READ_COST=100</code></td><td>Already accessed balance, storage, or included in access list (<a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>)</td></tr> <tr><td>Warm account and code</td><td><code>WARM_STORAGE_READ_COST=100</code></td><td>Already accessed account code</td></tr> </tbody></table> <p><code>COLD_ACCOUNT_ACCESS_COST</code>, <code>COLD_SLOAD_COST</code>, and <code>WARM_STORAGE_READ_COST</code> are defined in <a href="https://wg-eips.ritovision.com/2929/#parameters">EIP-2929</a>.</p> <h3 id="migration">Migration</h3> <p>This EIP adds a new field to the account tuple, <code>codesize</code>. That is, the account tuple goes from having the following four fields, <code>(nonce, balance, storage_root, code_hash)</code> to <code>(nonce, balance, storage_root, code_hash, codesize)</code>. The reason for this is that most key-value databases in use by production clients do not allow peeking at the size of a value pointed to by a given key without actually loading the full contents of the value.</p> <p>To avoid forcing a full migration, the following rules are followed:</p> <ol> <li>Any account created or updated on or after <code>FORK_BLKNUM</code> should additionally have its codesize written into the account tuple.</li> <li>Any account which does not have the <code>codesize</code> field is assumed to have codesize less than 24KB.</li> </ol> <h2 id="rationale">Rationale</h2> <p>The gas cost of 2 per word was chosen to account for:</p> <ol> <li>The additional disk I/O for retrieving larger contract code</li> <li>The increased computational resources for preprocessing larger code for execution (a.k.a. "JUMPDEST analysis").</li> <li>The growth in Merkle proof sizes for blocks containing larger contracts</li> </ol> <p>This EIP introduces the gas cost as an additional cost for contracts exceeding 24KB. It could have been specified as a simpler <code>ceil32(contract_size) * GAS_PER_CODE_WORD // 32</code>, without hardcoding the existing contract size limit. However, for the sake of being conservative and avoiding lowering the cost of loading existing contracts (which could be small, under the 24KB limit), the 24KB floor was added to the formula.</p> <p>The <code>EXTCODECOPY</code> opcode could theoretically be exempt from this, since clients could just load the parts of the bytecode which are actually requested. However, this might require a change at the protocol level, since the full code is required for the block witness. For this reason, <code>EXTCODECOPY</code> is included in the pricing scheme, and a carveout could be considered at a later date.</p> <p>The new limit has been set at 64KB. The limit has been put in place so that increasing the gas limit won't have unexpected side effects at the db or p2p layer. For instance, in devp2p, the maximum packet size is 10MB (<a rel="external" href="https://github.com/ethereum/devp2p/blob/5713591d0366da78a913a811c7502d9ca91d29a8/caps/eth.md#basic-operation">https://github.com/ethereum/devp2p/blob/5713591d0366da78a913a811c7502d9ca91d29a8/caps/eth.md#basic-operation</a>). As of time of this writing, the maximum packet size in snap sync is even lower, at 96KB.</p> <p>The limit for initcode has also been increased to 128KB, following the pattern set in EIP-3860 that the initcode limit is double the runtime code limit. While initcode is different from deployed code in that it does not live in the state and therefore isn't visible in devp2p or in the db, fully removing the limit could have unforeseen consequences.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces additional gas costs for certain operations. Specifically, <code>CALL</code>, <code>STATICCALL</code>, <code>DELEGATECALL</code>, <code>CALLCODE</code>, <code>EXTCODESIZE</code>, and <code>EXTCODECOPY</code> may now require extra gas when accessing cold contract code.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="reference-implementation">Reference Implementation</h2> <h2 id="security-considerations">Security Considerations</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-03-05T00:00:00+00:00 2026-02-11T14:49:28+00:00 Charles Cooperhttps://github.com/charles-cooper https://wg-eips.ritovision.com/7903/

Removes the initcode size limit introduced in EIP-3860

<h2 id="abstract">Abstract</h2> <p>This EIP proposes the removal of the <code>initcode</code> size limit of 49152 bytes introduced in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>. The restriction complicates deploying multiple contracts addressing the <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> limit (24576 bytes) within a single transaction, while the existing gas metering for <code>initcode</code>, already ensures fair <code>initcode</code> costing, including for <code>JUMPDEST</code> analysis.</p> <h2 id="motivation">Motivation</h2> <p>The EIP-3860 <code>initcode</code> size limit imposes an unnecessary constraint on deployment patterns, particularly for creation transactions creating large <em>logical</em> contracts composed of multiple <em>physical sub-contracts</em> in a single transaction. A key argument for retaining EIP-170's 24KB runtime code limit is that high-level languages (HLLs) should abstract it away. However, the EIP-3860 limit prevents HLLs from cleanly abstracting this, as deploying large logical contracts exceeding 49152 bytes of <code>initcode</code> requires splitting into multiple transactions, undermining the abstraction.</p> <p>Removing the cap simplifies smart contract deployment and enables HLLs to cleanly abstract large contracts, without compromising network security or cost attribution.</p> <h2 id="specification">Specification</h2> <p>Revert the <code>initcode</code> size limit introduced in EIP-3860. Specifically:</p> <ul> <li>Remove the 49152-byte cap on <code>initcode</code> size during contract creation.</li> <li>Retain existing gas costs for <code>initcode</code> execution, including the 2 gas per byte for <code>JUMPDEST</code> analysis, as defined in EIP-3860.</li> </ul> <p>No changes to deployed contract size limits (EIP-170) or gas schedules beyond removing the size restriction are proposed.</p> <h2 id="rationale">Rationale</h2> <p>This proposal is driven by the need to restore flexibility in contract deployment patterns, such as factory contracts creating multiple sub-contracts in one transaction. The design decision to remove the 49152-byte cap leverages the pre-existing gas metering system, which scales linearly with <code>initcode</code> size (i.e., 2 gas per byte), ensuring fair cost attribution without artificial limits.</p> <p>A key justification for EIP-170's 24576-byte limit is that high-level languages (HLLs) should abstract it away. However, EIP-3860's <code>initcode</code> cap undermines this by forcing multi-transaction deployments for large contracts, breaking the abstraction HLLs aim to provide. Removing the cap aligns with this philosophy by enabling single-transaction deployments.</p> <p>Alternative designs, such as increasing the cap (e.g., to 98304 bytes), were considered but rejected as arbitrary; gas metering already mitigates resource concerns. The per-block gas limit already naturally restricts <code>initcode</code> (at the current gas limit of 35 million, <code>initcode</code> is restricted to ~16mb). Furthermore, initcode has additional implied costs - it must have already been paid for via calldata or memory expansion, limiting it even more.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is fully backwards compatible. Existing contracts and transactions remain unaffected, as the proposal only lifts a restriction without altering execution semantics or gas costs.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="security-considerations">Security Considerations</h2> <p>No new security risks are introduced. The current gas schedule already mitigates denial-of-service concerns by charging per-byte for <code>initcode</code>. Benchmarks were performed, and ns/byte remained consistent across a range of different bytecodes, ranging from 128 bytes to 15MB.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0.</p> 2025-03-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/7898/

Separates the execution payload from beacon block to independently transmit them

<h2 id="abstract">Abstract</h2> <p>Currently, the beacon block in Ethereum Consensus embeds transactions within the <code>ExecutionPayload</code> field of <code>BeaconBlockBody</code>. This EIP proposes to replace <code>ExecutionPayload</code> with <code>ExecutionPayloadHeader</code> in <code>BeaconBlockBody</code> and to independently transmit <code>ExecutionPayloadWithInclusionProof</code>.</p> <p>However, this EIP makes no change to the block import mechanism, with the exception that block availability now includes waiting for the availability of <code>ExecutionPayloadWithInclusionProof</code>, making it different and simpler from proposals like ePBS/APS.</p> <p>But this availability requirement can in fact be restricted to <code>gossip</code> import while allowing optimistic syncing of the execution layer (EL) on checkpoint/range sync as EL can pull full blocks from their peers in optimistic sync as they do now.</p> <h2 id="motivation">Motivation</h2> <p>The Ethereum protocol has an ambitious goal to grow the <code>gasLimit</code> of the execution payloads (possibly by 10X). This leads to larger messages, negatively affecting the networking and block processing pipelines of the consensus layer (CL) clients leading to following issues:</p> <ol> <li>Higher latencies for the arrival of beacon blocks increase, requiring larger bandwidth resources to be made available for the beacon node.</li> <li>The greater number and size of transactions directly increase the merkelization compute time, increasing the import time of the block.</li> </ol> <p>We know from timing games that the block import latency greatly affects a client's performance to make correct head attestations. With this EIP, block transmission and block import processes will be decongested, allowing for greater flexibility in receiving a larger <code>ExecutionPayloadWithInclusionProof</code>, while the beacon block can simultaneously undergo processing.</p> <p>In addition, EL clients can also independently participate in forwarding and receiving larger execution blocks. That mechanism however can be independently developed and is out of scope for this EIP.</p> <p>Additional benefits obtained from this EIP:</p> <ul> <li>Consensus clients don't need to store and serve blocks with transactions, providing greater efficiency and reduced resource requirements for running a beacon node.</li> <li>The proposer-builder separation (PBS) pipeline becomes more efficient by the proposer transmitting the signed block directly to the p2p network, while submitting to the builder/relay for the independent reveal of the <code>ExecutionPayloadWithInclusionProof</code>.</li> <li>In the future with zero-knowledge (ZK) proof of the EL block execution, nodes could treat the transactions similarly to blobs which leverage data availability sampling (DAS) mechanisms for available data without requiring re-execution of transactions to establish validity. Hence the L1 execution could itself become a rollup by alleviating the need to import all transaction data by a node.</li> </ul> <p>Furthermore CL clients apis and code path will become cleaner and more maintainable because of collapse of blinded and full versions (like <code>BlindedBeaconBlock</code>, <code>BlindedBeaconBlockBody</code>) into same types.</p> <h2 id="specification">Specification</h2> <ul> <li><code>ExecutionPayload</code> in the <code>BeaconBlockBody</code> is replaced by <code>ExecutionPayloadHeader</code></li> <li><code>ExecutionPayloadWithInclusionProof</code> is computed by the block proposer/builder and gossiped independently on a separate new topic. Also builder <code>submitBlindedBlock</code> api is modified to respond with <code>ExecutionPayloadWithInclusionProof</code> instead.</li> <li>Data availability checks for block import into forkchoice now must wait for availability of the corresponding <code>ExecutionPayloadWithInclusionProof</code> but only for gossiped blocks</li> <li><code>newPayloadHeader</code> engine api is introduced to augment the previous usage of <code>newPayload</code> in block processing when <code>ExecutionPayload</code> is not available for e.g. in processing range synced blocks signaling EL clients to optimistic sync those payloads from EL p2p network.</li> </ul> <p>ELs can optionally introduce a <code>getExecutionPayload</code> method (similar to <code>getBlobs</code>) to assist with faster recovery of execution payload from the EL's p2p network peers who could announce new payload hashes when they see new <code>VALID</code> payloads. However, as noted above, that mechanism could be independently specified and is out of scope for this EIP.</p> <p>&lt;-- TODO: add spec details --&gt;</p> <h2 id="rationale">Rationale</h2> <p>There is another choice we could have made to go for <code>SignedExecutionPayload</code> instead of <code>ExecutionPayloadWithInclusionProof</code> and having a <code>SignedExecutionPayloadHeader</code> with builder signing these messages (validator is the builder in local block building). But without builder enshrinement tight gossip validation of <code>SignedExecutionPayload</code> would be an issue and could become a DOS vector.</p> <p>The benefit of <code>SignedExecutionPayload</code> design is that it could be transmitted ahead of even the <code>SignedExecutionPayloadHeader</code> inclusion in beacon block and is especially useful in PBS pipeline where the proposal to builder/relay latency can be reduced significantly.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change isn't backward compatible and a new hardfork is required to activate this EIP.</p> <h2 id="test-cases">Test Cases</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>&lt;-- TODO --&gt;</p> <h2 id="security-considerations">Security Considerations</h2> <p>&lt;-- TODO --&gt;</p> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-02-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Forshtathttps://github.com/forshtat Shahaf Nacsonhttps://github.com/shahafn Dror Tiroshhttps://github.com/drortirosh Yoav Weisshttps://github.com/yoavw https://wg-eips.ritovision.com/7906/

A transaction type that provides a way for senders to restrict the outcomes of their execution

<h2 id="abstract">Abstract</h2> <p>This proposal allows the transaction payload to define write protections for balances and storage slots that are enforced at the protocol level. These protected transactions empower Ethereum users to restrict the behavior of the deployed on-chain smart contracts without needing to perform a deep analysis of their EVM bytecode.</p> <h2 id="motivation">Motivation</h2> <p>The total value of crypto assets that have been stolen to date exceeds the yearly GDP of a medium-sized nation. This level of loss and waste is indefensible and has a long list of negative consequences for everyone involved.</p> <p>Specifically, one of the major ways in which Ethereum users end up losing their funds is not exposing private keys, but instead being tricked into signing transactions that appear innocent in their Wallet applications but in practice perform a complete sweep of the senders' assets.</p> <p>The ability of an average user or a Wallet application to find, collect, review, and analyze the EVM code the transaction will execute is very limited.</p> <p>This leaves the users with no mechanism to enforce any restrictions on what the transaction actually does once it is signed. This leads users to perform blind signing in order to interact with Ethereum, exposing them to significant and avoidable risks.</p> <p>By providing the Wallets and dApps with the ability to restrict the possible <strong>outcomes</strong> of a transaction, we create a tool that users and wallets will apply to reduce their risk levels.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td>RESTRICTED_TX_COST</td><td>TBD</td></tr> <tr><td>TRACE_CALL_GAS_COST</td><td>TBD</td></tr> <tr><td>GET_TRACE_CALL_ADDRESS</td><td>TBD</td></tr> <tr><td>RESTRICTED_EXECUTION_TX_TYPE</td><td>TBD</td></tr> </tbody></table> <h3 id="new-transaction-type">New Transaction Type</h3> <p>We introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction, "restricted execution transaction", where the <code>TransactionType</code> is <code>RESTRICTED_EXECUTION_TX_TYPE</code> and the <code>TransactionPayload</code> is the RLP serialization of the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, calldata, access_list, authorization_list, asserter_address, asserter_data, asserter_gas_limit, signature_y_parity, signature_r, signature_s])</span></span></code></pre> <ul> <li><code>asserter_address</code> - the address of an existing contract that will be called for the <a href="https://wg-eips.ritovision.com/7906/#assertion-frame">Assertion Frame</a>.</li> <li><code>asserter_data</code> - the data to be passed as a call data to the Assertion Frame. In case the <code>asserter_address</code> is not set, this field acts as a <a href="https://wg-eips.ritovision.com/7906/#one-time-restrictions-code">One-Time Restrictions Code</a>.</li> <li><code>asserter_gas_limit</code> - the gas limit provided to the asserter call frame.</li> </ul> <h3 id="one-time-restrictions-code">One-Time Restrictions Code</h3> <p>The <code>asserter_address</code>, <code>asserter_data</code> and <code>asserter_gas_limit</code> fields behave similarly to the <code>destination</code>, <code>calldata</code> and <code>gas_limit</code> fields in existing transaction types.</p> <p>If the <code>asserter_address</code> value is not set, the <code>asserter_data</code> is loaded and executed as <code>asserter_code</code>. This is similar to the <code>init_code</code> parameter logic of a legacy transaction type.</p> <p>This code is executed in a static context and cannot modify the blockchain state, set contract code or deploy new contracts.</p> <h3 id="assertion-frame">Assertion Frame</h3> <p>After the transaction execution frame is finished without reverting, the <code>RESTRICTED_EXECUTION_TX_TYPE</code> transactions MUST also successully execute a second execution frame. This frame runs in a static context and cannot modify storage or emit logs.</p> <p>The purpose of this frame is to execute the state change assertions as prescribed by the <code>asserter_address</code> and <code>asserter_data</code> parameters.</p> <p>In case of a revert in the Assertion Frame, the entire transaction is reverted.</p> <p>The gas costs in the Assertion Frame are charged same as in the regular execution.</p> <h3 id="execution-restrictions-assertion-frame">Execution Restrictions Assertion Frame</h3> <p>There are a number of parameters that constitute the core of the transaction's execution restriction. These parameters are joined together and RLP encoded as part of the transaction payload. There are no additional costs associated with providing this parameter other than its gas cost equivalent to <code>calldata</code>.</p> <p>In case any of the specified restrictions is violated, the entire transaction MUST <strong>revert on-chain</strong> and its gas MUST be paid until the point of the restriction violation.</p> <p>The transaction is considered to be a valid transaction that can be included in a block and pays its own gas regardless of the contents of the <code>execution_restrictions</code> parameter.</p> <h3 id="transaction-trace-precompile">Transaction Trace Precompile</h3> <p>We introduce a precompile at address <code>GET_TRACE_CALL_ADDRESS</code>.</p> <p>When called in a regular execution frame, the call returns a full stack trace of the current frame up to this point.</p> <p>When called in the Assertion Frame, the call returns a full stack trace of the entire transaction.</p> <p>The format of the returned transaction stack trace is described in <a href="https://wg-eips.ritovision.com/7906/#transaction-trace-data-structure">Transaction Trace Data Structure</a>.</p> <h3 id="transaction-trace-data-structure">Transaction Trace Data Structure</h3> <p>The stack trace is represented as an ABI encoding of the following struct:</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> Trace</span><span> {</span></span> <span class="giallo-l"><span> Call</span><span>[</span><span>]</span><span> calls</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> Call</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> address</span><span> sender</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> address</span><span> target</span><span>;</span></span> <span class="giallo-l"><span> Storage</span><span>[</span><span>]</span><span class="z-storage z-type"> storage</span><span>;</span></span> <span class="giallo-l"><span> Balance</span><span>[</span><span>]</span><span> balances</span><span>;</span></span> <span class="giallo-l"><span> CodeHash</span><span>[</span><span>]</span><span> codeHash</span><span>;</span></span> <span class="giallo-l"><span> OpCode</span><span>[</span><span>]</span><span> opCodes</span><span>;</span></span> <span class="giallo-l"><span> Call</span><span>[</span><span>]</span><span> calls</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> Storage</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span> slotId</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span> oldValue</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span> newValue</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> Balance</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> address</span><span> account</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> uint256</span><span> oldBalance</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> uint256</span><span> newBalance</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> CodeHash</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> address</span><span class="z-storage z-type"> contract</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span> newCodeHash</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">struct</span><span class="z-entity z-name"> OpCode</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint8</span><span> opCode</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span>[</span><span>]</span><span> params</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h4 id="opcodes-traced">Opcodes Traced</h4> <p>Including all opcodes called during a transaction execution in the stack trace is not practical. Instead, only the following opcodes with potentially dangerous non-local effects are reported as part of the <code>opCodes</code> field:</p> <ul> <li><code>SELFDESTRUCT</code> (<code>0xFF</code>)</li> <li><code>DELEGATECALL</code> (<code>0xF4</code>)</li> <li><code>CALLCODE</code> (<code>0xF2</code>)</li> <li><code>STATICCALL</code> (<code>0xFA</code>)</li> <li><code>CALL</code> (<code>0xFA</code>)</li> <li><code>LOG</code> (<code>0xA0</code>)</li> <li><code>LOG1</code> (<code>0xA1</code>)</li> <li><code>LOG2</code> (<code>0xA2</code>)</li> <li><code>LOG3</code> (<code>0xA3</code>)</li> <li><code>LOG4</code> (<code>0xA4</code>)</li> <li><code>REVERT</code> (<code>0xFD</code>)</li> <li><code>INVALID</code> (<code>0xFE</code>)</li> <li><code>KECCAK256</code> (<code>0x20</code>)</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="new-transaction-type-and-assertion-frame">New Transaction Type and Assertion Frame</h3> <p>One of the main advantages of a new Transaction Type for the Restricted Behaviour feature is the ability to protect all existing EOAs, and not just smart accounts. This makes it preferable to introduce a new Transaction Type instead of any other approach that would only work for smart contract accounts.</p> <h3 id="transaction-trace-precompile-behaviour">Transaction Trace Precompile Behaviour</h3> <p>It is important for us to provide the same protection level to both EOAs and Smart Accounts. The Smart Accounts are not able to initiate a <code>RESTRICTED_EXECUTION_TX_TYPE</code> transaction themselves, and instead need to rely on checks performed during the regular execution frame of any transaction type.</p> <p>By exposing the <code>GET_TRACE_CALL_ADDRESS</code> precompile at all times, we allow any smart contract to perform the state change assertions it may need to ensure safety and security.</p> <h3 id="deployable-and-one-time-restrictions-code">Deployable and One-Time Restrictions Code</h3> <p>In some scenarios, the wallets are likely to want to apply the exact same transaction behaviour to all transactions they initiate.</p> <p>In this case, it is reasonalbe and more efficient to deploy the assertions on-chain as a smart contract module, and provide its address and the inputs it may need.</p> <p>However, it is possible that the wallet may want to prepare the restrictions for the transaction dynamically. In that case, there is no benefit in having the assertion code permanently deployed, and it is more efficient to provide such code as part of the transaction payload. Luckily, the EVM already has a very similar behaviour defined for the <code>init_code</code> field, and it appears to fit the task perfectly.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal describes a new transaction type that should not affect the functionality of existing systems.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="correct-wallet-ui-presentation">Correct Wallet UI presentation</h3> <p>Successfull use of the <code>RESTRICTED_EXECUTION_TX_TYPE</code> transaction type requires the wallets to be abile to correctly understand and present the restrictions imposed on the transaction to the users.</p> <p>Wallets will need to be able to understand the meaning of the state changes being permitted by the transaction. This requires wallets to be aware of all major ERC standards, such as <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> and <a href="https://wg-eips.ritovision.com/721/">ERC-721</a>. In many cases, this also requires the wallets to be able to fetch and analyze the source code of the executed contracts.</p> <p>However, the introduction of the Execution Restrictions feature significantly streamlines the process by removing the need for a deep understanding of the executed <strong>code</strong>. Instead, only high-level information about the stack traces' meaning is required for a clear and safe representation of possible transaction outcomes.</p> <h3 id="insufficiently-restrictive-transactions">Insufficiently Restrictive Transactions</h3> <p>The worst outcome of introducing a security feature is creating a false sense of security for its user.</p> <p>Wallets are expected to provide the behaviour restriction logic that protects their users' valuable assets.</p> <p>It is critical that dApps, wallets, and users become educated about the consequences of not limiting their transactions' execution with sufficient strictness.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-02-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Shoham Chakrabortyhttps://github.com/shohamc1 Alex Forshtathttps://github.com/forshtat https://wg-eips.ritovision.com/7889/

Top level reverts emit a log with revert message

<h2 id="abstract">Abstract</h2> <p>All calls to the REVERT opcode with non-zero size must emit a log with revert data, making it accessible via standard RPC without the need for tracing.</p> <h2 id="motivation">Motivation</h2> <p>Revert messages are currently inaccessible to users as they are not available via standard RPC. Instead, users have to request a node to trace the transaction and check the stack and memory at the moment when the REVERT opcode was executed.</p> <p>This introduces overhead for users and nodes - users must make an additional request to find out why their transaction failed, and the node has to replay the full transaction (which may be slow and computationally expensive) to get back a relatively small piece of data.</p> <p>Currently it is up to smart wallet developers to emit logs before a revert, however this is not a standard feature and thus cannot be relied upon by tools such as client libraries and block explorers. Making this log part of the protocol allows these tools to rely on logs for revert reasons.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <!-- TODO --> <ul> <li><code>REVERTTOPIC</code>: <code>TBD</code></li> <li><code>DATA_LIMIT</code>: <code>TBD</code></li> </ul> <h3 id="functionality">Functionality</h3> <p>Whenever <code>REVERT</code> is called with non-zero size, emit a log identical to a LOG1 with the topic <code>REVERTTOPIC</code>. The log data is the raw bytes of the revert message. The data is truncated to <code>DATA_LIMIT</code>.</p> <h2 id="rationale">Rationale</h2> <p>This is the simplest possible implementation that allows revert messages to be accessible via RPC methods. It does not require any changes to client libraries, or other RPC consumers as it is backward compatible. It does not introduce new RPC methods or new opcodes.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Reverted transactions may now contain up to one log.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Reverted transactions must cost at least intrinsic gas (21000 gas), which is much more expensive than the LOG1 opcode (750 gas). Hence, this EIP does not introduce any new avenues to inflate Ethereum storage requirements. However, it is expected to increase the average number of logs.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-02-18T00:00:00+00:00 2026-02-11T14:49:28+00:00 Francesco D'Amatohttps://github.com/fradamt Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7886/

Separate block validation from execution

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a mechanism to make execution blocks statically verifiable through minimal checks that only require the previous state, without requiring execution of the block's transactions. This enables validators to attest to a block's validity without completing its execution.</p> <h2 id="motivation">Motivation</h2> <p>The primary advantage of this proposal is <strong>asynchronous block validation</strong>. In the current Ethereum protocol, blocks must be fully executed before validators can attest to them. This requirement creates a bottleneck in the consensus process, as attestors must wait for execution results before committing their votes, limiting the network's throughput potential.</p> <p>By introducing a mechanism where execution payloads can be reverted rather than invalidating the entire block, execution is no longer an immediate requirement for validation. Instead, a block's validity can be determined based on its structural correctness and the upfront payment of transaction fees by senders. This allows attestation to happen earlier in the slot, independent of execution, potentially enabling higher block gas limits and significant throughput improvements across the network.</p> <h2 id="specification">Specification</h2> <h3 id="header-changes">Header Changes</h3> <p>The block header structure is extended to support delayed execution:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Header</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Existing fields</span></span> <span class="giallo-l"><span> parent_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> ommers_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> coinbase</span><span>:</span><span> Address</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pre-execution state root - this is the state root before executing transactions</span></span> <span class="giallo-l"><span> pre_state_root</span><span>:</span><span> Root</span><span> </span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Deferred execution outputs from parent block</span></span> <span class="giallo-l"><span> parent_transactions_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Transaction root from parent block</span></span> <span class="giallo-l"><span> parent_receipt_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Receipt root from parent block</span></span> <span class="giallo-l"><span> parent_bloom</span><span>:</span><span> Bloom</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Logs bloom from parent block</span></span> <span class="giallo-l"><span> parent_requests_hash</span><span>:</span><span> Hash32</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Hash of requests from the parent block</span></span> <span class="giallo-l"><span> parent_execution_reverted</span><span>:</span><span class="z-support"> bool</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Indicates if parent block&#39;s execution was reverted</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Other existing fields</span></span> <span class="giallo-l"><span> difficulty</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> number</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> Uint</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Declared gas used by txs, validated post-execution</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span> U256</span></span> <span class="giallo-l"><span> extra_data</span><span>:</span><span> Bytes</span></span> <span class="giallo-l"><span> prev_randao</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> Bytes8</span></span> <span class="giallo-l"><span> base_fee_per_gas</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> withdrawals_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> blob_gas_used</span><span>:</span><span> U64</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Total blob gas used by transactions</span></span> <span class="giallo-l"><span> excess_blob_gas</span><span>:</span><span> U64</span></span> <span class="giallo-l"><span> parent_beacon_block_root</span><span>:</span><span> Root</span></span></code></pre> <p>The key changes are:</p> <ol> <li><code>pre_state_root</code>: Represents the state root before execution (checked against the post-execution state of the parent block)</li> <li><code>parent_receipt_root</code>: Receipt root from the parent block (deferred execution output)</li> <li><code>parent_bloom</code>: Logs bloom from the parent block (deferred execution output)</li> <li><code>parent_requests_hash</code>: Hash of requests from the parent block (deferred execution output)</li> <li><code>parent_execution_reverted</code>: Indicates whether the parent block's execution was reverted</li> </ol> <p>A block header MUST include all these fields to be considered valid under this EIP. The <code>pre_state_root</code> MUST match the state root after applying the parent block's execution. The parent execution outputs MUST accurately reflect the previous block's execution results to maintain chain integrity.</p> <h3 id="chain-state-tracking">Chain State Tracking</h3> <p>The blockchain object is extended to track execution outputs for verification in subsequent blocks:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BlockChain</span><span>:</span></span> <span class="giallo-l"><span> blocks</span><span>:</span><span> List</span><span>[</span><span>Block</span><span>]</span></span> <span class="giallo-l"><span> state</span><span>:</span><span> State</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> U64</span></span> <span class="giallo-l"><span> last_transactions_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Transaction root from the last executed block</span></span> <span class="giallo-l"><span> last_receipt_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Receipt root from last executed block</span></span> <span class="giallo-l"><span> last_block_logs_bloom</span><span>:</span><span> Bloom</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Logs bloom from last executed block</span></span> <span class="giallo-l"><span> last_requests_hash</span><span>:</span><span> Bytes</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Requests hash from last executed block</span></span> <span class="giallo-l"><span> last_execution_reverted</span><span>:</span><span class="z-support"> bool</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Indicates if the last block&#39;s execution was reverted</span></span></code></pre> <p>These additional fields are used to verify the deferred execution outputs claimed in subsequent blocks. The <code>last_transactions_root</code>, <code>last_receipt_root</code>, <code>last_block_logs_bloom</code>, <code>last_requests_hash</code>, and <code>last_execution_reverted</code> act as critical chain state references that MUST be updated after each block execution to ensure proper state progression. When a block's execution is reverted due to a gas mismatch, the <code>last_execution_reverted</code> field is set to <code>True</code>, which affects the base fee calculation of subsequent blocks.</p> <h3 id="block-validation">Block Validation</h3> <p>Static validation is performed separately from execution. In this phase, all checks that can be done without executing transactions are performed:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">chain</span><span>:</span><span> BlockChain</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate header against parent</span></span> <span class="giallo-l"><span> validate_header</span><span>(</span><span>chain</span><span>,</span><span> block</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate deferred execution outputs from the parent</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>parent_transactions_root</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_transactions_root</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>parent_receipt_root</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_receipt_root</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>parent_bloom</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_block_logs_bloom</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>parent_requests_hash</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_requests_hash</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>pre_state_root</span><span class="z-keyword"> !=</span><span> state_root</span><span>(</span><span>chain</span><span>.</span><span>state</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>parent_execution_reverted</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_execution_reverted</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process all transactions trie and validate transactions</span></span> <span class="giallo-l"><span> total_inclusion_gas</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> total_blob_gas_used</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> withdrawals_trie</span><span class="z-keyword"> =</span><span> Trie</span><span>(</span><span class="z-variable">secured</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>,</span><span class="z-variable"> default</span><span class="z-keyword">=</span><span class="z-constant">None</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track sender balances and nonces by address</span></span> <span class="giallo-l"><span> sender_balances</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"><span> sender_nonces</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calculate blob gas price based on excess blob gas</span></span> <span class="giallo-l"><span> blob_gas_price</span><span class="z-keyword"> =</span><span> calculate_blob_gas_price</span><span>(</span><span>block</span><span>.</span><span>header</span><span>.</span><span>excess_blob_gas</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate each transaction</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span class="z-support">map</span><span>(</span><span>decode_transaction</span><span>,</span><span> block</span><span>.</span><span>transactions</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate transaction parameters (signature, fees, etc.)</span></span> <span class="giallo-l"><span> validate_transaction</span><span>(</span><span>tx</span><span>,</span><span> block</span><span>.</span><span>header</span><span>.</span><span>base_fee_per_gas</span><span>,</span><span> block</span><span>.</span><span>header</span><span>.</span><span>excess_blob_gas</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Recover sender</span></span> <span class="giallo-l"><span> sender_address</span><span class="z-keyword"> =</span><span> recover_sender</span><span>(</span><span>chain</span><span>.</span><span>chain_id</span><span>,</span><span> tx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calculate gas costs (both EIP-7623 intrinsic cost and floor cost)</span></span> <span class="giallo-l"><span> intrinsic_gas</span><span>,</span><span> calldata_floor_gas_cost</span><span class="z-keyword"> =</span><span> calculate_intrinsic_cost</span><span>(</span><span>tx</span><span>)</span></span> <span class="giallo-l"><span> blob_gas_used</span><span class="z-keyword"> =</span><span> calculate_total_blob_gas</span><span>(</span><span>tx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track total gas usage (using the maximum of intrinsic gas and floor cost)</span></span> <span class="giallo-l"><span> total_inclusion_gas</span><span class="z-keyword"> +=</span><span class="z-support"> max</span><span>(</span><span>intrinsic_gas</span><span>,</span><span> calldata_floor_gas_cost</span><span>)</span></span> <span class="giallo-l"><span> total_blob_gas_used</span><span class="z-keyword"> +=</span><span> blob_gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calculate maximum gas fee (including blob fees)</span></span> <span class="giallo-l"><span> effective_gas_price</span><span class="z-keyword"> =</span><span> calculate_effective_gas_price</span><span>(</span><span>tx</span><span>,</span><span> block</span><span>.</span><span>header</span><span>.</span><span>base_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span> max_gas_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> *</span><span> effective_gas_price</span><span class="z-keyword"> +</span><span> blob_gas_used</span><span class="z-keyword"> *</span><span> blob_gas_price</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sender is an EOA or has delegation support</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> sender_address</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> sender_balances</span><span>:</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>chain</span><span>.</span><span>state</span><span>,</span><span> sender_address</span><span>)</span></span> <span class="giallo-l"><span> is_sender_eoa</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> account</span><span>.</span><span>code</span><span class="z-keyword"> ==</span><span class="z-support"> bytearray</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> is_valid_delegation</span><span>(</span><span>account</span><span>.</span><span>code</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_sender_eoa</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span> sender_balances</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> =</span><span> account</span><span>.</span><span>balance</span></span> <span class="giallo-l"><span> sender_nonces</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> =</span><span> account</span><span>.</span><span>nonce</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sender has sufficient balance</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> sender_balances</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> &lt;</span><span> max_gas_fee</span><span class="z-keyword"> +</span><span> Uint</span><span>(</span><span>tx</span><span>.</span><span>value</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify correct nonce</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> sender_nonces</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> !=</span><span> tx</span><span>.</span><span>nonce</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track balance and nonce changes</span></span> <span class="giallo-l"><span> sender_balances</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> -=</span><span> max_gas_fee</span><span class="z-keyword"> +</span><span> Uint</span><span>(</span><span>tx</span><span>.</span><span>value</span><span>)</span></span> <span class="giallo-l"><span> sender_nonces</span><span>[</span><span>sender_address</span><span>]</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate gas constraints</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> total_inclusion_gas</span><span class="z-keyword"> &gt;</span><span> block</span><span>.</span><span>header</span><span>.</span><span>gas_used</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> total_blob_gas_used</span><span class="z-keyword"> !=</span><span> block</span><span>.</span><span>header</span><span>.</span><span>blob_gas_used</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate withdrawals trie</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> wd</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>block</span><span>.</span><span>withdrawals</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> trie_set</span><span>(</span><span>withdrawals_trie</span><span>,</span><span> rlp</span><span>.</span><span>encode</span><span>(</span><span>Uint</span><span>(</span><span>i</span><span>)</span><span>)</span><span>,</span><span> rlp</span><span>.</span><span>encode</span><span>(</span><span>wd</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>header</span><span>.</span><span>withdrawals_root</span><span class="z-keyword"> !=</span><span> root</span><span>(</span><span>withdrawals_trie</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span></code></pre> <p>This validation function enforces several requirements:</p> <ol> <li>Clients MUST validate that the block's parent execution outputs match the chain's tracked last execution outputs.</li> <li>The <code>pre_state_root</code> MUST match the current state root to ensure proper state transition.</li> <li>All transactions MUST be statically validated for signature correctness and transaction type-specific requirements (<a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>, etc.).</li> <li>Sender accounts MUST be externally owned accounts (EOAs) or have valid delegation support (<a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>).</li> <li>Senders MUST have sufficient balance to cover maximum possible gas fees plus transaction value.</li> <li>Transaction nonces MUST be correct and sequential per sender.</li> <li>Total inclusion gas (using the maximum of intrinsic gas and <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor cost) MUST not exceed the block's declared gas_used.</li> <li>Total blob gas MUST match the declared blob_gas_used.</li> <li>Withdrawal trie root MUST match its respective header field.</li> </ol> <p>When calculating inclusion gas, the implementation uses the maximum of the regular intrinsic gas cost and the <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> calldata floor cost, which ensures proper accounting for calldata gas regardless of execution outcome.</p> <h3 id="block-execution-with-state-snapshots">Block Execution with State Snapshots</h3> <p>After a block passes static validation, execution proceeds with the pre-charged transaction senders:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> apply_body</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> block_env</span><span>:</span><span> vm</span><span>.</span><span>BlockEnvironment</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> transactions</span><span>:</span><span> Tuple</span><span>[</span><span>Union</span><span>[</span><span>LegacyTransaction</span><span>,</span><span> Bytes</span><span>]</span><span>,</span><span class="z-constant"> ...</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> withdrawals</span><span>:</span><span> Tuple</span><span>[</span><span>Withdrawal</span><span>,</span><span class="z-constant"> ...</span><span>]</span><span>,</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> vm</span><span>.</span><span>BlockOutput</span><span>:</span></span> <span class="giallo-l"><span> block_output</span><span class="z-keyword"> =</span><span> vm</span><span>.</span><span>BlockOutput</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process system transactions first (beacon roots, history storage)</span></span> <span class="giallo-l"><span> process_system_transaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> block_env</span><span class="z-keyword">=</span><span>block_env</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> target_address</span><span class="z-keyword">=</span><span class="z-constant">BEACON_ROOTS_ADDRESS</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> data</span><span class="z-keyword">=</span><span>block_env</span><span>.</span><span>parent_beacon_block_root</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> process_system_transaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> block_env</span><span class="z-keyword">=</span><span>block_env</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> target_address</span><span class="z-keyword">=</span><span class="z-constant">HISTORY_STORAGE_ADDRESS</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> data</span><span class="z-keyword">=</span><span>block_env</span><span>.</span><span>block_hashes</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The parent hash</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process user transactions</span></span> <span class="giallo-l"><span> process_transactions</span><span>(</span><span>block_env</span><span>,</span><span> block_output</span><span>,</span><span> transactions</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process withdrawals</span></span> <span class="giallo-l"><span> process_withdrawals</span><span>(</span><span>block_env</span><span>,</span><span> block_output</span><span>,</span><span> withdrawals</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process requests (deposits, withdrawals, consolidations)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> not generated if execution_reverted in header is True</span></span> <span class="giallo-l"><span> process_general_purpose_requests</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> block_env</span><span class="z-keyword">=</span><span>block_env</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> block_output</span><span class="z-keyword">=</span><span>block_output</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> block_output</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_transactions</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> block_env</span><span>:</span><span> vm</span><span>.</span><span>BlockEnvironment</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> block_output</span><span>:</span><span> vm</span><span>.</span><span>BlockOutput</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> transactions</span><span>:</span><span> Tuple</span><span>[</span><span>Union</span><span>[</span><span>LegacyTransaction</span><span>,</span><span> Bytes</span><span>]</span><span>,</span><span class="z-constant"> ...</span><span>]</span><span>,</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Take a block-level snapshot of the state before transaction execution</span></span> <span class="giallo-l"><span> begin_transaction</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Decode transactions</span></span> <span class="giallo-l"><span> decoded_transactions</span><span class="z-keyword"> =</span><span> [</span><span>decode_transaction</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> transactions</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pre-charge senders for maximum possible gas fees upfront</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> decoded_transactions</span><span>:</span></span> <span class="giallo-l"><span> deduct_max_tx_fee_from_sender_balance</span><span>(</span><span>block_env</span><span>,</span><span> tx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Execute each transaction</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>decoded_transactions</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> process_transaction</span><span>(</span><span>block_env</span><span>,</span><span> block_output</span><span>,</span><span> tx</span><span>,</span><span> Uint</span><span>(</span><span>i</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Stop processing if execution is already reverted</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_output</span><span>.</span><span>execution_reverted</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate declared gas used against actual gas used</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>execution_reverted</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>execution_reverted</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> block_output</span><span>.</span><span>block_gas_used</span><span class="z-keyword"> !=</span><span> block_env</span><span>.</span><span>block_gas_used</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If execution is reverted, reset all outputs and rollback the state</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_output</span><span>.</span><span>execution_reverted</span><span>:</span></span> <span class="giallo-l"><span> rollback_transaction</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>block_gas_used</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>transactions_trie</span><span class="z-keyword"> =</span><span> Trie</span><span>(</span><span class="z-variable">secured</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>,</span><span class="z-variable"> default</span><span class="z-keyword">=</span><span class="z-constant">None</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>receipts_trie</span><span class="z-keyword"> =</span><span> Trie</span><span>(</span><span class="z-variable">secured</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>,</span><span class="z-variable"> default</span><span class="z-keyword">=</span><span class="z-constant">None</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>receipt_keys</span><span class="z-keyword"> =</span><span> (</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>block_logs</span><span class="z-keyword"> =</span><span> (</span><span>)</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>requests</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>execution_reverted</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Commit the state if execution is valid</span></span> <span class="giallo-l"><span> commit_transaction</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>)</span></span></code></pre> <p>During block execution:</p> <ol> <li> <p>Clients MUST create a block-level snapshot before any transaction execution occurs. This happens after handling the system contracts from <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> and <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a>.</p> </li> <li> <p>Maximum fees MUST be deducted from sender balances upfront by:</p> </li> </ol> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> deduct_max_tx_fee_from_sender_balance</span><span>(</span><span class="z-variable z-parameter z-function">block_env</span><span>,</span><span class="z-variable z-parameter z-function"> tx</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> effective_gas_price</span><span class="z-keyword"> =</span><span> calculate_effective_gas_price</span><span>(</span><span>tx</span><span>,</span><span> block_env</span><span>.</span><span>base_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span> blob_gas_price</span><span class="z-keyword"> =</span><span> calculate_blob_gas_price</span><span>(</span><span>block_env</span><span>.</span><span>excess_blob_gas</span><span>)</span></span> <span class="giallo-l"><span> blob_gas_used</span><span class="z-keyword"> =</span><span> calculate_total_blob_gas</span><span>(</span><span>tx</span><span>)</span></span> <span class="giallo-l"><span> max_gas_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> *</span><span> effective_gas_price</span><span class="z-keyword"> +</span><span> blob_gas_used</span><span class="z-keyword"> *</span><span> blob_gas_price</span></span> <span class="giallo-l"><span> sender</span><span class="z-keyword"> =</span><span> recover_sender</span><span>(</span><span>block_env</span><span>.</span><span>chain_id</span><span>,</span><span> tx</span><span>)</span></span> <span class="giallo-l"><span> sender_account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>,</span><span> sender</span><span>)</span></span> <span class="giallo-l"><span> set_account_balance</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>,</span><span> sender</span><span>,</span><span> sender_account</span><span>.</span><span>balance</span><span class="z-keyword"> -</span><span> U256</span><span>(</span><span>max_gas_fee</span><span>)</span><span>)</span></span></code></pre> <ol start="3"> <li> <p>Transactions are executed sequentially until executing a transaction would cause the block to exceed the gas limit.</p> </li> <li> <p>After execution, clients MUST verify that the total gas used matches the declared <code>gas_used</code> in the block header.</p> </li> <li> <p>If the actual gas used doesn't match the declared value, clients MUST:</p> <ul> <li>Set <code>execution_reverted</code> to <code>True</code></li> <li>Roll back to the snapshot taken before execution</li> <li>Reset all execution outputs (receipts, logs, etc.)</li> <li>Return zero gas used</li> </ul> </li> <li> <p>The block itself remains valid, but execution outputs are not applied to the state.</p> </li> <li> <p>General purpose requests as defined in <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> are skipped when execution is reverted.</p> </li> <li> <p>The execution outputs (<code>last_transactions_root</code>, <code>last_receipt_root</code>, <code>last_block_logs_bloom</code>, <code>last_requests_hash</code>, <code>last_execution_reverted</code>) are updated in the chain state based on the execution results, and will be verified in subsequent blocks.</p> </li> </ol> <p>Execution SHALL be stopped and the payload reverted after exceeding the block gas limit:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_transaction</span><span>(</span><span>...</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_output</span><span>.</span><span>block_gas_used</span><span class="z-keyword"> +</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> &gt;</span><span> block_env</span><span>.</span><span>block_gas_limit</span><span>:</span></span> <span class="giallo-l"><span> block_output</span><span>.</span><span>execution_reverted</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="deferred-execution-outputs">Deferred Execution Outputs</h3> <p>The core innovation of deferring execution outputs to the next block enables static and stateful validation without requiring immediate execution. The <code>pre_state_root</code> provides a cryptographically verifiable starting point for validation, while parent execution outputs create a chain of deferred execution results that maintains the integrity of the blockchain state.</p> <p>This approach eliminates the execution bottleneck in the validation pipeline by allowing validators to attest to a block's validity based on its structure and the pre-charged transaction fees, without waiting for execution results.</p> <h3 id="pre-charging-mechanism">Pre-Charging Mechanism</h3> <p>Pre-charging senders with the maximum possible fees before execution provides a crucial guarantee that transactions have sufficient balance to be included in the block. This mechanism is compatible with existing fee models, including <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> dynamic fee transactions and <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> blob transactions.</p> <p>By tracking sender balances and nonces during validation, the protocol can enforce transaction validity without execution, enabling earlier block attestation.</p> <h3 id="state-snapshot-architecture">State Snapshot Architecture</h3> <p>The block-level snapshot mechanism provides a way to revert execution when necessary. This approach allows clients to roll back the entire block's execution if the actual gas used does not match the declared gas in the header, without invalidating the block structure itself.</p> <p>This provides two key benefits:</p> <ol> <li>It allows validators to attest to blocks before execution is complete</li> <li>It ensures execution is eventually performed correctly, with economic penalties for incorrect gas declarations</li> </ol> <h3 id="execution-reversion-handling">Execution Reversion Handling</h3> <p>When a block's execution is reverted due to gas mismatch:</p> <ol> <li>The block itself remains valid and part of the canonical chain</li> <li>The <code>last_execution_reverted</code> flag is set to <code>True</code> in chain state</li> <li>The next block must include this flag as <code>parent_execution_reverted</code></li> <li>Base fee calculations for subsequent blocks use 0 as parent gas used when parent execution was reverted</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork, as it alters the block validation and execution process.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="execution-correctness-guarantees">Execution Correctness Guarantees</h3> <p>The protocol ensures execution correctness through these primary mechanisms:</p> <ol> <li>Deferred execution outputs MUST match in subsequent blocks, creating a chain of verifiable execution results.</li> <li>State rollback MUST occur if the actual gas used doesn't match the declared value, providing an economic incentive for correct gas declaration.</li> <li>The <code>parent_execution_reverted</code> flag ensures that blocks acknowledge when parent execution has been reverted, maintaining chain integrity.</li> <li>Static and stateful validation guarantees that all transactions are properly authorized and senders have sufficient funds for maximum fees.</li> </ol> <h3 id="base-fee-dynamics-with-reverted-execution">Base Fee Dynamics with Reverted Execution</h3> <p>When a block's execution is reverted, the next block's base fee calculation treats the parent's gas used as zero, regardless of what was declared in the header. This ensures that base fee adjustments remain responsive to actual chain usage, and prevents manipulation of the fee market through incorrect gas declarations.</p> <h3 id="data-availability-and-economic-incentives">Data Availability and Economic Incentives</h3> <p>Block proposers MUST declare correct gas usage or lose transaction fees when execution is reverted. This aligns incentives for correct gas declaration and ensures execution integrity.</p> <p>Even when a block's execution is reverted due to incorrect gas declaration, the transaction data (calldata, <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> access lists, and blob data) MUST still be stored by all nodes for syncing and block validation purposes. This requirement creates a potential attack vector where malicious actors could attempt to place large amounts of data on-chain at a reduced cost by intentionally invalidating blocks through incorrect gas declarations.</p> <p>However, this attack is not economically sustainable for several reasons:</p> <ol> <li>Block proposers who invalidate blocks through incorrect gas declarations lose all execution layer rewards associated with the block.</li> <li>The attack requires control of block production, which is a scarce resource in the consensus layer.</li> </ol> <p>The economic costs of forgoing block rewards significantly outweigh any potential benefits, making such attacks financially impractical under normal network conditions.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-02-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Marcin Sobczakhttps://github.com/marcindsobczak Marek Moraczyńskihttps://github.com/MarekM25 Marcos Maceohttps://github.com/stdevMac https://wg-eips.ritovision.com/7883/

Increases cost of ModExp precompile

<h2 id="abstract">Abstract</h2> <p>This EIP is modifying the <code>ModExp</code> precompile pricing algorithm introduced in <a href="https://wg-eips.ritovision.com/2565/">EIP-2565</a>.</p> <h2 id="motivation">Motivation</h2> <p>Currently the <code>ModExp</code> precompile is underpriced in certain scenarios relative to its resource consumption. By adjusting the pricing formula, this EIP aims to address these discrepancies, making <code>ModExp</code> sufficiently efficient to enable potential increases in the block gas limit.</p> <h2 id="specification">Specification</h2> <p>Upon activation of this EIP, the gas cost of calling the precompile at address <code>0x0000000000000000000000000000000000000005</code> will be calculated as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def calculate_multiplication_complexity(base_length, modulus_length):</span></span> <span class="giallo-l"><span> max_length = max(base_length, modulus_length)</span></span> <span class="giallo-l"><span> words = math.ceil(max_length / 8)</span></span> <span class="giallo-l"><span> multiplication_complexity = 16</span></span> <span class="giallo-l"><span> if max_length &gt; 32: multiplication_complexity = 2 * words**2</span></span> <span class="giallo-l"><span> return multiplication_complexity</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def calculate_iteration_count(exponent_length, exponent):</span></span> <span class="giallo-l"><span> iteration_count = 0</span></span> <span class="giallo-l"><span> if exponent_length &lt;= 32 and exponent == 0: iteration_count = 0</span></span> <span class="giallo-l"><span> elif exponent_length &lt;= 32: iteration_count = exponent.bit_length() - 1</span></span> <span class="giallo-l"><span> elif exponent_length &gt; 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent &amp; (2**256 - 1)).bit_length() - 1)</span></span> <span class="giallo-l"><span> return max(iteration_count, 1)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def calculate_gas_cost(base_length, modulus_length, exponent_length, exponent):</span></span> <span class="giallo-l"><span> multiplication_complexity = calculate_multiplication_complexity(base_length, modulus_length)</span></span> <span class="giallo-l"><span> iteration_count = calculate_iteration_count(exponent_length, exponent)</span></span> <span class="giallo-l"><span> return max(500, math.floor(multiplication_complexity * iteration_count))</span></span></code></pre> <p>The specific changes from the algorithm defined in <a href="https://wg-eips.ritovision.com/2565/">EIP-2565</a>:</p> <h3 id="1-increased-minimal-and-general-price">1. Increased minimal and general price</h3> <p>The gas cost calculation is modified from:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> return max(200, math.floor(multiplication_complexity * iteration_count / 3))</span></span></code></pre> <p>to:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> return max(500, math.floor(multiplication_complexity * iteration_count))</span></span></code></pre> <p>This change increases the minimum gas cost from 200 to 500 and triples the general cost by removing the division by 3.</p> <h3 id="2-increase-cost-for-exponents-larger-than-32-bytes">2. Increase cost for exponents larger than 32 bytes</h3> <p>The gas cost calculation is modified from:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> elif exponent_length &gt; 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent &amp; (2**256 - 1)).bit_length() - 1)</span></span></code></pre> <p>to:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> elif exponent_length &gt; 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent &amp; (2**256 - 1)).bit_length() - 1)</span></span></code></pre> <p>The multiplier for exponents larger than 32 bytes is increased from 8 to 16, doubling its impact.</p> <h3 id="3-assume-the-minimal-base-modulus-length-to-be-32-and-increase-the-cost-when-it-is-larger-than-32-bytes">3. Assume the minimal base / modulus length to be 32 and increase the cost when it is larger than 32 bytes</h3> <p>The gas cost calculation is modified from:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def calculate_multiplication_complexity(base_length, modulus_length):</span></span> <span class="giallo-l"><span> max_length = max(base_length, modulus_length)</span></span> <span class="giallo-l"><span> words = math.ceil(max_length / 8)</span></span> <span class="giallo-l"><span> return words**2</span></span></code></pre> <p>to:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def calculate_multiplication_complexity(base_length, modulus_length):</span></span> <span class="giallo-l"><span> max_length = max(base_length, modulus_length)</span></span> <span class="giallo-l"><span> words = math.ceil(max_length / 8)</span></span> <span class="giallo-l"><span> multiplication_complexity = 16</span></span> <span class="giallo-l"><span> if max_length &gt; 32: multiplication_complexity = 2 * words**2</span></span> <span class="giallo-l"><span> return multiplication_complexity</span></span></code></pre> <p>This change introduces a minimal multiplication complexity of 16 and doubles the complexity if the base or modulus length exceeds 32 bytes.</p> <h2 id="rationale">Rationale</h2> <p>Benchmarking the <code>ModExp</code> precompile revealed several scenarios where its gas cost was significantly underestimated. Pricing adjustments are designed to rectify underpriced edge cases by modifying the existing <code>ModExp</code> pricing formula parameters. Specifically, the minimum cost for <code>ModExp</code> will rise from 200 to 500 (a 150% increase), the general cost will triple (a 200% increase), a minimum base/modulus length of 32 bytes will be assumed and the cost will scale more aggressively when the base, modulus, or exponent exceed 32 bytes. These modifications aim to ensure that the <code>ModExp</code> precompile's performance, even in its most resource-intensive edge cases across all execution layer clients, no longer impedes potential increases to the block gas limit.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a backwards-incompatible change. However, similar gas repricings have occurred multiple times in the Ethereum ecosystem, and their effects are well understood.</p> <p>An empirical analysis of this proposal is available <a href="https://wg-eips.ritovision.com/7883/assets/call_analysis/">here</a>, with a separate breakdown by affected entities provided <a href="https://wg-eips.ritovision.com/7883/assets/entity_analysis/">here</a>.</p> <h2 id="test-cases">Test Cases</h2> <p>The most common usages (approximately 99.69% of historical <code>Modexp</code> calls as of January 4th, 2025) will experience either a 150% increase (from 200 to 500 gas) or a 200% increase (tripling from approximately 1360 gas). No changes are made to the underlying interface or arithmetic algorithms, allowing existing test vectors to be reused. The table below presents the updated gas costs for these test vectors:</p> <table><thead><tr><th>Test Case</th><th><a href="https://wg-eips.ritovision.com/2565/">EIP-2565</a> Pricing</th><th>EIP-7883 Pricing</th><th>Increase</th></tr></thead><tbody> <tr><td>modexp_nagydani_1_square</td><td>200</td><td>500</td><td>150%</td></tr> <tr><td>modexp_nagydani_1_qube</td><td>200</td><td>500</td><td>150%</td></tr> <tr><td>modexp_nagydani_1_pow0x10001</td><td>341</td><td>2048</td><td>501%</td></tr> <tr><td>modexp_nagydani_2_square</td><td>200</td><td>512</td><td>156%</td></tr> <tr><td>modexp_nagydani_2_qube</td><td>200</td><td>512</td><td>156%</td></tr> <tr><td>modexp_nagydani_2_pow0x10001</td><td>1365</td><td>8192</td><td>501%</td></tr> <tr><td>modexp_nagydani_3_square</td><td>341</td><td>2048</td><td>501%</td></tr> <tr><td>modexp_nagydani_3_qube</td><td>341</td><td>2048</td><td>501%</td></tr> <tr><td>modexp_nagydani_3_pow0x10001</td><td>5461</td><td>32768</td><td>500%</td></tr> <tr><td>modexp_nagydani_4_square</td><td>1365</td><td>8192</td><td>501%</td></tr> <tr><td>modexp_nagydani_4_qube</td><td>1365</td><td>8192</td><td>501%</td></tr> <tr><td>modexp_nagydani_4_pow0x10001</td><td>21845</td><td>131072</td><td>500%</td></tr> <tr><td>modexp_nagydani_5_square</td><td>5461</td><td>32768</td><td>500%</td></tr> <tr><td>modexp_nagydani_5_qube</td><td>5461</td><td>32768</td><td>500%</td></tr> <tr><td>modexp_nagydani_5_pow0x10001</td><td>87381</td><td>524288</td><td>500%</td></tr> <tr><td>modexp_marius_1_even</td><td>2057</td><td>45296</td><td>2102%</td></tr> <tr><td>modexp_guido_1_even</td><td>2298</td><td>51136</td><td>2125%</td></tr> <tr><td>modexp_guido_2_even</td><td>2300</td><td>51152</td><td>2124%</td></tr> <tr><td>modexp_guido_3_even</td><td>5400</td><td>32400</td><td>500%</td></tr> <tr><td>modexp_guido_4_even</td><td>1026</td><td>94448</td><td>9105%</td></tr> <tr><td>modexp_marcin_1_base_heavy</td><td>200</td><td>1152</td><td>476%</td></tr> <tr><td>modexp_marcin_1_exp_heavy</td><td>215</td><td>16624</td><td>7632%</td></tr> <tr><td>modexp_marcin_1_balanced</td><td>200</td><td>1200</td><td>500%</td></tr> <tr><td>modexp_marcin_2_base_heavy</td><td>867</td><td>5202</td><td>500%</td></tr> <tr><td>modexp_marcin_2_exp_heavy</td><td>852</td><td>16368</td><td>1821%</td></tr> <tr><td>modexp_marcin_2_balanced</td><td>996</td><td>5978</td><td>500%</td></tr> <tr><td>modexp_marcin_3_base_heavy</td><td>677</td><td>2032</td><td>200%</td></tr> <tr><td>modexp_marcin_3_exp_heavy</td><td>765</td><td>4080</td><td>433%</td></tr> <tr><td>modexp_marcin_3_balanced</td><td>1360</td><td>4080</td><td>200%</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP does not introduce any new functionality or make existing operations cheaper, therefore there are no direct security concerns related to new attack vectors or reduced costs. The primary security consideration for this EIP is the potential for <code>ModExp</code> scenarios to be overpriced, though this is deemed a lesser risk compared to the current underpricing issues.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-02-08T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7880/

Add EXTCODEADDRESS instruction to EOF to address code delegation use cases

<h2 id="abstract">Abstract</h2> <p>Add an instruction to EOF that reads code delegation designations from an account without requiring code introspection.</p> <h2 id="motivation">Motivation</h2> <p>EOFv1 as scoped in <a href="https://wg-eips.ritovision.com/7692/">EIP-7692</a> removes code introspection capabilities from the EVM, preventing EOF from reading raw code values such as code delegation designations set by <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>. There are a number of use cases where reading the delegation designation of <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> would allow contracts to be more proactive about user experience issues.</p> <p>One example is a managed proxy contract. Such a contract may want to ensure security by not allowing the proxy to be updated to a delegated address. There are also safety concerns with pointing to a delegation, as the contract may be updated to non EOF code and <code>EXTDELEGATECALL</code> will no longer be able to call the contract, due to changes outside the control of the managed proxy contract.</p> <p>Another example are contracts that need to ensure that the delegation has not changed over a limited scope of time, such as sponsorships. This will prevent a transaction from receiving gas sponsorship, changing the delegation, and performing an act different than what was approved. Sponsors can encode the delegation into the transaction data and verify with this instruction.</p> <p>Finally, there is the case where contracts may want to de-escalate risks and only accept a small number of delegations for any given contract. To enable this validation contracts will need to be able to resolve the actual address of delegation, not just know that one exists.</p> <p>To address this the essential task of the designation parsing is moved into a new opcode <code>EXTCODEADDRESS</code>, where the task of calculating the delegated address will be performed. For non-delegated accounts or empty accounts the address will be the same as the queried address.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>GAS_COLD_ACCOUNT_ACCESS</code></td><td>Defined as <code>2600</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/1adcc1bfe774798bcacc685aebc17bd9935078c3/src/ethereum/cancun/vm/gas.py#L65-L66">Ethereum Execution Layer Spec Constants</a></td></tr> <tr><td><code>GAS_WARM_ACCESS</code></td><td>Defined as <code>100</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/1adcc1bfe774798bcacc685aebc17bd9935078c3/src/ethereum/cancun/vm/gas.py#L65-L66">Ethereum Execution Layer Spec Constants</a></td></tr> </tbody></table> <p>We introduce a new EOFv1 instruction <code>EXTCODEADDRESS</code> (<code>0xea</code>).</p> <p>EOF code which contains this instruction prior to the fork activating this instruction is considered invalid. Beginning with the first block this EIP is activated in, this instruction is added to the set of valid EOFv1 instructions.</p> <h3 id="execution-semantics">Execution Semantics</h3> <h4 id="extcodeaddress"><code>EXTCODEADDRESS</code></h4> <ul> <li>Deduct <code>GAS_WARM_ACCESS</code> gas</li> <li>pop 1 argument <code>target_address</code> from the stack</li> <li>if <code>target_address</code> has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address), then halt with an exceptional failure <ul> <li>Notice: Future expansion of the EVM address space may enlarge the number of valid addresses. Do not rely on this step always halting with the current restrictions.</li> </ul> </li> <li>deduct <code>GAS_COLD_ACCOUNT_ACCESS - GAS_WARM_ACCESS</code> if <code>target_address</code> is not in <code>accessed_addresses</code> and add <code>target_address</code> to <code>accessed_addresses</code></li> <li>Load the code from <code>target_address</code> and refer to it as <code>loaded_code</code></li> <li>If <code>loaded_code</code> indicates a delegation designator (for example, prefixed with <code>0xef0100</code> as defined in <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>) push the address of the designation onto the stack. <ul> <li>Notice: if <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation designations are updated in a future fork (such as allowing chained delegations), then this section is expected to comply with any such hypothetical changes.</li> </ul> </li> <li>Otherwise, push <code>target_address</code> onto the stack.</li> </ul> <p>Note: If <code>target_address</code> points to an account with a contract mid-creation, then <code>target_address</code> is returned. If delegation designator points to an account with a contract mid-creation, then address of the designation is returned.</p> <p>Note: Only <code>target_address</code> is warmed. If a delegation is found the address that it is delegated to is not added to the <code>accessed_addresses</code>. Also, whether the delegated address is in <code>accessed_addresses</code> has no impact on the gas charged for the operation.</p> <p>Note: This operation straddles the line between <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> code reading and code executing instructions. The operation steps work as a code reading instruction, but the value returned is the resolved address as through it is a code executing instruction.</p> <h2 id="rationale">Rationale</h2> <p>This EIP is very similar to <a href="https://wg-eips.ritovision.com/7761/">EIP-7761</a>, which introduces account type introspection. Its rationale is included by reference as they all apply to this situation.</p> <h3 id="alternative-return-the-whole-designation-have-contract-parse">Alternative: Return the whole designation, have contract parse</h3> <p>One alternative is to have a specially limited <code>EXTCODECOPY</code> that would return just delegation designations. Apart from the general objections to code introspection this would then lock in and limit delegation designation formats and capabilities that must be preserved in future forks. By allowing access to the effect of the delegation rather than the mechanism, EOF preserves space for the mechanism to be changed without breaking existing code.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>EXTCODEADDRESS</code> at <code>0xea</code> can be introduced in a backwards compatible manner into EOFv1 (no bump to version), because <code>0xea</code> has been rejected by EOF validation prior to the activation of this EIP, and there are no EOF contracts on-chain with an <code>0xea</code> instruction which would have their behavior altered.</p> <h2 id="security-considerations">Security Considerations</h2> <p><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> code delegation is a new feature that has not been made accessible to mainnet yet. EIP authors will keep abreast of any developments and reflect on their impact to this proposed instruction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a></p> 2025-02-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Jacek Glenhttps://github.com/JacekGlen Lukasz Glenhttps://github.com/lukasz-glen Maria Silvahttps://github.com/misilva73 https://wg-eips.ritovision.com/7904/

Gas Cost Increase to reflect computational complexity and transaction throughput increase

<h2 id="abstract">Abstract</h2> <p>This proposal raises the gas costs of 13 compute operations and precompiles performing worse than 60 million gas per second (Mgas/s). By removing these operations as bottlenecks, we can further increase the block gas limit, thus allowing for a higher throughput on the remaining operations.</p> <h2 id="motivation">Motivation</h2> <p>Recent empirical measurements have shown that EVM operations don't have a price consistent with their computational complexity. Some operations are significantly underpriced, leading to potential bottlenecks in transaction processing. These bottlenecks limit the overall throughput of the Ethereum network, as they consume a disproportionate amount of computational resources relative to their gas cost.</p> <p>By increasing the gas costs of these underpriced operations, we can alleviate these bottlenecks. This change will enable a higher block gas limit, allowing more transactions to be processed per block. The result is an overall increase in network throughput, improving the efficiency and scalability of the Ethereum blockchain.</p> <h2 id="specification">Specification</h2> <p>Upon activation of this EIP, the following gas costs will be updated.</p> <h3 id="opcodes">Opcodes</h3> <table><thead><tr><th style="text-align: center">Operation</th><th style="text-align: center">Parameter</th><th style="text-align: center">Current Gas</th><th style="text-align: center">New Gas (Rounded)</th><th style="text-align: center">Change</th></tr></thead><tbody> <tr><td style="text-align: center">ADDMOD</td><td style="text-align: center">constant</td><td style="text-align: center">8</td><td style="text-align: center">8</td><td style="text-align: center">0.0</td></tr> <tr><td style="text-align: center">DIV</td><td style="text-align: center">constant</td><td style="text-align: center">5</td><td style="text-align: center">15</td><td style="text-align: center">2.0</td></tr> <tr><td style="text-align: center">KECCAK256</td><td style="text-align: center">constant</td><td style="text-align: center">30</td><td style="text-align: center">45</td><td style="text-align: center">0.5</td></tr> <tr><td style="text-align: center">KECCAK256</td><td style="text-align: center">msg_size</td><td style="text-align: center">6</td><td style="text-align: center">6</td><td style="text-align: center">0.0</td></tr> <tr><td style="text-align: center">MOD</td><td style="text-align: center">constant</td><td style="text-align: center">5</td><td style="text-align: center">12</td><td style="text-align: center">1.4</td></tr> <tr><td style="text-align: center">MULMOD</td><td style="text-align: center">constant</td><td style="text-align: center">8</td><td style="text-align: center">11</td><td style="text-align: center">0.38</td></tr> <tr><td style="text-align: center">SDIV</td><td style="text-align: center">constant</td><td style="text-align: center">5</td><td style="text-align: center">20</td><td style="text-align: center">3.0</td></tr> <tr><td style="text-align: center">SMOD</td><td style="text-align: center">constant</td><td style="text-align: center">5</td><td style="text-align: center">5</td><td style="text-align: center">0</td></tr> </tbody></table> <h3 id="precompiles">Precompiles</h3> <table><thead><tr><th style="text-align: center">Operation</th><th style="text-align: center">Parameter</th><th style="text-align: center">Current Gas</th><th style="text-align: center">New Gas (Rounded)</th><th style="text-align: center">Change</th></tr></thead><tbody> <tr><td style="text-align: center">BLAKE2F</td><td style="text-align: center">constant</td><td style="text-align: center">0</td><td style="text-align: center">170</td><td style="text-align: center">NA</td></tr> <tr><td style="text-align: center">BLAKE2F</td><td style="text-align: center">num_rounds</td><td style="text-align: center">1</td><td style="text-align: center">2</td><td style="text-align: center">1.0</td></tr> <tr><td style="text-align: center">BLS12_G1ADD</td><td style="text-align: center">constant</td><td style="text-align: center">375</td><td style="text-align: center">643</td><td style="text-align: center">0.71</td></tr> <tr><td style="text-align: center">BLS12_G2ADD</td><td style="text-align: center">constant</td><td style="text-align: center">600</td><td style="text-align: center">765</td><td style="text-align: center">0.27</td></tr> <tr><td style="text-align: center">ECADD</td><td style="text-align: center">constant</td><td style="text-align: center">150</td><td style="text-align: center">314</td><td style="text-align: center">1.09</td></tr> <tr><td style="text-align: center">ECPAIRING</td><td style="text-align: center">constant</td><td style="text-align: center">45000</td><td style="text-align: center">45000</td><td style="text-align: center">0.0</td></tr> <tr><td style="text-align: center">ECPAIRING</td><td style="text-align: center">num_pairs</td><td style="text-align: center">34000</td><td style="text-align: center">34103</td><td style="text-align: center">0.0</td></tr> <tr><td style="text-align: center">ECRECOVER</td><td style="text-align: center">constant</td><td style="text-align: center">3000</td><td style="text-align: center">3000</td><td style="text-align: center">0</td></tr> <tr><td style="text-align: center">POINT_EVALUATION</td><td style="text-align: center">constant</td><td style="text-align: center">50000</td><td style="text-align: center">89363</td><td style="text-align: center">0.79</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <h3 id="empirical-estimation-of-gas-costs">Empirical Estimation of Gas Costs</h3> <h4 id="selecting-which-operations-to-reprice">Selecting which Operations to Reprice</h4> <p>The operations selected for repricing in this EIP were chosen based on their estimated million gas per second (Mgas/s) performance. For this EIP, a performance target of <strong>60 million gas per second</strong> is chosen. With this performance target, we will be able to increase the base throughput of the chain by 3x from our current 20Mgas/s performance.</p> <p>An important consideration for repricing is whether poor performance is isolated to a single client or affects multiple implementations. This is important for distinguishing between:</p> <ul> <li>Operations that genuinely need repricing (multiple clients struggle)</li> <li>Operations where a specific client needs optimization (only one client struggles)</li> </ul> <p>To separate these cases, we analyze the performance of each operation the 5 main clients (besu, erigon, geth, nethermind and reth). If the difference in performance between the worst and the second-worst client is higher than 20%, we consider the operation to be a candidate for optimization rather than repricing. All the remaining operations are candidates for repricing.</p> <p>The report with the full details of this step can be accessed <a href="https://wg-eips.ritovision.com/7904/assets/included_operations/">here</a>.</p> <h4 id="data-collection">Data Collection</h4> <p>The gas costs proposed in this EIP are based on the actual time each operation takes to run on the various execution clients. Similar to the methodology used in the Gas Cost Estimator project, synthetic blocks that isolate and stress individual EVM operations are generated. To benchmark a single operation, different blocks are created by varying the number of single operations executed and by changing the parameter values to the operation. The EEST benchmark suite contains the tests used to generate these blocks.</p> <p>Then, the Nethermind's Performance Benchmarking tool is used to collect the needed metrics. This tool returns the total execution time of the block and the number of times each operation was executed. Each test block is run multiple times on each client to account for variability in execution time.</p> <p><strong>What about dynamic costs?</strong></p> <p>Some operations have a dynamic component to their costs. For example, the <code>EXP</code> opcode has a gas cost that grows linearly with the exponent's byte size. In these cases, the test benchmarks the operation with a range of inputs to assess how the resource costs vary with different inputs.</p> <p><strong>What about differences between client implementations?</strong></p> <p>Ultimately, we require a single cost model that is independent of the client's implementation. Although the decision may be different in a specific situation, the general rule is to take the worst client result that cannot be optimized. This means that the worst-performing client on a given operation and resource combination will define the cost of that operation for the entire network. This is the safer and most conservative choice.</p> <h4 id="runtime-estimation">Runtime Estimation</h4> <p>To estimate the runtime of a single operation from the total execution time of the corresponding synthetic blocks, a <strong>Non-Negative Least Squares (NNLS) Linear Regression</strong> is used. This model enforces that all coefficients are non-negative, thus ensuring execution time cannot be negative. The model estimates runtime as a linear combination of:</p> <ul> <li><strong>Constant term (intercept)</strong>: Base overhead for executing the test, which includes setup and teardown time</li> <li><strong>Operation count (slope)</strong>: Number of times the operation is executed in the test. This parameter is the one that allows us to estimate the per-operation runtime.</li> <li><strong>Operation-specific parameters</strong>: Variables like number of rounds, message size, or number of pairs</li> </ul> <p>For simple operations (i.e., without additional parameters), the model estimates: <code>runtime = intercept + slope × operation_count</code></p> <p>For variable operations, the model estimates: <code>runtime = intercept + slope × operation_count + param1_coef × operation_count × param1 + param2_coef × operation_count × param2 + ...</code></p> <p>Independent models are created for each client and operation. Only operations and parameters with good model fits (R² &gt; 0.5 and p-value &lt; 0.05) are included in the gas cost proposal to ensure the reliability of the estimates.</p> <p>The report with the model performance by operation and client can be accessed <a href="https://wg-eips.ritovision.com/7904/assets/runtime_estimation/2026-01-15_2026-01-29/runtime_estimation_autogenerated_report/">here</a>, while the key model outputs can be found <a href="https://wg-eips.ritovision.com/7904/./assets/runtime_estimation/2026-01-15_2026-01-29/results.csv">here</a>.</p> <h4 id="conversion-to-gas-costs">Conversion to gas costs</h4> <p>New gas costs are calculated using the same target performance of 60Mgas/s. The formula used is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_gas = (anchor_rate * runtime_ms) / 1000</span></span></code></pre> <p>Where <code>runtime_ms</code> is the estimated runtime in milliseconds from the regression models.</p> <p>The report with the full details of this step can be accessed <a href="https://wg-eips.ritovision.com/7904/assets/runtime_estimation/2026-01-15_2026-01-29/new_gas_proposal/">here</a>.</p> <h3 id="other-projects">Other Projects</h3> <p>Several initiatives have explored the real gas costs of EVM operations, providing valuable context for this EIP. Notable examples include:</p> <ul> <li>The <a href="https://wg-eips.ritovision.com/7904/./assets/gas-cost-estimator-report.pdf">Gas Cost Estimator</a> project did a similar empirical analysis. It conducted extensive testing across seven widely-used EVM implementations to measure the actual computational effort required by various opcodes and operations. Conducted in a controlled environment to eliminate external variables, the tests produced accurate and reproducible <a href="https://wg-eips.ritovision.com/7904/./assets/final_gas_schedule_comparison.csv">results</a>. The <a href="https://wg-eips.ritovision.com/7904/./assets/gas-cost-estimator.pdf">findings</a> highlight misalignments between the current gas cost schedule and the real-world computational complexity of EVM operations.</li> <li><a href="https://wg-eips.ritovision.com/7883/">EIP-7883</a> - ModExp Gas Cost Increase: This EIP specifically analyzed the ModExp and proposed a revised pricing scheme. When adjusted with our <code>rescale factor</code>, its costs align with this proposal, requiring no further changes. This consistency validates our measuring approach.</li> <li>Nethermind's Gas Benchmarks: This project takes a different approach to measuring gas costs. It uses standalone clients rather than isolated EVM implementations. Despite the methodological difference, its results mirror those of the Gas Cost Estimator, reinforcing our conclusions.</li> <li>EVM Memory Analysis by @raxhvl: This project focuses on memory-related costs, providing valuable insights into the memory access and expansion costs.</li> </ul> <p>These projects collectively affirm the need to reassess gas costs and demonstrate broad alignment with our approach.</p> <h3 id="computational-complexity-only">Computational Complexity Only</h3> <p>This EIP intentionally focuses on computational complexity—measured as execution time on a bare CPU — while excluding network-related costs like state persistency. This ensures the proposed gas cost adjustments remain implementation-agnostic, applicable across diverse EVM clients regardless of their technological stack. By leveraging empirical data from multiple EVM implementations, we establish a universal, verifiable benchmark for computational effort. This focus simplifies estimation and enhances the proposal’s clarity and applicability within Ethereum’s varied ecosystem.</p> <h3 id="impact-of-gas-costs-changes">Impact of Gas Costs Changes</h3> <p>Raising costs for underpriced operations strengthens security by deterring abuse but may increase transaction fees and reduce throughput.</p> <p>This EIP adopts a conservative strategy, prioritizing increases for operations that empirical data show as underpriced. This allows us to increase the base throughput of the chain without changing the costs of the majority of the other operations.</p> <h4 id="point-evaluation-and-blob-fee-floor-price"><code>POINT_EVALUATION</code> and Blob Fee Floor Price</h4> <p>The proposed increase to <code>POINT_EVALUATION</code> gas cost (from 50,000 to 89,363) has implications for the blob fee floor price mechanism established in <a href="https://wg-eips.ritovision.com/7918/">EIP-7918</a>. Under EIP-7918, the blob base fee is bounded by execution costs through a reserve price of <code>BLOB_BASE_COST * base_fee_per_gas</code>, ensuring that blob consumers pay at least a relevant fraction of the market rate for the computational resources they impose on nodes. The computational resources imposed by blobs are the KZG proof commitments for blob transactions and, as such, the <code>BLOB_BASE_COST</code> was originally defined based on the cost of the <code>POINT_EVALUATION</code> precompile. However, for simplicity reasons, we decide not to change the <code>BLOB_BASE_COST</code>.</p> <h3 id="consideration-of-zk-snark-proof-generation">Consideration of ZK-SNARK Proof Generation</h3> <p>This EIP focuses on optimizing gas costs based on general computational complexity, using a bare CPU as the reference point. Therefore, it does not specifically address the unique demands of ZK-SNARK proof generation. Nevertheless, given that this EIP is only increasing the gas costs of certain operations, it will help rather than hinder proving times for EVM blocks.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Developers and node operators MUST update gas estimation handling to accommodate the new costs. Specifically:</p> <ul> <li>Wallets: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.</li> <li>Node Software: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation with the new state access cost values.</li> <li>Contracts with Hardcoded Gas Limits: Contracts that specify hardcoded gas limits for subcalls (e.g., using call(gas, ...)) may face issues if the new gas costs exceed these limits. In these cases, developers MUST review and potentially update these contracts to ensure they function as intended post-upgrade.</li> </ul> <p>Further research might be required to ensure that contracts that use hard coded limits are not broken.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Changing the cost of compute operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-01-31T00:00:00+00:00 2026-02-11T14:49:28+00:00 Piotr Dobaczewskihttps://github.com/pdobacz Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast Alex Beregszaszihttps://github.com/axic Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7873/

Adds a `TXCREATE` instruction to EOF and an accompanying transaction type allowing to create EOF contracts from transaction data

<h2 id="abstract">Abstract</h2> <p>EVM Object Format (EOF) removes the possibility to create contracts using creation transactions (with an empty <code>to</code> field), <code>CREATE</code> or <code>CREATE2</code> instructions. We introduce a new instruction: <code>TXCREATE</code>, as well as a new transaction type (<code>InitcodeTransaction</code>), to provide a way to create contracts using EOF containers in transaction data.</p> <h2 id="motivation">Motivation</h2> <p>This EIP uses terminology from the <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> which introduces the EOF format.</p> <p>Creation transaction and creation instructions <code>CREATE</code> and <code>CREATE2</code> are means provided by legacy EVM to deploy new code, but per requirement of removing code observability, they are not allowed to deploy EOF code. To allow Externally Owned Accounts (EOAs) to deploy EOF contracts, there must be a way to create EOF contracts using bytecode delivered in transaction data.</p> <p>Additionally, the new instruction and transaction type introduced in this EIP enable contracts to create other contracts using initcode from the transaction data, which in legacy EVM is achieved via a combination of <code>CREATE</code> or <code>CREATE2</code> and loading the initcode from calldata.</p> <p>This mechanism complements <code>EOFCREATE</code> and <code>RETURNCODE</code> instructions from <a href="https://wg-eips.ritovision.com/7620/">EIP-7620</a>, and thus all use cases of contract creation that are available in legacy EVM are enabled for EOF.</p> <p>Since <code>TXCREATE</code> is not restricted to EOF containers, it also serves the purpose of bootstrapping EOF contracts into the state.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>INITCODE_TX_TYPE</code></td><td><code>Bytes1(0x06)</code></td></tr> <tr><td><code>MAX_INITCODE_COUNT</code></td><td><code>256</code></td></tr> <tr><td><code>TX_CREATE_COST</code></td><td>Defined as <code>32000</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork_types.py#L42">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>STACK_DEPTH_LIMIT</code></td><td>Defined as <code>1024</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/vm/interpreter.py#L60">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>GAS_CODE_DEPOSIT</code></td><td>Defined as <code>200</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/vm/gas.py#L44">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>TX_DATA_COST_PER_ZERO</code></td><td>Defined as <code>4</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork_types.py#L41">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>TX_DATA_COST_PER_NON_ZERO</code></td><td>Defined as <code>16</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork_types.py#L40">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>MAX_CODE_SIZE</code></td><td>Defined as <code>24576</code> in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a></td></tr> <tr><td><code>MAX_INITCODE_SIZE</code></td><td>Defined as <code>2 * MAX_CODE_SIZE</code> in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a></td></tr> </tbody></table> <h3 id="transaction-types">Transaction Types</h3> <p>Introduce new transaction <code>InitcodeTransaction</code> (type <code>INITCODE_TX_TYPE</code>) which extends <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> (type 2) transaction by adding a new field <code>initcodes: List[ByteList[MAX_INITCODE_SIZE], MAX_INITCODE_COUNT]</code>.</p> <p>The <code>initcodes</code> can only be accessed via the <code>TXCREATE</code> instruction (see below), therefore <code>InitcodeTransactions</code> are intended to be sent to contracts including <code>TXCREATE</code> in their execution.</p> <h4 id="gas-schedule">Gas schedule</h4> <p><code>initcodes</code> items data costs the same as calldata: transaction gas of an <code>InitcodeTransaction</code> is extended to include tokens in <code>initcodes</code> alongside tokens in <code>calldata</code>. Using the conventions from <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>, the transaction gas is calculated as:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">STANDARD_TOKEN_COST</span><span class="z-keyword"> =</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span class="z-constant">TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> =</span><span class="z-constant"> 10</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>tokens_in_calldata</span><span class="z-keyword"> =</span><span> zero_bytes_in_calldata</span><span class="z-keyword"> +</span><span> nonzero_bytes_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span>tokens_in_initcodes</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword">for</span><span> initcode</span><span class="z-keyword"> in</span><span> initcodes</span><span>:</span></span> <span class="giallo-l"><span> tokens_in_initcodes</span><span class="z-keyword"> +=</span><span> zero_bytes_in_initcode</span><span class="z-keyword"> +</span><span> nonzero_bytes_in_initcode</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> (</span><span>tokens_in_calldata</span><span class="z-keyword"> +</span><span> tokens_in_initcodes</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> (</span><span>tokens_in_calldata</span><span class="z-keyword"> +</span><span> tokens_in_initcodes</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span>)</span></span></code></pre><h4 id="transaction-validation">Transaction validation</h4> <ul> <li><code>InitcodeTransaction</code> is invalid if there are zero entries in <code>initcodes</code>, or if there are more than <code>MAX_INITCODE_COUNT</code> entries.</li> <li><code>InitcodeTransaction</code> is invalid if any entry in <code>initcodes</code> is zero length, or if any entry exceeds <code>MAX_INITCODE_SIZE</code>.</li> <li><code>InitcodeTransaction</code> is invalid if the <code>to</code> is <code>nil</code>.</li> </ul> <p>Under transaction validation rules <code>initcodes</code> are not validated for conforming to the EOF specification. They are only validated when accessed via <code>TXCREATE</code>. This avoids potential DoS attacks of the mempool. If during the execution of an <code>InitcodeTransaction</code> no <code>TXCREATE</code> instruction is called, such transaction is still valid.</p> <p>Other creation transactions that support contract creation (specifically type 0 "Frontier," type 1 "AccessList," type 2 "FeeMarket" transactions with an empty <code>to</code> field) will not attempt to parse EOF containers in their <code>input</code> field and will execute the code as non-EOF code. This will result in immediately executing the undefined <code>0xEF</code> instruction and halting.</p> <h4 id="rlp-and-signature">RLP and signature</h4> <p>Given the definitions from <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> the <code>TransactionPayload</code> for an <code>InitcodeTransaction</code> is the RLP serialization of:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, initcodes, y_parity, r, s]</span></span></code></pre> <p><code>TransactionType</code> is <code>INITCODE_TX_TYPE</code> and the signature values <code>y_parity</code>, <code>r</code>, and <code>s</code> are calculated by constructing a secp256k1 signature over the following digest:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>keccak256(INITCODE_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, initcodes]))</span></span></code></pre> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <h3 id="execution-semantics">Execution Semantics</h3> <p>Wherever not explicitly listed, the rules of EOF contract creation, as well as the <code>TXCREATE</code> instruction, should be identical or analogous to those of <code>CREATE2</code> instruction. This includes but is not limited to:</p> <ul> <li>behavior on <code>accessed_addresses</code> and address collision (<a href="https://wg-eips.ritovision.com/684/">EIP-684</a> and <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>)</li> <li>EVM execution frame created for the <code>TXCREATE</code> initcode - memory, account context etc.</li> <li>nonce bumping of the account of newly created contract <a href="https://wg-eips.ritovision.com/161/">EIP-161</a></li> <li>balance checking and transfer for the creation endowment (<code>value</code> argument)</li> </ul> <p>Introduce a new instruction on the same block number <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is activated on: <code>TXCREATE</code> (<code>0xed</code>).</p> <h4 id="txcreate"><code>TXCREATE</code></h4> <ul> <li>deduct <code>TX_CREATE_COST</code> gas</li> <li>halt with exceptional failure if the current frame is in <code>static-mode</code>.</li> <li>pop <code>tx_initcode_hash</code>, <code>salt</code>, <code>input_offset</code>, <code>input_size</code>, <code>value</code> from the operand stack</li> <li>perform (and charge for) memory expansion using <code>[input_offset, input_size]</code></li> <li>load initcode EOF container from the transaction <code>initcodes</code> array which hashes to <code>tx_initcode_hash</code> <ul> <li>fails (returns 0 on the stack) if such initcode does not exist in the transaction, or if called from a transaction of <code>TransactionType</code> other than <code>INITCODE_TX_TYPE</code> <ul> <li>caller's nonce is not updated and gas for initcode execution is not consumed.</li> </ul> </li> <li>let <code>initcontainer</code> be that EOF container, and <code>initcontainer_size</code> its length in bytes</li> </ul> </li> <li>check that current call depth is below <code>STACK_DEPTH_LIMIT</code> and that caller balance is enough to transfer <code>value</code> <ul> <li>in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed.</li> </ul> </li> <li><strong>validate the initcode container and all its subcontainers recursively</strong> <ul> <li>unlike in general validation, <code>initcontainer</code> is additionally required to have <code>data_size</code> declared in the header equal to actual <code>data_section</code> size.</li> <li>validation includes checking that the <code>initcontainer</code> does not contain <code>RETURN</code> or <code>STOP</code></li> </ul> </li> <li>fails (returns 0 on the stack) if container was invalid <ul> <li>caller’s nonce is not updated and gas for initcode execution is not consumed.</li> </ul> </li> <li>caller's memory slice <code>[input_offset:input_size]</code> is used as calldata</li> <li>execute the container and deduct gas for execution. The 63/64th rule from <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> applies.</li> <li>increment <code>sender</code> account's nonce</li> <li>calculate <code>new_address</code> as <code>keccak256(0xff || sender32 || salt)[12:]</code>, where <code>sender32</code> is the sender address left-padded to 32 bytes with zeros</li> <li>an unsuccessful execution of initcode results in pushing <code>0</code> onto the stack <ul> <li>can populate returndata if execution <code>REVERT</code>ed</li> <li><code>sender</code>'s nonce stays updated</li> </ul> </li> <li>a successful execution ends with initcode executing <code>RETURNCODE{deploy_container_index}(aux_data_offset, aux_data_size)</code> instruction (see <a href="https://wg-eips.ritovision.com/7620/">EIP-7620</a>). After that: <ul> <li>load deploy EOF subcontainer at <code>deploy_container_index</code> in the container from which <code>RETURNCODE</code> is executed</li> <li>concatenate data section with <code>(aux_data_offset, aux_data_offset + aux_data_size)</code> memory segment and update data size in the header</li> <li>if updated deploy container size exceeds <code>MAX_CODE_SIZE</code>, instruction exceptionally aborts</li> <li>set <code>state[new_address].code</code> to the updated deploy container</li> <li>push <code>new_address</code> onto the stack</li> </ul> </li> <li>deduct <code>GAS_CODE_DEPOSIT * deployed_code_size</code> gas</li> </ul> <p>Note that the implementations are expected to cache the result of container validation for the time of current transaction execution, and therefore the cost of each container's validation is sufficiently covered by <code>InitcodeTransaction</code> intrinsic cost (initcodes charge).</p> <h2 id="rationale">Rationale</h2> <h3 id="txcreate-failure-modes"><code>TXCREATE</code> failure modes</h3> <p><code>TXCREATE</code> has two "light" failure modes in case the initcontainer is not present and in case the EOF validation is unsuccessful. An alternative design where both cases led to a "hard" failure (consuming the entire gas available) was considered. We decided to have the more granular and forgiving failure modes in order to align the gas costs incurred to the actual work the EVM performs.</p> <h3 id="allowing-txcreate-in-legacy-evm">Allowing <code>TXCREATE</code> in legacy EVM</h3> <p>EOF contract creation requires an exceptional possibility of calling an EOF opcode in legacy code - <code>TXCREATE</code>, because otherwise neither legacy contracts nor create transactions can deploy EOF code to bootstrap. The alternative approach was to continue using legacy creation mechanisms, by either still relying on fetching the <em>initcode</em> from memory and not satisfy the overarching requirement of code non-observability, or to abuse the legacy creation transactions mechanism, or to introduce a predeployed Creator Contract into the state.</p> <p>This also makes <a href="https://wg-eips.ritovision.com/7698/">EIP-7698</a> (EOF - Creation transaction) no longer an essential requirement for deploying EOF contracts onto the chain. The EIP could be removed from EOFv1 and withdrawn.</p> <h3 id="new-address-hashing-scheme">New address hashing scheme</h3> <p><code>TXCREATE</code> uses the scheme <code>new_address = keccak256(0xff || sender32 || salt)[12:]</code>, same as <code>EOFCREATE</code> instruction. The decision whether to include initcontainer hash into salt is left to the <code>TXCREATE</code> caller. See <a href="https://wg-eips.ritovision.com/7620/">EIP-7620</a> for detailed rationale.</p> <h3 id="eof-creation-transactions-vs-deployment-patterns">EOF creation transactions vs deployment patterns</h3> <p>Relying on the EOF creation transactions as the alternative solution makes it impossible for smart contract wallets to deploy arbitrary EOF contracts (only EOAs can). At the same time, it is a use case current legacy creation rules allow, thanks to <code>CREATE</code> and <code>CREATE2</code> instructions. A workaround where those arbitrary EOF contracts are first "uploaded" to a factory contract, and then deployed using an <code>EXTDELEGATECALL</code>-<code>EOFCREATE</code> sequence, is very expensive, as it requires the deployed contract to be put on-chain twice. Because of this, the approach proposed in this EIP is more compatible with the Account Abstraction (AA) roadmap, where smart contract wallets should have feature parity with EOAs.</p> <p>On top of this, relying on nonce-based hashing scheme to obtain addresses of newly created contracts, like in the case of the EOF creation transactions, would prevent EOF contracts from being deployed counterfactually to deterministic, cross-chain addresses. Introduction of the <code>TXCREATE</code> instruction, supports this out of the box. ERCs can be written to provide toehold contracts which will cater for the deployment patterns, such as salt-less deployment and hashing in the sender's address as part of the salt.</p> <h3 id="handling-of-0xef00-prefixed-code-in-existing-transaction-types">Handling of <code>0xEF00</code> prefixed code in existing transaction types.</h3> <p>Three existing transaction types (type 0 "Frontier," type 1 "AccessList," type 2 "FeeMarket") accept code as part of their input data in certain configurations. This code can start with <code>EF</code> as it is initcode and not a deployed contract.</p> <p>One possible way of handling potential EOF containers in these transactions is to make them invalid if they are attempting to execute an EOF container as initcode. Specifically the transactions is invalid if the input data begins with <code>0xef00</code> and if the <code>to</code> field is set to nil, signaling a contract creation transaction. This would make blocks containing these transactions invalid, whereas before the fork including this EIP they would have been valid.</p> <p>One impact that would be seen by this would be block builders, as they would need to ensure that the transactions that are invalid are not included in a block. There is precedent for this, as <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> established a new floor for the gas limit in transactions, prior to its adoption the limit was lower. However, block builders have an existing check on gas limits and transactions and that change was adjusting the formula and constants.</p> <p>We should also consider the treatment <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation designations receive if they show up as code in a contract creation transaction. The transaction is valid, is executed as plain bytecode, ad the first operation executed is <code>0xEF</code>, which is an invalid opcode and would cause the whole transaction to abort.</p> <p>Letting the inputdata of a type 0, 1, and 2 contract creation transaction execute as plain EVM code irrespective of the magic <code>0xEF00</code> bytes keeps a consistent behavior in client code and keeps block builders from having to update their logic in older transaction types.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. Despite the new instruction being introduced for legacy bytecode (code which is not EOF formatted), there is little chance that a meaningful contract would unintentionally execute <code>0xed</code> instruction with formally valid operands and inadvertently cause it to run EOF initcode (which would also require an <code>InitcodeTransaction</code> to be used, otherwise the initcode lookup will fail).</p> <p><code>TXCREATE</code> instruction introduction into legacy EVM does not affect <code>JUMPDEST</code> analysis, because instruction has no immediate arguments.</p> <p>The transactions of the new type are invalid until this change activates.</p> <p>Contract creation options do not change for legacy bytecode, including how existing transactions with <code>to: nil</code> behave when encountering code in their calldata that may look like an EOF container.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-01-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Josh Weintraubhttps://github.com/jhweintraub https://wg-eips.ritovision.com/7877/

Deprecate RETURN opcode in favor of new opcodes that allow returning data from various locations without first having to write to memory.

<h2 id="abstract">Abstract</h2> <p>This EIP specifies a series of new <code>RETURN</code> opcodes which allow the user to specify which data location to return from instead of defaulting to returning from memory.</p> <h2 id="motivation">Motivation</h2> <p>With the introduction of transient storage, many smart contracts have begun to store data using the new transient opcodes to optimize for gas usage, whereby a callback involves returning the data previously stored transiently. However, the current <code>RETURN</code> opcode only allows for returning sequential bytes in memory. This requires developers to incur additional gas overhead by manually writing data from transient storage to memory before returning, incuring both an additional memory expansion and opcode cost from complicated for-loops. Similar inefficiencies already occur when attempting to return data already placed in storage. This EIP attempts to rectify this by allowing developers to optimize their code by deciding where to return data from directly, instead of requiring the intermediate step of first copying the data to memory.</p> <h2 id="specification">Specification</h2> <p>This EIP introduces 3 new opcodes as well as renaming/aliasing an existing one.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SRETURN (0xf6)</span></span> <span class="giallo-l"><span>TRETURN (0xf7)</span></span> <span class="giallo-l"><span>RRETURN (0xf8)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>RETURN -&gt; MRETURN (0xf3)</span></span></code></pre> <p>The <code>MRETURN</code> opcode is a rename of <code>RETURN</code>, whereby sequential bytes in memory are returned. It will operate exactly as it currenty does as of the Cancun hard-fork, and its gas cost will remain the same.</p> <p><code>RRETURN</code> operates similar to <code>MRETURN</code>. It pops two items off the stack, an offset to begin reading bytes from in the existing <code>RETURNDATA</code> buffer, and a number of bytes to return. Those bytes are used to overwrite the existing <code>RETURNDATA</code> buffer and then a return to the previous function is performed.</p> <p><code>SRETURN</code> and <code>TRETURN</code> operate similarly, except on storage and transient respectively. It pops two items off the stack, a slot number to begin reading from, and a number of sequential slots to return from. Ex: <code>SRETURN(0x0, 0x40)</code> returns the 64 bytes of data in slots [0, 1], and <code>TRETURN(0x0, 0x40)</code> returns the data in transient storage slots [0, 1]. Since the existing <code>S/TLOAD</code> opcodes already return 32-bytes, having the opcode return data in chunks of 32-bytes should make implementation by assembly/compiler much simpler. If the length parameter is a zero, then only the initial slot value should be returned, so <code>SRETURN(0x00, 0x00)</code> returns the value at storage slot 0.</p> <p>The cost for these opcodes should be similar to the cost of accessing data now.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SRETURN = (number_of_cold_slots) * 2100 + (numer_of_warm_slots * 100)</span></span> <span class="giallo-l"><span>TRETURN = number_of_slots * 100</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>RRETURN = cost of RETURNDATACOPY without memory_expansion cost</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>minimum_word_size = (size + 31) / 32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>static_gas = 3</span></span> <span class="giallo-l"><span>dynamic_gas = 3 * minimum_word_size</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>overall = static_gas + dynamic_gas</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>Allowing for more targeted return opcodes allows for saving gas at all levels of smart contract optimization by eliminating the intermediate steps of first writing any data to memory before returning. In events where this data may be large, this can result in significant gas savings. These opcodes can be built into the Solidity compiler directly so that all contracts can take advantage of them. Similarly, by making return more explicit it allows for better static analysis by avoiding messy memory allocations.</p> <p>There is precedent for these changes.</p> <p>EIP-3855: Introducing <code>PUSH0</code> opcode to optimize away alternative methods of pushing 0 onto the stack.</p> <p>EIP-6: Renaming <code>SUICIDE</code> to <code>SELFDESTRUCT</code> without changing functionality.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backwards compatibility concerns, as <code>MRETURN</code> will utilize the same gas cost and opcode as <code>RETURN</code> does now. Due to EOF, it is suggested that these changes be activated in future EVM version once EOF has been fully implemented.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no security considerations as it is fully backwards compatible, and reduces potential attack space through simplified bytecode.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-01-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/8131/

Add EIP-7702 authorization data to the EIP-7623 floor calculation

<h2 id="abstract">Abstract</h2> <p>This EIP includes <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization data in the <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor calculation, preventing circumvention of floor pricing through authorization lists.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization tuples are priced for execution (<code>PER_EMPTY_ACCOUNT_COST = 25,000</code> gas per authorization) but do not contribute to the <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor calculation.</p> <p>This enables achieving ~9% larger blocks than intended by combining calldata with authorization data at an optimal ratio, circumventing the floor pricing mechanism.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th><th>Source</th></tr></thead><tbody> <tr><td><code>TOTAL_COST_FLOOR_PER_TOKEN</code></td><td><code>10</code></td><td><a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a></td></tr> <tr><td><code>FLOOR_COST_PER_AUTH</code></td><td><code>4040</code></td><td>101 bytes × 4 tokens × 10 gas</td></tr> <tr><td><code>PER_EMPTY_ACCOUNT_COST</code></td><td><code>25000</code></td><td><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a></td></tr> </tbody></table> <p>The <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor calculation is modified to include authorization data:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tokens_in_calldata</span><span class="z-keyword"> =</span><span> zero_bytes_in_calldata</span><span class="z-keyword"> +</span><span> nonzero_bytes_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>floor_gas</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> TX_BASE_COST</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> FLOOR_COST_PER_AUTH</span><span class="z-keyword"> *</span><span> num_authorizations</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>The gas used calculation becomes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> isContractCreation</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">32000</span><span class="z-keyword"> +</span><span class="z-constant"> INITCODE_WORD_COST</span><span class="z-keyword"> *</span><span> words</span><span>(</span><span>calldata</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> access_list_cost</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> PER_EMPTY_ACCOUNT_COST</span><span class="z-keyword"> *</span><span> num_authorizations</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> FLOOR_COST_PER_AUTH</span><span class="z-keyword"> *</span><span> num_authorizations</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Any transaction with a gas limit below <code>floor_gas</code> or below its intrinsic gas cost is considered invalid.</p> <h2 id="rationale">Rationale</h2> <h3 id="flat-cost-per-authorization">Flat Cost Per Authorization</h3> <p>Each authorization is charged a flat <code>FLOOR_COST_PER_AUTH = 4040</code> gas toward the floor, derived from:</p> <ul> <li>101 bytes per authorization tuple (as specified in <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>)</li> <li>4 tokens per byte (treating all bytes as non-zero)</li> <li>10 gas per token (<code>TOTAL_COST_FLOOR_PER_TOKEN</code>)</li> </ul> <p>This conservative approach avoids byte-level zero/non-zero accounting while ensuring authorization data is properly reflected in the floor calculation.</p> <h3 id="floor-only-modification">Floor-Only Modification</h3> <p>Authorization costs are added to the floor calculation only, not to intrinsic gas. This differs from <a href="https://wg-eips.ritovision.com/7981/">EIP-7981</a> (access lists) because:</p> <ul> <li>Authorization execution cost (25,000 gas) far exceeds floor contribution (4,040 gas per auth)</li> <li>Floor-only modification is sufficient to prevent bypass</li> </ul> <p>With this change:</p> <ul> <li>Authorization data contributes to the floor path</li> <li>High-execution transactions remain unaffected (execution exceeds floor)</li> <li>Data-heavy transactions cannot use authorizations to bypass floor pricing</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Requires updates to gas estimation in wallets and nodes. Normal usage patterns remain largely unaffected since authorization execution cost typically dominates the floor contribution.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="case-1-transaction-with-authorizations-only">Case 1: Transaction with Authorizations Only</h3> <ul> <li>Calldata: 0 bytes</li> <li>Authorizations: 10</li> </ul> <p>Old floor: 21,000 gas New floor: 21,000 + 10 × 4,040 = 61,400 gas Execution: 10 × 25,000 = 250,000 gas Result: Pay execution (250,000) - unchanged, execution dominates</p> <h3 id="case-2-bypass-attempt-now-blocked">Case 2: Bypass Attempt (Now Blocked)</h3> <ul> <li>Calldata: 100,000 bytes (400,000 tokens)</li> <li>Authorizations: 100</li> </ul> <p>Old floor: 21,000 + 400,000 × 10 = 4,021,000 gas New floor: 21,000 + 400,000 × 10 + 100 × 4,040 = 4,425,000 gas Execution: 21,000 + 1,600,000 + 2,500,000 = 4,121,000 gas Result: Pay new floor (4,425,000) - bypass blocked</p> <h2 id="reference-implementation">Reference Implementation</h2> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">FLOOR_COST_PER_AUTH</span><span class="z-keyword"> =</span><span class="z-constant"> 4040</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 101 bytes * 4 tokens/byte * 10 gas/token</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_intrinsic_cost</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>Uint</span><span>,</span><span> Uint</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Calculate intrinsic gas cost and floor gas cost.</span></span> <span class="giallo-l"><span class="z-string"> Returns (intrinsic_gas, floor_gas).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calldata tokens</span></span> <span class="giallo-l"><span> calldata_zero</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span class="z-constant">1</span><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span> tx</span><span>.</span><span>data</span><span class="z-keyword"> if</span><span> b</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> tokens_in_calldata</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span>calldata_zero</span><span class="z-keyword"> +</span><span> (</span><span class="z-support">len</span><span>(</span><span>tx</span><span>.</span><span>data</span><span>)</span><span class="z-keyword"> -</span><span> calldata_zero</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Authorization costs</span></span> <span class="giallo-l"><span> num_authorizations</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> auth_exec_cost</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> isinstance</span><span>(</span><span>tx</span><span>,</span><span> SetCodeTransaction</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> num_authorizations</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-support">len</span><span>(</span><span>tx</span><span>.</span><span>authorizations</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> auth_exec_cost</span><span class="z-keyword"> =</span><span class="z-constant"> PER_EMPTY_ACCOUNT_COST</span><span class="z-keyword"> *</span><span> num_authorizations</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Floor: calldata + flat cost per authorization</span></span> <span class="giallo-l"><span> floor_gas</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> TX_BASE_COST</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> tokens_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> num_authorizations</span><span class="z-keyword"> *</span><span class="z-constant"> FLOOR_COST_PER_AUTH</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Intrinsic: calldata + authorization execution cost</span></span> <span class="giallo-l"><span> calldata_cost</span><span class="z-keyword"> =</span><span> tokens_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> STANDARD_TOKEN_COST</span></span> <span class="giallo-l"><span> intrinsic_gas</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-keyword"> +</span><span> calldata_cost</span><span class="z-keyword"> +</span><span> access_list_cost</span><span class="z-keyword"> +</span><span> auth_exec_cost</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> intrinsic_gas</span><span>,</span><span> floor_gas</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>This EIP closes a loophole that allows circumventing <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor pricing. Without this fix, adversaries can achieve ~9% larger blocks by combining calldata with authorization data.</p> <h3 id="interaction-with-eip-7981">Interaction with EIP-7981</h3> <p>If <a href="https://wg-eips.ritovision.com/7981/">EIP-7981</a> is also adopted, both EIPs work together: access list tokens and authorization tokens are both included in the floor calculation. There are no conflicts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-01-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Guillaume Ballethttps://github.com/gballet Dankrad Feisthttps://github.com/dankrad Ignacio Hagopianhttps://github.com/jsign Kevaundray Wedderburnhttps://github.com/kevaundray Tanishq Jasoriahttps://github.com/tanishqjasoria Gajinder Singhhttps://github.com/g11tech Danno Ferrinhttps://github.com/shemnon Piper Merriamhttps://github.com/pipermerriam Gottfried Heroldhttps://github.com/GottfriedHerold https://wg-eips.ritovision.com/7864/

Switch Ethereum state tree to a unified binary tree

<h2 id="abstract">Abstract</h2> <p>Introduce a new binary state tree, intended to replace the hexary patricia trees. Account and storage tries are merged into a single tree with 32-byte keys, which also contains contracts code. Account data is broken into independent leaves which are grouped by 256 in order to provide some locality.</p> <p>Note: The hash function used in the current draft is not final. The current implementation uses BLAKE3 to reduce friction for EL clients experimenting with this EIP, but the final decision remains TBD. Other potential candidates include Keccak and Poseidon2.</p> <p>For Poseidon2, there's an ongoing Ethereum Foundation cryptography initiative assessing its security properties. If Poseidon2 is selected, additional specifications will be needed for field selection (BN254 scalar field, 31-bit field elements, etc.) and encoding 32-byte values into field elements.</p> <p>The hash function can be switched with minimal impact on implementations as this EIP progresses toward acceptance. <strong>Do not</strong> assume BLAKE3 is a final decision.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum's long-term goal is to allow blocks to be proved with validity proof so that chain verification is as simple and fast as possible. One of the most challenging parts of achieving that goal is proving the state of the tree, which is required for EVM execution.</p> <p>The current Merkle-Patricia Trie (MPT) design isn't friendly to validity proofs for many reasons, such as using RLP for node encoding, Keccak as a hashing function, being a "tree of trees", and not including accounts code as part of the state.</p> <p>Apart from requiring a state tree design that is friendly for block validity proofs, it's also important to have fast and small regular Merkle proofs when the amount of state to prove is small. This is useful not only for the application layer but also for supporting future protocol needs in a stateless world (e.g: inclusion lists).</p> <p>Regarding these regular Merkle proofs in an MPT, since it's a hexary tree, their size is quite big on average and in worst-case scenarios. Given a 2^32 size tree, the expected size for proving a single branch is <code>15 * 32 * log_16(2^32) = 3840</code>. From a worst-case block perspective, if 30M gas is used to access only a single byte of different account codes since this code isn't chunkified, we'd need <code>30M/2400*(5*480+24k)=330MB</code>.</p> <p>A binary tree has a good balance between out-of-circuit and in-circuit proving. Since the tree arity is two, this reduces the size of regular Merkle proofs (i.e., <code># siblings * log_arity(N)</code> for arity 2 is better than for arity 16). Moreover, we propose switching from Keccak to a more proving-friendly hash function, which would be more amenable to modern proving systems.</p> <h2 id="specification">Specification</h2> <p>The keywords "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 and RFC 8174.</p> <h3 id="notable-changes-from-the-hexary-structure">Notable changes from the hexary structure</h3> <ul> <li>The account and storage tries are merged into a single trie.</li> <li>RLP is no longer used.</li> <li>The account's code is chunked and included in the tree.</li> <li>Account data (e.g., balance, nonce, first storage slots, first code-chunks) is co-located in the tree to reduce branch openings.</li> </ul> <h3 id="tree-structure">Tree structure</h3> <p>The proposed Binary Tree stores key-value entries where both the key and value are 32 bytes. The first 31-bytes of the key define the entry stem, and the last byte is the subindex in that stem. If two keys have the same stem, they live in the same "big branch" — this co-locates groups of 256 keys (i.e: keys with the same first 31-bytes).</p> <p><img src="https://wg-eips.ritovision.com/7864/./assets/diagram2.png" alt="Image" /> (More details about the purple/orange part in the "Tree embedding" section)</p> <p>We can distinguish four node types:</p> <ul> <li><code>InternalNode</code> has a <code>left_hash</code> and <code>right_hash</code> field (black).</li> <li><code>StemNode</code> has fields <code>stem</code>, <code>left_hash</code> and <code>right_hash</code> (blue).</li> <li><code>LeafNode</code> has a field <code>value</code> which is a 32-byte blob or <code>empty</code>. (orange).</li> <li><code>EmptyNode</code> represents an empty node/sub-tree.</li> </ul> <p>The path to a <code>StemNode</code> is defined by the key's first 248-bits (31-bytes) from MSB to LSB. From this node, a subtree of 256 values exists indexed by the key's last byte (8 bits). A newly created <code>StemNode</code> subtree (i.e: 256 values) has all leaves with <code>value: empty</code>.</p> <p>The path length isn't 248-bits, but contains the minimal amount of <code>InternalNodes</code> required if other stems exist with the same prefix. As in, when walking the 248-bit path inserting a new <code>StemNode</code>, you can end on a <code>EmptyNode</code> or <code>StemNode</code>. In the former, you replace it with the new <code>StemNode</code>. In the latter, you create as many <code>InternalNodes</code> as common bits both stems have as prefixes. Another way to look at this is that there aren't <em>extension nodes</em> in paths, but we use the minimal amount of <code>InternalNodes</code> to place <code>StemNode</code>s with common prefixes.</p> <p>Below is an implementation that describes the tree structure:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> StemNode</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-support"> __init__</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> stem</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>stem</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 31</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">stem must be 31 bytes</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>stem</span><span class="z-keyword"> =</span><span> stem</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>values</span><span>:</span><span> list</span><span>[</span><span>Optional</span><span>[</span><span class="z-support">bytes</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">None</span><span>]</span><span class="z-keyword"> *</span><span class="z-constant"> 256</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> set_value</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> index</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>values</span><span>[</span><span>index</span><span>]</span><span class="z-keyword"> =</span><span> value</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> InternalNode</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-support"> __init__</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>left</span><span class="z-keyword"> =</span><span class="z-constant"> None</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>right</span><span class="z-keyword"> =</span><span class="z-constant"> None</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BinaryTree</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-support"> __init__</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>root</span><span class="z-keyword"> =</span><span class="z-constant"> None</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> insert</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>key</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">key must be 32 bytes</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>value</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">value must be 32 bytes</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> stem</span><span class="z-keyword"> =</span><span> key</span><span>[</span><span>:</span><span class="z-constant">31</span><span>]</span></span> <span class="giallo-l"><span> subindex</span><span class="z-keyword"> =</span><span> key</span><span>[</span><span class="z-constant">31</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-variable z-language"> self</span><span>.</span><span>root</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>root</span><span class="z-keyword"> =</span><span> StemNode</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>root</span><span>.</span><span>set_value</span><span>(</span><span>subindex</span><span>,</span><span> value</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>root</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_insert</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span>root</span><span>,</span><span> stem</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> _insert</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> node</span><span>,</span><span class="z-variable z-parameter z-function"> stem</span><span>,</span><span class="z-variable z-parameter z-function"> subindex</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>,</span><span class="z-variable z-parameter z-function"> depth</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> depth</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 248</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">depth must be less than 248</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> node</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> node</span><span class="z-keyword"> =</span><span> StemNode</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span> node</span><span>.</span><span>set_value</span><span>(</span><span>subindex</span><span>,</span><span> value</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> node</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> stem_bits</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_bytes_to_bits</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> isinstance</span><span>(</span><span>node</span><span>,</span><span> StemNode</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the stem already exists, update the value.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> node</span><span>.</span><span>stem</span><span class="z-keyword"> ==</span><span> stem</span><span>:</span></span> <span class="giallo-l"><span> node</span><span>.</span><span>set_value</span><span>(</span><span>subindex</span><span>,</span><span> value</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> node</span></span> <span class="giallo-l"><span> existing_stem_bits</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_bytes_to_bits</span><span>(</span><span>node</span><span>.</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> self</span><span>.</span><span>_split_leaf</span><span>(</span></span> <span class="giallo-l"><span> node</span><span>,</span><span> stem_bits</span><span>,</span><span> existing_stem_bits</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span> depth</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> We&#39;re in an internal node, go left or right based on the bit.</span></span> <span class="giallo-l"><span> bit</span><span class="z-keyword"> =</span><span> stem_bits</span><span>[</span><span>depth</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> node</span><span>.</span><span>left</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_insert</span><span>(</span><span>node</span><span>.</span><span>left</span><span>,</span><span> stem</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span> depth</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> node</span><span>.</span><span>right</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_insert</span><span>(</span><span>node</span><span>.</span><span>right</span><span>,</span><span> stem</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span> depth</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> node</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> _split_leaf</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> leaf</span><span>,</span><span class="z-variable z-parameter z-function"> stem_bits</span><span>,</span><span class="z-variable z-parameter z-function"> existing_stem_bits</span><span>,</span><span class="z-variable z-parameter z-function"> subindex</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>,</span><span class="z-variable z-parameter z-function"> depth</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the stem bits are the same up to this depth, we need to create another</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> internal node and recurse.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> stem_bits</span><span>[</span><span>depth</span><span>]</span><span class="z-keyword"> ==</span><span> existing_stem_bits</span><span>[</span><span>depth</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span class="z-keyword"> =</span><span> InternalNode</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> bit</span><span class="z-keyword"> =</span><span> stem_bits</span><span>[</span><span>depth</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>left</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_split_leaf</span><span>(</span></span> <span class="giallo-l"><span> leaf</span><span>,</span><span> stem_bits</span><span>,</span><span> existing_stem_bits</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span> depth</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>right</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_split_leaf</span><span>(</span></span> <span class="giallo-l"><span> leaf</span><span>,</span><span> stem_bits</span><span>,</span><span> existing_stem_bits</span><span>,</span><span> subindex</span><span>,</span><span> value</span><span>,</span><span> depth</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> new_internal</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span class="z-keyword"> =</span><span> InternalNode</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> bit</span><span class="z-keyword"> =</span><span> stem_bits</span><span>[</span><span>depth</span><span>]</span></span> <span class="giallo-l"><span> stem</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>_bits_to_bytes</span><span>(</span><span>stem_bits</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>left</span><span class="z-keyword"> =</span><span> StemNode</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>left</span><span>.</span><span>set_value</span><span>(</span><span>subindex</span><span>,</span><span> value</span><span>)</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>right</span><span class="z-keyword"> =</span><span> leaf</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>right</span><span class="z-keyword"> =</span><span> StemNode</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>right</span><span>.</span><span>set_value</span><span>(</span><span>subindex</span><span>,</span><span> value</span><span>)</span></span> <span class="giallo-l"><span> new_internal</span><span>.</span><span>left</span><span class="z-keyword"> =</span><span> leaf</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> new_internal</span></span></code></pre><h3 id="node-merkelization">Node merkelization</h3> <p>Define <code>hash(value)</code> as:</p> <ul> <li><code>hash([0x00] * 64) = [0x00] * 32</code></li> <li><code>hash(value) = H(value)</code>, where H is the selected cryptographic hash function.</li> </ul> <p>The <code>value</code> parameter lengths can only be 32 and 64.</p> <p>Merkelize each node type as follows:</p> <ul> <li><code>internal_node_hash = hash(left_hash || right_hash)</code></li> <li><code>stem_node_hash = hash(stem || 0x00 || hash(left_hash || right_hash))</code></li> <li><code>leaf_node_hash = hash(value)</code></li> <li><code>empty_node_hash = [0x00] * 32</code></li> </ul> <p>Below is an implementation of these rules using BLAKE3 as a reference implementation:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> _hash</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> data</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> data</span><span class="z-keyword"> in</span><span> (</span><span class="z-constant">None</span><span>,</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> *</span><span class="z-constant"> 64</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> *</span><span class="z-constant"> 32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 64</span><span class="z-keyword"> or</span><span class="z-support"> len</span><span>(</span><span>data</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">data must be 32 or 64 bytes</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> blake3</span><span>(</span><span>data</span><span>)</span><span>.</span><span>digest</span><span>(</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This will be replaced with the final hash function</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> merkelize</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> _merkelize</span><span>(</span><span class="z-variable z-parameter z-function">node</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> node</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> *</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> isinstance</span><span>(</span><span>node</span><span>,</span><span> InternalNode</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> left_hash</span><span class="z-keyword"> =</span><span> _merkelize</span><span>(</span><span>node</span><span>.</span><span>left</span><span>)</span></span> <span class="giallo-l"><span> right_hash</span><span class="z-keyword"> =</span><span> _merkelize</span><span>(</span><span>node</span><span>.</span><span>right</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> self</span><span>.</span><span>_hash</span><span>(</span><span>left_hash</span><span class="z-keyword"> +</span><span> right_hash</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> level</span><span class="z-keyword"> =</span><span> [</span><span class="z-variable z-language">self</span><span>.</span><span>_hash</span><span>(</span><span>x</span><span>)</span><span class="z-keyword"> for</span><span> x</span><span class="z-keyword"> in</span><span> node</span><span>.</span><span>values</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span class="z-support"> len</span><span>(</span><span>level</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span> new_level</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-support"> len</span><span>(</span><span>level</span><span>)</span><span>,</span><span class="z-constant"> 2</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> new_level</span><span>.</span><span>append</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span>_hash</span><span>(</span><span>level</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> +</span><span> level</span><span>[</span><span>i</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> level</span><span class="z-keyword"> =</span><span> new_level</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> self</span><span>.</span><span>_hash</span><span>(</span><span>node</span><span>.</span><span>stem</span><span class="z-keyword"> +</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\0</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> +</span><span> level</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> _merkelize</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span>root</span><span>)</span></span></code></pre><h3 id="tree-embedding">Tree embedding</h3> <p>Instead of a two-layer structure like the MPT, we will embed all information into a unique <code>key: value</code> space in the proposed single tree. This section specifies which tree keys store the state's information (account header data, code, storage). The data is colocated in such way that data that is usually accessed together lives in the same <code>StemNode</code> which reduces branch openings.</p> <p>The following is a big picture of what we'll continue to describe in the rest of this section:</p> <p><img src="https://wg-eips.ritovision.com/7864/./assets/diagram1.png" alt="Image" /></p> <p>The account stem (green <code>account</code> node) contains accounts basic data, first 64-storage slots, and first 128-code chunks. This co-location of data allows having data in a single stem branch that is usually accessed together. The rest of storage slots and code-chunks are spread into groups of 256 values in the rest of the tree -- this is also done for convenience since slots/code-chunks that are close together will share the same stem branch.</p> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td>BASIC_DATA_LEAF_KEY</td><td>0</td></tr> <tr><td>CODE_HASH_LEAF_KEY</td><td>1</td></tr> <tr><td>HEADER_STORAGE_OFFSET</td><td>64</td></tr> <tr><td>CODE_OFFSET</td><td>128</td></tr> <tr><td>STEM_SUBTREE_WIDTH</td><td>256</td></tr> <tr><td>MAIN_STORAGE_OFFSET</td><td>256**31</td></tr> </tbody></table> <p><em>It's a required invariant that <code>STEM_SUBTREE_WIDTH &gt; CODE_OFFSET &gt; HEADER_STORAGE_OFFSET</code> and that <code>HEADER_STORAGE_OFFSET</code> is greater than the leaf keys. Additionally, <code>MAIN_STORAGE_OFFSET</code> MUST be a power of <code>STEM_SUBTREE_WIDTH</code>.</em></p> <p>Note that addresses are always passed around as an <code>Address32</code>. To convert existing addresses to <code>Address32</code>, prepend with 12 zero bytes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> old_style_address_to_address32</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address</span><span>)</span><span> -&gt;</span><span> Address32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\\</span><span class="z-string">x00</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-keyword"> *</span><span class="z-constant"> 12</span><span class="z-keyword"> +</span><span> address</span></span></code></pre><h3 id="header-values">Header values</h3> <p>These are the positions in the tree at which header fields of an account are stored.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> tree_hash</span><span>(</span><span class="z-variable z-parameter z-function">inp</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> bytes32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> bytes32</span><span>(</span><span>blake3</span><span>.</span><span>blake3</span><span>(</span><span>inp</span><span>)</span><span>.</span><span>digest</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_tree_key</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address32</span><span>,</span><span class="z-variable z-parameter z-function"> tree_index</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> sub_index</span><span>:</span><span class="z-support"> int</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Assumes STEM_SUBTREE_WIDTH = 256</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tree_hash</span><span>(</span><span>address</span><span class="z-keyword"> +</span><span> tree_index</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">32</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>)</span><span>[</span><span>:</span><span class="z-constant">31</span><span>]</span><span class="z-keyword"> +</span><span class="z-support"> bytes</span><span>(</span></span> <span class="giallo-l"><span> [</span><span>sub_index</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_tree_key_for_basic_data</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address32</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> get_tree_key</span><span>(</span><span>address</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> BASIC_DATA_LEAF_KEY</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_tree_key_for_code_hash</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address32</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> get_tree_key</span><span>(</span><span>address</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> CODE_HASH_LEAF_KEY</span><span>)</span></span></code></pre> <p>An account's <code>version</code>, <code>balance</code>, <code>nonce</code>, and <code>code_size</code> fields are packed with big-endian encoding in the value found at <code>BASIC_DATA_LEAF_KEY</code>:</p> <table><thead><tr><th>Name</th><th>Offset</th><th>Size</th></tr></thead><tbody> <tr><td><code>version</code></td><td>0</td><td>1</td></tr> <tr><td><code>code_size</code></td><td>5</td><td>3</td></tr> <tr><td><code>nonce</code></td><td>8</td><td>8</td></tr> <tr><td><code>balance</code></td><td>16</td><td>16</td></tr> </tbody></table> <p>Bytes <code>1..4</code> are reserved for future use.</p> <p>The current layout and encoding allow for an extension of <code>code_size</code> to 4 bytes without changing the account version. The goal of packing these fields together in a basic-data leaf is to reduce gas costs, since we only need one branch opening compared with the usual 3 or 4 if the fields aren't packed. This also simplifies witness generation.</p> <p>When any account header field is set, the <code>version</code> field is also set to zero. The <code>codehash</code> and <code>code_size</code> fields are set upon contract or EOA creation.</p> <h3 id="code">Code</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_tree_key_for_code_chunk</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address32</span><span>,</span><span class="z-variable z-parameter z-function"> chunk_id</span><span>:</span><span class="z-support"> int</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> get_tree_key</span><span>(</span></span> <span class="giallo-l"><span> address</span><span>,</span></span> <span class="giallo-l"><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> +</span><span> chunk_id</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> STEM_SUBTREE_WIDTH</span><span>,</span></span> <span class="giallo-l"><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> +</span><span> chunk_id</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> STEM_SUBTREE_WIDTH</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>Chunk <code>i</code> stores a 32 byte value, where bytes 1…31 are bytes <code>i*31...(i+1)*31 - 1</code> of the code (i.e. the i'th 31-byte slice of it), and byte 0 is the number of leading bytes that are part of PUSHDATA (e.g. if part of the code is <code>...PUSH4 99 98 | 97 96 PUSH1 128 MSTORE...</code> where <code>|</code> is the position where a new chunk begins, then the encoding of the latter chunk would begin <code>2 97 96 PUSH1 128 MSTORE</code> to reflect that the first 2 bytes are PUSHDATA).</p> <p>For precision, here is an implementation of code chunkification:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">PUSH_OFFSET</span><span class="z-keyword"> =</span><span class="z-constant"> 95</span></span> <span class="giallo-l"><span class="z-constant">PUSH1</span><span class="z-keyword"> =</span><span class="z-constant"> PUSH_OFFSET</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-constant">PUSH32</span><span class="z-keyword"> =</span><span class="z-constant"> PUSH_OFFSET</span><span class="z-keyword"> +</span><span class="z-constant"> 32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> chunkify_code</span><span>(</span><span class="z-variable z-parameter z-function">code</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> Sequence</span><span>[</span><span>bytes32</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pad to multiple of 31 bytes</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> 31</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> code</span><span class="z-keyword"> +=</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\\</span><span class="z-string">x00</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">31</span><span class="z-keyword"> -</span><span> (</span><span class="z-support">len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> 31</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Figure out how much pushdata there is after including each byte</span></span> <span class="giallo-l"><span> bytes_to_exec_data</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> *</span><span> (</span><span class="z-support">len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 32</span><span>)</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> pos</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> PUSH1</span><span class="z-keyword"> &lt;=</span><span> code</span><span>[</span><span>pos</span><span>]</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> PUSH32</span><span>:</span></span> <span class="giallo-l"><span> pushdata_bytes</span><span class="z-keyword"> =</span><span> code</span><span>[</span><span>pos</span><span>]</span><span class="z-keyword"> -</span><span class="z-constant"> PUSH_OFFSET</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> pushdata_bytes</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> x</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>pushdata_bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> bytes_to_exec_data</span><span>[</span><span>pos</span><span class="z-keyword"> +</span><span> x</span><span>]</span><span class="z-keyword"> =</span><span> pushdata_bytes</span><span class="z-keyword"> -</span><span> x</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span> pushdata_bytes</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Output chunks</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> [</span></span> <span class="giallo-l"><span class="z-support"> bytes</span><span>(</span><span>[</span><span class="z-support">min</span><span>(</span><span>bytes_to_exec_data</span><span>[</span><span>pos</span><span>]</span><span>,</span><span class="z-constant"> 31</span><span>)</span><span>]</span><span>)</span><span class="z-keyword"> +</span><span> code</span><span>[</span><span>pos</span><span>:</span><span> pos</span><span class="z-keyword">+</span><span class="z-constant">31</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> pos</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>,</span><span class="z-constant"> 31</span><span>)</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"></span></code></pre><h3 id="storage">Storage</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_tree_key_for_storage_slot</span><span>(</span><span class="z-variable z-parameter z-function">address</span><span>:</span><span> Address32</span><span>,</span><span class="z-variable z-parameter z-function"> storage_key</span><span>:</span><span class="z-support"> int</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> storage_key</span><span class="z-keyword"> &lt;</span><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> -</span><span class="z-constant"> HEADER_STORAGE_OFFSET</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> HEADER_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> storage_key</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> MAIN_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> storage_key</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> get_tree_key</span><span>(</span></span> <span class="giallo-l"><span> address</span><span>,</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> //</span><span class="z-constant"> STEM_SUBTREE_WIDTH</span><span>,</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> %</span><span class="z-constant"> STEM_SUBTREE_WIDTH</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>Note that storage slots within the same range of size <code>STEM_SUBTREE_WIDTH</code> (i.e. a range with the form <code>x*STEM_SUBTREE_WIDTH ... (x+1)*STEM_SUBTREE_WIDTH-1)</code> are all, except for the <code>HEADER_STORAGE_OFFSET</code> special case, part of a single stem.</p> <h3 id="fork">Fork</h3> <p>Described in <a href="https://wg-eips.ritovision.com/7612/">EIP-7612</a>.</p> <h3 id="access-events">Access events</h3> <p>Described in <a href="https://wg-eips.ritovision.com/4762/">EIP-4762</a>.</p> <h2 id="rationale">Rationale</h2> <p>This EIP defines a new Binary Tree that starts empty. Only new state changes are stored in the tree. The MPT continues to exist but is frozen. This sets the stage for a future hard fork that migrates the MPT data to this Binary Tree (<a href="https://wg-eips.ritovision.com/7748/">EIP-7748</a>).</p> <h3 id="single-tree-design">Single tree design</h3> <p>The proposal uses a single-layer tree structure with 32-byte keys and values for several reasons:</p> <ul> <li><strong>Simplicity</strong>: working with the abstraction of a key/value store makes it easier to write code dealing with the tree (e.g. database reading/writing, caching, syncing, proof creation, and verification) and upgrade it to other trees in the future. Additionally, witness gas rules can become simpler and clearer.</li> <li><strong>Uniformity</strong>: the state is uniformly spread throughout the tree; even if a single contract has millions of storage slots, the contract's storage slots are not concentrated in one place. This is useful for state-syncing algorithms. Additionally, it helps reduce the effectiveness of unbalanced tree-filling attacks.</li> <li><strong>Extensibility</strong>: account headers and code being in the same structure as storage makes it easier to extend both features and even add new structures if desired.</li> </ul> <h3 id="snark-friendliness-and-post-quantum-security">SNARK friendliness and Post-Quantum security</h3> <p>The proposed design should consider the usual complexity, performance, and efficiency for out-of-circuit implementations (i.e. EL clients) and in-circuit ones for generating proofs in ZK circuits.</p> <p>The tree design structure tries to be simple, by not having complex branching rules. For example, in contrast with the MPT, we avoid extension nodes injected in the middle of branches. Also, RLP encoding was removed since it adds unnecessary complexity. Although complexity can be managed more easily in out-of-circuit implementations, it's valuable to help circuit implementations be as simple as possible to avoid proving overhead.</p> <p>The most important factor in the design is the cryptographic hash function used for merkleization. This hash function should have efficient implementations both out and in circuits. The hash function selection remains TBD, with several candidates under consideration:</p> <ol> <li> <p><strong>BLAKE3</strong>:</p> <ul> <li>Good out-of-circuit performance (i.e., for raw EL client execution)</li> <li>Reasonable in-circuit performance for proving</li> <li>Well-established security properties</li> <li>Currently used in the reference implementation to facilitate experimentation</li> </ul> </li> <li> <p><strong>Keccak</strong>:</p> <ul> <li>Already used in Ethereum, reducing implementation complexity</li> <li>Well-studied security properties</li> <li>Less efficient for circuit proving than alternatives</li> </ul> </li> <li> <p><strong>Poseidon2</strong>:</p> <ul> <li>Excellent in-circuit performance for ZK proofs</li> <li>Potentially better proving throughput</li> <li>Security analysis still ongoing through EF cryptography initiative</li> <li>Would require additional specification for field selection and encoding</li> </ul> </li> </ol> <p>The final hash function selection will balance these considerations, with particular attention to security, proving efficiency, and implementation complexity.</p> <p>Due to recent progress in the quantum computing field, expert estimations consider that they can become real in the 2030s. NIST suggests stopping the use of ECC by 2030 too. Other alternatives, such as Verkle Trees, introduce a new cryptography stack to the protocol, which relies on elliptic curves that aren't post-quantum secure. This makes the current tree proposal attractive since it only depends on hash functions, which are still safe in this new paradigm.</p> <p>Moreover, there has been impressive progress in proving systems, which indicates that we could be close to achieving the required performance for creating pre-state &amp; post-state proofs fast enough. This last point is crucial since the main advantage of Verkle Trees was having proofs that are small and fast to generate.</p> <p>Finally, the current state tree proposal will probably be the final state tree used in the protocol, compared with Verkle Trees, which would eventually need to be replaced by a post-quantum secure alternative.</p> <h3 id="arity-2">Arity-2</h3> <p>Binary tries have been chosen primarily because they reduce the witness size. In general, in an <code>N</code>-element tree with each element having <code>k</code> children, the average size of a branch is roughly <code>32 * (k-1) * log(N) / log(k)</code> plus a few percent for overhead. 32 is the length of a hash; the <code>k-1</code> refers to the fact that a Merkle proof needs to provide all <code>k-1</code> sister nodes at each level, and <code>log(N) / log(k)</code> is an approximation of the number of levels in the tree (e.g. a tree where each node has 5 children, with 625 nodes total, would have depth 4, as <code>625 = 5**4</code> and so <code>log(625) / log(5) = 4</code>).</p> <p>For any <code>N</code>, the expression is minimized at <code>k = 2</code>. Here's a table of branch lengths for different <code>k</code> values assuming <code>N = 2**24</code>:</p> <table><thead><tr><th><code>k</code> (children per node)</th><th>Branch length (chunks)</th><th>Branch length (bytes)</th></tr></thead><tbody> <tr><td>2</td><td>1 * 24 = 24</td><td>768</td></tr> <tr><td>4</td><td>3 * 12 = 36</td><td>1152</td></tr> <tr><td>8</td><td>7 * 8 = 56</td><td>1792</td></tr> <tr><td>16</td><td>15 * 6 = 90</td><td>2880</td></tr> </tbody></table> <p>Actual branch lengths might be slightly larger than this due to uneven distribution, but the pattern of <code>k=2</code> remains by far the best.</p> <h3 id="tree-depth">Tree depth</h3> <p>The tree design attempts to be as simple as possible considering both out-of-circuit and circuit implementations, while satisfying our throughput constraints on proving hashes.</p> <p>The proposed design avoids a full 248-bit depth as it would happen in a Sparse Merkle Tree (SMT). This approach helps reduce the hashing load in proving systems, which is currently a throughput bottleneck on commodity hardware. The choice of hash function will impact this consideration - arithmetic-friendly hash functions like Poseidon2 would have different performance characteristics than cryptographic hash functions like BLAKE3 or Keccak. There are some optimization techniques that could be applied, but they add complexity to the specification.</p> <p>Moreover, we could push this further trying to introduce extension nodes in the middle of paths as done in a MPT, but this also adds complexity that might not be worth it considering the tree should be quite balanced.</p> <h3 id="state-expiry">State-expiry</h3> <p>State-expiry strategies such as <a href="https://wg-eips.ritovision.com/7736/">EIP-7736</a> could still be applied, requiring a change in the design. One potential solution is adding a field to the <code>StemNode</code> with <code>epoch</code> as described in the mentioned EIP. Another alternative is to use 247-bits for the stem, and have two subtrees <code>StemValuesNode</code>, which would correspond to the current 256-values, and <code>StemMetaNode</code> which is also a 256-subtree that can be used to store arbitrary stem metadata.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The main breaking changes are:</p> <ul> <li>(1) Gas costs for code chunk access can have an impact on applications' economic viability</li> <li>(2) Tree structure change makes in-EVM proofs of historical state no longer work</li> </ul> <p>(1) can be mitigated by increasing the gas limit while implementing this EIP, allowing the same economic viability for applications.</p> <!-- TODO: ## Test Cases - Add comprehensive test vectors for tree operations - Finalize hash function selection and provide test vectors for the selected function - Add test cases for edge cases in tree operations --> <!-- TODO: Remove external link ## Reference Implementation Python reference implementation (`github.com/jsign/binary-tree-spec`). --> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion. <!-- TODO --></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2025-01-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Toni Wahrstätterhttps://github.com/nerolation Jochem Brouwerhttps://github.com/jochem-brouwer Alex Stokeshttps://github.com/ralexstokes Ansgar Dietrichshttps://github.com/adietrichs Yoav Weisshttps://github.com/yoavw Alex Forshtathttps://github.com/forshtat https://wg-eips.ritovision.com/7863/

Warm addresses and storage keys over the duration of a block

<h2 id="abstract">Abstract</h2> <p>This proposal introduces block-level address and storage key warming, allowing accessed addresses and storage keys to maintain their "warm" status throughout an entire block's execution. Accessed slots can be effectively cached at the block level, allowing for this optimization.</p> <h2 id="motivation">Motivation</h2> <p>Currently, the EVM's storage slot warming mechanism operates at the transaction level, requiring each transaction to "warm up" slots independently, even when accessing the same storage locations within the same block. This design does not take advantage of the fact that modern node implementations can effectively cache storage access patterns at the block level. By extending the slot warming duration to the block level, we can:</p> <ol> <li>Reduce redundant warming costs for frequently accessed slots</li> <li>Better align gas costs with actual computational overhead</li> <li>Improve overall network throughput without compromising security.</li> </ol> <p>As of Jan. 2025, the empirically measured efficiency gains are around 5%.</p> <h2 id="specification">Specification</h2> <h3 id="mechanics">Mechanics</h3> <p>When a storage slot is accessed within a block:</p> <ol> <li>The first access to a slot in a block incurs the cold access cost as of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</li> <li>All subsequent accesses to the same slot within the same block incur only the warm access cost as of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</li> <li>The warm/cold status resets at block boundaries</li> </ol> <h3 id="block-processing">Block Processing</h3> <ol> <li>At the start of each block: <ul> <li>Initialize two empty sets <code>block_level_accessed_addresses</code> and <code>block_level_accessed_storage_keys</code></li> </ul> </li> <li>For each transaction in the block: <ul> <li>Before processing storage access: <ul> <li>Check if touched address is in <code>block_level_accessed_addresses</code></li> <li>If yes: charge <code>WARM_STORAGE_READ_COST</code></li> <li>If no: <ul> <li>Charge <code>COLD_ACCOUNT_ACCESS_COST</code></li> <li>Add address to <code>block_level_accessed_addresses</code></li> </ul> </li> <li>Check if storage key is in <code>block_level_accessed_storage_keys</code></li> <li>If yes: charge <code>WARM_STORAGE_READ_COST</code></li> <li>If no: <ul> <li>Charge <code>COLD_SLOAD_COST</code></li> <li>Add storage key to <code>block_level_accessed_storage_keys</code></li> </ul> </li> </ul> </li> </ul> </li> </ol> <h3 id="implementation-details">Implementation Details</h3> <p>The implementation modifies the block execution process to maintain block-level sets of accessed addresses and storage slots.</p> <h4 id="block-level-storage-management">Block-Level Storage Management</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> apply_body</span><span>(</span><span>...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initialize block-level tracking sets</span></span> <span class="giallo-l"><span> block_level_accessed_addresses</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> block_level_accessed_storage_keys</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span class="z-support">map</span><span>(</span><span>decode_transaction</span><span>,</span><span> transactions</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Create environment with block-level context</span></span> <span class="giallo-l"><span> env</span><span class="z-keyword"> =</span><span> vm</span><span>.</span><span>Environment</span><span>(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ... other parameters ...</span></span> <span class="giallo-l"><span class="z-variable"> block_level_accessed_addresses</span><span class="z-keyword">=</span><span>block_level_accessed_addresses</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> block_level_accessed_storage_keys</span><span class="z-keyword">=</span><span>block_level_accessed_storage_keys</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process transaction and update block-level sets</span></span> <span class="giallo-l"><span> gas_used</span><span>,</span><span> accessed_addresses</span><span>,</span><span> accessed_storage_keys</span><span>,</span><span> logs</span><span>,</span><span> error</span><span class="z-keyword"> =</span><span> process_transaction</span><span>(</span><span>env</span><span>,</span><span> tx</span><span>)</span></span> <span class="giallo-l"><span> block_level_accessed_addresses</span><span class="z-keyword"> +=</span><span> accessed_addresses</span></span> <span class="giallo-l"><span> block_level_accessed_storage_keys</span><span class="z-keyword"> +=</span><span> accessed_storage_keys</span></span></code></pre> <p>This code shows how block-level slot warming is implemented at the execution layer. The <code>block_level_accessed_addresses</code> and <code>block_level_accessed_storage_keys</code> sets are maintained throughout the block's execution and passed to each transaction's environment.</p> <h4 id="transaction-processing">Transaction Processing</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_transaction</span><span>(</span><span class="z-variable z-parameter z-function">env</span><span>:</span><span> vm</span><span>.</span><span>Environment</span><span>,</span><span class="z-variable z-parameter z-function"> tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>Uint</span><span>,</span><span> Tuple</span><span>[</span><span>Log</span><span>,</span><span class="z-constant"> ...</span><span>]</span><span>,</span><span> Optional</span><span>[</span><span class="z-support">Exception</span><span>]</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> preaccessed_addresses</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> preaccessed_storage_keys</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Add block-level pre-accessed slots</span></span> <span class="giallo-l"><span> preaccessed_addresses</span><span>.</span><span>add</span><span>(</span><span>env</span><span>.</span><span>block_level_accessed_addresses</span><span>)</span></span> <span class="giallo-l"><span> preaccessed_storage_keys</span><span>.</span><span>add</span><span>(</span><span>env</span><span>.</span><span>block_level_accessed_storage_keys</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Handle access lists from transaction</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>This adds the block-level-accessed addresses and storage keys to the preaccessed addresses and storage keys. As a result, from the perspective of a transaction, block-level accessed addresses and storage keys are treated the same as precompiles or the coinbase address.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_message_call</span><span>(</span><span class="z-variable z-parameter z-function">message</span><span>:</span><span> Message</span><span>,</span><span class="z-variable z-parameter z-function"> env</span><span>:</span><span> Environment</span><span>)</span><span> -&gt;</span><span> MessageCallOutput</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> MessageCallOutput</span><span>(</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ... other fields ...</span></span> <span class="giallo-l"><span class="z-variable"> accessed_addresses</span><span class="z-keyword">=</span><span>evm</span><span>.</span><span>accessed_addresses</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> accessed_storage_keys</span><span class="z-keyword">=</span><span>evm</span><span>.</span><span>accessed_storage_keys</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>The message call processing tracks accessed addresses and storage keys during execution, which are then propagated back up to the transaction level and ultimately to the block level.</p> <h2 id="rationale">Rationale</h2> <p>The proposal builds on several key observations:</p> <ol> <li> <p><strong>Caching Efficiency</strong>: Modern Ethereum clients already implement sophisticated caching mechanisms at the block level. Extending address and storage key warming to match this caching behavior better aligns gas costs with actual computational costs.</p> </li> <li> <p><strong>Backward Compatibility</strong>: The worst-case scenario for any transaction remains unchanged - it will never pay more than the current cold access cost for its first access to a slot.</p> </li> <li> <p><strong>Handling Reverts</strong>: In EIP-2929, if a sub-call reverts, all accessed addresses and slots are reverted to a cold state. Under block-level warming, it remains an open question whether a failing transaction (i.e., one that reverts) should ‘unwarm’ previously warmed addresses and slots for subsequent transactions within the same block. Some propose removing this revert-induced “cold reset” altogether to maintain consistency with block-level warming. This point warrants further discussion, particularly around whether or not preserving a warmed state even upon failure aligns with the broader goal of better matching gas costs to actual client caching behavior.</p> </li> <li> <p><strong>First Access Warms For All</strong>: Under the proposed mechanism, the first transaction in a block that accesses and warms multiple addresses or storage slots bears the entire cost of warming, even if subsequent transactions benefit from those already-warmed slots without incurring additional costs. This approach is deemed acceptable because early execution within a block—where warming typically occurs—is generally occupied for transactions placed by professional builders aiming for top-of-block execution. Since the resulting cost discrepancy is relatively minor, a more complex cost-sharing model is avoided in favor of maintaining simplicity. An alternative to the one-warms-for-all mechanism involves distributing the warming costs across all accesses within a block. In this approach, each transaction must at least be able to pay the cold access cost. Once all transactions in the block are executed, the total warming costs are evenly distributed, and transaction originators are refunded accordingly.</p> </li> <li> <p><strong>Alternative Block Warming Windows</strong>: Instead of applying warming at the block level, more advanced multi-block warming approaches can be considered. Potential options include:</p> <ul> <li>Warming addresses and storage keys over the duration of an epoch</li> <li>Using a ring buffer spanning <code>x</code> blocks Since the Execution Layer (EL) currently operates without regard to epoch boundaries, it may be preferable to maintain this design. Therefore, the second option, involving a ring buffer of size x, could be more suitable. For the ring buffer, one approach might be to store the relevant warmed information in the block header for those x blocks, but this introduces additional overhead and can complicate statelessness. Careful design would be required to manage these trade-offs (e.g., header size, client complexity) if a multi-block warming solution were adopted.</li> </ul> </li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backward compatible and requires a hard fork activation. However, it does not introduce any breaking changes for existing contracts, as:</p> <ol> <li>All existing transactions will continue to work as before</li> <li>Gas costs will only decrease, never increase</li> <li>Contract logic depending on gas costs will remain valid, as the worst-case scenario is unchanged</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <ol> <li> <p><strong>Memory Usage</strong>: The set of warm slots is still bounded by block gas limit / minimum gas cost per slot access, preventing DoS attacks through excessive memory usage.</p> </li> <li> <p><strong>MEV Considerations</strong>: Block producers can optimize transaction ordering to maximize slot warming benefits for themselves. Third-party block builders can backrun transactions that warmed specific addresses or storage keys.</p> </li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-27T00:00:00+00:00 2026-02-11T14:49:28+00:00 Liyi Guohttps://github.com/colinlyguo https://wg-eips.ritovision.com/7851/

Introduce a new precompiled contract for EOAs with delegated code to deactivate or reactivate private keys.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a precompiled contract that enables Externally Owned Accounts (EOAs) with delegated control to smart contracts via <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> to deactivate or reactivate their private keys. This design does not require additional storage fields or account state changes. By leveraging delegated code, reactivation can be performed securely through mechanisms such as social recovery.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> enables EOAs to gain smart contract capabilities, but the private key of the EOA still retains full control over the account.</p> <p>With this EIP, EOAs can fully migrate to smart contract wallets, while retaining private key recovery options with reactivation. The flexible deactivate and reactivate design also paves the way for native account abstraction. e.g., <a href="https://wg-eips.ritovision.com/7701/">EIP-7701</a>.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>PRECOMPILE_ADDRESS</code></td><td><code>0xTBD</code></td></tr> <tr><td><code>PRECOMPILE_GAS_COST</code></td><td><code>13000</code></td></tr> </tbody></table> <h3 id="definitions">Definitions</h3> <ul> <li><code>||</code> is the byte/byte-array concatenation operator.</li> </ul> <h3 id="delegated-code-encoding">Delegated Code Encoding</h3> <p>The deactivation status is encoded by appending or removing the <code>0x00</code> byte at the end of the delegated code. The transitions between two states are as follows:</p> <ul> <li>Active state: <code>0xef0100 || address</code>. The private key is active and can sign transactions.</li> <li>Deactivated state: <code>0xef0100 || address || 0x00</code>. The private key is deactivated and cannot sign transactions or <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation authorizations.</li> </ul> <h3 id="precompiled-contract">Precompiled Contract</h3> <p>A new precompiled contract is introduced at address <code>PRECOMPILE_ADDRESS</code>. It costs <code>PRECOMPILE_GAS_COST</code> and executes the following logic:</p> <ul> <li>Returns a precompile contract error, consumes all gas, and no state changes are made if: <ul> <li>Gas is insufficient.</li> <li>Called via <code>STATICCALL</code> (i.e., in a read-only context).</li> <li>Caller is not an EOA with delegated code (prefix <code>0xef0100</code> as per <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>).</li> </ul> </li> <li>Updates caller's delegated code based on length: <ul> <li><code>23</code> bytes (<code>0xef0100 || address</code>): Appends <code>0x00</code> to deactivate private key authorization.</li> <li><code>24</code> bytes (<code>0xef0100 || address || 0x00</code>): Removes last byte <code>0x00</code> to activate private key authorization.</li> </ul> </li> <li>Saves updated code as caller's new account code.</li> </ul> <h3 id="transaction-validation">Transaction Validation</h3> <p>Validation to check whether a private key is deactivated (identified by a code prefix <code>0xef0100</code> and a code length of <code>24</code>) MUST be performed in the following scenarios:</p> <ul> <li>During transaction validity checks before execution, nodes MUST reject transactions signed with deactivated private keys to ensure such transactions cannot be included in blocks.</li> <li>The same validation MUST be applied to the transaction pool when receiving new transactions to prevent invalid transactions from propagating through the network.</li> <li>Any <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization issued by an authority with a deactivated private key MUST be treated as invalid and skipped.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="cost-of-precompiled-contract">Cost of Precompiled Contract</h3> <p>The <code>PRECOMPILE_GAS_COST</code> represents the gas required to validate and potentially update an account's code. A fair cost for calling this precompiled contract can be determined by analyzing its impact on the node:</p> <ul> <li>Reading the code of the address: <code>2600</code>.</li> <li>Changing the code hash (from non-zero to non-zero): <code>5000</code>.</li> <li>Deploying at most <code>24</code> bytes of code: <code>200 * 24 = 4800</code>.</li> </ul> <p>The primary operation consumes a total of <code>12400</code> gas. To account for additional overhead, such as context switching during state transitions, as well as code prefix and length validations, the cost is rounded up to <code>13000</code>.</p> <h3 id="additional-transaction-validation-overhead">Additional Transaction Validation Overhead</h3> <p>Due to <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a> and <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>, nodes already load the account code during transaction validation to verify whether the sender is an EOA (empty code or code with prefix <code>0xef0100</code>). This EIP introduces only a code length check after loading the code, resulting in minimal additional overhead. Similarly, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>’s authorization validation already involves retrieving the account code, with this EIP adding only a code length check, which is negligible compared to code reading.</p> <p>Transaction pools already perform state-based checks, such as those for nonce and balance. This EIP adds an account code read and a length check, which together are comparable to nonce and balance validations. DoS prevention mechanisms, expected in transaction pools, also support these additional checks.</p> <h3 id="an-alternative-eoa-deprecation-approach">An Alternative EOA Deprecation Approach</h3> <p>An alternative deprecation approach involves using a hard fork to edit all existing and new EOAs to pre-written upgradeable smart contracts, which utilize the original EOA private key for authorization. Users can add and replace keys, or upgrade the smart contracts to other implementations. However, this approach is incompatible with EOAs already delegated to smart contracts, as it will overwrite the existing smart contract implementations. This EIP aims to fill this migration gap.</p> <h3 id="using-a-precompiled-contract">Using a Precompiled Contract</h3> <p>Alternative methods for deactivating and reactivating EOA private keys include:</p> <ul> <li>Adding a new transaction type: Introducing a new transaction type could provide a mechanism to deactivate and reactivate EOA private keys. However, reactivating the private key would rely on a delegated contract as the authorizer, which complicates defining the rules for the new transaction type.</li> <li>Deploying a smart contract: Compared to reusing the code field, using a smart contract has higher costs: (i) it requires new contract storage slots to track the deactivation status of each address (ii) executing bytecode increases the overhead of the node compared to precompiled contracts, (iii) during transaction validation, reusing the code field allows deactivation status check to be combined with existing code loading in some scenarios, thereby reducing the need for additional storage reads, as discussed in <a href="https://wg-eips.ritovision.com/7851/#additional-transaction-validation-overhead">Additional Transaction Validation Overhead</a> section.</li> </ul> <h3 id="in-protocol-reactivation">In-Protocol Reactivation</h3> <p>This approach ensures maximum compatibility with future migrations. EOAs can reactivate their private keys, delegate their accounts to an <a href="https://wg-eips.ritovision.com/7701/">EIP-7701</a> contract, and then deactivate their private keys again. This avoids the limitations of contract upgrades. e.g., to remove legacy proxy contracts (reducing gas overhead) when upgrading to EOF contracts, one can reactivate the EOA and redelegate it to an EOF proxy contract.</p> <p>Reactivation can only be performed by the delegated contract. Since reactivating the private key grants full control over the wallet, wallets must implement this interface with strict security measures. These measures should treat reactivation as the highest level of authority, equivalent to full wallet ownership. Users should delegate their EOAs only to wallets that have been thoroughly audited and follow best practices for security.</p> <h3 id="avoiding-delegated-code-prefix-modification">Avoiding Delegated Code Prefix Modification</h3> <p>This EIP appends a byte (<code>0x00</code>) to the delegated code instead of modifying the prefix (<code>0xef0100</code>) of <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> to ensure forward compatibility. If new prefixes such as <code>0xef0101</code> are introduced in the future, changing the prefix to represent the deactivated status (e.g., <code>0xef01ff</code>) makes it unclear which prefix to restore (<code>0xef0100</code> or <code>0xef0101</code>) upon reactivation.</p> <h3 id="avoiding-account-state-changes">Avoiding Account State Changes</h3> <p>An alternative is to add a <code>deactivated</code> field in the account state to track the status. However, this approach will introduce backward compatibility logic and more test vectors related to this optional field when enabling this EIP, because the field is not present in existing accounts.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>When the private key is deactivated, this EIP introduces: (i) an extra byte (<code>0x00</code>) to be appended to the end of the delegated code, and (ii) the delegated code length becomes <code>24</code> bytes (e.g., <code>EXTCODESIZE</code> would return <code>24</code>).</p> <p>These changes are not breaking. However, they require protocol, application, and contract implementations to use strict offsets to parse the delegated address correctly. Implementations must also check the delegated code prefix <code>0xef0100</code> to determine whether it represents an EOA with delegated code, while avoiding over-restrictive checks, such as asserting the code length to be exactly <code>23</code>.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Initialize the state database and precompiled contract</span></span> <span class="giallo-l"><span>state_db</span><span class="z-keyword"> =</span><span> StateDB</span><span>(</span><span>)</span></span> <span class="giallo-l"><span>precompile</span><span class="z-keyword"> =</span><span> PrecompiledContract</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Test 1: Valid activation and deactivation</span></span> <span class="giallo-l"><span>caller</span><span class="z-keyword"> =</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0123</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span>delegated_addr</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>.</span><span>fromhex</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">1122334455667788990011223344556677889900</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span>active_code</span><span class="z-keyword"> =</span><span> PrecompiledContract</span><span>.</span><span class="z-constant">DELEGATED_CODE_PREFIX</span><span class="z-keyword"> +</span><span> delegated_addr</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Active state</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>state_db</span><span>.</span><span>set_code</span><span>(</span><span>caller</span><span>,</span><span> active_code</span><span>)</span></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span class="z-constant">15000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> state_db</span><span>.</span><span>get_code</span><span>(</span><span>caller</span><span>)</span><span class="z-keyword"> ==</span><span> active_code</span><span class="z-keyword"> +</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Deactivated state</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 15000</span><span class="z-keyword"> -</span><span> PrecompiledContract</span><span>.</span><span class="z-constant">PRECOMPILE_GAS_COST</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span class="z-constant">15000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> state_db</span><span>.</span><span>get_code</span><span>(</span><span>caller</span><span>)</span><span class="z-keyword"> ==</span><span> active_code</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Turns to the active state again</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 15000</span><span class="z-keyword"> -</span><span> PrecompiledContract</span><span>.</span><span class="z-constant">PRECOMPILE_GAS_COST</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Test 2: Error cases</span></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span class="z-constant">15000</span><span>,</span><span class="z-variable"> read_only</span><span class="z-keyword">=</span><span class="z-constant">True</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">STATICCALL disallows state modification</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span>PrecompiledContract</span><span>.</span><span class="z-constant">PRECOMPILE_GAS_COST</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">insufficient gas</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>caller</span><span class="z-keyword"> =</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x4567</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EOA that is not delegated to code</span></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span class="z-constant">15000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">the address is not an EOA delegated to code</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>caller</span><span class="z-keyword"> =</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x89ab</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This is a contract address.</span></span> <span class="giallo-l"><span>state_db</span><span>.</span><span>set_code</span><span>(</span><span>caller</span><span>,</span><span class="z-support"> bytes</span><span>.</span><span>fromhex</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">60006000f3</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>)</span></span> <span class="giallo-l"><span>error</span><span>,</span><span> gas_left</span><span class="z-keyword"> =</span><span> precompile</span><span>.</span><span>execute</span><span>(</span><span>caller</span><span>,</span><span> state_db</span><span>,</span><span class="z-variable"> gas</span><span class="z-keyword">=</span><span class="z-constant">15000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> error</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">the address is not an EOA delegated to code</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> gas_left</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span></span></code></pre><h2 id="reference-implementation">Reference Implementation</h2> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> PrecompiledContract</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> DELEGATED_CODE_PREFIX</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>.</span><span>fromhex</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">ef0100</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span class="z-constant"> PRECOMPILE_GAS_COST</span><span class="z-keyword"> =</span><span class="z-constant"> 13000</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> execute</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> caller</span><span>,</span><span class="z-variable z-parameter z-function"> state_db</span><span>,</span><span class="z-variable z-parameter z-function"> gas</span><span>,</span><span class="z-variable z-parameter z-function"> read_only</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Switch the private key state of delegated EOAs between active and deactivated.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Parameters:</span></span> <span class="giallo-l"><span class="z-string"> - caller: The address calling the contract</span></span> <span class="giallo-l"><span class="z-string"> - state_db: The state database</span></span> <span class="giallo-l"><span class="z-string"> - gas: Gas provided for execution</span></span> <span class="giallo-l"><span class="z-string"> - read_only: Whether called in a read-only context</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> Returns:</span></span> <span class="giallo-l"><span class="z-string"> - Tuple of (result, gas_left)</span></span> <span class="giallo-l"><span class="z-string"> result: error bytes on failure, empty bytes on success</span></span> <span class="giallo-l"><span class="z-string"> gas_left: remaining gas, 0 on error</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check gas</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> gas</span><span class="z-keyword"> &lt;</span><span class="z-variable z-language"> self</span><span>.</span><span class="z-constant">PRECOMPILE_GAS_COST</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">insufficient gas</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check STATICCALL</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> read_only</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">STATICCALL disallows state modification</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Get and validate caller&#39;s code</span></span> <span class="giallo-l"><span> code</span><span class="z-keyword"> =</span><span> state_db</span><span>.</span><span>get_code</span><span>(</span><span>caller</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> code</span><span>.</span><span>startswith</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span class="z-constant">DELEGATED_CODE_PREFIX</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">the address is not an EOA delegated to code</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Update delegated code based on length</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 23</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Active state</span></span> <span class="giallo-l"><span> state_db</span><span>.</span><span>set_code</span><span>(</span><span>caller</span><span>,</span><span> code</span><span class="z-keyword"> +</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Deactivate</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 24</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Deactivated state</span></span> <span class="giallo-l"><span> state_db</span><span>.</span><span>set_code</span><span>(</span><span>caller</span><span>,</span><span> code</span><span>[</span><span>:</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Activate</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Although this is not possible, it&#39;s added for completeness</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">invalid delegated code length</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span> gas</span><span class="z-keyword"> -</span><span class="z-variable z-language"> self</span><span>.</span><span class="z-constant">PRECOMPILE_GAS_COST</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> StateDB</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Simplified state database, omitting other account fields</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-support"> __init__</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>accounts</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> get_code</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> self</span><span>.</span><span>accounts</span><span>.</span><span>get</span><span>(</span><span>addr</span><span>,</span><span> {</span><span>}</span><span>)</span><span>.</span><span>get</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">code</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> set_code</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> addr</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span class="z-variable z-language"> self</span><span>.</span><span>accounts</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>accounts</span><span>[</span><span>addr</span><span>]</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>accounts</span><span>[</span><span>addr</span><span>]</span><span>[</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">code</span><span class="z-punctuation z-definition z-string">&quot;</span><span>]</span><span class="z-keyword"> =</span><span> value</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <h3 id="contracts-using-ecdsa-secp256k1-signatures">Contracts Using ECDSA <code>Secp256k1</code> Signatures</h3> <p>Contracts that have already been deployed and use ECDSA <code>secp256k1</code> signatures outside of transaction signatures (e.g., <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> tokens that support <a href="https://wg-eips.ritovision.com/2612/">ERC-2612</a>, the <code>permit</code> function) will not be able to verify the deactivated status of the EOA. This means that signatures signed by private keys will remain valid in these functions.</p> <p>To handle deactivated EOAs, new or upgradeable contracts can check the signing address's deactivation status, for example:</p> <ul> <li>Use <code>EXTCODESIZE</code> to get the account's code length.</li> <li>If the code length is <code>24</code> bytes, use <code>EXTCODECOPY</code> to verify the code starts with <code>0xef0100</code> (delegated code prefix).</li> <li>If both conditions are satisfied (i.e., the code size is <code>24</code> bytes and the code starts with <code>0xef0100</code>), the private key is confirmed to be deactivated, and the signature should be rejected.</li> </ul> <p>For non-upgradeable contracts, the above method cannot be applied directly. Another potential solution, at the protocol level, is to modify <code>ecRecover</code> precompiled contract: if the private key of the recovered address is deactivated, the <code>ecRecover</code> precompiled contract could return a precompile contract error (or, if not adding an error return path, return a zero address or a collision-resistant address, such as <code>0x1</code>). However, this approach also has limitations, as it cannot cover cases where contracts implement their own signature verification logic without relying on <code>ecRecover</code>.</p> <h3 id="irreversible-deactivation">Irreversible Deactivation</h3> <p>Delegating to a wallet that lacks reactivation support (e.g., by calling the precompiled contract through an appropriate interface) may result in irreversible deactivation. To mitigate this risk, users should delegate their EOAs only to thoroughly audited implementations that explicitly support this EIP.</p> <h3 id="deactivation-and-reactivation-replay">Deactivation and Reactivation Replay</h3> <p>Replay attacks can occur in two scenarios: (i) repeating the same authorization on a single chain, or (ii) using the authorization across different chains.</p> <p>For deactivation through EOA-signed transactions, the use of nonces in transactions ensures the same message cannot be replayed multiple times on the same chain. Additionally, the replay protection mechanism provided by <a href="https://wg-eips.ritovision.com/155/">EIP-155</a>, if enabled, effectively prevents cross-chain message replay.</p> <p>For deactivation or reactivation via delegated contracts, the contract should implement robust replay protection mechanism(s) (e.g., adding a customized nonce and the chain ID to the signed message) to safeguard against replay attacks both within the same chain and across different chains. Especially when the EOA has been (or will be) delegated to the same implementation on multiple chains.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-27T00:00:00+00:00 2026-02-11T14:49:27+00:00 Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7981/

Price access lists for data to reduce maximum block size

<h2 id="abstract">Abstract</h2> <p>This EIP charges access lists for their data footprint, preventing the circumvention of the <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor pricing. This effectively reduces the worst-case block size by ~21% with minimal impact on users.</p> <h2 id="motivation">Motivation</h2> <p>Access lists are only priced for storage but not for their data.</p> <p>Furthermore, access lists can circumvent the <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor pricing by contributing to EVM gas while still leaving a non-negligible data footprint. This enables achieving the maximal possible block size by combining access lists with calldata at a certain ratio.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th><th>Source</th></tr></thead><tbody> <tr><td><code>ACCESS_LIST_ADDRESS_COST</code></td><td><code>2400</code></td><td><a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a></td></tr> <tr><td><code>ACCESS_LIST_STORAGE_KEY_COST</code></td><td><code>1900</code></td><td><a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a></td></tr> <tr><td><code>TOTAL_COST_FLOOR_PER_TOKEN</code></td><td><code>10</code></td><td><a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a></td></tr> </tbody></table> <p>Let <code>access_list_nonzero_bytes</code> and <code>access_list_zero_bytes</code> be the count of non-zero and zero bytes respectively in the addresses (20 bytes each) and storage keys (32 bytes each) contained within the access list.</p> <p>Let <code>tokens_in_access_list = access_list_zero_bytes + access_list_nonzero_bytes * 4</code>.</p> <p>The access list cost formula changes from <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> to include data cost:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>access_list_cost</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> ACCESS_LIST_ADDRESS_COST</span><span class="z-keyword"> *</span><span> access_list_addresses</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> ACCESS_LIST_STORAGE_KEY_COST</span><span class="z-keyword"> *</span><span> access_list_storage_keys</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> tokens_in_access_list</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>The <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor calculation is modified to include access list tokens:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tokens_in_calldata</span><span class="z-keyword"> =</span><span> zero_bytes_in_calldata</span><span class="z-keyword"> +</span><span> nonzero_bytes_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span>total_data_tokens</span><span class="z-keyword"> =</span><span> tokens_in_calldata</span><span class="z-keyword"> +</span><span> tokens_in_access_list</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>data_floor_gas_cost</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-keyword"> +</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> total_data_tokens</span></span></code></pre> <p>The gas used calculation becomes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> isContractCreation</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">32000</span><span class="z-keyword"> +</span><span class="z-constant"> INITCODE_WORD_COST</span><span class="z-keyword"> *</span><span> words</span><span>(</span><span>calldata</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> access_list_cost</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> total_data_tokens</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Any transaction with a gas limit below <code>21000 + TOTAL_COST_FLOOR_PER_TOKEN * total_data_tokens</code> or below its intrinsic gas cost is considered invalid.</p> <h2 id="rationale">Rationale</h2> <p>Access list data is always charged at floor rate (added to <code>access_list_cost</code>), and access list tokens are included in the floor calculation. This ensures:</p> <ul> <li>Access list data always pays floor rate regardless of execution level</li> <li>Access lists cannot be used to bypass the calldata floor pricing</li> <li>Consistent pricing across all transaction data sources</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Requires updates to gas estimation in wallets and nodes. Normal usage patterns remain largely unaffected.</p> <h2 id="reference-implementation">Reference Implementation</h2> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_access_list_tokens</span><span>(</span><span class="z-variable z-parameter z-function">access_list</span><span>:</span><span> Tuple</span><span>[</span><span>Access</span><span>,</span><span class="z-constant"> ...</span><span>]</span><span>)</span><span> -&gt;</span><span> Uint</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span><span class="z-string">Count data tokens in access list addresses and storage keys.</span><span class="z-punctuation z-definition z-string">&quot;&quot;&quot;</span></span> <span class="giallo-l"><span> zero_bytes</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> nonzero_bytes</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> access</span><span class="z-keyword"> in</span><span> access_list</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> byte</span><span class="z-keyword"> in</span><span> access</span><span>.</span><span>account</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> byte</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> zero_bytes</span><span class="z-keyword"> +=</span><span> Uint</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> nonzero_bytes</span><span class="z-keyword"> +=</span><span> Uint</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> slot</span><span class="z-keyword"> in</span><span> access</span><span>.</span><span>slots</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> byte</span><span class="z-keyword"> in</span><span> slot</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> byte</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> zero_bytes</span><span class="z-keyword"> +=</span><span> Uint</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> nonzero_bytes</span><span class="z-keyword"> +=</span><span> Uint</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> zero_bytes</span><span class="z-keyword"> +</span><span> nonzero_bytes</span><span class="z-keyword"> *</span><span> Uint</span><span>(</span><span class="z-constant">4</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_intrinsic_cost</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>Uint</span><span>,</span><span> Uint</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Calculate intrinsic gas cost and floor gas cost.</span></span> <span class="giallo-l"><span class="z-string"> Returns (intrinsic_gas, floor_gas).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Calldata tokens</span></span> <span class="giallo-l"><span> calldata_zero_bytes</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> byte</span><span class="z-keyword"> in</span><span> tx</span><span>.</span><span>data</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> byte</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> calldata_zero_bytes</span><span class="z-keyword"> +=</span><span> Uint</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span> tokens_in_calldata</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> calldata_zero_bytes</span><span class="z-keyword"> +</span><span> (</span><span>ulen</span><span>(</span><span>tx</span><span>.</span><span>data</span><span>)</span><span class="z-keyword"> -</span><span> calldata_zero_bytes</span><span>)</span><span class="z-keyword"> *</span><span> Uint</span><span>(</span><span class="z-constant">4</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Access list tokens and cost</span></span> <span class="giallo-l"><span> tokens_in_access_list</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> access_list_cost</span><span class="z-keyword"> =</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> has_access_list</span><span>(</span><span>tx</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> tokens_in_access_list</span><span class="z-keyword"> =</span><span> calculate_access_list_tokens</span><span>(</span><span>tx</span><span>.</span><span>access_list</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> access</span><span class="z-keyword"> in</span><span> tx</span><span>.</span><span>access_list</span><span>:</span></span> <span class="giallo-l"><span> access_list_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> TX_ACCESS_LIST_ADDRESS_COST</span></span> <span class="giallo-l"><span> access_list_cost</span><span class="z-keyword"> +=</span><span> ulen</span><span>(</span><span>access</span><span>.</span><span>slots</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> TX_ACCESS_LIST_STORAGE_KEY_COST</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-7981: Always charge data cost</span></span> <span class="giallo-l"><span> access_list_cost</span><span class="z-keyword"> +=</span><span> tokens_in_access_list</span><span class="z-keyword"> *</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-7981: Floor includes all data tokens</span></span> <span class="giallo-l"><span> total_data_tokens</span><span class="z-keyword"> =</span><span> tokens_in_calldata</span><span class="z-keyword"> +</span><span> tokens_in_access_list</span></span> <span class="giallo-l"><span> floor_gas</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-keyword"> +</span><span> total_data_tokens</span><span class="z-keyword"> *</span><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Intrinsic gas</span></span> <span class="giallo-l"><span> calldata_cost</span><span class="z-keyword"> =</span><span> tokens_in_calldata</span><span class="z-keyword"> *</span><span class="z-constant"> STANDARD_TOKEN_COST</span></span> <span class="giallo-l"><span> create_cost</span><span class="z-keyword"> =</span><span class="z-constant"> TX_CREATE_COST</span><span class="z-keyword"> +</span><span> init_code_cost</span><span>(</span><span>tx</span><span>.</span><span>data</span><span>)</span><span class="z-keyword"> if</span><span> is_create</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> else</span><span> Uint</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> intrinsic_gas</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-keyword"> +</span><span> calldata_cost</span><span class="z-keyword"> +</span><span> create_cost</span><span class="z-keyword"> +</span><span> access_list_cost</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> intrinsic_gas</span><span>,</span><span> floor_gas</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>This EIP closes a loophole that allows circumventing <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> floor pricing. Without this fix, attackers can achieve larger blocks than intended by combining access lists with calldata. All transaction data sources now contribute to the floor calculation consistently.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charlie Noyescharlie@paradigm.xyz Dan Robinsondan@paradigm.xyz Justin Drakejustin@ethereum.org Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7862/

Separate state root computation from block validation

<h2 id="abstract">Abstract</h2> <p>This proposal decouples state root computation from block validation by deferring the execution layer's state root reference by one block. Each block's header contains the post-state root of the previous block rather than its own. Validators can attest to block validity without waiting for state root computation.</p> <h2 id="motivation">Motivation</h2> <p>State root computation is a significant bottleneck in block production. With <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a> (ePBS), builders have tighter timing constraints. <a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a> (Block-Level Access Lists) enables parallel state access but doesn't help with state root computation for builders.</p> <p>With delayed state roots:</p> <ol> <li><strong>Builders compute one state root per slot</strong> (for the previous block) instead of thousands during the MEV auction window</li> <li><strong>State root computation can use BAL data</strong> from the previous block to parallelize proof generation</li> <li><strong>The critical path shifts</strong>: state root computation is frontloaded to the beginning of the slot rather than blocking attestations</li> </ol> <p>The state root in block <code>n</code> represents the post-state of block <code>n-1</code> (equivalently: the pre-state of block <code>n</code>). Light clients experience one slot of additional latency for state proofs.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="header">Header</h3> <p>The <code>state_root</code> field semantics change. No new fields are added.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Header</span><span>:</span></span> <span class="giallo-l"><span> parent_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> ommers_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> coinbase</span><span>:</span><span> Address</span></span> <span class="giallo-l"><span> state_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Post-state of block (n-1), i.e., pre-state of this block</span></span> <span class="giallo-l"><span> transactions_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> receipt_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> bloom</span><span>:</span><span> Bloom</span></span> <span class="giallo-l"><span> difficulty</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> number</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span> U256</span></span> <span class="giallo-l"><span> extra_data</span><span>:</span><span> Bytes</span></span> <span class="giallo-l"><span> prev_randao</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> Bytes8</span></span> <span class="giallo-l"><span> base_fee_per_gas</span><span>:</span><span> Uint</span></span> <span class="giallo-l"><span> withdrawals_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> blob_gas_used</span><span>:</span><span> U64</span></span> <span class="giallo-l"><span> excess_blob_gas</span><span>:</span><span> U64</span></span> <span class="giallo-l"><span> parent_beacon_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> requests_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> block_access_list_hash</span><span>:</span><span> Hash32</span></span></code></pre><h3 id="blockchain">BlockChain</h3> <p>The <code>BlockChain</code> object tracks the last computed state root:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BlockChain</span><span>:</span></span> <span class="giallo-l"><span> blocks</span><span>:</span><span> List</span><span>[</span><span>Block</span><span>]</span></span> <span class="giallo-l"><span> state</span><span>:</span><span> State</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> U64</span></span> <span class="giallo-l"><span> last_computed_state_root</span><span>:</span><span> Root</span></span></code></pre><h3 id="header-validation">Header Validation</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_header</span><span>(</span><span class="z-variable z-parameter z-function">chain</span><span>:</span><span> BlockChain</span><span>,</span><span class="z-variable z-parameter z-function"> header</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> header</span><span>.</span><span>number</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> parent_header</span><span class="z-keyword"> =</span><span> chain</span><span>.</span><span>blocks</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span><span>.</span><span>header</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify delayed state root matches the last computed state root</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> header</span><span>.</span><span>state_root</span><span class="z-keyword"> !=</span><span> chain</span><span>.</span><span>last_computed_state_root</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ... remaining validation unchanged</span></span></code></pre><h3 id="state-transition">State Transition</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> state_transition</span><span>(</span><span class="z-variable z-parameter z-function">chain</span><span>:</span><span> BlockChain</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> validate_header</span><span>(</span><span>chain</span><span>,</span><span> block</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> block_env</span><span class="z-keyword"> =</span><span> vm</span><span>.</span><span>BlockEnvironment</span><span>(</span><span class="z-constant">...</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> block_output</span><span class="z-keyword"> =</span><span> apply_body</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> block_env</span><span class="z-keyword">=</span><span>block_env</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> transactions</span><span class="z-keyword">=</span><span>block</span><span>.</span><span>transactions</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> withdrawals</span><span class="z-keyword">=</span><span>block</span><span>.</span><span>withdrawals</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate all roots except state_root (already validated in header)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_output</span><span>.</span><span>block_gas_used</span><span class="z-keyword"> !=</span><span> block</span><span>.</span><span>header</span><span>.</span><span>gas_used</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> InvalidBlock</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ... other validations</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute and store state root for the NEXT block</span></span> <span class="giallo-l"><span> chain</span><span>.</span><span>last_computed_state_root</span><span class="z-keyword"> =</span><span> state_root</span><span>(</span><span>block_env</span><span>.</span><span>state</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> chain</span><span>.</span><span>blocks</span><span>.</span><span>append</span><span>(</span><span>block</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>chain</span><span>.</span><span>blocks</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 255</span><span>:</span></span> <span class="giallo-l"><span> chain</span><span>.</span><span>blocks</span><span class="z-keyword"> =</span><span> chain</span><span>.</span><span>blocks</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">255</span><span>:</span><span>]</span></span></code></pre><h3 id="fork-activation">Fork Activation</h3> <p>At activation block <code>F</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> apply_fork</span><span>(</span><span class="z-variable z-parameter z-function">old</span><span>:</span><span> BlockChain</span><span>)</span><span> -&gt;</span><span> BlockChain</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initialize last_computed_state_root to current state root</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> (post-state of block F-1)</span></span> <span class="giallo-l"><span> old</span><span>.</span><span>last_computed_state_root</span><span class="z-keyword"> =</span><span> state_root</span><span>(</span><span>old</span><span>.</span><span>state</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> old</span></span></code></pre> <p>Block <code>F</code> MUST contain the post-state root of block <code>F-1</code>. From <code>F+1</code> onwards, each block contains its parent's post-state root.</p> <h2 id="rationale">Rationale</h2> <h3 id="epbs-compatibility">ePBS Compatibility</h3> <p>With <a href="https://wg-eips.ritovision.com/7732/">EIP-7732</a>, the <code>ExecutionPayloadEnvelope</code> contains a CL <code>state_root</code> verified at the end of <code>process_execution_payload</code>. This EIP changes only the EL header's <code>state_root</code> semantics. The CL state root verification is unaffected.</p> <h3 id="bal-synergy">BAL Synergy</h3> <p><a href="https://wg-eips.ritovision.com/7928/">EIP-7928</a> provides the block access list, which identifies all storage slots touched during execution. With delayed state roots, clients can:</p> <ol> <li>Receive block <code>n</code> with BAL</li> <li>Use the BAL to parallelize state root computation for block <code>n</code></li> <li>Include that root in block <code>n+1</code></li> </ol> <p>Without this EIP, BALs don’t help with state root computation: the root is only known after execution finishes, which is too late to use within the same slot. With this proposal, builders can start constructing a block without fully executing the previous one, by applying the BAL state diff to the slot’s pre-state.</p> <h3 id="light-client-impact">Light Client Impact</h3> <p>State proofs for block <code>n</code> require waiting for block <code>n+1</code>. Most light client protocols already tolerate multi-block delays for proof generation. The security model is unchanged; only timing shifts by one slot.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Requires a hard fork. Clients that do not implement this change will reject blocks with delayed state roots.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="reorganization-handling">Reorganization Handling</h3> <p>During reorgs, clients MUST recompute <code>last_computed_state_root</code> for each block in the new canonical chain. The delayed nature does not affect reorg logic.</p> <h3 id="pre-state-availability">Pre-state Availability</h3> <p>Clients MUST retain the pre-state (post-state of parent block) until the current block's state root is included in the next block. This is already standard practice for reorg handling.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Entrikenhttps://github.com/fulldecent https://wg-eips.ritovision.com/7848/

Allows participants to indicate readiness for a client upgrade when producing blocks

<h2 id="abstract">Abstract</h2> <p>This proposal adds a mechanism for clients to signal their willingness for a network upgrade by including a “reference implementation hash” field in each block. A network upgrade activates only if enough blocks specify that they are using the new software.</p> <h2 id="motivation">Motivation</h2> <p>Currently, upgrades to Ethereum Mainnet are announced on the ethereum.org blog. This proposal changes that process by activating upgrades based on the consent of network participants.</p> <h2 id="specification">Specification</h2> <p>Ethereum consensus clients shall identify with a reference implementation having its equivalent behaviors.</p> <p>Ethereum consensus clients shall include a <code>referenceImplementationHash</code> (specified below) field immediately following the <code>extraData</code> field in the block header.</p> <p>Proposed new Ethereum consensus clients shall initially behave as the then-current network does. If, and only if, a successful upgrade (defined below) is activated will the new behavior take effect.</p> <p>When a network participant is willing to support a network upgrade, they shall immediately begin using the new software. The blocks they create including the new <code>referenceImplementationHash</code> will contribute to the network upgrade activation.</p> <h3 id="the-reference-implementation-hash">The Reference Implementation Hash</h3> <p>When proposing a network upgrade, the proposer shall point to a published, feature-complete reference implementation including the new software behaviors.</p> <p>The <strong>reference implementation hash</strong> is the SHA-256 hash of the tarred source code of this reference implementation.</p> <h3 id="verification">Verification</h3> <p>Network participants shall study the reference implementation and decide whether they support an upgrade.</p> <p>Network participants shall study any specific software they will run and ensure it faithfully implements the behaviors consistent with that reference implementation.</p> <h3 id="upgrade">Upgrade</h3> <p>Upgrade proposals (often referred to as hard fork EIPs) must specify an upgrade window and threshold. These parameters are implemented in the consensus client:</p> <ul> <li><code>VOTING_WINDOW_BEGIN</code>: the first block (inclusive) to count votes.</li> <li><code>VOTING_WINDOW_END</code>: the last block (inclusive) to count votes.</li> <li><code>REFERENCE_IMPLEMENTATION_HASH</code>: this is defined above.</li> <li><code>REQUIRED_APPROVALS</code>: the minimum number of approvals necessary for the upgrade.</li> </ul> <p>The difference (<code>VOTING_WINDOW_END</code> - <code>VOTING_WINDOW_BEGIN</code>) must be strictly greater than 14400 (about two days) and should be chosen to provide sufficient time to advertise the upgrade to network participants.</p> <p>The required approvals must be strictly greater than 50% of the blocks in the voting window. A higher threshold (such as 95% or more) is recommended.</p> <p>When the block numbered <code>VOTING_WINDOW_END</code> is created, the upgrade is considered "activated" if <code>REQUIRED_APPROVALS</code> or more blocks during the voting window had set <code>referenceImplementationHash</code> to the value <code>REFERENCE_IMPLEMENTATION_HASH</code>; otherwise, the upgrade fails.</p> <p>Blocks created from <code>VOTING_WINDOW_END</code> + 1 onward will use the new software behaviors if and only if the upgrade was successful.</p> <p>For proof-of-work networks and other scenarios, it is possible that one fork activates the upgrade while another does not. In any case, blocks strictly greater than <code>VOTING_WINDOW_END</code> shall be created according to the behaviors of the software considering the outcome of the votes in the voting window which are the ancestors of that block.</p> <p>Note: Just because an upgrade was activated, this does not necessarily mean that the new software behaviors must generate block <code>VOTING_WINDOW_END</code> + 1 differently than the old software behaviors. Perhaps the new software behaviors will stipulate that only blocks at some later time will generate differently. Perhaps the new software behaviors include some other consensus change which does not change how blocks are created.</p> <h2 id="rationale">Rationale</h2> <h3 id="forking-is-no-longer-possible">Forking is no Longer Possible</h3> <p>Since the merge, forking Ethereum Mainnet has become practically impossible. Validators stake valuable assets to participate in the network, so any rational validator will choose to upgrade only if they expect widespread adoption. If a validator expects 95% or more participants to upgrade, they should upgrade; if they expect only 5% or less, they should not. For intermediate cases, there is a threshold where a validator would rationally shut down (incurring a small penalty) rather than risk participating in the wrong network—which could result in slashing 100% of their staked ether (currently 16 Ether per share).</p> <p>Therefore, proper management of consensual upgrades is crucial.</p> <h3 id="community-direction">Community Direction</h3> <ol> <li>The Ethereum project and community do not have an official mission statement or vision. However, this proposal asserts that the Ethereum community would prefer Ethereum Mainnet to be a community-directed project.</li> <li>On-chain signaling of upgrades enables community direction in a way that is not possible today.</li> </ol> <h3 id="window">Window</h3> <p>Using a voting window to count votes provides real-time on-chain feedback about upgrade readiness. The upgrade is activated only after the successful completion of the voting window.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h3 id="trademark">Trademark</h3> <p>The Ethereum Foundation (Stiftung Ethereum), Zug, Switzerland, owns the trademark “Ethereum.” As a result, if anybody publishes a proposed Ethereum Mainnet consensus client, the foundation may have the right to restrict marketing of that software as an “Ethereum” client. That also poses unique risks related to securities rules.</p> <h3 id="eip-2124">EIP-2124</h3> <p>EIP-2124 introduces a mechanism to communicate software versions between nodes. However, it does not allow for signaling readiness before an upgrade, nor does it specify what software is being upgraded to.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Any upgrade that achieves less than 100% participation will harm validators who do not participate.</p> <ul> <li>Overlapping or competitive upgrades must be managed carefully; such scenarios could result in multiple networks achieving the minimum approval threshold.</li> <li>An upgrade with an excessively long time period could hinder/delay the proposal of subsequent upgrades.</li> <li>Since the four voting parameters are embedded in the reference implementation, network participants must exercise due diligence to ensure that they understand the actual software behaviors.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights have been waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-06T00:00:00+00:00 2026-02-11T14:49:28+00:00 Keyvan Kambakhshhttps://github.com/keyvank Nobitex Labslabs@nobitex.ir https://wg-eips.ritovision.com/7833/

Giving life to smart contracts by enabling their functions to be automatically invoked by block producers.

<h2 id="abstract">Abstract</h2> <p>Ethereum's smart contracts enable users to delegate control of their funds to code, but these contracts require an external trigger to execute. Timing is often critical, and issues such as network delays or malicious behavior by block producers—like MEV attacks—can prevent timely execution. To address these challenges, this Ethereum Improvement Proposal (EIP) introduces a new opcode, OFFERCALL, which allows contracts to schedule function calls. When functions self-schedule, they exhibit bot-like behavior. These scheduled calls would offer ETH to block producers as an incentive to prioritize their execution over manually submitted transactions. If the offer is not fulfilled, the bot is deactivated until manually re-ignited by the owner. The EIP proposes enforcing the execution of scheduled calls as a requirement for block validity. This could help mitigate MEV attacks, as block producers would be compelled to execute bots that neutralize market manipulation within the blockchain.</p> <h2 id="specification">Specification</h2> <p>Adding bot-like behavior to an EVM function is achieved by recursively scheduling a call to the same function in the next block. We propose introducing a new EVM opcode, OFFERCALL, which, as the name implies, offers ETH to be burnt to the block producer of the next block in exchange for invoking a function. These offers are aggregated and ranked by the Ethereum node, with only the top N offers being retained; all others are discarded. Scheduled calls must be executed before any user transactions, with execution order determined by their rank in the sorted list. The offered ETH is burnt to prevent block producers from exploiting the system by scheduling calls that pay the offered amounts back to themselves.</p> <p>Here is a solidity example of how the usage of OFFERCALL would look like:</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">contract</span><span class="z-entity z-name"> Bot</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint256</span><span> offerPerCall</span><span>;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-storage z-type"> constructor</span><span>(</span><span class="z-support">uint256</span><span class="z-variable z-parameter z-function"> _offer</span><span>)</span><span> {</span></span> <span class="giallo-l"><span> offerPerCall </span><span class="z-keyword">=</span><span> _offer</span><span>;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> Ignite the bot with an initial invocation offer</span></span> <span class="giallo-l"><span class="z-entity z-name"> offercall</span><span>(</span><span>update</span><span>,</span><span> offerPerCall</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> setOffer</span><span>(</span><span class="z-support">uint256</span><span class="z-variable z-parameter z-function"> _offer</span><span>)</span><span class="z-storage z-type"> external</span><span> {</span></span> <span class="giallo-l"><span> offerPerCall </span><span class="z-keyword">=</span><span> _offer</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> update</span><span>(</span><span>)</span><span class="z-storage z-type"> external</span><span> {</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> Do scheduled work</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> The callee may reschedule itself in order to</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> introduce a bot-like behavior.</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> The callee has to be careful about its offer</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> otherwise it may die.</span></span> <span class="giallo-l"><span class="z-entity z-name"> offercall</span><span>(</span><span>update</span><span>,</span><span> offerPerCall</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> Once an offercall fails, the contract owner</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> may have to set a new offer by calling `setOffer`</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> and then invoking the `update()` function again.</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>An OFFERCALL fails in two situations:</p> <ul> <li>The contract does not hold at least the offered amount of ETH.</li> <li>The offered amount is not large enough to rank within the top N offers.</li> </ul> <p>In the case of a self-scheduling function, once an OFFERCALL fails, the bot is deactivated. The only way to revive it is for the contract owner to manually call the function again, likely with a higher offer.</p> <h2 id="rationale">Rationale</h2> <p>The rationale behind this Ethereum Improvement Proposal (EIP) stems from the need to enhance the reliability and fairness of smart contract execution on the Ethereum network. While Ethereum’s smart contracts allow for a high degree of programmability and automation, the execution of these contracts often depends on external triggers, such as user transactions or network conditions. This dependency introduces significant challenges, particularly in situations where timing is critical or when malicious actors, like block producers, can exploit the system for profit.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The introduction of the new OFFERCALL opcode in this EIP requires a network upgrade, as it adds new functionality that is not currently supported by the Ethereum Virtual Machine (EVM). This change will affect how smart contracts can schedule and incentivize the execution of specific function calls, introducing a new mechanism that block producers must accommodate.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <p>The main concern with this EIP is whether it could lead to centralization, as wealthier users might dominate execution priorities. Burning unfulfilled offers partly addresses this by preventing endless offers.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Kaan Uzdoganhttps://github.com/kuzdogan Marco Castignolihttps://github.com/marcocastignoli Manuel Wedlerhttps://github.com/manuelwedler https://wg-eips.ritovision.com/7834/

Introduce a new separate metadata section to the EOF

<h2 id="abstract">Abstract</h2> <p>Introduce a new separate metadata section to the Ethereum Object Format (EOF) that is unreachable by the code, and any changes to which does not affect the code.</p> <h2 id="motivation">Motivation</h2> <p>It is desirable to include metadata in contract's bytecode for various reasons. For instance, both the Solidity and Vyper compilers by default include the language and compiler version used to compile. Vyper (with 0.4.1) appends an integrity hash to the initcode in CBOR encoding. Solidity additionally includes the IPFS or the Swarm hash of the Solidity contract metadata.json file, and the experimental Solidity flag. The current (pre-EOF) practice is to append this CBOR encoded metadata section in the contract's runtime bytecode, followed by the 2 bytes length of the CBOR encoded bytes.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> Solidity ┌──────────────────────────────────────────0x0033 bytes──────────────────────────────────────────────┐</span></span> <span class="giallo-l"><span>...7265206c656e677468a2646970667358221220dceca8706b29e917dacf25fceef95acac8d90d765ac926663ce4096195952b6164736f6c634300060b0033</span></span></code></pre> <p>This poses a problem for source code verification where the onchain bytecode is compared to the compiled bytecode of the given source code. During a contract verification, metadata sections, in particular the IPFS hash, need to be ignored and only the executional bytecode should be compared. Since pre-EOF bytecode is not structured, it is not possible to distinguish the metadata section from the executional bytecode easily. This gets even trickier in the case of factory contracts with multiple nested bytecodes, each having their own metadata sections. Verifiers need to implement their own heuristics and workarounds to find the metadata sections and ignore it.</p> <p>The EOF brings structure to the bytecode by separating the code from the data, and placing the code of each contract in their respective containers. In its current form, this makes it possible to find the data easier than the pre-EOF bytecode. However, the current spec also does not describe a metadata section. Compilers currently need to place the contract metadata inside the data section which poses several problems:</p> <ol> <li>It is not straightforward to distinguish the metadata part in the <code>data_section</code>, which poses the same problem as the pre-EOF bytecode.</li> <li>Any change to the metadata's size within the data section will change the executional bytecode, e.g. through shifting <code>DATALOADN</code> offsets. With that, two identical contracts with different metadata sizes will not match during source code, since the code will be different.</li> <li>The metadata can theoretically be reached by the code, e.g. via manipulating the <code>DATALOADN</code> instructions.</li> </ol> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Extending the format introduced in <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>, this EIP proposes to add a new OPTIONAL section in the body called <code>metadata_section</code> before the <code>data_section</code>, and to add two new OPTIONAL fields <code>kind_metadata</code> (value: <code>0x05</code>) and <code>metadata_size</code> to the header before the <code>kind_data</code> and <code>data_size</code> fields.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>container := header, body</span></span> <span class="giallo-l"><span>header :=</span></span> <span class="giallo-l"><span> magic, version,</span></span> <span class="giallo-l"><span> kind_type, type_size,</span></span> <span class="giallo-l"><span> kind_code, num_code_sections, code_size+,</span></span> <span class="giallo-l"><span> [kind_container, num_container_sections, container_size+,]</span></span> <span class="giallo-l"><span> [kind_metadata, metadata_size,]</span></span> <span class="giallo-l"><span> kind_data, data_size,</span></span> <span class="giallo-l"><span> terminator</span></span> <span class="giallo-l"><span>body := types_section, code_section+, container_section*, [metadata_section], data_section</span></span> <span class="giallo-l"><span>types_section := (inputs, outputs, max_stack_increase)+</span></span></code></pre><h3 id="header">Header</h3> <table><thead><tr><th>name</th><th>length</th><th>value</th><th>description</th></tr></thead><tbody> <tr><td>...</td><td>...</td><td>...</td><td>...</td></tr> <tr><td>kind_metadata</td><td>1 byte</td><td>0x05</td><td>kind marker for metadata size section</td></tr> <tr><td>metadata_size</td><td>2 bytes</td><td>0x0001-0xFFFF</td><td>16-bit unsigned big-endian integer denoting the length of the metadata section content</td></tr> <tr><td>kind_data</td><td>1 byte</td><td>0xff</td><td>kind marker for data size section</td></tr> <tr><td>data_size</td><td>2 bytes</td><td>0x0000-0xFFFF</td><td>16-bit unsigned big-endian integer denoting the length of the data section content (*)</td></tr> <tr><td>terminator</td><td>1 byte</td><td>0x00</td><td>marks the end of the header</td></tr> </tbody></table> <h3 id="body">Body</h3> <table><thead><tr><th>name</th><th>length</th><th>value</th><th>description</th></tr></thead><tbody> <tr><td>...</td><td>...</td><td>...</td><td>...</td></tr> <tr><td>metadata_section</td><td>variable</td><td>n/a</td><td>arbitrary sequence of bytes</td></tr> <tr><td>data_section</td><td>variable</td><td>n/a</td><td>arbitrary sequence of bytes</td></tr> </tbody></table> <p>The structure and the encoding of the <code>metadata_section</code> is not defined by this EIP. It is left to the compilers, tooling, or the contract developers to define the encoding and the content. The current practice by the Solidity and Vyper compilers is to use CBOR encoding.</p> <h2 id="rationale">Rationale</h2> <p>The <code>metadata_section</code> in the <code>body</code>, as well as the <code>kind_metadata</code> and <code>metadata_size</code> fields in the <code>header</code>, are OPTIONAL. This way, the compilers can avoid additional bytes in the container if they don't want to write any metadata. The <code>data_section</code> can change in its size and content during deployment, therefore it needs to be REQUIRED, even if the data is empty. The <code>metadata_section</code> is not expected to change during the deployment.</p> <p>The reason for placing the <code>metadata_section</code> before the <code>data_section</code>, and assigning <code>kind_metadata</code> the value <code>0x05</code> (and not <code>0x04</code>) is to make it easier for the existing EOF tooling adapt the changes. Additionally, if the <code>metadata_section</code> was placed after the <code>data_section</code>, changes to the <code>data_section</code> in deploy time would cause the <code>metadata_section</code> to shift. By placing the <code>metadata_section</code> before, this could be mitigated.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues are expected since <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is not implemented yet.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security considerations as this section is meant not to be executed.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-12-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Marc Harvey-Hillhttps://github.com/Marchhill https://wg-eips.ritovision.com/7843/

Opcode to get the current slot number

<h2 id="abstract">Abstract</h2> <p>This EIP proposes to add a new opcode <code>SLOTNUM</code> (<code>0x4b</code>), that returns the corresponding slot number for the current block.</p> <h2 id="motivation">Motivation</h2> <p>There are currently two ways to get the current slot number onchain:</p> <ol> <li> <p>Calculate from the block timestamp. This requires hardcoding the chain slot length into a smart contract.</p> </li> <li> <p>Provide the slot number as calldata and prove it against the beacon block root (using <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a>).</p> </li> </ol> <p>Both of these approaches have significant drawbacks. (1) would break contracts in the event of a change to the slot length. (2) is expensive in terms of gas, encouraging approach (1) to be used instead.</p> <p>A better approach is for the slot length to be abstracted away from applications, and instead the slot number can be calculated in the consensus layer client and exposed by an opcode. This paves the way for future changes to the slot length.</p> <h2 id="specification">Specification</h2> <p>A new opcode <code>SLOTNUM</code> is introduced at <code>0x4b</code>. It shall return one stack element.</p> <h3 id="output">Output</h3> <p>One element <code>slotNumber</code> is added to the stack; it is equal to the corresponding slot number for this block. <code>slotNumber</code> is a <code>uint64</code> in big endian encoding.</p> <h3 id="gas-cost">Gas Cost</h3> <p>The gas cost for <code>SLOTNUM</code> is a fixed fee of <code>2</code>.</p> <h3 id="rpc-changes">RPC changes</h3> <p>The slot number is calculated in the consensus layer and passed to the execution layer through the engine API.</p> <h4 id="header-extension">Header extension</h4> <p>The header encoding shall be extended to include a <code>slotNumber</code> field of type <code>uint64</code>.</p> <h4 id="engine-api-changes">Engine API changes</h4> <p>New objects <code>ExecutionPayloadV4</code> and <code>PayloadAttributesV4</code> are introduced, adding a <code>slotNumber</code> field of type <code>uint64</code>. The methods <code>engine_newPayloadV4</code>, <code>engine_getPayloadV6</code>, and <code>engine_forkChoiceUpdateV4</code> are added, to use the new objects.</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-price">Gas Price</h3> <p>The opcode is priced to match similar opcodes in the <code>W_base</code> set.</p> <h3 id="calculation-in-consensus-layer">Calculation in consensus layer</h3> <p>The slot number could alternatively be calculated in the execution layer using the timestamp, but it is more appropriate to calculate values pertaining to the beacon chain in the consensus layer. Additionally this avoids code duplication, as the slot number is already calculated in the consensus layer.</p> <h3 id="zk-vm-proving">ZK-VM proving</h3> <p>The <code>SLOTNUM</code> opcode should not increase the complexity of proving EVM execution, as it is similar to existing opcodes such as <code>TIMESTAMP</code>. The slot number is included in the block header rather than as a <code>engine_newPayload</code> parameter, ensuring that the block is self-contained for proving; no extra inputs to the circuit are required.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-11-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7830/

Raise the limit for only EOF contracts to 64 KiB

<h2 id="abstract">Abstract</h2> <p>Revise the contract size limit for EOF contracts to be 64 KiB instead of the existing 24 KiB limit. Legacy contracts are unaffected.</p> <h2 id="motivation">Motivation</h2> <p>The contract size limit was introduced as a measure against DoS attacks. <code>JUMPDEST</code>-analysis is required for legacy contracts, and many of the algorithms performing it are not linear and/or have unknown unknowns. This is one of the reasons for the hesitance of a limit increase.</p> <p>For contract developers the limit poses annoying problems, given modern contracts with good error reporting would consume more space. They are forced to work with workarounds, like "libraries" (using <code>DELEGATECALL</code>), splitting an application across regular contracts (and <code>CALL</code>-ing across), or working with proxies (e.g. the "diamond pattern"). All these solutions have resulted in suboptimal patterns, bugs in deployed contracts, and loss of funds.</p> <p>With EOF the <code>JUMPDEST</code>-analysis is removed from runtime and a validation process is performed once during deployment. The initcode cost <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> introduced accounts for this validation too. Therefore, with EOF there are no known problems for increasing the limit, because the overheads are already accounted for.</p> <p>Storage cost is already paid per contract byte.</p> <h2 id="specification">Specification</h2> <p><a href="https://wg-eips.ritovision.com/170/">EIP-170</a> specifies <code>MAX_CODE_SIZE</code> as 24576 bytes, and <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> specifies <code>MAX_INITCODE_SIZE</code> as <code>2 * MAX_CODE_SIZE</code> (49152 bytes).</p> <p>Starting <code>FORK_BLOCK</code>, for EOF initcode/code (code starting with the <code>0xEF 0x00</code> bytes) the limit is changed:<code>MAX_CODE_SIZE</code> is set to 65536 bytes (64 KiB). This means <code>MAX_INITCODE_SIZE</code> becomes 131072 bytes (128 KiB).</p> <h2 id="rationale">Rationale</h2> <p>The 64 KiB limit is over 2x of existing limit, while it is not a significant increase, it is the realistic increase given the limitations of initcode. In EOF deployment the to-be-deployed code is stored as a section ("subcontainer"), which has a size limit of 64 KiB, therefore it is not possible to deploy larger contracts without introducing a large or variable-length-encoded size field.</p> <p>A further increase can be proposed with applying these changes to EOF.</p> <p>This increase still fits within the gas schedule, limiting the size to less than what gas limits allow. In <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> the gas limit was first set "by setting the cap at a value slightly higher than what is feasible with current gas limits." At that time the gas limit had not exceeded 5M gas.</p> <p>A simple analysis shows contract deployments for 64 KiB contracts to be between 14M and 16M gas, roughly close to the current 15M target.</p> <table><thead><tr><th></th><th style="text-align: right">Cancun</th><th style="text-align: right">This EIP</th><th style="text-align: right">36M Gas</th><th style="text-align: right">Max Initcode</th></tr></thead><tbody> <tr><td><strong>Initcode bytes</strong></td><td style="text-align: right">200</td><td style="text-align: right">200</td><td style="text-align: right">200</td><td style="text-align: right">65,536</td></tr> <tr><td><strong>Deployed Bytes</strong></td><td style="text-align: right">24,576</td><td style="text-align: right">65,536</td><td style="text-align: right">165,331</td><td style="text-align: right">65,536</td></tr> <tr><td><strong>Zero byte ratio</strong></td><td style="text-align: right">10%</td><td style="text-align: right">10%</td><td style="text-align: right">10%</td><td style="text-align: right">10%</td></tr> <tr><td><strong>Initcode Cost</strong></td><td style="text-align: right">4/16</td><td style="text-align: right">4/16</td><td style="text-align: right">4/16</td><td style="text-align: right">4/16</td></tr> <tr><td></td><td style="text-align: right"></td><td style="text-align: right"></td><td style="text-align: right"></td><td style="text-align: right"></td></tr> <tr><td><strong>Intrinsic Gas</strong></td><td style="text-align: right">53,000</td><td style="text-align: right">53,000</td><td style="text-align: right">53,000</td><td style="text-align: right">53,000</td></tr> <tr><td><strong>Calldata Gas</strong></td><td style="text-align: right">366,685</td><td style="text-align: right">972,893</td><td style="text-align: right">2,449,859</td><td style="text-align: right">1,939,866</td></tr> <tr><td><strong>EIP-3860 Gas</strong></td><td style="text-align: right">49,552</td><td style="text-align: right">131,472</td><td style="text-align: right">331,062</td><td style="text-align: right">262,144</td></tr> <tr><td><strong>EVM Execution</strong></td><td style="text-align: right">100,000</td><td style="text-align: right">100,000</td><td style="text-align: right">100,000</td><td style="text-align: right">100,000</td></tr> <tr><td><strong>Code Deposit</strong></td><td style="text-align: right">4,915,200</td><td style="text-align: right">13,107,200</td><td style="text-align: right">33,066,200</td><td style="text-align: right">13,107,200</td></tr> <tr><td></td><td style="text-align: right"></td><td style="text-align: right"></td><td style="text-align: right"></td><td style="text-align: right"></td></tr> <tr><td><strong>Total Cost</strong></td><td style="text-align: right">5,484,437</td><td style="text-align: right">14,364,565</td><td style="text-align: right">36,000,121</td><td style="text-align: right">15,462,210</td></tr> </tbody></table> <p>Note that the Max 30M gas contract size of 135 KiB is outside the limits of what is proposed in this EIP and is included to show what it would take to exceed current gas limits.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards compatible change. Existing contracts are unaffected, and only new deployments see the effect.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Given the analysis cost is paid as part of deployment, the size of contract should have no effect on the runtime.</p> <p>A more thorough analysis may be needed to determine whether the proposed limit poses any risk because of client storage architectures.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-11-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Giulio Rebuffohttps://github.com/Giulio2002 Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7825/

Introduce a protocol-level cap on the maximum gas used by a transaction to 16,777,216 (2^24).

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a protocol-level cap on the maximum gas usage per transaction to 16,777,216 (2^24) gas. By implementing this limit, Ethereum can enhance its resilience against certain DoS vectors, improve network stability, and provide more predictability to transaction processing costs, especially in the context of increasing the gas limit.</p> <h2 id="motivation">Motivation</h2> <p>Currently, transactions can theoretically consume up to the entire block gas limit, which poses several risks:</p> <ol> <li><strong>DoS Attacks</strong>: A single transaction consuming most or all of the block gas can result in uneven load distribution and impact network stability.</li> <li><strong>State Bloat Risks</strong>: High-gas transactions often result in larger state changes, increasing the burden on nodes and exacerbating the Ethereum state growth problem.</li> <li><strong>Validation Overhead</strong>: High-gas transactions can lead to longer block verification times, negatively impacting user experience and network decentralization.</li> </ol> <p>By limiting individual transactions to a maximum of 16,777,216 gas, we aim to:</p> <ul> <li>Reduce the risks of single-transaction DoS attacks.</li> <li>Promote fairer gas allocation across transactions within a block.</li> <li>Ensure better synchronization among nodes by mitigating extreme block validation times.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="gas-cap">Gas Cap</h3> <ul> <li>Enforce a protocol-level maximum of <strong>16,777,216 gas (2^24)</strong> for any single transaction.</li> <li>This cap applies regardless of the block gas limit set by miners or validators.</li> <li>Transactions specifying gas limits higher than 16,777,216 gas will be rejected with an appropriate error code (e.g., <code>MAX_GAS_LIMIT_EXCEEDED</code>).</li> </ul> <h3 id="changes-to-evm-behavior">Changes to EVM Behavior</h3> <ol> <li><strong>Txpool Validation</strong>: During transaction validation, if the <code>gasLimit</code> specified by the sender exceeds 16,777,216, the transaction is invalidated (not included in the txpool).</li> <li><strong>Block Validation</strong>: As part of block validation before processing, any block having a transaction with <code>gasLimit</code> &gt; 16,777,216 is deemed invalid and rejected.</li> </ol> <h3 id="protocol-adjustment">Protocol Adjustment</h3> <ul> <li>The <code>GAS_LIMIT</code> parameter for transactions will be capped in client implementations at 16,777,216.</li> <li>This cap is <strong>independent</strong> of the block gas limit, which exceeds this value.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-16-777-216-2-24">Why 16,777,216 (2^24)?</h3> <p>The proposed cap of 16,777,216 gas (2^24) provides a clean power-of-two boundary that simplifies implementation while still being large enough to accommodate most complex transactions, including contract deployments and advanced DeFi interactions. This value represents approximately half of typical block sizes (30-40 million gas), ensuring multiple transactions can fit within each block.</p> <h3 id="compatibility-with-current-gas-dynamics">Compatibility with Current Gas Dynamics</h3> <ul> <li><strong>Backward Compatibility</strong>: Transactions with gas usage below 16,777,216 remain unaffected. Existing tooling and dApps need only minor updates to enforce the new cap.</li> <li><strong>Impact on Validators</strong>: Validators can continue to process blocks with a gas limit exceeding 16,777,216, provided individual transactions adhere to the cap.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is <strong>not backward-compatible</strong> with transactions that specify gas limits exceeding 16,777,216. Transactions with such high limits will need to be split into smaller operations. This adjustment is expected to impact a minimal number of users and dApps, as most transactions today fall well below the proposed cap.</p> <p>An <a href="https://wg-eips.ritovision.com/7825/assets/analysis/">empirical analysis</a> has been conducted to assess the potential impact of this change.</p> <h2 id="security-considerations">Security Considerations</h2> <ol> <li><strong>DoS Mitigation</strong>: A fixed cap reduces the risk of DoS attacks caused by excessively high-gas transactions.</li> <li><strong>Block Verification Stability</strong>: By capping individual transactions, the validation of blocks becomes more predictable and uniform.</li> <li><strong>Edge Cases</strong>: Certain highly complex transactions, such as large contract deployments, may require re-architecting to fit within the 16,777,216 gas cap.</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-11-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Hadrien Crouboishttps://github.com/amxx https://wg-eips.ritovision.com/7819/

Introduce a new instruction allowing contracts to create clones using EIP-7702 delegation designations

<h2 id="abstract">Abstract</h2> <p>Introduce a new instruction that allows smart contracts to create (and update) delegation accounts that match <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>'s design. These accounts can be used similarly to <a href="https://wg-eips.ritovision.com/1167/">ERC-1167</a> clones, with significant advantages.</p> <h2 id="motivation">Motivation</h2> <p>Many on-chain applications involve creating multiple instances of the same code at different locations. These applications often rely on clones, or proxies, to reduce deployment costs.</p> <p>Clones, such as the one described in ERC-1167 are minimal pieces of code that contain the target address directly in the code. That makes them extremely light but prevents any form of reconfiguration (upgradability).</p> <p>Upgradeable proxies differ from clones in that they read the implementation's address from storage. This makes them more versatile but also more expensive to use.</p> <p>In both cases delegating the received calls to an implementation using EVM code comes with some downsides:</p> <ul> <li>Calldata must be copied to memory before performing the delegate call</li> <li>If EOF is enabled, clones and proxy written in EOF do not support delegation to an implementation written in legacy EVM code, and are thus limited or possibly dangerous. This encourages the continued use of legacy EVM code.</li> </ul> <p>EIP-7702 introduces a new type of object that has the expected behavior: delegation indicator. These objects are designed to be instantiated at the address of EOA's, but the same behavior could be re-used to implement clones at the protocol level. Using delegation indicators for this use-case provides upgradeability without the need for storage lookups if the contract calling the <code>SETDELEGATE</code> allows it. It also removes any issue related to code version incompatibilities.</p> <h3 id="account-abstraction">Account abstraction</h3> <p>Smart accounts, as in contracts that are "owned" by one or multiple keys and are intended to replace EOAs, are often deployed using clones or proxies that point to a singleton implementation. This forces a choice between having an upgradeable or a non-upgradeable design. Both designs come with downsides. Non-upgradeable design can leave you stranded with a buggy (or limited) account code. Upgradeable design comes with costs associated with fetching the implementation address.</p> <p>The <code>SETDELEGATE</code> instruction would enable new factories to implement an upgradeable design without the added cost of the lookup. Factories could also deploy non-upgradeable variants, or even selectively disable the upgradeability of some accounts. Both the upgrade mechanism and the selective locking would be handled at the factory level, which removes the burden of implementing the upgrade logic into the account itself.</p> <p>Additionally, using EIP-7702 delegations instead of clones/proxies moves the call redirection logic from the userspace to the protocol. This means fewer EVM operations, and thus a reduced gas consumption of every operation that calls these contracts. This includes the verification of signatures and the execution of user operations, but also transfers of assets that include a callback, such as <a href="https://wg-eips.ritovision.com/721/">ERC-721</a> and <a href="https://wg-eips.ritovision.com/1155/">ERC-1155</a> tokens.</p> <h3 id="scalability">Scalability</h3> <p>Clones and proxy contracts are present in large numbers in the blockchain state. OpenZeppelin's <a href="https://wg-eips.ritovision.com/1967/">ERC-1967</a> proxies are ~708 bytes. Using EIP-7702 delegations that are only 23 bytes would reduce blockchain state usage.</p> <p>Additionally, clones and proxy contracts have to handle the redirection of the call in the userspace, which includes execution cost. Using EIP-7702 delegations, which would move the redirection to the protocol level, would reduce the gas cost of all operations that target. This means more gas / blockspace is available for the actual execution of the contracts.</p> <h2 id="specification">Specification</h2> <p>A new instruction (<code>SETDELEGATE</code>) is added at <code>0xf6</code>.</p> <h3 id="behavior">Behavior</h3> <p>Executing this instruction does the following:</p> <ol> <li>deduct <code>EMPTY_ACCOUNT_COST</code> gas</li> <li>halt if the current frame is in <code>static-mode</code></li> <li>pop <code>salt</code>, <code>target</code> from the operand stack</li> <li>calculate <code>location</code> as <code>keccak256(DESIGNATOR ++ address ++ salt)[12:]</code></li> <li>add <code>location</code> to <code>accessed_addresses</code>, as defined in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></li> <li>halt if the code at <code>location</code> is not empty and does not start with <code>0xEF0100</code> (no empty and not a delegation indicator)</li> <li>add <code>EMPTY_ACCOUNT_COST - BASE_COST</code> gas to the global refund counter if <code>location</code> exists in the trie</li> <li>set the code of <code>location</code> to be <code>DESIGNATOR ++ target</code>, matching the delegation process defined in EIP-7702 <ul> <li>Similarly to EIP-7702, if <code>target</code> is <code>0x0</code> do not write the designation. Clear the code at <code>location</code> and reset the <code>location</code>'s code hash to the empty hash <code>0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code>.</li> </ul> </li> <li>if the nonce of the account at <code>location</code> is 0, increment it to 1</li> <li>push <code>location</code> onto the stack</li> </ol> <p>On step 8, <code>target</code> MUST be exactly 20 bytes. If the value retrieved from the stack is smaller than 20 bytes, it MUST be left fill (big-endian notation) with zeros. If it is bigger than 20 bytes, it must be trimmed of the highest bytes. The code placed at <code>location</code> MUST be exactly 23 bytes long, following EIP-7702.</p> <p>The delegation indicator created at <code>location</code> behaves identically to those created by EIP-7702.</p> <p>Note: The delegation is effective immediately upon the completion of the operation. Calls to the address as soon as the next operation will execute the newly delegated code.</p> <p>The delegation indicators created by the <code>SETDELEGATE</code> opcode are the same objects as the one created using EIP-7702. Therefore, all the behavior specificities documented in EIP-7702 (<code>CODESIZE</code>, <code>CODECOPY</code>, targeting precompile, or chaining delegation indicator) also apply here. Any future EIP that modify the behavior of EIP-7702 delegation indicators should also apply to the delegation indicators created using <code>SETDELEGATE</code>. They are not contracts, and cannot be deleted using <code>SELFDESTRUCT</code>, even if the <code>SELFDESTRUCT</code> appens in the same transaction that created the account at <code>location</code>. Destruction of the delegations SHOULD only be possible by the same caller (that created them) doing a new <code>SETDELEGATE</code> call with the same salt and a zero target.</p> <p>Step 9 ensures that an account that was created using <code>SETDELEGATE</code> never returns to an empty state (forbiden by <a href="https://wg-eips.ritovision.com/7523/">EIP-7523</a>). Even if the balance is zero, no state was ever set, and the code is removed by a <code>SETDELEGATE</code> operation (with zero target), then the nonce being (at least) one would guarantee the account is not empty.</p> <h3 id="parameters">Parameters</h3> <p>These parameters are the same ones as used in EIP-7702.</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>DESIGNATOR</code></td><td>0xef0100</td></tr> <tr><td><code>EMPTY_ACCOUNT_COST</code></td><td>25000</td></tr> <tr><td><code>BASE_COST</code></td><td>12500</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <h3 id="gas-cost">Gas cost</h3> <p>The execution of the <code>SETDELEGATE</code> instruction involves fewer moving pieces than what EIP-7702 gas costs account for:</p> <ul> <li>there is no signature recovery</li> <li>there is no dedicated calldata that must be accounted for that is not already paid for at the transaction level</li> <li>there is no nonce update</li> </ul> <p>Therefore, the cost of executing this instruction could be lower than EIP-7702. Numbers from EIP-7702 are reused for simplicity. They are lower than <code>CREATE</code> or <code>CREATE2</code> operations, making the use of this instruction competitive for the intended use-cases.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h3 id="address-collision">Address collision</h3> <p>The derivation of the <code>location</code> is designed not to conflict with contracts created using the <code>CREATE</code> or <code>CREATE2</code> opcodes. In particular, the pre-images used to hash the produced address have different lengths, preventing any collision:</p> <p>Contracts deployed using <code>CREATE2</code> have an address that is derived from a 85 bytes long pre-image, as opposed to 55 bytes for <code>SET_DELEGATE</code>. This observation alone remove the risk of pre-image collision.</p> <p>Contracts deployed using <code>CREATE</code> have an address that is derived from the <code>RLP([address, nonce])</code>. For this pre-image to have a length 55 (like <code>SET_DELEGATE</code>), <code>nonce</code> must be 32 bytes long. In that case, the <code>RLP([address, nonce])</code> would be <code>0xf694&lt;address&gt;a0&lt;nonce&gt;</code> and would thus not start with the magic value used by <code>SETDELEGATE</code>. A smaller nonce could lead to the pre-image starting with <code>0xef</code>, but in that case the pre-image would be smaller than 55 bytes. Even in that case, the pre-image would start with <code>0xef94</code>, <code>0x94</code> encoding the <code>address</code> object (that is 20 bytes long).</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="delegator-upgrades-deletion">Delegator upgrades &amp; deletion</h3> <p>Reusing EIP-7702 behavior, including clearing the code if the target is 0, results in the ability to upgrade or even "remove" the created designator. This process is controlled (and can be restricted) by the factory (the contract that calls <code>SETDELEGATE</code>). Some factories will add checks that prevent re-executing <code>SETDELEGATE</code> with a salt that was already used, making the create designator immutable. Others may allow access-restricted upgrades, but prevent deletion. In any case, guarantees about the lifecycle of the designator created using <code>SETDELEGATE</code> are provided by the contracts that call it and not by the protocol.</p> <h3 id="delegator-chaining">Delegator chaining</h3> <p>As documented in EIP-7702, designator chains or loops are not resolved. This means that, unlike clones, chaining is an issue. This is however something developers are used to, as chaining proxy can result in strange behaviors, including infinite delegation loops.</p> <p>Factories may want to protect against this risk by verifying that the <code>target</code> doesn't contain a designator. This can be achieved using a legacy contract helper that has access to <code>EXTCODEHASH</code>. It could also be done using other forms of introspection such as an <code>ACCOUNT_TYPE</code> instruction.</p> <h3 id="front-running-initialization">Front running initialization</h3> <p>Unlike EIP-7702 signature, which can be included in any transaction, and can thus lead to initialization front-running if the implementation doesn't check the authenticity of the initialization parameters, <code>CREATE_DELEGATE</code> is executed by a smart contract that can execute the initialization logic atomically, just after the delegation is created. This process is well-known to developers that initialize clones and proxies just after creation.</p> <h3 id="multiple-delegation-changes-within-a-single-transaction">Multiple delegation changes within a single transaction.</h3> <p>If a contract performs multiple <code>SETDELEGATE</code> operations with the same salt but different targets within the same transaction, while doing calls corresponding address, this would have, in the same transaction without reverts, an address that has multiple different codes associated with it, two or more of which are executed. This include the delegation being removed/reset any number of time during the transaction.</p> <p>This behavior, is already possible with more traditional upgradeable contracts, where change of target are caused by a specific storage slot being modified.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-11-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Radoslaw Zagorowiczhttps://github.com/rodiazet https://wg-eips.ritovision.com/7823/

Each input field is restricted to a maximum of 8192 bits

<h2 id="abstract">Abstract</h2> <p>Introduce an upper bound on the inputs of the MODEXP precompile. This can reduce the number of potential bugs, because the testing surface is not infinite anymore, and makes it easier to be replaced using EVMMAX.</p> <h2 id="motivation">Motivation</h2> <p>The MODEXP precompile has been a source of numerous consensus bugs. Many of them were due to specifically crafted cases using impractical input lengths.</p> <p>Its pricing function is also quite complex given its nature of unbounded inputs. While we don't suggest to rework the pricing function, it may be possible in a future upgrade once the limits are in place.</p> <p>Furthermore this limitation makes it more feasible to have the precompile replaced with EVM code through features like EVMMAX.</p> <h2 id="specification">Specification</h2> <p>Recap from <a href="https://wg-eips.ritovision.com/198/">EIP-198</a>:</p> <blockquote> <p>At address <code>0x00……05</code>, add a precompile that expects input in the following format:</p> <p><code>&lt;length_of_BASE&gt; &lt;length_of_EXPONENT&gt; &lt;length_of_MODULUS&gt; &lt;BASE&gt; &lt;EXPONENT&gt; &lt;MODULUS&gt;</code></p> </blockquote> <p>We introduce an upper bound to the inputs of the precompile, each of the length inputs (<code>length_of_BASE</code>, <code>length_of_EXPONENT</code> and <code>length_of_MODULUS</code>) MUST be less than or equal to 8192 bits (1024 bytes).</p> <p>If any of these inputs are larger than the limit, the precompile execution stops, returns an error, and consumes all gas.</p> <h2 id="rationale">Rationale</h2> <h3 id="limit">Limit</h3> <p>This upper bound allows the existing use cases of MODEXP:</p> <ol> <li>RSA verification with up to 8192 bit keys. Commonly used ones are 1024/2048/4096 bits.</li> <li>Elliptic curve related use cases are usually less than 384 bits.</li> </ol> <h3 id="evmmax">EVMMAX</h3> <p>Replacing the precompile with EVM code using an instruction set like EVMMAX would be made simpler with this limit: Common cases (256, 381, 1024, 2048) could be implemented in special fast paths, while a slow fallback could be provided for the rest. Or even special, frequently used, moduli could have their own paths.</p> <p>Furthermore one could consider limiting the lengths to certain inputs only.</p> <h3 id="analysis">Analysis</h3> <p>Since MODEXP was introduced in the Byzantium hard fork, an analysis has been conducted between block 5472266 (April 20, 2018) and block 21550926 (January 4th, 2025). All lengths of inputs are expressed in bytes.</p> <h4 id="base-length-occurrences">Base length occurrences</h4> <table><thead><tr><th><code>input_of_BASE</code></th><th>count</th></tr></thead><tbody> <tr><td>32</td><td>2439595</td></tr> <tr><td>128</td><td>4167</td></tr> <tr><td>256</td><td>2969</td></tr> <tr><td>160</td><td>436</td></tr> <tr><td>512</td><td>36</td></tr> <tr><td>0</td><td>13</td></tr> <tr><td>64</td><td>7</td></tr> <tr><td>78</td><td>2</td></tr> <tr><td>513</td><td>2</td></tr> <tr><td>129</td><td>1</td></tr> <tr><td>385</td><td>1</td></tr> </tbody></table> <h4 id="exponent-length-occurrences">Exponent length occurrences</h4> <table><thead><tr><th><code>input_of_EXPONENT</code></th><th>count</th></tr></thead><tbody> <tr><td>32</td><td>2442255</td></tr> <tr><td>3</td><td>4771</td></tr> <tr><td>1</td><td>159</td></tr> <tr><td>128</td><td>29</td></tr> <tr><td>0</td><td>13</td></tr> <tr><td>5</td><td>2</td></tr> </tbody></table> <h4 id="modulo-length-occurrences">Modulo length occurrences</h4> <table><thead><tr><th><code>input_of_MODULUS</code></th><th>count</th></tr></thead><tbody> <tr><td>32</td><td>2439594</td></tr> <tr><td>128</td><td>4167</td></tr> <tr><td>256</td><td>2968</td></tr> <tr><td>160</td><td>436</td></tr> <tr><td>512</td><td>38</td></tr> <tr><td>0</td><td>13</td></tr> <tr><td>64</td><td>8</td></tr> <tr><td>78</td><td>2</td></tr> <tr><td>129</td><td>1</td></tr> <tr><td>384</td><td>1</td></tr> <tr><td>257</td><td>1</td></tr> </tbody></table> <p>This shows that no past successful use case exceeded an input length of 513 bytes, and the majority uses 32/128/256 byte inputs.</p> <p>Besides these, there were a few invocations with invalid inputs:</p> <ul> <li>Empty inputs</li> <li>Inputs consisting of only <code>0x9e5faafc</code> or <code>0x85474728</code></li> <li>A large, but invalid input: <code>0x9e281a98000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021e19e0c9bab2400000</code></li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible change. However, based on analysis until block 21550926 (see above), no past transaction would have behaved differently after this change.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Since only the accepted input range is reduced, no new security surface area is expected.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-11-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Thomas Thieryhttps://github.com/soispokethomas.thiery@ethereum.org Francesco D'Amatofrancesco.damato@ethereum.org Julian Majulian.ma@ethereum.org Barnabé Monnotbarnabe.monnot@ethereum.org Terence Tsaottsao@offchainlabs.com Jacob Kaufmannjacob.kaufmann@ethereum.org Jihoon Songjihoon.song@ethereum.org https://wg-eips.ritovision.com/7805/

Allow a committee of validators to force-include a set of transactions in every block

<h2 id="abstract">Abstract</h2> <p>FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion.</p> <p>FOCIL (<strong>Fo</strong>rk-<strong>c</strong>hoice enforced <strong>I</strong>nclusion <strong>L</strong>ists) is built in a few simple steps:</p> <ul> <li>In each slot, a set of validators is selected as inclusion list (IL) committee members. Each member builds and gossips one IL according to their subjective view of the mempool.</li> <li>The proposer and all attesters of the next slot monitor, store and forward available ILs.</li> <li>The proposer (or the builder if the block is not built locally by the proposer) includes transactions from all collected ILs in its block. The proposer then broadcasts the block including IL transactions to the rest of the network.</li> <li>Attesters only vote for the proposer's block if it includes transactions from all stored ILs.</li> </ul> <h2 id="motivation">Motivation</h2> <p>In an effort to shield the Ethereum validator set from centralizing forces, the right to build blocks has been auctioned off to specialized entities known as <em>builders</em>. This has led to a few sophisticated builders dominating block production, leading to a deterioration of the network’s censorship resistance properties. To address this issue, research has focused on improving Ethereum's transaction inclusion guarantees by enabling validators to impose constraints on builders. This is achieved by force-including transactions in blocks via ILs.</p> <h3 id="high-level-overview">High-level Overview</h3> <p>FOCIL is a committee-based, fork-choice enforced inclusion list (IL) design that improves upon previous IL mechanisms and block co-creation proposals. It addresses issues related to bribing/extortion attacks, IL equivocation, account abstraction (AA), and transaction invalidation.</p> <p><img src="https://wg-eips.ritovision.com/7805/./assets/diagram_FOCIL.png" alt="FOCIL diagram" /></p> <h3 id="roles-and-participants">Roles And Participants</h3> <p>This section outlines the workflow of FOCIL, detailing the roles and responsibilities of various participants: IL committee members, validators, builders, proposers and attesters.</p> <h4 id="il-committee-members">IL Committee Members</h4> <ul> <li><strong><code>Slot N</code>, <code>t=0 to 8s</code></strong>: IL committee members construct their ILs by including transactions pending in the public mempool, and broadcast them over the P2P network after processing the block for <code>slot N</code> and confirming it as the head. If no block is received by <code>t=7s</code>, they should run <code>get_head</code> and build and release their ILs based on the node’s local head.</li> </ul> <p>IL committee members may follow different strategies for constructing their ILs as discussed in <a href="https://wg-eips.ritovision.com/7805/#il-building">IL Building</a>.</p> <h4 id="validators">Validators</h4> <ul> <li> <p><strong><code>Slot N</code>, <code>t=0s to 9s</code></strong>: Validators receive ILs from the P2P network and store (1) all new ILs that pass the CL P2P validation rules, and (2) any evidence of IL equivocation by committee members (i.e., if multiple ILs are received from the same committee member).</p> </li> <li> <p><strong><code>Slot N</code>, <code>t=9s</code> to <code>Slot N+1</code>, <code>t=4s</code></strong>: After the view freeze deadline at <code>t=9s</code>, validators:</p> <ol> <li>Do not store new ILs received after the deadline.</li> <li>Continue forwarding ILs to peers following the CL P2P validation rules.</li> <li>Record any evidence of IL equivocation that occurs after the view freeze deadline.</li> </ol> </li> </ul> <p>After the attestation deadline of <strong><code>Slot N+1</code>, <code>t=4s</code></strong>, validators ignore any new ILs related to the previous slot's IL committee, and stop recording equivocation evidence for the previous slot's ILs.</p> <h4 id="builder">Builder</h4> <ul> <li> <p><strong><code>Slot N</code>, <code>t=0s to 11s</code></strong>: The builder (i.e., a proposer doing local block building or an external builder) receives ILs from the P2P network, forwarding and caching those that pass the CL P2P validation rules. Optionally, an RPC endpoint can be added to allow the builder to request missing ILs from its peers (e.g., by committee index at <code>t=10s</code>).</p> </li> <li> <p><strong><code>Slot N</code>, <code>t=11s</code></strong>: The builder freezes its view of ILs and asks the EL to update its execution payload by adding transactions from its view (the exact timings will be defined after running some tests/benchmarks).</p> </li> </ul> <h4 id="proposer">Proposer</h4> <ul> <li><strong><code>Slot N+1</code>, <code>t=0s</code></strong>: The proposer broadcasts its block with the up-to-date execution payload satisfying IL transactions over the P2P network.</li> </ul> <h4 id="attesters">Attesters</h4> <ul> <li><strong><code>Slot N+1</code>, <code>t=4s</code></strong>: Attesters monitor the P2P network for the proposer’s block. Upon detecting it, they verify whether all transactions from their stored ILs are included in the proposer’s execution payload, except for ILs whose sender has equivocated. Based on their frozen view of the ILs from <code>t=9s</code> in the previous slot, attesters check if the execution payload satisfies IL conditions. This is done either by confirming that all transactions are present or by determining if any missing transactions are invalid when appended to the end of the payload. In such cases, attesters use the EL to perform nonce and balance checks to validate the missing transactions and check whether there is enough space in the block to include the transaction(s).</li> </ul> <h4 id="cl-p2p-validation-rules">CL P2P Validation Rules</h4> <p>When validators receive ILs from the P2P network, they perform a series of validation checks before forwarding or caching them. These rules protect against Denial-of-Service attacks by (1) limiting ILs' byte size and (2) restricting IL proposals to a small committee of IL committee members, thereby tightly bounding bandwidth, the main resource consumed by the propagation of ILs. Consumption of other relevant resources, such as verification time, is minimal because the only nontrivial check performed on IL propagation is signature verification. At this stage, there is no EL verification of the transactions within ILs. This means that ILs are allowed to contain any transactions—valid or invalid—since validators do not perform EL-side validity checks. This design choice is intended to avoid additional computational overhead.</p> <ol> <li>The slot of the IL matches the current or previous slot.</li> <li>The root of the IL committee referenced in the IL matches the expected IL committee root for its slot.</li> <li>Received two or fewer ILs from this IL committee member (see IL equivocation section below).</li> <li>The IL is correctly signed by the validator.</li> <li>The validator is part of the IL committee.</li> <li>The size of a IL does not exceed the maximum size allowed (e.g., <code>MAX_BYTES_PER_INCLUSION_LIST = 8 KiB</code>).</li> </ol> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution Layer</h3> <p>On the execution layer, an additional check is introduced for new payloads. After all of the transactions in the payload have been executed, we check whether any transaction from ILs, that is not already present in the payload, could be validly included (i.e. nonce and balance checks pass). If that is the case for any transaction, then an error is returned to the CL. Although the block is valid, the CL will not attest to it.</p> <p>Let <code>B</code> denote the current block. Let <code>S</code> denote the execution state following the execution of the last transaction in <code>B</code>. Let <code>gas_left</code> be the gas remaining after execution of B.</p> <p>For each transaction <code>T</code> in ILs, perform the following:</p> <ol> <li> <p>Check whether <code>T</code> is present in <code>B</code>. If <code>T</code> is present, then jump to the next transaction, else continue with next step.</p> </li> <li> <p>Check whether <code>B</code> has enough remaining gas to execute <code>T</code>. If <code>T.gas</code> &gt; <code>gas_left</code>, then jump to the next transaction, else continue with next step.</p> </li> <li> <p>Validate <code>T</code> against <code>S</code> by checking the nonce and balance of <code>T.origin</code>.</p> </li> </ol> <ul> <li> <p>If <code>T</code> is invalid, then continue to the next transaction.</p> </li> <li> <p>If <code>T</code> is valid, terminate process and return an <code>INCLUSION_LIST_UNSATISFIED</code> status.</p> </li> </ul> <h4 id="engine-api-changes">Engine API Changes</h4> <p>We make the following changes to the engine API:</p> <ul> <li>Add <code>engine_getInclusionListV1</code> endpoint to retrieve an IL from the <code>ExecutionEngine</code>.</li> <li>Add <code>engine_updatePayloadWithInclusionListV1</code> endpoint to update a payload with the IL that should be used to build the block. This takes as an argument an 8-byte <code>payloadId</code> of the ongoing payload build process, along with the IL itself.</li> <li>Modify <code>engine_newPayload</code> endpoint to include a parameter for transactions in ILs determined by the IL committee member. If the IL is not satisfied an <code>INCLUSION_LIST_UNSATISFIED</code> status must be returned.</li> </ul> <h4 id="il-building">IL Building</h4> <p>The rules for building ILs are left to the discretion of implementers. For instance, they may select transactions from the public mempool in various ways such as at random, by priority fee, or based on how long they have been pending. The IL has a maximum size of <code>MAX_BYTES_PER_INCLUSION_LIST = 8 KiB</code> for all of the RLP encoded transactions.</p> <h3 id="consensus-layer">Consensus Layer</h3> <p>The full consensus changes can be found in the following GitHub repository. They are split between:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/e678deb772fe83edd1ea54cb6d2c1e4b1e45cec6/specs/_features/eip7805/beacon-chain.md">Beacon Chain</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/e678deb772fe83edd1ea54cb6d2c1e4b1e45cec6/specs/_features/eip7805/fork-choice.md">Fork choice</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/e678deb772fe83edd1ea54cb6d2c1e4b1e45cec6/specs/_features/eip7805/p2p-interface.md">P2P</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/e678deb772fe83edd1ea54cb6d2c1e4b1e45cec6/specs/_features/eip7805/validator.md">Honest validator guide</a> changes.</li> </ul> <h4 id="beacon-chain-changes">Beacon chain changes</h4> <h5 id="preset">Preset</h5> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>DOMAIN_IL_COMMITTEE</code></td><td><code>DomainType('0x0C000000')</code></td></tr> <tr><td><code>IL_COMMITTEE_SIZE</code></td><td><code>uint64(2**4)</code> (=16)</td></tr> <tr><td><code>MAX_BYTES_PER_INCLUSION_LIST</code></td><td><code>uint64(2**13)</code> (=8192)</td></tr> </tbody></table> <h5 id="new-containers">New containers</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> InclusionList</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> validator_index</span><span>:</span><span> ValidatorIndex</span></span> <span class="giallo-l"><span> inclusion_list_committee_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> transactions</span><span>:</span><span> List</span><span>[</span><span>Transaction</span><span>,</span><span class="z-constant"> MAX_TRANSACTIONS_PER_PAYLOAD</span><span>]</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SignedInclusionList</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> message</span><span>:</span><span> InclusionList</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h4 id="fork-choice-changes">Fork choice changes</h4> <ul> <li>Store ILs observed over gossip before the view freeze deadline.</li> <li>If more than one IL is observed from the same IL committee member, mark the committee member as an equivocator and ignore any further ILs from them.</li> <li>The beacon block from the current slot is only attested to if it satisfies IL conditions, based on all stored ILs from non equivocators.</li> </ul> <h4 id="p2p-changes">P2P changes</h4> <ul> <li>A new global topic for broadcasting <code>SignedInclusionList</code> objects.</li> <li>A new RPC topic for request <code>SignedInclusionList</code> based on IL committee index.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="core-properties">Core Properties</h3> <ul> <li>Committee-based: FOCIL relies on a committee of multiple validators, rather than a single proposer, to construct and broadcast ILs. This approach significantly reduces the surface for bribery and extortion attacks and strengthens censorship resistance.</li> <li>Fork-choice enforced: FOCIL incorporates the force-inclusion mechanism into the fork-choice rule, an integral component of the consensus process, thereby preventing any actor from bypassing the system. Attesters vote only for blocks that include transactions from a set of ILs provided by the IL committee and that satisfy the IL constraints. Any block failing to meet these criteria will not be voted on by the attesters, and therefore cannot be canonical.</li> <li>Same-slot: With FOCIL running in parallel with the block building process for <code>slot N+1</code> during <code>slot N</code>, the constraints imposed on <code>block B</code> for <code>slot N+1</code> can include transactions submitted during <code>slot N</code>. This represents a strict improvement over forward IL designs like <a href="https://wg-eips.ritovision.com/7547/">EIP-7547</a>, where the forward property introduced a 1-slot delay.</li> <li>Conditional inclusion: FOCIL adopts conditional inclusion, accepting blocks that may lack some transactions from ILs if they cannot append the transactions to the end of the block or if they are full.</li> <li>Anywhere-in-block: FOCIL is unopinionated about the placement of transactions from ILs within a block. This reduces incentives for sophisticated actors to use side channels to bypass the mechanism. Combined with conditional inclusion, this flexibility makes the emergence of off-protocol markets less attractive.</li> <li>No incentive mechanism: FOCIL does not provide explicit rewards for IL committee members participating in the mechanism. We believe that the added complexity of implementing a transaction fee system for FOCIL is not justified. Instead, we rely on altruistic behavior, as FOCIL requires only a <code>1-out-of-N</code> honesty assumption from IL committee members for the mechanism to work as intended.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="consensus-liveness">Consensus Liveness</h3> <p>The builder of <code>slot N+1</code> cannot construct a canonical block without first receiving the ILs broadcast during <code>slot N</code>. This means that the builder (including cases in which the proposer locally builds its block) must be well-connected to the IL committee members to ensure timely access to these inclusion lists. Additionally, there must be sufficient time between the view freeze deadline (<code>t=9s</code> of <code>slot N</code>) and the moment the proposer must broadcast <code>block B</code> to the rest of the network. This buffer allows the builder to gather all available ILs and update the execution payload of <code>block B</code> accordingly.</p> <h3 id="il-equivocation">IL Equivocation</h3> <p>To mitigate IL equivocation, FOCIL introduces a new P2P network rule that allows forwarding up to two ILs per IL committee member. If the proposer or attesters detect two different ILs sent by the same IL committee member, they should ignore all ILs from that member. In the worst case, the bandwidth of the IL gossip subnet can at most double.</p> <h3 id="payload-construction">Payload Construction</h3> <p>The builder, responsible for constructing the execution payload, must ensure that the IL is satisfied. A naive way to do so would be to build an initial payload in whatever way the builder desires, then execute the following algorithm:</p> <ol> <li>Sequentially check validity of any yet-to-be-included IL tx against the post-state. If none is found, payload building is over.</li> <li>If one is found, append it to the end of the payload and update the post-state. Go back to step 1.</li> </ol> <p>The issue with this simple approach is that, given a set of <code>n</code> IL transactions, one might end up needing to do <code>n + (n-1) + (n-2) + ...</code> validity checks, so <code>O(n^2)</code>. For example, the <code>n</code>th tx might be valid while all others are not, but its execution sends balance to the sender of the <code>(n-1)</code>th tx, making it valid, and in turn, the <code>(n-1)</code>th sends balance to the sender of the <code>(n-2)</code>th tx, etc.</p> <p>To efficiently ensure that all valid IL txs have been included in the payload, builders can adopt a simple strategy: prior to building the payload, they store the <code>nonce</code> and <code>balance</code> of all Externally Owned Accounts (EOAs) involved in IL transactions. As they construct the payload, builders track these EOAs, maintaining and updating each EOA's <code>nonce</code> and <code>balance</code> whenever changes occur—specifically, when the <code>nonce</code> increments (indicating that a transaction from that EOA has been executed) or when the <code>balance</code> changes without a <code>nonce</code> increment (e.g., after an Account Abstraction (AA) transaction has interacted with that EOA).</p> <p>This tracking allows builders to verify IL transaction validity in real-time, enabling them to add transactions sequentially until all remaining transactions are either invalid because the nonce or balance of the associated EOA does not change or cannot be included due to insufficient gas. This approach minimizes overhead by keeping track only of the state changes that are relevant to the validity of IL txs.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lucas Saldanhahttps://github.com/lucassaldanha Mikhail Kalininhttps://github.com/mkalinin https://wg-eips.ritovision.com/7804/

Allow validators to update their withdrawal credentials via execution requests

<h2 id="abstract">Abstract</h2> <p>This proposal defines a mechanism to allow validators to update their withdrawal credentials using a new execution request type (0x03). The request allows for changing the execution address and the withdrawal credential prefix (0x01 or 0x02).</p> <h2 id="motivation">Motivation</h2> <p>When the ability to update a validator BLS withdrawal credentials to execution address was introduced in Capella, one of the most common questions was about allowing the withdrawal credential to be changed in the future. Either for security (e.g. credential rotation) or to allow for alternative ways of handling withdrawals (e.g. having a contract address as credentials). The main reason for not adding this options was because implementing this communication channel between the Execution Layer and the Consensus Layer is complex (based on the experience with the Eth1 bridge).</p> <p>In Electra, the protocol was upgraded with Execution Requests (deposits, withdrawals and consolidations), and a mechanism for general purpose execution requests <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a>, decreasing the complexity of adding a new request from execution to consensus layer.</p> <p>The introduction of execution requests that are created on the execution layer, opened up possibilities on how validators can be managed. Execution request can be created via smart contracts, allowing for decentralized and on-chain mechanisms to be explored. This also means validators will be able to move between execution and compounding withdrawal credentials (following the correct churn on the total staked amount).</p> <p>For an execution request to be authorized in the consensus layer, the withdrawal credential of the validator must be the same of the <code>msg.caller</code> when processing the transaction on the EVM. So the validator's withdrawal credential must be the same address of the smart contract creating the request (not the credential of the transaction sender), or the contract needs to use <code>DELEGATECALL</code> to ensure the caller address matches the address in the validator's withdrawal credential. Validators that already have a contract address as their withdrawal credentials should be able to update their contracts to meet this demand (assuming they have an updatable contract).</p> <p>There problems for existing validators that have their withdrawal credentials set to an EOA account is they will never be able to use smart contracts for creating execution requests, because the current design does not allow for these credentials to ever be changed.</p> <p>Allowing for validators to update their withdrawal credentials mean they can opt-in and out of different schemes and strategies on managing their validators, favouring experimentation and innovation. Today, the only alternative to this is exiting the validator and creating a new validator with different withdrawal credentials.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td><em>TBD</em></td><td>Mainnet</td></tr> </tbody></table> <h3 id="configuration">Configuration</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_PREDEPLOY_ADDRESS</code></td><td><code>0x09Fc772D0857550724b07B850a4323f39112aAaA</code></td><td>Where to call and store relevant details about the withdrawal credentials update mechanism</td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_TYPE</code></td><td><code>0x03</code></td><td>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> type prefix for withdrawal credential update request</td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td><td>Address used to invoke system operation on contract</td></tr> <tr><td><code>EXCESS_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_STORAGE_SLOT</code></td><td>0</td><td></td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_COUNT_STORAGE_SLOT</code></td><td>1</td><td></td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_HEAD_STORAGE_SLOT</code></td><td>2</td><td>Pointer to head of the withdrawal credential update request message queue</td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_TAIL_STORAGE_SLOT</code></td><td>3</td><td>Pointer to the tail of the withdrawal credential update request message queue</td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_STORAGE_OFFSET</code></td><td>4</td><td>The start memory slot of the in-state withdrawal credential update request message queue</td></tr> <tr><td><code>MAX_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_PER_BLOCK</code></td><td>4</td><td>Maximum number of withdrawal credential update requests that can be dequeued into a block</td></tr> <tr><td><code>TARGET_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_PER_BLOCK</code></td><td>1</td><td></td></tr> <tr><td><code>MIN_WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_FEE</code></td><td>1</td><td></td></tr> <tr><td><code>WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_FEE_UPDATE_FRACTION</code></td><td>17</td><td></td></tr> <tr><td><code>EXCESS_INHIBITOR</code></td><td><code>2**256-1</code></td><td>Excess value used to compute the fee before the first system call</td></tr> </tbody></table> <h3 id="execution-layer">Execution Layer</h3> <ul> <li><strong><code>FORK_BLOCK</code></strong> -- the first block in a blockchain with the <code>timestamp</code> greater or equal to <code>FORK_TIMESTAMP</code>.</li> </ul> <h4 id="withdrawal-credentials-update-request-operation">Withdrawal Credentials Update request operation</h4> <p>The new withdrawal credential update request operation is an <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request with type <code>0x03</code> and consists of the following fields:</p> <ol> <li><code>pubkey</code>: <code>Bytes48</code></li> <li><code>old_address</code>: <code>Bytes20</code></li> <li><code>new_address</code>: <code>Bytes20</code></li> </ol> <p>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> encoding of a withdrawal credential update request is computed as follows.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>request_type</span><span class="z-keyword"> =</span><span class="z-constant"> WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_TYPE</span></span> <span class="giallo-l"><span>request_data</span><span class="z-keyword"> =</span><span> read_withdrawal_credential_update_requests</span><span>(</span><span>)</span></span></code></pre><h4 id="withdrawal-credentials-update-request-contract">Withdrawal Credentials Update Request Contract</h4> <p>The contract is similar to other execution requests contracts for Deposits, Withdrawals and Consolidation. The contract has three different code paths, which can be summarized at a high level as follows:</p> <ol> <li>Add request - requires a <code>68</code> byte input, the validator's public key concatenated with the new address for withdrawal credentials.</li> <li>Excess requests getter - if the input length is zero, return the current excess requests count.</li> <li>System process - if called by system address, pop off the withdrawal credential update requests for the current block from the queue.</li> </ol> <!-- TODO add sudo code / bytecode / deployment / etc (very similar to existing request contracts) --> <h4 id="block-processing">Block processing</h4> <p>At the end of processing any execution block where <code>block.timestamp &gt;= FORK_TIMESTAMP</code> (i.e. after processing all transactions and after performing the block body requests validations) client software <strong>MUST</strong> include a call the contract as <code>SYSTEM_ADDRESS</code> and empty input data to trigger the system subroutine execute. The response should be treated as a new request type (0x03) according to <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a>.</p> <h4 id="block-validation">Block Validation</h4> <p>EL must check that the commitment hash in the execution block header matches the hash of the list of execution requests the CL sends when validating the execution block (including any requests of the new defined type 0x03).</p> <h3 id="consensus-layer">Consensus Layer</h3> <!-- TODO complete the specification --> <p>Summary of changes:</p> <ul> <li>New container <code>WithdrawalCredentialUpdateRequest</code></li> <li>New method in Block Processing: <code>process_withdrawal_credential_update_request</code></li> <li>New Beacon State mutator method: <code>update_withdrawal_credentials</code></li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> WithdrawalCredentialUpdateRequest</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> validator_pubkey</span><span>:</span><span> BLSPubkey</span></span> <span class="giallo-l"><span> old_address</span><span>:</span><span> ExecutionAddress</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> request contract will set this to msg.caller</span></span> <span class="giallo-l"><span> new_address</span><span>:</span><span> ExecutionAddress</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_withdrawal_credential_update_request</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> withdrawal_credentials_update_requests</span><span>:</span><span> WithdrawalCredentialUpdateRequest</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> validator_pubkeys</span><span class="z-keyword"> =</span><span> [</span><span>v</span><span>.</span><span>pubkey</span><span class="z-keyword"> for</span><span> v</span><span class="z-keyword"> in</span><span> state</span><span>.</span><span>validators</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify pubkey exists</span></span> <span class="giallo-l"><span> request_pubkey</span><span class="z-keyword"> =</span><span> withdrawal_credentials_update_requests</span><span>.</span><span>validator_pubkey</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> request_pubkey</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> validator_pubkeys</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span> index</span><span class="z-keyword"> =</span><span> ValidatorIndex</span><span>(</span><span>validator_pubkeys</span><span>.</span><span>index</span><span>(</span><span>request_pubkey</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify withdrawal credentials</span></span> <span class="giallo-l"><span> has_correct_credential</span><span class="z-keyword"> =</span><span> has_execution_withdrawal_credential</span><span>(</span><span>validator</span><span>)</span></span> <span class="giallo-l"><span> is_correct_old_address</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> validator</span><span>.</span><span>withdrawal_credentials</span><span>[</span><span class="z-constant">12</span><span>:</span><span>]</span><span class="z-keyword"> ==</span><span> withdrawal_credentials_update_requests</span><span>.</span><span>old_address</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> (</span><span>has_correct_credential</span><span class="z-keyword"> and</span><span> is_correct_old_address</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> credential_type</span><span class="z-keyword"> =</span><span> withdrawal_credentials_update_requests</span><span>.</span><span>type</span></span> <span class="giallo-l"><span> is_eth1_type</span><span class="z-keyword"> =</span><span> credential_type</span><span class="z-keyword"> ==</span><span class="z-constant"> ETH1_ADDRESS_WITHDRAWAL_PREFIX</span></span> <span class="giallo-l"><span> is_compounding_type</span><span class="z-keyword"> =</span><span> credential_type</span><span class="z-keyword"> ==</span><span class="z-constant"> COMPOUNDING_WITHDRAWAL_PREFIX</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify valid type</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> (</span><span>is_eth1_type</span><span class="z-keyword"> or</span><span> is_compounding_type</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-invalid z-deprecated">;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> update_withdrawal_credentials</span><span>(</span><span>state</span><span>,</span><span> index</span><span>,</span><span> credential_type</span><span>,</span><span> withdrawal_credentials_update_requests</span><span>.</span><span>new_address</span><span>)</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> update_withdrawal_credentials</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> index</span><span>:</span><span> ValidatorIndex</span><span>,</span><span class="z-variable z-parameter z-function"> new_credential_type</span><span>:</span><span> Bytes1</span><span>,</span><span class="z-variable z-parameter z-function"> new_withdrawal_credentials</span><span>:</span><span> ExecutionAddress</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> old_credential_type</span><span class="z-keyword"> =</span><span> validator</span><span>.</span><span>withdrawal_credentials</span><span>[</span><span>:</span><span class="z-constant">1</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> validator</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span></span> <span class="giallo-l"><span> validator</span><span>.</span><span>withdrawal_credentials</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> new_credential_type</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-keyword"> *</span><span class="z-constant"> 11</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> new_withdrawal_credentials</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If moving from 0x01 to 0x02</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>old_credential_type</span><span class="z-keyword"> ==</span><span class="z-constant"> ETH1_ADDRESS_WITHDRAWAL_PREFIX</span><span class="z-keyword"> and</span><span> new_credential_type</span><span class="z-keyword"> ==</span><span class="z-constant"> COMPOUNDING_WITHDRAWAL_PREFIX</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-keyword">TODO</span><span class="z-comment">: in this case we need to ensure we put them through the churn/likely re-using some of the exiting rules</span></span> <span class="giallo-l"><span> switch_to_compounding_validator</span><span>(</span><span>state</span><span>,</span><span> index</span><span>)</span></span> <span class="giallo-l"><span> }</span></span></code></pre><h2 id="rationale">Rationale</h2> <!-- TODO --> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <!-- TODO --> <h2 id="test-cases">Test Cases</h2> <!-- TODO --> <h2 id="security-considerations">Security Considerations</h2> <p>Ownership is defined based on control of the withdrawal credential account, either as a private key (for EOA accounts) or controlling the smart contract at the address set as withdrawal credential. Therefore allowing an update should not bring any security implications.</p> <p>Further discussion needed.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/7799/

Per-block logs without associated transactions

<h2 id="abstract">Abstract</h2> <p>This EIP defines an extension for eth_getLogs to provide logs for events that are not associated with a given transaction, such as block rewards and withdrawals.</p> <h2 id="motivation">Motivation</h2> <p>With <a href="https://wg-eips.ritovision.com/7708/">EIP-7708</a> wallets gain the ability to use eth_getLogs to track changes to their ETH balance. However, the ETH balance may change without an explicit transaction, through block production and withdrawals. By having such operations emit block-level system logs, eth_getLogs provides a complete picture of ETH balance changes.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="fee-payment-logs">Fee payment logs</h3> <p>A log, identical to a LOG2, is issued for every transaction and appended after all other logs created by EVM execution. The fee amount incorporates the total fee charged during transaction execution, including the base fee, the priority fee, and potential blob fees.</p> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0x7bd3aa7d673767f759ebf216e7f6c12844986c661ae6e0f1d988cf7eb7394d1d</code> (<code>keccak256('Fee(address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td><code>from</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <h3 id="system-logs-list">System logs list</h3> <p>A new list is introduced to track all block level logs emitted from system interactions. The definition uses the <code>Log</code> SSZ type from <a href="https://wg-eips.ritovision.com/6466/">EIP-6466</a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>system_logs</span><span class="z-keyword"> =</span><span> ProgressiveList</span><span>[</span><span>Log</span><span>]</span><span>(</span></span> <span class="giallo-l"><span> log_0</span><span>,</span><span> log_1</span><span>,</span><span> log_2</span><span>,</span><span class="z-constant"> ...</span><span>)</span></span></code></pre><h3 id="priority-fee-processing">Priority fee processing</h3> <p>A log SHALL be appended to the system logs list when crediting the batched <a href="https://wg-eips.ritovision.com/8115/">EIP-8115</a> priority fee.</p> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0x5dfe9c0fd3043bb299f97cfece428f0396cf8b7890c525756e4ea5c0ff7d61b2</code> (<code>keccak256('PriorityRewards(address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td><code>to</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <h3 id="withdrawal-processing">Withdrawal processing</h3> <p>A log SHALL be appended to the system logs list on every <a href="https://wg-eips.ritovision.com/4895/">EIP-4895</a> withdrawal.</p> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0x7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65</code> (<code>keccak256('Withdrawal(address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td><code>to</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <h3 id="genesis-processing">Genesis processing</h3> <p>A log SHALL be appended to the system logs list when generating genesis blocks for networks that adopt this EIP from the beginning.</p> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0xba2f6409ffd24dd4df8e06be958ed8c1706b128913be6e417989c74969b0b55a</code> (<code>keccak256('Genesis(address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td><code>to</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <h3 id="execution-block-header-changes">Execution block header changes</h3> <p>The <a rel="external" href="https://github.com/ethereum/devp2p/blob/5713591d0366da78a913a811c7502d9ca91d29a8/caps/eth.md#block-encoding-and-validity">execution block header</a> is extended with a new field, <code>system-logs-root</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>block_header</span><span>.</span><span>system_logs_root</span><span class="z-keyword"> =</span><span> system_logs</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span></span></code></pre><h3 id="json-rpc-api">JSON-RPC API</h3> <p>Block header objects in the context of the JSON-RPC API are extended to include:</p> <ul> <li><code>systemLogsRoot</code>: <code>DATA</code>, 32 Bytes</li> </ul> <p>Log objects in the context of the JSON-RPC API are updated as follows:</p> <ul> <li><code>logIndex</code>: <code>QUANTITY</code> - The additional system logs are indexed consecutively after the existing logs from transaction receipts</li> <li><code>transactionIndex</code>: <code>QUANTITY</code> - <code>null</code> is also used for system logs; pending logs can still be identified by checking the <code>blockHash</code> for <code>null</code></li> <li><code>transactionHash</code>: DATA, 32 Bytes - <code>null</code> is also used for system logs</li> </ul> <h3 id="engine-api">Engine API</h3> <p>In the engine API, the <code>ExecutionPayload</code> for versions corresponding to forks adopting this EIP is extended to include:</p> <ul> <li><code>systemLogsRoot</code>: <code>DATA</code>, 32 Bytes</li> </ul> <p>As part of <code>engine_forkchoiceUpdated</code>, Execution Layer implementations SHALL verify that <code>systemLogsRoot</code> for each block matches the actual value computed from local processing. This extends on top of existing <code>receiptsRoot</code> validation.</p> <h3 id="consensus-executionpayload-changes">Consensus <code>ExecutionPayload</code> changes</h3> <p>The consensus <code>ExecutionPayload</code> type is extended with a new field to store the system logs root.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayload</span><span>(</span><span class="z-constant">...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> system_logs_root</span><span>:</span><span> Root</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>Together with <a href="https://wg-eips.ritovision.com/7708/">EIP-7708</a> this EIP provides the ability for wallets to compute the exact ETH balance from logs without requiring download of every single block header and all withdrawals.</p> <p>The block reward from priority fees no longer has to be summed up by processing all receipts and can be obtained from the system logs root, making it efficiently provable.</p> <h3 id="alternatives-future">Alternatives / Future</h3> <ul> <li> <p>The information from withdrawals is now duplicated across both the <code>withdrawals</code> list and the system logs. Maybe the information could be massaged into the emitted <code>Withdrawal</code> log data, allowing the existing <code>withdrawals</code> list to be retired. The current list design requires the wallet to obtain all block headers and all withdrawals to ensure they obtained all data pertaining to the observed account. Allowing them to be queried using <code>eth_getLogs</code> is more in line with how deposits are being tracked.</p> </li> <li> <p>The log definitions themselves are subject to change. Aligning them with <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> for plain credits provides consistency. For withdrawals, the log data could match the form of deposit logs and <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request logs.</p> </li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As a new field is added to the block header, applications assuming a specific block header layout may need updating.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The emitted logs use <code>SYSTEM_ADDRESS</code> as their <code>address</code> which cannot conflict with user controlled smart contracts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/7807/

Migration of execution blocks to SSZ

<h2 id="abstract">Abstract</h2> <p>This EIP defines a migration process of execution blocks to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md">Simple Serialize (SSZ)</a>.</p> <h2 id="motivation">Motivation</h2> <p>With <a href="https://wg-eips.ritovision.com/6404/">EIP-6404</a> SSZ transactions, <a href="https://wg-eips.ritovision.com/6466/">EIP-6466</a> SSZ receipts, and <a href="https://wg-eips.ritovision.com/6465/">EIP-6465</a> SSZ withdrawals, all Merkle-Patricia Tries (MPT) besides the state trie are converted to SSZ. This enables the surrounding data structure, the execution block itself, to also convert to SSZ, achieving a unified block representation across both Consensus Layer and Execution Layer.</p> <ol> <li> <p><strong>Normalized block hash:</strong> The Consensus Layer can compute the block hash autonomously, enabling it to process all consistency checks that currently require asynchronous communication with the Execution Layer (<a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#modified-verify_and_notify_new_payload"><code>verify_and_notify_new_payload</code></a>). This allows early rejection of inconsistent blocks and dropping the requirement to wait for engine API interactions while syncing.</p> </li> <li> <p><strong>Optimized engine API:</strong> With all exchanged data supporting SSZ, the engine API can be changed from the textual JSON encoding to binary SSZ encoding, reducing exchanged data size by ~50% and significantly improving encoding/parsing efficiency.</p> </li> <li> <p><strong>Proving support:</strong> With SSZ, individual fields of the execution block header become provable without requiring full block headers to be present. With <a href="https://wg-eips.ritovision.com/7495/">EIP-7495</a> SSZ <code>ProgressiveContainer</code>, proofs are forward compatible as long as underlying semantics of individual fields are unchanged, reducing maintenance requirements for smart contracts and verifying client applications.</p> </li> <li> <p><strong>Cleanup opportunity:</strong> The conversion to SSZ allows dropping historical fields from the PoW era and the inefficient logs bloom mechanism.</p> </li> </ol> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="gas-amounts">Gas amounts</h3> <p>The different kinds of gas amounts are combined into a single structure, mirroring the <a href="https://wg-eips.ritovision.com/6404/#gas-fees">EIP-6404 gas fees</a>.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th></tr></thead><tbody> <tr><td><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>GasAmount</code></a></td><td><code>uint64</code></td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> GasAmounts</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> regular</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> blob</span><span>:</span><span> GasAmount</span></span></code></pre><h3 id="requests-hash-computation">Requests hash computation</h3> <p><code>requests_hash</code> is changed to <code>ExecutionRequests.hash_tree_root()</code> using the same structure as in the Consensus Layer <code>BeaconBlockBody</code>.</p> <h3 id="execution-block-headers">Execution block headers</h3> <p>New execution block headers use a normalized SSZ representation.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionBlockHeader</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> parent_hash</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> miner</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> state_root</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> transactions_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-6404 transactions.hash_tree_root()</span></span> <span class="giallo-l"><span> receipts_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-6466 receipts.hash_tree_root()</span></span> <span class="giallo-l"><span> number</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> gas_limits</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> extra_data</span><span>:</span><span> ByteList</span><span>[</span><span class="z-constant">MAX_EXTRA_DATA_BYTES</span><span>]</span></span> <span class="giallo-l"><span> mix_hash</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> base_fees_per_gas</span><span>:</span><span> BlobFeesPerGas</span></span> <span class="giallo-l"><span> withdrawals_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-6465 withdrawals.hash_tree_root()</span></span> <span class="giallo-l"><span> excess_gas</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> parent_beacon_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> requests_hash</span><span>:</span><span> Bytes32</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-6110 execution_requests.hash_tree_root()</span></span> <span class="giallo-l"><span> system_logs_root</span><span>:</span><span> Root</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> EIP-7799 system_logs.hash_tree_root()</span></span></code></pre><h3 id="execution-block-hash-computation">Execution block hash computation</h3> <p>For new blocks, the execution block hash is changed to be based on <code>hash_tree_root</code> in all contexts, including (1) the <code>BLOCKHASH</code> opcode, (2) JSON-RPC API interactions (<code>blockHash</code> field), (3) devp2p networking.</p> <h3 id="consensus-executionpayload-changes">Consensus <code>ExecutionPayload</code> changes</h3> <p>Usages of <code>ExecutionPayloadHeader</code> are replaced with <code>ExecutionBlockHeader</code>.</p> <p>Usages of <code>ExecutionPayload</code> are updated to share <code>hash_tree_root</code> with <code>ExecutionBlockHeader</code>. <code>transactions_root</code>, <code>withdrawals_root</code> and <code>requests_hash</code> are expanded to their full list contents.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> parent_hash</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> miner</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> state_root</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> transactions</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Transaction</span><span>]</span></span> <span class="giallo-l"><span> receipts_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> number</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> gas_limits</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> extra_data</span><span>:</span><span> ByteList</span><span>[</span><span class="z-constant">MAX_EXTRA_DATA_BYTES</span><span>]</span></span> <span class="giallo-l"><span> mix_hash</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> base_fees_per_gas</span><span>:</span><span> BlobFeesPerGas</span></span> <span class="giallo-l"><span> withdrawals</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Withdrawal</span><span>]</span></span> <span class="giallo-l"><span> excess_gas</span><span>:</span><span> GasAmounts</span></span> <span class="giallo-l"><span> parent_beacon_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> requests</span><span>:</span><span> ExecutionRequests</span></span> <span class="giallo-l"><span> system_logs_root</span><span>:</span><span> Root</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>This completes the transition to SSZ for everything except the execution state trie.</p> <h3 id="future">Future</h3> <ul> <li> <p>With SSZ <code>Log</code>, the withdrawals mechanism and validator requests could be redefined to be based on logs (similar to deposits, originally, but without the delay), possibly removing the need for <code>withdrawals_root</code> and <code>requests_hash</code>.</p> <ul> <li>The CL would insert the extra logs for minting (<a href="https://wg-eips.ritovision.com/7799/">EIP-7799</a>) and could fetch the ones relevant for withdrawing (deposits, requests, consolidations). That mechanism would be more generic than <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> and would drop requiring the EL to special case requests, including <code>compute_requests_hash</code>.</li> <li>For client applications and smart contracts, it would streamline transaction history verification based on <a href="https://wg-eips.ritovision.com/7792/">EIP-7792</a>.</li> </ul> </li> <li> <p>The Engine API should be updated with (1) possible withdrawals/requests refactoring as above, (2) dropping the <code>block_hash</code> field so that <code>ExecutionPayload</code> is replaced with <code>ExecutionBlockHeader</code>, (3) binary encoding based on <code>ForkDigest</code>-context (through HTTP header or interleaved, similar to beacon-API). This reduces encoding overhead and also simplifies sharing data structures in combined CL/EL in-process implementations.</p> </li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This breaks compatibility of smart contracts that depend on the previous block header binary format, including for "generic" implementations that assume a common prefix and run the entire data through a linear keccak256 hash.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The SSZ block hash is based on SHA256 and shares the namespace with existing keccak256 based block hashes. As these hash algorithms are fundamentally different, no significant collision risk is expected.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status https://wg-eips.ritovision.com/7797/

Double the performance of hash_tree_root by customizing SHA-256

<h2 id="abstract">Abstract</h2> <p>This EIP explains how to customize <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md#merkleization"><code>hash_tree_root</code></a> to double its performance.</p> <h2 id="motivation">Motivation</h2> <p>Hashing is a dominant performance bottleneck for Consensus Layer implementations. To support large validator counts, it is critical to optimize hashing performance.</p> <p>Consensus Layer hashes are based on <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md#merkleization"><code>hash_tree_root</code></a>, a mechanism that splits up the data into chunks and then forms a tree by recursively combining two adjacent chunks and hashing them into a single parent chunk until only a single root chunk remains.</p> <p>For hashing, Secure Hash Algorithm 2 with a digest size of 256 bits is used (SHA-256). This algorithm produces <em>exactly</em> 256 bits of output for a variable-length input message. However, as <code>hash_tree_root</code> pads all input chunks to exactly 256 bits, the effective input message length is always <em>exactly</em> 512 bits.</p> <p>This EIP defines how the SHA-256 algorithm used by <code>hash_tree_root</code> can be customized to exploit knowledge of the exact input length to double its performance, while retaining its security properties.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="sha-256-preprocessing">SHA-256 preprocessing</h3> <p>Before SHA-256 hash computation begins, the input message is preprocessed. A single <code>1</code> bit is appended to the input message, followed by a varying number of <code>0</code> bits, and finally a big endian <code>uint64</code> indicating the input message bit length. The number of <code>0</code> bits is chosen so that the message size is the smallest possible multiple of 512 bits. In the context of <code>hash_tree_root</code> where the input message size is 512 bits, preprocessing results in the following padded message:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 0 1 2 3 4 5 6 7 8 9 A B C D E F</span></span> <span class="giallo-l"><span> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+</span></span> <span class="giallo-l"><span> 0x00 | |</span></span> <span class="giallo-l"><span> 0x10 | Input |</span></span> <span class="giallo-l"><span> 0x20 | message |</span></span> <span class="giallo-l"><span> 0x30 | |</span></span> <span class="giallo-l"><span> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+</span></span> <span class="giallo-l"><span> 0x40 |80|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|</span></span> <span class="giallo-l"><span> 0x50 |00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|</span></span> <span class="giallo-l"><span> 0x60 |00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|</span></span> <span class="giallo-l"><span> 0x70 |00 00 00 00 00 00 00 00|00 00 00 00 00 00 02 00|</span></span> <span class="giallo-l"><span> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+</span></span></code></pre><h3 id="sha-256-blocks">SHA-256 blocks</h3> <p>SHA-256 operates on message blocks of 512 bits. Therefore, in the context of <code>hash_tree_root</code> where the input message size is 512 bits, two message blocks are formed, the first containing the entire input message, and the second containing entirely static data resulting from the preprocessing step.</p> <p>Note that the second 512 bit message block does not provide any entropy, and is only useful to distinguish input messages that share a common prefix and only vary in the number of trailing <code>0</code> bits. As <code>hash_tree_root</code> uses a fixed message size, no distinguishing is necessary. Further, SHA-256 is also considered secure for padded messages that fit into a single message block.</p> <h3 id="sha-256-512">SHA-256-512</h3> <p>A new algorithm SHA-256-512 is defined as a modified SHA-256 algorithm that skips input message preprocessing and is restricted to inputs of exactly 512 bits. The input message SHALL be processed as is, as a single 512-bit SHA-256 message block.</p> <p>For every <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md#composite-types">composite SSZ type</a> in use, implementations SHALL support a new type that shares the same functionality, but hashes using SHA-256-512 instead of regular SHA-256.</p> <h3 id="consensus-types">Consensus types</h3> <p>Starting with the hard fork that introduces this EIP, the SHA-256-512 based composite SSZ types SHOULD be preferred over existing SHA-256 based types.</p> <p>Certain use cases covering historical objects MAY require conversion to the historical data type and re-hashing with the original SHA-256 type to recover their historical root. This includes <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#compute_signing_root"><code>compute_signing_root</code></a> signing over historical data, and also individual fields such as <code>BeaconState.latest_block_header</code> which MAY refer to data from prior forks.</p> <p>Certain other objects such as <code>DepositData</code> or <code>VoluntaryExit</code> MAY continue to rely on existing SHA-256 logic.</p> <h2 id="rationale">Rationale</h2> <p>Doubling the throughput of the underlying hash algorithm allows scaling to more validators on the same hardware, or allows using the freed CPU time for other tasks. Even when caching rarely-changed intermediate hashes across computations such as the <code>validators</code> list of a <code>BeaconState</code>, and employing hardware-accelerated SHA-256 implementations that are further optimized for the tree structure using libraries such as <code>prysmaticlabs/hashtree</code>, the state root validation step of the Consensus Layer state transition function can still consume ~25% of CPU time (Holesky test network, ~1.7m validators), mostly dominated by frequently changing per-validator structures such as the <code>EpochParticipationFlags</code> lists.</p> <p>If the hash algorithm is changed to a more zero-knowledge friendly one in the future, similar efforts as described in this EIP would be needed to identify the locations where historical objects need to be hashed using historical hashes, and also to introduce new composite SSZ types. A switch from SHA-256 to SHA-256-512 would pull such work ahead, and any future hash algorithm changes would solely have to extend on these known locations. The total work necessary to switch hash algorithms multiple times is comparable to switching a single time.</p> <p>Existing hardware acceleration for SHA-256 continues to be viable, as only the message preprocessing step is dropped. Hardware acceleration typically only implements the SHA-256 message block function, which is unchanged by this EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Smart contracts and client applications that verify Consensus Layer data require updates to remain compatible with data hashed using SHA-256-512. New logic may be required to correctly select the hash algorithm for historical structures such as <code>BeaconBlockHeader</code>.</p> <p>SSZ serialization, generalized indices, as well as semantics of individual object fields remain unchanged.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Certain SHA-256-512 hashes of 512 bit data may collide with regular SHA-256 hashes of shorter data. For example:</p> <ul> <li>Any common 440-bit prefix: <code>COMMON_PREFIX := 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536</code></li> <li><code>SHA-256-512(COMMON_PREFIX ++ 0x80 ++ 0x00000000000001b8) == 463eb28e72f82e0a96c0a4cc53690c571281131f672aa229e0d45ae59b598b59</code></li> <li><code>SHA-256(COMMON_PREFIX) == 463eb28e72f82e0a96c0a4cc53690c571281131f672aa229e0d45ae59b598b59</code></li> </ul> <p>Because SSZ has never hashed data with sizes different from 512 bits, SSZ hashes based on SHA-256 do not collide with hashes based on SHA-256-512.</p> <p>SHA-256-512 SHOULD NOT be used for purposes other than SSZ Merkleization.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7792/

Scheme to make the eth_getLogs response verifiable

<h2 id="abstract">Abstract</h2> <p>This EIP defines a method to make the <code>eth_getLogs</code> JSON-RPC response verifiable.</p> <h2 id="motivation">Motivation</h2> <p>The <code>eth_getLogs</code> endpoint is used by wallets to obtain the transaction history pertaining to an account or a topic. To verify correctness and completeness of the logs, a wallet would also have to obtain all block headers and check against their logs bloom. However, that mechanism is inefficient due to its high false positive rate and also involves an unpractical amount of network round trips. This EIP defines a replacement mechanism to efficiently and incrementally verify correctness and completeness of <code>eth_getLogs</code> responses.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="configuration">Configuration</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>LOG_CONTRACT_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td></tr> </tbody></table> <h3 id="log-accumulation">Log accumulation</h3> <p>After executing all transactions of a block, commitments of all emitted logs are accumulated into the storage of <code>LOG_CONTRACT_ADDRESS</code>. The contract has no code, and its storage layout consists of three slots of type <code>mapping</code>. However to prevent <a href="https://wg-eips.ritovision.com/158/">EIP-158</a> cleanup, the contract's nonce is set to <code>1</code> at the first write.</p> <p>| Name | Value | Type | | <code>LOG_ADDRESS_STORAGE_SLOT</code> | <code>0</code> | <code>mapping(address =&gt; bytes32)</code> | | <code>LOG_TOPICS_STORAGE_SLOT</code> | <code>1</code> | <code>mapping(bytes32 =&gt; bytes32)</code> | | <code>LOG_ADDRESS_TOPICS_STORAGE_SLOT</code> | <code>2</code> | <code>mapping(bytes32 =&gt; bytes32)</code> |</p> <p>Additional metadata about each log's origin is mixed in to each <code>LogEntry</code>. The definition uses the <code>Log</code> SSZ type as defined in <a href="https://wg-eips.ritovision.com/6466/">EIP-6466</a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BlockMeta</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> number</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> LogMeta</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> block</span><span>:</span><span> BlockMeta</span></span> <span class="giallo-l"><span> transaction_index</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Log</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> topics</span><span>:</span><span> List</span><span>[</span><span>Bytes32</span><span>,</span><span class="z-constant"> MAX_TOPICS_PER_LOG</span><span>]</span></span> <span class="giallo-l"><span> data</span><span>:</span><span> ByteList</span><span>[</span><span class="z-constant">MAX_LOG_DATA_SIZE</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> LogEntry</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> meta</span><span>:</span><span> LogMeta</span></span> <span class="giallo-l"><span> log</span><span>:</span><span> Log</span></span></code></pre> <p>The <code>hash_tree_root(LogEntry)</code> commitments are subsequently tracked as part of <code>LOG_CONTRACT_ADDRESS</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> accumulate_log</span><span>(</span><span class="z-variable z-parameter z-function">evm</span><span>:</span><span> Evm</span><span>,</span><span class="z-variable z-parameter z-function"> entry_root</span><span>:</span><span> Bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes32</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> root</span><span class="z-keyword"> =</span><span> hashlib</span><span>.</span><span>sha256</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> root</span><span>.</span><span>update</span><span>(</span><span>entry_root</span><span>)</span></span> <span class="giallo-l"><span> root</span><span>.</span><span>update</span><span>(</span><span>sload</span><span>(</span><span>evm</span><span>.</span><span>env</span><span>.</span><span>state</span><span>,</span><span class="z-constant"> LOG_CONTRACT_ADDRESS</span><span>,</span><span> key</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span>evm</span><span>.</span><span>env</span><span>.</span><span>state</span><span>,</span><span class="z-constant"> LOG_CONTRACT_ADDRESS</span><span>,</span><span> key</span><span>,</span><span> root</span><span>.</span><span>digest</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> track_log</span><span>(</span><span class="z-variable z-parameter z-function">evm</span><span>:</span><span> Evm</span><span>,</span><span class="z-variable z-parameter z-function"> entry</span><span>:</span><span> LogEntry</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> entry_root</span><span class="z-keyword"> =</span><span> entry</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Allow verification via `address` filter</span></span> <span class="giallo-l"><span> key</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>abi</span><span>.</span><span>encode</span><span>(</span><span>entry</span><span>.</span><span>log</span><span>.</span><span>address</span><span>,</span><span class="z-constant"> LOG_ADDRESS_STORAGE_SLOT</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> accumulate_log</span><span>(</span><span>evm</span><span>,</span><span> entry_root</span><span>,</span><span> key</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> topic</span><span class="z-keyword"> in</span><span> entry</span><span>.</span><span>log</span><span>.</span><span>topics</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Allow verification via `topics` filter</span></span> <span class="giallo-l"><span> key</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>abi</span><span>.</span><span>encode</span><span>(</span><span>topic</span><span>,</span><span class="z-constant"> LOG_TOPICS_STORAGE_SLOT</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> accumulate_log</span><span>(</span><span>evm</span><span>,</span><span> entry_root</span><span>,</span><span> key</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Allow verification via combined `address` + `topics` filter</span></span> <span class="giallo-l"><span> key</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>abi</span><span>.</span><span>encode</span><span>(</span><span>entry</span><span>.</span><span>log</span><span>.</span><span>address</span><span>,</span><span> topic</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> key</span><span class="z-keyword"> =</span><span> keccak256</span><span>(</span><span>abi</span><span>.</span><span>encode</span><span>(</span><span>key</span><span>,</span><span class="z-constant"> LOG_ADDRESS_TOPICS_STORAGE_SLOT</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> accumulate_log</span><span>(</span><span>evm</span><span>,</span><span> entry_root</span><span>,</span><span> key</span><span>)</span></span></code></pre><h3 id="json-rpc-api">JSON-RPC API</h3> <p>The <code>eth_getLogs</code> response format is extended to include:</p> <ul> <li><code>blockTimestamp</code>: <code>QUANTITY</code> - The timestamp field of the block referred to by <code>blockHash</code></li> </ul> <h3 id="verification">Verification</h3> <p>For <code>eth_getLogs(address, topics, fromBlock, toBlock)</code>, the response data can be verified for correctness and completion by obtaining:</p> <ol> <li><code>fromBlock</code> and <code>toBlock</code> block headers (validated against their known hashes)</li> <li><code>fromBlock</code>'s <code>parentBlock</code> header (validated against <code>fromBlock.parentHash</code>)</li> <li>Historical log accumulator at <code>parentBlock</code> based on given filters (validated with <code>eth_getProof</code>)</li> <li>Log accumulator at <code>toBlock</code> based on given filters (validated with <code>eth_getProof</code>)</li> </ol> <p>Starting from the historical log accumulator from (3), each response entry is applied to it in a way compatible with <code>accumulate_log</code> above. If the log accumulator ends up matching the value from (4), the response data is correct and <code>LogEntry</code> derived from it can be trusted.</p> <h2 id="rationale">Rationale</h2> <p>Making the <code>eth_getLogs</code> response verifiable adds the necessary security attributes to enable wallets to transition away from relying on trusted data providers, ultimately improving the wallet's privacy guarantees as it is no longer subject to the privacy policy of any given provider.</p> <h3 id="gas-cost">Gas cost</h3> <p>The gas cost produced by this scheme is significantly higher than what <code>LOG#</code> opcodes produce as of Prague, primarily due to the additional <code>SLOAD</code> / <code>SSTORE</code> and the double cost of <code>SHA256</code> opcodes compared to <code>KECCAK256</code> opcodes. The gas cost increases outweigh the savings from dropping logs blooms.</p> <p>If the mechanism turns out to be prohibitively expensive even when optimized, it may be necessary to move the log accumulators to a separate optimized data structure (not in <code>state_root</code>), or to an out-of-protocol zk system. Even then, the gas cost for logs should still reflect the actual overall cost to update a typical out-of-protocol accumulator to deter against log spamming.</p> <h3 id="block-number-transaction-index-in-meta-instead-of-hashes">Block number / transaction index in meta instead of hashes</h3> <p>As long as the accumulators are stored in the state trie, they cannot refer to the block hash as the block hash hashes over the state trie, producing a cyclic dependency. If an external system is used, hashes may be included as in that scenario the state root is not affected by the IVC.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>It is still possible to process <code>eth_getLogs</code> responses from trusted servers as is, without verifying them. Client applications with strict response validation may need to be updated to allow the additional <code>blockTimestamp</code> field.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This scheme reuses existing <code>eth_getProof</code> and SSZ Merkle proofs; it does not introduce new security risks.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Marc Harvey-Hillhttps://github.com/Marchhill Ahmad Bitarhttps://github.com/smartprogrammer93 https://wg-eips.ritovision.com/7793/

Transactions that only executes at a specific index and slot

<h2 id="abstract">Abstract</h2> <p>This EIP proposes to add a new transaction format for "conditional transactions", that are only valid at a specified slot and index within the block. A new opcode <code>TXINDEX</code> is introduced to expose the conditional transaction index onchain.</p> <h2 id="motivation">Motivation</h2> <p>The proposal aims to improve support for encrypted mempools. Transactions in an encrypted mempool are ordered while the transactions are encrypted, before being decrypted and included onchain at the top of the block. If the builder does not respect the order when including the decrypted transactions then they could frontrun decrypted transactions. The new transaction type can be used to make this impossible; if a decrypted transaction is not included at the correct index, it will be invalid.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>COND_TX_TYPE</code></td><td><code>Bytes1(0x05)</code></td></tr> <tr><td><code>TXINDEX_OPCODE_BYTE</code></td><td><code>Bytes1(0x4c)</code></td></tr> <tr><td><code>TXINDEX_OPCODE_GAS</code></td><td><code>2</code></td></tr> </tbody></table> <h3 id="conditional-transaction-type">Conditional Transaction Type</h3> <p>We introduce a new type of <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction, "conditional transactions", where the <code>TransactionType</code> is <code>COND_TX_TYPE</code> and the <code>TransactionPayload</code> is the RLP serialization of the following <code>TransactionPayloadBody</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, conditional_slot, conditional_tx_index, y_parity, r, s]</span></span></code></pre> <p>The fields <code>chain_id</code>, <code>nonce</code>, <code>max_priority_fee_per_gas</code>, <code>max_fee_per_gas</code>, <code>gas_limit</code>, <code>to</code>, <code>value</code>, <code>data</code>, <code>access_list</code>, <code>max_fee_per_blob_gas</code> follow the same semantics as <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>. The field <code>blob_versioned_hashes</code> is the same except that the list may be empty for a conditional transaction.</p> <p>The fields <code>conditional_slot</code> and <code>conditional_tx_index</code> are both <code>uint64</code> and specify the slot and transaction index in which this transaction should be considered valid respectively. In order to verify that <code>conditional_slot</code> is correct, <a href="https://wg-eips.ritovision.com/7843/">EIP-7843</a> is a dependency, as this adds the slot number to the header. For both fields <code>-1</code> is used as a sentinel value for which the slot or transaction index check will not take place.</p> <h4 id="signature">Signature</h4> <p>The signature values <code>y_parity</code>, <code>r</code>, and <code>s</code> are calculated by constructing a secp256k1 signature over the following digest:</p> <p><code>keccak256(COND_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, conditional_slot, conditional_tx_index]))</code>.</p> <h3 id="txindex-opcode">TXINDEX opcode</h3> <p>A new opcode <code>TXINDEX</code> is introduced at <code>TXINDEX_OPCODE_BYTE</code>.</p> <h4 id="output">Output</h4> <p>One element <code>TransactionIndex</code> is added to the stack. <code>TransactionIndex</code> is a <code>uint64</code> in big endian encoding. It is equal to <code>conditional_tx_index</code> if the current transaction is a conditional transaction, and <code>-1</code> otherwise.</p> <h4 id="gas-cost">Gas Cost</h4> <p>The gas cost for <code>TXINDEX</code> is a fixed fee of <code>TXINDEX_OPCODE_GAS</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="transaction-type">Transaction Type</h3> <p>An alternative design could simply return the current transaction index without adding a new transaction type. Adding a new transaction type is favoured as it means that the expected transaction index must be declared statically upfront, rather than allowing dynamic behaviour based on the returned transaction index. This prevents complex constraints being imposed that makes it difficult to build a block.</p> <h3 id="gas-price">Gas Price</h3> <p>The opcode is priced to match similar opcodes in the <code>W_base</code> set.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-15T00:00:00+00:00 2026-02-11T14:49:28+00:00 Marc Harvey-Hillhttps://github.com/Marchhill https://wg-eips.ritovision.com/7788/

Target blob count changes dynamically to aim for constant blob costs

<h2 id="abstract">Abstract</h2> <p>This EIP proposes to make the target blob count adjust dynamically up to a safe maximum target. This adjustment will target a constant price in ETH for blobs, aiming for consistent costs of L2 transactions.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum currently uses a target of 50% capacity for blob count, with <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> smoothing out short-term spikes and pushing average throughput towards the target. A dynamic target is orthogonal to EIP-1559, tweaking the target itself over a longer timescale to aim for some desired blob cost.</p> <p>With static targeting the target may be higher than the actual demand, causing the protocol to undercharge for blobspace. This decreases the amount of fees burned, negatively affecting the price of ETH and total network security.</p> <p>As an example, consider what would happen if there was a large increase in max blob count due to DAS implementation but the target remained at 50%. It is unlikely that demand would immediately jump to anywhere near the target, and so for months or years the protocol would effectively charge nothing for L2 transactions. With a dynamic target, the target blob count would drop until the cost of blobspace for an L2 transaction approximated some affordable constant value. In this way, some fees are still burned by the protocol, but new L2s are not discouraged from using Ethereum blobspace, knowing that the target will increase in response to an increase in demand and blob fees will remain reasonably consistent.</p> <p>While the max blob count and max target are hard constraints based on resource utilisation limits, setting the target itself is far more subjective. A dynamic target can optimise for constant and affordable L2 transaction costs without requiring regular intervention by core developers to make tweaks based on changes in demand.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td>TBD</td></tr> <tr><td><code>TARGET_BLOB_COUNT_CHANGE_RATE</code></td><td><code>1</code></td></tr> <tr><td><code>MIN_TARGET_BLOB_COUNT</code></td><td><code>1</code></td></tr> <tr><td><code>MAX_TARGET_BLOB_COUNT</code></td><td><code>3</code></td></tr> <tr><td><code>BLOB_COST_CHANGE_MARGIN</code></td><td><code>2^48</code></td></tr> <tr><td><code>TARGET_BLOB_COST</code></td><td><code>2^49</code></td></tr> </tbody></table> <h3 id="dynamic-targeting">Dynamic targeting</h3> <p>The target blob count changes each epoch based on the mean blob cost over the previous epoch. If the average cost exceeds the desired amount beyond some margin then the target is increased; likewise if it is below the desired amount by some margin the target will decrease. The target can increase up to <code>MAX_TARGET_BLOB_COUNT</code>, which is deemed to be a safe average throughput for the network, and down to a minimum of <code>MIN_TARGET_BLOB_COUNT</code>.</p> <p>Calculating targets:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>blob_cost_diff</span><span class="z-keyword"> =</span><span> mean_blob_cost</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_BLOB_COST</span></span> <span class="giallo-l"><span>target_change_direction</span><span class="z-keyword"> =</span><span class="z-keyword"> -</span><span class="z-constant">1</span><span class="z-keyword"> if</span><span> blob_cost_diff</span><span class="z-keyword"> &lt;</span><span class="z-keyword"> -</span><span class="z-constant">BLOB_COST_CHANGE_MARGIN</span><span class="z-keyword"> else</span><span> (</span><span class="z-constant">1</span><span class="z-keyword"> if</span><span> blob_cost_diff</span><span class="z-keyword"> &gt;</span><span class="z-constant"> BLOB_COST_CHANGE_MARGIN</span><span class="z-keyword"> else</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span>next_epoch_blob_count</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-support">min</span><span>(</span><span class="z-constant">MAX_TARGET_BLOB_COUNT</span><span>,</span><span> previous_epoch_blob_count</span><span class="z-keyword"> +</span><span> (</span><span>target_change_direction</span><span class="z-keyword"> *</span><span class="z-constant"> TARGET_BLOB_COUNT_CHANGE_RATE</span><span>)</span><span>)</span><span>,</span><span class="z-constant"> MIN_TARGET_BLOB_COUNT</span><span>)</span></span></code></pre><h3 id="engine-api-change">Engine API change</h3> <p>The Engine API is extended to provide the <code>mean_blob_cost</code> for the current epoch when the CL requests it from the EL. The CL requests this at the end of an epoch to set the target for the next epoch (depends on <a href="https://wg-eips.ritovision.com/7742/">EIP-7742</a>).</p> <h2 id="rationale">Rationale</h2> <h3 id="constant-blob-cost-target">Constant blob cost target</h3> <p>A constant blob cost target can keep L2 transaction costs affordable for end users. Volatility in the price of ETH would affect affordability, but is unlikely to be significant compared to normal fluctuations in blob gas costs due to spikes in activity. In future the costs could be adjusted in the case of changes in the order of magnitude of ETH price.</p> <p>An alternative approach would be to track a target blob cost in fiat. However, choosing a specific fiat currency is not credibly neutral, and introducing exchange rate oracles into the protocol could be an attack vector.</p> <p>Yet another alternative is to have validators vote on the target blob cost, but they may have conflicts of interest (for example if they operate a rollup) so again this is not credibly neutral.</p> <h3 id="target-block-gas">Target block gas</h3> <p>The same logic could be applied to the target block gas, but generally blockspace is in high demand so arguably gas costs are never too low. The target should be set to the maximum average throughput that the network can safely handle, a dynamic target is not necessary.</p> <h3 id="parameter-choices">Parameter choices</h3> <p><code>TARGET_BLOB_COST</code> is chosen so that the system targets affordable L2 transactions. Assuming that the theoretical compressed size of a simple transfer is 23 bytes, this gives a blobspace cost for L2 transactions of:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(23 / 125000) * TARGET_BLOB_COST ≈ 104 gWei</span></span></code></pre> <p>At today’s prices, $1 would cover blobspace for around 3700 simple transfers on L2. The blob cost target should be chosen with extensive community involvement. Note that this is the cost of blobspace for an L2 transaction; the total cost will be more due to rollup execution costs.</p> <p><code>TARGET_BLOB_COUNT_CHANGE_RATE</code> is chosen as a compromise between the system being reactive to changes in demand, and not having large jumps in average throughput. <code>BLOB_COST_CHANGE_MARGIN</code> is set such that target blob count will stay static when blob costs are within a range ±50% of <code>TARGET_BLOB_COST</code>.</p> <p><code>MAX_TARGET_BLOB_COUNT</code> is set to <code>3</code> to match the current static target. This value should be increased in future when it is deemed to be safe to increase average blob throughput.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>N/A</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <!-- TODO --> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-07T00:00:00+00:00 2026-02-11T14:49:28+00:00 Tim Pecherskyhttps://github.com/peersky https://wg-eips.ritovision.com/7784/

Global byte code accessing by its hash

<h2 id="abstract">Abstract</h2> <p>This is a proposal to add a new opcode, <code>GETCONTRACT</code>. The <code>GETCONTRACT</code> opcode would return the address containing the bytecode by its hash.</p> <h2 id="motivation">Motivation</h2> <p>Content addressing by hash is a common pattern in database design. It allows to store and retrieve data by its unique footprint in the storage. This pattern is widely used in the industry and it allows abstracting the actual storage location and allows reusing the same bytecode in multiple contracts.</p> <p>Today, existing contract discovery relies on addresses, which are non-deterministic and can be obfuscated through proxies. Indexing by bytecode hash provides a deterministic and tamper-proof way to identify and verify contract code, enhancing security and trust in the Ethereum ecosystem.</p> <p>Consider a security auditor who wants to attest to the integrity of a contract’s code. By referencing bytecode hashes, auditors can focus their audit on the bytecode itself, without needing to assess deployment parameters or storage contents. This method verifies the integrity of a contract’s codebase without auditing the entire contract state.</p> <p>Additionally, bytecode referencing allows whitelist contracts before deployment, allowing developers to get pre-approval for their codebase without disclosing the code itself, or even pre-setup infrastructure that will change it behavior upon adding some determined functionality on chain.</p> <p>For developers relying on extensive code reuse, bytecode referencing protects against malicious changes that can occur with address-based referencing through proxies. This builds long-term trust chains extending to end-user applications.</p> <p>For decentralized application (dApp) developers, a code index can save gas costs by allowing them to reference existing codebase instead of redeploying them, optimizing resource usage. This can be useful for dApps that rely on extensive re-use of same codebase as own dependencies.</p> <p>This also allows to build new core standards more conveniently, for example, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> can use it as dependency, to allow users who want to set up one-time code on their EOAs by referring to <code>GETCONTRACT</code> instead of specifying potentially mutable address based functionality.</p> <h2 id="specification">Specification</h2> <h3 id="opcode-definition">Opcode Definition</h3> <ul> <li><strong>Mnemonic:</strong> <code>GETCONTRACT</code></li> <li><strong>Opcode Value:</strong> <code>0x4f</code></li> <li><strong>Input:</strong> <ul> <li><code>codehash</code>: A single 32-byte code hash from the stack.</li> </ul> </li> <li><strong>Output:</strong> <ul> <li><code>address</code>: If the <code>codehash</code> exists in the state, pushes the corresponding contract address onto the stack. Otherwise, pushes 0.</li> </ul> </li> <li><strong>Gas Cost:</strong> 150</li> <li><strong>Stack Effects:</strong> Pops 1 item, pushes 1 item.</li> <li><strong>Error Handling:</strong> If the <code>codehash</code> is invalid or the bytecode retrieval encounters an error, the instruction will revert.</li> </ul> <p>Every contract stored in EVM MUST be added to the state trie with the key being the keccak256 hash of the contract's bytecode, provided it is:</p> <ul> <li>not already present</li> <li>The contract did not invoke the <code>SELFDESTRUCT</code> opcode.</li> <li>The <code>EXTCODEHASH</code> return value IS NOT <code>0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329</code> (<code>keccak256(0xef01)</code>)</li> </ul> <h3 id="example-usage">Example Usage</h3> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> getContractAddress</span><span>(</span><span class="z-support">bytes32</span><span class="z-variable"> codehash</span><span>)</span><span class="z-storage z-type"> public</span><span class="z-storage z-type"> view</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">address</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> address</span><span> contractAddress</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> assembly</span><span> {</span></span> <span class="giallo-l"><span> contractAddress </span><span class="z-keyword">:=</span><span class="z-entity z-name"> GETCONTRACT</span><span>(</span><span>codehash</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> contractAddress</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="rationale">Rationale</h2> <p><strong>Bytecode over Addresses</strong>: Bytecode is deterministic and can be verified on-chain, while addresses are opaque and mutable.</p> <p><strong>Do not re-index</strong>: There is small, yet non-zero probability of hash collision attack. Disallowing updates to indexed location of bytecode coupes with this.</p> <p><strong>Gas cost</strong>: This operation is more complex than simple data retrieval, however lookup in the database by hash generally is simpler in complexity.</p> <h2 id="security-considerations">Security Considerations</h2> <p><strong>Malicious Code</strong>: The index does NOT guarantee the safety or functionality of indexed contracts. Users MUST exercise caution and perform their own due diligence before interacting with indexed contracts.</p> <p><strong>Storage contents of registered contracts</strong>: The index only refers to the bytecode of the contract, not the storage contents. This means that the contract state is not indexed and may change over time.</p> <p><strong><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegation:</strong> Temporary code delegation is disallowed to prevent case of registering a code hash that becomes unavailable. Standard explicitly disallows contracts with bytecode delegated via <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> from being indexed.</p> <p><strong>SELFDESTRUCT</strong>: Contracts that <code>selfdestruct</code> are not indexed, as they will not have a codehash in the state trie.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-10-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Adamshttps://github.com/benaadams Dankrad Feisthttps://github.com/dankrad Maria Inês Silvahttps://github.com/misilva73 Paul Harrishttps://github.com/rolfyone https://wg-eips.ritovision.com/7782/

Reduce Ethereum's slot time from 12s to 6s to decrease latency by 50%, distribute bandwidth usage, and improve UX.

<h2 id="abstract">Abstract</h2> <p>Reduce Ethereum's slot time from 12 s to 6 s, halving on‑chain latency and epoch duration. This doubles slot throughput while keeping block and blob sizes unchanged, smoothing bandwidth usage. The change delivers better user experience, faster Layer 2 interaction, tighter DEX pricing, reduced MEV, and quicker finality.</p> <h2 id="motivation">Motivation</h2> <ul> <li><strong>Protocol Carrying Capacity</strong> It is impractical to increase block sizes beyond 10MiB without substantial networking changes. However it is practical to decrease slot time to achieve similar effect while also improving the UX at same time.</li> <li><strong>Enhanced UX</strong>: Confirmations now arrive in ~6 s instead of 12 s.</li> <li><strong>Faster Finality</strong>: Epochs shrink from 384 s (32 × 12 s) to 192 s (32 × 6 s), accelerating Casper‑FFG finality.</li> <li><strong>L2 Interoperability</strong>: Layer 2 rollups see half the settlement delay on L1, improving throughput and reducing reorg risk period.</li> <li><strong>Based rollups</strong>: Based rollup sequencing is tied to L1 block time so faster blocks directly improves based rollups.</li> <li><strong>DEX Economics</strong>: More frequent blocks decrease LVR (Loss Versus Rebalancing), which improves the economics for liquidity providers. More liquidity means lower spreads (reduced slippage).</li> <li><strong>Bandwidth Smoothing</strong>: Doubling slot rate distributes bandwidth evenly without increasing peak block size; nodes with modest capacity remain supported.</li> </ul> <h2 id="specification">Specification</h2> <p>On the consensus layer, a new parameter is added to the configuration:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SLOT_SCHEDULE:</span></span> <span class="giallo-l"><span> - EPOCH: 348618</span></span> <span class="giallo-l"><span> SECONDS_PER_SLOT: 12</span></span> <span class="giallo-l"><span> - EPOCH: 355368</span></span> <span class="giallo-l"><span> SECONDS_PER_SLOT: 6</span></span></code></pre> <p>The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.</p> <h3 id="adjustment-to-gas-and-blob-limits">Adjustment to gas and blob limits</h3> <p>The first execution block after the fork needs to specify half the previous gas limit. With this fork, all gas limit settings are reinterpreted as "gas per 12 seconds". I.e., if the user configuration or otherwise default gas limit vote was 36,000,000, the client should now vote for 18,000,000. All values are rounded down to integers.</p> <p>The blob target and limit are also halved, rounded down to the nearest integer.</p> <h3 id="attestation-deadlines">Attestation deadlines</h3> <p>All clients need to be reconfigured so that deadlines can be configured in milliseconds for finer granularity. Currently the slot is split into three equal intervals, with proposal happening at time 0, and attestations and aggregations being sent at one thirds and two thirds of the slot time. We change this to a new uneven schedule, in order to give sufficient time for block propagation, which takes the most time:</p> <ul> <li>Block proposal at 0 ms</li> <li>Attestations at 3000 ms</li> <li>Aggregates at 4500 ms</li> </ul> <h2 id="rationale">Rationale</h2> <p>This proposal balances user experience, economic efficiency, and network stability:</p> <ul> <li> <p>UX &amp; Finality: Halving slot time directly reduces confirmation latency and halves epoch duration, delivering faster feedback to users and speeding up Casper-FFG finality.</p> </li> <li> <p>Economic Efficiency: Increased block frequency tightens DEX price spreads, lowers slippage, and diminishes arbitrage and MEV opportunities, improving on-chain trading conditions.</p> </li> <li> <p>L2 &amp; Based Rollups Synergy: Layer 2 rollups, especially based rollups, benefit from reduced L1 settlement delays, enhancing throughput and user-perceived performance in rollup ecosystems.</p> </li> <li> <p>Network Stability: Maintaining existing p2p network maximum smooths bandwidth usage over time, avoiding peak-load spikes and preserving accessibility for nodes with diverse bandwidth capacities.</p> </li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backwards compatibility concerns.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li> <p><strong>Network Congestion</strong>:</p> <ul> <li><strong>Increased Message Frequency</strong>: The network must handle more frequent messages without congestion.</li> <li><strong>Mitigation</strong>: Implement network optimizations and encourage the use of efficient client software.</li> </ul> </li> <li> <p><strong>Consensus Integrity</strong>:</p> <ul> <li><strong>Fork Choice Stability</strong>: Ensure that the fork choice rule remains robust against potential reorganization attacks.</li> <li><strong>Finality Gadgets</strong>: Confirm that finality mechanisms function correctly under new timing conditions.</li> </ul> </li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0 1.0 Universal.</p> 2024-10-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Adamshttps://github.com/benaadams Toni Wahrstätterhttps://github.com/nerolation https://wg-eips.ritovision.com/7778/

Prevent Block Gas Limit Circumvention by Excluding Refunds from Block Gas Accounting

<h2 id="abstract">Abstract</h2> <p>This EIP modifies the block gas accounting mechanism to prevent the circumvention of block gas limits. It proposes that gas refunds, particularly those from SSTORE operations setting storage slots to zero, should not reduce the gas counted toward the block gas limit, while still being applied to transaction gas costs for users.</p> <h2 id="motivation">Motivation</h2> <p>Currently, gas refunds from operations like clearing storage slots (setting to zero) reduce both the transaction gas cost for users and the gas counted toward the block gas limit. This creates a discrepancy between the computational work performed and the gas accounted for in the block.</p> <p>Example: Block <code>20878522</code> shows a net usage of 28.5 MGas, but contains 4.01 MGas of refunds, bringing the gross usage to 32.51 MGas—exceeding the block gas limit by 2.51 MGas.</p> <p>This mechanism can be exploited to perform more operations in a block than the gas limit intends to allow, potentially leading to:</p> <ol> <li>Network instability due to oversized blocks</li> <li>Denial-of-service vectors</li> <li>Computational loads exceeding the intended block gas limit</li> </ol> <h2 id="specification">Specification</h2> <h3 id="gas-accounting-changes">Gas Accounting Changes</h3> <ol> <li> <p><strong>User Gas Accounting (Unchanged):</strong></p> <ul> <li>Users continue to receive gas refunds for operations that qualify (e.g., setting storage to zero)</li> <li>Transaction gas: <code>gas_spent = max(tx_gas_used - gas_refund, calldata_floor_gas_cost)</code></li> </ul> </li> <li> <p><strong>Block Gas Accounting (Modified):</strong></p> <ul> <li>When calculating gas for block gas limit enforcement, refunds are not subtracted</li> <li>Block gas accounting becomes: <code>block.gas_used += max(tx_gas_used, calldata_floor_gas_cost)</code> (incorporating the calldata floor from <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>)</li> <li>Storage discounts that reflect actual reduced computational work (e.g., warm storage access, reverting to original values) remain applied to block gas accounting</li> </ul> </li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="aligning-gas-limits-with-computational-work">Aligning Gas Limits with Computational Work</h3> <p>The block gas limit is designed to constrain the computational load per block. Gas refunds were introduced to incentivize "cleaning up" the state, not to allow exceeding computational limits. By excluding refunds from block gas accounting, we ensure the block gas limit effectively constrains computational load</p> <h3 id="preserving-user-incentives">Preserving User Incentives</h3> <p>Users still receive gas refunds, maintaining incentives for efficient state management. Only the accounting for block-level constraints changes, not the economics for individual users</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <ul> <li>This change is not backwards compatible and requires a hard fork</li> <li>User and developer experience for individual transactions remains unchanged</li> <li>Block producers need to adjust their transaction selection algorithms to account for the new gas accounting rules</li> </ul> <h2 id="test-cases">Test Cases</h2> <ol> <li> <p><strong>SSTORE Operations:</strong></p> <ul> <li>Setting storage to zero: User receives refund, but block gas accounting uses full cost</li> <li>Verify blocks containing many storage-clearing operations still adhere to gas limits</li> </ul> </li> <li> <p><strong>Block Gas Limit Edge Cases:</strong></p> <ul> <li>Construct blocks with varying amounts of refundable operations</li> <li>Ensure blocks cannot exceed gas limits through refund mechanisms</li> </ul> </li> <li> <p><strong>Transaction Gas vs Block Gas:</strong></p> <ul> <li>Verify that transaction costs for users remain unchanged</li> <li>Confirm block gas accounting properly excludes refunds</li> </ul> </li> </ol> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Eliminates potential denial-of-service vectors that exploit gas refunds to exceed block computational limits</li> <li>Improves predictability of block processing times by enforcing stricter limits on computational work</li> <li>Prevents miners/validators from including transactions that collectively contain more computational work than intended</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-09-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dev Bearhttps://github.com/itsdevbear https://wg-eips.ritovision.com/7775/

An opcode to burn native ether at the given address

<h2 id="abstract">Abstract</h2> <p>This proposal introduces a <code>BURN</code> opcode to the EVM. When called, the opcode is to burn native ether at the address of the current evm context.</p> <h2 id="motivation">Motivation</h2> <p>The motivation for this proposal is to provide a standardized and efficient way to burn native ether directly within the EVM. Historically, contracts such as the BeaconDepositContract have "burned" ether by making it irrecoverable from the given address. This approach can lead to confusion and potential misuse. By introducing a dedicated <code>BURN</code> opcode, we can ensure a clear and consistent method for burning native ether. This could become useful for Ethereum L2s when transferring ether back to the L1, as well as other EVM L1 chains that could leverage this for their cryptoeconomics.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="behaviour">Behaviour</h3> <p>The <code>BURN</code> opcode <code>(0xFC)</code> is introduced with the following behavior:</p> <ol> <li>Pops one 32-byte word from the top of the stack, treating these bytes as the <code>uint256</code> amount of native ether to be burned.</li> <li>Retrieves the current address from the EVM execution context.</li> <li>Checks the balance of the current address.</li> <li>If the amount to be burned is greater than the balance of the current address, the opcode <code>MUST</code> revert.</li> <li>If the amount to be burned is 0, the execution <code>MUST NOT</code> revert.</li> <li>Subtracts the amount from the current address's native ether balance.</li> </ol> <p>When <code>BURN</code> is used in the context of a DELEGATECALL or CALLCODE, the contract whose balance is to be manipulated is the contract that issued the DELEGATECALL or CALLCODE instruction.</p> <p>When <code>BURN</code> is used in the context of a STATICCALL the call <code>MUST</code> revert.</p> <h3 id="gas-cost">Gas Cost</h3> <p>The base gas cost for the <code>BURN</code> opcode is 100 gas. The dynamic gas cost is determined as follows:</p> <ol> <li>If the value to be burned is 0, the dynamic gas cost is 0.</li> <li>If the account doesn't exist, or the balance of the account is 0, the dynamic gas cost is 0.</li> <li>Otherwise, the dynamic gas cost is 2800.</li> </ol> <p>The total gas cost for the <code>BURN</code> opcode is the sum of the base gas cost and the dynamic gas cost.</p> <h3 id="pseudocode">Pseudocode</h3> <p>Example pseudocode for the <code>BURN</code> opcode:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> op_burn</span><span>(</span><span class="z-variable z-parameter z-function">pc</span><span>,</span><span class="z-variable z-parameter z-function"> interpreter</span><span>,</span><span class="z-variable z-parameter z-function"> scope</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Consume the base gas cost</span></span> <span class="giallo-l"><span> interpreter</span><span>.</span><span>consume_gas</span><span>(</span><span class="z-constant">100</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Pop the value to be burned from the stack</span></span> <span class="giallo-l"><span> value_to_burn</span><span class="z-keyword"> =</span><span> scope</span><span>.</span><span>stack</span><span>.</span><span>pop</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the value to be burned is 0, do not revert</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> value_to_burn</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> None</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Retrieve the current address from the EVM execution context</span></span> <span class="giallo-l"><span> current_address</span><span class="z-keyword"> =</span><span> scope</span><span>.</span><span>contract</span><span>.</span><span>address</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check the balance of the current address</span></span> <span class="giallo-l"><span> balance</span><span class="z-keyword"> =</span><span> interpreter</span><span>.</span><span>evm</span><span>.</span><span>state_db</span><span>.</span><span>get_balance</span><span>(</span><span>current_address</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the value to be burned is greater than the balance, revert</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> value_to_burn</span><span class="z-keyword"> &gt;</span><span> balance</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">ErrInsufficientBalance</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the account balance is 0, return.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> balance</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> None</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Subtract the value from the current address&#39;s balance</span></span> <span class="giallo-l"><span> interpreter</span><span>.</span><span>evm</span><span>.</span><span>state_db</span><span>.</span><span>sub_balance</span><span>(</span><span>current_address</span><span>,</span><span> value_to_burn</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The account is known to exist at this point, thus we consume &quot;warm&quot; gas.</span></span> <span class="giallo-l"><span> interpreter</span><span>.</span><span>consume_gas</span><span>(</span><span class="z-constant">2800</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> None</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The introduction of the <code>BURN</code> opcode helps clean up a piece of weird semantics in the Ethereum. Historically, burning native ether involved sending them to an address from which they could not be recovered, such as the zero address or a contract with no withdrawal functionality. This method is not only inefficient but also confusing for indexers and other tools that track token movements. By providing a dedicated <code>BURN</code> opcode, we eliminate this ambiguity and ensure that the act of burning tokens is explicit and standardized.</p> <p>Potential Pros:</p> <ul> <li>Provides a clear and standardized method for burning native ether within smart contracts.</li> <li>Allows for better accounting practices of native token within smart contracts.</li> <li>Reduces the possibility of a smart contract exploit caused by native token that was marked as "burned" being unintetionally recovered.</li> </ul> <p>Potential Cons:</p> <ul> <li>Does not help remove unrecoverable ether sitting in existing contracts.</li> <li>New code in the clients</li> <li>New concept needed to be added to the yellow paper.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new opcode and thus must be activated via a scheduled hardfork.</p> <h2 id="test-cases">Test Cases</h2> <!-- TODO --> <h2 id="reference-implementation">Reference Implementation</h2> <!-- TODO --> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Potentially opens up misuse when using <code>DELEGATECALL</code>.</li> </ul> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-09-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Andrei Maiborodahttps://github.com/gumb0 Piotr Dobaczewskihttps://github.com/pdobacz Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7761/

Add EXTCODETYPE instruction to EOF to address common uses of EXTCODE* instructions

<h2 id="abstract">Abstract</h2> <p>Allow EOF contracts to discriminate between EOAs (Externally Owned Accounts) and contract accounts by introducing an <code>EXTCODETYPE</code> instruction.</p> <h2 id="motivation">Motivation</h2> <p>EOFv1 as scoped in <a href="https://wg-eips.ritovision.com/7692/">EIP-7692</a> removes code introspection capabilities from the EVM, including the <code>EXTCODESIZE</code> instruction (in <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>). This makes it hard for <a href="https://wg-eips.ritovision.com/721/">ERC-721</a> and <a href="https://wg-eips.ritovision.com/1155/">ERC-1155</a> standard contracts to be implemented, as they rely on discovering whether a token's <code>safeTransfer</code> call target was an EOA or a contract account:</p> <ul> <li><code>safeTransfers</code> to EOAs succeed</li> <li><code>safeTransfers</code> to contract accounts call an <code>onERC721Received</code> (<code>onERC1155Received</code>) on them and expect to get a special magic return value, otherwise the transfer reverts (on the assumption that such a recipient may not be able to interact with the token)</li> </ul> <p>Application and library developers are also concerned about dynamic proxies written in EOF accidentally pointing to legacy accounts which cannot safely be called with <code>EXTDELEGATECALL</code>. They would like a way to differentiate between EOF and legacy contracts.</p> <p><code>EXTCODETYPE</code> is aimed to fill this gap and bring back the possibility to easily implement ERC-721 and ERC-1155 standard contracts in EOF as well as preserve EOF proxy contract safety.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLKNUM</code></td><td>tbd</td></tr> <tr><td><code>GAS_COLD_ACCOUNT_ACCESS</code></td><td>Defined as <code>2600</code> in the [Ethereum Execution Layer Spec Constants]</td></tr> <tr><td><code>GAS_WARM_ACCESS</code></td><td>Defined as <code>100</code> in the [Ethereum Execution Layer Spec Constants]</td></tr> <tr><td><code>TYPE_NONE</code></td><td>0</td></tr> <tr><td><code>TYPE_LEGACY_CONTRACT</code></td><td>1</td></tr> <tr><td><code>TYPE_EOF_CONTRACT</code></td><td>2</td></tr> </tbody></table> <p>We introduce a new EOFv1 instruction on the block number <code>FORK_BLKNUM</code>: <code>EXTCODETYPE</code> (<code>0xe9</code>)</p> <p>EOF code which contains this instruction before <code>FORK_BLKNUM</code> is considered invalid. Beginning with block <code>FORK_BLKNUM</code> <code>0xe9</code> is added to the set of valid EOFv1 instructions.</p> <h3 id="execution-semantics">Execution Semantics</h3> <h4 id="extcodetype"><code>EXTCODETYPE</code></h4> <ul> <li>deduct <code>GAS_WARM_ACCESS</code> gas</li> <li>pop 1 argument <code>target_address</code> from the stack</li> <li>if <code>target_address</code> has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address), then halt with an exceptional failure <ul> <li>Notice: Future expansion of the EVM address space may remove or reduce the number of bytes in this check.</li> </ul> </li> <li>deduct <code>GAS_COLD_ACCOUNT_ACCESS - GAS_WARM_ACCESS</code> if <code>target_address</code> is not in <code>accessed_addresses</code> and add <code>target_address</code> to <code>accessed_addresses</code></li> <li>Load the code from <code>target_address</code> and refer to it as <code>loaded_code</code></li> <li>if <code>loaded_code</code> is empty (does not exist or has zero length), push <code>TYPE_NONE</code> onto the stack and stop processing the operation</li> <li>If <code>loaded_code</code> indicates a delegation designator (for example, <code>0xef0100</code> as defined in <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>), <ul> <li>replace <code>loaded_code</code> with the delegated code.</li> <li>deduct gas in accordance with the delegation designation rules</li> </ul> </li> <li>If <code>loaded_code</code> indicates an EOFv1 packaged contract (starts with the bytes <code>0xef0001</code>) push <code>TYPE_EOF_CONTRACT</code> onto the stack and stop processing the operation</li> <li>Otherwise, push <code>TYPE_LEGACY_CONTRACT</code> onto the stack and stop processing the operation</li> </ul> <p>Note: if there is not enough gas to deduct for delegation designation the whole message frame will halt, making updating the <code>accessed_addresses</code> irrelevant.</p> <p>Note: If <code>target_address</code> or the delegation designator points to an account with a contract mid-creation then the code is empty and returns <code>0</code> (<code>TYPE_NONE</code>). This is aligned with similar behavior of instructions like <code>EXTCODESIZE</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="alternative-solutions">Alternative solutions</h3> <p>There have been other solutions proposed to alleviate the problems related to lack of code introspection required for ERC-721 and ERC-1155 standards:</p> <ol> <li>Extra status code for <code>EXT*CALL</code> instruction - allowing to discriminate a result coming from calling an EOA</li> <li>Extra argument for <code>EXT*CALL</code> (a "fail if EOA" flag)</li> <li>Two return values from <code>EXT*CALL</code> (status code + whether it was EOA)</li> <li><code>EXT*CALL</code> setting a new <code>callstatus</code> register (+ a new <code>CALLSTATUS</code> instruction)</li> <li>Re-enable <code>EXTCODESIZE</code> in EOF, keeping its behavior same as in legacy</li> </ol> <p><code>EXTCODETYPE</code> has been chosen as the most elegant and minimal solution satisfying the requirements at hand and still able to be introduced in EOFv1.</p> <h3 id="reuse-the-0x3b-extcodesize-opcode-for-extcodetype">Reuse the <code>0x3b</code> (<code>EXTCODESIZE</code>) opcode for <code>EXTCODETYPE</code></h3> <p>A new opcode is preferred by a general policy to not reuse opcodes. Also <code>EXTCODETYPE</code> can be rolled out in legacy EVM if desired.</p> <h3 id="keep-code-introspection-banned">Keep code introspection banned</h3> <p>Removing code introspection is one of the tenets of EOF and <code>EXTCODETYPE</code> would be an exception from the principle. Without <code>EXTCODETYPE</code>, ERC-721 and ERC-1155 standard implementations have to resort to either:</p> <ol> <li>Leveraging a "booster contract" which would be legacy and would call <code>EXTCODESIZE</code> for them. This has been deemed inelegant and inconvenient from the point of view of library implementers, requiring them to hard code an address of such a contract (with the usual address-related problems arising on different EVM chains)</li> <li>Continuing to use legacy EVM themselves. This is suboptimal, since EVM compilers are likely to at some point deprecate legacy EVM as compilation target</li> <li>Updating the standards to not rely on code introspection patterns in <code>safeTransfer</code> safeguards. This can be accomplished for example by leveraging <a href="https://wg-eips.ritovision.com/165/">ERC-165</a>, leaving out only contracts which do not implement ERC-165, and at the same time have non-throwing fallback functions, as indistinguishable from EOAs. This is not easy to achieve since ERC-721 and ERC-1155 are Final and adopted in practice.</li> </ol> <h3 id="endgame-account-abstraction-issues">"Endgame Account Abstraction" issues</h3> <p><code>EXTCODETYPE</code> (and earlier <code>EXTCODESIZE</code> available in legacy EVM) are claimed to slow down AA adoption, because they encourage patterns which discriminate between smart contract and EOA accounts, e.g. not allowing the former to interact. However, there are counterarguments that it is up to other factors which slow down AA adoption (assumption that accounts can produce ECDSA signatures, and the lack of adoption of smart contract signatures).</p> <h3 id="including-safeguarding-against-proxy-bricking">Including safeguarding against proxy bricking</h3> <p>In parallel to the ERC-721 / ERC-1155 problem, another potential risk has been brought to attention. Since EOFv1 prohibits <code>EXTDELEGATECALL</code> targeting legacy contracts, there exists a scenario where an EOF proxy contract accidentally upgrades its implementation to a legacy EVM one. Since reverting this or upgrading again (using current proxy standards) requires the implementation contract to be called, it would effectively render the contract unusable.</p> <p>For this reason it was decided to have a generalized <code>EXTCODETYPE</code> instruction instead of a <code>HASCODE</code> instruction. This provides the means to safeguard against such a scenario that a simpler instruction could not.</p> <h3 id="relation-to-eip-7702-set-eoa-account-code">Relation to <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> "Set EOA account code"</h3> <p>After <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> is activated, the discrimination between EOAs and contract accounts using <code>EXTCODESIZE</code> (or <code>EXTCODETYPE</code>) has an edge case: Whenever an EOA sets its code to a contract account which does not respond as expected to an <code>onERC721Received</code> (<code>onERC1155Received</code>) callback, transfers to it will revert, despite the recipient being able to interact with the token. This has been deemed unlikely to be a problem, as for the intended real-world uses of EIP-7702, those callbacks will be implemented by designator codes.</p> <p>Because of the requirement that EOF proxy contracts be able to determine if the new target is safe we cannot return a value for indicating that the account itself is delegated without also providing the delegated address. Instead, we return the code for the account that has the delegated code, applying the delegation. This is because the executable code is what matters for proxy updates.</p> <p>This differs from <code>EXTCODECOPY</code> and <code>EXTCODEHASH</code> behavior which do return a hash and short code indicating the proxy. The behavior of <code>EXTCODETYPE</code> is closer to a "code executing operation" in purpose as it is meant to describe the execution behavior of the account.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>EXTCODETYPE</code> at <code>0xe9</code> can be introduced in a backwards compatible manner into EOFv1 (no bump to version), because <code>0xe9</code> has been rejected by EOF validation before <code>FORK_BLKNUM</code> and there are no EOF contracts on-chain with a <code>0xe9</code> which would have their behavior altered.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion <!-- TODO --></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a></p> <p>[Ethereum Execution Layer Spec Constants] :https://github.com/ethereum/execution-specs/blob/1adcc1bfe774798bcacc685aebc17bd9935078c3/src/ethereum/cancun/vm/gas.py#L65-L66</p> 2024-08-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Max Resnickhttps://github.com/MaxResnick Davide Crapishttps://github.com/dcrapis Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/7762/

Adjust the MIN_BASE_FEE_PER_BLOB_GAS to speed up price discovery on blob space

<h2 id="abstract">Abstract</h2> <p>This EIP proposes an increase to the MIN_BASE_FEE_PER_BLOB_GAS to speed up price discovery on blob space. It also resets the excess blob gas to 0, to avoid a blob base fee spike.</p> <h2 id="motivation">Motivation</h2> <p>When scoping 4844, the thinking was that blobs would only enter price discovery once, relatively quickly after the blob rollout; however, this has not been the case. In fact, blobs have entered price discovery several times, and the frequency of price discovery events is likely to increase in the short term as we approach saturation of capacity. Moreover, the roadmap calls for further increases in blob capacity in subsequent hardforks, which may lead to price discovery events happening around those changes in the future.</p> <p>Increasing the MIN_BASE_FEE_PER_BLOB_GAS will speed up price discovery on blob space.</p> <h2 id="specification">Specification</h2> <h3 id="min-base-fee-per-blob-gas-increase"><code>MIN_BASE_FEE_PER_BLOB_GAS</code> Increase</h3> <p>The main specification change introduced by this EIP is setting MIN_BASE_FEE_PER_BLOB_GAS to 2**25:</p> <pre class="giallo z-code"><code data-lang="diff"><span class="giallo-l"><span class="z-punctuation z-definition z-inserted">+</span><span class="z-markup z-inserted"> MIN_BASE_FEE_PER_BLOB_GAS = 2**25</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-deleted">-</span><span class="z-markup z-deleted"> MIN_BASE_FEE_PER_BLOB_GAS = 1</span></span></code></pre><h3 id="excess-blob-gas-reset"><code>excess_blob_gas</code> Reset</h3> <p>To avoid a blob base fee spike, the <code>calc_excess_blob_gas</code> is modified to reset <code>excess_blob_gas</code> to 0 at the fork. To detect the fork height, the block timestamp needs to be passed into <code>calc_excess_blob_gas</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>,</span><span class="z-variable z-parameter z-function"> block_timestamp</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> at the fork, set excess_blob_gas to 0</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>timestamp</span><span class="z-keyword"> &lt;</span><span class="z-constant"> FORK_TIMESTAMP</span><span class="z-keyword"> and</span><span> block_timestamp</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_TIMESTAMP</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> otherwise, calculate normally</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p><code>validate_block</code> needs to be updated to pass the block timestamp into <code>calc_excess_blob_gas</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> add timestamp parameter</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>header</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> ==</span><span> calc_excess_blob_gas</span><span>(</span><span>block</span><span>.</span><span>parent</span><span>.</span><span>header</span><span>,</span><span> block</span><span>.</span><span>header</span><span>.</span><span>timestamp</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The current MIN_BASE_FEE_PER_BLOB_GAS is 1 wei. This is many orders of magnitude lower than the prevailing price of blobs when blobs enter price discovery. Whenever demand for blobs exceeds supply, blobs enter price discovery, but traversing the 8 orders of magnitude between 1 wei and the point where elasticity of demand starts to decrease takes a long time.</p> <p>The blob base fee can at most double every $\log_{1.125}(10) = 5.885$ blocks when blocks use all available blob space. When blobs enter price discovery, they must climb many factors of 2 to reach the prevailing price.</p> <p>To set the parameter appropriately, one approach is to look at the cost of simple transfers when base fees are low. The cost of a simple transfer when the base fee is 1 GWEI is ~5 cents USD at today's prices (2,445.77$ ETH/USDC). We can try to peg the minimum price of a blob to that. Today, to reach this price, it requires an excess blob gas of <code>63070646</code>. When you calculate how long this would take to reach from 0 excess blob gas, you get:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>63070646/(3 * 2**17) = 160.396947225</span></span></code></pre> <p>The closest power of 2 to the corresponding reserve price would be <code>MIN_BASE_FEE_PER_BLOB_GAS = 2**27</code>. Out of an abundance of caution, we will go with <code>MIN_BASE_FEE_PER_BLOB_GAS = 2**25</code> to ensure that even if the price of ETH rises significantly, the reserve price will not be set too high. This value corresponds to a minimum blob price of ~1 cent at today's prices (2,445.77$ ETH/USDC). Further, decreasing the <code>MIN_BASE_FEE_PER_BLOB_GAS</code> beyond <code>2**25</code> would slow down price discovery without a significant decrease in the price of blobs when the network is unsaturated.</p> <p>Below you will find a plot provided by @dataalways showing the fraction of type 3 transaction fees that are paid in blob base fees for different values of <code>MIN_BASE_FEE_PER_BLOB_GAS</code>. Note that even after the proposed change, for historical values of l1 gas, the price of blobs would have been dominated by the price of the L1 gas.</p> <p><img src="https://wg-eips.ritovision.com/7762/./assets/base_fee_1.png" alt="Base Fee 1" /></p> <p><img src="https://wg-eips.ritovision.com/7762/./assets/base_fee_225.png" alt="Base Fee 2^25" /></p> <hr /> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not backwards compatible and requires a coordinated upgrade across all clients at a specific block number.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Rollups that use blobs as a data availability layer will need to update their posting strategies.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-08-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper pcaversacciohttps://github.com/pcaversaccio https://wg-eips.ritovision.com/7791/

Introduces a new opcode, `GAS2ETH`, to convert gas to ETH

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new <code>GAS2ETH</code> opcode that enables the direct conversion of gas into ether (ETH).</p> <h2 id="motivation">Motivation</h2> <p>This EIP is based on the premise that smart contract authors, compiler teams, and public goods projects in general should be compensated for their contributions. Moreover, their compensation should <em>scale</em> with the usage of their contracts. A widely used and popular contract offers significant value to its users through its functionality and to the network by driving demand for blockspace — Ethereum's <em>raison d'être</em>. This increased demand also benefits miners and validators, who are rewarded for executing these contracts.</p> <p>Monetizing smart contracts in a scalable manner remains challenging at the time of this writing. This difficulty is evident from existence of many different monetization strategies employed across various smart contracts — ranging from fee structures to the issuance of tokens with "tokenomics" of varying levels of complexity. Additionally, many public goods projects struggle to secure funding.</p> <p>Introducing the <code>GAS2ETH</code> opcode offers contract authors, as well as the tools they use, a new way to achieve their monetization objectives. By charging gas, they integrate with an established user experience that is both familiar and understood by users. The proposed instruction ensures that existing transaction creation and processing tools remain unchanged. Moreover, by charging gas, contract authors align economically with network activity; they benefit from higher compensation during periods of intense network usage and receive less when activity is low. This helps align the incentives of smart contract authors, validators, and the broader network.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>A new opcode, <code>GAS2ETH</code> (<code>0xFC</code>), is introduced to enable direct conversion of gas into ETH within the EVM. This opcode operates under a new budgeting mechanism: each transaction maintains a <em>global</em> <code>GAS2ETH</code> budget initialized to the transaction gas limit (<code>tx.gas_limit</code>), and each call frame derives a <em>local</em> allowance from the gas forwarded to it. These budgets cap the total amount of gas that can be converted into ETH, both per call frame and across the entire transaction.</p> <h3 id="execution-semantics">Execution Semantics</h3> <p>The <code>GAS2ETH</code> (<code>0xFC</code>) opcode executes according to the following rules:</p> <ul> <li>Pops two values from the stack: <code>addr</code> then <code>gas_amount</code>. If there are fewer than two values on the stack, the calling context MUST fail with stack underflow.</li> <li>Deducts <code>gas_amount</code> from both the current call frame's local <code>GAS2ETH</code> allowance and the transaction-global <code>GAS2ETH</code> budget. <ul> <li>If <code>gas_amount</code> is greater than the current call frame's local <code>GAS2ETH</code> allowance or the remaining transaction-global <code>GAS2ETH</code> budget, set <code>gas_amount</code> to <code>min(gas_amount, remaining_local_allowance, remaining_global_GAS2ETH_budget)</code>.</li> </ul> </li> <li>Computes <code>wei_val</code> by multiplying <code>gas_amount</code> by the current transaction context's <code>gas_price</code> (<a rel="external" href="https://github.com/ethereum/execution-specs/blob/98d6ddaaa709a2b7d0cd642f4cfcdadc8c0808e1/src/ethereum/cancun/vm/instructions/environment.py#L325">EELS</a>).</li> <li>Endows the address <code>addr</code> with <code>wei_val</code> wei.</li> <li>Pushes <code>wei_val</code> onto the stack.</li> </ul> <p>On reverts (e.g., through the <code>REVERT</code> opcode or any exceptional halt), any gas paid out via <code>GAS2ETH</code> MUST be refunded to both the transaction-global and the parent call frame's budgets.</p> <p>Note that the transfer of <code>wei_val</code> to the target account cannot fail. In particular, the destination account code (if any) is not executed, or, if the account does not exist, the balance is still added to the given address <code>addr</code>.</p> <p>Gas consumed by <code>GAS2ETH</code> does not affect the base fee, burn, block <code>gasUsed</code>, or the transaction fee. Instead, the ETH transfer represents a direct payment from the transaction signer (i.e. <code>tx.origin</code>) to the recipient address, outside the block reward and fee accounting mechanisms. This ensures no duplication of ETH between the <code>COINBASE</code> reward and the amount transferred via <code>GAS2ETH</code>.</p> <h3 id="gas2eth-budgeting-model"><code>GAS2ETH</code> Budgeting Model</h3> <p>A transaction maintains a single global <code>GAS2ETH</code> budget initialized to the transaction gas limit (<code>tx.gas_limit</code>). Each call frame also maintains a local allowance, derived automatically from the gas forwarded to it:</p> <ul> <li>On <code>CALL</code>, <code>CALLCODE</code>, or <code>STATICCALL</code>: <code>allowance = min(forwarded_gas, remaining_global_GAS2ETH_budget)</code>.</li> <li>On <code>DELEGATECALL</code>: the callee shares the caller's allowance.</li> <li>On revert: all <code>GAS2ETH</code> deductions within that call frame are refunded to both the transaction-global and parent frame's budgets.</li> <li>On normal return: any unused local allowance is returned to the transaction-global <code>GAS2ETH</code> budget.</li> </ul> <p>This model ensures that untrusted callees cannot consume more <code>GAS2ETH</code> than the gas explicitly forwarded to them, while keeping total <code>GAS2ETH</code> creation bounded by the transaction's gas limit.</p> <h3 id="gas-cost">Gas cost</h3> <p>The proposed cost of this opcode is identical to the recently proposed <code>PAY</code> opcode.</p> <h4 id="constants">Constants</h4> <table><thead><tr><th>Constant</th><th>Definition</th></tr></thead><tbody> <tr><td><code>WARM_STORAGE_READ_COST</code></td><td><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td><code>COLD_ACCOUNT_ACCESS_COST</code></td><td><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td><code>GAS_NEW_ACCOUNT</code></td><td><a rel="external" href="https://github.com/ethereum/execution-specs/blob/4d953035fb0cceda7cf21d71b2ab7a9a6f4632f0/src/ethereum/frontier/vm/gas.py#L52">EELS</a></td></tr> <tr><td><code>GAS_CALL_VALUE</code></td><td><a rel="external" href="https://github.com/ethereum/execution-specs/blob/4d953035fb0cceda7cf21d71b2ab7a9a6f4632f0/src/ethereum/frontier/vm/gas.py#L53">EELS</a></td></tr> </tbody></table> <h4 id="gas-calculation">Gas calculation</h4> <ul> <li>Is <code>addr</code> in <code>accessed_addresses</code>? <ul> <li>If yes, <code>WARM_STORAGE_READ_COST</code>;</li> <li>Otherwise, <code>COLD_ACCOUNT_ACCESS_COST</code>.</li> </ul> </li> <li>Does <code>addr</code> exist or is <code>val</code> zero? <ul> <li>If yes to either, zero;</li> <li>Otherwise, <code>GAS_NEW_ACCOUNT</code>.</li> </ul> </li> <li>Is <code>val</code> zero? <ul> <li>If yes, zero;</li> <li>Otherwise, <code>GAS_CALL_VALUE</code>.</li> </ul> </li> </ul> <h2 id="rationale">Rationale</h2> <ul> <li><code>GAS2ETH</code> vs. pro-rata: The pro-rata model incentivizes inflating contract gas usage to artificially increase fees. In contrast, this proposal allows contract authors to charge their desired amount directly, eliminating the need for unnecessary gas consumption.</li> <li>Target address vs. simply increasing balance of the currently executing contract: Using a target address is more flexible, enabling contract authors to write more modular code and separate the concerns of fee collection from contract functionality. For instance, the contract may want to designate a specific recipient for fees without necessarily granting them direct withdrawal access.</li> <li>Charging gas instead of ETH: Charging ETH directly complicates the user experience and prevents contract authors from participating in fluctuations in gas demand directly.</li> <li>For the value of <code>gas_price</code>, use the same gas price as which is used to calculate the tx cost in ETH. This leads to the most consistent computation between <code>GAS2ETH</code> and the user's experience when creating a transaction.</li> <li>Separate budget: Having a separate budget prevents certain types of DoS attacks where usage of <code>GAS2ETH</code> can interfere with the actual budget needed for execution of the contract. (For example, a target contract can "waste" gas with <code>GAS2ETH</code>, resulting in the caller not having enough gas to finish execution). This also results in <code>GAS2ETH</code> usage not affecting the burn rate. The intuition is that, since it doesn't actually use computational resources (which gas normally "accounts" for), it shouldn't affect blockspace computations or the base fee.</li> <li>Budget being 100% of the gas limit: 100% of the gas limit is a "natural" bound on the gas used and provides some protection to the user from unbounded <code>GAS2ETH</code> spending. In the future, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a>-based transaction type could be added which includes an explicitly user-specified <code>GAS2ETH</code> budget.</li> <li>No exceptional halt when <code>gas_amount</code> exceeds the remaining budgets, both the current call frame's local <code>GAS2ETH</code> allowance and the transaction-global <code>GAS2ETH</code> budget. Since these budgets are not introspectable, the contract would otherwise have no way to gracefully avoid an exceptional halt.</li> <li>Bounding by execution gas ensures that untrusted callees cannot consume more <code>GAS2ETH</code> than the gas explicitly forwarded to them.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>Like the <a href="https://wg-eips.ritovision.com/5920/"><code>PAY</code></a> opcode and <a href="https://wg-eips.ritovision.com/4895/">beacon withdrawals</a>, <code>GAS2ETH</code> enables ETH transfers that occur without code execution in the recipient account. To prevent denial-of-service (DoS) attacks from untrusted callees, each call frame receives a local <code>GAS2ETH</code> allowance automatically derived from the gas <em>forwarded</em> to it, while a transaction-global <code>GAS2ETH</code> budget enforces an overall cap equal to the transaction's gas limit. This ensures that:</p> <ul> <li>Callees cannot deplete the sender's <code>GAS2ETH</code> budget beyond the gas explicitly forwarded to them.</li> <li>Contracts calling into untrusted code remain robust, as the callee's <code>GAS2ETH</code> spending capacity is naturally limited by its gas stipend.</li> <li>The total ETH that can be created via <code>GAS2ETH</code> in a transaction is strictly bounded.</li> </ul> <p>It's important to note that <code>GAS2ETH</code> introduces an economic incentive for malicious contracts to consume as much of their allowance as possible, converting previously non-profitable griefing vectors into potentially profitable ones. Contract authors SHOULD minimize forwarded gas and <code>GAS2ETH</code> exposure when interacting with untrusted code, similar to existing best practices for limiting gas stipends or ETH transfers.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-07-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Ignacio Hagopianhttps://github.com/jsign Gajinder Singhhttps://github.com/g11tech Ansgar Dietrichshttps://github.com/adietrichs Gottfried Heroldhttps://github.com/GottfriedHerold Jamie Lokierhttps://github.com/jlokier Tanishq Jasoriahttps://github.com/tanishqjasoria Parithosh Jayanthihttps://github.com/parithosh Gabriel Rocheleauhttps://github.com/gabrocheleau Karim Taamhttps://github.com/matkt https://wg-eips.ritovision.com/7748/

Describes a state conversion procedure to migrate key-values from the Merkle Patricia Tree to the Verkle Tree.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a procedure to convert, on each block, a fixed number of key-values from the existing Merkle Patricia Tree (MPT) to the Verkle Tree (VKT).</p> <h2 id="motivation">Motivation</h2> <p>The accounts state is too large to wait for transactions to organically move all of them to the VKT through the Overlay Tree. Thus, we need a strategy to convert all the state within a reasonable time. The state conversion completion allows removing the Overlay Tree abstraction introduced in <a href="https://wg-eips.ritovision.com/7612/">EIP-7612</a> and to use directly the VKT for all state access.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Parameter</th><th>value</th><th>Description</th></tr></thead><tbody> <tr><td><code>CONVERSION_START_TIMESTAMP</code></td><td><code>TBD</code></td><td>Timestamp at which the conversion starts.</td></tr> <tr><td><code>CONVERSION_STRIDE</code></td><td><code>TBD</code></td><td>Maximum number of <em>conversion units</em> to be converted per block</td></tr> </tbody></table> <p>A <em>conversion unit</em> is:</p> <ul> <li>A contract storage slot.</li> <li>An account data (e.g. balance, nonce, code-hash) and code (if any).</li> </ul> <h3 id="changes-to-the-execution-spec">Changes to the execution spec</h3> <p>Include the following code in the existing <code>apply_body(...)</code> function:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> apply_body</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span> ...</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>Uint</span><span>,</span><span> Root</span><span>,</span><span> Root</span><span>,</span><span> Bloom</span><span>,</span><span> State</span><span>,</span><span> Root</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;new_code&gt;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block_time</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> CONVERSION_START_TIMESTAMP</span><span class="z-keyword"> and</span><span class="z-keyword"> not</span><span> state</span><span>.</span><span>_conversion_finished</span><span>:</span></span> <span class="giallo-l"><span> state_convert</span><span>(</span><span>state</span><span>,</span><span class="z-constant"> CONVERSION_STRIDE</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;/new_code&gt;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> tx</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span class="z-support">map</span><span>(</span><span>decode_transaction</span><span>,</span><span> transactions</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>Before executing txs, it calls <code>state_convert(...)</code> (described below) which performs a state conversion step for this block.</p> <p>In <code>state.py</code>, add the following code:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> StoragePhase</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> The account next conversion step continues converting the </span></span> <span class="giallo-l"><span class="z-string"> storage-slot with key greater than or equal to next_key. </span></span> <span class="giallo-l"><span class="z-string"> If there isn&#39;t such a storage-slot, the account must move to</span></span> <span class="giallo-l"><span class="z-string"> AccountDataPhase.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> next_key</span><span>:</span><span> Bytes</span><span> </span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> AccountDataPhase</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> The account next conversion step continues migrating the account </span></span> <span class="giallo-l"><span class="z-string"> code (if any) and basic data. After processing, the account must </span></span> <span class="giallo-l"><span class="z-string"> move to the next account in the trie (or finish if it was the </span></span> <span class="giallo-l"><span class="z-string"> last one).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> CurrentConvertingAccount</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Contains the state conversion next step.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> Address</span></span> <span class="giallo-l"><span> phase</span><span> :</span><span> StoragePhase</span><span class="z-keyword"> |</span><span> AccountDataPhase</span></span></code></pre> <p>These new structures allows <code>State</code> to track where we're in the conversion process.</p> <p>Modify the <code>State</code> class by adding the following attributes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> State</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;new_code&gt;</span></span> <span class="giallo-l"><span> _conversion_curr_account</span><span>:</span><span> Optional</span><span>[</span><span>CurrentConvertingAccount</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> None</span></span> <span class="giallo-l"><span> _conversion_finished</span><span>:</span><span class="z-support"> bool</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;/new_code&gt;</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> </span></span></code></pre> <p>Define a function with the following signature:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> trie_get_next_at_key</span><span>(</span><span class="z-variable z-parameter z-function">trie</span><span>:</span><span> Trie</span><span>[</span><span>K</span><span>,</span><span> V</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> key_seek</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> (</span><span>K</span><span>,</span><span> V</span><span>,</span><span> Optional</span><span>[</span><span>Bytes</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Returns the first (key, value) in the trie-key is &gt;= key_seek.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This method must only be used on Tries with secured=True,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> since key_seek is the keccak256(K).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Returns:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> - K, V: the key and value (e.g: Address/Value, StorageSlot/Value)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> - next_key: The smallest trie-key present in the trie greater </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> than key_seek, or None if there isn&#39;t one.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> It is up to the implementer to decide the best implementation</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> considering its client architecture.</span></span></code></pre> <p>Add or modify the following functions:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> New function.</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_conversion_account</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>)</span><span> -&gt;</span><span> CurrentConvertingAccount</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> When starting the conversion, initialize with the first account</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> in the MPT.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>_conversion_curr_account</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initialize with the first account in the account trie.</span></span> <span class="giallo-l"><span> first_account</span><span class="z-keyword"> =</span><span> trie_get_next_at_key</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Accounts conversion starts with storage-slots conversion.</span></span> <span class="giallo-l"><span> phase</span><span class="z-keyword"> =</span><span> StoragePhase</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Starts with the lowest storage-slot key.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_conversion_curr_account</span><span class="z-keyword"> =</span><span> CurrentConvertingAccount</span><span>(</span><span>first_account</span><span>,</span><span> phase</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>_conversion_curr_account</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> New function.</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> conversion_move_to_next_account</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> curr_account</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>get_conversion_account</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> address</span><span>,</span><span> _</span><span>,</span><span> next_key</span><span class="z-keyword"> =</span><span> trie_get_next_at_key</span><span>(</span><span>state</span><span>.</span><span>_main_trie</span><span>,</span><span> curr_account</span><span>.</span><span>phase</span><span>.</span><span>next_key</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> next_key</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> We finished the conversion</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_conversion_finished</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Move to the next account</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_conversion_curr_account</span><span>.</span><span>address</span><span class="z-keyword"> =</span><span> address</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_conversion_curr_account</span><span>.</span><span>phase</span><span class="z-keyword"> =</span><span> StoragePhase</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0x00</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Modified function: add new only_if_empty optional parameter.</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> set_storage</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>:</span><span> U256</span><span>,</span><span class="z-variable z-parameter z-function"> only_if_empty</span><span>:</span><span class="z-support"> bool</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;new_code&gt;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> only_if_empty</span><span>:</span></span> <span class="giallo-l"><span> value</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>_overlay_tree</span><span>.</span><span>get</span><span>(</span><span>get_tree_key_for_storage_slot</span><span>(</span><span>addr</span><span>,</span><span> key</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> value</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> &lt;/new_code&gt;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_overlay_tree</span><span>.</span><span>set</span><span>(</span><span>get_tree_key_for_storage_slot</span><span>(</span><span>addr</span><span>,</span><span> key</span><span>)</span><span>,</span><span> value</span><span>)</span></span></code></pre> <p>As mentioned previously, the next function is called by <code>apply_body(...)</code> to perform the conversion step for a block:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Note the following function is optimized for readability, not for performance.</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> state_convert</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> stride</span><span>:</span><span class="z-support"> int</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> n</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span> </span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> n</span><span class="z-keyword"> &lt;</span><span> stride</span><span class="z-keyword"> and</span><span class="z-keyword"> not</span><span> state</span><span>.</span><span>_conversion_finished</span><span>:</span></span> <span class="giallo-l"><span> curr_account</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>get_conversion_account</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Skip translating storage if the account has an empty code hash.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Skip storage conversion for accounts with 0 nonce and empty code.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This covers the 28 EIP-7610 accounts, but would also cover all</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> pre-eip161 accounts on other chains.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> curr_account</span><span>.</span><span>nonce</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span class="z-support"> len</span><span>(</span><span>curr_account</span><span>.</span><span>code</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_conversion_curr_account</span><span>.</span><span>phase</span><span class="z-keyword"> =</span><span> AccountDataPhase</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Account storage.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> curr_account</span><span>.</span><span>phase</span><span class="z-keyword"> is</span><span> StoragePhase</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Get the storage-slot from _storage_tries which is MPT data.</span></span> <span class="giallo-l"><span> trie</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>_storage_tries</span><span>.</span><span>get</span><span>(</span><span>curr_account</span><span>.</span><span>address</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> trie</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> slot_num</span><span>,</span><span> slot_value</span><span>,</span><span> next_key</span><span class="z-keyword"> =</span><span> trie_get_next_at_key</span><span>(</span><span>trie</span><span>,</span><span> curr_account</span><span>.</span><span>phase</span><span>.</span><span>next_key</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The Overlay Tree will write in the VKT. We use the new</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> only_if_empty parameter to avoid writing stale values.</span></span> <span class="giallo-l"><span> set_storage</span><span>(</span><span>state</span><span>,</span><span> curr_account</span><span>.</span><span>address</span><span>,</span><span> slot_num</span><span>,</span><span> slot_value</span><span>,</span><span class="z-variable"> only_if_empty</span><span class="z-keyword">=</span><span class="z-constant">True</span><span>)</span></span> <span class="giallo-l"><span> n</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> next_key</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> There&#39;re more storage-slots to be converted, continue in this phase.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>conversion_curr_account</span><span>.</span><span>phase</span><span>.</span><span>next_key</span><span class="z-keyword"> =</span><span> next_key</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> No more storage-slots. Move to the account data migration.</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>conversion_curr_account</span><span>.</span><span>phase</span><span class="z-keyword"> =</span><span> AccountDataPhase</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> There&#39;s no storage trie for the account, move directly to</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> migrating account&#39;s data and code (if any).</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>conversion_curr_account</span><span>.</span><span>phase</span><span class="z-keyword"> =</span><span> AccountDataPhase</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Account code and basic data.</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Getting the code from the Overlay Tree is fine since it promises to return</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> the Account full code which would come from the MPT or a separate code database.</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>state</span><span>,</span><span> curr_account</span><span>.</span><span>address</span><span>)</span></span> <span class="giallo-l"><span> chunked_code</span><span class="z-keyword"> =</span><span> chunkify_code</span><span>(</span><span>account</span><span>.</span><span>code</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> chunk_num</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span class="z-support">len</span><span>(</span><span>chunked_code</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state_set_codechunk</span><span>(</span><span>state</span><span>,</span><span> address</span><span>,</span><span> chunk_num</span><span>,</span><span> chunked_code</span><span>[</span><span>chunk_num</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If the account data (i.e: nonce, balance, code-size, code-hash) lives in MPT, </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> get_account will pull from MPT and then we write to the VKT. If the account </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> data already lives in the VKT (i.e: it was indirectly converted by a tx), then </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> it will return it from the VKT and write it again (i.e: it&#39;s a noop).</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Thus, this operation is correct under both scenarios. That is, it won&#39;t</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> write stale data.</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>state</span><span>,</span><span> curr_account</span><span>.</span><span>address</span><span>)</span></span> <span class="giallo-l"><span> set_account</span><span>(</span><span>state</span><span>,</span><span> curr_account</span><span>.</span><span>address</span><span>,</span><span> account</span><span>)</span></span> <span class="giallo-l"><span> n</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> state</span><span>.</span><span>conversion_move_to_next_account</span><span>(</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="state-conversion-step-position-in-block-execution">State conversion step position in block execution</h3> <p>Performing the conversion step before the block txs execution has some benefits:</p> <ul> <li>If the state conversion step is done after txs execution, there's a possibility that txs execution writes overlap with converted key-values, having to care about them becoming stale in the same block. With the proposed ordering, they can only become stale by writes of previous blocks.</li> <li>It can reduce the complexity of optimizations, such as frontrunning the state conversion for the next block before it arrives.</li> </ul> <h3 id="conversion-stride-proposed-value"><code>CONVERSION_STRIDE</code> proposed value</h3> <p>Performance benchmarks were done to achieve the right balance between:</p> <ul> <li>Don't overload the clients with too much extra work per block.</li> <li>Don't create an unmanageable load in clients during feasible long reorgs.</li> <li>Finish the conversion as fast as possible.</li> </ul> <h3 id="account-code-chunking-done-in-a-single-step">Account code chunking done in a single step</h3> <p>If an account has code, this is chunked and inserted in the VKT in one go. An alternative is including a <code>CodePhase</code> and let each inserted chunk consume one unit of <code>CONVERSION_STRIDE</code>.</p> <p>We decided to not do this to reduce the algorithm complexity. Considering the current maximum code size, the worst case scenario for a block could overflow the <code>CONVERSION_STRIDE</code> limit by 24k/31~=793 units.</p> <h3 id="deletion-of-eip-7610-accounts">Deletion of <a href="https://wg-eips.ritovision.com/7610/">EIP-7610</a> accounts</h3> <p>EIP-7610 mentions the existence of 28 accounts that have:</p> <ul> <li>a nonce of 0,</li> <li>no code</li> <li>a non-empty storage tree</li> </ul> <p>These storage slots are to be omitted from the conversion process, as they can not be accessed.</p> <h3 id="expected-time-for-the-conversion-to-finish">Expected time for the conversion to finish</h3> <p>TODO: We have an estimation, but it might be worth recalculating it closer to the proposed fork having a more up to date state size estimate.</p> <h3 id="missed-slots">Missed slots</h3> <p>The conversion logic runs at the start of each block, so missed slots don't create special situations.</p> <h3 id="accounts-storage-account-data-order">Accounts storage-&gt;account-data order</h3> <p>The proposed order synergizes with many EL client flat-db architectures, minimizing random disk-IO.</p> <h3 id="not-counting-eip-161-accounts-for-conversion-stride-limit">Not counting <a href="https://wg-eips.ritovision.com/161/">EIP-161</a> accounts for <code>CONVERSION_STRIDE</code> limit</h3> <p>The <code>CONVERSION_STRIDE</code> parameter tries to limit the load of effective writes. These special accounts are skipped since we try to perform a bulk <a href="https://wg-eips.ritovision.com/158/">EIP-158</a> deletion of the remaining accounts.</p> <p>This might sound dangerous since if there were 1k of these accounts and all corresponded to be converted in the same block, we'd be forcing the clients to iterate 1k accounts without counting any quota from <code>CONVERSION_STRIDE</code>. The number of remaining accounts to delete is very low (i.e.: dozen) and also not contiguous, so this shouldn't be a concern.</p> <h3 id="mpt-preimage-resolving">MPT preimage resolving</h3> <p>EL clients are expected to satisfy at least one of these conditions:</p> <ul> <li>They have a proper flat-db design, which doesn't require preimage resolving.</li> <li>They have a full preimage database which can resolve <em>trie_key</em>-&gt;<em>preimage</em> (but this can have poor performance).</li> <li>They have downloaded the preimage database image that will be distributed before the conversion starts.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO: currently described in an external document.</p> <h2 id="reference-implementation">Reference Implementation</h2> <ul> <li><code>transition-post-genesis</code> branch in <code>github.com/gballet/go-ethereum</code> implements this when setting <code>--override.overlay-stride</code> to a non-zero value on the command line.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-07-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Zsolt Felföldihttps://github.com/zsfelfoldi https://wg-eips.ritovision.com/7745/

An efficient, light client and DHT friendly replacement for block header bloom filters

<h2 id="abstract">Abstract</h2> <p>Replace the fixed 2048 bit log event bloom filters with a new lookup index data structure that can adapt to the changing number of events per block and consistently guarantee a sufficiently low false positive ratio, allowing efficient trustless proofs of log event queries, canonical block hash and transaction hash lookups.</p> <p>The proposed structure maps all index entries (log events, transaction and block markers) onto a global linear index space and hashes them into a binary Merkle tree based on that index. It also contains a <em>filter map</em> for every fixed length section of the index space. These are two dimensional sparse bit maps that provide an efficient probabilistic method for looking up indexed values or query patterns of values, yielding potential matches in the form of exact positions in the linear index space. Unlike the per-block bloom filters, they allow searching for specific events by accessing only a small portion of the entire dataset which can also be proven with a Merkle proof, making the search both efficient and light client friendly.</p> <p>The proposed structure can be efficiently used both for local search and for remote proof generation/verification, thereby simplifying implementation of provers and verifiers. It also allows validators that are not interested in either searching or proving logs to generate the index root hash by maintaining a minimal index state with a relatively small (hard capped) size.</p> <h2 id="motivation">Motivation</h2> <p>Adding logs has a significantly lower gas cost and should accordingly be less resource consuming than writing to the state. The original design of bloom filters in each block achieves this goal as there is no complex data structure like the state to update, the set of logs emitted in each block is all contained within the header and receipts belonging to that block. Logs mostly just have long term storage costs. On the other hand, searching logs in a long range of blocks is very expensive and the current bloom filters do not really help.</p> <p>Bloom filters are only useful as long as they are sufficiently sparse. False positive ratio rises rapidly with the number of events per filter and the density of <code>1</code> bits in the filter bit vector. In the currently existing bloom filter each log address and topic sets 3 out of a fixed length of 2048 bits which resulted in sufficiently sparse filters in the beginning but with the increase of the block gas limits the false positive ratio soon made the filter practically useless. Mainnet blocks currently add over 1000 log addresses and topics in average and therefore the bloom filter size would need to increase about tenfold in order to achieve acceptable false positive rates again. This would raise block header size to about 3 kilobytes. Even if the size of the per-block bloom filters would be raised to a sufficient level, log search would still require accessing the entire header chain. Searching in just the most recent one year history would cost over 6 gigabytes of data, not counting the access of actual logs where the bloom filters have a match. The current situation is even worse, requiring a large portion of the full block receipt sets to be accessed due to the high false positive rate of the bloom filters. Transaction inclusion lookup is also very expensive, requiring all block bodies in the searched range.</p> <p>While full nodes and RPC servers can and usually do build additional index structures to aid certain lookups, these structures cannot be verified remotely. While it is important to improve the transaction processing capabilities of Ethereum, trustless provability is required throughout the entire stack, from end user applications signing transactions, to the same or other end user applications getting the results they need. Scaling transaction processing only makes sense as long as there is also a trustless and scalable way to access the relevant results of those transactions. Users relying on trusted servers and indexers kind of beats the whole point of Ethereum.</p> <h2 id="specification">Specification</h2> <h3 id="terms-and-definitions">Terms and definitions</h3> <ul> <li><em>index entry</em>: a single entry in the <code>index_entries</code> tree associated with an indexed event. It is either a <em>log entry</em>, a <em>transaction entry</em> or a <em>block entry</em>. An <em>index entry</em> generates one or more <em>map values</em>. Each <em>log entry</em> adds one <em>address value</em> and 0..4 <em>topic values</em> (in this order). Each <em>transaction entry</em> adds one <em>transaction value</em> and each <em>block entry</em> adds one <em>block value</em>.</li> <li><em>map value</em>: a searchable value associated with an <em>index entry</em>. It is either an <em>address value</em>, a <em>topic value</em>, a <em>transaction value</em> or a <em>block value</em>. Each <em>map value</em> is represented by a 32 byte hash (the <em>map value hash</em>) which is calculated as <code>sha2(address)</code>, <code>sha2(topic)</code>, <code>sha2(tx_hash + b"\x01")</code> or <code>sha2(block_hash + b"\x02")</code>.</li> <li><em>map value index</em>: a single position in the global linear index space. A new <em>map value index</em> is assigned to each indexed <em>map value</em>.</li> <li><em>map entry index</em>: the position where an <em>index entry</em> is located in the <code>index_entries</code> tree. Each <em>index entry</em> is located at the position corresponding to the <em>map value index</em> of the first <em>map value</em> it generates.</li> <li><em>filter map</em>: a <code>MAP_WIDTH</code> by <code>MAP_HEIGHT</code> sized sparse bit map assigned to a <code>VALUES_PER_MAP</code> length section of the <em>map value index</em> space. Each <em>map value</em> assigned to this range is marked on the map at a row and column that depends on the <em>map value index</em>, <em>mapping layer</em> and the <em>map value hash</em>. Rows are sparsely encoded as a list of marked column indices (in strictly ascending order, which also coincides with the order of occurence). Each map contains at most <code>VALUES_PER_MAP</code> marks and therefore the chance of false positives is kept at a constant low level.</li> <li><em>mapping layer</em>: each layer defines a (<em>map index</em>, <em>map value hash</em>) =&gt; <em>row index</em> mapping and imposes a limit on the number of <em>map values</em> mapped into each row using that particular mapping. Multiple <em>mapping layers</em> can be applied simultaneously on the same <em>filter map</em>. Each <em>map value</em> is mapped using the lowest possible <em>mapping layer</em> where the number of marks in the assigned row is lower than the limit. On layer 0 the <em>row index</em> mapping only changes once per <em>index epoch</em>. On higher layers the mapping changes more frequently and also the row size limit is higher.</li> <li><em>index epoch</em>: a <code>MAPS_PER_EPOCH</code> sized group of consecutive <em>filter maps</em> stored in the hash tree in a way so that multiple rows of adjacent <em>filter maps</em> with the same <em>row index</em> can be efficiently retrieved in a single Merkle multiproof.</li> </ul> <h3 id="consensus-data-format">Consensus data format</h3> <h4 id="block-headers">Block headers</h4> <p>Beginning at the execution timestamp <code>FORK_TIMESTAMP</code>, execution clients MUST replace the <code>logs_bloom</code> field of the header schema with <code>log_index_root</code> which is the root hash of the <code>LogIndex</code> structure after adding the logs emitted in the given block.</p> <p>The resulting RLP encoding of the header is therefore:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([</span></span> <span class="giallo-l"><span> parent_hash,</span></span> <span class="giallo-l"><span> 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash</span></span> <span class="giallo-l"><span> coinbase,</span></span> <span class="giallo-l"><span> state_root,</span></span> <span class="giallo-l"><span> txs_root,</span></span> <span class="giallo-l"><span> receipts_root,</span></span> <span class="giallo-l"><span> log_index_root,</span></span> <span class="giallo-l"><span> 0, # difficulty</span></span> <span class="giallo-l"><span> number,</span></span> <span class="giallo-l"><span> gas_limit,</span></span> <span class="giallo-l"><span> gas_used,</span></span> <span class="giallo-l"><span> timestamp,</span></span> <span class="giallo-l"><span> extradata,</span></span> <span class="giallo-l"><span> prev_randao,</span></span> <span class="giallo-l"><span> 0x0000000000000000, # nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas,</span></span> <span class="giallo-l"><span> withdrawals_root,</span></span> <span class="giallo-l"><span> blob_gas_used,</span></span> <span class="giallo-l"><span> excess_blob_gas,</span></span> <span class="giallo-l"><span> parent_beacon_block_root,</span></span> <span class="giallo-l"><span>])</span></span></code></pre><h4 id="container-types">Container types</h4> <p>These definitions use the <code>ProgressiveList</code> and <code>ProgressiveByteList</code> SSZ types as defined in <a href="https://wg-eips.ritovision.com/7916/">EIP-7916</a>.</p> <p>Note that the <code>LogIndex</code> and <code>IndexEpoch</code> container definitions below are "naive" definitions suitable to define SSZ merkleization. The entire log index is typically too big to be represented in memory as a whole. A more efficient implementation can be found here: <a href="https://wg-eips.ritovision.com/7745/./assets/log_index.py">log_index.py</a>, <a href="https://wg-eips.ritovision.com/7745/./assets/binary_tree.py">binary_tree.py</a> (taken from the EELS implementation). This code keeps only the currently processed parts of the tree in memory, expanding untouched empty subtrees on demand and collapsing finalized subtrees.</p> <p>Also note that the containers defined here (including <code>FilterRow</code>) have a non-initialized default value, represented as a null leaf in the Merkle tree. Initialization of these containers is explicit and happens at a well defined point. <code>IndexEpoch</code> is initialized when the first <em>index entry</em> is added to the epoch. All rows of a map are initialized when the first <em>index entry</em> is added to the map. <code>IndexEntry</code> is initialized when added; entry positions belonging to unused <em>map entry indices</em> are left uninitialized. The <code>Log</code> container is only initialized in case of <em>log entries</em>. If it is initialized then <code>topics</code> and <code>data</code> lists in the <code>Log</code> container are always initialized.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class LogIndex(Container):</span></span> <span class="giallo-l"><span> epochs: Vector[IndexEpoch, MAX_EPOCH_HISTORY]</span></span> <span class="giallo-l"><span> next_index: uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>class IndexEpoch(Container):</span></span> <span class="giallo-l"><span> filter_maps: Vector[Vector[FilterRow, MAPS_PER_EPOCH], MAP_HEIGHT]</span></span> <span class="giallo-l"><span> index_entries: Vector[IndexEntry, MAPS_PER_EPOCH * VALUES_PER_MAP]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>type FilterRow = ProgressiveList[uint32]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>class IndexEntry(Container):</span></span> <span class="giallo-l"><span> log_entry: Log</span></span> <span class="giallo-l"><span> entry_meta: Vector[Bytes32, 4] # LogMeta / TransactionMeta / BlockMeta</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>class Log(Container):</span></span> <span class="giallo-l"><span> address: ExecutionAddress</span></span> <span class="giallo-l"><span> topics: List[Bytes32, 4]</span></span> <span class="giallo-l"><span> data: ProgressiveByteList</span></span></code></pre> <p>The <code>entry_meta</code> vector has a fixed format but its interpretation depends on the type of <em>index entry</em> and the type of entry can also be determined based on its contents (and based on whether <code>log_entry</code> is initialized or not). Whenever <code>IndexEntry</code> is initialized, <code>entry_meta</code> contains either one of these containers:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class LogMeta(Container):</span></span> <span class="giallo-l"><span> block_number: uint64</span></span> <span class="giallo-l"><span> transaction_hash: Root</span></span> <span class="giallo-l"><span> transaction_index: uint64</span></span> <span class="giallo-l"><span> log_in_tx_index: uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>class TransactionMeta(Container):</span></span> <span class="giallo-l"><span> block_number: uint64</span></span> <span class="giallo-l"><span> transaction_hash: Root</span></span> <span class="giallo-l"><span> transaction_index: uint64</span></span> <span class="giallo-l"><span> receipt_hash: Root</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>class BlockMeta(Container):</span></span> <span class="giallo-l"><span> block_number: uint64</span></span> <span class="giallo-l"><span> block_hash: Root</span></span> <span class="giallo-l"><span> timestamp: uint64</span></span> <span class="giallo-l"><span> zero: uint64</span></span></code></pre><h4 id="index-entry-types-and-corresponding-map-values">Index entry types and corresponding map values</h4> <p>Three types of <em>index entries</em> are added during state transition: log, transaction and block. For each processed transaction, a <em>transaction entry</em> is added first, then <em>log entries</em> are added in the order of EVM execution. The <em>block entry</em> referring to the processed block is not added during the state transition because it is supposed to reference the block hash which is not known yet. It can be added either after block building/validaton or are the beginning of the next state transition. In either case, the <code>block entry</code> of block N first appears in the log index state of block N+1 as the first new <code>index entry</code>.</p> <p>The following table shows an example of mapping all index entry types onto the <em>map value index</em> space:</p> <table><thead><tr><th>Index entry</th><th>Map entry index</th><th>Map values</th><th>Map value indices</th></tr></thead><tbody> <tr><td>Block #0</td><td>0</td><td>Block</td><td>0</td></tr> <tr><td>Tx #1/0</td><td>1</td><td>Transaction</td><td>1</td></tr> <tr><td>Log #1/0/0</td><td>2</td><td>Addr, 3x Topic</td><td>2, 3, 4, 5</td></tr> <tr><td>Log #1/0/1</td><td>6</td><td>Addr, 3x Topic</td><td>6, 7, 8, 9</td></tr> <tr><td>Tx #1/1</td><td>10</td><td>Transaction</td><td>10</td></tr> <tr><td>Log #1/1/0</td><td>11</td><td>Addr, 2x Topic</td><td>11, 12, 13</td></tr> <tr><td>Log #1/1/1</td><td>14</td><td>Addr, Topic</td><td>14, 15</td></tr> <tr><td>Log #1/1/2</td><td>16</td><td>Addr, 2x Topic</td><td>16, 17, 18</td></tr> <tr><td>Block #1</td><td>19</td><td>Block</td><td>19</td></tr> <tr><td>Tx #2/0</td><td>20</td><td>Transaction</td><td>20</td></tr> <tr><td>Log #2/0/0</td><td>21</td><td>Addr, 4x Topic</td><td>21, 22, 23, 24, 25</td></tr> </tbody></table> <p>Note that the missing <em>map entry indices</em> are represented in the <code>index_entries</code> tree with uninitialized <code>IndexEntry</code> containers (zero value leaves in the <code>index_entries</code> vector). Most of these empty entries correspond to the <em>topic value</em> indices. Also, the last few entries of each map might be emtpy because the <em>map values</em> generated by a single <em>index entry</em> never cross a filter map boundary. So, for example, when <code>VALUES_PER_MAP</code> is 0x10000 and <code>next_index</code> is <code>0x2FFFE</code> and a <em>log entry</em> with on address and two topics is added, the last two positions of the map are left empty and the new <em>log entry</em> is added starting from position 0x30000.</p> <h4 id="filter-map-row-encoding">Filter map row encoding</h4> <p>Each row of the <em>filter map</em> is encoded as a series of little endian binary encoded column indices. For encoding simplicity the column indices are always encoded as 32 bit values, regardless of the fact that <code>MAP_WIDTH</code> is less than 32. This only applies to consensus encoding and hashing though while local storage and proof encoding can use a more tightly packed format.</p> <h4 id="proposed-constants">Proposed constants</h4> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td>MAP_WIDTH</td><td>2**24</td></tr> <tr><td>MAP_HEIGHT</td><td>2**16</td></tr> <tr><td>VALUES_PER_MAP</td><td>2**16</td></tr> <tr><td>MAPS_PER_EPOCH</td><td>2**10</td></tr> <tr><td>MAX_EPOCH_HISTORY</td><td>2**24</td></tr> <tr><td>MAX_ROW_LENGTH</td><td>[8, 168, 2728, 10920]</td></tr> <tr><td>MAPPING_FREQUENCY</td><td>[2**10, 2**6, 2**2, 1]</td></tr> </tbody></table> <p>Note that <code>MAX_ROW_LENGTH</code> and <code>MAPPING_FREQUENCY</code> parameters are specified as lists because the applicable values depend on the used <em>mapping layer</em>. For layers higher than the index of the last elements of these lists the last element is applicable. Also note that the <code>MAX_ROW_LENGTH</code> values correspond to the cumulative capacity of <code>ProgressiveList</code> tree levels; a layer 0 row fits into the first level, a layer 1 row fits into the first three levels and so on.</p> <h3 id="constructing-the-filter-map">Constructing the filter map</h3> <p>For each <code>VALUES_PER_MAP</code> long section of the <em>map value index</em> space a <em>filter map</em> is generated. These are fixed size <code>MAP_WIDTH</code> by <code>MAP_HEIGHT</code> sparse bit maps and each <em>map value</em> is marked on the map with a single bit being set to one. The number of marks in a row (the length of the sparse encoded row) is referred to as "row length", not to be confused with the constant <code>MAP_WIDTH</code>.</p> <h4 id="epochs-and-mapping-layers">Epochs and mapping layers</h4> <p>In order to allow efficient search of a certain <em>map value</em> in a long historical range, <em>filter maps</em> are organized into <em>index epochs</em>, each consisting of a fixed <code>MAPS_PER_EPOCH</code> number of maps. In the most usual case (when row density is around average or below) row mapping stays the same during an entire epoch. The hash tree is organized in a way that instead of putting all rows of a single map close to each other, rows of the same <em>row index</em> throughout an entire epoch are close to each other and therefore are cheap to access and/or prove with a Merkle proof.</p> <p>In order to mitigate collisions in densely populated rows, the concept of <em>mapping layers</em> is introduced, meaning that if a certain row already has a certain number of entries then the row mapping is changed and very frequent <em>map values</em> are mapped into multiple rows. Initially, when a map is empty, every <em>map value</em> is mapped using <em>mapping layer</em> 0 or the "base layer". If a row reaches <code>MAX_ROW_LENGTH[0]</code> then any further <em>map values</em> mapped onto that row in the base layer mapping will use layer 1 mapping instead. On layer 1 a different row is assigned to the same <em>map value</em> and the row length limit in increased to <code>MAX_ROW_LENGTH[1]</code>. If this row also reaches its limit, layer 2 mapping is used and so on. Note that a row filled at a certain <em>mapping layer</em> can be grown further on a higher layer. Different <em>map values</em> colliding in the same row on a certain layer are probably mapped in different rows on the next layer, which means that a very popular value might populate multiple rows (also very long ones) but an unlucky less popular one colliding with it on base layer will probably just have to move one layer up. The search process is similar, if the searcher finds that the row belonging to the searched value is full according to the base layer limit then it also has to check the next layer and so on, until it finds a non-full row.</p> <p>If a row is longer than the limit according to the layer the searcher is looking at then it can safely ignore the extra entries assuming that they were added by another value on a higher layer. The <code>ProgressiveList</code> container makes it efficient to prove row data belonging to the lower layer even if there is much more data in the same row added on a higher layer.</p> <h4 id="row-mapping">Row mapping</h4> <p>While base layer row mapping stays the same for an entire epoch, higher layer mappings are changed more frequently. Each mapping change has a cost in terms of database access overhead and Merkle proof size overhead and epoch size is determined in a way that these overheads stay sufficiently low compared to the cost of accessing the actual useful data. On higher layers where the rows are longer, a more frequent remapping is possible because the useful data size per map is also higher. It is also desirable so that a less frequent <em>map value</em> will only suffer from colliding with a more popular one for a shorter time.</p> <p>The <em>row index</em> is calculated as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_row_index(map_index, layer_index: Uint, map_value_hash: Hash32) -&gt; Uint:</span></span> <span class="giallo-l"><span> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> Returns the row index where the given map value hash is mapped on the given</span></span> <span class="giallo-l"><span> map and mapping layer.</span></span> <span class="giallo-l"><span> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> mf_index = min(layer_index, len(MAPPING_FREQUENCY) - 1)</span></span> <span class="giallo-l"><span> mapping_frequency = MAPPING_FREQUENCY[mf_index]</span></span> <span class="giallo-l"><span> masked_map_index = map_index - (map_index % mapping_frequency)</span></span> <span class="giallo-l"><span> row_hash = sha256(</span></span> <span class="giallo-l"><span> map_value_hash</span></span> <span class="giallo-l"><span> + masked_map_index.to_le_bytes4()</span></span> <span class="giallo-l"><span> + layer_index.to_le_bytes4()</span></span> <span class="giallo-l"><span> ).digest()</span></span> <span class="giallo-l"><span> return Uint.from_le_bytes(row_hash[0:4]) % MAP_HEIGHT</span></span></code></pre> <p>The following figure shows how <em>map values</em> are mapped to rows on different <em>mapping layers</em>. Each dot represents a map row and the numbers indicate the <em>mapping layer</em> on which the row has been assigned to the given <em>map value</em>. Note that it might happen that a higher layer mapping coincides with a lower layer mapping for the same value; this does not cause any problem though as the row is simply grown further on the higher layer. The search algorithm can also simply revisit the same row in a higher layer iteration if necessary and process the rest of the row that it first ignored.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>map index 111111 1111222222222233 3333333344444444 4455555555556666</span></span> <span class="giallo-l"><span> 0123456789012345 6789012345678901 2345678901234567 8901234567890123</span></span> <span class="giallo-l"><span> +----------------+----------------+----------------+----------------+</span></span> <span class="giallo-l"><span>row 0 |2........2......|2...............|...2............|........2.......|</span></span> <span class="giallo-l"><span>row 1 |........1111.2..|.....2..1111....|1111.....2...2..|2111..2......2..|</span></span> <span class="giallo-l"><span>row 2 |0000000000000000|.2..2....2..2...|....2111....2...|..2.....11112...|</span></span> <span class="giallo-l"><span>row 3 |....2..22...1111|..........2.1111|2.......2.2.1111|.......2...2....|</span></span> <span class="giallo-l"><span>row 4 |.2..1111..2....2|1112..2.2....2..|0000000011110020|...21111.2....2.|</span></span> <span class="giallo-l"><span>row 5 |...2........2...|...............2|.2...2.........2|.2...2..........|</span></span> <span class="giallo-l"><span>row 6 |1111.22....2..2.|0020000000020000|.......2...2....|..........2.1112|</span></span> <span class="giallo-l"><span>row 7 |..2.............|....1112......2.|..2...2.........|0000200000000000|</span></span> <span class="giallo-l"><span> +----------------+----------------+----------------+----------------+</span></span> <span class="giallo-l"><span> epoch 0 epoch 1 epoch 2 epoch 3</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>Fig 2. Row mapping of a single log value on different mapping layers</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>MAP_HEIGHT = 8</span></span> <span class="giallo-l"><span>MAPS_PER_EPOCH = 16</span></span> <span class="giallo-l"><span>MAPPING_FREQUENCY = [16, 4, 1]</span></span></code></pre><h4 id="column-mapping">Column mapping</h4> <p>Column mapping assumes that <code>MAP_WIDTH</code> is a multiple of <code>VALUES_PER_MAP</code>. <em>column index</em> is calculated as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_column_index(map_value_index: Uint, map_value_hash: Hash32) -&gt; Uint:</span></span> <span class="giallo-l"><span> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> Returns the column index where the given entry hash is mapped at the given</span></span> <span class="giallo-l"><span> entry index.</span></span> <span class="giallo-l"><span> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span> col_hash = fnv1a_64(map_value_index.to_le_bytes8() + map_value_hash)</span></span> <span class="giallo-l"><span> folded_hash = (col_hash &gt;&gt; 32) ^ (col_hash &amp; 0xFFFFFFFF)</span></span> <span class="giallo-l"><span> hash_bits = LOG2_MAP_WIDTH - LOG2_VALUES_PER_MAP</span></span> <span class="giallo-l"><span> return (</span></span> <span class="giallo-l"><span> (map_value_index % VALUES_PER_MAP)</span></span> <span class="giallo-l"><span> &lt;&lt; hash_bits + folded_hash</span></span> <span class="giallo-l"><span> &gt;&gt; (32 - hash_bits)</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>As shown on the figure below, this mapping practically assigns a <code>MAP_WIDTH // VALUES_PER_MAP</code> by <code>MAP_HEIGHT</code> rectangle to each <em>map value index</em> and ensures that each <em>map value</em> places exactly one mark in its own rectangle (the letters A-D represent different <em>map values</em>). This property also ensures that <em>map value index</em> can be restored from <em>map index</em> and <em>column index</em>, column indices never collide and keep the original order of <em>map value</em> indices, allowing efficient Merkle exclusion proofs of certain <em>column indices</em> in long rows.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>column 11 1111 1111 2222 2222 2233</span></span> <span class="giallo-l"><span> 0123 4567 8901 2345 6789 0123 4567 8901</span></span> <span class="giallo-l"><span> +---------------------------------------+</span></span> <span class="giallo-l"><span>row 0 |.... .... .... .... .... .... .... ....|</span></span> <span class="giallo-l"><span>row 1 |.... .... .... .... .... .C.. .... ....|</span></span> <span class="giallo-l"><span>row 2 |.A.. .... ...A .... A... .... ...A ....|</span></span> <span class="giallo-l"><span>row 3 |.... .... .... .... .... .... .... ....|</span></span> <span class="giallo-l"><span>row 4 |.... .... .... .... .... .... .... ....|</span></span> <span class="giallo-l"><span>row 5 |.... .B.. .... ...B .... .... .... ....|</span></span> <span class="giallo-l"><span>row 6 |.... .... .... .... .... .... .... ..D.|</span></span> <span class="giallo-l"><span>row 7 |.... .... .... .... .... .... .... ....|</span></span> <span class="giallo-l"><span> +---------------------------------------+</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>Fig 3. A single filter map with 8 entries of 4 different log values</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>MAP_WIDTH = 32</span></span> <span class="giallo-l"><span>MAP_HEIGHT = 8</span></span> <span class="giallo-l"><span>VALUES_PER_MAP = 8</span></span></code></pre><h3 id="updating-the-log-index-and-calculating-the-root-hash">Updating the log index and calculating the root hash</h3> <p>See the following functions in <a href="https://wg-eips.ritovision.com/7745/./assets/log_index.py">log_index.py</a>:</p> <ul> <li><code>log_index_add_log_entries</code></li> <li><code>log_index_add_transaction_entry</code></li> <li><code>log_index_add_block_entry</code></li> <li><code>log_index_root</code></li> </ul> <p>Note that the <em>block entry</em> may be added either after building/verifying the given block or before processing the next one, but <code>log_index_root</code> should always be calculated after adding transaction and log entries and before adding the block entry for the some block (block building would not even be possible otherwise as the log index root is referenced in the block header).</p> <h3 id="finding-potential-matches">Finding potential matches</h3> <p>Determining whether a <em>column index</em> found in the appropriate row is relevant for the searched <em>map value</em> is possible by restoring the <em>map value index</em> and then calculating the <em>column index</em> from it again in order to check whether the quasi-random collision filter part matches the expected value for the given <em>map value</em>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_map_value_index(map_index, column_index: Uint) -&gt; Uint:</span></span> <span class="giallo-l"><span> map_value_width = MAP_WIDTH // VALUES_PER_MAP</span></span> <span class="giallo-l"><span> return map_index * VALUES_PER_MAP + column_index // map_value_width</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def is_potential_match(map_index, column_index: Uint, map_value: Hash32) -&gt; bool:</span></span> <span class="giallo-l"><span> return get_column_index(get_map_value_index(map_index, column_index), map_value) == column_index</span></span></code></pre> <p>Iterating through all relevant <em>mapping layers</em> and corresponding rows is similar to how new <em>map values</em> are added. Filtering all potential matches from all relevant rows can be done with the following function:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_potential_matches((log_index: LogIndexReader, map_index: Uint, map_value: Hash) -&gt; List[Uint]:</span></span> <span class="giallo-l"><span> matches = []</span></span> <span class="giallo-l"><span> layer_index = 0</span></span> <span class="giallo-l"><span> while True:</span></span> <span class="giallo-l"><span> mr_index = min(layer_index, len(MAX_ROW_LENGTH) - 1)</span></span> <span class="giallo-l"><span> max_row_length = MAX_ROW_LENGTH[mr_index]</span></span> <span class="giallo-l"><span> row_index = get_row_index(map_index, layer_index, map_value)</span></span> <span class="giallo-l"><span> row = get_filter_row(log_index, map_index, row_index)[:max_row_length]</span></span> <span class="giallo-l"><span> for column_index in row:</span></span> <span class="giallo-l"><span> if is_potential_match(map_index, column_index, log_value):</span></span> <span class="giallo-l"><span> matches.append(get_log_value_index(map_index, column_index))</span></span> <span class="giallo-l"><span> if len(row) &lt; max_row_length:</span></span> <span class="giallo-l"><span> break</span></span> <span class="giallo-l"><span> layer_index += 1</span></span> <span class="giallo-l"><span> return matches</span></span></code></pre><h3 id="initialization-minimal-state-and-wire-protocol-extension">Initialization, minimal state and wire protocol extension</h3> <p>It is a property of the log index tree that over time most of the tree nodes get finalized, which means that in a minimal log index state representation finalized subtrees can be collapsed into a single tree node as their descendants are no longer needed for adding new entries. At every single moment there is one <em>filter map</em> being updated, maybe the few most recently completed maps might still be affected by a reorg, but if the chain finalizes properly then all but the few most recent maps are also finalized. Internal tree nodes with all finalized children are also finalized and can be collapsed into the lowest finalized ancestor. Similarly, internal nodes covering a range that has not been touched yet can be stored without having their children in memory, and they can be expanded on demand.</p> <p>Certain types of clients (those only interested in validation and not in using/serving log index data) have the option to just maintain this minimal log index state. Those who are interested in event history should probably also only keep the minimal state in memory and store the finalized and collapsed subtrees on disk. Clients can also initialize their log index with such a minimal state and then optionally regenerate the older parts from blocks and receipts locally. When the log index state of a finalized block is represented and no room for rollback is needed, the minimal tree representation simplifies into a set of Merkle branches leading to the map rows and to the <em>index entry</em> corresponding to <code>next_index</code> (with everything on the left side of these branches collapsed and nothing on their right sides expanded yet). Assuming an efficient encoding of the current <code>filter_map_rows</code> where the variable length of each filter row is encoded in two bytes and the column indices tightly packed into 3 bytes each, the minimal log index state can be serialized into 21300808 bytes. This number can be considered as an estimate of the amount of data required to initialize the log index data structure at any point.</p> <p>Note that initialization is also possible on an epoch boundary, in which case the log index is very cheap to initialize (only requires the last <em>block entry</em> branch before the epoch boundary and the first one after) but in this case all blocks and receipts between the boundary and the current head are required to generate the last unfinished epoch. Epoch boundary initialization can also be used to index further historical epochs after the initialization of the head state.</p> <p>Both head state initialization and epoch boundary initialization requires the extension of the Ethereum Wire Protocol through which clients can request Merkle multiproofs to initialize the required parts of the log index tree, using a recently finalized block as the starting point. Note that since the total amount of initialization data is too big to fit in a single devp2p response, the protocol splits the data into multiple subsets, each obtainable in the form of a separately verifiable log index Merkle proof. See the <a href="https://wg-eips.ritovision.com/7745/assets/wire_protocol_extension/">wire protocol extension</a> and <a href="https://wg-eips.ritovision.com/7745/assets/log_index_proof_format/">log index proof format</a> specs for further details.</p> <h2 id="rationale">Rationale</h2> <h3 id="design-goals">Design goals</h3> <p>The proposed data structure is intended to realize a balance between the cost of adding items and accessing old ones. In a search structure of a constantly growing dataset there is typically a tradeoff between the cost of adding new data and the cost of searcing the existing dataset. One extreme is just linearly storing the data, which is practically the case now with logs, with the bloom filters being mostly useless. The other extreme is one big Merkle tree with all <em>map values</em> ever used as keys and the list of all occurences (possibly in a further merkleized format) as values. With billions of unique <em>map values</em>, adding new entries here is expected to have costs similar to that of the state, with multiple lookups and modifications/insertions at random places in a database on the order of magnitude of hundreds of gigabytes. Another issue where this is similar to the state is that removing old entries is hard and expensive. Adding logs is supposed to be cheaper than writing the state so solutions between these two extremes were considered as potentially practical, with multiple smaller structures generated periodically.</p> <p>The <em>filter maps</em> have a fixed tree size and an efficient tree hashing scheme. Filter entries are sorted into rows based on content and position in a way that allows quick linear database access and size efficient Merkle proofs. The difficulties arising from certain types of events being much more frequent than others are also mitigated. Update and maintenance costs are also limited as tree nodes are eventually finalized and the number of non-finalized non-empty nodes is always hard capped, ensuring moderate memory requirements. Initialization costs of the data structure at any point of the chain are also capped. Additional database storage costs of <em>filter maps</em> is about 15-20% of the size of the actual logs, depending on certain implementation tradeoffs. The Merkle tree structure also makes it easy to discard entire epochs along with the corresponding Merkle subtrees, making the implementation of history expiry of the log index simple.</p> <h3 id="map-value-index-space">Map value index space</h3> <p>In each block a varying number of <em>map values</em> are emitted. In addition to inefficient search, another drawback of per-block fixed size bloom filters is the varying filter utilization leading to over-utilized filters giving many false positives in some blocks and/or wastefully under-utilized filters in some blocks. Block gas limits also tend to change significantly over the long term so any future-proof solution has to be able to adapt to the varying number of <em>map values</em> per block.</p> <p>Mapping <em>map values</em> on their own linear index space ensures uniform filter utilization of identically structured <em>filter maps</em>. Compared to the alternative of constantly changing adaptive filter size, this approach greatly improves the efficiency of database access and Merkle proofs. It also allows efficient search pattern filtering as each potential match provides exact position information.</p> <h3 id="index-entries-tree">Index entries tree</h3> <p>Hashing every event into the <code>index_entries</code> tree keyed by <em>map entry index</em> is additional work and complexity but it simplifies the proving process significantly. Proving the events based only on <em>map value indices</em> would be possible if receipts had a <em>map value index</em> pointer hashed into them (so the client could also verify that the received receipt actually covers the <em>map value index</em> derived from the <em>filter map</em>; in this case though an extra mechanism would be necessary to prove that the receipt is referenced in a block that is part of the same canonical chain where the log index root was referenced. Proving old canonical blocks is currently theoretically possible through the beacon chain but painful and also would require extra infrastructure. On the other hand, the <code>index_entries</code> tree not only solves the problem of proving the matching canonical receipts, with the <em>block entries</em> it also provides a convenient way to prove canonical EL blocks through EL data structures only, and even provides provable canonical block hash to block number lookups.</p> <p>Note though that storing the entire<code>index_entries</code> trees directly in their proposed merkleized format on disk is not really efficient. This is not an issue for validators that want to maintain a minimal state; for them, updating the <code>index_entries</code> subtrees is really cheap as they only need to maintain a single Merkle branch pointing to the next <em>map value index</em>. Provers can implement <code>index_entries</code> efficiently by storing a subset of the Merkle tree nodes (the ones at least a few levels below leaf level in order to save space) and generate the rest on demand based on the receipts that encode the same data in a more compact form.</p> <h3 id="alternative-filter-structures-considered">Alternative filter structures considered</h3> <p>One question considered was whether to periodically build lookup trees of events with each unique <em>map value</em> emitted in a given period being a separate key under which only the occurences of that specific event are listed, or to use a more compressed fixed size tree format where different <em>map values</em> might collide (though preferably not too many of them). This decision mostly boiled down to data access efficiency, both in terms of local disk access and remote Merkle proof size. Identically structured trees can be efficiently arranged in larger units (called <em>index epochs</em> here), with values belonging to the same key in subsequent trees of an epoch located close to each other. This improves database access speed. It also allows smaller Merkle proofs with a series of leaves encoded together in an efficient format and internal nodes on only two boundary branches. Database writes are also efficient as the order of adding tree entries is not random and all the non-finalized parts of the tree can be kept in memory with a hard capped memory requirement.</p> <p>The other design decision considered here was whether to hash entire index entries into the list of <em>map value</em> occurences or just store position info and have a separate tree of log entries. Though the separate <code>filter_maps</code> and <code>index_entries</code> structures do present some additional complexity, the second option was chosen because of the size of Merkle proofs. Looking up a rarely used <em>map value</em> means encountering more irrelevant entries than relevant ones. By adding probabilistic filter information to position information, the vast majority of the irrelevant entries can be filtered out after accessing/proving 3 bytes of data instead of an entire <em>map value</em> (32 bytes). When proving matches of multiple <em>map value</em> patterns this 10x advantage exists even with more frequent individual lookup values. Tests have shown that realistic log searches often yield a lot more matches for the individual <em>map values</em> themselves that the pattern itself. Pattern matching can be performed on the position information of individual potential matches and actual <em>index entries</em> only need to be proven at the potential pattern matches.</p> <p>In conclusion, for the given application the fixed tree size approach with separate position info plus probabilistic collision filter approach seemed to be the most appropriate.</p> <h3 id="false-positive-rate">False positive rate</h3> <p>From the <em>filter maps</em> a set of potential matches can be derived for any block range and <em>map value</em> or pattern of <em>map values</em>. These matches can then be looked up in the corresponding <code>index_entries</code> trees and actually matching events can be added to the set of results. The design guarantees that the set of potential matches includes all actual matches but and also has a consistently low false positive rate.</p> <p>False positives can happen when the quasi-random collision filter part of a <em>column index</em> accidentally matches the expected value even though it was generated by a <em>map value</em> other than the searched one. The chance of this happening is <code>VALUES_PER_MAP / MAP_WIDTH</code> per colliding enrty in a row that is relevant for the search. Assuming that most entries in a map are different from the searched one, assuming uniform random distribution of entries, the average number of colliding entries found in a relevant row is <code>VALUES_PER_MAP / MAP_HEIGHT</code> giving an average false positive rate of <code>VALUES_PER_MAP ** 2 / MAP_WIDTH / MAP_HEIGHT</code> per <em>filter map</em>.</p> <p>Though certain <em>map values</em> might be emitted a lot more than others and therefore the <em>row index</em> distribution might not be entirely uniform, periodical remapping of rows and using multiple <em>mapping layers</em> ensures that over a long enough search period random collisions with more frequent <em>map values</em> do even out. <em>Mapping layers</em> do have another consequence though; if any row has at least <code>MAX_ROW_LENGTH[0]</code> entries then the search logic requires looking into another row that is mapped to the searched <em>map value</em> on the next <em>mapping layer</em>. The maximum possible number of such rows is <code>VALUES_PER_MAP / MAX_ROW_LENGTH[0]</code> and therefore the chance of randomly hitting one is <code>VALUES_PER_MAP / MAX_ROW_LENGTH[0] / MAP_HEIGHT</code> in the worst case. In this case an extra row has to be processed, with extra chance of finding false positives. A collision with a frequent value at a certain <em>mapping layer</em> does not indicate a collision on the next layer though, therefore the expected number of entries in that row is no different from the first one. Having to process a third row would presume that the second one had at least <code>MAX_ROW_LENGTH[1]</code> entries. The chance of this happening after the first coincidence is practically negligible in the context of expected false positives.</p> <p>The expected number of false positives for a single <em>map value</em> search can be estimated as <code>VALUES_PER_MAP ** 2 / MAP_WIDTH / MAP_HEIGHT * (1 + VALUES_PER_MAP / MAX_ROW_LENGTH[0] / MAP_HEIGHT)</code> per <em>filter map</em>. With the proposed constants this roughly equals 0.0044 false positives per map. As of March 2025 the average number of <em>map values</em> emitted in a mainnet block is slightly over 1000 while a <em>filter map</em> consists of 65536 <em>map values</em>. This gives a rough estimate of one false positive per 14000 blocks, which costs the searcher an extra lookup in a <code>log_entries</code> tree. The expected number of false positives in the entire chain history is around 1200.</p> <p>Note that this is only true for a single value search while a typical pattern search requiring certain values on multiple positions has an exponentially lower false positive rate. For example if the pattern is [Addr, Topic1, Topic2] then three <em>map value</em> searches are performed and an actual log lookup is only necessary if the first search yields <code>N</code>, the second <code>N+1</code> and the third <code>N+2</code> simultaneously. If necessary, the rate can be easily reduced by using a higher <code>MAP_WIDTH</code>, at the cost of growing the size of encoded rows.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The existing log filter API (<code>eth_getLogs</code>, <code>eth_newFilter</code>, <code>eth_getFilterLogs</code>, <code>eth_getFilterChanges</code>) can be implemented with the new filter data structure. Applications relying on this API can operate without any change, benefiting from a higher search performance. Repricing the <code>LOG</code> opcode might be considered after performing benchmarks but the extra processing cost is not significant while the extra storage cost is around 15%. Other than that the EVM is not affected in any way as it only emits logs but does not directly access them.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="safe-access-with-a-remote-prover">Safe access with a remote prover</h3> <p>In order to prove a complete set of matches matching a given search pattern in a given block range, the prover needs to</p> <ul> <li>prove the <em>map value index</em> range that corresponds to the searched block number range by proving the <em>block entries</em> of <code>first_block - 1</code> and <code>last_block</code></li> <li>prove the relevant rows of <em>filter maps</em> based on <em>map index</em> and <em>row index</em> (verifier can determine the relevant rows in advance based on the <em>map values</em> in the search pattern and the relevant <em>map value index</em> range)</li> <li>prove the actual <em>index entry</em> belonging to any potentially matching <em>map value index</em> and also the <em>block entry</em> with the same block number if the <code>blockHash</code> of the log position info is needed</li> </ul> <p>Since all three steps can be realized with Merkle proofs of the same <code>LogIndex</code> structure referenced in the block headers, any search with a remove prover is as safe as the client's knowledge about the chain head.</p> <h3 id="deliberate-false-positive-attacks">Deliberate false positive attacks</h3> <p>The design guarantees that false positive rates do even out statistically over several epochs, even in case of random collisions with very frequent values, ensuring that an excessive amount false positives will not make the bandwidth and processing costs of the search prohibitively high. All of this is true for random collisions only though, not deliberately created collisions. A deliberate attack on a certain important <em>map value</em> in order to raise its false positive rate can not be ruled out entirely since with a low amount of filter data generated per <em>map value</em> it is always possible to "mine" another value that generates colliding filter data. The column mapping used here makes this attack a lot harder though, since the <em>column index</em> depends on both the <em>map value</em> and the exact <em>map value index</em>, making this attack only possible for block builders who are probably offered MEV rewards for much more lucrative manipulations of the transaction set than making the search of certain events slightly more expensive.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-07-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Stokeshttps://github.com/ralexstokes https://wg-eips.ritovision.com/7742/

Have CL verify blob maximum and have EL get target value from CL

<h2 id="abstract">Abstract</h2> <p>Update blob maximum and target verification from <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>.</p> <p>The execution layer no longer verifies the blob maximum and receives the target dynamically from the consensus layer.</p> <h2 id="motivation">Motivation</h2> <p>Following EIP-4844, the execution layer (EL) maintains a hard-coded blob target value and blob maximum value. Given the relationship of the EL and the consensus layer (CL) node software, the verification of the blob maximum is redundant so it can be removed entirely without any change in security. The blob maximum is still provided during block construction via the Engine API. This EIP also changes how the EL sources the current blob target value for two reasons:</p> <ol> <li> <p>Gain more flexibility over the value, rather than the static <code>TARGET == MAX // 2</code> relation in EIP-4844.</p> </li> <li> <p>Uncouple development and deployment of the CL and EL layers in the event it is desirable to change the blob target value.</p> </li> </ol> <h3 id="background">Background</h3> <p>The data facility introduced via EIP-4844 adds blobs to Ethereum blocks, which are simply fixed sets of data that can be included in the canonical chain but have no execution semantics (cf. <code>calldata</code> in an Ethereum transaction).</p> <p>The protocol specifies a maximum allowed blob count per block to prevent DoS vectors via the abuse of this data facility. The protocol also maintains an <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>-like "target" value for an intended running average amount of blob throughput per unit time. Blob usage is compared against this target to influence a "blob base fee" to administer allocation of this resource to users of the Ethereum protocol.</p> <p>Both of these values are currently hard-coded in the EL after EIP-4844 and the blob maximum is separately hard-coded in the CL following EIP-4844. This EIP proposes a set of changes to uncouple these values across the CL and EL to make development and deployment of changes to the blob count easier.</p> <h4 id="maximum-blobs-per-block">Maximum blobs per block</h4> <p>The blob maximum is verified in the CL node and the EL inherits this verification during the consistency check of the versioned hashes corresponding to each blob as specified by the Engine API. Because of this, the strict check specified by EIP-4844 is unnecessary.</p> <h4 id="target-amount-of-blobs-per-block">Target amount of blobs per block</h4> <p>The target is currently specified as a fixed value in relation to the blob count. The Ethereum community intends to increase the blob parameters as part of its scaling strategy and the ability to have a more flexible target value in relation to the blob max is desirable to reduce rigidity in this protocol parameter.</p> <p>Even if the EL keeps a fixed target value based on the max, removing the max implies the EL would not know what the target value should be. To address this lack of information, this EIP proposes the CL sends the current target value to the EL with each provided payload over the Engine API. The EL block header will also need to be extended with this target value to preserve the security of optimistic sync.</p> <h2 id="specification">Specification</h2> <h3 id="block-structure-and-validity">Block structure and validity</h3> <p>Upon activation of this EIP, execution clients <strong>MUST</strong> extend the header schema with an additional 64-bit field: the <code>target_blobs_per_block</code>. This value is set to the current target blob count. The Engine API is modified along with this EIP to provide the <code>target_blobs_per_block</code> with each payload and implementations can use this value to correctly set the block header field.</p> <p>Validity of the <code>target_blobs_per_block</code> is guaranteed from the consensus layer, much like how withdrawals are handled.</p> <p>When verifying a block, execution clients <strong>MUST</strong> ensure the target blob count in the block header matches the one provided by the consensus client.</p> <p>For a genesis block with no existing parent, the value should be set according to the agreed specification for the target blob count given by that genesis block's protocol rule set.</p> <h3 id="block-processing">Block processing</h3> <p>Upon activating this EIP (i.e. before processing any transactions), the verification of the blob maximum as given in EIP-4844 can be skipped. Concretely, this means any logic relating to <code>MAX_BLOB_GAS_PER_BLOCK</code> as given in EIP-4844 can be deprecated.</p> <p>Additionally, <code>calc_excess_blob_gas</code> is updated as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> target_blob_gas</span><span class="z-keyword"> =</span><span> parent</span><span>.</span><span>target_blobs_per_block</span><span class="z-keyword"> *</span><span class="z-constant"> GAS_PER_BLOB</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> &lt;</span><span> target_blob_gas</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> -</span><span> target_blob_gas</span></span></code></pre> <p>Otherwise, the specification of EIP-4844 is not changed. For example, blob base fee accounting and excess blob gas tracking occur in the exact same way.</p> <h3 id="block-construction">Block construction</h3> <p>The Engine API is extended to provide both the <code>target_blobs_per_block</code> and the <code>max_blobs_per_block</code> when the CL requests the EL to construct a payload for proposal.</p> <p>These values should be used to ensure the correct number of blobs are included in any constructed payload, and to ensure that the blob base fee accounting is correctly computed.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-not-have-the-cl-also-compute-the-blob-base-fee-and-remove-any-notion-of-blob-counts-from-el-processing">Why not have the CL also compute the blob base fee and remove any notion of blob counts from EL processing?</h3> <p>Hoisting the full computation into the CL is possible, but it does violate the separation of concerns between these two layers of the protocol stack. The CL maintains a maximum value to address e.g. DoS risks, and the EL maintains knowledge of the target value to address fee accounting. Putting the target computation in the CL violates the respective responsibilities of each layer.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No issues.</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <p>N/A</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-07-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Wei Han Nghttps://github.com/weiihann https://wg-eips.ritovision.com/7736/

Simple state expiry scheme in which only "extension-and-suffix trees" are expired.

<h2 id="abstract">Abstract</h2> <p>Adds an "update epoch" to the verkle tree extension node. When it is time for an epoch to expire, the extension node and its suffix nodes can be deleted.</p> <p>A new transaction type with a simple verkle proof pays for the costs of reactivating the extension and suffix nodes, and updating the epoch counter.</p> <h2 id="motivation">Motivation</h2> <p>Previous attempts at implementing state expiry have been stalled by the quickly-increasing complexity, require heavy change in the structure of ethereum (address space extension, oil, multiple trees, ...). This proposal is offering a simpler albeit non-exhaustive approach to state expiry: only removing the leaf nodes and leaving the rest of the tree intact. This removes the need for methods that would be detrimental to the user and developer experience.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Description</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_TIME</code></td><td>Fork activation time</td><td>TBD</td></tr> <tr><td><code>EPOCH_LENGTH</code></td><td>Duration of an epoch, in s</td><td>15778800 (6 months)</td></tr> <tr><td><code>INITIAL_EPOCH_COUNTER</code></td><td>The epoch that ends at timestamp <code>FORK_TIME</code></td><td>0</td></tr> <tr><td><code>NUM_ACTIVE_EPOCHS</code></td><td>Number of concurrently unexpired epochs</td><td>2</td></tr> <tr><td><code>RESURRECT_TX_TYPE</code></td><td>Type ID for resurrection transactions</td><td>TBD</td></tr> </tbody></table> <h3 id="change-to-the-verkle-tree">Change to the verkle tree</h3> <p>Add an integral variable called <code>current_epoch</code>. It is initialized to <code>INITIAL_EPOCH_COUNTER</code> before the fork, and contains the current epoch number.</p> <p>Add a new <code>last_epoch</code> field to the extension node:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> extension_and_suffix_tree</span><span>(</span><span class="z-variable z-parameter z-function">stem</span><span>:</span><span> bytes31</span><span>,</span><span class="z-variable z-parameter z-function"> values</span><span>:</span><span> Dict</span><span>[</span><span>byte</span><span>,</span><span> bytes32</span><span>]</span><span>,</span><span class="z-variable z-parameter z-function"> last_epoch</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> sub_leaves</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> *</span><span class="z-constant"> 512</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> suffix</span><span>,</span><span> value</span><span class="z-keyword"> in</span><span> values</span><span>.</span><span>items</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> sub_leaves</span><span>[</span><span class="z-constant">2</span><span class="z-keyword"> *</span><span> suffix</span><span>]</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>value</span><span>[</span><span>:</span><span class="z-constant">16</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">128</span></span> <span class="giallo-l"><span> sub_leaves</span><span>[</span><span class="z-constant">2</span><span class="z-keyword"> *</span><span> suffix</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>]</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>value</span><span>[</span><span class="z-constant">16</span><span>:</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> C1</span><span class="z-keyword"> =</span><span> compute_commitment_root</span><span>(</span><span>sub_leaves</span><span>[</span><span>:</span><span class="z-constant">256</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> C2</span><span class="z-keyword"> =</span><span> compute_commitment_root</span><span>(</span><span>sub_leaves</span><span>[</span><span class="z-constant">256</span><span>:</span><span>]</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> compute_commitment_root</span><span>(</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Extension marker</span></span> <span class="giallo-l"><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>stem</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> group_to_scalar_field</span><span>(</span><span>C1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> group_to_scalar_field</span><span>(</span><span>C2</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> last_epoch</span><span>]</span><span class="z-keyword"> +</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Added in this EIP</span></span> <span class="giallo-l"><span> [</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> *</span><span class="z-constant"> 251</span><span>)</span></span></code></pre> <p>The following rules are added to tree update operations:</p> <ul> <li>For a read or write event to the tree, check that <code>current_epoch &lt; last_epoch + NUM_ACTIVE_EPOCHS</code>. <ul> <li>If this is <code>true</code>, proceed with the write/read</li> <li>Otherwise, revert.</li> </ul> </li> <li><code>last_epoch</code> is updated with the value of <code>current_epoch</code> each time that a <em>write</em> event is processed for this extension node.</li> </ul> <h3 id="expiry">Expiry</h3> <p>At the start of block processing, before transactions are executed, run <code>check_epoch_end</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> check_epoch_end</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>timestamp</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_TIME</span><span class="z-keyword"> +</span><span> current_epoch</span><span class="z-keyword"> *</span><span class="z-constant"> EPOCH_LENGTH</span><span>:</span></span> <span class="giallo-l"><span> current_epoch</span><span class="z-keyword"> =</span><span> current_epoch</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> schedule_expiry</span><span>(</span><span>current_epoch</span><span class="z-keyword">-</span><span class="z-constant">NUM_ACTIVE_EPOCHS</span><span>)</span></span></code></pre> <p>It is left to client implementers to decide on the behavior of the <code>schedule_expiry</code> function.</p> <p>Data that needs to be kept for the expiry:</p> <ul> <li>the <code>stem</code> value, so that siblings can be inserted</li> <li>The commitment <code>C</code> to the node</li> </ul> <p>That data is referred to as the <em>keepsake</em> for this extension-and-suffix node.</p> <p><strong>Note</strong>: that actual deletion may not happen before the first block in the epoch has finalized, unless there is a way for the client to recover the block in case of a reorg.</p> <h3 id="resurrection">Resurrection</h3> <p>The resurrection transaction is defined as follows:</p> <p><code>RESURRECT_TX_TYPE|ssz(Vector[stem,last_epoch,values])</code></p> <p>Where:</p> <ul> <li><code>stem</code> is used to find the location in the tree, so that the node can be recreated;</li> <li><code>last_epoch</code> and <code>values</code> are the items that were deleted;</li> </ul> <p>At the start of the validation, charge the costs using constants defined in <a href="https://wg-eips.ritovision.com/4762/">EIP-4762</a>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> resurrect_gas_cost</span><span>(</span><span class="z-variable z-parameter z-function">values</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> WITNESS_BRANCH_COST</span><span class="z-keyword"> +</span><span> </span></span> <span class="giallo-l"><span class="z-constant"> SUBTREE_EDIT_COST</span><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> sum</span><span>(</span><span class="z-constant">WITNESS_CHUNK_COST</span><span class="z-keyword"> +</span><span class="z-constant"> CHUNK_EDIT_COST</span><span class="z-keyword"> +</span><span class="z-constant"> CHUNK_FILL_COST</span><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span> values</span><span>)</span></span></code></pre> <p>Once the gas cost has been paid, the validation process begins:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_subtrees</span><span>(</span><span class="z-variable z-parameter z-function">tree</span><span>,</span><span class="z-variable z-parameter z-function"> tx</span><span>,</span><span class="z-variable z-parameter z-function"> current_epoch</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The tx is a SSZ payload</span></span> <span class="giallo-l"><span> subtrees</span><span class="z-keyword"> =</span><span> deserialize_ssz</span><span>(</span><span>tx</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> subtrees</span><span class="z-keyword"> ==</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> false</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Process all subtrees in the transaction</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> subtree</span><span class="z-keyword"> in</span><span> subtrees</span><span>:</span></span> <span class="giallo-l"><span> ok</span><span class="z-keyword"> =</span><span> validate_subtree</span><span>(</span><span>tree</span><span>,</span><span> subtree</span><span>.</span><span>stem</span><span>,</span><span> subtree</span><span>.</span><span>values</span><span>,</span><span> subtree</span><span>.</span><span>last_epoch</span><span>,</span><span> current_epoch</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> ok</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> false</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> true</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_subtree</span><span>(</span><span class="z-variable z-parameter z-function">tree</span><span>,</span><span class="z-variable z-parameter z-function"> stem</span><span>,</span><span class="z-variable z-parameter z-function"> values</span><span>,</span><span class="z-variable z-parameter z-function"> last_epoch</span><span>,</span><span class="z-variable z-parameter z-function"> current_epoch</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Compute the commitment to the expired</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> tree, get the </span></span> <span class="giallo-l"><span> expired_C</span><span class="z-keyword"> =</span><span> extension_and_suffix_tree</span><span>(</span><span>stem</span><span>,</span><span> values</span><span>,</span><span> last_epoch</span><span>)</span></span> <span class="giallo-l"><span> expired</span><span class="z-keyword"> =</span><span> tree</span><span>.</span><span>get_keepsake</span><span>(</span><span>stem</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> keepsake</span><span>.</span><span>C</span><span class="z-keyword"> !=</span><span> expired_C</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Replace the keepsake with the resurrected</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> extension-and-suffix tree.</span></span> <span class="giallo-l"><span> new_C</span><span class="z-keyword"> =</span><span> extension_and_suffix_tree</span><span>(</span><span>stem</span><span>,</span><span> values</span><span>,</span><span> current_epoch</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> tree</span><span>.</span><span>resurrect_subtree</span><span>(</span><span>stem</span><span>,</span><span> new_C</span><span>,</span><span> values</span><span>,</span><span> current_epoch</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> None</span></span></code></pre> <p>where <code>resurrect_subtree</code> will return <code>None</code> upon success, and an error otherwise.</p> <h2 id="rationale">Rationale</h2> <p>This approach has the benefit of simplicity, over previous proposals for state expiry:</p> <ul> <li>no Address Space Extension (ASE) required</li> <li>it only uses a single tree instead of multiple, per-epoch trees</li> <li>smaller resurrection proofs, as only providing the data is necessary to resurrect.</li> <li>clear gas costs</li> <li>only expire "cold" data, the "hot" data set remains active</li> <li>it is forward-compatible, as ASE or multiple trees are still possible.</li> <li>the exponentiation/addition computation for <code>current_epoch</code> need only be paid once per epoch, which is quickly amortized.</li> </ul> <p>While it's not deleting <em>all</em> the data, it deletes <em>most</em> of it, namely the values and subcommitments, while retaining the ability to easily insert siblings.</p> <p>It is also more expensive than resurrecting a single leaf, which is the cost paid for simplification.</p> <p>The reason why only writes update the resurrection counter, is that any update to the resurrection counter has the effect of a write. Doing so would mean either:</p> <ul> <li>Increasing the cost of a read to that of a write. This would increase the gas costs even more than they did in EIP-4762.</li> <li>Effectively doing a write for the cost of a read. This would both neuter state expiry and possibly add a DOS vector.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal is backwards-compatible with verkle, as by default the value for the 4th (index starting at 0) evaluation point is set to <code>0</code> in <a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a>, which is the value of <code>INITIAL_EPOCH_COUNTER</code>.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-06-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Francesco D'Amatofrancesco.damato@ethereum.org Barnabé Monnotbarnabe.monnot@ethereum.org Michael Neudermichael.neuder@ethereum.org Potuzhttps://github.com/potuz Justin Tragliajtraglia@ethereum.org Terence Tsaottsao@offchainlabs.com https://wg-eips.ritovision.com/7732/

Separates the ethereum block in consensus and execution parts, adds a mechanism for the consensus proposer to choose the execution proposer.

<h2 id="abstract">Abstract</h2> <p>This EIP fundamentally changes the way an Ethereum block is validated by decoupling the execution validation from the consensus validation both logically as well as temporally. It does so by introducing a new in-protocol entity called <em>builders</em> and adding a new duty (submitting <em>payload timeliness attestations</em>) to Ethereum validators. The <code>ExecutionPayload</code> field of the <code>BeaconBlockBody</code> is removed and instead it is replaced by a signed commitment (a <code>SignedExecutionPayloadBid</code> object) from a builder to later reveal the corresponding execution payload. This commitment specifies in particular the blockhash of the execution block and a <em>value</em> to be paid to the beacon block proposer. When processing the <code>BeaconBlock</code>, the committed value is deducted from the builder's beacon chain balance and later a withdrawal is placed to an address, of the proposer's choosing, in the execution layer. A subset of validators in the beacon committee is assigned to the <em>Payload Timeliness Committee</em> (PTC), these validators are tasked to attest (by broadcasting a <code>PayloadAttestationMessage</code>) to whether the corresponding builder has revealed the committed execution payload (with the right blockhash) in a timely fashion and whether the correspoding blob data was available according to their view. PTC members are not required to validate the execution payload, execution validation is thus deferred until the next beacon block validation. While builder's are staked entities, their stake is not actively validating the beacon chain, they are not subject to the usual deposit and exit churn/queues and can be staked for as little as 1ETH. While the in-protocol payment via withdrawals is trustlessly deducted from this stake, the protocol also accomodates for trusted payments in the form of <em>promises</em> to be fulfiled elsewhere.</p> <h2 id="motivation">Motivation</h2> <p>This EIP solves a different set of unrelated important problems.</p> <ul> <li>An overwhelming majority of beacon block proposers outsource the construction of the execution payload within their blocks to a third party (henceforth called a <em>builder</em>). In order to do so, they request the hash tree root (HTR) of a promised execution payload and submit a <code>SignedBlindedBeaconBlock</code> to a trusted party that is tasked with replacing the HTR with the full execution payload (received from the builder) before broadcasting. This EIP allows for a trust-free fair exchange between the beacon block proposer and the builder, guaranteeing that an honest beacon block proposer will receive payment from the builder regardless of the latter's actions and that the honest builder's payload will be the canonical head of the chain regardless of the proposer's action.</li> <li>Currently, validators have the time between receiving the full beacon block (including an execution payload) and the attesting deadline (4 seconds in Ethereum mainnet) to perform both consensus and execution state transition functions, check blob data availability and evaluate the new head of the blockchain. The remainder of the slot time is spent doing less CPU-intense and critical task. By separating the validation of the execution and consensus part of the block, validators are only tasked to perform the consensus state transition function in this critical time before attesting, while execution and data availability validation is deferred for most of the remainder of the slot (between the builder's reveal time and the next attestation deadline).</li> <li>By removing the full execution payload size from the consensus block, it allows for faster network propagation on the critical path.</li> <li>It removes the increased reorg likeliness of including blob transactions in blocks given the natural increase in timelines for data availability checks and the fact that the builder may broadcast the blob sidecars even before attestations for the beacon block have been released.</li> <li>It prevents validators from missing attestations and strengthens the weight properties of fork choice in the event that builders produce invalid payloads.</li> <li>It removes the need to use trusted middleware in order to delegate block construction to a builder.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution Layer</h3> <p>No changes are required.</p> <h3 id="consensus-layer">Consensus Layer</h3> <p>The full consensus changes can be found in the consensus-specs Github repository. They are split between:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/beacon-chain.md">Beacon Chain</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/fork-choice.md">Fork choice</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/p2p-interface.md">P2P</a> changes.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/validator.md">Honest validator guide</a> changes.</li> <li>A new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/builder.md">honest builder</a> guide.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas/fork.md">Fork logic</a> changes.</li> </ul> <p>A summary of the main changes is included below, the <a href="https://wg-eips.ritovision.com/7732/#rationale">Rationale</a> section contains explanation for most of the design decisions around these changes.</p> <h4 id="beacon-chain-changes">Beacon chain changes</h4> <h5 id="types">Types</h5> <table><thead><tr><th>Name</th><th>SSZ equivalent</th><th>Description</th></tr></thead><tbody> <tr><td><code>BuilderIndex</code></td><td><code>uint64</code></td><td>Builder registry index</td></tr> </tbody></table> <h5 id="constants">Constants</h5> <h6 id="index-flags">Index flags</h6> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>BUILDER_INDEX_FLAG</code></td><td><code>uint64(2**40)</code></td><td>Bitwise flag which indicates that a <code>ValidatorIndex</code> should be treated as a <code>BuilderIndex</code></td></tr> </tbody></table> <h5 id="domains">Domains</h5> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>DOMAIN_BEACON_BUILDER</code></td><td><code>DomainType('0x0B000000')</code></td></tr> <tr><td><code>DOMAIN_PTC_ATTESTER</code></td><td><code>DomainType('0x0C000000')</code></td></tr> <tr><td><code>DOMAIN_PROPOSER_PREFERENCES</code></td><td><code>DomainType('0x0D000000')</code></td></tr> </tbody></table> <h5 id="misc">Misc</h5> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>BUILDER_INDEX_SELF_BUILD</code></td><td><code>BuilderIndex(UINT64_MAX)</code></td><td>Value which indicates the proposer built the payload</td></tr> <tr><td><code>BUILDER_PAYMENT_THRESHOLD_NUMERATOR</code></td><td><code>uint64(6)</code></td><td></td></tr> <tr><td><code>BUILDER_PAYMENT_THRESHOLD_DENOMINATOR</code></td><td><code>uint64(10)</code></td><td></td></tr> </tbody></table> <h5 id="withdrawal-prefixes">Withdrawal prefixes</h5> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>BUILDER_WITHDRAWAL_PREFIX</code></td><td><code>Bytes1('0x03')</code></td><td>Withdrawal credential prefix for a builder</td></tr> </tbody></table> <h5 id="preset">Preset</h5> <h6 id="misc-1">Misc</h6> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>PTC_SIZE</code></td><td><code>uint64(2**9)</code> (= 512)</td></tr> </tbody></table> <h6 id="max-operations-per-block">Max operations per block</h6> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAX_PAYLOAD_ATTESTATIONS</code></td><td><code>4</code></td></tr> </tbody></table> <h6 id="state-list-lengths">State list lengths</h6> <table><thead><tr><th>Name</th><th>Value</th><th>Unit</th></tr></thead><tbody> <tr><td><code>BUILDER_REGISTRY_LIMIT</code></td><td><code>uint64(2**40)</code> (= 1,099,511,627,776)</td><td>Builders</td></tr> <tr><td><code>BUILDER_PENDING_WITHDRAWALS_LIMIT</code></td><td><code>uint64(2**20)</code> (= 1,048,576)</td><td>Builder pending withdrawals</td></tr> </tbody></table> <h6 id="withdrawals-processing">Withdrawals processing</h6> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAX_BUILDERS_PER_WITHDRAWALS_SWEEP</code></td><td><code>2**14</code> (= 16,384)</td></tr> </tbody></table> <h5 id="configuration">Configuration</h5> <h6 id="time-parameters">Time parameters</h6> <table><thead><tr><th>Name</th><th>Value</th><th style="text-align: center">Unit</th></tr></thead><tbody> <tr><td><code>MIN_BUILDER_WITHDRAWABILITY_DELAY</code></td><td><code>uint64(2**6)</code> (= 64)</td><td style="text-align: center">epochs</td></tr> </tbody></table> <h5 id="containers">Containers</h5> <h6 id="new-containers">New containers</h6> <h6 id="builder"><code>Builder</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Builder</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> pubkey</span><span>:</span><span> BLSPubkey</span></span> <span class="giallo-l"><span> version</span><span>:</span><span> uint8</span></span> <span class="giallo-l"><span> execution_address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> balance</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> deposit_epoch</span><span>:</span><span> Epoch</span></span> <span class="giallo-l"><span> withdrawable_epoch</span><span>:</span><span> Epoch</span></span></code></pre><h6 id="builderpendingpayment"><code>BuilderPendingPayment</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BuilderPendingPayment</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> weight</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> withdrawal</span><span>:</span><span> BuilderPendingWithdrawal</span></span></code></pre><h6 id="builderpendingwithdrawal"><code>BuilderPendingWithdrawal</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BuilderPendingWithdrawal</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> fee_recipient</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> builder_index</span><span>:</span><span> BuilderIndex</span></span></code></pre><h6 id="payloadattestationdata"><code>PayloadAttestationData</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> PayloadAttestationData</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> beacon_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> payload_present</span><span>:</span><span> boolean</span></span> <span class="giallo-l"><span> blob_data_available</span><span>:</span><span> boolean</span></span></code></pre><h6 id="payloadattestation"><code>PayloadAttestation</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> PayloadAttestation</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> aggregation_bits</span><span>:</span><span> Bitvector</span><span>[</span><span class="z-constant">PTC_SIZE</span><span>]</span></span> <span class="giallo-l"><span> data</span><span>:</span><span> PayloadAttestationData</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h6 id="payloadattestationmessage"><code>PayloadAttestationMessage</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> PayloadAttestationMessage</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> validator_index</span><span>:</span><span> ValidatorIndex</span></span> <span class="giallo-l"><span> data</span><span>:</span><span> PayloadAttestationData</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h6 id="indexedpayloadattestation"><code>IndexedPayloadAttestation</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> IndexedPayloadAttestation</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> attesting_indices</span><span>:</span><span> List</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> PTC_SIZE</span><span>]</span></span> <span class="giallo-l"><span> data</span><span>:</span><span> PayloadAttestationData</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h6 id="executionpayloadbid"><code>ExecutionPayloadBid</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayloadBid</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> parent_block_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> parent_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> block_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span> prev_randao</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> fee_recipient</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> builder_index</span><span>:</span><span> BuilderIndex</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> execution_payment</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> blob_kzg_commitments</span><span>:</span><span> List</span><span>[</span><span>KZGCommitment</span><span>,</span><span class="z-constant"> MAX_BLOB_COMMITMENTS_PER_BLOCK</span><span>]</span></span></code></pre><h6 id="signedexecutionpayloadbid"><code>SignedExecutionPayloadBid</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SignedExecutionPayloadBid</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> message</span><span>:</span><span> ExecutionPayloadBid</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h6 id="executionpayloadenvelope"><code>ExecutionPayloadEnvelope</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayloadEnvelope</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> ExecutionPayload</span></span> <span class="giallo-l"><span> execution_requests</span><span>:</span><span> ExecutionRequests</span></span> <span class="giallo-l"><span> builder_index</span><span>:</span><span> BuilderIndex</span></span> <span class="giallo-l"><span> beacon_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> state_root</span><span>:</span><span> Root</span></span></code></pre><h6 id="signedexecutionpayloadenvelope"><code>SignedExecutionPayloadEnvelope</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SignedExecutionPayloadEnvelope</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> message</span><span>:</span><span> ExecutionPayloadEnvelope</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> BLSSignature</span></span></code></pre><h6 id="modified-containers">Modified containers</h6> <h6 id="beaconblockbody"><code>BeaconBlockBody</code></h6> <p><em>Note</em>: The removed fields (<code>execution_payload</code>, <code>blob_kzg_commitments</code>, and <code>execution_requests</code>) now exist in <code>ExecutionPayloadEnvelope</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconBlockBody</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> randao_reveal</span><span>:</span><span> BLSSignature</span></span> <span class="giallo-l"><span> eth1_data</span><span>:</span><span> Eth1Data</span></span> <span class="giallo-l"><span> graffiti</span><span>:</span><span> Bytes32</span></span> <span class="giallo-l"><span> proposer_slashings</span><span>:</span><span> List</span><span>[</span><span>ProposerSlashing</span><span>,</span><span class="z-constant"> MAX_PROPOSER_SLASHINGS</span><span>]</span></span> <span class="giallo-l"><span> attester_slashings</span><span>:</span><span> List</span><span>[</span><span>AttesterSlashing</span><span>,</span><span class="z-constant"> MAX_ATTESTER_SLASHINGS_ELECTRA</span><span>]</span></span> <span class="giallo-l"><span> attestations</span><span>:</span><span> List</span><span>[</span><span>Attestation</span><span>,</span><span class="z-constant"> MAX_ATTESTATIONS_ELECTRA</span><span>]</span></span> <span class="giallo-l"><span> deposits</span><span>:</span><span> List</span><span>[</span><span>Deposit</span><span>,</span><span class="z-constant"> MAX_DEPOSITS</span><span>]</span></span> <span class="giallo-l"><span> voluntary_exits</span><span>:</span><span> List</span><span>[</span><span>SignedVoluntaryExit</span><span>,</span><span class="z-constant"> MAX_VOLUNTARY_EXITS</span><span>]</span></span> <span class="giallo-l"><span> sync_aggregate</span><span>:</span><span> SyncAggregate</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP7732]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Removed `execution_payload`</span></span> <span class="giallo-l"><span> bls_to_execution_changes</span><span>:</span><span> List</span><span>[</span><span>SignedBLSToExecutionChange</span><span>,</span><span class="z-constant"> MAX_BLS_TO_EXECUTION_CHANGES</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP7732]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Removed `blob_kzg_commitments`</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP7732]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Removed `execution_requests`</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> signed_execution_payload_bid</span><span>:</span><span> SignedExecutionPayloadBid</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> payload_attestations</span><span>:</span><span> List</span><span>[</span><span>PayloadAttestation</span><span>,</span><span class="z-constant"> MAX_PAYLOAD_ATTESTATIONS</span><span>]</span></span></code></pre><h6 id="beaconstate"><code>BeaconState</code></h6> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconState</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> genesis_time</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> genesis_validators_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> fork</span><span>:</span><span> Fork</span></span> <span class="giallo-l"><span> latest_block_header</span><span>:</span><span> BeaconBlockHeader</span></span> <span class="giallo-l"><span> block_roots</span><span>:</span><span> Vector</span><span>[</span><span>Root</span><span>,</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span><span>]</span></span> <span class="giallo-l"><span> state_roots</span><span>:</span><span> Vector</span><span>[</span><span>Root</span><span>,</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span><span>]</span></span> <span class="giallo-l"><span> historical_roots</span><span>:</span><span> List</span><span>[</span><span>Root</span><span>,</span><span class="z-constant"> HISTORICAL_ROOTS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> eth1_data</span><span>:</span><span> Eth1Data</span></span> <span class="giallo-l"><span> eth1_data_votes</span><span>:</span><span> List</span><span>[</span><span>Eth1Data</span><span>,</span><span class="z-constant"> EPOCHS_PER_ETH1_VOTING_PERIOD</span><span class="z-keyword"> *</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span></span> <span class="giallo-l"><span> eth1_deposit_index</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> validators</span><span>:</span><span> List</span><span>[</span><span>Validator</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> balances</span><span>:</span><span> List</span><span>[</span><span>Gwei</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> randao_mixes</span><span>:</span><span> Vector</span><span>[</span><span>Bytes32</span><span>,</span><span class="z-constant"> EPOCHS_PER_HISTORICAL_VECTOR</span><span>]</span></span> <span class="giallo-l"><span> slashings</span><span>:</span><span> Vector</span><span>[</span><span>Gwei</span><span>,</span><span class="z-constant"> EPOCHS_PER_SLASHINGS_VECTOR</span><span>]</span></span> <span class="giallo-l"><span> previous_epoch_participation</span><span>:</span><span> List</span><span>[</span><span>ParticipationFlags</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> current_epoch_participation</span><span>:</span><span> List</span><span>[</span><span>ParticipationFlags</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> justification_bits</span><span>:</span><span> Bitvector</span><span>[</span><span class="z-constant">JUSTIFICATION_BITS_LENGTH</span><span>]</span></span> <span class="giallo-l"><span> previous_justified_checkpoint</span><span>:</span><span> Checkpoint</span></span> <span class="giallo-l"><span> current_justified_checkpoint</span><span>:</span><span> Checkpoint</span></span> <span class="giallo-l"><span> finalized_checkpoint</span><span>:</span><span> Checkpoint</span></span> <span class="giallo-l"><span> inactivity_scores</span><span>:</span><span> List</span><span>[</span><span>uint64</span><span>,</span><span class="z-constant"> VALIDATOR_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> current_sync_committee</span><span>:</span><span> SyncCommittee</span></span> <span class="giallo-l"><span> next_sync_committee</span><span>:</span><span> SyncCommittee</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [Modified in Gloas:EIP7732]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Removed `latest_execution_payload_header`</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> latest_execution_payload_bid</span><span>:</span><span> ExecutionPayloadBid</span></span> <span class="giallo-l"><span> next_withdrawal_index</span><span>:</span><span> WithdrawalIndex</span></span> <span class="giallo-l"><span> next_withdrawal_validator_index</span><span>:</span><span> ValidatorIndex</span></span> <span class="giallo-l"><span> historical_summaries</span><span>:</span><span> List</span><span>[</span><span>HistoricalSummary</span><span>,</span><span class="z-constant"> HISTORICAL_ROOTS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> deposit_requests_start_index</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> deposit_balance_to_consume</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> exit_balance_to_consume</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> earliest_exit_epoch</span><span>:</span><span> Epoch</span></span> <span class="giallo-l"><span> consolidation_balance_to_consume</span><span>:</span><span> Gwei</span></span> <span class="giallo-l"><span> earliest_consolidation_epoch</span><span>:</span><span> Epoch</span></span> <span class="giallo-l"><span> pending_deposits</span><span>:</span><span> List</span><span>[</span><span>PendingDeposit</span><span>,</span><span class="z-constant"> PENDING_DEPOSITS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> pending_partial_withdrawals</span><span>:</span><span> List</span><span>[</span><span>PendingPartialWithdrawal</span><span>,</span><span class="z-constant"> PENDING_PARTIAL_WITHDRAWALS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> pending_consolidations</span><span>:</span><span> List</span><span>[</span><span>PendingConsolidation</span><span>,</span><span class="z-constant"> PENDING_CONSOLIDATIONS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span> proposer_lookahead</span><span>:</span><span> Vector</span><span>[</span><span>ValidatorIndex</span><span>,</span><span> (</span><span class="z-constant">MIN_SEED_LOOKAHEAD</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> builders</span><span>:</span><span> List</span><span>[</span><span>Builder</span><span>,</span><span class="z-constant"> BUILDER_REGISTRY_LIMIT</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> next_withdrawal_builder_index</span><span>:</span><span> BuilderIndex</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> execution_payload_availability</span><span>:</span><span> Bitvector</span><span>[</span><span class="z-constant">SLOTS_PER_HISTORICAL_ROOT</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> builder_pending_payments</span><span>:</span><span> Vector</span><span>[</span><span>BuilderPendingPayment</span><span>,</span><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span class="z-constant"> SLOTS_PER_EPOCH</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> builder_pending_withdrawals</span><span>:</span><span> List</span><span>[</span><span>BuilderPendingWithdrawal</span><span>,</span><span class="z-constant"> BUILDER_PENDING_WITHDRAWALS_LIMIT</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> latest_block_hash</span><span>:</span><span> Hash32</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in Gloas:EIP7732]</span></span> <span class="giallo-l"><span> payload_expected_withdrawals</span><span>:</span><span> List</span><span>[</span><span>Withdrawal</span><span>,</span><span class="z-constant"> MAX_WITHDRAWALS_PER_PAYLOAD</span><span>]</span></span></code></pre> <p>The <code>BeaconState</code> container is modified with the addition of:</p> <ul> <li><code>builders</code>, of type <code>List[Builder, BUILDER_REGISTRY_LIMIT]</code> to track the new in-protocol staked builders.</li> <li><code>next_withdrawal_builder_index</code> of type <code>BuilderIndex</code> to help tracking builder withdrawals.</li> <li><code>execution_payload_availability</code>, of type <code>Bitvector[SLOTS_PER_HISTORICAL_ROOT]</code> to track the presence of execution payloads on the canonical chain.</li> <li><code>builder_pending_payments</code>, of type <code>Vector[BuilderPendingPayment, 2 * SLOTS_PER_EPOCH]</code> to track pending payments from builders to proposers before the execution payload has been processed.</li> <li><code>builder_pending_withdrawals</code>, of type <code>List[BuilderPendingWithdrawal, BUILDER_PENDING_WITHDRAWALS_LIMIT]</code> to track pending withdrawals to the execution layer with the builders' payments.</li> <li><code>latest_block_hash</code>, of type <code>Hash32</code>, to track the blockhash of the last execution payload in the blockchain.</li> <li><code>payload_expected_withdrawals</code> of type <code>List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD]</code> to track the latest withdrawals that were deducted in the consensus layer and need to still be honored in the Execution Layer.</li> </ul> <p>The <code>BeaconBlockBody</code> is modified with the addition of:</p> <ul> <li><code>signed_execution_payload_bid</code> of type <code>SignedExecutionPayloadBid</code> with the builder's commitment.</li> <li><code>payload_attestations</code> of type <code>List[PayloadAttestation, MAX_PAYLOAD_ATTESTATIONS]</code> a list of PTC attestations from the previous slot.</li> </ul> <p>The <code>ExecutionPayloadHeader</code> object is changed (and renamed to <code>ExecutionPayloadBid</code>) to only track the minimum information needed to commit to a builder's payload.</p> <p>State transition logic is modified by:</p> <ul> <li>A new beacon state getter <code>get_ptc</code> returns the PTC members for a given slot.</li> <li><code>process_withdrawals</code> is modified as follows. Withdrawals are obtained directly from the beacon state instead of the execution payload. They are deducted from the beacon chain. The beacon state <code>latest_withdrawals_root</code> is updated with the HTR of this list. The next execution payload MUST include withdrawals matching the <code>state.latest_withdrawals_root</code>.</li> <li><code>process_execution_payload</code> is removed from <code>process_block</code>. Instead a new function <code>process_execution_payload_bid</code> is included, this function validates the <code>SignedExecutionPayloadBid</code> included in the <code>BeaconBlockBody</code>, ensures the payment from the builder's balance can be deducted and adds a <code>BuilderPendingPayment</code> object to the beacon state.</li> <li><code>process_deposit_request</code> is removed from <code>process_operations</code> and deferred until <code>process_execution_payload</code>. Special care is added for deposit requests from new validator pubkeys, with withdrawal credentials starting with the prefix <code>BUILDER_WITHDRAWAL_PREFIX</code>. These deposits are immediately added to the beacon chain and processed as new builders.</li> <li><code>process_withdrawal_request</code> is removed from <code>process_operations</code> and deferred until <code>process_execution_payload</code>.</li> <li><code>process_consolidation_request</code> is removed from <code>process_operations</code> and deferred until <code>process_execution_payload</code>.</li> <li>A new <code>process_payload_attestation</code> is added to <code>process_operations</code>, this function validates the payload timeliness attestations broadcast by the PTC members.</li> <li><code>process_execution_payload</code> is now called as a separate helper when receiving a <code>SignedExecutionPayloadEnvelope</code> on the P2P layer. This function in particular checks that the HTR of the resulting beacon state coincides with the committed one in the payload envelope. On sucessful processing of the execution payload, the corresponding <code>BuilderPendingPayment</code> is removed from the beacon state and a <code>BuilderPendingWithdrawal</code> is queued.</li> </ul> <p>Epoch processing is modified by addition of a new helper function <code>process_builder_pending_payments</code>, that processes the builder pending payments from those payloads that were not included in the canonical chain. Although there is no change in the <code>AttestationData</code> object, the <code>index</code> field which is unused since the Electra fork, is now repurposed to signal payload availability. The value of <code>0</code> is used when attesting to the current beacon block or a past beacon block without a payload present, and the value of <code>1</code> is used to attest to a past beacon block with a payload present.</p> <h4 id="fork-choice-changes">Fork-Choice changes</h4> <p>Forkchoice is changed substantially to deal with the fact that forkchoice nodes can have different payload content.</p> <h4 id="p2p-changes">P2P changes</h4> <ul> <li>A new global topic for broadcasting <code>SignedExecutionPayloadBid</code> messages (builder bids).</li> <li>A new global topic for broadcasting <code>PayloadAttestationMessage</code> objects.</li> <li>A new global topic for broadcasting <code>ProposerPreferences</code> objects.</li> </ul> <h3 id="engine-api">Engine API</h3> <p>No changes needed.</p> <h2 id="rationale">Rationale</h2> <h3 id="staked-builders">Staked builders</h3> <p>Being a builder is a new type of entity tracked in the beacon state. As such builders are staked in the beacon chain and they have their own withdrawal credential prefix. This allows for in-protocol trustless enforcement of the builder's payment to the proposer. Alternatively, payment could be enforced in the Execution Layer (EL) at the cost of adding the corresponding EL consensus-changing logic. Payments in the EL have the advantage of not requiring the builder to periodically submit deposit transactions to replenish their validator balance. Both systems require availability of funds before the payload is revealed: in the Consensus Layer (CL) this is done by getting builders to stake. In the EL this is done with a balance check and a payment transaction. This transaction can be checked without executing the payload only if it the first transaction of the block.</p> <h3 id="delayed-validation">Delayed validation</h3> <p>The Payload Timeliness Committee members do not need to validate the execution payload before attesting to it. They perform basic checks such as verifying the builder's signature, and the correct blockhash is included. This takes away the full execution payload validation from the hot path of validation of an Ethereum block, giving the next proposer 6 seconds (<code>SECONDS_PER_SLOT * 2 // INTERVALS_PER_SLOT</code>) to validate the payload and every other validator 9 seconds (<code>SECONDS_PER_SLOT * 3 // INTERVALS_PER_SLOT</code>). From a user UX perspective, a transaction included in slot <code>N</code> by the builder is not widely validated until the proposer of slot <code>N+1</code> releases their beacon block on top of block <code>N</code> first and the attesters of slot <code>N+1</code> vote on this beacon block as the head of the chain.</p> <h3 id="fork-choice">Fork choice</h3> <p>The following features of fork choice are guaranteed under specified margins of security:</p> <ul> <li>Proposer unconditional payment.</li> <li>Builder reveal safety.</li> <li>Builder withhold safety.</li> </ul> <p>Proposer unconditional payment refers to the following. An Ethereum slot can be either:</p> <ul> <li><em>Full</em>: both the beacon block and the execution payload have been revealed and included on-chain.</li> <li><em>Skipped</em>: No beacon block (and therefore no execution payload) has been included on-chain for this slot.</li> <li><em>Empty</em>: The beacon block has been included on-chain, but the committed execution payload has not.</li> </ul> <p>Proposer unconditional payment refers to the fact that in the third scenario the beacon block proposer received payment from the corresponding builder.</p> <p>Builder reveal safety refers to the fact that if the builder acted honestly and revealed a payload in a timely fashion (as attested by the PTC) then the revealed payload will be included on-chain.</p> <p>Builder withhold safety refers to the fact that if some beacon block containing a builder's commitment is withheld and revealed late, the builder will not be charged the value of the bid. In particular, the payload does not even need to be revealed in this case.</p> <p>The precise method by which these safety mechanisms are enforced is by allowing attestations to also signal their view of the slot as in either of the above options <em>Full</em>, <em>Skipped</em> or <em>Empty</em>. For this, the <code>index</code> field in the <code>AttestationData</code> is used as explained above.</p> <h3 id="ptc-equivocations">PTC equivocations</h3> <p>There is no penalty for PTC nor payload equivocation (that is revealing the right payload and also a withheld message at the same time). A collusion of a builder controlling network partition with a single malicious PTC member could cause a split view by achieving consensus both on payload withheld and a payload present. This could be mitigated by setting <code>PAYLOAD_TIMELY_THRESHOLD</code> to be 2/3 of the PTC, in which case the malicious operator would have to control at least 33% of the PTC.</p> <p>Another mitigation mechanism is to add new slashing conditions for payload equivocation or PTC equivocations (both are signed messages by validators).</p> <p>Since this attack results in a split view at a cost for the builder (the payload is revealed and may not be included) this EIP opted for simplicity of implementation.</p> <h3 id="withdrawals">Withdrawals</h3> <p>Withdrawals from the beacon chain are complex in nature, they involve removing funds from one layer and crediting them on another, with different trigger mechanisms that can start from either layer. Before applying the consensus layer state transition function to a given beacon state <code>pre_state</code> and processing a given signed beacon block <code>block</code>, the set of withdrawals that are expected to be deducted from the beacon chain are completely determined by <code>pre_state</code>. Previous to this EIP the set of withdrawals that are credited on the execution layer are included in <code>block</code>. The block is deemed invalid if these withdrawals do not match. With the separation included in this EIP, these operations of deducting and crediting become asynchronous:</p> <ul> <li>When processing the beacon block, the withdrawals are deducted from the beacon chain.</li> <li>The set of withdrawals just deducted is committed to the beacon state <code>post_state</code>.</li> <li>When processing any execution payload whose parent beacon state is <code>post_state</code>, the payload is deemed invalid if it doesn't include precisely the list of withdrawals committed to <code>post_state</code>.</li> </ul> <p>This asynchronous mechanism has some consequences as slots may be <em>empty</em> as defined above. In these cases, the consensus layer does not process any more withdrawals until an execution payload has fulfilled the outstanding ones. An alternative design would be to defer all of withdrawal processing to the execution payload validation phase (ie. <code>process_execution_payload</code>). This has the advantage of not needing to track the fulfilled withdrawals on the beacon chain. The logic changes when several payloads are missing, in which case balances on the beacon chain change and therefore a withdrawal that would be possible with the former mechanism may be different, or even impossible with the latter.</p> <h3 id="three-state-transition-functions">Three state transition functions</h3> <p>The current EIP adds an extra state transition function to the block processing in Ethereum. Processing a <code>SignedBeaconBlock</code> changes the consensus layer <code>BeaconState</code>. A <code>SignedExecutionPayloadEnvelope</code> changes both the execution layer state and the consensus layer one. As such, the envelope commits to the consensus layer post-state-transition beacon state root.</p> <h3 id="compatible-designs">Compatible designs</h3> <h4 id="inclusion-lists">Inclusion lists</h4> <p>This EIP is fully compatible with forkchoice enforced inclusion lists as specified in <a href="https://wg-eips.ritovision.com/7805/">EIP-7805</a> or similar.</p> <h4 id="slot-auctions">Slot auctions</h4> <p>A simple change to this EIP is to remove the blockhash commitment from the <code>SignedExecutionPayloadBid</code>. This allows the builder to commit any payload to the slot. A preliminary security analysis shows that payload equivocation does not weaken fork choice's FFG. Some advantages of Slot auctions include:</p> <ul> <li>Better user experience as any submitted transaction can be included in the next block (with block auctions a transaction sent in the first half of the slot can only be included in the following block).</li> <li>Longer continuous time to build blocks.</li> <li>Better compatibility designs with fork choice enforced inclusion list proposals.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="free-option-problem">Free option problem</h3> <p>Economically rational but malicious (as defined by the honest builder guide) builders may chose to withhold their payload in the event that it would be profitable for them. This could result in missed slots and degradation of user experience of Ethereum. Some preliminary data in the form of simulation suggests that the number of these occurrences may be noticeable. Some mitigations were proposed in the form of variable penalties for builders that fail to include their payload envelopes in the canonical chain.</p> <h3 id="builder-safety">Builder safety</h3> <ul> <li>A colluding set of proposers and attesters controlling consecutive blocks and more than 20% of the total stake can reorg a builder's payload and force it to pay the bid's value.</li> <li>There is no possible <em>unbundling</em> of the builder's payload in the same slot, that is, if the builder reveals a payload for the head of the chain, no other payload is possible for the current slot.</li> </ul> <h3 id="malicious-ptc">Malicious PTC</h3> <p>The expected time for a malicious attacker, controlling 35% of the total stake, to have a majority control on the PTC is 205 000 years.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-06-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lily Johnsonhttps://github.com/lilyjjo https://wg-eips.ritovision.com/7727/

Enable meta transactions to order other transactions without revert protections.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces two new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction types and one new opcode, enabling smart contracts and transactions to delegate their local sequencing rights to an off-chain entity. These new transaction types work together to create EVM-native 'bundles', which are similar to but weaker than the Proposer-Builder Separation (PBS) bundles offered by builders to searchers.</p> <p>One of the EIP-2718 transactions is an extended normal transaction that supports:</p> <ul> <li>Specifying the entity who can place the transaction in a bundle.</li> <li>An optional block number that the transaction is valid in.</li> </ul> <p>The other EIP-2718 transaction is a 'meta' transaction that does not enter into execution, but rather orders transactions of its own type and the other new type. The 'meta' transaction can also specify an entity allowed to include it in a bundle and a valid block number.</p> <p>The new opcode reveals to the EVM the entity that placed the transaction in a bundle if the transaction was in a bundle.</p> <h2 id="motivation">Motivation</h2> <p>Currently, a single block builder has unrestricted control over the final sequencing of a block’s transactions. This poses a problem, as sequencing—the choice of who gets to interact with specific pieces of state and in what order—significantly influences value flow. The objective of this EIP is to allow more parties to participate in the construction of single blocks by exposing sequencing concepts inside of the EVM. This change would enable EVM applications to reclaim some of the sequencing value that is currently monopolized by block builders, redirecting it back to the applications themselves.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td>DELEGATED_TX_TYPE</td><td>0x05</td></tr> <tr><td>BUNDLE_TX_TYPE</td><td>0x06</td></tr> <tr><td>BUNDLE_BASE_GAS_COST</td><td>TBD <!-- TODO --></td></tr> <tr><td>BUNDLE_SIGNER_OPCODE_NUMBER</td><td>TBD <!-- TODO --></td></tr> </tbody></table> <h3 id="new-transaction-payload-types">New Transaction Payload Types</h3> <p>Two new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transactions with types <code>DELEGATED_TX_TYPE</code> and <code>BUNDLE_TX_TYPE</code>.</p> <p>For the <code>DELEGATED_TX_TYPE</code>, the transaction payload should be interpreted as:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-keyword">0x</span><span class="z-constant">05</span><span class="z-keyword"> ||</span><span class="z-entity z-name"> rlp</span><span>(</span><span>[</span></span> <span class="giallo-l"><span class="z-variable z-other"> bundleSigner</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blockNumber</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> chainId</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> nonce</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> gasPrice</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> gasLimit</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> to</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> value</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> data</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureYParity</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureR</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureS</span></span> <span class="giallo-l"><span>]</span><span>)</span></span></code></pre> <p>The <code>signatureYParity</code>, <code>signatureR</code>, <code>signatureS</code> elements of the <code>DELEGATED_TX_TYPE</code> represent a secp256k1 signature over:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-entity z-name">keccak256</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">05</span><span class="z-keyword"> ||</span><span class="z-entity z-name"> rlp</span><span>(</span><span>[</span><span class="z-variable z-other">bundleSigner</span><span>,</span><span class="z-variable z-other"> blockNumber</span><span>,</span><span class="z-variable z-other"> chain_id</span><span>,</span><span class="z-variable z-other"> nonce</span><span>,</span><span class="z-variable z-other"> gasPrice</span><span>,</span><span class="z-variable z-other"> gasLimit</span><span>,</span><span class="z-variable z-other"> to</span><span>,</span><span class="z-variable z-other"> value</span><span>,</span><span class="z-variable z-other"> data</span><span>]</span><span>)</span><span>)</span></span></code></pre> <p>For the <code>BUNDLE_TX_TYPE</code>, the transaction payload should be interpreted as:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-keyword">0x</span><span class="z-constant">06</span><span class="z-keyword"> ||</span><span class="z-entity z-name"> rlp</span><span>(</span><span>[</span></span> <span class="giallo-l"><span class="z-variable z-other"> bundleSigner</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blockNumber</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> chainId</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> nonce</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> gasPrice</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> transactionList</span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureYParity</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureR</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> signatureS</span></span> <span class="giallo-l"><span>]</span><span>)</span></span></code></pre> <p>Where the <code>transactionList</code> element is a list of syntactically valid transactions of either type <code>DELEGATED_TX_TYPE</code> or <code>BUNDLE_TX_TYPE</code>. At least one transaction must be in the list.</p> <p>An example would of the <code>transactionList</code> would be:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span>[</span></span> <span class="giallo-l"><span class="z-variable z-other"> DELEGATED_TX_TYPE</span><span>.</span><span class="z-variable z-other">payload</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> BUNDLE_TX_TYPE</span><span>.</span><span class="z-variable z-other">payload</span><span>,</span><span> </span></span> <span class="giallo-l"><span class="z-variable z-other"> DELEGATED_TX_TYPE</span><span>.</span><span class="z-variable z-other">payload</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>The <code>signatureYParity</code>, <code>signatureR</code>, <code>signatureS</code> elements of the <code>BUNDLE_TX_TYPE</code> represent a secp256k1 signature over:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-entity z-name">keccak256</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">06</span><span class="z-keyword"> ||</span><span class="z-entity z-name"> rlp</span><span>(</span><span>[</span><span class="z-variable z-other">bundleSigner</span><span>,</span><span class="z-variable z-other"> blockNumber</span><span>,</span><span class="z-variable z-other"> chainId</span><span>,</span><span class="z-variable z-other"> nonce</span><span>,</span><span class="z-variable z-other"> gasPrice</span><span>,</span><span class="z-variable z-other"> transactionList</span><span>]</span><span>)</span><span>)</span></span></code></pre> <p>We’ll refer to address resolved by this signature the bundle transaction’s signer.</p> <h3 id="bundle-signer-opcode"><code>BUNDLE_SIGNER</code> Opcode</h3> <p>The <code>BUNDLE_SIGNER</code> is a new opcode identified by <code>BUNDLE_SIGNER_OPCODE_NUMBER</code> that requires zero stack arguments.</p> <p>When the transaction type is <code>DELEGATED_TX_TYPE</code>, this opcode pushes the <code>bundleSigner</code> from the transaction payload onto the stack as an address. If the transaction is of a different type, it returns the zero address.</p> <p>The gas cost for this opcode is the <code>GAS_VERY_LOW</code> gas constant.</p> <h3 id="transaction-validity-rules">Transaction Validity Rules</h3> <p>For a <code>DELEGATED_TX_TYPE</code> to be valid, the following must be true:</p> <ul> <li>The transaction must be included in a <code>BUNDLE_TX_TYPE</code>'s <code>transactionList</code> to be valid.</li> <li>The transaction’s specified <code>bundleSigner</code> must be equal to the address who signed over the <code>BUNDLE_TX_TYPE</code> that included the transaction in a <code>transactionList</code>.</li> <li>The payload variable <code>blockNumber</code>, if not zero, must be the block number that the transaction is executed in.</li> </ul> <p>For a <code>BUNDLE_TX_TYPE</code> to be valid, the following MUST be true:</p> <ul> <li>All transactions in the <code>transactionList</code> must specify the signer of the <code>BUNDLE_TX_TYPE</code> as the <code>bundleSigner</code>.</li> <li>The transaction must be included in a <code>BUNDLE_TX_TYPE</code>'s <code>transactionList</code> if the <code>bundleSigner</code> payload variable is not the zero address.</li> <li>The payload variable <code>blockNumber</code>, if not zero, must be the block number that the transaction is executed in.</li> </ul> <h3 id="gas-costs">Gas Costs</h3> <p>The <code>BUNDLE_TX_TYPE</code> has a new gas cost formula that changes based on whether the transactions in the <code>transactionList</code> are valid at the time of execution.</p> <p>If a transaction in the <code>transactionList</code> is invalid, the <code>BUNDLE_TX_TYPE</code> transaction is charged as if the invalid transaction's bytes were part of a typical transaction's <code>CALL_DATA</code>. If an inner transaction is valid, there is no cost for its inclusion in the list.</p> <p>The formula is calculated as follows:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-variable z-other">BUNDLE_BASE_GAS_COST</span><span class="z-keyword"> +</span></span> <span class="giallo-l"><span> (</span><span class="z-variable z-other">CALL_DATA_TOKEN_COST</span><span class="z-keyword"> *</span><span class="z-variable z-other"> transaction_list_invalid_tx_byte_length</span><span>)</span></span> <span class="giallo-l"></span></code></pre> <p>At the start of processing, the <code>BUNDLE_TX_TYPE</code>'s signer is charged as if all inner transactions were invalid and is refunded the gas for the valid transactions as each valid transaction finishes execution.</p> <p>The <code>DELEGATED_TX_TYPE</code> follows typical gas costing rules.</p> <h3 id="execution">Execution</h3> <p><code>DELEGATED_TX_TYPE</code> execute normally with the <code>BUNDLE_SIGNER</code> opcode returning the <code>bundleSigner</code> payload variable.</p> <p><code>BUNDLE_TX_TYPE</code> do not start execution contexts. The<code>BUNDLE_TX_TYPE</code>'s <code>NONCE</code> must be incremented before the start of any <code>transactionList</code> execution.</p> <h3 id="receiptpayload-definitions">ReceiptPayload Definitions</h3> <p>For <code>DELEGATED_TX_TYPE</code> transaction that are able to begin execution, their <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> receipt payload should be interpreted as:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-entity z-name">rlp</span><span>(</span><span>[</span><span class="z-variable z-other">status</span><span>,</span><span class="z-variable z-other"> cumulativeGasUsed</span><span>,</span><span class="z-variable z-other"> logsBloom</span><span>,</span><span class="z-variable z-other"> logs</span><span>]</span><span>)</span></span></code></pre> <p><code>DELEGATED_TX_TYPE</code> transactions that are invalid do not get transaction receipts.</p> <p>The <code>BUNDLE_TX_TYPE</code> transaction’s <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> receipt payload should be interpreted as:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-entity z-name">rlp</span><span>(</span><span>[</span><span class="z-variable z-other">statusArray</span><span>,</span><span class="z-variable z-other"> cumulativeGasUsed</span><span>]</span><span>)</span></span></code></pre> <p>Where the <code>statusArray</code> is a list of status results for the inner <code>transactionList</code>'s transactions. The list must be the same length as the <code>transactionList</code> and report the statuses in the same order. The status type <code>0x3</code> should be used to report invalid transactions.</p> <p>The <code>cumulateGasUsed</code> is the amount of gas spent by the <code>BUNDLE_TX_TYPE</code>'s signer on the <code>BUNDLE_TX_TYPE</code> transaction costs post <code>CALLDATA</code> refund.</p> <h2 id="rationale">Rationale</h2> <h3 id="allowing-invalid-transactions-to-be-included-in-a-bundle-tx-type-s-transactionlist">Allowing invalid transactions to be included in a <code>BUNDLE_TX_TYPE</code>'s <code>transactionList</code></h3> <p>Knowing how a transaction will execute is challenging without knowing the state root to which the transaction is applied. Creators of <code>BUNDLE_TX_TYPE</code> transactions can only access the previous block’s state root and cannot predict which transactions will precede the <code>BUNDLE_TX_TYPE</code> transaction in the upcoming block's total order. If only valid transactions were permitted, <code>BUNDLE_TX_TYPE</code> transaction lists could be easily invalidated by a single inner transaction attempting to grief the bundle through nonce or gas invalidations.</p> <h3 id="charging-the-bundle-tx-type-s-signer-calldata-gas-costs-for-invalid-transactions">Charging the <code>BUNDLE_TX_TYPE</code>'s signer <code>CALLDATA</code> gas costs for invalid transactions</h3> <p>Blockchains must charge for the work that nodes perform to prevent DoS attacks. Even though invalid transactions in <code>BUNDLE_TX_TYPE</code> transaction lists do not execute, they still occupy block space as bytes and must be paid for by some entity. It is assumed that <code>BUNDLE_TX_TYPE</code> creators will be sophisticated entities capable of simulating the previous block’s state with relative accuracy and able to generate enough profit to offset any invalidation costs incurred.</p> <p>The <code>BUNDLE_BASE_GAS_COST</code> should be set to make the cost of attempting to grief the <code>BUNDLE_TX_TYPE</code> signer more expensive than the cost of the bytes to cover the invalid transaction.</p> <h3 id="requiring-delegated-tx-type-typed-transactions-to-be-included-in-a-bundle-tx-type-s-transactionlist">Requiring <code>DELEGATED_TX_TYPE</code> typed transactions to be included in a <code>BUNDLE_TX_TYPE</code>'s <code>transactionList</code></h3> <p>If <code>DELEGATED_TX_TYPE</code> transactions were able to be executed outside of a <code>BUNDLE_TX_TYPE</code> transaction list, then there would be competition between the <code>BUNDLE_TX_TYPE</code> signer and the total block builder for the right to choose how to locally sequence the transaction. If the <code>DELEGATED_TX_TYPE</code> transaction signer wished to allow the total block builder to choose the local ordering, then the <code>DELEGATED_TX_TYPE</code> transaction type should not be used.</p> <p>The same principle applies to <code>BUNDLE_TX_TYPE</code> transactions. Those that specify a <code>bundleSigner</code> must only be included in a <code>BUNDLE_TX_TYPE</code> list, while those that do not specify a <code>bundleSigner</code> must not be included in such a list.</p> <h3 id="not-allowing-other-transactions-types-to-be-included-in-a-bundle-tx-type-s-transactionlist">Not allowing other transactions types to be included in a <code>BUNDLE_TX_TYPE</code>'s <code>transactionList</code></h3> <p>This restriction was implemented as a precautionary measure and could be reconsidered in the future. Allowing the inclusion of other transaction types that do not specify a <code>bundleSigner</code> into the <code>transactionList</code> could result in multiple searchers attempting to include the same transaction in a bundle. This could potentially create spam within a block.</p> <h3 id="differences-from-pbs-searcher-bundles">Differences from PBS Searcher Bundles</h3> <p>PBS block builders currently offer 'bundles' as a service to searchers in the form of transaction lists that either all execute without reversion or are not included in a block. Searchers typically use these bundles to bid for the right to be the first to interact with a piece of state or to place logic before or after transactions created by non-searcher entities, with back-running and sandwiching being examples. PBS block builders provide this service as a way to gain order flow and increase their block's value.</p> <p>The <code>BUNDLE_TX_TYPE</code> transaction differ in two key ways:</p> <ol> <li>There is no revert protection.</li> <li>Only transactions explicitly delegating to a <code>bundleSigner</code> can be bundled.</li> </ol> <p>These choices were made to prevent DoS attacks on builders and to be compatible with non-PBS block builders running other algorithms.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Block builders are problematic today partly due to their ability to perform censorship and enforce malicious orderings. These concerns persist even when sequencing rights are delegated to a specific entity. The code that generates the off-chain ordering should be public and executed in a trust-minimized manner, such as in a TEE (Trusted Execution Environment) or on a blockchain with faster block times.</p> <p>Similarly, smart contracts that restrict functionality to transactions signed by a specific <code>BUNDLE_SIGNER</code> should provide mechanisms for users to withdraw funds without relying on the delegated sequencing entity to be online or non-malicious. A two-step fund removal process could be implemented to allow safe interaction with bundle construction and simulation logic.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 dapplionhttps://github.com/dapplion Toni Wahrstätterhttps://github.com/nerolation Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7716/

Adjust penalties for missed attestations based on in-slot correlation of missed attestation

<h2 id="abstract">Abstract</h2> <p>The decentralization of the validator set is one of the most important properties of Ethereum for credible neutrality and censorship resistance. By adjusting penalties to foster decentralization, diversification and fault-tolerance, this EIP proposes to adjust penalties in a way that more diversified entities get lower penalties while entities with high correlations in their setup face more severe ones.</p> <h2 id="motivation">Motivation</h2> <p>As of now, during times of usual network operation, there are no economic incentives to diversify node operations through using multiple different nodes, geographical locations, clients, ISP providers, etc., except for reducing the risk of penalties affecting all validators simultaneously, thereby limiting the impact to only a fraction of them.</p> <p>Attestation penalties are currently agnostic to other participation actions. This proposal scales attestation penalties as a function of other participants' actions. The goal is to decrease the profitability of participants that exhibit correlated behavior.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>PENALTY_ADJUSTMENT_FACTOR</code></td><td><code>4096</code></td></tr> <tr><td><code>MAX_PENALTY_FACTOR</code></td><td><code>4</code></td></tr> </tbody></table> <p>Add a variable <code>NET_EXCESS_PENALTIES</code> to the beacon state.</p> <p>Let <code>penalty_factor</code> be determined through</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>min(</span></span> <span class="giallo-l"><span> (non_attesting_balance * PENALTY_ADJUSTMENT_FACTOR) // (NET_EXCESS_PENALTIES * total_active_balance + 1), </span></span> <span class="giallo-l"><span> MAX_PENALTY_FACTOR</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Let <code>NET_EXCESS_PENALTIES</code> be <code>max(1, NET_EXCESS_PENALTIES + penalty_factor) - 1</code></p> <h2 id="rationale">Rationale</h2> <h3 id="penalty-adjustment-factor">PENALTY_ADJUSTMENT_FACTOR</h3> <p>This variable impacts the sensitivity of the <code>NET_EXCESS_PENALTIES</code>.</p> <p>Given stable participation, the <code>penalty_factor</code> is one. If participation decreases, the <code>penalty_factor</code> will temporarily increase above one until <code>net_excess_penalties</code> catches up. If participation increases, the <code>penalty_factor</code> will temporarily be zero until <code>net_excess_penalties</code> catches up.</p> <p>The <code>PENALTY_ADJUSTMENT_FACTOR</code> regulates how fast <code>net_excess_penalties</code> catches up. In other words, the <code>PENALTY_ADJUSTMENT_FACTOR</code> determines the frequency that the penalty_factor is not one.</p> <p>A high <code>PENALTY_ADJUSTMENT_FACTOR</code> causes the <code>net_excess_penalties</code> to adjust slower. A low <code>PENALTY_ADJUSTMENT_FACTOR</code> causes the <code>net_excess_penalties</code> to react more sensitively to changes in participation.</p> <h3 id="max-penalty-factor"><code>MAX_PENALTY_FACTOR</code></h3> <p>The <code>MAX_PENALTY_FACTOR</code> puts a ceiling onto the maximum factor with which the penalty for missed attestations is scaled to prevent overly harsh punishments.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible adjustment of attestations rewards and penalties that requires a scheduled network upgrade.</p> <h2 id="security-considerations">Security Considerations</h2> <p>We acknowledge that splitting validator views can be leveraged as an attack to increase the <code>penalty_factor</code> for validators of consecutive slots with little risk for the proposer. TBD.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Tomasz Stanczakhttps://github.com/tkstanczak Guillaume Ballethttps://github.com/gballet Gajinder Singhhttps://github.com/g11tech Tanishq Jasoriahttps://github.com/tanishqjasoria Ignacio Hagopianhttps://github.com/jsign Jochem Brouwerhttps://github.com/jochem-brouwer Gabriel Rocheleauhttps://github.com/gabrocheleau https://wg-eips.ritovision.com/7709/

Read the `BLOCKHASH (0x40)` opcode from the EIP-2935 system contract storage and adjust its gas cost to reflect storage access.

<h2 id="abstract">Abstract</h2> <p>Update the <code>BLOCKHASH (0x40)</code> opcode to read and serve from the system contract storage and charge the <strong>additional</strong> (cold or warm) storage costs.</p> <h2 id="motivation">Motivation</h2> <p>The <code>BLOCKHASH (0x40)</code> opcode currently assumes that the client has knowledge of the previous blocks, which in Verkle <a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a> would prevent stateless execution. However with <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> blockhashes can be retrieved and served from its system contract storage which allows Verkle blocks to include a storage access witness for stateless execution.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td>TBD</td></tr> <tr><td><code>HISTORY_STORAGE_ADDRESS</code></td><td><code>0x0000F90827F1C53a10cb7A02335B175320002935</code></td></tr> <tr><td><code>BLOCKHASH_SERVE_WINDOW</code></td><td><code>256</code></td></tr> </tbody></table> <p>The <code>BLOCKHASH</code> opcode semantics remains the same as before. From the <code>fork_block</code> (defined as <code>fork_block.timestamp &gt;= FORK_TIMESTAMP and fork_block.parent.timestamp &lt; FORK_TIMESTAMP</code>), the <code>BLOCKHASH</code> instruction should be updated to resolve block hash in the following manner:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> resolve_blockhash</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>,</span><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> arg</span><span>:</span><span> uint64</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> note that outside the BLOCKHASH_SERVE_WINDOW we continue to return 0</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> despite the 2935 history contract being able to serve more hashes</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> arg</span><span class="z-keyword"> &gt;=</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> or</span><span> (</span><span>arg</span><span class="z-keyword"> +</span><span class="z-constant"> BLOCKHASH_SERVE_WINDOW</span><span>)</span><span class="z-keyword"> &lt;</span><span> block</span><span>.</span><span>number</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> performs an sload on arg % HISTORY_SERVE_WINDOW including gas charges,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> warming effects as well as execution accesses</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> note that the `BLOCKHASH_SERVE_WINDOW` and the 2935 ring buffer window</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> `HISTORY_SERVE_WINDOW` for slot calculation are different</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> state</span><span>.</span><span>load_slot</span><span>(</span><span class="z-constant">HISTORY_STORAGE_ADDRESS</span><span>,</span><span> arg</span><span class="z-keyword"> %</span><span class="z-constant"> HISTORY_SERVE_WINDOW</span><span>)</span></span></code></pre> <p>ONLY if the <code>arg</code> is within the correct <code>BLOCKHASH</code> window, clients can choose to either</p> <ul> <li>do a direct <code>SLOAD</code> from state, or</li> <li>do a system call to <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> contract via its <code>get</code> mechanism (caller other than <code>SYSTEM_ADDRESS</code>) or</li> <li>serve from memory or as per current designs if maintaining requisite history (full clients for e.g.)</li> </ul> <p>However the entire semantics and after effects of the <code>SLOAD</code> operation needs to be applied as per the current fork if the <code>arg</code> is within the correct <code>BLOCKHASH</code> window:</p> <ul> <li><code>SLOAD</code> gas costs (cold or warm) for the <code>arg % HISTORY_SERVE_WINDOW</code> slot.</li> <li><code>SLOAD</code> after effects on the slot (warming the slot)</li> <li><code>SLOAD</code> accesses added to execution witnesses if Verkle (<a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a> and <a href="https://wg-eips.ritovision.com/4762/">EIP-4762</a>) is activated</li> </ul> <h3 id="activation">Activation</h3> <p>This EIP specifies the transition to the new logic assuming that <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> has been activated:</p> <ul> <li>sufficiently ahead of this EIP's activation (&gt;= <code>BLOCKHASH_SERVE_WINDOW</code>) or</li> <li>at genesis for testnets/devnets where this EIP could also be activated at genesis</li> </ul> <p>The current proposal is to activate this EIP with Verkle to allow for stateless execution of the block.</p> <h3 id="gas-costs">Gas costs</h3> <p>As described above, if the <code>arg</code> to be resolved is within the correct window, the corresponding <code>SLOAD</code> charges and accesses are to be applied for the slot <code>arg % HISTORY_SERVE_WINDOW</code>. Note that the <code>HISTORY_SERVE_WINDOW</code> and <code>BLOCKHASH_SERVE_WINDOW</code> are different.</p> <h3 id="reading-from-the-system-contract">Reading from the System contract</h3> <p>Even if the clients choose to resolve <code>BLOCKHASH</code> through system call to <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> contract, the gas cost for the system code execution (and also the code witnesses if Verkle activated) is not applied. Only the effect of <code>SLOAD</code> is applied as described above.</p> <h2 id="rationale">Rationale</h2> <ul> <li>The reason behind the updated gas cost is to match the real operation, which is equivalent to an <code>SLOAD</code>.</li> <li>The <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> system contract execution charges (and accesses) are not applied to keep the gas low and to keep things simple for clients which choose to resolve <code>BLOCKHASH</code> in other ways (directly or though memory/maintained history)</li> </ul> <p>Note that <code>BLOCKHASH</code> opcode only serves a limited <code>BLOCKHASH_SERVE_WINDOW</code> to be backward compatible (and to not extend the above exemptions). For deeper accesses one will need to directly call <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> system contract which will lead to a normal contract execution (as well as charges and accesses)</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a significant increase in the cost of <code>BLOCKHASH</code>, which could break use-cases that rely on the previous gas cost. Also, this EIP introduces a breaking change in the case where less than <code>BLOCKHASH_SERVE_WINDOW</code> elapse between the <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> fork and this EIP's fork (unless <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> is activated in genesis for e.g. in testnets/devnets) as the <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> system contract would not have saved the required history.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>If <code>BLOCKHASH</code> is not called or there is no <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> contract call by any transaction, only the <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> system update of the parent hash shows up in witnesses if Verkle is activated.</li> <li>If <code>BLOCKHASH</code> is called, there MUST be a storage access gas charge (and corresponding access witness if Verkle is activated) for the storage slot but ONLY if the <code>BLOCKHASH</code> query is for the last <code>BLOCKHASH_SERVE_WINDOW</code> ancestors. This is irrespective of how the client chooses to resolve the <code>BLOCKHASH</code> (directly, via system contract or via memory)</li> <li>The gas cost for each <code>BLOCKHASH</code> operation should still be charged, in addition to the <code>SLOAD</code> cost of each lookup (if performed)</li> <li>If the <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> contract is called directly (i.e. not through <code>BLOCKHASH</code>), then the witness and gas costs (including those related to contract code) are applied as per normal contract execution of the current fork.</li> <li><code>BLOCKHASH</code> should be consistently resolved if this EIP is activated correctly <code>&gt;= BLOCKHASH_SERVE_WINDOW</code> after <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a></li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>No security considerations other than the ones contained in <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a> are determined as of now.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Peter Davieshttps://github.com/petertdavies Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech Carsonhttps://github.com/carsons-eels Jared Wasingerhttps://github.com/jwasinger https://wg-eips.ritovision.com/7708/

All ETH transfers emit a log

<h2 id="abstract">Abstract</h2> <p>All ETH-transfers, including transactions, <code>CALL</code> and <code>SELFDESTRUCT</code> emit a log.</p> <h2 id="motivation">Motivation</h2> <p>Logs are often used to track when balance changes of assets on Ethereum. Logs work for <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> tokens, but they do not work for ETH. ETH transfers from EOAs can be read from the transaction list in the block, but ETH transfers from smart contract wallets are not automatically logged anywhere. This has already led to problems in the past, eg. early exchanges would often not properly support deposits from smart contract wallets, or only support them with a much longer delay. This EIP proposes that we automatically generate a log every time a value-transferring <code>CALL</code> or <code>SELFDESTRUCT</code> happens. We also add a similar log for transfers in transactions, so that all ETH transfers can be tracked using one mechanism.</p> <h2 id="specification">Specification</h2> <h3 id="eth-transfer-logs">ETH transfer logs</h3> <p>A log, identical to a LOG3, is issued for:</p> <ul> <li>Any nonzero-value-transferring transaction to a different account, before any other logs created by EVM execution</li> <li>Any nonzero-value-transferring <code>CALL</code> to a different account, at the time that the value transfer executes</li> <li>Any nonzero-value-transferring <code>SELFDESTRUCT</code> to a different account, at the time that the value transfer executes</li> </ul> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code> emitting log</td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef</code> (<code>keccak256('Transfer(address,address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td><code>from</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>topics[2]</code></td><td><code>to</code> address (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <p>This matches the <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> Transfer event definition.</p> <h3 id="selfdestruct-processing">Selfdestruct processing</h3> <p>A log, identical to a LOG2, is issued for:</p> <ul> <li>Any non-zero balance removal which occurs when a contract created in the same transaction invokes <code>SELFDESTRUCT</code> with itself as a target, at the time that the opcode is invoked.</li> <li>Each account which has been marked for deletion and holds a balance at the time of removal during transaction finalization. Burn logs are emitted after any other logs created by EVM execution and the payment of the <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> priority fee to the coinbase, in lexicographical order of account address</li> </ul> <table><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody> <tr><td><code>address</code> emitting log</td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>)</td></tr> <tr><td><code>topics[0]</code></td><td><code>0x4bfaba3443c1a1836cd362418edc679fc96cae8449cbefccb6457cdf2c943083</code> (<code>keccak256('Selfdestruct(address,uint256)')</code>)</td></tr> <tr><td><code>topics[1]</code></td><td>Closed <code>contract_address</code> (zero prefixed to fill uint256)</td></tr> <tr><td><code>data</code></td><td><code>amount</code> in Wei (big endian uint256)</td></tr> </tbody></table> <p>The Selfdestruct log is emitted when (1) a <code>SELFDESTRUCT</code> to self is triggered, or when (2) a smart contract is closed after receiving more ETH after already flagged for <code>SELFDESTRUCT</code>.</p> <h2 id="rationale">Rationale</h2> <p>This is the simplest possible implementation that ensures that all ETH transfers are implemented in some kind of record that can be easily accessed through making RPC calls into a node, or through asking for a Merkle branch that is hashed into the block root. The log type is compatible with the ERC-20 token standard, but does not introduce any overly-specific ERC-20 features (eg. ABI encodings) into the specification.</p> <h3 id="open-questions">Open questions</h3> <ol> <li>Magic value used for <code>address</code>? For address: (a) <code>0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code> (same as <code>eth_simulateV1</code>), (b) <code>0xfffffffffffffffffffffffffffffffffffffffe</code> (<a href="https://wg-eips.ritovision.com/4788/"><code>SYSTEM_ADDRESS</code></a>), (c) zero address</li> <li>Should fee payments trigger a log? It would ensure "completeness", in the sense that you can compute the exact current balance table by watching logs, but it would greatly increase the number of logs, perhaps to an unacceptably high amount.</li> <li>Should withdrawals also trigger a log? They are not associated with transactions.</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>ETH transfers already cost a minimum of 6700 gas, which is much more expensive than the LOG3 opcode (1500 gas). Hence, this EIP does not increase the worst-case number of logs that can be put into a block. It will somewhat increase the average number of logs.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7706/

Create a separate basefee and gaslimit for calldata

<h2 id="abstract">Abstract</h2> <p>Add a new type of gas for transaction calldata. Add a new transaction type that provides <code>max_basefee</code> and <code>priority_fee</code> as a vector, providing values for execution gas, blob gas and calldata gas. Modify the basefee adjustment to use the same mechanism for the three types of gas.</p> <h2 id="motivation">Motivation</h2> <p>A major argument against raising the Ethereum gas limit, making calldata cheaper, or increasing the <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> blob count before technologies like PeerDAS become available, is that the theoretical maximum size of an Ethereum block is already too large, and we cannot afford to increase it further. However, there is an inefficiency here: the current average size of a block (not including blobs) is ~100 kB, and the theoretical max is <code>30,000,000 / 16 = 1,875,000</code> bytes (one could make larger blocks using zero bytes, but in practice zero-byte-heavy blocks would be compressed to less than 1.87 million bytes due to snappy compression). Ideally, we would have a way to bound the maximum, without making calldata more scarce <em>on average</em>.</p> <p>This EIP does exactly this, by adopting the same technique that was applied for blob data in EIP-4844: we introduce a separate fee market for calldata, with a separate basefee and a separate per-block gas limit. The theoretical max calldata size of a block would be greatly reduced, while basic economic analysis suggests that <em>on average</em>, calldata would become considerably cheaper.</p> <p>The EIP also introduces a new transaction type which includes the three types of max-basefees and priority fees as a vector, allowing the same code paths to handle all three types of gas. We also make the basefee adjustment, which currently uses separate mechanisms for execution gas (introduced in <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>) and blobs (introduced in EIP-4844), use the same approach for all three types of gas. This simplifies the basefee adjustment rules, and ensures that the stronger mathematical properties of the newer EIP-4844 basefee adjustment algorithm cover all three types of gas.</p> <h2 id="specification">Specification</h2> <p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code> = <code>TBD</code></li> <li><code>NEW_TX_TYPE</code> = <code>TBD</code></li> <li><code>CALLDATA_GAS_PER_TOKEN</code> = <code>4</code></li> <li><code>TOKENS_PER_NONZERO_BYTE</code> = <code>4</code></li> <li><code>CALLDATA_GAS_LIMIT_RATIO</code> = <code>4</code></li> <li><code>LIMIT_TARGET_RATIOS = [2, 2, 4]</code></li> <li><code>MIN_BASE_FEE_PER_GAS = 1</code> # Rename of EIP-4844 MIN_BASE_FEE_PER_BLOB_GAS</li> <li><code>BASE_FEE_UPDATE_FRACTION = 8</code> # Roughly matches EIP-4844 parameters</li> </ul> <h3 id="new-transaction-type">New transaction type</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> = <code>TX_TYPE(NEW_TX_TYPE)</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, gas_limit, to, value, data, access_list, blob_versioned_hashes, max_fees_per_gas, priority_fees_per_gas, y_parity, r, s]</span></span></code></pre> <p>We require <code>max_fees_per_gas</code> and <code>priority_fees_per_gas</code> to be length-3 vectors, each of which contain integers from <code>0</code> to <code>2**64-1</code>.</p> <p>The intrinsic cost of the new transaction is inherited from EIP-4844, except that the calldata gas cost (16 per nonzero byte, 4 per zero byte) is removed.</p> <h3 id="block-processing-and-transaction-fees">Block processing and transaction fees</h3> <p>We add the functions <code>get_max_fees</code> and <code>get_priority_fees</code>, to compute these length-3 vectors for previous transaction types:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_max_fees(tx: Transaction) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> if tx.type == NEW_TX_TYPE:</span></span> <span class="giallo-l"><span> return tx.max_fees_per_gas</span></span> <span class="giallo-l"><span> elif tx.type == BLOB_TX_TYPE:</span></span> <span class="giallo-l"><span> return [tx.max_fee_per_gas, tx.max_fee_per_blob_gas, tx.max_fee_per_gas]</span></span> <span class="giallo-l"><span> elif is_eip_1559(tx.type):</span></span> <span class="giallo-l"><span> return [tx.max_fee_per_gas, 0, tx.max_fee_per_gas]</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> return [tx.gasprice, 0, tx.gasprice]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_priority_fees(tx: Transaction) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> if tx.type == NEW_TX_TYPE:</span></span> <span class="giallo-l"><span> return tx.priority_fees_per_gas</span></span> <span class="giallo-l"><span> elif tx.type == BLOB_TX_TYPE:</span></span> <span class="giallo-l"><span> return [tx.max_priority_fee_per_gas, 0, tx.max_priority_fee_per_gas]</span></span> <span class="giallo-l"><span> elif is_eip_1559(tx.type):</span></span> <span class="giallo-l"><span> return [tx.max_priority_fee_per_gas, 0, tx.max_priority_fee_per_gas]</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> return [tx.gasprice, 0, tx.gasprice]</span></span></code></pre> <p>We also add some helpers:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def all_less_or_equal(v1: [int, int, int], v2: [int, int, int]) -&gt; bool:</span></span> <span class="giallo-l"><span> return all(x &lt;= y for x, y in zip(v1, v2))</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def vector_add(v1: [int, int, int], v2: [int, int, int]) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [x+y for x, y in zip(v1, v2)]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def vector_subtract(v1: [int, int, int], v2: [int, int, int]) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [x-y for x, y in zip(v1, v2)]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def vector_subtract_clamp_at_zero(v1: [int, int, int], v2: [int, int, int]) -&gt; [uint, uint, uint]:</span></span> <span class="giallo-l"><span> return [x-y if x &gt;= y else 0 for x, y in zip(v1, v2)]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def vector_mul(v1: [int, int, int], v2: [int, int, int]) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [x*y for x, y in zip(v1, v2)]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span># Same rules as current calldata pricing, but rephrased (similar language to EIP-7623)</span></span> <span class="giallo-l"><span>def get_calldata_gas(calldata: bytes) -&gt; int:</span></span> <span class="giallo-l"><span> tokens = calldata.count(0) + (len(calldata) - calldata.count(0)) * TOKENS_PER_NONZERO_BYTE</span></span> <span class="giallo-l"><span> return tokens * CALLDATA_GAS_PER_TOKEN</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_gaslimits(tx: Transaction) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> if tx.type == NEW_TX_TYPE:</span></span> <span class="giallo-l"><span> return [tx.gaslimit, len(tx.blob_versioned_hashes) * GAS_PER_BLOB, get_calldata_gas(tx.data)]</span></span> <span class="giallo-l"><span> elif tx.type == BLOB_TX_TYPE:</span></span> <span class="giallo-l"><span> return [tx.gaslimit, len(tx.blob_versioned_hashes) * GAS_PER_BLOB, get_calldata_gas(tx.data)]</span></span> <span class="giallo-l"><span> elif is_eip_1559(tx.type):</span></span> <span class="giallo-l"><span> return [tx.gaslimit, 0, get_calldata_gas(tx.data)]</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> return [tx.gaslimit, 0, get_calldata_gas(tx.data)]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_fees_per_gas(tx: Transaction, block_basefees: [int, int, int]) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> max_fees = get_max_fees(tx)</span></span> <span class="giallo-l"><span> priority_fees = get_priority_fees(tx)</span></span> <span class="giallo-l"><span> output = []</span></span> <span class="giallo-l"><span> # Fee sufficiency check, similar to EIP-1559 and 4844</span></span> <span class="giallo-l"><span> require(all_less_or_equal(block_basefees, max_fees))</span></span> <span class="giallo-l"><span> # Similar logic to EIP-1559 and 4844</span></span> <span class="giallo-l"><span> return [</span></span> <span class="giallo-l"><span> min(basefee + priority_fee, max_fee)</span></span> <span class="giallo-l"><span> for block_basefee, max_fee, priority_fee in zip(block_basefees, max_fees, priority_fees)</span></span> <span class="giallo-l"><span> ]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>get_block_gaslimits(block: Block) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [block.gaslimit, MAX_BLOB_GAS_PER_BLOCK, block.gaslimit // CALLDATA_GAS_LIMIT_RATIO]</span></span></code></pre> <p><strong>At the start of block processing</strong>:</p> <ul> <li>We initialize a vector <code>gas_used_so_far</code> to <code>[0, 0, 0]</code></li> </ul> <p><strong>At the start of processing a transaction</strong>:</p> <ul> <li>Compute <code>fees_per_gas = get_fees_per_gas(tx, get_block_basefees(block))</code> and <code>tx_gaslimits = get_gaslimits(tx)</code></li> <li>Check that <code>all_less_or_equal(vector_add(gas_used_so_far, tx_gaslimits), block.gas_limits)</code></li> <li>Deduct <code>sum(vector_mul(fees_per_gas, tx_gaslimits))</code> wei from the <code>tx.origin</code> account</li> </ul> <p>Note that <code>get_block_basefees(block)</code> is not yet defined, we will define it in the section below. The <code>block.gas_limits</code> field is also defined in the section below.</p> <p><strong>At the end of processing a transaction</strong>:</p> <ul> <li>Compute <code>tx_gas_consumed</code> as a three item vector, where the first item is the amount of gas actually consumed by the transaction execution, and the second and third match the values in <code>get_gaslimits(tx)</code></li> <li>Refund <code>sum(vector_mul(fees_per_gas, vector_sub(tx_gaslimits, tx_gas_consumed)))</code> to the <code>tx.origin</code> account (in practice, only the first term will be nonzero for now)</li> <li>Set <code>gas_used_so_far = vector_add(gas_used_so_far, tx_gas_consumed)</code></li> </ul> <p><strong>At the end of processing a block</strong>:</p> <ul> <li>Require <code>block.gas_used = gas_used_so_far</code></li> </ul> <p>The <code>block.gas_used</code> field will be defined in the section below.</p> <h3 id="block-structure">Block structure:</h3> <p>We update <code>BlockHeader</code> field, to remove the <code>blob_gas_used</code>, <code>gas_used</code>, <code>base_fee_per_gas</code>, <code>gas_limit</code> and <code>excess_blob_gas</code> fields, and we add new fields, all of the <code>[int, int, int]</code> type: <code>gas_limits</code>, <code>gas_used</code>, <code>excess_gas</code>. The resulting RLP encoding becomes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([</span></span> <span class="giallo-l"><span> parent_hash,</span></span> <span class="giallo-l"><span> 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash</span></span> <span class="giallo-l"><span> coinbase,</span></span> <span class="giallo-l"><span> state_root,</span></span> <span class="giallo-l"><span> txs_root,</span></span> <span class="giallo-l"><span> receipts_root,</span></span> <span class="giallo-l"><span> logs_bloom,</span></span> <span class="giallo-l"><span> 0, # difficulty</span></span> <span class="giallo-l"><span> number,</span></span> <span class="giallo-l"><span> timestamp,</span></span> <span class="giallo-l"><span> extradata,</span></span> <span class="giallo-l"><span> prev_randao,</span></span> <span class="giallo-l"><span> 0x0000000000000000, # nonce</span></span> <span class="giallo-l"><span> withdrawals_root,</span></span> <span class="giallo-l"><span> gas_limits,</span></span> <span class="giallo-l"><span> gas_used,</span></span> <span class="giallo-l"><span> excess_gas</span></span> <span class="giallo-l"><span>])</span></span></code></pre> <p>We define:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>get_block_gas_targets(parent: Header) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [limit // target_ratio for limit, target_ratio in zip(parent.gas_limits, LIMIT_TARGET_RATIOS)]</span></span></code></pre> <p>We calculate the required <code>excess_gas</code> values as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def calc_excess_gas(parent: Header) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return vector_subtract_clamp_at_zero(vector_add(parent_excess, parent_used), get_block_gas_targets(parent))</span></span></code></pre> <p>We calculate the required <code>gas_limits</code> as follows:</p> <ul> <li><code>gas_limits[0]</code> must follow the existing adjustment formula</li> <li><code>gas_limits[1]</code> must equal <code>MAX_BLOB_GAS_PER_BLOCK</code></li> <li><code>gas_limits[2]</code> must equal <code>gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO</code></li> </ul> <p>Now, we define <code>get_block_basefees</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_block_basefees(parent: Header) -&gt; [int, int, int]:</span></span> <span class="giallo-l"><span> return [</span></span> <span class="giallo-l"><span> fake_exponential(</span></span> <span class="giallo-l"><span> MIN_BASE_FEE_PER_GAS,</span></span> <span class="giallo-l"><span> excess_gas,</span></span> <span class="giallo-l"><span> target * BASE_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> for (excess_gas, target) in zip(parent.excess_gas, get_block_gas_targets(parent))</span></span> <span class="giallo-l"><span> ]</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="conversion-of-all-gas-related-mechanics-into-vectors">Conversion of all gas-related mechanics into vectors</h3> <p>This allows the same logic that is used for handling gas to handle all three types of gas. As a result, it's arguably a net simplification of protocol gas handling logic, despite the fact that the total number of gas types increases from 2 to 3</p> <h3 id="target-ratios">Target ratios</h3> <p>The target ratios for execution gas and blobs are set to 2; the target ratio for calldata is set to 4. This greatly decreases the number of scenarios in which calldata actually hits the limit, which mitigates economic impact of the EIP, because analysis of EIP-1559-style fee markets is much simpler in "under-the-limit" conditions than in "at-the-limit" conditions. Additionally, it reduces the risk that applications requiring large calldata will outright stop working.</p> <p>The current parameters set the target calldata per block to 187,500 bytes, about 2x the current average. Using basic supply-and-demand reasoning, this implies that calldata is likely to become significantly cheaper as a result of this EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Previous transaction types set the calldata basefee and priority fee to equal each other. The calldata gas costs were intentionally set to be identical to today, and the gas target similar to present-day usage, so that setting the two fees to be equal each other is a reasonable approximation to optimal behavior. In practice, the new transaction type would be superior, so we expect users to switch to it over time. However, the loss suffered by old-style transaction users would not be that high, because priority fees are generally small compared to basefees, and the amount that a user pays is proportional to the basefee.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Optimal block building behavior becomes more complex as a result of this EIP, particularly under the boundary conditions when blocks are full of one or both types of gas. We argue that the effects of this are not too large, because in practice over 90% of blocks are under-full, and naive "greedy algorithms" can get a close-enough-to-optimal outcome. The centralization risks of proprietary block-building algorithms are thus likely to be much smaller than other existing risks with eg. MEV extraction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Adamshttps://github.com/benaadams Oleg Iakushkinhttps://github.com/OlegJakushkin https://wg-eips.ritovision.com/7707/

This EIP proposes updating gas cost parameters for access lists to incentivise their use and improve transaction execution efficiency.

<h2 id="abstract">Abstract</h2> <p>This EIP reduces the gas cost of access list data, incentivizing the inclusion of complete and valid access lists in transactions to improve data load efficiency for execution layer clients.</p> <h2 id="motivation">Motivation</h2> <p>While <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> introduced <code>accessLists</code> as a mechanism for <code>SLOAD</code> pre-warming to reduce gas costs by informing the EVM upfront about which storage slots a transaction will access, the practical use is limited and uncommon due to the savings versus penalties involved. In order to break even for each address included <code>24 storage keys</code> are required per address, and there is a <code>100 gas</code> saving per key at <code>25+</code>; in contrast the penalty for including an unused key is <code>1900 gas</code>, so break-even where one key is unused is <code>43 keys</code>.</p> <p>This situation makes the break-even and risk-reward ratio of <code>accessLists</code> rarely appealing in practice for regular transactions, where a prior transaction could lead to a different branch being taken and a slightly different set of storage slots being accessed. Furthermore, a very high number of SLOADs is required to start breaking even.</p> <p>For some clients, data loading takes <code>&gt;70%</code> of block execution time. This happens in part due to sequential transaction execution and iterative search of effectively random access data.</p> <p>While NVMe drives have massive throughput and IOPS; this is their concurrent throughput operated through multiple queues and they do not have this performance if data is accessed completely sequentially with one request waiting for the prior to complete i.e. stacking individual IOPS latency end to end will not give anything close to maximal throughput that these drives can deliver (which is different from the HDD world where heads needed to seek to different physical locations for each read). This is a similar situation with network attached storage or cloud data disks; however the latency here is even more amplified than a local direct CPU attached NVMe drive (i.e. via network card).</p> <p>If nodes had a somewhat clearer picture of what data to pre-load for the block's execution; that can be done in parallel, hiding much of the latency from accessing that data when discovered from executing the transaction. Very much in a similar way to instruction pipelining on a CPU hiding memory access latencies; the data access for transactions could be pipelined. This can lead to faster/cheaper block execution and would facilitate data dependency hints for parallel Tx execution in the future, like on other emerging chains that were developed with more modern hardware in mind.</p> <h2 id="specification">Specification</h2> <p>We shall update <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> parameters:</p> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>ACCESS_LIST_STORAGE_KEY_COST</code></td><td>320</td></tr> <tr><td><code>ACCESS_LIST_ADDRESS_COST</code></td><td>512</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <p>As stated in the introduction the gas cost benefit analysis does not encourage the users of the chain to provide accessList hints, even though the mechanism is already in protocol (and a call to <code>eth_createAccessList</code> will give them, or a wallet the correct list to include). So we propose a reduction in the pricing of those data access lists to make them more inline with calldata.</p> <p>Levelling the playing field between small <code>call_data</code> and <code>access_lists</code> costs, (and incentivise <code>access_lists</code> provisioning from transaction senders as they are needed for transaction execution in a faster manner), the price model updates would look as follows:</p> <p>Use <code>STANDARD_TOKEN_COST * tokens_in_access_lists</code>, where <code>tokens_in_access_lists = bytes_in_access_lists * 4</code>, making it as expensive to send as plain small call data. So we will get:</p> <ul> <li> <p><code>32*4*4 = 512</code> for addresses (instead of 2400, 4.6 times less)</p> </li> <li> <p><code>20*4*4 = 320</code> for storage keys (instead of 1900, 5.9 times less)</p> </li> </ul> <p>This means users pay for on-chain data inclusion as usual <code>call_data</code>. It changes the original <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> logic of "covering the bandwidth costs", which was not described in detail and is potentially outdated.</p> <p>It should be noted that this is not the first time <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> additions have been proposed. In <a href="https://wg-eips.ritovision.com/3521/">EIP-3521</a>, a reduction was already proposed, but it focused only on <code>ACCESS_LIST_ADDRESS_COST</code>.</p> <h3 id="examples">Examples</h3> <p>Current</p> <table><thead><tr><th>Inst</th><th>Type</th><th>Access List</th><th>Keys for address</th><th>OP Price</th><th>AccessList Key Price</th><th>AccessList Address Price</th><th>Total gas per OP</th></tr></thead><tbody> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Not included</td><td>-</td><td>2100</td><td>0</td><td>0</td><td>2100</td></tr> <tr><td><code>SLOAD</code></td><td>Warm</td><td>Not included</td><td>-</td><td>100</td><td>0</td><td>0</td><td>100</td></tr> <tr><td><code>SLOAD</code></td><td>Warm</td><td>Included</td><td>-</td><td>100</td><td>-</td><td>-</td><td>100</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>1</td><td>100</td><td>1900</td><td>2400</td><td>4400</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>1</td><td>0</td><td>1900</td><td>2400</td><td>4300</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>10</td><td>100</td><td>1900</td><td>240</td><td>2240</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>10</td><td>0</td><td>1900</td><td>240</td><td>2140</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>50</td><td>100</td><td>1900</td><td>48</td><td>2048</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>50</td><td>0</td><td>1900</td><td>48</td><td>1948</td></tr> </tbody></table> <p>Proposed</p> <table><thead><tr><th>Inst</th><th>Type</th><th>Access List</th><th>Keys for address</th><th>OP Price</th><th>AccessList Key Price</th><th>AccessList Address Price</th><th>Total gas per OP</th></tr></thead><tbody> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Not included</td><td>-</td><td>2100</td><td>0</td><td>0</td><td>2100</td></tr> <tr><td><code>SLOAD</code></td><td>Warm</td><td>Not included</td><td>-</td><td>100</td><td>0</td><td>0</td><td>100</td></tr> <tr><td><code>SLOAD</code></td><td>Warm</td><td>Included</td><td>-</td><td>100</td><td>-</td><td>-</td><td>100</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>1</td><td>100</td><td>320</td><td>512</td><td>932</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>1</td><td>0</td><td>320</td><td>512</td><td>832</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>10</td><td>100</td><td>320</td><td>51.2</td><td>471</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>10</td><td>0</td><td>320</td><td>51.2</td><td>371</td></tr> <tr><td><code>SLOAD</code></td><td>Cold</td><td>Included</td><td>50</td><td>100</td><td>320</td><td>10.24</td><td>430</td></tr> <tr><td><code>SLOAD</code></td><td>None</td><td>Included</td><td>50</td><td>0</td><td>320</td><td>10.24</td><td>330</td></tr> </tbody></table> <ul> <li>Already paid on making warm</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP makes a minor update to <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> with respect to modern execution challenges and capabilities.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Same as per <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper https://wg-eips.ritovision.com/7705/

Opcodes to mark a contract as nonreentrant

<h2 id="abstract">Abstract</h2> <p>Add two opcodes, <code>NONREENTRANT</code> and <code>REENTRANT</code>, which set and clear a contract's reentrancy status. After invoking <code>NONREENTRANT</code>, a contract cannot be <code>CALL</code>ed (or <code>STATICCALL</code>ed, or <code>DELEGATECALL</code>ed) until <code>REENTRANT</code> is invoked.</p> <h2 id="motivation">Motivation</h2> <p>Reentrancy attacks account for a substantial portion of user funds stolen on EVM chains, including the famous "DAO hack". However, due to the cost of preventing reentrancy attacks in application code, developers often opt-out of reentrancy protection. This cost has come down with the advent of transient storage (<a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a>), but it is still not cheap enough where it is a "no-brainer" to use it by default. This EIP proposes opcodes which make it cheaper to protect against reentrancy in application code.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Two new opcodes are introduced, <code>NONREENTRANT</code> (0xF6) and <code>REENTRANT</code> (0xF7), which set and clear a contract's nonreentrancy flag. The effect of invoking <code>NONREENTRANT</code> is that a contract can no longer have execution context transferred to it (via any of the <code>*CALL</code> opcodes), until <code>REENTRANT</code> is invoked. <code>CALL</code>ing a contract which has the nonreentrancy flag set is equivalent to executing a single <code>REVERT</code> opcode.</p> <p>Both <code>NONREENTRANT</code> and <code>REENTRANT</code> are idempotent; that is, invoking <code>NONREENTRANT</code> when a contract already has nonreentrant status is a no-op, and likewise for <code>REENTRANT</code>.</p> <p>The scope of the nonreentrant flag is limited to the current transaction. That is, nonreentrant flags are cleared at the end of every transaction. In the presence of reversion (<code>REVERT</code> or exceptional halt), the contract's nonreentrancy flag reverts to whatever its value was before the call.</p> <p>The cost of <code>NONREENTRANT</code> and <code>REENTRANT</code> are both set at 5 (<code>G_mid</code>).</p> <h2 id="rationale">Rationale</h2> <p>The computational cost of pushing the current value to the call stack (for handling reverts) is accounted for in the overhead cost of the <code>*CALL</code> opcodes.</p> <p>An alternative design could be considered which only introduces one opcode. This opcode, <code>NONREENTRANT</code>, would take a single stack item and set the nonreentrancy flag based on its value. This alternative design can be considered based on feedback.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="reference-implementation">Reference Implementation</h2> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-07T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Sam Wilsonhttps://github.com/SamWilsn Ansgar Dietrichshttps://github.com/adietrichs lightclienthttps://github.com/lightclient https://wg-eips.ritovision.com/7702/

Add a new tx type that permanently sets the code for an EOA

<h2 id="abstract">Abstract</h2> <p>Add a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type that allows Externally Owned Accounts (EOAs) to set the code in their account. This is done by attaching a list of authorization tuples -- individually formatted as <code>[chain_id, address, nonce, y_parity, r, s]</code> -- to the transaction. For each tuple, a delegation indicator <code>(0xef0100 || address)</code> is written to the authorizing account's code. All code executing operations must load and execute the code pointed to by the delegation.</p> <h2 id="motivation">Motivation</h2> <p>Despite great advances in the smart contract wallet ecosystem, EOAs have held back broad adoption of UX improvements across applications. This EIP therefore focuses on adding short-term functionality improvements to EOAs which will allow UX improvements to permeate through the entire application stack. Three particular features this EIP is designed around are:</p> <ul> <li><strong>Batching</strong>: allowing multiple operations from the same user in one atomic transaction. One common example is an <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> approval followed by spending that approval. This is a common workflow in DEXes that requires two transactions today. Advanced use cases of batching occasionally involve dependencies: the output of the first operation is part of the input to the second operation.</li> <li><strong>Sponsorship</strong>: account X pays for a transaction on behalf of account Y. Account X could be paid in some other ERC-20 for this service, or it could be an application operator including the transactions of its users for free.</li> <li><strong>Privilege de-escalation</strong>: users can sign sub-keys and give them specific permissions that are much weaker than global access to the account. For example, a permission to spend ERC-20 tokens but not ETH, or to spend up to 1% of the total balance per day, or to interact only with a specific application.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>SET_CODE_TX_TYPE</code></td><td><code>0x04</code></td></tr> <tr><td><code>MAGIC</code></td><td><code>0x05</code></td></tr> <tr><td><code>PER_AUTH_BASE_COST</code></td><td><code>12500</code></td></tr> <tr><td><code>PER_EMPTY_ACCOUNT_COST</code></td><td><code>25000</code></td></tr> </tbody></table> <h3 id="set-code-transaction">Set code transaction</h3> <p>A new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction known as the "set code transaction" is introduced, where the <code>TransactionType</code> is <code>SET_CODE_TX_TYPE</code> and the <code>TransactionPayload</code> is the RLP serialization of the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,</span></span> <span class="giallo-l"><span>destination, value, data, access_list, authorization_list, signature_y_parity,</span></span> <span class="giallo-l"><span>signature_r, signature_s])</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]</span></span></code></pre> <p>The fields <code>chain_id</code>, <code>nonce</code>, <code>max_priority_fee_per_gas</code>, <code>max_fee_per_gas</code>, <code>gas_limit</code>, <code>destination</code>, <code>value</code>, <code>data</code>, and <code>access_list</code> of the outer transaction follow the same semantics as <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>. <em>Note, this implies a null destination is not valid.</em></p> <p>The <code>signature_y_parity, signature_r, signature_s</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(SET_CODE_TX_TYPE || TransactionPayload)</code>.</p> <p>The <code>authorization_list</code> is a list of tuples that indicate what code the signer of each tuple desires to execute in the context of their EOA. The transaction is considered invalid if the length of <code>authorization_list</code> is zero.</p> <p>The transaction is also considered invalid when any field in an authorization tuple cannot fit within the following bounds:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> auth</span><span>.</span><span>chain_id</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> auth</span><span>.</span><span>nonce</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">64</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-support"> len</span><span>(</span><span>auth</span><span>.</span><span>address</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 20</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> auth</span><span>.</span><span>y_parity</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">8</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> auth</span><span>.</span><span>r</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> auth</span><span>.</span><span>s</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span></code></pre> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <h4 id="behavior">Behavior</h4> <p>The authorization list is processed before the execution portion of the transaction begins, but after the sender's nonce is incremented.</p> <p>For each <code>[chain_id, address, nonce, y_parity, r, s]</code> tuple, perform the following:</p> <ol> <li>Verify the chain ID is 0 or the ID of the current chain.</li> <li>Verify the <code>nonce</code> is less than <code>2**64 - 1</code>.</li> <li>Let <code>authority = ecrecover(msg, y_parity, r, s)</code>. <ul> <li>Where <code>msg = keccak(MAGIC || rlp([chain_id, address, nonce]))</code>.</li> <li>Verify <code>s</code> is less than or equal to <code>secp256k1n/2</code>, as specified in <a href="https://wg-eips.ritovision.com/2/">EIP-2</a>.</li> </ul> </li> <li>Add <code>authority</code> to <code>accessed_addresses</code>, as defined in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</li> <li>Verify the code of <code>authority</code> is empty or already delegated.</li> <li>Verify the nonce of <code>authority</code> is equal to <code>nonce</code>.</li> <li>Add <code>PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST</code> gas to the global refund counter if <code>authority</code> is not empty.</li> <li>Set the code of <code>authority</code> to be <code>0xef0100 || address</code>. This is a delegation indicator. <ul> <li>If <code>address</code> is <code>0x0000000000000000000000000000000000000000</code>, do not write the delegation indicator. Clear the account's code by resetting the account's code hash to the empty code hash <code>0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code>.</li> </ul> </li> <li>Increase the nonce of <code>authority</code> by one.</li> </ol> <p>If any step above fails, immediately stop processing the tuple and continue to the next tuple in the list. When multiple tuples from the same authority are present, set the code using the address in the last valid occurrence.</p> <p>Note, if transaction execution results in failure (e.g. any exceptional condition or code reverting), the processed delegation indicators is <em>not rolled back</em>.</p> <h5 id="delegation-indicator">Delegation indicator</h5> <p>Delegation indicators use the banned opcode <code>0xef</code>, defined in <a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>, to indicate that the code must be handled differently than regular code. The delegation forces all code executing operations to follow the address pointer to obtain the code to execute. For example, <code>CALL</code> loads the code at <code>address</code> and executes it in the context of <code>authority</code>.</p> <p>The affected executing operations are:</p> <ul> <li><code>CALL</code></li> <li><code>CALLCODE</code></li> <li><code>DELEGATECALL</code></li> <li><code>STATICCALL</code></li> <li>any transaction where <code>destination</code> points to an address with a delegation indicator present</li> </ul> <p>For code reading, only <code>CODESIZE</code> and <code>CODECOPY</code> instructions are affected. They operate directly on the executing code instead of the delegation. For example, when executing a delegated account <code>EXTCODESIZE</code> returns <code>23</code> (the size of <code>0xef0100 || address</code>) whereas <code>CODESIZE</code> returns the size of the code residing at <code>address</code>.</p> <p><em>Note, this means during delegated execution <code>CODESIZE</code> and <code>CODECOPY</code> produce a different result compared to calling <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> on the authority.</em></p> <h6 id="precompiles">Precompiles</h6> <p>When a precompile address is the target of a delegation, the retrieved code is considered empty and <code>CALL</code>, <code>CALLCODE</code>, <code>STATICCALL</code>, <code>DELEGATECALL</code> instructions targeting this account will execute empty code, and therefore succeed with no execution when given enough gas to initiate the call.</p> <h6 id="loops">Loops</h6> <p>In case a delegation indicator points to another delegation, creating a potential chain or loop of delegations, clients must retrieve only the first code and then stop following the delegation chain.</p> <h4 id="gas-costs">Gas Costs</h4> <p>The intrinsic cost of the new transaction is inherited from <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, specifically <code>21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count</code>. Additionally, add a cost of <code>PER_EMPTY_ACCOUNT_COST * authorization list length</code>.</p> <p>The transaction sender will pay for all authorization tuples, regardless of validity or duplication.</p> <p>If a code executing instruction accesses a cold account during the resolution of delegated code, add an additional <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> <code>COLD_ACCOUNT_READ_COST</code> cost of <code>2600</code> gas to the normal cost and add the account to <code>accessed_addresses</code>. Otherwise, assess a <code>WARM_STORAGE_READ_COST</code> cost of <code>100</code>.</p> <h4 id="transaction-origination">Transaction origination</h4> <p>Modify the restriction put in place by <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a> to allow EOAs whose code is a valid delegation indicator, i.e. <code>0xef0100 || address</code>, to originate transactions. Accounts with any other code values may not originate transactions.</p> <p>Additionally, if a transaction's <code>destination</code> has a delegation indicator, add the target of the delegation to <code>accessed_addresses</code>.</p> <h2 id="rationale">Rationale</h2> <p>Below is the rationale for both general design directions of the EIP, as well as specific technical choices.</p> <h3 id="general-design-philosophy">General design philosophy</h3> <h4 id="persistence-of-code-delegation">Persistence of code delegation</h4> <p>The first draft of this proposal had a clever idea to avoid disagreement on whether in-protocol revocation was needed or not. The idea was to temporarily set code in the account with the authorization. After the transaction finished, the code would be completely cleared. This was a new design space for enriching EOA functionality.</p> <p>Even this approach was not without its flaws. Fundamentally, there was not much friction for users including set code authorizations. This meant that some users and applications would opt to treat the extension as more of a scripting facility, rather than a full-fledged upgrade to a smart contract wallet. The outcome of this would be two somewhat competing workstreams for UX improvements: smart contract wallets and EOA scripts.</p> <p>Previous proposals had been met with similar criticisms. To counteract this, persistent delegations were introduced. They create enough friction in deployment that users will not deploy new, unique ones regularly. This will hopefully unify the workstreams and minimize fragmentation in UX developments.</p> <h4 id="no-initcode">No initcode</h4> <p>Running initcode is not desirable for many reasons. It creates a new mode of execution that needs extensive testing, and may be used for purposes not possible with standard smart contract wallets. It also forces developers to perform initialization as a standard call to the EOA after delegation. The lack of atomicity in these operations is another factor that will push users to complete smart contract wallet solutions, instead of EOA scripts.</p> <p>Additionally, initcode tends to be propagated inside the transaction calldata. This means it would need to be included in the authorization tuple and signed over. The minimum initcode is around 15 bytes -- it would simply copy the contract code from an external address. The total cost would be <code>16 * 15 = 240</code> calldata cost, plus the <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> cost of <code>2 * 15 = 30</code>, plus the runtime costs of around <code>150</code>. So nearly <code>500</code> additional gas would be spent preparing the account. Even more likely, 1200+ gas if not copying from an external account.</p> <h4 id="creation-by-template">Creation by template</h4> <p>Initcode or not, there is a question of how users should specify the code they intend to run in their account. The two main options are to specify the bytecode directly in the transaction or to specify a pointer to the code. The simplest pointer would just be the address of code deployed on-chain.</p> <p>The cost analysis makes the answer clear. The smallest proxy would be around 50 bytes and an address is 20 bytes. The 30 byte difference provides no useful additional functionality and will be inefficiently replicated billions of times.</p> <p>Furthermore, specifying code directly would again make it possible for EOAs to have a new, unique ability to execute arbitrary code specified in the transaction calldata. It is for these reasons that creation by template is chosen.</p> <h4 id="interaction-with-applications-and-wallets">Interaction with applications and wallets</h4> <p>While this EIP provides a lot of flexibility to applications and EOAs, there are incorrect ways of using it. Applications <strong>must not</strong> expect that they can suggest the user sign an authorization, and therefore it is the duty of the wallet to not provide an interface to do so.</p> <p><strong>There is no safe way to provide this interface</strong>. The code specified by an authorization has unrestricted access to the account and must always be closely audited by the wallet. Few users have the level of sophistication to reasonably verify the code they are delegating to.</p> <p>It is also not possible to implement a system of permissions at this level to minimize the risk. If applications require custom wallet functionality, they must use standardized extension / module systems built on top of the delegated code that correctly implements permissions.</p> <h4 id="forward-compatibility-with-future-account-abstraction">Forward-compatibility with future account abstraction</h4> <p>This EIP is designed to be forward-compatible with endgame account abstraction, without over-enshrining any fine-grained details of <a href="https://wg-eips.ritovision.com/4337/">ERC-4337</a> or RIP-7560.</p> <p>To start, the <code>address</code> that users sign could directly point to existing ERC-4337 wallet code. This essentially requires the "code pathways" that are used are code pathways that would, in most cases, continue to make sense in a pure-smart-contract-wallet world. Hence, it avoids the problem of creating two separate UX workstreams because, to a large extent, they would be the same ecosystem.</p> <p>There will be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset. The EIP does not require adding any opcodes, that would become dangling and useless in a post-EOA world, and it allows EOAs to masquerade as contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing <code>EntryPoint</code>.</p> <h4 id="self-sponsoring-allowing-tx-origin-to-set-code">Self-sponsoring: allowing <code>tx.origin</code> to set code</h4> <p>Allowing <code>tx.origin</code> to set code and execute its own delegated code enables what is called self-sponsoring. It allows users to take advantage of EIP-7702 without relying on any third party infrastructure.</p> <p>However, that means the EIP breaks the invariant that <code>msg.sender == tx.origin</code> only happens in the topmost execution frame of a transaction. This will affect smart contracts containing <code>require(msg.sender == tx.origin)</code> style checks. This check is used for at least three purposes:</p> <ol> <li>Ensuring that <code>msg.sender</code> is an EOA (given that <code>tx.origin</code> always has to be an EOA). This invariant does not depend on the execution layer depth and, therefore, is not affected.</li> <li>Protecting against atomic sandwich attacks like flash loans, which rely on the ability to modify state before and after the execution of the target contract as part of the same atomic transaction. This protection would be broken by this EIP. However, relying on <code>tx.origin</code> in this way is considered bad practice, and can already be circumvented by miners conditionally including transactions in a block.</li> <li>Preventing reentrancy.</li> </ol> <p>Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal). On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive.</p> <p>This distribution of occurrences—many (1), some (2), and no (3)—is exactly what the authors of this EIP expect because:</p> <ul> <li>Determining if <code>msg.sender</code> is an EOA without <code>tx.origin</code> is difficult, if not impossible.</li> <li>The only execution context which is safe from atomic sandwich attacks is the topmost context, and <code>tx.origin == msg.sender</code> is the only way to detect that context.</li> <li>In contrast, there are many direct and flexible ways of preventing reentrancy (e.g., using a transient storage variable). Since <code>msg.sender == tx.origin</code> is only true in the topmost context, it would make an obscure tool for preventing reentrancy, rather than other more common approaches.</li> </ul> <p>There are other approaches to mitigate this restriction which do not break the invariant:</p> <ul> <li>Set <code>tx.origin</code> to a constant <code>ENTRY_POINT</code> address when using the <code>CALL*</code> instruction in the context of an EOA.</li> <li>Set <code>tx.origin</code> to a special address derived from the sender or signer addresses.</li> <li>Disallow <code>tx.origin</code> from setting code. This would make the simple batching use cases impossible, but could be relaxed in the future.</li> </ul> <h3 id="rationale-for-technical-details">Rationale for technical details</h3> <h4 id="cost-of-delegation">Cost of delegation</h4> <p>The <code>PER_AUTH_BASE_COST</code> is the cost to process the authorization tuple and set the delegation destination. To compute a fair cost for this operation, the authors review its impact on the system:</p> <ul> <li>ferry 101 bytes of calldata = <code>101 * non-zero cost (16) = 1616</code></li> <li>recovering the <code>authority</code> address = <code>3000</code></li> <li>reading the nonce and code of <code>authority</code> = <code>2600</code></li> <li>storing values in already warm account = <code>200</code></li> <li>cost to deploy code = <code>200 * 23 = 4600</code></li> </ul> <p>The impact-based assessment identifies <code>12016</code> gas of comparable computation for the operation. It is rounded up to <code>12500</code> to account for miscellaneous costs associated with shuttling data around the state transition.</p> <h4 id="clearing-delegation-indicators">Clearing delegation indicators</h4> <p>A general design goal in state transition changes is to minimize the number of special cases an EIP has. In early iterations, this EIP resisted a special case for clearing an account's delegation indicator.</p> <p>For most intents and purposes, an account delegated to <code>0x0</code> is indistinguishable from a true EOA. However, one particular unfortunate case is unavoidable. Even if a user has a zeroed out delegation indicator, most operations that interact with that account will incur an additional <code>COLD_ACCOUNT_READ_COST</code> upon the first touch caused by attempting to load the code at <code>0x0</code>.</p> <p>For this reason, the authors have opted to include a special case which allow users to restore their EOA to its original purity.</p> <h4 id="lack-of-instruction-prohibition">Lack of instruction prohibition</h4> <p>Consistency is a valuable property in the EVM, both from an implementation perspective and a user-understanding-perspective. Despite considering bans on several families of instructions in the context of EOAs, the authors feel there is not a compelling reason to do so, as it would cause smart contract wallets and EOA smart contract wallets to proceed down distinct UX workstreams.</p> <p>The main instruction families where a ban was considered were storage related and contract creation related. The decision to not ban storage instructions hinged mostly on their importance to smart contract wallets. Although it's possible to have an external storage contract that the smart contract wallet calls into, it is unnecessarily complicated and inefficient. In the future, new state schemes may allow substantially cheaper access to certain storage slots within an account. This is something smart contract wallets will want to take advantage of that a storage contract wouldn't support.</p> <p>Creation instructions were considered for a ban as well on other similar EIPs, however because this EIP allows EOAs to spend value intra-transaction, the concern with bumping the nonce intra-transaction and invalidating pending transactions is not significant.</p> <h4 id="protection-from-malleability-cross-chain">Protection from malleability cross-chain</h4> <p>One consideration when signing a code pointer is what code that address points to on another chain. While it is possible to create a deterministic deployment, i.e. via Nick's method, verifying such a deployment may not always be desirable. In such situations, the chain ID can be set to reduce the scope of the authorization. When universal deployment is preferred, simply set chain ID to 0.</p> <p>An alternative to adding chain ID could be to substitute in the actual code for the address in the signature. This seems to have the benefit of both minimizing the on-chain size of auth tuples, by continuing to serialize only the address, while retaining specificity of the actual code running in the account, by pulling in the code for the signature. One unfortunate issue of this format, though, is that it imposes a database lookup to determine the signer of each auth tuple. This imposition itself seems to create enough complexity in transaction propagation that it is decided to avoid and simply sign over the address directly.</p> <h4 id="delegation-of-code-execution-only">Delegation of code execution only</h4> <p>Other code retrieving operations like <code>EXTCODEHASH</code> do not automatically follow delegations, they operate on the delegation indicator itself. If instead delegations were followed, an account would be able to temporarily masquerade as having a particular codehash, which would break contracts that rely on codehashes as a definition of possible account behavior. A change of behavior in a contract is currently only possible if its code explicitly allows it (in particular via <code>DELEGATECALL</code>), and a change of codehash is only possible in the presence of <code>SELFDESTRUCT</code> (which, as of Cancun, only applies in the same transaction as contract creation), so choosing to follow delegations in <code>EXTCODE*</code> opcodes would have created a new type of account breaking prior assumptions.</p> <h4 id="charge-maximum-cost-upfront">Charge maximum cost upfront</h4> <p>While computing the intrinsic gas cost, the transaction is charged the worst-case cost for each delegation. Later, while processing the authorization list, a refund is issued if the account already exists in state. This mechanism is designed to avoid state lookups for each authorization when computing the intrinsic gas and can quickly determine the validity of the transaction with only a state lookup on the sender's account.</p> <h4 id="no-blobs-no-contract-creation">No blobs, no contract creation</h4> <p>Transactions should be thought of as specialized tools and not necessarily a one-type-does-all solution. EIP-4844 is treated differently at the p2p level due to burden blobs place on a node's bandwidth. EIP-7702 has different implications on transaction gossiping and there is no need to complicate those rules unnecessarily by making it a superset of all possible functionality. The authors ultimately do not expect there to be much demand for atomic delegation and blob submission.</p> <p>Contract creation is another specialized use case that has been grandfathered into several transaction types. It adds complexity to testing, because it is a new distinct branch of execution that needs to be tested when any change to the EVM occurs and verify the change works as expected in that context.</p> <p>For these reasons, the authors have chosen to keep the scope of the EIP focused on improving UX.</p> <h4 id="disallow-delegation-to-precompiles">Disallow delegation to precompiles</h4> <p>Precompiles are themselves edge cases, so allowing delegations to precompiles or not requires some focus in implementation. Considering the fact that precompiles technically do not have code associated with their accounts, the authors decided it would be marginally simpler to not execute the precompile logic when a user delegates to one. This is somewhat unintuitive.</p> <h4 id="non-empty-authorization-list-required">Non-empty authorization list required</h4> <p>Set code transactions are required to have at least one authorization to be considered valid. This is to disincentivize senders from using type 4 transactions as a generic transaction format, because this transaction has different implications on the transaction pool than, say, <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> transactions.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP breaks a few invariants:</p> <ul> <li>An account balance can only decrease as a result of a transaction originating from that account. <ul> <li>Once an account has been delegated, any call to the account may also cause the balance to decrease.</li> </ul> </li> <li>An EOA nonce may not increase after transaction execution has begun. <ul> <li>Once an account has been delegated, the account may call a create operation during execution, causing the nonce to increase.</li> </ul> </li> <li><code>tx.origin == msg.sender</code> can only be true in the topmost frame of execution. <ul> <li>Once an account has been delegated, it can invoke multiple calls per transaction.</li> </ul> </li> </ul> <h2 id="security-considerations">Security Considerations</h2> <h3 id="implementation-of-secure-delegate-contracts">Implementation of secure delegate contracts</h3> <p>The following is a non-exhaustive list of pitfalls that delegate contracts <em>should</em> be wary of and require a signature over from the account's authority:</p> <ul> <li>Replay protection (e.g., a nonce) should be implemented by the delegate and signed over. Without it, a malicious actor can reuse a signature, repeating its effects.</li> <li><code>value</code> -- without it, a malicious sponsor could cause unexpected effects in the callee.</li> <li><code>gas</code> -- without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.</li> <li><code>target</code> / <code>calldata</code> -- without them, a malicious actor may call arbitrary functions in arbitrary contracts.</li> </ul> <p>A poorly implemented delegate can <em>allow a malicious actor to take near complete control over a signer's EOA</em>.</p> <h3 id="front-running-initialization">Front running initialization</h3> <p>Smart contract wallet developers must consider the implications of setting code in an account without execution. Contracts are normally deployed by executing initcode to determine the exact code to be placed in the account. This gives developers the opportunity to initialize storage slots at the same time. The initial values of the account cannot be replaced by an observer, because they are either signed over by an EOA in the case of a creation transaction or they are committed to by computing the contract's address deterministically from the hash of the initcode.</p> <p>This EIP does not provide developers the opportunity to run initcode and set storage slots during delegation. To secure the account from an observer front-running the initialization of the delegation with an account they control, smart contract wallet developers must verify the initial calldata to the account for setup purposes be signed by the EOA's key using ecrecover. This ensures the account can only be initialized with desirable values.</p> <h3 id="storage-management">Storage management</h3> <p>Changing an account's delegation is a security-critical operation that should not be done lightly, especially if the newly delegated code is not purposely designed and tested as an upgrade to the old one.</p> <p>In particular, in order to ensure a safe migration of an account from one delegate contract to another, it's important for these contracts to use storage in a way that avoids accidental collisions among them. For example, using <a href="https://wg-eips.ritovision.com/7201/">ERC-7201</a> a contract may root its storage layout at a slot dependent on a unique identifier. To simplify this, smart contract languages may provide a way of re-rooting the entire storage layout of existing contract source code.</p> <p>If all contracts previously delegated to by the account used the approach described above, a migration should not cause any issues. However, if there is any doubt, it is recommended to first clear all account storage, an operation that is not natively offered by the protocol but that a special-purpose delegate contract can be designed to implement.</p> <h3 id="setting-code-as-tx-origin">Setting code as <code>tx.origin</code></h3> <p>Allowing the sender of an EIP-7702 to also set code has the possibility to:</p> <ul> <li>Break atomic sandwich protections which rely on <code>tx.origin</code>;</li> <li>Break reentrancy guards of the style <code>require(tx.origin == msg.sender)</code>.</li> </ul> <p>The authors of this EIP believe the risks of allowing this are acceptable for the reasons outlined in the Rationale section.</p> <h3 id="sponsored-transaction-relayers">Sponsored transaction relayers</h3> <p>It is possible for the <code>authorized</code> account to cause sponsored transaction relayers to spend gas without being reimbursed by either invalidating the authorization (i.e., increasing the account's nonce) or by sweeping the relevant assets out of the account. Relayers should be designed with these cases in mind, possibly by requiring a bond to be deposited or by implementing a reputation system.</p> <h3 id="transaction-propagation">Transaction propagation</h3> <p>Allowing EOAs to behave as smart contracts via the delegation indicator poses some challenges for transaction propagation. Traditionally, EOAs have only been able to send value via a transaction. This invariant allows nodes to statically determine the validity of transactions for that account. In other words, a single transaction has only been able to invalidate transactions pending from the sender's account.</p> <p>With this EIP, it becomes possible to cause transactions from other accounts to become stale. This is due to the fact that once an EOA has delegated to code, that code can be called by anyone at any point in a transaction. It becomes impossible to know if the balance of the account has been swept in a static manner.</p> <p>While there are a few mitigations for this, the authors recommend that clients do not accept more than one pending transaction for any EOA with a non-zero delegation indicator. This minimizes the number of transactions that can be invalidated by a single transaction.</p> <p>An alternative would be to expand the EIP-7702 transaction with a list of accounts the caller wishes to "hydrate" during the transaction. Those accounts behave as the delegated code <em>only</em> for EIP-7702 transactions which include them in such a list, thus returning to clients the ability to statically analyze and reason about pending transactions.</p> <p>A related issue is that an EOA's nonce may be incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn't a major concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-07T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/7703/

Increase calldata cost to decrease the maximum block size

<h2 id="abstract">Abstract</h2> <p>An adjustment in the Ethereum calldata cost which reduces the maximum possible block size and allows a higher block gas limit.</p> <h2 id="motivation">Motivation</h2> <p>Larger blocks take longer to propagate through the network. In this way, the maximum potential block size is constraining the block gas limit. Therefore, in order to safely increase the block gas limit, the calldata gas must be increased.</p> <h2 id="specification">Specification</h2> <ul> <li>Increase <code>G_CALLDATAZERO</code> from 4 to 12.</li> <li>Increase <code>G_CALLDATANONZERO</code> from 16 to 48.</li> </ul> <h2 id="rationale">Rationale</h2> <p>Tripling the gas cost of calldata reduces the maximum possible block size by a factor of three.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Activation can cause some transactions to revert due to the increased gas costs. Ahead of activation, <code>eth_estimateGas</code> could be calculated using the new parameters in order to provide results viable for activation, avoiding out-of-gas reverts.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security issues have been found.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-05-01T00:00:00+00:00 2026-02-11T14:49:28+00:00 Vitalik Buterinhttps://github.com/vbuterin Yoav Weisshttps://github.com/yoavw Alex Forshtathttps://github.com/forshtat Dror Tiroshhttps://github.com/drortirosh Shahaf Nacsonhttps://github.com/shahafn https://wg-eips.ritovision.com/7701/

Native Account Abstraction protocol, relying on a new transaction type and a family of opcodes

<h2 id="abstract">Abstract</h2> <p>We propose splitting the Ethereum transaction scope into multiple steps: validations, execution, and post-operation logic. Transaction validity is determined by the result of the validation steps of a transaction.</p> <p>We further separate transaction validation for the purposes of authorization and the gas fee payment, allowing one contract to pay gas for a transaction that will be executed from another contract.</p> <h2 id="motivation">Motivation</h2> <p>Native Account Abstraction allows custom validation logic of a transaction and custom gas payment logic, opening new use-cases and features for wallets and dApps.</p> <p>A more detailed motivation for this proposal can be found in the <a href="https://wg-eips.ritovision.com/7701/assets/README/">README document</a>.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>AA_TX_TYPE</code></td><td>TBD</td></tr> <tr><td><code>AA_ENTRY_POINT</code></td><td><code>address(0x7701)</code></td></tr> <tr><td><code>AA_BASE_GAS_COST</code></td><td>15000</td></tr> <tr><td><code>ROLE_SENDER_DEPLOYMENT</code></td><td><code>0xA0</code></td></tr> <tr><td><code>ROLE_SENDER_VALIDATION</code></td><td><code>0xA1</code></td></tr> <tr><td><code>ROLE_PAYMASTER_VALIDATION</code></td><td><code>0xA2</code></td></tr> <tr><td><code>ROLE_SENDER_EXECUTION</code></td><td><code>0xA3</code></td></tr> <tr><td><code>ROLE_PAYMASTER_POST_OP</code></td><td><code>0xA4</code></td></tr> </tbody></table> <h3 id="new-transaction-type">New Transaction Type</h3> <p>A new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction with type <code>AA_TX_TYPE</code> is introduced. Transactions of this type are referred to as "AA transactions".</p> <p>Their payload should be interpreted as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>AA_TX_TYPE || rlp([</span></span> <span class="giallo-l"><span> chain_id,</span></span> <span class="giallo-l"><span> nonce,</span></span> <span class="giallo-l"><span> sender, sender_validation_data,</span></span> <span class="giallo-l"><span> deployer, deployer_data,</span></span> <span class="giallo-l"><span> paymaster, paymaster_data,</span></span> <span class="giallo-l"><span> sender_execution_data,</span></span> <span class="giallo-l"><span> max_priority_fee_per_gas, max_fee_per_gas,</span></span> <span class="giallo-l"><span> sender_validation_gas, paymaster_validation_gas,</span></span> <span class="giallo-l"><span> sender_execution_gas, paymaster_post_op_gas,</span></span> <span class="giallo-l"><span> access_list,</span></span> <span class="giallo-l"><span> authorization_list</span></span> <span class="giallo-l"><span>])</span></span> <span class="giallo-l"></span></code></pre><h3 id="current-role-and-accept-role-opcodes"><code>CURRENT_ROLE</code> and <code>ACCEPT_ROLE</code> opcodes</h3> <p><code>current_context_role</code> is a context variable set by the AA transaction to the current role. During AA transactions, it is set to the current role in the transaction's lifecycle for each top level call. During non-AA transactions it is always set to <code>ROLE_SENDER_EXECUTION</code>. It remains unchanged on <code>DELEGATECALL</code> but is reset to <code>ROLE_SENDER_EXECUTION</code> on <code>CALL</code> / <code>STATICCALL</code> / <code>CALLCODE</code>. This behavior resembles <code>msg.sender</code>.</p> <p>The <code>CURRENT_ROLE</code> opcode returns the <code>current_context_role</code> value.</p> <p>The <code>ACCEPT_ROLE</code> opcode is equivalent to <code>RETURN</code> in the sense that it copies a memory slice, ends execution, and pastes the memory slice onto parent returndata, with a single modification:</p> <ul> <li>It accepts the <code>frame_role</code> as the additional input parameter, and reverts if it differs from the <code>current_context_role</code></li> </ul> <p>For each <code>role</code> in the transaction's lifecycle, a successful <code>ACCEPT_ROLE</code> is expected with the <code>frame_role == role</code>. If any validation frame failed to perform an <code>ACCEPT_ROLE</code> matching its role, the transaction fails the validity checks and cannot be included.</p> <h3 id="txparam-opcodes"><code>TXPARAM*</code> opcodes</h3> <p>The <code>TXPARAMDLOAD</code>, <code>TXPARAMSIZE</code>, <code>TXPARAMCOPY</code> opcodes follow the pattern of <code>CALLDATA*</code> / <code>RETURNDATA*</code> opcode families.</p> <p>Each <code>TXPARAM*</code> opcode takes an extra stack input value as a first input compared to its <code>CALLDATA*</code> equivalent. The values of this input are as follows:</p> <table><thead><tr><th><code>n</code></th><th>Return value</th><th>Data size</th><th>Default</th><th>Comment</th></tr></thead><tbody> <tr><td>0x00</td><td>current transaction type</td><td>32</td><td></td><td></td></tr> <tr><td>0x01</td><td><code>nonce</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x02</td><td><code>sender</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x03</td><td><code>sender_validation_data</code></td><td>dynamic</td><td></td><td></td></tr> <tr><td>0x04</td><td><code>deployer</code></td><td>0 or 32</td><td><code>address(0)</code></td><td></td></tr> <tr><td>0x05</td><td><code>deployer_data</code></td><td>dynamic</td><td>empty array</td><td></td></tr> <tr><td>0x06</td><td><code>paymaster</code></td><td>0 or 32</td><td><code>address(0)</code></td><td></td></tr> <tr><td>0x07</td><td><code>paymaster_data</code></td><td>dynamic</td><td>empty array</td><td></td></tr> <tr><td>0x08</td><td><code>sender_execution_data</code></td><td>dynamic</td><td></td><td></td></tr> <tr><td>0x0B</td><td><code>max_priority_fee_per_gas</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x0C</td><td><code>max_fee_per_gas</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x0D</td><td><code>sender_validation_gas</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x0E</td><td><code>paymaster_validation_gas</code></td><td>32</td><td><code>0</code></td><td></td></tr> <tr><td>0x0F</td><td><code>sender_execution_gas</code></td><td>32</td><td></td><td></td></tr> <tr><td>0x10</td><td><code>paymaster_post_op_gas</code></td><td>32</td><td><code>0</code></td><td></td></tr> <tr><td>0x11</td><td><code>access_list</code> hash</td><td>32</td><td></td><td></td></tr> <tr><td>0x12</td><td><code>authorization_list</code> hash</td><td>32</td><td></td><td></td></tr> <tr><td>0xf1</td><td><code>execution_status</code></td><td>32</td><td></td><td>See transaction scoped vars in <a href="https://wg-eips.ritovision.com/7701/#aa-transaction-processing-flow">processing flow</a></td></tr> <tr><td>0xf2</td><td><code>execution_gas_used</code></td><td>32</td><td></td><td>See transaction scoped vars in <a href="https://wg-eips.ritovision.com/7701/#aa-transaction-processing-flow">processing flow</a></td></tr> <tr><td>0xff</td><td><code>tx_hash_for_signature</code></td><td>32</td><td></td><td>Hash of the transaction without the signature</td></tr> </tbody></table> <h3 id="affected-opcodes">Affected opcodes</h3> <p>In all top-level frames, the global variables have the following meaning:</p> <table><thead><tr><th>Opcode Name</th><th>Solidity Equivalent</th><th>Value</th></tr></thead><tbody> <tr><td><code>CALLER</code></td><td><code>msg.sender</code></td><td>The <code>AA_ENTRY_POINT</code> address</td></tr> <tr><td><code>ORIGIN</code></td><td><code>tx.origin</code></td><td>The transaction <code>sender</code> address</td></tr> <tr><td><code>CALLDATA*</code></td><td><code>msg.data</code></td><td>Empty for all call frames except for the sender execution frame, for which it is set to <code>sender_execution_data</code></td></tr> </tbody></table> <h3 id="costs-of-accessing-cold-addresses-for-sender-paymaster-and-deployer">Costs of accessing cold addresses for Sender, Paymaster, and Deployer</h3> <p>The Sender address is pre-warmed as part of the <code>AA_BASE_GAS_COST</code>.</p> <p>When a non-zero address that is not equal to the <code>Sender</code> address, is provided for a <code>Paymaster</code> or a <code>Deployer</code> contract, an additional <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> <code>ACCESS_LIST_ADDRESS_COST</code> cost of <strong>2400 gas</strong> is charged and the address is added to <code>accessed_addresses</code>.</p> <h3 id="aa-transaction-processing-flow">AA transaction processing flow</h3> <p>We define processing flow for an AA transaction as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def state_transition_function(tx, block, state):</span></span> <span class="giallo-l"><span> # Empty refunds, warm list, execution status and gas used (new), etc</span></span> <span class="giallo-l"><span> state.transaction_scoped_vars = {}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> max_gas = tx.sender_validation_gas + tx.paymaster_validation_gas + tx.sender_execution_gas + tx.paymaster_post_op_gas</span></span> <span class="giallo-l"><span> gas_price = min(tx.max_fee_per_gas, block.base_fee_per_gas + tx.max_priority_fee_per_gas)</span></span> <span class="giallo-l"><span> payer = tx.sender if tx.paymaster is None else tx.paymaster</span></span> <span class="giallo-l"><span> total_max_cost = max_gas * gas_price</span></span> <span class="giallo-l"><span> balances[payer] -= total_max_cost</span></span> <span class="giallo-l"><span> gas_used = 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if get_code(tx.sender) is None:</span></span> <span class="giallo-l"><span> deployer_result = call(tx.deployer, [], tx.sender_validation_gas_limit, ROLE_SENDER_DEPLOYMENT)</span></span> <span class="giallo-l"><span> assert deployer_result.accepted_role == ROLE_SENDER_DEPLOYMENT</span></span> <span class="giallo-l"><span> gas_used += deployer_result.gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> sender_result = call(tx.sender, [], tx.sender_validation_gas_limit - gas_used, ROLE_SENDER_VALIDATION)</span></span> <span class="giallo-l"><span> assert sender_result.accepted_role == ROLE_SENDER_VALIDATION</span></span> <span class="giallo-l"><span> gas_used += sender_result.gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if tx.paymaster:</span></span> <span class="giallo-l"><span> paymaster_result = call(tx.paymaster, [], tx.paymaster_validation_gas, ROLE_PAYMASTER_VALIDATION)</span></span> <span class="giallo-l"><span> assert paymaster_result.accepted_role == ROLE_PAYMASTER_VALIDATION</span></span> <span class="giallo-l"><span> gas_used += paymaster_result.gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> checkpoint = state.take_snapshot()</span></span> <span class="giallo-l"><span> sender_execution_result = call(tx.sender, [], tx.sender_execution_gas, ROLE_SENDER_EXECUTION)</span></span> <span class="giallo-l"><span> gas_used += sender_execution_result.gas_used</span></span> <span class="giallo-l"><span> state.transaction_scoped_vars[execution_status] = sender_execution_result.output_code</span></span> <span class="giallo-l"><span> state.transaction_scoped_vars[execution_gas_used] = gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if tx.paymaster:</span></span> <span class="giallo-l"><span> postop_result = call(tx.paymaster, [], tx.paymaster_post_op_gas, ROLE_PAYMASTER_POST_OP)</span></span> <span class="giallo-l"><span> gas_used += postop_result.gas_used</span></span> <span class="giallo-l"><span> if postop_result.accepted_role != ROLE_PAYMASTER_POST_OP:</span></span> <span class="giallo-l"><span> state.revert_snapshot(checkpoint)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> balances[payer] += gas_price * (max_gas - gas_used)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>A full list of rationales for the decisions made in this proposal can be found in the <a href="https://wg-eips.ritovision.com/7701/assets/README/">README document</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h2 id="security-considerations">Security Considerations</h2> <p>As the <code>ACCEPT_ROLE</code> opcode represent a generic way to authorize any action on behalf of the contract, correct and secure implementation of this code is critical. We expect that compilers targeting EVM will play a major role in enabling and ensuring Smart Contract Accounts' security.</p> <p>For smart contract security auditors and security-oriented developer tools it is crucial to ensure that contracts not meant to have roles in AA transactions do not have unexpected <code>ACCEPT_ROLE</code> opcode. Otherwise, these contracts may present an immediate security threat.</p> <p>As an example, block explorers should tag contracts as "user accounts" or "paymasters" if they have the <code>ACCEPT_ROLE</code> opcode used in their source code.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Piotr Dobaczewskihttps://github.com/pdobacz Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/7698/

Deploy EOF contracts using creation transactions

<h2 id="abstract">Abstract</h2> <p>Creation transactions (i.e. the ones with empty <code>to</code>) can be used to deploy EOF contracts by providing EOF initcontainer concatenated with <code>calldata</code> for initcontainer execution in transaction's <code>data</code>. Initcontainer execution is similar to its execution during <code>EOFCREATE</code> instruction, ending with <code>RETURNCODE</code> instruction. New account address calculation is based on sender's address and nonce.</p> <h2 id="motivation">Motivation</h2> <p>Creation transaction is one of the three ways alongside creation instructions provided by legacy EVM to deploy new code. Given that legacy creation instructions (<code>CREATE</code> and <code>CREATE2</code>) are not allowed to deploy EOF code, supporting EOF in creation transactions is the only way to get the first EOF on-chain.</p> <p>The mechanism for providing constructor arguments to initcontainer is exactly the same as for deploying legacy code (just concatenating them with initcontainer), therefore existing deployment tooling can be used as is to deploy EOF.</p> <h2 id="specification">Specification</h2> <p>Wherever not explicitly listed, the rules of EOF contract creation should be identical or analogous to those of legacy creation transaction. This includes but is not limited to:</p> <ul> <li>behavior on <code>accessed_addresses</code> and address collision (<a href="https://wg-eips.ritovision.com/684/">EIP-684</a> and <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>)</li> <li>EVM execution frame created for the initcode - memory, account context etc.</li> <li>nonce bumping of the account of newly created contract <a href="https://wg-eips.ritovision.com/161/">EIP-161</a></li> <li>balance checking and transfer for the creation endowment</li> </ul> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>EOF_MAGIC</code></td><td>Defined as <code>0xEF00</code> in <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a></td></tr> <tr><td><code>MAX_CODE_SIZE</code></td><td>Defined as <code>24576</code> in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a></td></tr> </tbody></table> <p>In case a creation transaction (transaction with empty <code>to</code>) has <code>data</code> starting with <code>EOF_MAGIC</code>, <code>data</code> is interpreted as a concatenation of EOF <code>initcontainer</code> and <code>calldata</code>. More specifically:</p> <ol> <li>Intrinsic gas cost rules and limits defined in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> for creation transactions apply. The entire <code>data</code> of the transaction is used for these calculations.</li> <li>Find the split of <code>data</code> into <code>initcontainer</code> and <code>calldata</code>: <ul> <li>Parse EOF header</li> <li>Find <code>intcontainer</code> size by reading all section sizes from the header and adding them up with the header size to get the full container size.</li> </ul> </li> <li>Validate the <code>initcontainer</code> and all its subcontainers recursively. <ul> <li>Unlike in general validation, <code>initcontainer</code> is additionally required to have <code>data_size</code> declared in the header equal to actual <code>data_section</code> size.</li> <li>Validation includes checking that the <code>initcontainer</code> does not contain <code>RETURN</code> or <code>STOP</code></li> </ul> </li> <li>If EOF header parsing or full container validation fails, transaction is considered valid and failing. Gas for initcode execution is not consumed, only intrinsic creation transaction costs are charged.</li> <li><code>calldata</code> part of transaction <code>data</code> that follows <code>initcontainer</code> is treated as calldata to pass into the execution frame.</li> <li>Execute the container and deduct gas for execution. <ol> <li>Calculate <code>new_address</code> as <code>keccak256(sender || sender_nonce)[12:]</code></li> <li>A successful execution ends with initcode executing <code>RETURNCODE{deploy_container_index}(aux_data_offset, aux_data_size)</code> instruction. After that: <ul> <li>load deploy-contract from EOF subcontainer at <code>deploy_container_index</code> in the container from which <code>RETURNCODE</code> is executed,</li> <li>concatenate data section with <code>(aux_data_offset, aux_data_offset + aux_data_size)</code> memory segment and update data size in the header,</li> <li>let <code>deployed_code_size</code> be updated deploy container size,</li> <li>if <code>deployed_code_size &gt; MAX_CODE_SIZE</code> instruction exceptionally aborts,</li> <li>set <code>state[new_address].code</code> to the updated deploy container (rules of <a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>, prohibiting deployment of <code>code</code> starting with <code>EF</code> from creation transactions, do not apply in this case).</li> </ul> </li> </ol> </li> <li>Deduct <code>200 * deployed_code_size</code> gas.</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="irregular-state-change-to-deploy-creator-contract">Irregular state change to deploy Creator Contract</h3> <p>Originally it was proposed to deploy the first EOF contract via irregular state change. This contract would execute <code>TXCREATE</code> instruction and could be used then as an entry point to deploy any other EOF code. This would also require an introduction of <code>InitcodeTransaction</code>, required by <code>TXCREATE</code>. It was decided against this variant for the benefit of reduced scope of changes.</p> <h3 id="constructor-arguments-outside-of-initcontainer-vs-in-data-section">Constructor arguments outside of initcontainer vs in data section</h3> <p>Alternative mechanism for providing constructor arguments to initcontainer execution was considered, where they are concatenated with data section of the initcontainer and are accessed via <code>DATA*</code> instructions instead of <code>CALLDATA*</code>. This has a benefit of not requiring the step finding the split of <code>transaction.data</code> into <code>initcontainer</code> and <code>calldata</code>, as entire <code>transaction.data</code> is an EOF container. However it was rejected for the following reasons:</p> <ul> <li>Existing tooling could not be used for deploying EOF without modification. To construct EOF creation transaction, the tooling would need to append constructor arguments to the container, as well as update data section size in the EOF header. Compiler could predict the size of constructor arguments to put the anticipated data size in the header, but it would not be possible for variadic length constructor arguments.</li> <li>In case a specialized EOF creation transaction is introduced in a later upgrade (such as the <code>InitcodeTransaction</code>), it would have a dedicated field for initcontainer execution input (<code>calldata</code>), and it will be accessed with <code>CALLDATA*</code> instructions in initcode. It is better to avoid the situation where compilers would need to generate initcontainer code differently depending on which context it will be used in.</li> <li>As a general argument, data section can be seen to contain the data that execution considers validated and being closely coupled with the code definition, whereas calldata is an input from the outside that may be arbitrary and not validated.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Creation transactions deploying legacy code are not affected, because any such transaction starting with <code>EF</code> byte previously would fail on executing invalid instruction.</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Parithosh Jayanthihttps://github.com/parithosh Toni Wahrstätterhttps://github.com/nerolation Sam Calder-Masonhttps://github.com/samcm Andrew Davishttps://github.com/savid Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/7691/

Increase the number of blobs to reach a new target and max of 6 and 9 blobs per block respectively

<h2 id="abstract">Abstract</h2> <p>Increases the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum, with its rollup centric roadmap, scales by relying on L2. Since the Dencun fork, the blob gas target and maximum was set to 3/6 respectively. The blob gas limit was arrived at based on a series of big block tests performed on the Ethereum mainnet network as well as a series of testnets. The values were chosen cautiously, as it's extremely hard to predict the exact p2p behaviour of Ethereum mainnet.</p> <p>As we now have the Dencun upgrade live, we are able to use monitoring tools to check the network health. Initial monitoring indicates that we have a stable network with the current gas target and the re-org rate is trending downwards. Additionally, analysis on messages in gossipsub indicate that the inclusion of <code>IDONTWANT</code> messages could bring us a significant bandwidth savings. This allows us to consider starting a series of big block and blob tests to determine the theoretical headroom we currently have. The EIP specifies a proposed new blob gas target and limit based on the series of tests.</p> <p>This EIP aims to increase the throughput short term to provide some scaling until future solutions are deployed. In order to alleviate valid concerns about solo-stakers, approaches such as the inclusion of a flag indicating the max blobs per block for locally built blocks could be considered.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAX_BLOBS_PER_BLOCK_ELECTRA</code></td><td><code>9</code></td></tr> <tr><td><code>TARGET_BLOBS_PER_BLOCK_ELECTRA</code></td><td><code>6</code></td></tr> <tr><td><code>MAX_BLOB_GAS_PER_BLOCK</code></td><td><code>1179648</code></td></tr> <tr><td><code>TARGET_BLOB_GAS_PER_BLOCK</code></td><td><code>786432</code></td></tr> <tr><td><code>BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code></td><td><code>5007716</code></td></tr> </tbody></table> <p><code>MAX_BLOBS_PER_BLOCK_ELECTRA</code> and <code>TARGET_BLOBS_PER_BLOCK_ELECTRA</code> are consumed by the consensus layer clients, and starting at <code>PECTRA_FORK_EPOCH</code> replace the respective old max and target values.</p> <p><code>MAX_BLOB_GAS_PER_BLOCK</code>, <code>TARGET_BLOB_GAS_PER_BLOCK</code> and <code>BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> are consumed by the execution layer clients, and starting at the epoch when this EIP is activated, replace the old max, target and update fraction values. Any references to <code>MAX_BLOB_GAS_PER_BLOCK</code> and <code>TARGET_BLOB_GAS_PER_BLOCK</code> in <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> should be updated to the new values defined in this EIP when processing the activation block. The value <code>BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> replaces its previous equivalent when processing the activation block. These changes imply that <code>get_base_fee_per_blob_gas</code> and <code>calc_excess_blob_gas</code> functions defined in <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> use the new values for the first block of the fork (and for all subsequent blocks).</p> <h2 id="rationale">Rationale</h2> <h3 id="simplicity">Simplicity</h3> <p>The EIP aims to minimize the amount of testing and implementation effort from the perspective of the client teams, to allow for more resources to be allocated to peerDAS and other scaling research.</p> <p>While this EIP may not achieve the new optimal blob limit, it offers a compromise for a short term increase.</p> <h3 id="update-fraction">Update Fraction</h3> <p>The original target and max values from <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> were at a 1:2 ratio. As a consequence, responsiveness to full and empty blob sections was symmetrical:</p> <ul> <li>full blobs: basefee increases by ~12.5%</li> <li>no blobs: basefee decreases by ~11.1%</li> </ul> <p>The new target and max values from this EIP are at a 2:3 ratio, which breaks that symmetry. As a consequence, the basefee becomes significantly more responsive to empty blob sections (that are 6 blobs under target) than to full ones (that are 3 blobs over target). This is by design, as it takes two blocks with full blobs in a row to make up for a single block with no blobs. However, it creates the challenge of finding a good compromise base fee sensitivity level.</p> <p>The <code>BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> value in this EIP is chosen as the mid-point between keeping the responsiveness to full blobs and no blobs constant:</p> <ul> <li>full blobs: basefee increases by ~8.2%</li> <li>no blobs: basefee decreases by ~14.5%</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The consensus clients would continue to use <code>MAX_BLOBS_PER_BLOCK</code> and <code>TARGET_BLOBS_PER_BLOCK</code> for the deneb fork and once the <code>ELECTRA</code> fork is active, they would use <code>MAX_BLOBS_PER_BLOCK_ELECTRA</code> and <code>TARGET_BLOBS_PER_BLOCK_ELECTRA</code> respectively.</p> <p>The execution clients would continue to use <code>MAX_BLOB_GAS_PER_BLOCK</code>, <code>TARGET_BLOB_GAS_PER_BLOCK</code> and <code>BLOB_BASE_FEE_UPDATE_FRACTION</code> for the cancun fork and once the prague fork is active, they would use <code>MAX_BLOB_GAS_PER_BLOCK</code>, <code>TARGET_BLOB_GAS_PER_BLOCK</code> and <code>BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> respectively.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="network-impacts">Network Impacts</h3> <p>Through the use of big block/blob tests on Ethereum mainnet as well as testnets, we can earn a high degree of certainty that the blob limit increase would not negatively impact the network. These tests as well as the associated analysis can be performed mostly by non-client team entities, with minimal input required. Since the changes are quite contained, the EIP should be able to reduce the risk of the blob limit increase.</p> <h3 id="stability-around-fork-epoch">Stability Around Fork Epoch</h3> <p>A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7686/

Adjust memory limits and gas limits of sub-calls to create a clear linear bound on how much total memory an EVM execution can consume

<h2 id="abstract">Abstract</h2> <p>Add a hard memory limit equal to the gas limit of the current context. Make the maximum gas cost of a sub-call depend on the memory used in the current context. The two rules together ensure that a transaction with N gas can use at most N bytes of memory.</p> <h2 id="motivation">Motivation</h2> <p>Today, memory pricing rules are complicated: we have the quadratic cost for expanding memory as well as the 63/64 rule for how much gas can go into a child call. This also makes it extremely hard to calculate a maximum possible amount of memory required to process a given EVM execution.</p> <p>The rules in this post simplify these rules, and add a new hard limit: an EVM execution with N gas can require at most N total bytes of memory to process. This limit is tight: there are easy ways for an N-gas call to use <code>N - O(1)</code> bytes of memory.</p> <h2 id="specification">Specification</h2> <p>Change <code>memory_cost</code> from:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>memory_size_word</span><span class="z-keyword"> =</span><span> (</span><span>memory_byte_size</span><span class="z-keyword"> +</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> /</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span>memory_cost</span><span class="z-keyword"> =</span><span> (</span><span>memory_size_word</span><span class="z-keyword"> **</span><span class="z-constant"> 2</span><span>)</span><span class="z-keyword"> /</span><span class="z-constant"> 512</span><span class="z-keyword"> +</span><span> (</span><span class="z-constant">3</span><span class="z-keyword"> *</span><span> memory_size_word</span><span>)</span></span></code></pre> <p>To:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>memory_size_word</span><span class="z-keyword"> =</span><span> (</span><span>memory_byte_size</span><span class="z-keyword"> +</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> /</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span>memory_cost</span><span class="z-keyword"> =</span><span class="z-constant"> 3</span><span class="z-keyword"> *</span><span> memory_size_word</span></span></code></pre> <p>Additionally, if a memory expansion would lead to <code>memory_byte_size</code> strictly exceeding the current call's initial gas limit, revert with an error.</p> <p>When making any type of call, change the maximum gas limit from the current <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> definition:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> max_call_gas</span><span>(</span><span class="z-variable z-parameter z-function">gas</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> gas</span><span class="z-keyword"> -</span><span> (</span><span>gas</span><span class="z-keyword"> //</span><span class="z-constant"> 64</span><span>)</span></span></code></pre> <p>To:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> max_call_gas</span><span>(</span><span class="z-variable z-parameter z-function">gas</span><span>,</span><span class="z-variable z-parameter z-function"> memory_byte_size</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> gas</span><span class="z-keyword"> -</span><span class="z-support"> max</span><span>(</span><span>gas</span><span class="z-keyword"> //</span><span class="z-constant"> 64</span><span>,</span><span> memory_byte_size</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>With this EIP, there is a simple EVM implementation that can process an N-gas call using an N-byte bytearray as memory: allocate all bytes to the current context, when doing a child call use the remaining memory starting from the position <code>memory_byte_size</code> for the child call's memory, and so on recursively.</p> <p>Having this clean invariant is useful for EVM implementations, especially EVM implementations in constrained environments (eg. ZK-SNARK provers).</p> <p>The 3 gas per word memory expansion cost is retained because it is equivalent to MCOPY, and so the operation of clearing memory at the end of a child call (cheap in regular machines, but more expensive in ZK-SNARKs and other unusual contexts) can be implemented with the same logic as that used to implement the MCOPY opcode itself.</p> <p>The 63/64 rule is maintained in order to maintain the current de-facto call stack depth limit of roughly <code>1 + log((gaslimit + 6300) / 6400) / log(64/63) = 537</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>It is theoretically possible for EVM code that works today to fail to work under this new EIP, if that code accesses a high index in memory but is called with a low gas limit. However, almost all EVM execution consumes far more code than it uses bytes of memory. For example, for a call to cause even a single state change, it must have at least 5000 gas. This would allow it 5000 bytes of memory, which is greater than that used by almost all applications. More complex applications would have even higher limits.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security concerns were raised.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Caymanhttps://github.com/wemeetagain https://wg-eips.ritovision.com/7688/

Transition consensus SSZ data structures to ProgressiveContainer

<h2 id="abstract">Abstract</h2> <p>This EIP defines the changes needed to adopt <code>ProgressiveContainer</code> from <a href="https://wg-eips.ritovision.com/7495/">EIP-7495</a> and <code>ProgressiveList</code> from <a href="https://wg-eips.ritovision.com/7916/">EIP-7916</a> in consensus data structures.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum's consensus data structures make heavy use of <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md">Simple Serialize (SSZ)</a> <code>Container</code>, which defines how they are serialized and merkleized. The merkleization scheme allows application implementations to verify that individual fields (and partial fields) have not been tampered with. This is useful, for example, in smart contracts of decentralized staking pools that wish to verify that participating validators have not been slashed.</p> <p>While SSZ <code>Container</code> defines how data structures are merkleized, the merkleization is prone to change across the different forks. When that happens, e.g., because new features are added or old features get removed, existing verifier implementations need to be updated to be able to continue processing proofs.</p> <p><code>ProgressiveContainer</code>, of <a href="https://wg-eips.ritovision.com/7495/">EIP-7495</a>, is a forward compatible alternative that guarantees a forward compatible merkleization scheme. By transitioning consensus data structures to use <code>ProgressiveContainer</code>, smart contracts that contain verifier logic no longer have to be maintained in lockstep with Ethereum's fork schedule as long as the underlying features that they verify don't change. For example, as long as the concept of slashing is represented using the boolean <code>slashed</code> field, existing verifiers will not break when unrelated features get added or removed. This is also true for off-chain verifiers, e.g., in hardware wallets or in operating systems for mobile devices that are on a different software update cadence than Ethereum.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="container-conversion"><code>Container</code> conversion</h3> <p><code>Container</code> types that are expected to evolve over forks SHALL be redefined as <code>ProgressiveContainer(active_fields=[1] * len(type.fields()))</code>.</p> <p>For example, given a type in the old fork:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Foo</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> a</span><span>:</span><span> uint8</span></span> <span class="giallo-l"><span> b</span><span>:</span><span> uint16</span></span></code></pre> <p>This type can be converted to support stable Merkleization in the new fork:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Foo</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> a</span><span>:</span><span> uint8</span></span> <span class="giallo-l"><span> b</span><span>:</span><span> uint16</span></span></code></pre> <p>As part of the conversion, a stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> is assigned to each field that remains valid in future forks.</p> <ul> <li>If a fork appends a field, <code>active_fields</code> MUST be extended with a trailing <code>1</code>.</li> <li>If a fork removes a field, the corresponding <code>active_fields</code> bit MUST be changed to <code>0</code>.</li> <li>Compatibility rules SHOULD be enforced, e.g., by defining a <code>CompatibleUnion[fork_1.Foo, fork_2.Foo, fork_3.Foo, ...]</code> type in the unit test framework.</li> </ul> <h3 id="list-type-n-bitlist-conversion"><code>List[type, N]</code> / <code>Bitlist</code> conversion</h3> <p><code>List</code> types frequently have been defined with excessively large capacities <code>N</code> with the intention that <code>N</code> is never reached in practice. In other cases, the capacity itself has changed over time.</p> <ul> <li><code>List</code> types with dynamic or unbounded capacity semantics SHALL be redefined as <code>ProgressiveList[type]</code>, and the application logic SHALL be updated to check for an appropriate limit at runtime.</li> <li><code>Bitlist</code> types with dynamic or unbounded capacity semantics SHALL be redefined as <code>ProgressiveBitlist</code></li> </ul> <p>As part of the conversion, a stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> is assigned to each list element that remains valid regardless of the number of added elements.</p> <h3 id="converted-types">Converted types</h3> <p>The following types SHALL be converted to <code>ProgressiveContainer</code>:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#attestation"><code>Attestation</code></a> <ul> <li>The <code>aggregation_bits</code> field is redefined to use <code>ProgressiveBitlist</code></li> </ul> </li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#indexedattestation"><code>IndexedAttestation</code></a> <ul> <li>The <code>attesting_indices</code> field is redefined to use <code>ProgressiveList</code></li> </ul> </li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/beacon-chain.md#executionpayload"><code>ExecutionPayload</code></a> <ul> <li>The <code>transactions</code> and <code>withdrawals</code> fields are redefined to use <code>ProgressiveList</code></li> <li>The <code>MAX_TRANSACTIONS_PER_PAYLOAD</code> (1M) limit is no longer enforced (the limit is unreachable with <code>MAX_PAYLOAD_SIZE</code> 10 MB)</li> </ul> </li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#executionrequests"><code>ExecutionRequests</code></a> <ul> <li>The <code>deposits</code>, <code>withdrawals</code> and <code>consolidations</code> fields are redefined to use <code>ProgressiveList</code></li> </ul> </li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#beaconblockbody"><code>BeaconBlockBody</code></a> <ul> <li>The <code>proposer_slashings</code>, <code>attester_slashings</code>, <code>attestations</code>, <code>deposits</code>, <code>voluntary_exits</code> and <code>bls_to_execution_changes</code> fields are redefined to use <code>ProgressiveList</code></li> </ul> </li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#beaconstate"><code>BeaconState</code></a> <ul> <li>The <code>validators</code>, <code>balances</code>, <code>previous_epoch_participation</code>, <code>current_epoch_participation</code>, <code>inactivity_scores</code>, <code>pending_deposits</code>, <code>pending_partial_withdrawals</code> and <code>pending_consolidations</code> fields are redefined to use <code>ProgressiveList</code></li> </ul> </li> <li>The <code>blob_kzg_commitments</code>, <code>kzg_proofs</code> and <code>column</code> fields are redefined to use <code>ProgressiveList</code></li> </ul> <h3 id="immutable-types">Immutable types</h3> <p>These types are used as part of the <code>ProgressiveContainer</code> definitions, and, as they are not <code>ProgressiveContainer</code> themselves, are considered to have immutable Merkleization. If a future fork requires changing these types in an incompatible way, a new type SHALL be defined and assigned a new field name.</p> <table><thead><tr><th>Type</th><th>Description</th></tr></thead><tbody> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Slot</code></a></td><td>Slot number on the beacon chain</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Epoch</code></a></td><td>Epoch number on the beacon chain, a group of slots</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>CommitteeIndex</code></a></td><td>Index of a committee within a slot</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>ValidatorIndex</code></a></td><td>Unique index of a beacon chain validator</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Gwei</code></a></td><td>Amount in Gwei (1 ETH = 10^9 Gwei = 10^18 Wei)</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Root</code></a></td><td>Byte vector containing an SSZ Merkle root</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Hash32</code></a></td><td>Byte vector containing an opaque 32-byte hash</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Version</code></a></td><td>Consensus fork version number</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>BLSPubkey</code></a></td><td>Cryptographic type representing a BLS12-381 public key</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>BLSSignature</code></a></td><td>Cryptographic type representing a BLS12-381 signature</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/_features/sharding/polynomial-commitments.md#custom-types"><code>KZGCommitment</code></a></td><td>G1 curve point for the KZG polynomial commitment scheme</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#fork"><code>Fork</code></a></td><td>Consensus fork information</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#checkpoint"><code>Checkpoint</code></a></td><td>Tuple referring to the most recent beacon block up through an epoch's start slot</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#validator"><code>Validator</code></a></td><td>Information about a beacon chain validator</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#attestationdata"><code>AttestationData</code></a></td><td>Vote that attests to the availability and validity of a particular consensus block</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#eth1data"><code>Eth1Data</code></a></td><td>Target tracker for importing deposits from transaction logs</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#depositdata"><code>DepositData</code></a></td><td>Log data emitted as part of a transaction's receipt when depositing to the beacon chain</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#beaconblockheader"><code>BeaconBlockHeader</code></a></td><td>Consensus block header</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#proposerslashing"><code>ProposerSlashing</code></a></td><td>Tuple of two equivocating consensus block headers</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#deposit"><code>Deposit</code></a></td><td>Tuple of deposit data and its inclusion proof</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#voluntaryexit"><code>VoluntaryExit</code></a></td><td>Consensus originated request to exit a validator from the beacon chain</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#signedvoluntaryexit"><code>SignedVoluntaryExit</code></a></td><td>Tuple of voluntary exit request and its signature</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/altair/beacon-chain.md#syncaggregate"><code>SyncAggregate</code></a></td><td>Cryptographic type representing an aggregate sync committee signature</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#custom-types"><code>ExecutionAddress</code></a></td><td>Byte vector containing an account address on the execution layer</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#custom-types"><code>Transaction</code></a></td><td>Byte list containing an RLP encoded transaction</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#custom-types"><code>WithdrawalIndex</code></a></td><td>Unique index of a withdrawal from any validator's balance to the execution layer</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#withdrawal"><code>Withdrawal</code></a></td><td>Withdrawal from a beacon chain validator's balance to the execution layer</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#depositrequest"><code>DepositRequest</code></a></td><td>Tuple of flattened deposit data and its sequential index</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#withdrawalrequest"><code>WithdrawalRequest</code></a></td><td>Execution originated request to withdraw from a validator to the execution layer</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#consolidation"><code>ConsolidationRequest</code></a></td><td>Execution originated request to consolidate two beacon chain validators</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#blstoexecutionchange"><code>BLSToExecutionChange</code></a></td><td>Request to register the withdrawal account address of a beacon chain validator</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#signedblstoexecutionchange"><code>SignedBLSToExecutionChange</code></a></td><td>Tuple of withdrawal account address registration request and its signature</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/altair/beacon-chain.md#custom-types"><code>ParticipationFlags</code></a></td><td>Participation tracker of a beacon chain validator within an epoch</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#historicalsummary"><code>HistoricalSummary</code></a></td><td>Tuple combining a historical block root and historical state root</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#pendingdeposit"><code>PendingDeposit</code></a></td><td>Pending operation for depositing to a beacon chain validator</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#pendingpartialwithdrawal"><code>PendingPartialWithdrawal</code></a></td><td>Pending operation for withdrawing from a beacon chain validator</td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#pendingconsolidation"><code>PendingConsolidation</code></a></td><td>Pending operation for consolidating two beacon chain validators</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <h3 id="best-timing">Best timing?</h3> <p>Applying this EIP breaks <code>hash_tree_root</code> and Merkle tree verifiers a single time, while promising forward compatibility from the fork going forward. It is best to apply it before merkleization would be broken by different changes. Merkleization is broken by a <code>Container</code> reaching a new power of 2 in its number of fields.</p> <h3 id="can-this-be-applied-retroactively">Can this be applied retroactively?</h3> <p>While <code>ProgressiveContainer</code> serializes in the same way as the legacy <code>Container</code>, the merkleization and <code>hash_tree_root</code> of affected data structures changes. Therefore, verifiers that wish to process Merkle proofs of legacy variants still need to support the corresponding legacy schemes.</p> <h3 id="immutability">Immutability</h3> <p>Once a field in a <code>ProgressiveContainer</code> has been published, its name can no longer be used to represent a different type in the future. This is in line with historical management of certain cases:</p> <ul> <li>Phase0: <code>BeaconState</code> contained <code>previous_epoch_attestations</code> / <code>current_epoch_attestations</code></li> <li>Altair: <code>BeaconState</code> replaced these fields with <code>previous_epoch_participation</code> / <code>current_epoch_participation</code></li> </ul> <p>Furthermore, new fields have to be appended at the end of <code>ProgressiveContainer</code>. This is in line with historical management of other cases:</p> <ul> <li>Capella appended <code>historical_summaries</code> to <code>BeaconState</code> instead of squeezing the new field next to <code>historical_roots</code></li> </ul> <p>With <code>ProgressiveContainer</code>, stable Merkleization requires these rules to become strict.</p> <h3 id="cleanup-opportunities">Cleanup opportunities</h3> <h4 id="beaconstate"><code>BeaconState</code></h4> <ul> <li>The <code>eth1_data</code>, <code>eth1_data_votes</code>, <code>eth1_deposit_index</code> and <code>deposit_requests_start_index</code> fields could be dropped as they are no longer needed after the <a href="https://wg-eips.ritovision.com/6110/#eth1data-poll-deprecation">EIP-6110</a> transition period finishes.</li> <li><code>historical_summaries</code> could be redefined to use <code>ProgressiveList</code> and also integrate the historical <code>historical_roots</code> data by merging in full <code>HistoricalSummary</code> data from an archive (<code>historical_root</code> is frozen since Capella), simplifying access to historical block and state roots.</li> </ul> <h4 id="attestation"><code>Attestation</code></h4> <ul> <li>The <code>committee_bits</code> is defined as a <code>Bitvector</code>, but the top bits are forced to 0 based on <code>get_committee_count_per_slot(state, data.target.epoch)</code>. It could be re-defined as a <code>ProgressiveBitlist</code>.</li> </ul> <h4 id="indexedattestation"><code>IndexedAttestation</code></h4> <p>The <code>attesting_indices</code> are limited to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#indexedattestation"><code>MAX_VALIDATORS_PER_COMMITTEE * MAX_COMMITTEES_PER_SLOT</code></a>, which is insufficient when the <code>IndexedAttestation</code> is formed from <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#singleattestation"><code>SingleAttestation</code></a> traffic. <code>SingleAttestation</code> allows validators that are not assigned to a slot to produce signatures that are not aggregatable into an <code>Attestation</code> (as such validators are not assigned), but that are still slashable.</p> <p>Further, <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/electra/beacon-chain.md#max-operations-per-block"><code>MAX_ATTESTER_SLASHINGS_ELECTRA</code></a> at 1 limits inclusion efficiency of slashings in non-finality scenarios with a lot of forks where slashings happen across multiple different <code>AttestationData</code> values.</p> <p>Limits could be rethought to be based on actual resource usage, e.g., by limiting:</p> <ul> <li>The total number of <code>attesting_indices</code> across all <code>AttesterSlashing</code> (shared total)</li> <li>The total number of signature checks across all <code>AttesterSlashing</code>, <code>ProposerSlashing</code>, <code>VoluntaryExit</code>, and <code>SignedBLSToExecutionChange</code> messages</li> </ul> <p>Limiting totals rather than individual resources would allow extra attester slashings to be included at the cost of potentially delaying inclusion of a couple altruistic messages (if there even are any <code>VoluntaryExit</code> / <code>SignedBLSToExecutionChange</code> messages at that time), thus increasing security and block packing efficiency.</p> <h4 id="executionpayload"><code>ExecutionPayload</code></h4> <p>The <code>block_hash</code> field could be moved to the top of <code>ExecutionPayload</code>, reducing the Merkle proof size.</p> <h4 id="executionrequests"><code>ExecutionRequests</code></h4> <p>As deposits cannot be retried by the user (they pay the ETH upfront), deposit requests cannot fizzle like other requests; they are always included in the same block (since Pectra). For that reason, the current <code>MAX_DEPOSIT_REQUESTS_PER_PAYLOAD</code> (8192) is essentially unbounded at current gas limits, but may eventually become reachable (around ~192M gas, or earlier with gas repricings). The CL limit for deposit requests could be dropped to avoid scaling issues, instead solely relying on EL backpressure (gas fees, 1 ETH deposit minimum).</p> <p>For other requests (withdrawal / consolidation requests), a shared total limit based on the added CL state size could provide more flexibility than the current per-operation limits. For example, in times without consolidation requests, space could be used to enqueue more withdrawal requests.</p> <h4 id="beaconblockheader"><code>BeaconBlockHeader</code></h4> <p>The <code>BeaconBlockHeader</code> is currently proposed to be kept as is. Updating the <code>BeaconBlockHeader</code> to <code>ProgressiveContainer</code> is tricky as it breaks <code>hash_tree_root(latest_block_header)</code> in the <code>BeaconState</code>. One option could be to store <code>latest_block_header_root</code> separately, possibly also incorporating the block proposer signature into the hash to avoid proposer signature checks while backfilling historical blocks.</p> <h4 id="validator"><code>Validator</code></h4> <p>The <code>Validator</code> container is currently proposed to be kept as is. Updating the <code>Validator</code> to <code>ProgressiveContainer</code> would add an extra hash for each validator; validators are mostly immutable so rarely need to be re-hashed. With a conversion, implementations may have to incrementally construct the new <code>Validator</code> entries ahead of the fork when validator counts are high. It should be evaluated whether the hashing overhead is worth a clean transition to future fields, e.g., for holding postquantum keys. Also consider that such a transition may also involve a new hash function, which is a breaking change to the Merkle proofs, so generalized indices do not have to be stable across that transition.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Existing Merkle proof verifiers need to be updated to support the new Merkle tree shape. This includes verifiers in smart contracts on different blockchains and verifiers in hardware wallets, if applicable.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Before this EIP, all <code>List</code> types had a fixed upper bound, enabling implementations to reject messages exceeding that size early. With <code>ProgressiveList</code>, that is no longer possible, as there is no more maximum message size. Instead, the length checks have to be implemented as part of P2P gossip validation, and as part of the state transition logic. However, many of the limits are not practically reachable (e.g., the gas limit is reached before the maximum payload size). Further note that SSZ is simple enough that clever implementations could still enforce those length checks on the serialized data, before fully decoding it.</p> <p>All data inbound via libp2p is decrypted, then uncompressed with Snappy, then hashed with <code>MESSAGE_DOMAIN_VALID_SNAPPY</code> / <code>MESSAGE_DOMAIN_INVALID_SNAPPY</code> prefix depending on whether the decompression worked to compute the libp2p message ID, while honoring a global <code>MAX_PAYLOAD_SIZE</code> message size limit. This has to be done even if the underlying SSZ data ends up being invalid.</p> <p>As SSZ does not use variable-length encoding, it does not have uncontrolled blowup (no 1 byte becomes 100 MB). Therefore, attempting to decode a <code>MAX_PAYLOAD_SIZE</code> message before checking dynamic <code>List</code> limits does not decrease security. Any intentional DoS attacks can already target a heavier portion of the processing pipeline (e.g., by sending invalid BLS signatures, or by sending invalid Snappy data that still needs to be hashed to compute the message ID). Therefore, the EIP does not notably impact security.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 lightclienthttps://github.com/lightclient Felix Langehttps://github.com/fjl https://wg-eips.ritovision.com/7685/

A general purpose bus for sharing EL triggered requests with the CL

<h2 id="abstract">Abstract</h2> <p>This proposal defines a general purpose framework for storing contract-triggered requests. It extends the execution header with a single field to store the request information. Requests are later on exposed to the consensus layer, which then processes each one.</p> <h2 id="motivation">Motivation</h2> <p>The proliferation of smart contract controlled validators has caused there to be a demand for additional EL triggered behaviors. By allowing these systems to delegate administrative operations to their governing smart contracts, they can avoid intermediaries needing to step in and ensure certain operations occur. This creates a safer system for end users. By abstracting each individual request details from the EL, adding new request types is simpler and does not require an update on the execution block structure.</p> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution Layer</h3> <h4 id="requests">Requests</h4> <p>A <code>requests</code> object consists of a <code>request_type</code> byte prepended to an opaque byte array <code>request_data</code>. The <code>request_data</code> contains zero or more encoded request objects.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>requests = request_type ++ request_data</span></span></code></pre> <p>Each request type will define its own <code>requests</code> object with its own <code>request_data</code> format.</p> <h4 id="block-header">Block Header</h4> <p>Extend the header with a new 32 byte commitment value <code>requests_hash</code>.</p> <p>While processing a block, multiple <code>requests</code> objects with different <code>request_type</code>s will be produced by the system, and accumulated in the block requests list.</p> <p>In order to compute the commitment, an intermediate hash list is first built by hashing all non-empty requests elements of the block requests list. Items with empty <code>request_data</code> are excluded, i.e. the intermediate list skips <code>requests</code> items which contain only the <code>request_type</code> (1 byte) and nothing else.</p> <p>Within the intermediate list, <code>requests</code> items must be ordered by <code>request_type</code> ascending.</p> <p>The final commitment is computed as the sha256 hash of the intermediate element hashes.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_requests_hash</span><span>(</span><span class="z-variable z-parameter z-function">block_requests</span><span>:</span><span> Sequence</span><span>[</span><span class="z-support">bytes</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> m</span><span class="z-keyword"> =</span><span> sha256</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> r</span><span class="z-keyword"> in</span><span> block_requests</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>r</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span> m</span><span>.</span><span>update</span><span>(</span><span>sha256</span><span>(</span><span>r</span><span>)</span><span>.</span><span>digest</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> m</span><span>.</span><span>digest</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>block</span><span>.</span><span>header</span><span>.</span><span>requests_hash</span><span class="z-keyword"> =</span><span> compute_requests_hash</span><span>(</span><span>requests</span><span>)</span></span></code></pre><h3 id="consensus-layer">Consensus Layer</h3> <p>Each proposal may choose how to extend the beacon chain types to include new EL request types.</p> <h2 id="rationale">Rationale</h2> <h3 id="opaque-byte-array-rather-than-an-rlp-array">Opaque byte array rather than an RLP array</h3> <p>By having the bytes of <code>request_data</code> array from second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the request payload in the future such as SSZ, LEB128, or a fixed width format.</p> <h3 id="request-source-and-validity">Request source and validity</h3> <p>This EIP makes no strict requirement where a request may come from nor when/how a request must be validated. This is to provide future protocol designers maximum flexibility.</p> <p>The authors' recommendations on source and validity of requests are:</p> <ul> <li>The source of requests should be from the execution of transactions. More specifically, transactions which make calls to designated system contracts that store the request in account. The storage would later be retrieved by a post-block system call to the contract. Alternatively, if the system call does not need to be inherently concerned with rate limiting, it could rely simply on emitting an event which is later parsed post-block by the system and converted into a request.</li> <li>A request's validity can often not be fully verified at the execution layer. This is why they are referred to merely as "requests"; they do not carry the authority on their own to unilaterally catalyze an action. We expect the system contracts to perform whatever validation is possible by the EL and then pass it on to the CL for further validation.</li> </ul> <h3 id="ordering">Ordering</h3> <p>The ordering across types is ascending by type. This is to simplify the process of verifying that all requests which were committed to in <code>requests_hash</code> match.</p> <p>An alternative could be to order by when the request was generated within the block. Since it's expected that many requests will be accumulated at the end of the block via system calls, this would be difficult to enforce. Therefore, ordering by type is the most straightforward ordering which ensures integrity.</p> <h4 id="intra-type">Intra-type</h4> <p>Within the same type, order is not defined. This is because the data of the request is opaque as far as this EIP is concerned. Therefore, it is to be determined by each request type individually.</p> <h3 id="removing-empty-requests-in-commitment">Removing empty requests in commitment</h3> <p>We exclude empty requests elements from the <code>requests_hash</code> commitment in order to get a stable 'empty' hash value that is independent of the blockchain fork. For a block with no requests data, the <code>requests_hash</code> is simply <code>sha256("")</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lionhttps://github.com/dapplion https://wg-eips.ritovision.com/7684/

Automatically withdraw deposits for existing validator records but with distinct execution withdrawal credentials

<h2 id="abstract">Abstract</h2> <p>Automatically withdraw deposits for existing validator records, but where the deposit includes a distinct execution withdrawal credential.</p> <h2 id="motivation">Motivation</h2> <p>Some staking operations feature two distinct entities, one operating the validating key, and one funding the deposit. The funding entity delegates control of the stake operation but must retain ultimate control of funds. If the funding entity naively submits a single deposit with the full stake amount and the other entity's validating key, it is subject to a front-run attack. The validating entity can front-run the bigger deposit with a second deposit with its own set of withdrawal credentials. The full stake amount deposit becomes a top-up, in control of the validating entity.</p> <p>There exist workarounds to the front-run attack. Using some distributed key generation protocol between the funding and validating entity, such that a deposit must be made with the consent of both entities. Submit a 1 ETH deposit first wait for its inclusion then send the full stake amount as a top-up, to bind the maximum loss under the attack to 1 ETH. While these workarounds, work; they difficult the operation of trustless autonomous staking protocols.</p> <p>This specification reduces the total loss on a naive deposit submission from the full deposit amount to <code>RETURN_DEPOSIT_PENALTY</code>.</p> <h2 id="specification">Specification</h2> <h3 id="consensus-layer">Consensus Layer</h3> <p>The configuration values and mechanics of the specification can be found in the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/2360756c8c19c0f7b0e91135f5bbcddecdf0a835/specs/_features/eip9999/beacon_chain.md">Consensus Layer specs</a>.</p> <p>A sketch of the resulting changes to the consensus layer is included below.</p> <ul> <li>Modify <code>apply_deposit</code> to queue for withdrawal deposits with distinct execution withdrawal credentials</li> <li>Modify <code>get_expected_withdrawals</code> to return pending withdrawals first</li> <li>Modify <code>process_withdrawals</code> to clear the pending withdrawals queue</li> </ul> <h3 id="execution-layer">Execution Layer</h3> <p>This specification does not require any changes to the Execution Layer.</p> <h2 id="rationale">Rationale</h2> <h3 id="persist-pending-withdrawals">Persist pending withdrawals</h3> <p>Rejected deposits from block at slot N can not be withdrawn in block N due to a cyclic dependency. An execution client must know the full list of withdrawals before constructing a payload for slot N. After <a href="https://wg-eips.ritovision.com/6110/">EIP-6110</a>, a consensus client must know the full execution payload for slot N before constructing the beacon block for slot N. Therefore, rejected deposits must be withdrawn in some future slot. All pending withdrawals are processed at once in the very next slot for simplicity but could be queued and processed progressively if there are DOS concerns.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backward incompatible change to the Consensus Layer of Ethereum and must be scheduled with a hard fork.</p> <p>There are no forwards / backwards compatibility issues with the Execution Layer</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases are work-in-progress within the standard Consensus Layer tests.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The worst-case number of withdrawals is raised from a fixed 16 to 1,271 under current gas rules and a 30M gas block. Citing <a href="https://wg-eips.ritovision.com/6110/">EIP-6110</a>, future gas efficiencies can increase the number to 1,916 withdrawals in a 30M gas block. Each withdrawal results in a single address balance change. There is no explicit pricing for such an operation, but under the worst case, it results in a notable increase in the total block gas (30% assuming 6,900 gas per withdrawal and current gas rules).</p> <p><code>RETURN_DEPOSIT_PENALTY</code> disincentivizes rejected deposits, and imposes a gas cost of 144,927 Gwei / gas, assuming 6,900 gas per withdrawal.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-04-03T00:00:00+00:00 2026-02-11T14:49:28+00:00 Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7676/

Update EOF opcodes so addresses are not trimmed during execution

<h2 id="abstract">Abstract</h2> <p>Operations in the Legacy EVM trim off the top 12 bytes of an address operand before evaluation. This EIP changes the handling of those opcodes within EOF so that no trimming occurs and the top twelve bytes need to be zero or an exceptional halt is raised.</p> <h2 id="motivation">Motivation</h2> <p>There have been proposals to extend Ethereum Addresses from 160 bits to 256, such as one that would use the extra bits for state expiry (such as the ethereum magicians forum topic "Increasing the address size from 20 to 32 bytes"). One issue ground the work to a halt: EVM opcodes that accept addresses trim all but the lowest 20 bytes out from the operand before processing. EVM Reference tests verify this behavior in the 'stBadOpcode/invalidAddr.json' tests.</p> <p>The EVM Object Format presents an opportunity to remove this address masking in a backwards compatible way, by baking it into the format definition from the start.</p> <p>Most of the work is already in place. The following 5 operations have already been banned from EOF: <code>EXTCODESIZE</code>, <code>EXTCODECOPY</code>, <code>EXTCODEHASH</code>, <code>CALLCODE</code>, and <code>SELFDESTRUCT</code>. Three call operations, <code>CALL</code>, <code>DELEGATECALL</code>, and <code>STATICCALL</code> are being revamped in <a href="https://wg-eips.ritovision.com/7069/">EIP-7069</a>. That leaves only one operation, <code>BALANCE</code>, with issues.</p> <p>When future uses of address space extension are specified it is expected that the exceptional halt behavior will be modified.</p> <h2 id="specification">Specification</h2> <p>We introduce one new instruction:</p> <ul> <li><code>EXTBALANCE</code> (<code>tbd</code>) with arguments <code>(target_address)</code>, returning <code>balance</code></li> </ul> <p><code>EXTBALANCE</code> will pop one stack item off of the stack, the address of another account or contract. The balance of that account or contract will be pushed onto the stack.</p> <p>If <code>EXTBALANCE</code> is invoked with any of the high 12 bytes in <code>target_address</code> set to a non-zero value the operation will cause an exceptional halt. All gas in the current frame will be consumed on failure, no gas schedule change is needed.</p> <p>The gas cost of <code>EXTBALANCE</code> will be costed according to the gas schedule for the <code>BALANCE</code> operation specified in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>. This means if the account is not in <code>accessed_addresses</code> then it is charged 2600 gas and added to <code>accessed_addresses</code>. If the account is in <code>accessed_addresses</code> then 100 gas is charged. The <code>accessed_addresses</code> is shared with all other operands described in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</p> <p>Also, for the <code>EXTCALL</code>, <code>EXTDELEGATECALL</code>, and <code>EXTSTATICCALL</code> operations a new step is added just before the memory expansion check: halt with exceptional failure if any of the high 96 bits of the <code>target_address</code> are set.</p> <p>It is anticipated that future EIPs will alter the behavior in a way that will not result in an exceptional halt. Contract implementors should not depend on the exceptional halt.</p> <h2 id="rationale">Rationale</h2> <h3 id="new-opcode">New Opcode</h3> <p>There is no need to ban the <code>BALANCE</code> opcode as it does not cause any problems that would require banning it within an EOF container. Adding a new opcode also allows the existing opcode to behave the same in EOF and legacy code, reducing potential friction points for end user confusion and bugs.</p> <h3 id="revert-on-invalid-address">Revert on invalid address</h3> <p>There are two alternative ways to handle accounts with high bits set. The specification calls for an exceptional halt, but the alternative was to treat the account as empty. The reason the "empty account" approach was rejected is twofold:</p> <ul> <li>The <code>accessed_addresses</code> list could be required to track 256 bit accounts when an invalid address is accessed.</li> <li>The <code>EXTCALL</code> series instructions could still send balance to those addresses and such accounts would then hold an (inaccessible) balance that would need to be reflected in the merkle trie.</li> </ul> <h3 id="no-change-in-gas-costing">No change in gas costing</h3> <p>Because the BALANCE operation already needs to check <code>accessed_addresses</code> there is already a good amount of processing that must go into the operation. Hence, no changes to the gas schedule are needed to prevent abuse of the failures. Such incremental costs will be dominated by costs related to reverts and address checking for valid accounts.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Preparing for Address Space Expansion is explicitly done inside the scope of EOF with the intent that it will not require changes in old contracts, but with the caveat that old contracts may not be able to use addresses in the expanded space.</p> <p>Future EIPs should be mindful when adding new operation with an address operand or parameter to how it interacts with EOF and legacy contracts. Authors should ensure that such additions remain in harmony with this EIP.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases similar to <code>invalidAddr.json</code> tests in the standard reference tests will need to be written for the EOF tests, except they would check for halts on invalid addresses.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TBD <!-- TODO --></p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP only defines a revert behavior for previously stripped addresses. Compilers will need to be aware of the need to mask addresses coming in from call data. Some of this is already present in existing Solidity ABI standards, but more care should be taken in examining the flow around <code>EXTBALANCE</code> and code for <code>EXTCALL</code> operations to ensure that compiled code strips the high bytes.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7666/

Remove the identity precompile, and put into place a piece of EVM code that has equivalent functionality

<h2 id="abstract">Abstract</h2> <p>Remove the identity precompile at 0x04. At the start of executing the block in which this change activates, put into that contract a short piece of EVM code that has the same functionality.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum today has a large number of precompiles. Nearly half of these precompiles are not seeing significant use, and are contributing to ongoing maintenance cost and risk of consensus bugs, as well as increased development effort for new Ethereum client implementations, including ZK-EVMs and implementations in formal-verification-friendly languages.</p> <p>This EIP proposes a path for the Ethereum ecosystem to gracefully abandon these precompiles, and takes a first step by applying this procedure to the simplest precompile of all: the identity precompile (which outputs returndata equal to the input calldata). The identity precompile was originally introduced because memory copying is a common operation, and there was no opcode available to do it directly. Since then, norms around what is acceptable for an opcode have changed, and we have introduced the MCOPY opcode with <a href="https://wg-eips.ritovision.com/5656/">EIP-5656</a>. And so we can remove the identity precompile, and replace it with an ultra-minimal piece of EVM code that replicates its functionality.</p> <p>In the future, this technique can be applied to other more complex precompiles, such as little-used hash functions and MODEXP.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>IDENTITY_PRECOMPILE_ADDRESS</code></td><td><code>0x0000....0004</code></td></tr> <tr><td><code>EVM_CODE</code></td><td><code>0x365f5f37365ff3</code></td></tr> </tbody></table> <p>At the start of the block in which this fork activates, set the code of <code>IDENTITY_PRECOMPILE_ADDRESS</code> to <code>EVM_CODE</code>. Starting from and including that block, <code>IDENTITY_PRECOMPILE_ADDRESS</code> should no longer be treated as a precompile.</p> <h2 id="rationale">Rationale</h2> <p>The given <code>EVM_CODE</code> corresponds to</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>CALLDATASIZE PUSH0 PUSH0 CALLDATACOPY CALLDATASIZE PUSH0 RETURN</span></span></code></pre> <p>Which copies calldata into memory, and then returns the same memory slice. This is thus a minimally disruptive change to Ethereum that preserves functionality, and accomplishes the goal of reducing the number of precompiles by 1.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The functionality of the given <code>EVM_CODE</code> is the same as the identity precompile. Gas costs are slightly different, though gas repricings have been done in the Ethereum ecosystem several times before and their effects are well understood.</p> <h2 id="security-considerations">Security Considerations</h2> <p>As no new functionality is introduced or made cheaper, no security concerns are raised.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7667/

Raise the gas costs of hash function opcodes and precompiles, to match prover expenses in ZK-EVMs

<h2 id="abstract">Abstract</h2> <p>Raise the gas costs of opcodes and precompiles that involve hash functions.</p> <h2 id="motivation">Motivation</h2> <p>Gas costs for hash function opcodes and precompiles were originally set based on the time that it takes to execute them on a regular CPU. Since then, however, there has emerged another equally important execution substrate that the EVM is executed on: zero knowledge proof (ZK-SNARK) systems. By that standard, these opcodes and precompiles are <em>very</em> underpriced relative to other operations.</p> <p>Blocks that are heavy with hash function executions take much longer to ZK-SNARK prove than average blocks. Today, many layer-2 protocols are using workarounds such as arbitrary limits and rules enforced by centralized sequencers to deal with this issue. These workarounds are often poorly designed and lead to unneeded security and centralization concerns.</p> <p>Additionally, there is a design goal of eventually using ZK-SNARKs to prove the correctness of layer-1 Ethereum blocks. To do this, we need to establish very tight bounds on how long it takes to generate a ZK-SNARK proof of an Ethereum execution block's correctness. Today, the difference between average-case proving time and worst-case proving time is large, and hash function executions are the largest reason why.</p> <p>Verkle trees solve the part of this problem that comes from Keccak hashing in the Merkle Patricia tree. Today, the theoretical worst case is a block with <code>30000000 / 2600 = 11538</code> account accesses (minus a small percent for EVM overhead), where proving each access would require proving <code>24000</code> bytes of code, plus a roughly <code>512 * log(500m) / log(16) = 3712</code> byte Merkle-Patricia proof: roughly <code>305 MB</code> of hashing spread between <code>83650</code> hash calls. Verkle trees solve this. However, using opcodes, a block execution can still require roughly the following amount of hashing:</p> <table><thead><tr><th>Hash</th><th>Cost per word</th><th>Maximum bytes from 30 million gas</th></tr></thead><tbody> <tr><td><code>KECCAK</code> (opcode)</td><td>6</td><td>160 million</td></tr> <tr><td><code>SHA256</code> (precompile)</td><td>12</td><td>80 million</td></tr> <tr><td><code>RIPEMD</code> (precompile)</td><td>120</td><td>8 million</td></tr> <tr><td><code>BLAKE2</code> (precompile)</td><td>3 (12 per 128 bytes)</td><td>320 million</td></tr> <tr><td><code>LOG*</code> (hashing data)</td><td>256 (8 per byte)</td><td>3.75 million</td></tr> </tbody></table> <p>These hash functions have been optimized for rapid CPU computation, so CPUs can compute them quickly: for example, this author's laptop can compute a 160-million byte keccak in less than half a second. In ZK-SNARKs, however, these operations are <em>very</em> time-consuming and inefficient. This is mitigated in newer proof systems based on small fields, but hashes remain underpriced.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Previous value</th><th>New value</th></tr></thead><tbody> <tr><td><code>KECCAK_BASE_COST</code></td><td>30</td><td>300</td></tr> <tr><td><code>KECCAK_WORD_COST</code></td><td>6</td><td>60</td></tr> <tr><td><code>SHA256_BASE_COST</code></td><td>60</td><td>300</td></tr> <tr><td><code>SHA256_WORD_COST</code></td><td>12</td><td>60</td></tr> <tr><td><code>RIPEMD_BASE_COST</code></td><td>600</td><td>600</td></tr> <tr><td><code>RIPEMD_WORD_COST</code></td><td>120</td><td>120</td></tr> <tr><td><code>BLAKE2_GFROUND</code></td><td>1</td><td>10</td></tr> <tr><td><code>GLOGBYTE</code></td><td>8</td><td>10</td></tr> </tbody></table> <p>Change the above parameters to their new values.</p> <h2 id="rationale">Rationale</h2> <p>The above increases the gas costs of all opcodes and precompiles that can be used to require large amounts of hashing in the EVM. All hashing costs are increased to 300 per hash plus 60 per word (or kept the same if they are already higher than this). '" A possible alternative to this approach is to implement either multidimensional gas pricing (ie. a separate floating basefee and per-block target and limit for hashes) or a "total gas cost floor" similar to what <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> does for calldata. However, this approach is much harder to implement for in-EVM gas costs such as hashes than it is for calldata and blobs, because EVM gas limits are set not just by users, for whom new transaction types that specify newly required limits, max-basefees and priority fees can easily be added, but also by contracts making sub-calls to other contracts.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>For most applications, a reasonable upper bound is that data that is getting hashed in the EVM is getting brought in as calldata. If the hashing being done is binary Merkle proof verification, every 32 bytes of data corresponds to a 64-byte (2-word) hash. A word of costs 512 gas. Under the new costs, the hashing per word in that situation would be <code>300 + 60 * 2 = 420</code> gas. Hence, this will increase gas consumption for that component of the application by less than 2x.</p> <p>Concretely, a length-20 Keccak-based binary Merkle proof gas cost would increase from <code>(512 + 42) * 20 = 11080</code> to <code>(512 + 420) * 20 = 18640</code>. This is a small increase, especially taking into account other costs associated with such an application.</p> <h2 id="security-considerations">Security Considerations</h2> <p>As no new operations are introduced or made cheaper, no security concerns were raised.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7668/

Remove bloom filters from the execution block

<h2 id="abstract">Abstract</h2> <p>Require the bloom filters in an execution block, including at the top level and in the receipt object, to be empty.</p> <h2 id="motivation">Motivation</h2> <p>Logs were originally introduced to give applications a way to record information about onchain events, which decentralized applications (dapps) would be able to easily query. Using bloom filters, dapps would be able to quickly go through the history, identify the few blocks that contained logs relative to their application, and then quickly identify which individual transactions have the logs that they need.</p> <p>In practice, this mechanism is far too slow. Almost all dapps that access history end up doing so not through RPC calls to an Ethereum node (even a remote-hosted one), but through centralized extra-protocol services.</p> <p>This EIP proposes recognizing that reality, and removing bloom filters from the protocol. Applications that need history querying would be encouraged to develop and use decentralized protocols that create provable log indexes using eg. ZK-SNARKs and incrementally-verifiable computation.</p> <h2 id="specification">Specification</h2> <p>The logs bloom of an execution block is now required to be empty (ie. 0 bytes long). The logs bloom of a transaction receipt is now required to be empty (ie. 0 bytes long).</p> <h2 id="rationale">Rationale</h2> <p>This is a minimally disruptive way to remove the need to handle blooms from clients. A future EIP can later clean up by removing this field entirely, along with other fields that have been deprecated.</p> <p>Gas costs of LOG are not reduced, because while the externality of polluting the bloom filter no longer needs to be accounted for, the costs of hashing have increased due to the needs of ZK-SNARK EVM implementations.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Applications that depend on bloom filters to read events will cease to work. Very few applications depend on this feature today, because at current gas limits the false positive rate is so high and processing the logs in a long history query is so slow, especially for light clients (whom this feature was primarily intended to benefit).</p> <h2 id="security-considerations">Security Considerations</h2> <p>As no new features are introduced or made cheaper, no security concerns are raised.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-27T00:00:00+00:00 2026-02-11T14:49:27+00:00 Diederik Loerakkerhttps://github.com/protolambda https://wg-eips.ritovision.com/7664/

The access-key opcode enables contracts to read inputs that are statically declared in access-lists.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new opcode to inspect the access-list keys of the executing address.</p> <h2 id="motivation">Motivation</h2> <p>This EIP serves as a substitute of top-level-call detection to enable a smart-contract to enforce static declaration of attributes.</p> <p>Previously, application-layer contracts, against common advice from account-abstraction proponents, used to rely on the <code>tx.origin</code> to enforce a top-level call, such that the contract inputs are encoded as transaction input.</p> <p>While the access-list of transactions directly affects the execution, it only affects the gas-costs. This EIP enhances the access-list feature to provide the property of statically-defined contract-inputs, without relying on top-level calls, the <code>tx.origin</code> behavior, or gas introspection.</p> <p>This enables smart contracts to reliably enforce static declaration of inputs.</p> <p>This is a step towards fulfilling the purposes as described in the Motivation of <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>:</p> <blockquote> <p>Introduces the access list format and the logic for handling the format. This logic can later be repurposed for many other purposes, including block-wide witnesses, use in ReGenesis, moving toward static state access over time, and more."</p> </blockquote> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>ACCESS_KEY_OPCODE_GAS</code></td><td><code>3</code></td></tr> <tr><td><code>ACCESS_KEY_OPCODE_BYTE</code></td><td><code>0x4B</code></td></tr> </tbody></table> <h3 id="opcode">Opcode</h3> <p>We add an instruction <code>ACCESS_KEY</code> (with opcode <code>ACCESS_KEY_OPCODE_BYTE</code>) which pops <code>index</code> from the top of the stack as big-endian <code>uint256</code>, and pushes <code>tx.access_list[address][index]</code> back on the stack, if <code>address</code> is present in the <code>tx.access_list</code> and <code>index &lt; len(tx.access_list[address])</code>, and otherwise pushes a zeroed <code>bytes32</code> value.</p> <h3 id="gas-costs">Gas costs</h3> <p>The opcode has a fixed gas cost of <code>ACCESS_KEY_OPCODE_GAS</code>.</p> <p>The intrinsic gas costs of the access-list contents of the transaction itself do not change.</p> <h2 id="rationale">Rationale</h2> <h3 id="static-analysis-of-transactions">Static analysis of transactions</h3> <p>Static declaration of contract-inputs enables advanced layer-two constructions and block-building techniques: data is available without EVM introspection, and contracts can reliably tell if the executing transaction declared critical properties to the block builder and verifying nodes.</p> <p>Static-declaration of contract inputs is now independent of account-abstraction related changes, such as transaction bundlers, as well as in-protocol with 3074.</p> <!-- EIP link/requires omitted due to Walidator EIP status bug --> <h3 id="global-read-only-values">Global read-only values</h3> <p>Akin to <code>TLOAD</code>, as described in <a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a>, the <code>ACCESS_KEY</code> opcode provides contracts with a view that is global to the message-execution of the transaction in the EVM.</p> <p>However, with <code>ACCESS_KEY</code> it is guaranteed to be read-only, and cannot change during the execution of a transaction.</p> <h3 id="access-list-utility">Access-list utility</h3> <p>Access-lists are under-utilized today: very few users utilize this to warm-up storage interactions for reduced gas costs. Generally the gas cost savings achieved with EIP-2930 are not applicable in as many use-cases.</p> <p>With this EIP, the utility of the access-list functionality increases, without requiring additional resources from the EVM.</p> <h3 id="witness-data">Witness data</h3> <p>This EIP supports the transformation of applications to reduce statefulness, by supporting read-only application state to be provided to contracts without requiring the contract caller to support forwarding of data.</p> <p>The access-list contents may contain witness-data, which the contract can verify and utilize statelessness.</p> <h3 id="gas-costs-1">Gas costs</h3> <p>The gas cost of <code>ACCESS_KEY_OPCODE_GAS</code> gas matches that of similar operations, specifically the <code>BLOBHASH</code> opcode of <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>: this opcode also pop an index-like EVM word from the stack, and pushes a full 32 byte EVM word back on the stack, based on a list of hashes embedded in the transaction.</p> <p>The <code>BLOBHASH</code> functionality of <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> is not re-usable for the purposes of this EIP however, as the intention is to have access to just the statically declared hash, and not the cost of a blob.</p> <h3 id="naming-of-access-key">Naming of <code>ACCESS_KEY</code></h3> <p>Access-lists currently only support a list of access-keys. The list is not enforced to be sorted, and thus supports indexed lookups.</p> <p>This is not a <code>LOAD</code> opcode, as <code>SLOAD</code> or <code>TLOAD</code> are, since the opcode returns a key.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h3 id="no-transaction-type-changes">No transaction-type changes</h3> <p>This enhancement of access-lists utility does not affect the access-list encoding, or the existing transaction types that support access-lists.</p> <h3 id="minimal-impact-on-evm-transaction-context">Minimal impact on EVM transaction-context</h3> <p>With EIP-2930, the access-list contents are already readily available in the transaction-context during EVM execution, and the RPC methods that trigger said execution.</p> <p>This EIP thus does not require significant changes to the construction of the EVM context, nor any changes to RPC methods.</p> <h2 id="test-cases">Test Cases</h2> <p>The block fee-recipient, and any other warmed-up attributes not declared statically in the transaction access-list, must not be considered to be part of the access-list.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The access-list attributes are already gas-metered in EIP-2930, and readily accessible in the EVM to determine storage gas-costs. In terms of denial-of-service risks, this EIP introduces no new significant data or data-processing costs.</p> <p>The access-list is read-only, and thus forms a minimal risk to application-developers.</p> <p>The access is scoped strictly to the contract that would otherwise perform a warm <code>SLOAD</code>, and thus storage-layout abstractions do not leak between different smart contract applications.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status https://wg-eips.ritovision.com/7657/

Slashing condition for malicious sync committee messages

<h2 id="abstract">Abstract</h2> <p>This EIP defines a slashing condition for malicious <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/altair/validator.md#containers">sync committee messages</a>.</p> <h2 id="motivation">Motivation</h2> <p>A dishonest supermajority of sync committee members is able to convince applications relying on Ethereum's <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/altair/light-client/sync-protocol.md">light client sync protocol</a> to assume a non-canonical finalized header, and to potentially take over the sync authority for future <code>SyncCommitteePeriod</code>. By signing a malicious beacon block root, a malicious (but valid!) <code>LightClientUpdate</code> message can be formed and subsequently used to, for example, exploit a trust-minimized bridge contract based on the light client sync protocol.</p> <p>An additional type of slashing is introduced to deter against signing non-canonical beacon block roots as a sync committee member. As is the case with <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#proposerslashing"><code>ProposerSlashing</code></a> and <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#attesterslashing"><code>AttesterSlashing</code></a>, only malicious behaviour is slashable. This includes simultaneous contradictory participation across multiple chain branches, but a validator that is simply tricked into syncing to an incorrect checkpoint should not be slashable even though it is participating on a non-canonical chain. Note that a slashing must be verifiable even without access to history, e.g., by a checkpoint synced beacon node.</p> <p>Note that regardless of the slashing mechanism, a slashing can only be applied retroactively after an attack has already occurred. Use cases that secure a larger amount than <code>SYNC_COMMITTEE_SIZE * MAX_EFFECTIVE_BALANCE</code> = <code>512 * 32 ETH</code> = <code>16384 ETH</code> (on mainnet) should combine the light client sync protocol with other established methods such as a multisig, or may want to require posting additional collateral to be eligible for submitting updates. Other methods are out of scope for this EIP.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="state-transition-checks">State transition checks</h3> <p>Note: This still allows having contradictions between attestations/proposals and sync committee messages. This also, by design, allows a validator to not participate at all in honest sync committee messages but solely participate in dishonest sync committee messages.</p> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>BLOCK_STATE_ROOT_INDEX</code></td><td><code>get_generalized_index(BeaconBlock, 'state_root')</code> (= 11)</td></tr> <tr><td><code>STATE_BLOCK_ROOTS_INDEX</code></td><td><code>get_generalized_index(BeaconState, 'block_roots')</code> (= 37)</td></tr> <tr><td><code>STATE_HISTORICAL_ROOTS_INDEX</code></td><td><code>get_generalized_index(BeaconState, 'historical_roots')</code> (= 39)</td></tr> <tr><td><code>HISTORICAL_BATCH_BLOCK_ROOTS_INDEX</code></td><td><code>get_generalized_index(HistoricalBatch, 'block_roots')</code> (= 2)</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SyncCommitteeSlashingEvidence</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> attested_header</span><span>:</span><span> BeaconBlockHeader</span></span> <span class="giallo-l"><span> next_sync_committee</span><span>:</span><span> SyncCommittee</span></span> <span class="giallo-l"><span> next_sync_committee_branch</span><span>:</span><span> Vector</span><span>[</span><span>Root</span><span>,</span><span> floorlog2</span><span>(</span><span class="z-constant">NEXT_SYNC_COMMITTEE_INDEX</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> finalized_header</span><span>:</span><span> BeaconBlockHeader</span></span> <span class="giallo-l"><span> finality_branch</span><span>:</span><span> Vector</span><span>[</span><span>Root</span><span>,</span><span> floorlog2</span><span>(</span><span class="z-constant">FINALIZED_ROOT_INDEX</span><span>)</span><span>]</span></span> <span class="giallo-l"><span> sync_aggregate</span><span>:</span><span> SyncAggregate</span></span> <span class="giallo-l"><span> signature_slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"><span> sync_committee_pubkeys</span><span>:</span><span> Vector</span><span>[</span><span>BLSPubkey</span><span>,</span><span class="z-constant"> SYNC_COMMITTEE_SIZE</span><span>]</span></span> <span class="giallo-l"><span> actual_finalized_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> actual_finalized_branch</span><span>:</span><span> List</span><span>[</span><span>Root</span><span>,</span><span> (</span></span> <span class="giallo-l"><span> floorlog2</span><span>(</span><span class="z-constant">BLOCK_STATE_ROOT_INDEX</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> floorlog2</span><span>(</span><span class="z-constant">STATE_HISTORICAL_ROOTS_INDEX</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span class="z-keyword"> +</span><span> floorlog2</span><span>(</span><span class="z-constant">HISTORICAL_ROOTS_LIMIT</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> floorlog2</span><span>(</span><span class="z-constant">HISTORICAL_BATCH_BLOCK_ROOTS_INDEX</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span class="z-keyword"> +</span><span> floorlog2</span><span>(</span><span class="z-constant">SLOTS_PER_HISTORICAL_ROOT</span><span>)</span><span>)</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SyncCommitteeSlashing</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> slashable_validators</span><span>:</span><span> List</span><span>[</span><span>ValidatorIndex</span><span>,</span><span class="z-constant"> SYNC_COMMITTEE_SIZE</span><span>]</span></span> <span class="giallo-l"><span> evidence_1</span><span>:</span><span> SyncCommitteeSlashingEvidence</span></span> <span class="giallo-l"><span> evidence_2</span><span>:</span><span> SyncCommitteeSlashingEvidence</span></span> <span class="giallo-l"><span> recent_finalized_block_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> recent_finalized_slot</span><span>:</span><span> Slot</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> sync_committee_slashing_evidence_has_sync_committee</span><span>(</span><span class="z-variable z-parameter z-function">evidence</span><span>:</span><span> SyncCommitteeSlashingEvidence</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> evidence</span><span>.</span><span>next_sync_committee_branch</span><span class="z-keyword"> !=</span><span> [</span><span>Root</span><span>(</span><span>)</span><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>floorlog2</span><span>(</span><span class="z-constant">NEXT_SYNC_COMMITTEE_INDEX</span><span>)</span><span>)</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> sync_committee_slashing_evidence_has_finality</span><span>(</span><span class="z-variable z-parameter z-function">evidence</span><span>:</span><span> SyncCommitteeSlashingEvidence</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> evidence</span><span>.</span><span>finality_branch</span><span class="z-keyword"> !=</span><span> [</span><span>Root</span><span>(</span><span>)</span><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>floorlog2</span><span>(</span><span class="z-constant">FINALIZED_ROOT_INDEX</span><span>)</span><span>)</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> is_valid_sync_committee_slashing_evidence</span><span>(</span><span class="z-variable z-parameter z-function">evidence</span><span>:</span><span> SyncCommitteeSlashingEvidence</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> recent_finalized_block_root</span><span>:</span><span> Root</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> recent_finalized_slot</span><span>:</span><span> Slot</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> genesis_validators_root</span><span>:</span><span> Root</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sync committee has sufficient participants</span></span> <span class="giallo-l"><span> sync_aggregate</span><span class="z-keyword"> =</span><span> evidence</span><span>.</span><span>sync_aggregate</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> sum</span><span>(</span><span>sync_aggregate</span><span>.</span><span>sync_committee_bits</span><span>)</span><span class="z-keyword"> &lt;</span><span class="z-constant"> MIN_SYNC_COMMITTEE_PARTICIPANTS</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that the `finality_branch`, if present, confirms `finalized_header`</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> to match the finalized checkpoint root saved in the state of `attested_header`.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Note that the genesis finalized checkpoint root is represented as a zero hash.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> sync_committee_slashing_evidence_has_finality</span><span>(</span><span>evidence</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> !=</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>finalized_header</span><span class="z-keyword"> !=</span><span> BeaconBlockHeader</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span><span class="z-keyword"> ==</span><span class="z-constant"> GENESIS_SLOT</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> !=</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>finalized_header</span><span class="z-keyword"> !=</span><span> BeaconBlockHeader</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> finalized_root</span><span class="z-keyword"> =</span><span> Root</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> finalized_root</span><span class="z-keyword"> =</span><span> hash_tree_root</span><span>(</span><span>evidence</span><span>.</span><span>finalized_header</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_merkle_branch</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> leaf</span><span class="z-keyword">=</span><span>finalized_root</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> branch</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>finality_branch</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> depth</span><span class="z-keyword">=</span><span>floorlog2</span><span>(</span><span class="z-constant">FINALIZED_ROOT_INDEX</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> index</span><span class="z-keyword">=</span><span>get_subtree_index</span><span>(</span><span class="z-constant">FINALIZED_ROOT_INDEX</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> root</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>attested_header</span><span>.</span><span>state_root</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that the `next_sync_committee`, if present, actually is the next sync committee saved in the</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> state of the `attested_header`</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> sync_committee_slashing_evidence_has_sync_committee</span><span>(</span><span>evidence</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>next_sync_committee</span><span class="z-keyword"> !=</span><span> SyncCommittee</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_merkle_branch</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> leaf</span><span class="z-keyword">=</span><span>hash_tree_root</span><span>(</span><span>evidence</span><span>.</span><span>next_sync_committee</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> branch</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>next_sync_committee_branch</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> depth</span><span class="z-keyword">=</span><span>floorlog2</span><span>(</span><span class="z-constant">NEXT_SYNC_COMMITTEE_INDEX</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> index</span><span class="z-keyword">=</span><span>get_subtree_index</span><span>(</span><span class="z-constant">NEXT_SYNC_COMMITTEE_INDEX</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> root</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>attested_header</span><span>.</span><span>state_root</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify that the `actual_finalized_block_root`, if present, is confirmed by `actual_finalized_branch`</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> to be the block root at slot `finalized_header.slot` relative to `recent_finalized_block_root`</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> !=</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> ==</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>evidence</span><span>.</span><span>actual_finalized_branch</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> finalized_slot</span><span class="z-keyword"> =</span><span> evidence</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> recent_finalized_slot</span><span class="z-keyword"> &lt;</span><span> finalized_slot</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> distance</span><span class="z-keyword"> =</span><span> recent_finalized_slot</span><span class="z-keyword"> -</span><span> finalized_slot</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> distance</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> GeneralizedIndex</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span class="z-constant"> BLOCK_STATE_ROOT_INDEX</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> distance</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span><span>:</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> floorlog2</span><span>(</span><span class="z-constant">STATE_BLOCK_ROOTS_INDEX</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> STATE_BLOCK_ROOTS_INDEX</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> floorlog2</span><span>(</span><span class="z-constant">STATE_HISTORICAL_ROOTS_INDEX</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> STATE_HISTORICAL_ROOTS_INDEX</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> uint64</span><span>(</span><span class="z-constant">1</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 0</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> `mix_in_length`</span></span> <span class="giallo-l"><span> historical_batch_index</span><span class="z-keyword"> =</span><span> finalized_slot</span><span class="z-keyword"> //</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> floorlog2</span><span>(</span><span class="z-constant">HISTORICAL_ROOTS_LIMIT</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span> historical_batch_index</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> floorlog2</span><span>(</span><span class="z-constant">HISTORICAL_BATCH_BLOCK_ROOTS_INDEX</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> HISTORICAL_BATCH_BLOCK_ROOTS_INDEX</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> uint64</span><span>(</span><span class="z-constant">1</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 0</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> `mix_in_length`</span></span> <span class="giallo-l"><span> block_root_index</span><span class="z-keyword"> =</span><span> finalized_slot</span><span class="z-keyword"> %</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span></span> <span class="giallo-l"><span> gindex</span><span class="z-keyword"> =</span><span> (</span><span>gindex</span><span class="z-keyword"> &lt;&lt;</span><span> floorlog2</span><span>(</span><span class="z-constant">SLOTS_PER_HISTORICAL_ROOT</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span> block_root_index</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>evidence</span><span>.</span><span>actual_finalized_branch</span><span>)</span><span class="z-keyword"> !=</span><span> floorlog2</span><span>(</span><span>gindex</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_valid_merkle_branch</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> leaf</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>actual_finalized_block_root</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> branch</span><span class="z-keyword">=</span><span>evidence</span><span>.</span><span>actual_finalized_branch</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> depth</span><span class="z-keyword">=</span><span>floorlog2</span><span>(</span><span>gindex</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> index</span><span class="z-keyword">=</span><span>get_subtree_index</span><span>(</span><span>gindex</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> root</span><span class="z-keyword">=</span><span>recent_finalized_block_root</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sync committee aggregate signature</span></span> <span class="giallo-l"><span> sync_committee_pubkeys</span><span class="z-keyword"> =</span><span> evidence</span><span>.</span><span>sync_committee_pubkeys</span></span> <span class="giallo-l"><span> participant_pubkeys</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> for</span><span> (</span><span>bit</span><span>,</span><span> pubkey</span><span>)</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>sync_aggregate</span><span>.</span><span>sync_committee_bits</span><span>,</span><span> sync_committee_pubkeys</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> fork_version</span><span class="z-keyword"> =</span><span> compute_fork_version</span><span>(</span><span>compute_epoch_at_slot</span><span>(</span><span>evidence</span><span>.</span><span>signature_slot</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> domain</span><span class="z-keyword"> =</span><span> compute_domain</span><span>(</span><span class="z-constant">DOMAIN_SYNC_COMMITTEE</span><span>,</span><span> fork_version</span><span>,</span><span> genesis_validators_root</span><span>)</span></span> <span class="giallo-l"><span> signing_root</span><span class="z-keyword"> =</span><span> compute_signing_root</span><span>(</span><span>evidence</span><span>.</span><span>attested_header</span><span>,</span><span> domain</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> bls</span><span>.</span><span>FastAggregateVerify</span><span>(</span><span>participant_pubkeys</span><span>,</span><span> signing_root</span><span>,</span><span> sync_aggregate</span><span>.</span><span>sync_committee_signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_sync_committee_slashing</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> sync_committee_slashing</span><span>:</span><span> SyncCommitteeSlashing</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> is_slashable</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check that evidence is ordered descending by `attested_header.slot` and is not from the future</span></span> <span class="giallo-l"><span> evidence_1</span><span class="z-keyword"> =</span><span> sync_committee_slashing</span><span>.</span><span>evidence_1</span></span> <span class="giallo-l"><span> evidence_2</span><span class="z-keyword"> =</span><span> sync_committee_slashing</span><span>.</span><span>evidence_2</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_1</span><span>.</span><span>signature_slot</span><span class="z-keyword"> &gt;</span><span> evidence_1</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_1</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_2</span><span>.</span><span>signature_slot</span><span class="z-keyword"> &gt;</span><span> evidence_2</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_2</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> evidence_1</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_2</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Only conflicting data among the current and previous sync committee period is slashable;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> on new periods, the sync committee initially signs blocks in a previous sync committee period.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This allows a validator synced to a malicious checkpoint to contribute again in a future period</span></span> <span class="giallo-l"><span> evidence_1_attested_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>evidence_1</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span> evidence_2_attested_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>evidence_2</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> evidence_1_attested_period</span><span class="z-keyword"> &lt;=</span><span> evidence_2_attested_period</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> It is not allowed to sign conflicting `attested_header` for a given slot</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence_1</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span class="z-keyword"> ==</span><span> evidence_2</span><span>.</span><span>attested_header</span><span>.</span><span>slot</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence_1</span><span>.</span><span>attested_header</span><span class="z-keyword"> !=</span><span> evidence_2</span><span>.</span><span>attested_header</span><span>:</span></span> <span class="giallo-l"><span> is_slashable</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> It is not allowed to sign conflicting finalized `next_sync_committee`</span></span> <span class="giallo-l"><span> evidence_1_finalized_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>evidence_1</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span> evidence_2_finalized_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>evidence_2</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span> evidence_1_attested_period</span><span class="z-keyword"> ==</span><span> evidence_2_attested_period</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> evidence_1_finalized_period</span><span class="z-keyword"> ==</span><span> evidence_1_attested_period</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> evidence_2_finalized_period</span><span class="z-keyword"> ==</span><span> evidence_2_attested_period</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> sync_committee_slashing_evidence_has_finality</span><span>(</span><span>evidence_1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> sync_committee_slashing_evidence_has_finality</span><span>(</span><span>evidence_2</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> sync_committee_slashing_evidence_has_sync_committee</span><span>(</span><span>evidence_1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> sync_committee_slashing_evidence_has_sync_committee</span><span>(</span><span>evidence_2</span><span>)</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> evidence_1</span><span>.</span><span>next_sync_committee</span><span class="z-keyword"> !=</span><span> evidence_2</span><span>.</span><span>next_sync_committee</span><span>:</span></span> <span class="giallo-l"><span> is_slashable</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> It is not allowed to sign a non-linear finalized history</span></span> <span class="giallo-l"><span> recent_finalized_slot</span><span class="z-keyword"> =</span><span> sync_committee_slashing</span><span>.</span><span>recent_finalized_slot</span></span> <span class="giallo-l"><span> recent_finalized_block_root</span><span class="z-keyword"> =</span><span> sync_committee_slashing</span><span>.</span><span>recent_finalized_block_root</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span class="z-keyword"> not</span><span> sync_committee_slashing_evidence_has_finality</span><span>(</span><span>evidence_1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span class="z-keyword"> not</span><span> sync_committee_slashing_evidence_has_finality</span><span>(</span><span>evidence_2</span><span>)</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> Root</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> Root</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> recent_finalized_slot</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Merkle proofs may be included to indicate that `finalized_header` does not match</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> the `actual_finalized_block_root` relative to a given `recent_finalized_block_root`.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The finalized history is linear. Therefore, a mismatch indicates signing on an unrelated chain.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Note that it is not slashable to sign solely an alternate history, as long as it is consistent.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> This allows a validator synced to a malicious checkpoint to contribute again in a future period</span></span> <span class="giallo-l"><span> linear_1</span><span class="z-keyword"> =</span><span> (</span><span>evidence_1</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> ==</span><span> hash_tree_root</span><span>(</span><span>evidence_1</span><span>.</span><span>finalized_header</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> linear_2</span><span class="z-keyword"> =</span><span> (</span><span>evidence_2</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> ==</span><span> hash_tree_root</span><span>(</span><span>evidence_2</span><span>.</span><span>finalized_header</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-keyword"> not</span><span> linear_1</span><span class="z-keyword"> or</span><span class="z-keyword"> not</span><span> linear_2</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> linear_1</span><span class="z-keyword"> or</span><span> linear_2</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Do not slash on signing solely an alternate history</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> `actual_finalized_branch` may be rooted in the provided `finalized_header` with highest slot</span></span> <span class="giallo-l"><span> rooted_in_evidence_1</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> evidence_1</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_2</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_slot</span><span class="z-keyword"> ==</span><span> evidence_1</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> evidence_1</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> and</span><span> linear_1</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> rooted_in_evidence_2</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> evidence_2</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span><span class="z-keyword"> &gt;=</span><span> evidence_1</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_slot</span><span class="z-keyword"> ==</span><span> evidence_2</span><span>.</span><span>finalized_header</span><span>.</span><span>slot</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> evidence_2</span><span>.</span><span>actual_finalized_block_root</span><span class="z-keyword"> and</span><span> linear_2</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Alternatively, if evidence about non-linearity cannot be obtained directly from an attack,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> it can be proven that one of the `finalized_header` is part of the canonical finalized chain</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> that our beacon node is synced to, while the other `finalized_header` is unrelated.</span></span> <span class="giallo-l"><span> rooted_in_canonical</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> recent_finalized_slot</span><span class="z-keyword"> &lt;</span><span> state</span><span>.</span><span>slot</span><span class="z-keyword"> &lt;=</span><span> recent_finalized_slot</span><span class="z-keyword"> +</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_slot</span><span class="z-keyword"> &lt;=</span><span> compute_start_slot_at_epoch</span><span>(</span><span>state</span><span>.</span><span>finalized_checkpoint</span><span>.</span><span>epoch</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> recent_finalized_block_root</span><span class="z-keyword"> ==</span><span> state</span><span>.</span><span>block_roots</span><span>[</span><span>recent_finalized_slot</span><span class="z-keyword"> %</span><span class="z-constant"> SLOTS_PER_HISTORICAL_ROOT</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> rooted_in_evidence_1</span><span class="z-keyword"> or</span><span> rooted_in_evidence_2</span><span class="z-keyword"> or</span><span> rooted_in_canonical</span></span> <span class="giallo-l"><span> is_slashable</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> is_slashable</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check that slashable validators are sorted, known, and participated in both signatures</span></span> <span class="giallo-l"><span> will_slash_any</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> sync_aggregate_1</span><span class="z-keyword"> =</span><span> evidence_1</span><span>.</span><span>sync_aggregate</span></span> <span class="giallo-l"><span> sync_aggregate_2</span><span class="z-keyword"> =</span><span> evidence_2</span><span>.</span><span>sync_aggregate</span></span> <span class="giallo-l"><span> sync_committee_pubkeys_1</span><span class="z-keyword"> =</span><span> evidence_1</span><span>.</span><span>sync_committee_pubkeys</span></span> <span class="giallo-l"><span> sync_committee_pubkeys_2</span><span class="z-keyword"> =</span><span> evidence_2</span><span>.</span><span>sync_committee_pubkeys</span></span> <span class="giallo-l"><span> participant_pubkeys_1</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> for</span><span> (</span><span>bit</span><span>,</span><span> pubkey</span><span>)</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>sync_aggregate_1</span><span>.</span><span>sync_committee_bits</span><span>,</span><span> sync_committee_pubkeys_1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> participant_pubkeys_2</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> for</span><span> (</span><span>bit</span><span>,</span><span> pubkey</span><span>)</span><span class="z-keyword"> in</span><span class="z-support"> zip</span><span>(</span><span>sync_aggregate_2</span><span>.</span><span>sync_committee_bits</span><span>,</span><span> sync_committee_pubkeys_2</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> bit</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> slashable_validators</span><span class="z-keyword"> =</span><span> sync_committee_slashing</span><span>.</span><span>slashable_validators</span></span> <span class="giallo-l"><span> num_validators</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span>,</span><span> index</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>slashable_validators</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> (</span></span> <span class="giallo-l"><span> index</span><span class="z-keyword"> &lt;</span><span> num_validators</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> (</span><span>i</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span class="z-keyword"> or</span><span> index</span><span class="z-keyword"> &gt;</span><span> slashable_validators</span><span>[</span><span>i</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span><span>.</span><span>pubkey</span><span class="z-keyword"> in</span><span> participant_pubkeys_1</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span><span>.</span><span>pubkey</span><span class="z-keyword"> in</span><span> participant_pubkeys_2</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_slashable_validator</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span><span>,</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> will_slash_any</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> will_slash_any</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate evidence, including signatures</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> is_valid_sync_committee_slashing_evidence</span><span>(</span></span> <span class="giallo-l"><span> evidence_1</span><span>,</span></span> <span class="giallo-l"><span> recent_finalized_block_root</span><span>,</span></span> <span class="giallo-l"><span> recent_finalized_slot</span><span>,</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>genesis_validators_root</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> is_valid_sync_committee_slashing_evidence</span><span>(</span></span> <span class="giallo-l"><span> evidence_2</span><span>,</span></span> <span class="giallo-l"><span> recent_finalized_block_root</span><span>,</span></span> <span class="giallo-l"><span> recent_finalized_slot</span><span>,</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>genesis_validators_root</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Perform slashing</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> index</span><span class="z-keyword"> in</span><span> slashable_validators</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_slashable_validator</span><span>(</span><span>state</span><span>.</span><span>validators</span><span>[</span><span>index</span><span>]</span><span>,</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> slash_validator</span><span>(</span><span>state</span><span>,</span><span> index</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="what-s-the-use-case">What's the use case?</h3> <p>Without a slashing, the light client sync protocol is somewhat limited. While wallet applications may benefit from it (the risk being, that incorrect data is displayed) and new beacon nodes may use it for accelerating chain synchronization, other interesting use cases such as bridges, token distributions or other systems requiring proofs depend on the mechanism providing higher security guarantees.</p> <p>By making attacks by sync committee members slashable, a sufficiently high deterrent could be provided. A majority of the sync committee would have to be bribed to succeed in an attack even in the most simple cases, representing a sizable slashable balance.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork as it introduces new consensus validation rules.</p> <p>Supporting infrastructure may be introduced separately once the consensus validation rules are in place, including but not limited to:</p> <ul> <li>Slashing protection DB updates, to guarantee that honest validators cannot be slashed on reorgs</li> <li>Validator client / remote signer APIs, to pass along information related to slashing protection</li> <li>libp2p meshes for exchanging slashing evidence between beacon nodes</li> <li>Slasher, to monitor potential targets and construct slashing evidence</li> <li>Beacon APIs, to submit and monitor slashing evidence</li> </ul> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status https://wg-eips.ritovision.com/7658/

Mechanism for beacon nodes for syncing historical light client data

<h2 id="abstract">Abstract</h2> <p>This EIP defines a mechanism for syncing <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/full-node.md">light client data</a> between beacon nodes.</p> <h2 id="motivation">Motivation</h2> <p><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/full-node.md">Light client data</a> is collected by beacon nodes to assist <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/light-client.md">light clients</a> to sync with the network. The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/sync-protocol.md">sync protocol</a> defines a mechanism to sync forward in time. However, it cannot be used to sync backward.</p> <p>Collecting light client data is challenging because beacon nodes need to have access to the corresponding <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/phase0/beacon-chain.md#beaconstate"><code>BeaconState</code></a> and <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/phase0/beacon-chain.md#signedbeaconblock"><code>SignedBeaconBlock</code></a>. <code>BeaconState</code> objects are not available before the initially synced checkpoint state, and <code>SignedBeaconBlock</code> objects have a limited retention period on libp2p.</p> <p>Furthermore, each <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/beacon-chain.md#get_next_sync_committee">sync committee period</a> consists of <code>EPOCHS_PER_SYNC_COMMITTEE_PERIOD * SLOTS_PER_EPOCH</code> slots. To support archive services such as Portal network to provide a consistent view regardless of backend, it is necessary to choose a single canonical slot for which to derive the representative light client data for that period. Such data should be verifiable to be canonical and optimal in a decentralized and independent manner.</p> <p>To support light client data backfill, this EIP proposes to track the canonical and optimal <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/beacon-chain.md#syncaggregate"><code>SyncAggregate</code></a> in the <code>BeaconState</code>. This minimal addition allows proving that derived <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/sync-protocol.md#lightclientupdate"><code>LightClientUpdate</code></a> and <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/sync-protocol.md#lightclientbootstrap"><code>LightClientBootstrap</code></a> are also canonical and optimal.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="containers">Containers</h3> <h4 id="new-containers">New containers</h4> <h5 id="syncdata"><code>SyncData</code></h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SyncData</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Sync committee aggregate signature</span></span> <span class="giallo-l"><span> sync_aggregate</span><span>:</span><span> SyncAggregate</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Slot at which the aggregate signature was created</span></span> <span class="giallo-l"><span> signature_slot</span><span>:</span><span> Slot</span></span></code></pre><h4 id="extended-containers">Extended containers</h4> <h5 id="beaconstate"><code>BeaconState</code></h5> <p>New fields are added to the end of <code>BeaconState</code> from the activating fork onward to track the current and previous sync committee period's best sync data.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BeaconState</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Sync history</span></span> <span class="giallo-l"><span> previous_best_sync_data</span><span>:</span><span> SyncData</span></span> <span class="giallo-l"><span> current_best_sync_data</span><span>:</span><span> SyncData</span></span> <span class="giallo-l"><span> parent_block_has_sync_committee_finality</span><span>:</span><span class="z-support"> bool</span></span></code></pre><h3 id="helper-functions">Helper functions</h3> <h4 id="default-sync-data"><code>default_sync_data</code></h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> default_sync_data</span><span>(</span><span>)</span><span> -&gt;</span><span> SyncData</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> SyncData</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> sync_aggregate</span><span class="z-keyword">=</span><span>SyncAggregate</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> sync_committee_bits</span><span class="z-keyword">=</span><span>Bitvector</span><span>[</span><span class="z-constant">SYNC_COMMITTEE_SIZE</span><span>]</span><span>(</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> sync_committee_signature</span><span class="z-keyword">=</span><span class="z-constant">G2_POINT_AT_INFINITY</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> signature_slot</span><span class="z-keyword">=</span><span class="z-constant">GENESIS_SLOT</span><span>,</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h3 id="beacon-chain-state-transition-function">Beacon chain state transition function</h3> <h4 id="epoch-processing">Epoch processing</h4> <h5 id="modified-process-sync-committee-updates">Modified <code>process_sync_committee_updates</code></h5> <p>On sync committee boundaries, current period data is moved to previous period. This allows proving that light client data for the previous period is canonical.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_sync_committee_updates</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> next_epoch</span><span class="z-keyword"> =</span><span> get_current_epoch</span><span>(</span><span>state</span><span>)</span><span class="z-keyword"> +</span><span> Epoch</span><span>(</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> next_epoch</span><span class="z-keyword"> %</span><span class="z-constant"> EPOCHS_PER_SYNC_COMMITTEE_PERIOD</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>previous_best_sync_data</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>current_best_sync_data</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>current_best_sync_data</span><span class="z-keyword"> =</span><span> default_sync_data</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>parent_block_has_sync_committee_finality</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span></code></pre><h4 id="block-processing">Block processing</h4> <p>Block processing is extended to track the optimal light client data for the current period. Due to the possibility for empty slots this must be tracked before the block header is overwritten; this allows tracking the exact block after which <code>next_sync_committee</code> becomes finalized.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_block</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> BeaconBlock</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> process_best_sync_data</span><span>(</span><span>state</span><span>,</span><span> block</span><span>)</span></span> <span class="giallo-l"><span> process_block_header</span><span>(</span><span>state</span><span>,</span><span> block</span><span>)</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h5 id="new-process-best-sync-data">New <code>process_best_sync_data</code></h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_best_sync_data</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> BeaconState</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> BeaconBlock</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> signature_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>block</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"><span> attested_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period_at_slot</span><span>(</span><span>state</span><span>.</span><span>latest_block_header</span><span>.</span><span>slot</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track sync committee finality</span></span> <span class="giallo-l"><span> old_has_sync_committee_finality</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>parent_block_has_sync_committee_finality</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> state</span><span>.</span><span>parent_block_has_sync_committee_finality</span><span>:</span></span> <span class="giallo-l"><span> new_has_sync_committee_finality</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> state</span><span>.</span><span>finalized_checkpoint</span><span>.</span><span>epoch</span><span class="z-keyword"> &lt;</span><span class="z-constant"> ALTAIR_FORK_EPOCH</span><span>:</span></span> <span class="giallo-l"><span> new_has_sync_committee_finality</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> finalized_period</span><span class="z-keyword"> =</span><span> compute_sync_committee_period</span><span>(</span><span>state</span><span>.</span><span>finalized_checkpoint</span><span>.</span><span>epoch</span><span>)</span></span> <span class="giallo-l"><span> new_has_sync_committee_finality</span><span class="z-keyword"> =</span><span> (</span><span>finalized_period</span><span class="z-keyword"> ==</span><span> attested_period</span><span>)</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>parent_block_has_sync_committee_finality</span><span class="z-keyword"> =</span><span> new_has_sync_committee_finality</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Track best sync data</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> attested_period</span><span class="z-keyword"> ==</span><span> signature_period</span><span>:</span></span> <span class="giallo-l"><span> max_active_participants</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>block</span><span>.</span><span>body</span><span>.</span><span>sync_aggregate</span><span>.</span><span>sync_committee_bits</span><span>)</span></span> <span class="giallo-l"><span> new_num_active_participants</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>block</span><span>.</span><span>body</span><span>.</span><span>sync_aggregate</span><span>.</span><span>sync_committee_bits</span><span>)</span></span> <span class="giallo-l"><span> old_num_active_participants</span><span class="z-keyword"> =</span><span class="z-support"> sum</span><span>(</span><span>state</span><span>.</span><span>current_best_sync_data</span><span>.</span><span>sync_aggregate</span><span>.</span><span>sync_committee_bits</span><span>)</span></span> <span class="giallo-l"><span> new_has_supermajority</span><span class="z-keyword"> =</span><span> new_num_active_participants</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span><span class="z-keyword"> &gt;=</span><span> max_active_participants</span><span class="z-keyword"> *</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span> old_has_supermajority</span><span class="z-keyword"> =</span><span> old_num_active_participants</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span><span class="z-keyword"> &gt;=</span><span> max_active_participants</span><span class="z-keyword"> *</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> new_has_supermajority</span><span class="z-keyword"> !=</span><span> old_has_supermajority</span><span>:</span></span> <span class="giallo-l"><span> is_better_sync_data</span><span class="z-keyword"> =</span><span> new_has_supermajority</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span class="z-keyword"> not</span><span> new_has_supermajority</span><span class="z-keyword"> and</span><span> new_num_active_participants</span><span class="z-keyword"> !=</span><span> old_num_active_participants</span><span>:</span></span> <span class="giallo-l"><span> is_better_sync_data</span><span class="z-keyword"> =</span><span> new_num_active_participants</span><span class="z-keyword"> &gt;</span><span> old_num_active_participants</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> new_has_sync_committee_finality</span><span class="z-keyword"> !=</span><span> old_has_sync_committee_finality</span><span>:</span></span> <span class="giallo-l"><span> is_better_sync_data</span><span class="z-keyword"> =</span><span> new_has_sync_committee_finality</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> new_num_active_participants</span><span class="z-keyword"> !=</span><span> old_num_active_participants</span><span>:</span></span> <span class="giallo-l"><span> is_better_sync_data</span><span class="z-keyword"> =</span><span> new_num_active_participants</span><span class="z-keyword"> &gt;</span><span> old_num_active_participants</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> is_better_sync_data</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>slot</span><span class="z-keyword"> &lt;</span><span> state</span><span>.</span><span>current_best_sync_data</span><span>.</span><span>signature_slot</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> is_better_sync_data</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>current_best_sync_data</span><span class="z-keyword"> =</span><span> SyncData</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> sync_aggregate</span><span class="z-keyword">=</span><span>block</span><span>.</span><span>body</span><span>.</span><span>sync_aggregate</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> signature_slot</span><span class="z-keyword">=</span><span>block</span><span>.</span><span>slot</span><span>,</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="how-to-rank-syncaggregate">How to rank <code>SyncAggregate</code>?</h3> <p>The EIP reuses the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/specs/altair/light-client/sync-protocol.md#is_better_update"><code>is_better_update</code></a> function from existing specs.</p> <p>To ensure deterministic selection when participation and finality are equal, implementations MUST break ties by preferring the lower <code>signature_slot</code>; if equal, the existing selection SHOULD be retained.</p> <h3 id="how-could-a-backfill-protocol-use-this">How could a backfill protocol use this?</h3> <p>Once the data is available in the <code>BeaconState</code>, a light client data backfill protocol could be defined that serves, for past periods:</p> <ol> <li>A <code>LightClientUpdate</code> from requested <code>period</code> + 1 that proves that the entirety of <code>period</code> is finalized.</li> <li><code>BeaconState.historical_summaries[period].block_summary_root</code> at (1)'s <code>attested_header.beacon.state_root</code> + Merkle proof.</li> <li>For each epoch's slot 0 block within requested <code>period</code>, the corresponding <code>LightClientHeader</code> + Merkle multi-proof for the block's inclusion into (2)'s <code>block_summary_root</code>.</li> <li>For each of the entries from (3) with <code>beacon.slot</code> within <code>period</code>, the <code>current_sync_committee_branch</code> + Merkle proof for constructing <code>LightClientBootstrap</code>.</li> <li>If (4) is not empty, the requested <code>period</code>'s <code>current_sync_committee</code>.</li> <li>The best <code>LightClientUpdate</code> from <code>period</code>, if one exists, + Merkle proof that its <code>sync_aggregate</code> + <code>signature_slot</code> is selected as the canonical best one in (1)'s <code>attested_header.beacon.state_root</code>.</li> </ol> <p>Only the proof in (6) depends on <code>BeaconState</code> tracking the best light client data. This modification would enshrine the logic of a subset of <code>is_better_update</code>, but does not require adding any <code>LightClientXyz</code> data structures to the <code>BeaconState</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork as it introduces new consensus validation rules.</p> <p>Only light client data following the hard fork can be proven to be canonical and optimal. However, after finalization of the fork transition block, earlier light client data can no longer change and could be locked in using a hash.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-10T00:00:00+00:00 2026-02-11T14:49:28+00:00 Qi Zhouhttps://github.com/qizhou Zhiqiang Xuhttps://github.com/zhiqiangxu https://wg-eips.ritovision.com/7650/

Add a precompiled contract that add access lists programmatically

<h2 id="abstract">Abstract</h2> <p>We introduce a new precompiled contract named <code>prefetch</code>, which accepts an <code>accessList</code>.</p> <p>The <code>accessList</code> specifies a list of addresses and local storage keys; these addresses and local storage keys are added into the <code>accessed_addresses</code> and <code>accessed_storage_keys</code> global sets (introduced in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>). Similar to <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, prefetching data through this precompile incurs a gas charge, albeit at a reduced rate compared to accesses made outside of this list.</p> <h2 id="motivation">Motivation</h2> <p>The primary goal of this EIP is to enhance EIP-2930 by enabling contracts to add access lists programmatically. The advantage of implementing this precompile within a contract is the sustained reduction in gas costs for data access operations, leveraging the concurrent computing and IOs that most nodes have.</p> <h2 id="specification">Specification</h2> <p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK_NUMBER</code></td><td><code>TBD</code></td></tr> <tr><td><code>PREFETCH_PRECOMPILE_ADDRESS</code></td><td><code>TBD</code></td></tr> <tr><td><code>CONCURRENCY</code></td><td><code>TBD</code></td></tr> </tbody></table> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new precompile is deployed at <code>PREFETCH_PRECOMPILE_ADDRESS</code>. The encoding of the precompile input is the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[32 bytes for local storage key length n][n * 32 bytes local storage keys][32 bytes for address length m][m * 32 bytes addresses]</span></span></code></pre> <p>At the beginning of the call, we will charge <code>2100 * (N + CONCURRENCY - 1) // CONCURRENCY + 2600 * (M + CONCURRENCY - 1) // CONCURRENCY</code>, where <code>//</code> is the integer division operator, <code>N</code> is the number of local storage keys not in <code>accessed_storage_keys</code> global set, and <code>M</code> is the number of addresses not in <code>accessed_addresses</code> global set. The client should concurrently read the keys and addresses and put the keys and addresses into the <code>accessed_addresses</code> and <code>accessed_storage_keys</code> global sets. The following read cost of the storage keys and addresses obeys <code>WARM_STORAGE_READ_COST</code> as defined in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</p> <h3 id="examples">Examples</h3> <p>Using UniswapV2 <code>swap()</code> function as an example:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> // this low-level function should be called from a contract which performs important safety checks</span></span> <span class="giallo-l"><span> function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {</span></span> <span class="giallo-l"><span> prefetch {</span></span> <span class="giallo-l"><span> token0.slot,</span></span> <span class="giallo-l"><span> token1.slot,</span></span> <span class="giallo-l"><span> reserve0.slot,</span></span> <span class="giallo-l"><span> price0CumulativeLast.slot,</span></span> <span class="giallo-l"><span> price1CumulativeLast.slot,</span></span> <span class="giallo-l"><span> } // add the storage keys `accessed_storage_keys`</span></span> <span class="giallo-l"><span> prefetch {</span></span> <span class="giallo-l"><span> token0,</span></span> <span class="giallo-l"><span> token1,</span></span> <span class="giallo-l"><span> } // add the contracts of token0 and token1 to `accessed_addresses`</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> }</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="charging-less-for-accesses-in-the-access-list">Charging less for accesses in the access list</h3> <p>Similar to EIP-2930, we encourage contract developers to use the <code>prefetch</code> precompile as much as possible, especially assuming the nodes have some decent concurrent capabilities (e.g., some cores and IO bandwidth).</p> <h3 id="allowing-duplicates">Allowing duplicates</h3> <p>Similar to EIP-2930, we allow duplicates in the list to maximize simplicity.</p> <h3 id="no-storage-keys-for-external-contract">No storage keys for external contract</h3> <p>Unlike EIP-2930, the <code>prefetch</code> precompile only accepts local storage keys and addresses. Prefetching the data of the storage keys of external contracts assumes that the contract knows the storage layout of an external contract, which may not be a good practice. To better employ the concurrency of a node, the precompile may accept a list of static calls of external contracts together with the calldata. This work may be done in the future EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>If the EIP is not yet implemented, a contract calling the precompile should result in no operation.</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security considerations were found.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-03-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Cyrus Adkissonhttps://github.com/cyrusadkisson Eirik Ulversøyhttps://github.com/EirikUlversoy https://wg-eips.ritovision.com/7645/

Eliminate ORIGIN tech debt to lay groundwork for account abstraction and close security holes

<h2 id="abstract">Abstract</h2> <p>This EIP proposes aliasing the ORIGIN opcode to the SENDER opcode within the Ethereum Virtual Machine (EVM). The purpose of this change is to move Ethereum closer to enabling account abstraction by harmonizing the treatment of externally owned accounts (EOAs) and smart contracts and to address the security concerns associated with the use of ORIGIN that have and will continue to surface in all or most account abstraction proposals.</p> <h2 id="motivation">Motivation</h2> <p>The ORIGIN opcode in Ethereum returns the address of the account that started the transaction chain, differing from the SENDER (or CALLER) opcode, which returns the address of the direct caller. The use of ORIGIN has been discouraged and deemed deprecated since mid-2016 due to the security problems it introduces, such as susceptibility to phishing attacks and other vulnerabilities where the distinction between the original sender and the immediate sender can be exploited.</p> <p>For instance, if an <a href="https://wg-eips.ritovision.com/4337/">ERC-4337</a> bundler has tokens or other authority in a smart contract determined by ORIGIN, any of the transactions it bundles can hijack this authority since ORIGIN remains the bundler address throughout each child transaction.</p> <p>More apropos in the current context of EVM evolution, the differentiation between the ORIGIN and SENDER opcodes presents a challenge for all account abstraction efforts, such as those outlined in <a href="https://wg-eips.ritovision.com/7377/">EIP-7377</a> and <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a>, because any move towards account abstraction must address the ORIGIN opcode's role, either by modifying or completely bypassing it. Without addressing this, the ORIGIN opcode stands as a barrier to the evolution of Ethereum's account model towards greater flexibility and functionality.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>This EIP proposes the alteration of the behavior of the ORIGIN opcode within the Ethereum Virtual Machine (EVM). Currently, the ORIGIN opcode returns the address of the original transaction initiator. Under this EIP, the ORIGIN opcode would, instead, return the same value as the SENDER opcode, which is the address of the immediate sender of the message or transaction.</p> <p>Definition Change: The ORIGIN opcode (0x32) MUST, in all contexts of execution, return the same value as that returned by the SENDER (also known as CALLER) opcode (0x33).</p> <p>EVM Implementation: All Ethereum clients MUST implement the following change to the EVM: Whenever the ORIGIN opcode is called, the value to be pushed onto the stack is the current call's sender address, as if the SENDER opcode was executed instead.</p> <p>Transaction Validation: Transactions MUST be validated as before, with no changes to the transaction structure or processing logic beyond the EVM opcode behavior specified above.</p> <p>Compatibility: Smart contracts relying on the ORIGIN opcode for obtaining the transaction initiator's address MUST be reviewed to ensure they function correctly under the new definition and worked-around or avoided if this EIP introduces breaking changes.</p> <p>Implementers are encouraged to provide feedback on this specification and report any potential issues encountered during the implementation or testing phases.</p> <h2 id="rationale">Rationale</h2> <p>The rationale behind aliasing ORIGIN to SENDER is to:</p> <p>Facilitate Account Abstraction: Elegantly nullify a universal barrier to account abstraction, enabling more flexible and powerful account models in Ethereum.</p> <p>Enhance Security: Eliminate the security vulnerabilities associated with differentiating between the original transaction initiator and the immediate caller.</p> <p>Clean up tech debt and simplify the EVM Model: Reduce the complexity of the EVM's transaction and execution model by removing an outdated and deprecated feature, making future changes easier and safer.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not fully backwards compatible. Contracts relying on the distinction between ORIGIN and SENDER for logic or security will be affected. However, given the longstanding discouragement of ORIGIN's use, the minimal impact of the change, the widespread desire for a future account abstraction solution in the EVM, and the reality that any AA solution will ultimately have to deal with ORIGIN one way or the other, this incompatibility is considered a necessary step forward for Ethereum's development.</p> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>For each CALL, STATICCALL, DELEGATECALL, CALLCODE:</p> <p>Direct - Ensure that, at the target smart contract, ORIGIN and SENDER produce the same value. (For simple no-hop EOA-to-EOA/SCA transactions, this is already the case today.)</p> <p>Multi-hop - Ensure that, at each frame in a multi-hop transaction, ORIGIN and SENDER produce the same value.</p> <h2 id="security-considerations">Security Considerations</h2> <p>By aliasing ORIGIN to SENDER, the specific security vulnerabilities associated with the ORIGIN opcode are addressed and eliminated. Outside the scope of this EIP, it may be wise to ban all use of ORIGIN to eliminate further misunderstanding or misuse. This can be done via tooling changes outside the EVM or, inside the EVM, reverting smart contract deployments that use ORIGIN.</p> <p>For existing misuse of ORIGIN affected negatively by this aliasing to SENDER (of yet a clear example has yet to be identified), it may be necessary to educate users to avoid this problematic legacy code.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 lightclienthttps://github.com/lightclient kdemehttps://github.com/kdeme https://wg-eips.ritovision.com/7643/

Commit to a single root for all block data before the merge.

<h2 id="abstract">Abstract</h2> <p>Defines an SSZ object for accumulating all pre-PoS data and commit to the historical hashes accumulator's root <code>0xec8e040fd6c557b41ca8ddd38f7e9d58a9281918dc92bdb72342a38fb085e701</code>.</p> <h2 id="motivation">Motivation</h2> <p>There are two main uses we consider for the historical hashes accumulator:</p> <ul> <li>for users who wish to download the pre-PoS data for the execution chain and verify it without executing each block, they may simply compute each block hash, accumulate the epoch records, and then compare the local accumulator root with the expected value.</li> <li>additionally, the accumulator root allows for <code>O(log(n))</code> sized proofs to any pre-PoS block, whereas today to achieve something similar, one must recursively verify the header chain.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="historical-hashes-accumulator">Historical Hashes Accumulator</h3> <p>The historical hashes accumulator commits to the set of pre-merge headers and their associated total difficulty. The format for this data is defined as:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">EPOCH_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 8192</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> blocks</span></span> <span class="giallo-l"><span class="z-constant">MAX_HISTORICAL_EPOCHS</span><span class="z-keyword"> =</span><span class="z-constant"> 2048</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> An individual record for a historical header.</span></span> <span class="giallo-l"><span>HeaderRecord</span><span class="z-keyword"> =</span><span> Container</span><span>[</span><span>block_hash</span><span>:</span><span> bytes32</span><span>,</span><span> total_difficulty</span><span>:</span><span> uint256</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> The records of the headers from within a single epoch</span></span> <span class="giallo-l"><span>EpochRecord</span><span class="z-keyword"> =</span><span> List</span><span>[</span><span>HeaderRecord</span><span>,</span><span> max_length</span><span>=</span><span class="z-constant">EPOCH_SIZE</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>HistoricalHashesAccumulator</span><span class="z-keyword"> =</span><span> Container</span><span>[</span></span> <span class="giallo-l"><span> historical_epochs</span><span>:</span><span> List</span><span>[</span><span>bytes32</span><span>,</span><span> max_length</span><span>=</span><span class="z-constant">MAX_HISTORICAL_EPOCHS</span><span>]</span><span>,</span></span> <span class="giallo-l"><span> current_epoch</span><span>:</span><span> EpochRecord</span><span>,</span></span> <span class="giallo-l"><span>]</span></span></code></pre><h3 id="pre-pos-root">Pre-PoS Root</h3> <p>The hash tree root of <code>HistoricalHashesAccumulator</code> for data before block 15537394 is <code>0xec8e040fd6c557b41ca8ddd38f7e9d58a9281918dc92bdb72342a38fb085e701</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="inclusion-of-total-difficulty">Inclusion of total difficulty</h3> <p>The total difficulty allowed so that clients may return the value for specific JSON-RPC methods which support it. It is also useful for verifying the TTD of the final proof-of-work block.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>n/a</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="csv"><span class="giallo-l"><span>epoch,</span><span class="z-keyword">root</span></span> <span class="giallo-l"><span>00000,</span><span class="z-keyword">0x5ec1ffb8c3b146f42606c74ced973dc16ec5a107c0345858c343fc94780b4218</span></span> <span class="giallo-l"><span>00001,</span><span class="z-keyword">0xa5364e9a9bc513c4601f0d62e6b46dbdedf3200bbfae54d6350f46f2c7a01938</span></span> <span class="giallo-l"><span>00002,</span><span class="z-keyword">0x98cbd8a95ae7dc9c1ed823156d0eab9aaffa869f6852cab18ff0083063f27d26</span></span> <span class="giallo-l"><span>00003,</span><span class="z-keyword">0xd8b8a40b8cf6818e1bac871d882e772be0b28d1baaf72374946506d9e6fa7d75</span></span> <span class="giallo-l"><span>00004,</span><span class="z-keyword">0x6e3baba7e324b99ed72d98f0255d25ce66832736550f8b971c12280eac2a0bb8</span></span> <span class="giallo-l"><span>00005,</span><span class="z-keyword">0x5cff5a4b7284b1a4a6cebfcc80d876ab0418f71254d03f91d46a9a1fab49fa09</span></span> <span class="giallo-l"><span>00006,</span><span class="z-keyword">0x678fb79306f84e9d0a4749323dc29934ca59b852fbc7c8d2890eabe8a0cde282</span></span> <span class="giallo-l"><span>00007,</span><span class="z-keyword">0xd9bc682bc5bc63b20a8344407ae12cb17e2085d448f438efa6aa5d522b913a20</span></span> <span class="giallo-l"><span>00008,</span><span class="z-keyword">0x12c9605f2d8d4738f9aa04fbecdbbbc8b77135ebfaa9db399135c14e1ef10bee</span></span> <span class="giallo-l"><span>00009,</span><span class="z-keyword">0xf9e4e8905b214c97bb4ed1f69178d6ecc769e21352885147fce5b671215db2a8</span></span> <span class="giallo-l"><span>00010,</span><span class="z-keyword">0x5f5d4516b7a38929b47ea7334b62b53829b9665d37f752d96c33fad0f7f78583</span></span> <span class="giallo-l"><span>00011,</span><span class="z-keyword">0x30f04eb968efe4079356b873e37f1657984717e60af612ecca95c98226528d54</span></span> <span class="giallo-l"><span>00012,</span><span class="z-keyword">0x5ecb9bf9e193da08c7e7f22abcd50d1b4d3c2b909f980ac1315856cb48ca49cc</span></span> <span class="giallo-l"><span>00013,</span><span class="z-keyword">0xd0175c1ed6e694180c4c161ac7f06a913784daba14dc1d2e926f72def4f7f65d</span></span> <span class="giallo-l"><span>00014,</span><span class="z-keyword">0x4f92d78141b7fa8d6fcef45f9dbc611f858447629eeac2d63bb43d07e6bd1aca</span></span> <span class="giallo-l"><span>00015,</span><span class="z-keyword">0xa47cb8eb7157d56f718a6896c2ee1843a44e3de81b9127e64b78fc38ee382310</span></span> <span class="giallo-l"><span>00016,</span><span class="z-keyword">0x9344d8b785c0e619d0b1b83e5d7b3849d667f1ec0d0d6390d26fa33dd4cb31af</span></span> <span class="giallo-l"><span>00017,</span><span class="z-keyword">0x43963724de4a8917d16d8c6a663c38fcdcf3ce5b89a51bc766dcd0ffd1d5aa32</span></span> <span class="giallo-l"><span>00018,</span><span class="z-keyword">0xefce27b480c92a0e7fec472fe38e87ed9a1c91c3d07324cc2f262de3916a38f6</span></span> <span class="giallo-l"><span>00019,</span><span class="z-keyword">0xf5434352253a7f35d909fb2c383e7cdad65761c509eec24741197b869ebcc212</span></span> <span class="giallo-l"><span>00020,</span><span class="z-keyword">0x0c405203cb7b2e54b910e5d953b5378ff4f0c3bcebef92e7e3a1f240dd6703ee</span></span> <span class="giallo-l"><span>00021,</span><span class="z-keyword">0x20d8f1af038c2777dea9f86fe9e33f14af9e4270ee20adb32e0dddedc4b85236</span></span> <span class="giallo-l"><span>00022,</span><span class="z-keyword">0xb694d8955851f744e44c68fba193f6bc41d1159036531c5f55fac9ce91883695</span></span> <span class="giallo-l"><span>00023,</span><span class="z-keyword">0x11beacba76e467dda23253f104d064b00ab75672ab33cff6097be1c3e8ce7053</span></span> <span class="giallo-l"><span>00024,</span><span class="z-keyword">0xf216a28afb2212269b634b9b44ff327a4a79f261640ff967f7e3283e3a184c70</span></span> <span class="giallo-l"><span>00025,</span><span class="z-keyword">0x987cb6206e5bae4b68ce0eeb6c05ae090d02b7331e47d1705a2a515ac88475aa</span></span> <span class="giallo-l"><span>00026,</span><span class="z-keyword">0x3afd50ff0edf3cae577c42bfc39871f0f0ffe7bdd5ee0b96f7b2e879c9b29994</span></span> <span class="giallo-l"><span>00027,</span><span class="z-keyword">0x28083285c935c0c169ea1406f9830701ff20fde3d0b2a5b83efc1cd13139dccf</span></span> <span class="giallo-l"><span>00028,</span><span class="z-keyword">0x362fc97cbcfa6ab609f1a3f8ca2f8a6e0ac6061c33e84a285a14713cfd73f203</span></span> <span class="giallo-l"><span>00029,</span><span class="z-keyword">0xa0cb99e26e896f5d115914910c4c66fc112ae240bc827acdd564785e738ff29c</span></span> <span class="giallo-l"><span>00030,</span><span class="z-keyword">0x78fc5e8e58e6dd726499295eea1f7f52a31979c6a003d48d4e027d95285e851c</span></span> <span class="giallo-l"><span>00031,</span><span class="z-keyword">0x52306cf9ed840bea9d8c3466bfbed5ffecdfd51107f33d013a487c3b653b3646</span></span> <span class="giallo-l"><span>00032,</span><span class="z-keyword">0xcb4d0c3a2384b890a8acd698da6b9ae6267c5365fcc516391829f7adbae838ee</span></span> <span class="giallo-l"><span>00033,</span><span class="z-keyword">0x0c3781bbc07124e29ff67754bdcf556b20ac4f4ef19ddb004837ec50193ce0bc</span></span> <span class="giallo-l"><span>00034,</span><span class="z-keyword">0xfac9315aa442073b647e71716a7acf1c170e5a0092b69edc2a5634813716592f</span></span> <span class="giallo-l"><span>00035,</span><span class="z-keyword">0x737e07578f0dd5eeebd8313e58cdb59ac705c0ba07d842feace53fa2922c6508</span></span> <span class="giallo-l"><span>00036,</span><span class="z-keyword">0x84c7c1e7c4a8949247953858992012799d323ebcd0fc6cdecf8002f20f2ea7e1</span></span> <span class="giallo-l"><span>00037,</span><span class="z-keyword">0x34d067652cbea843a01e70ba75566b6f174218969dc453c285e59b4f309faee8</span></span> <span class="giallo-l"><span>00038,</span><span class="z-keyword">0x38aaf94c653d619b1a08e7cf9fac72ecc57715bc19ba236c942d400742bc3f16</span></span> <span class="giallo-l"><span>00039,</span><span class="z-keyword">0x4ad4940c51be350c9d8c69f424f01a9e87e42fe6b312afae3f8f7267c62512e5</span></span> <span class="giallo-l"><span>00040,</span><span class="z-keyword">0x4707f60dffab08b6837078ae91316ebe04a275aa19892462521cb6125913d3d7</span></span> <span class="giallo-l"><span>00041,</span><span class="z-keyword">0xa6a87a9e797af923887645fc57602d60f7cd684357ae837a6270936eb6e5ebd5</span></span> <span class="giallo-l"><span>00042,</span><span class="z-keyword">0x5c8dca3c7c7842995372aed15fae7b9bada264b56082bec19c870bd4c7562b97</span></span> <span class="giallo-l"><span>00043,</span><span class="z-keyword">0xcb513d912a6ee576a33cf3683d596354b57484cfb4d7e382f64326eef5bec32b</span></span> <span class="giallo-l"><span>00044,</span><span class="z-keyword">0x1c72a3909e56831cea647e4c67faeb91db49b5be8c61832082041c16b2072e87</span></span> <span class="giallo-l"><span>00045,</span><span class="z-keyword">0xa87afdc1e1d225e6826d8f18c15c0415c7d13ba2a3933dc35816491bbc64501c</span></span> <span class="giallo-l"><span>00046,</span><span class="z-keyword">0x22b3f78d1437187866a86fc05463d5afa558903def2357a05ffd32663d5b7896</span></span> <span class="giallo-l"><span>00047,</span><span class="z-keyword">0x92d8437253506251ea652d6242ced9f3941906d4ffaa78edcb396a6c5fcad7d7</span></span> <span class="giallo-l"><span>00048,</span><span class="z-keyword">0x78ae53ed63f208b18448b40e3c31476eb2cd6627d6c65ba7dbc96d3e1051dcca</span></span> <span class="giallo-l"><span>00049,</span><span class="z-keyword">0x3934e9608386c1bab748cf80199b6b6341e581a163c64f6c0bfc55d36d41cc64</span></span> <span class="giallo-l"><span>00050,</span><span class="z-keyword">0x71698ebf74b826ce701bdda7c804c2b9d0aa3616bc1ccfbb62d4455cc2b0bec6</span></span> <span class="giallo-l"><span>00051,</span><span class="z-keyword">0x2c1c77788b22e42409b9e068fc98a28310af7cb451dbdc2601d29771bb117c47</span></span> <span class="giallo-l"><span>00052,</span><span class="z-keyword">0x3a047d9aba82db1eac26733dcc652c0aed663250b25781360ba9596db48ebe01</span></span> <span class="giallo-l"><span>00053,</span><span class="z-keyword">0x161ee1b5102e9c6300c04d4885dda180e50f3e5078ca8d2bc1f3d0af0a9d8287</span></span> <span class="giallo-l"><span>00054,</span><span class="z-keyword">0x14074ce7acc2ad4e4d60966d9717d8f2e6f7d28cffa1fccede05d4ab7269b772</span></span> <span class="giallo-l"><span>00055,</span><span class="z-keyword">0xae639ad86664191274136f85177a515b7524be9d089571f5e24c13bff9f91a38</span></span> <span class="giallo-l"><span>00056,</span><span class="z-keyword">0xd92c394c57df45119161e4ffecf8445e3af06c79c90987db86db649f2cbf7840</span></span> <span class="giallo-l"><span>00057,</span><span class="z-keyword">0x4bbe776e7229c9583ccc6da7d82451b56ef1fc015c802c27b2d364ffff7c6e7d</span></span> <span class="giallo-l"><span>00058,</span><span class="z-keyword">0x9ac60ed891eb7490ae1a5fa1d9c14ef66b01bf5fdc6f31a419a28c2946e0c3bc</span></span> <span class="giallo-l"><span>00059,</span><span class="z-keyword">0x246c1b33d8b91d3fad3c3b88d6aa04cd872bdf0608aafcd1f11a53c437418eec</span></span> <span class="giallo-l"><span>00060,</span><span class="z-keyword">0x4533d0c5d211593355e4bf1e07564fc04bc158e75437f33eb97ec9066322b3dd</span></span> <span class="giallo-l"><span>00061,</span><span class="z-keyword">0x122db1c231fee4e86b938a432ae95eae69a3ea733b82b15c2d784c70be3f9b89</span></span> <span class="giallo-l"><span>00062,</span><span class="z-keyword">0x65505079e3493c2fb572db2d1d9e455ef3e48be78c18f760fa6724fe1326f5ff</span></span> <span class="giallo-l"><span>00063,</span><span class="z-keyword">0x39b219117b1d306e0e9ac0a8f969d47f1cc375d7593e2c8e0996fbb80822f293</span></span> <span class="giallo-l"><span>00064,</span><span class="z-keyword">0xdb26a83cc55bf6f8c6ff63525fafd2c8dca1a0cd99828afcdbc5d3146da18dde</span></span> <span class="giallo-l"><span>00065,</span><span class="z-keyword">0x1df3a40f96ae6291f081fcf9dab9ebe03382d958cde909a4cb7cdc76201fe006</span></span> <span class="giallo-l"><span>00066,</span><span class="z-keyword">0x07bde22d34d4cd3a29214dd2bd1c35a49190a3df40505ddddde8e3622c6e7cab</span></span> <span class="giallo-l"><span>00067,</span><span class="z-keyword">0x751bac833356761ab2a1794fed46b04afcbc60d23e608a707db5b897e5d042d2</span></span> <span class="giallo-l"><span>00068,</span><span class="z-keyword">0x546a10c136f0cb0c85bf58b69e04424ffcf1b00b4afffd3f33c5ee253899367b</span></span> <span class="giallo-l"><span>00069,</span><span class="z-keyword">0x55c236ed7566681663e88a71b9597a48970297cbc0ee8b23b1d302dfe69f61f6</span></span> <span class="giallo-l"><span>00070,</span><span class="z-keyword">0x0ac3ebb18ec9ee6c921f36d5053d9343ad81218f797c39376d9e4f4352c768c7</span></span> <span class="giallo-l"><span>00071,</span><span class="z-keyword">0x2fb03713d78b7fba05408f872267c4877ed8db5e1bd1b9f1e57d872c5cc08adf</span></span> <span class="giallo-l"><span>00072,</span><span class="z-keyword">0x2f9a4a75044a49046297e71c578329b8326352fd49bd01158f42c73ea6948454</span></span> <span class="giallo-l"><span>00073,</span><span class="z-keyword">0x32871a4303777114e0f17126567013d94bb2884ea22bf0a103d45fef47c4b005</span></span> <span class="giallo-l"><span>00074,</span><span class="z-keyword">0x8aacdeeec1021158c05056e5aa2ea4cc4994aa2372f5d37d22272ed065f7493d</span></span> <span class="giallo-l"><span>00075,</span><span class="z-keyword">0x368ce2b13e74f99ef231825ba5df588d654ccaea62e0ff46d012b879608454d5</span></span> <span class="giallo-l"><span>00076,</span><span class="z-keyword">0x290a4131608502c9423b9ec4fdbb4cfdfa245ec92a571053702cb431d6d661ab</span></span> <span class="giallo-l"><span>00077,</span><span class="z-keyword">0x5d736b0aecc493c6160872dbcc216816071483a4c4518a2284bbaad9a9c592c9</span></span> <span class="giallo-l"><span>00078,</span><span class="z-keyword">0x98ac3e9dfdd27556bf5d5e037d10de525ad1142c1e954de9cc3b7e2287dc9ca9</span></span> <span class="giallo-l"><span>00079,</span><span class="z-keyword">0x95e0734eb17b4182d2458e6f5268abbc75c44e743b5abeb775d99bfdb1d1f6a2</span></span> <span class="giallo-l"><span>00080,</span><span class="z-keyword">0xd778ae86ee6b3ed9f3f3dc83a5ece367faa9ea230daa21c07c54e073af83f2fe</span></span> <span class="giallo-l"><span>00081,</span><span class="z-keyword">0x2089ffc8e635baaf3e1673f9ca3ed6d64b1dd02dd73aa5c2beb692af5363a1a1</span></span> <span class="giallo-l"><span>00082,</span><span class="z-keyword">0x382ac3bc7f5de4df286366863351ae1d3655fe5df7aa195e3f955e5cb4988bed</span></span> <span class="giallo-l"><span>00083,</span><span class="z-keyword">0x5ab1cca211eb959107d5541a30d1b9f3e8a6fcf9935643acabd4f2dff8f3d212</span></span> <span class="giallo-l"><span>00084,</span><span class="z-keyword">0x9ec0497d2130e92ea521793e98774962fe83ebd994fcac4963cede93950efaaf</span></span> <span class="giallo-l"><span>00085,</span><span class="z-keyword">0xf847bef9c0f4876906d74c0955d362175cc4d9bb83f134d60dad7bf3df6d0b3b</span></span> <span class="giallo-l"><span>00086,</span><span class="z-keyword">0x0dd5eb92d78e345af8ac60db208207fe3f4621e5ea09f195da8c977418c358fb</span></span> <span class="giallo-l"><span>00087,</span><span class="z-keyword">0xc0612d68f34fc28c18a095b0062d5762cf56d5c6554d94a0e97315ef262a4dd7</span></span> <span class="giallo-l"><span>00088,</span><span class="z-keyword">0x3f433e6334fa2b3d05edd615d92926aaec56b355f9375e3ea4b91ca0dd7c654d</span></span> <span class="giallo-l"><span>00089,</span><span class="z-keyword">0x0432ee13cd0aab4c445219c8edcbf80bd502d11170a2724cabad19f55d8f2ad1</span></span> <span class="giallo-l"><span>00090,</span><span class="z-keyword">0xcf23b0c8c31f2368dc982efbf1220f64439b107d691450a3eb15dca1180f5854</span></span> <span class="giallo-l"><span>00091,</span><span class="z-keyword">0x9fbb0197fb4b50008c5feea2810b0336d38dba1958fafdb3482036e6ad269895</span></span> <span class="giallo-l"><span>00092,</span><span class="z-keyword">0xf88ab15fc925643c8adc5b3485f19240e4afc53dc777f0c9bf9ab5c6c6f3338b</span></span> <span class="giallo-l"><span>00093,</span><span class="z-keyword">0xb7499b8c5bdb76c9a892b9e0d09cde7813ed0c38740d25743d02910f337c3c6a</span></span> <span class="giallo-l"><span>00094,</span><span class="z-keyword">0x5c45bbb126771f6277dca461a28239b4efd388b55afe6ef1c6e595ea4ebd9509</span></span> <span class="giallo-l"><span>00095,</span><span class="z-keyword">0xa3dea11d2eef1db4c8855ae369918a0e12de5b99e0087e3af0105ceb1ed1e0a3</span></span> <span class="giallo-l"><span>00096,</span><span class="z-keyword">0x91ff33f7ed74652bdd22a154aeec0cf24542b29477122dc02704000ef15dd540</span></span> <span class="giallo-l"><span>00097,</span><span class="z-keyword">0x8e4ffd2bc8e767d8848b4d001c20a7dbf942fe73b20f6821a2abd586c8462334</span></span> <span class="giallo-l"><span>00098,</span><span class="z-keyword">0x4c5709afb1a85d25d9131fe5e441ad7f0d5d4608583c07836ff4cc2e3228a30d</span></span> <span class="giallo-l"><span>00099,</span><span class="z-keyword">0xd55b92c14fec40d8ccf4fee501efecf9f71ced6d787eb3faaa4cd7050f3a3e08</span></span> <span class="giallo-l"><span>00100,</span><span class="z-keyword">0xbb39d00a031359e390914a91d9c26c1b8dff1b6d8ca4a44ebb64d5946a5451c0</span></span> <span class="giallo-l"><span>00101,</span><span class="z-keyword">0xe6df19425c17f10ef876e9964f7561bf3f7bc41fdca9151c26797f38e4a064e4</span></span> <span class="giallo-l"><span>00102,</span><span class="z-keyword">0x2aac9e21e2134958f6ebebe21acaa65142ccab41a0ca386aad4eb4c383b69145</span></span> <span class="giallo-l"><span>00103,</span><span class="z-keyword">0x3fe56c2aa4b33540147f05427b757a5ecfb57a4301a84022a0a26c57bd1f5b4b</span></span> <span class="giallo-l"><span>00104,</span><span class="z-keyword">0xf3269b3047cc6b5dd1f38313ff3bcc717b44375148a8637e4ce41ec39a9adc57</span></span> <span class="giallo-l"><span>00105,</span><span class="z-keyword">0x6f2f86e801b6456e59b5f4c6d2587ca8e5cfd97fbf93dcbd11b7c3cf65b83170</span></span> <span class="giallo-l"><span>00106,</span><span class="z-keyword">0x621a252741c0cc84c5e7e3b01f90d30d86474348f44cc659ff48000093671bbd</span></span> <span class="giallo-l"><span>00107,</span><span class="z-keyword">0xc3e8f7cdf2b7fd8a0ac98834d4ab1374e8aec4644fc722a04db5abd57329405c</span></span> <span class="giallo-l"><span>00108,</span><span class="z-keyword">0xbe1a1635522e1529456595e0615c4d3c53905a0198ad65320c8ec1f7f3ec665b</span></span> <span class="giallo-l"><span>00109,</span><span class="z-keyword">0x49424c3e48cdef7a00003a3ea76da66ce8f833df83f74580faacfa7cbff5dd28</span></span> <span class="giallo-l"><span>00110,</span><span class="z-keyword">0xaf29e604357c6c3d6f8a23c69ab648b8b19c0bac3e7e8ffcfe3d23f62c585490</span></span> <span class="giallo-l"><span>00111,</span><span class="z-keyword">0x1738246f2b0b1ba4a084cbe299233f487f3730d8ebcac38bc6cb43e503992248</span></span> <span class="giallo-l"><span>00112,</span><span class="z-keyword">0x0074a32e1420b57f8f7c142a61d5d945fa0df577c3007b375dc4412c46e774a0</span></span> <span class="giallo-l"><span>00113,</span><span class="z-keyword">0x56e191304d05e3370a821bf16ef43a7528b63105a03b425fb2c408ec21807233</span></span> <span class="giallo-l"><span>00114,</span><span class="z-keyword">0x10c2a569cfef2c20fbce1953dcabaa463cae1daf08e83a38322091fb1da59db0</span></span> <span class="giallo-l"><span>00115,</span><span class="z-keyword">0x26efb6b7b8a822fcfb126451c09491efa88a986bf3ee4f0bcbc7ff5610f051c1</span></span> <span class="giallo-l"><span>00116,</span><span class="z-keyword">0xbdf3bc6e520513ff3ca5382abbcfad7f2bc857db708233a07f17149d57d66648</span></span> <span class="giallo-l"><span>00117,</span><span class="z-keyword">0xe68e5334db9c4e799fdd67843038b909e231e8f5d248af1cb212907554ccc352</span></span> <span class="giallo-l"><span>00118,</span><span class="z-keyword">0x1c9a243765a53509f7ac091504edfdb27fe9e22f9766a7cfa02e0f87ba6774b5</span></span> <span class="giallo-l"><span>00119,</span><span class="z-keyword">0x5fc6b689c399c8151792427fa1e9b44c6453f520ea15ca643ec14cf1860b3397</span></span> <span class="giallo-l"><span>00120,</span><span class="z-keyword">0xcfefc65fab88cf757198c581e272c0e02d6488f4447b87dea8c908cbd8b3fdc6</span></span> <span class="giallo-l"><span>00121,</span><span class="z-keyword">0x0e29b6cdd3b4816acfbd104ca56b2ed140958c37fd4f7d9dbe5d62e1e7444e61</span></span> <span class="giallo-l"><span>00122,</span><span class="z-keyword">0xcddbda3fd6f764602c06803ff083dbfc73f2bb396df17a31e5457329b9a0f38d</span></span> <span class="giallo-l"><span>00123,</span><span class="z-keyword">0x7717d3958ced7ec038af0b4d7daaaf2ab4da56290db865faaf96da59e9babf7b</span></span> <span class="giallo-l"><span>00124,</span><span class="z-keyword">0x2e66a66a8ff5e15178ee8c9e500475b7badb71cc65d26dd6074e8faad109b427</span></span> <span class="giallo-l"><span>00125,</span><span class="z-keyword">0x82fdaab150f1a25c78a2a0253018fc5a83c420bfed8ec727f6c98e1571b39b6c</span></span> <span class="giallo-l"><span>00126,</span><span class="z-keyword">0x427637ff154cc2036316442348c319c019515af54dd5a2c702527b87f6ea4611</span></span> <span class="giallo-l"><span>00127,</span><span class="z-keyword">0x65e302f1d26bca3ceb600bcc6c19190d2a5e9723a47a99e0710f4ea1fdf9a2f7</span></span> <span class="giallo-l"><span>00128,</span><span class="z-keyword">0x6fdc1fedc9d9454ed6b7f1067da89f57ee4c4e298767cebcf549b37c38b463e3</span></span> <span class="giallo-l"><span>00129,</span><span class="z-keyword">0xc8705b6e734dc09bff141a739eddafc9a3016ca7e7078a09439db7785fb4e688</span></span> <span class="giallo-l"><span>00130,</span><span class="z-keyword">0x650f1d51006a9afa156973b7080774340dbff7334f6d4941729ed1fd39f4bbd2</span></span> <span class="giallo-l"><span>00131,</span><span class="z-keyword">0x7b4435cab2538749da96316d2068854b40a8cc5eb4810155954acb70ab8eefec</span></span> <span class="giallo-l"><span>00132,</span><span class="z-keyword">0x23bd760353974c8a41e410bb24b6aee32d19eb703692420d375da68ed5b8b4a9</span></span> <span class="giallo-l"><span>00133,</span><span class="z-keyword">0xc0faccfc19b41bb694cb86c86b88760dddc771125caff85b33ee5cf935f5106b</span></span> <span class="giallo-l"><span>00134,</span><span class="z-keyword">0xec9cf3ec39f1bb33d363eda9d803fd63de89a5b4afeed17c9bb5185b784d4cc2</span></span> <span class="giallo-l"><span>00135,</span><span class="z-keyword">0x66f5486b3e5c79a9d9d10d4ac5581bf89b4068376bf05ced98455b7d50b08844</span></span> <span class="giallo-l"><span>00136,</span><span class="z-keyword">0xdc4ebb94b5007edaa6be31715620430cab85927af56ff7efcd8e5c4df5b2912d</span></span> <span class="giallo-l"><span>00137,</span><span class="z-keyword">0x022982006526d25c7ee022373f4832c10fe42c7aa25b26044ee3f317b812c221</span></span> <span class="giallo-l"><span>00138,</span><span class="z-keyword">0x3d2314001a3de949f8cf44018b245fe6522bfe212ecae7b8e1676505d05c9905</span></span> <span class="giallo-l"><span>00139,</span><span class="z-keyword">0x5f31661180c2ee22f0f7209e38c1c2aea2fc03384aa0ea1f9d8b98cb0747ca5d</span></span> <span class="giallo-l"><span>00140,</span><span class="z-keyword">0xf13c9fc08dd8e3fd03250091f66d0cebcad41cfb4330d6e68bf447863d2f8201</span></span> <span class="giallo-l"><span>00141,</span><span class="z-keyword">0x17dbb0e39329cd8b2bf6839de0722241211c8a602c233f48302e50d7e6aa6361</span></span> <span class="giallo-l"><span>00142,</span><span class="z-keyword">0xe42539c839845c3033143db80f7bd316ab323114554cca363c2f3ead3ed6a68d</span></span> <span class="giallo-l"><span>00143,</span><span class="z-keyword">0x5594a813aaa2752040681086954b21e457ddc5a8f1d816b45925eb85ee7528ee</span></span> <span class="giallo-l"><span>00144,</span><span class="z-keyword">0x5ac2296fd274fd53197c615a25b4fb6f4303b17a977954775f73e036981eb4f0</span></span> <span class="giallo-l"><span>00145,</span><span class="z-keyword">0x9244d418b8875cb5a463decd0f8cee235755222f2e72ad97810635975f6ffff8</span></span> <span class="giallo-l"><span>00146,</span><span class="z-keyword">0xaf9e7a53390b2fe7c833e937cdbf627a8ecb39da70260eda50ad0af37b4a2d1f</span></span> <span class="giallo-l"><span>00147,</span><span class="z-keyword">0x1b6fa332dd5f6b04e3fb1a027b63f2513b4159035d3294b0212899649b61da2a</span></span> <span class="giallo-l"><span>00148,</span><span class="z-keyword">0x39f0b0575eec3daa97f64b9bc538f841242003a72256fed04e015e78f72bb92d</span></span> <span class="giallo-l"><span>00149,</span><span class="z-keyword">0x586c4a913ddb47e0cd4847637cccd2b458a09e35e10b29451febc5ce8f19f696</span></span> <span class="giallo-l"><span>00150,</span><span class="z-keyword">0x3ff89a4a288f9325e315b394c991680a5843acde1412d0539412363b08ee7c4d</span></span> <span class="giallo-l"><span>00151,</span><span class="z-keyword">0xe322efe1b787fb583eed8d19ef06ac5660c014e566ba2541c160251273f8eaf5</span></span> <span class="giallo-l"><span>00152,</span><span class="z-keyword">0x4d9d0d1c39a4d03a8e4def8892d713c4c9c84df804bd2da90e20e596c99ff6f1</span></span> <span class="giallo-l"><span>00153,</span><span class="z-keyword">0x6b5702b39f5bde08d74649594e48ef49faf24a19c5d7ec75d8cf490157f4f201</span></span> <span class="giallo-l"><span>00154,</span><span class="z-keyword">0x13608c120fd377b160206bd5f9afe2ed660ecd8a121210faeaec26c9b6010975</span></span> <span class="giallo-l"><span>00155,</span><span class="z-keyword">0xd0bf6ce2d1f149196b41e2379831cd9e07d215a9da2be8a2b772be32a10b3f64</span></span> <span class="giallo-l"><span>00156,</span><span class="z-keyword">0xb8c3629c89fbf5c93a481688d05e108af37f4ca1152e2c1ce66de366db58e934</span></span> <span class="giallo-l"><span>00157,</span><span class="z-keyword">0x97351a9d18fe2307ffc128e294f580eb5c9c9f48fba6a5f4f25a0aa98d97fac8</span></span> <span class="giallo-l"><span>00158,</span><span class="z-keyword">0x5cee8f8c5f208a9d23dc367deb3c47e1b3e186bbdd94f2812ac27b40825de041</span></span> <span class="giallo-l"><span>00159,</span><span class="z-keyword">0xb92f84e91d955459a2de86bc28544a82ffaf23c6175f657f767303d63cf8b842</span></span> <span class="giallo-l"><span>00160,</span><span class="z-keyword">0x3e41d9f5b9538accaac888b49abc201aa3d71f5aa6c516a97e69314886989788</span></span> <span class="giallo-l"><span>00161,</span><span class="z-keyword">0x0736b99a2882a562bfd35db27b128a498711834107fd2c0356063b406ed8c804</span></span> <span class="giallo-l"><span>00162,</span><span class="z-keyword">0x0a1530daf01f3cddb2af69fc527b5f7635aab2d02adc46e5a21f8344eed9f7b3</span></span> <span class="giallo-l"><span>00163,</span><span class="z-keyword">0x43212d3b60bfcccb6b12bf765fd072f8785a7d41dca097e37ea14b7c8faf6d85</span></span> <span class="giallo-l"><span>00164,</span><span class="z-keyword">0x3744a01c5c7968e2230ec9d29de8a370db7f43763ef8f22f58cbbdf13f27eb1e</span></span> <span class="giallo-l"><span>00165,</span><span class="z-keyword">0x3d14fc84c9f2dafa748275285205ae2b29df613c8f982d1f334d661b1511f8e2</span></span> <span class="giallo-l"><span>00166,</span><span class="z-keyword">0x97c2592527a83d1c2c514f447e8ae6fdb1481c0dc9c4a3f7212049c5eeae578d</span></span> <span class="giallo-l"><span>00167,</span><span class="z-keyword">0x1148500252c17babbed0e2df0e3913dc380f7c0a06e680d4ba101748620660b4</span></span> <span class="giallo-l"><span>00168,</span><span class="z-keyword">0x88a365fabc60615ca56960314ae6006f61df6fe729a40341c12bb3c98045a4dc</span></span> <span class="giallo-l"><span>00169,</span><span class="z-keyword">0xf18242e71a0c97722f01fbe9c462e0fe857d93a43f1d683fff9e36e4d3ad59df</span></span> <span class="giallo-l"><span>00170,</span><span class="z-keyword">0xf03ea8ee5343e37601df81cc61173e6276516b1f69225a8c1a94fb079545957f</span></span> <span class="giallo-l"><span>00171,</span><span class="z-keyword">0xbec8ccd9a6e13443a8e61a931138f3cf6218a2b477d11ef59a082f898796c439</span></span> <span class="giallo-l"><span>00172,</span><span class="z-keyword">0x34a4c5d21fc33c31b415829b9e46c63588db2327e3ee13682d52233108a2af25</span></span> <span class="giallo-l"><span>00173,</span><span class="z-keyword">0xe1ae6c812dc2ca1cb0613ab42e6c81721f96e771b13c79d284dacbb30c65e5aa</span></span> <span class="giallo-l"><span>00174,</span><span class="z-keyword">0x727d10b81b790e7f5f608c35126fafc3523c7e991bfdb8ef018edbdd207b4c24</span></span> <span class="giallo-l"><span>00175,</span><span class="z-keyword">0x1bf21dcc47b8d4ed6511e49dfc4bc14c1f40f2c21464d52aba8b4a50c60e3b1f</span></span> <span class="giallo-l"><span>00176,</span><span class="z-keyword">0xecc872aa4aa1c53bdc3c22687ed31f1373db111f1c1219286f857b157f6990b0</span></span> <span class="giallo-l"><span>00177,</span><span class="z-keyword">0x966bdbf23d2e86326afccf08377aac0067d485c6098d90c1c74a84b34b8eea3a</span></span> <span class="giallo-l"><span>00178,</span><span class="z-keyword">0xb412f22cecb0219921846638c68908fbc2d73f3d2c7d32d7d86795e9f48c5145</span></span> <span class="giallo-l"><span>00179,</span><span class="z-keyword">0x09e40d3b668d4808509a521703734da066da50c303525314712713c5dbc6a2f2</span></span> <span class="giallo-l"><span>00180,</span><span class="z-keyword">0x8ce22357ac0066d519294b9ab476c222a2edf3cbcc4e06a2df0504ad11f5c1ca</span></span> <span class="giallo-l"><span>00181,</span><span class="z-keyword">0xac1cf418529f5346213890d7f11ccf4a21e24023d40f2eaaa943606f8b7a1e6e</span></span> <span class="giallo-l"><span>00182,</span><span class="z-keyword">0xf770e12a39d1ebfe34919a211fcedb2098ff562689be021bbfb8636f756c4b95</span></span> <span class="giallo-l"><span>00183,</span><span class="z-keyword">0x798224ae95fa5281f29cdd3ac9eb753ca8e9ee44b9cb2c5747f97c8d71917b58</span></span> <span class="giallo-l"><span>00184,</span><span class="z-keyword">0x876fdbe53a7831817a5e123f1b043700f1f3d47f685b772dded35c953d629e5a</span></span> <span class="giallo-l"><span>00185,</span><span class="z-keyword">0x7b447a76548eb9c28145371f61831a2dc941acd907804808a7ab93f7c171d621</span></span> <span class="giallo-l"><span>00186,</span><span class="z-keyword">0xf1e11ac5a67e45142b1a1a13663c725f82a84d5e59ddf65f3b740dbd028b3d63</span></span> <span class="giallo-l"><span>00187,</span><span class="z-keyword">0xce8b009f996254d6df379dd2b3a5aba9dd1d3e0b64de28e5838b43f411f42e4b</span></span> <span class="giallo-l"><span>00188,</span><span class="z-keyword">0xc7bd816d6d55b71c0f6784b2925ff9e1daf65bfb238fc1bb4980274130b500c9</span></span> <span class="giallo-l"><span>00189,</span><span class="z-keyword">0x144cc97d4bfc31469fec6de2cc4ab5556af13aa4b00b96081692ea64092c592d</span></span> <span class="giallo-l"><span>00190,</span><span class="z-keyword">0xcbbcca518e96049a99aad9b53f2e579cf866d6c8fa3a69e407404a3508963394</span></span> <span class="giallo-l"><span>00191,</span><span class="z-keyword">0x3a7f648499e877f2451d3bb6f1e90e5e48ce653459849d52aef5b1f04bd7a9cb</span></span> <span class="giallo-l"><span>00192,</span><span class="z-keyword">0x8a4639c3f8df41e06f4af80ecd6227823708c39128cd6a791e9ce390d9bcc7c9</span></span> <span class="giallo-l"><span>00193,</span><span class="z-keyword">0x52629553fb11ce8b1f53ad71c3ec8fa911ff6e0424b7c0a015922311888079d3</span></span> <span class="giallo-l"><span>00194,</span><span class="z-keyword">0xc4828a4b7616281c5e82ba47e691de8a9975512f0d9033b098082cf027e90236</span></span> <span class="giallo-l"><span>00195,</span><span class="z-keyword">0xf50a165e20e68aa37f97ead770fd9710ccb7b4fdc80581b5982f1d7a219feae8</span></span> <span class="giallo-l"><span>00196,</span><span class="z-keyword">0x5c31919b4d982bee212e5d30e35fc2998d946a0c124e54e3e2c27fbf8d129494</span></span> <span class="giallo-l"><span>00197,</span><span class="z-keyword">0x9e2a709b9953cd0e76df8b6f36d2cee961b24aa19ed11c6def3f5a1744c1755b</span></span> <span class="giallo-l"><span>00198,</span><span class="z-keyword">0xc3e781bf3998d0fd70bdbdf8213e066bb31636039606d9763ab9449cf73ad5d1</span></span> <span class="giallo-l"><span>00199,</span><span class="z-keyword">0x20c05ee3e79b3ab76d806ae93d9cd01340ea68c007816dcedede0635df91850a</span></span> <span class="giallo-l"><span>00200,</span><span class="z-keyword">0xdc265ad95ef9c500cecb8bf2a5da52b3f29d171aa981c8bd9ccbd6ccb7696e69</span></span> <span class="giallo-l"><span>00201,</span><span class="z-keyword">0x1356f2dabf963afe35b149a0de796d3e48f87bc41d9a516d4924854af52dd709</span></span> <span class="giallo-l"><span>00202,</span><span class="z-keyword">0x84e861144a0bfc933935e47097d963e8591a0f321cdb7ad1d75d899ca501df1e</span></span> <span class="giallo-l"><span>00203,</span><span class="z-keyword">0xf2da7b50b32ed6bc786564ffc8e7b85ab250ec0eaa0096dea3faebfc9e07bdc7</span></span> <span class="giallo-l"><span>00204,</span><span class="z-keyword">0x7f42b43f0556b03846f18a12da581203682f8d2266fcd686b388970ea6229de5</span></span> <span class="giallo-l"><span>00205,</span><span class="z-keyword">0xafd08f8ec73d9a83ac8b099ba3202cda132e9e07e3dd18738dc4b5b1f0d98e93</span></span> <span class="giallo-l"><span>00206,</span><span class="z-keyword">0xcf4a2c657b1cf55f37167bf85a51ed104eac71967a98bd4c02a42dfc057c02a6</span></span> <span class="giallo-l"><span>00207,</span><span class="z-keyword">0x59a0e883c7a7087b9c330ae4703d0cf263eedd8d20466e313c894519235f5d44</span></span> <span class="giallo-l"><span>00208,</span><span class="z-keyword">0x3d0bbaf203bdf186daab82974347c617e1210a586751ec6c9818185d0a096e3f</span></span> <span class="giallo-l"><span>00209,</span><span class="z-keyword">0xc1041285ee311030789717024ad66718f6184a03a0d31a1ce4ccb0948fa17dc5</span></span> <span class="giallo-l"><span>00210,</span><span class="z-keyword">0x1eb673abfb14d61c67d81d48dad2b7f72080a90fe090b6846779fb78046402ff</span></span> <span class="giallo-l"><span>00211,</span><span class="z-keyword">0x01e5a4d0cf29ec996c00f168d445f55eb3552f213200a247c4efd60d4fceede4</span></span> <span class="giallo-l"><span>00212,</span><span class="z-keyword">0x83c3bb0ad1f3784c92a88909ab533c62dd5e7b3dcacbaf624ae95ee12022eb11</span></span> <span class="giallo-l"><span>00213,</span><span class="z-keyword">0x9a09fe68cd5dcdc15ea76f08eac7e2a679075e772064354c747b75e5ddca8d2f</span></span> <span class="giallo-l"><span>00214,</span><span class="z-keyword">0x9e78dc12bf0023bdf0c8c1b8e7f7c6e5a92d66b56475594bfa334c129df58735</span></span> <span class="giallo-l"><span>00215,</span><span class="z-keyword">0xb02bf96a7443e246b6733270453b35a70ff1fcf49375cedc97338614ac65ac51</span></span> <span class="giallo-l"><span>00216,</span><span class="z-keyword">0x209c8b324d31fd9d8c8c4cf26f6506657608e6816471fe522adb1425b5ebd04d</span></span> <span class="giallo-l"><span>00217,</span><span class="z-keyword">0x6c84f49aa1ae7943df31f340739b2b63df7476e87cf0ddf82862982456865c95</span></span> <span class="giallo-l"><span>00218,</span><span class="z-keyword">0xacb60f14bf4bdc96ce579f02f62f8bb35db16f03dde7329363bb50388c3c45b0</span></span> <span class="giallo-l"><span>00219,</span><span class="z-keyword">0x0a773645ba0627df6df44158e292f2f226ca74bbc90464ec4796ac2e9bf26578</span></span> <span class="giallo-l"><span>00220,</span><span class="z-keyword">0x76ed2324a565e51cf2a82bd0cdb025f255caf25d61396d4da19d708c40adcf92</span></span> <span class="giallo-l"><span>00221,</span><span class="z-keyword">0x76ddd2d829c12483b2ffec2c587557bc5972e08dc8866708a2d44a31575483d2</span></span> <span class="giallo-l"><span>00222,</span><span class="z-keyword">0x71e986b22213ce63d0e3df141581fca8fbfc41569f0bcd62c101c67cb00295b3</span></span> <span class="giallo-l"><span>00223,</span><span class="z-keyword">0xca2b5c289ff78be184a6cea0f072aa71cfe0977f18bbcca536b48938e5d64276</span></span> <span class="giallo-l"><span>00224,</span><span class="z-keyword">0xff571e13e54cdc9ca6facd7012051ee787bee1c52a555653fd969751bfaac7f2</span></span> <span class="giallo-l"><span>00225,</span><span class="z-keyword">0x1cfe32398c41e4ecdde6cff7b2df6f9f2651ee87aae1b52bc35e4d76f136c3a0</span></span> <span class="giallo-l"><span>00226,</span><span class="z-keyword">0xb0eb8f2f68728e48a4ded02891b9a682f7c925099e899c26143083850b3f2829</span></span> <span class="giallo-l"><span>00227,</span><span class="z-keyword">0x83556e9f3d0e05c0d4cd809cf1bcad1557bfeae027ac4de16e6956596e8309fc</span></span> <span class="giallo-l"><span>00228,</span><span class="z-keyword">0x7651e7fbd8326e549f9af9122585f517c4f59ab6e735cd958888fb6f80f29db3</span></span> <span class="giallo-l"><span>00229,</span><span class="z-keyword">0x238ed7884113c0356cf4e5ef35e05434d3e076428884b93bbb873ac30afef54d</span></span> <span class="giallo-l"><span>00230,</span><span class="z-keyword">0x3826affaf4ebf5817b453c54c937951770c19ddb7900c9a7742919c24242f6b0</span></span> <span class="giallo-l"><span>00231,</span><span class="z-keyword">0xb81f93c6179db089673e919d91660274e96f240a699a12a140185c69ac19b674</span></span> <span class="giallo-l"><span>00232,</span><span class="z-keyword">0x0cda2a75d5dd4059a2e5712ac7cb151f033b700995e93c0819f38cb01b7f005e</span></span> <span class="giallo-l"><span>00233,</span><span class="z-keyword">0xb183167b3a03238701597a198475ccec1308e2c55babbe5d5acb92fcd694fa21</span></span> <span class="giallo-l"><span>00234,</span><span class="z-keyword">0x4a88300d556d8a8d66669f2d2b395263ded44d9a86bd45b3b426a55f7da8eb22</span></span> <span class="giallo-l"><span>00235,</span><span class="z-keyword">0x05ef61436ee159233c382043f0a9e99d34ed88a0bf3c12244f546b7b861b9f5f</span></span> <span class="giallo-l"><span>00236,</span><span class="z-keyword">0x4164fdf451a7134e2faa3672aa40a0168e2a16895020c0cd5632322793fc96d1</span></span> <span class="giallo-l"><span>00237,</span><span class="z-keyword">0xd5c9eed4c1796793e8595d155187444376f4b5478ea5ff1804f1ba06bd328506</span></span> <span class="giallo-l"><span>00238,</span><span class="z-keyword">0xdb0d90c5045dec94b87c81a03fb985a6fb84e1debb372b56c2513f25d4a2d8f8</span></span> <span class="giallo-l"><span>00239,</span><span class="z-keyword">0xa0c972ed0270d34b19b803a74649470307f138ef0567df85ef53a862b383dbdd</span></span> <span class="giallo-l"><span>00240,</span><span class="z-keyword">0x9cc1a86a28230bad01981b644067885e0333588976edef464aac674744c9eed9</span></span> <span class="giallo-l"><span>00241,</span><span class="z-keyword">0x8ab5ad435e4c9a37815b47344d282c90a3f364d516374b4b2158cf16148d79de</span></span> <span class="giallo-l"><span>00242,</span><span class="z-keyword">0x491f232e15a8a44b1f045dc68552543672c6d3bff361a5fecd7c0a54c1f21d2f</span></span> <span class="giallo-l"><span>00243,</span><span class="z-keyword">0xf66eb348a6b9dd916baf6bbab3299c57b9d95e5bfb585893f2953209c2c451e8</span></span> <span class="giallo-l"><span>00244,</span><span class="z-keyword">0x7b141f131b2878edbef5e71682051e3082490e755502c0372e5ace9cb5ea3d5b</span></span> <span class="giallo-l"><span>00245,</span><span class="z-keyword">0xef5b96a583318ef2d24bde313396aa09dd5d102cbd270b95c036bc6db98349a5</span></span> <span class="giallo-l"><span>00246,</span><span class="z-keyword">0x32d63aa14065862ce43f33e578625a2892710dd11025a9299f8722421c625874</span></span> <span class="giallo-l"><span>00247,</span><span class="z-keyword">0x7b033a6c76470c8b7b953161d562fe30c90705672f950a176de70a6aa5f1b130</span></span> <span class="giallo-l"><span>00248,</span><span class="z-keyword">0x50916052436d167fa83998749a703038ddb08d7cc789c276099235f9af28a613</span></span> <span class="giallo-l"><span>00249,</span><span class="z-keyword">0x75e0db34d48e90e80705be01c100e3767aa3302d4269a00f4c944069ea451ccf</span></span> <span class="giallo-l"><span>00250,</span><span class="z-keyword">0x4781ac7f896d2a547f2a973fdd352d5e9efb019939bd10ab31f0f84887968831</span></span> <span class="giallo-l"><span>00251,</span><span class="z-keyword">0xc0f8b33bf4828ab6578b5312d922b37139bf9c1d0eddd973f5ee84b39af48a28</span></span> <span class="giallo-l"><span>00252,</span><span class="z-keyword">0xafa72ca222af4feacee96c6a64a4b05a1fe464f9ed48e93e13cdb096d0147d25</span></span> <span class="giallo-l"><span>00253,</span><span class="z-keyword">0x96c6ccb34878fb040117b6933c7d7f1ca4f534dc63ab86d2cc4914b06786331a</span></span> <span class="giallo-l"><span>00254,</span><span class="z-keyword">0x7b32050e8240cfbf7ab11e4b06647d363c83aafa32d78cf34460b335d0e55a3c</span></span> <span class="giallo-l"><span>00255,</span><span class="z-keyword">0x16317cf915089e0c7cc1afb35540a004fa2c79e75f4410dbd89e6d9fdb2b89e1</span></span> <span class="giallo-l"><span>00256,</span><span class="z-keyword">0xb4ccb50be9c8f0759450e6dd9d05cb16778cc2852c0f8aaaeaa118a45267891b</span></span> <span class="giallo-l"><span>00257,</span><span class="z-keyword">0x98808d165ea3e628d92a93cfb1081e68254c4e2a48eea8c1cb3771772ee0fa74</span></span> <span class="giallo-l"><span>00258,</span><span class="z-keyword">0x3cf61b1ca697e63092bcbaafad3cf25608f47a9b6563bf8dc1720eb2a7fbe384</span></span> <span class="giallo-l"><span>00259,</span><span class="z-keyword">0x051764d24d14c62f71e8df8e9eda01d4edba8a9a52cf50ed50dce0d06f33bbeb</span></span> <span class="giallo-l"><span>00260,</span><span class="z-keyword">0x3b0545e8512ad0ef40623a237e1461577102fb2d6aa820dc0a9420d62f1a5942</span></span> <span class="giallo-l"><span>00261,</span><span class="z-keyword">0xa6f4bfcafda2d4cfc8bc900a5f844d60a50822aff332f7aadec3157b12a8d1ba</span></span> <span class="giallo-l"><span>00262,</span><span class="z-keyword">0x1a75662f7da5af8abe9f73deddfdbc4fa23772f28a2968eb44dab1e413238841</span></span> <span class="giallo-l"><span>00263,</span><span class="z-keyword">0x21bf7eeeff2979facb0c0a59ebfe07e4f110c9f7417217a341039ae2deb4c6d7</span></span> <span class="giallo-l"><span>00264,</span><span class="z-keyword">0xd41eb83d2e64d9928f6c18e95060bca40c3226b4982f91dc97a518201aac8fb2</span></span> <span class="giallo-l"><span>00265,</span><span class="z-keyword">0xe7a1956113e4b4c440a7ca46855ad2d2705ee3c018770e3fa8f8a3b3a6b6d6a9</span></span> <span class="giallo-l"><span>00266,</span><span class="z-keyword">0x4f172aab43c6bec97adf68392b12e82b4512ebc52df0298ce3253672fe59135b</span></span> <span class="giallo-l"><span>00267,</span><span class="z-keyword">0x7c0e1bcfc2aaa6ae002a1bc3fe0ed288598013b4c0dbce889d4b41cc8f1c792b</span></span> <span class="giallo-l"><span>00268,</span><span class="z-keyword">0xc839e6d47fa99f7bab58ca9eea51d6306873f67fd286ddeca8348a09c773cc42</span></span> <span class="giallo-l"><span>00269,</span><span class="z-keyword">0x9ec52dfb6facec401f848cee38bd6eda4e3429291939754a4985eb8ae969787d</span></span> <span class="giallo-l"><span>00270,</span><span class="z-keyword">0x4e8bc7277defdbc8c904f780c9b6f82c214816b5379e95490c7f0052a7295465</span></span> <span class="giallo-l"><span>00271,</span><span class="z-keyword">0x5294c75dc9cdf4c43f683b6c02c9078852607faf9dec990339b74476e0c0108b</span></span> <span class="giallo-l"><span>00272,</span><span class="z-keyword">0x02a11db25d807b03efafe32a0ee0647b35d47506a7fac186bb51e3c3a77a5655</span></span> <span class="giallo-l"><span>00273,</span><span class="z-keyword">0xd81a2c4138adf6e8b1af325a9a0b08ce6a0b3b72a79b367118294bafb4b832e9</span></span> <span class="giallo-l"><span>00274,</span><span class="z-keyword">0x9c4bd87dc1b25b83302973a9c4223cda44c1200ea2a83106463adf6317bdc605</span></span> <span class="giallo-l"><span>00275,</span><span class="z-keyword">0x85b9c67dc6b5b7c0014824f8b1909633459cd0b8e1584753064f85e1a1243c8a</span></span> <span class="giallo-l"><span>00276,</span><span class="z-keyword">0x38cc12366c2a7d559e4df0705bb822d8d0db59221de71477dfcab90e317b2e97</span></span> <span class="giallo-l"><span>00277,</span><span class="z-keyword">0x40c70f952d1ecfafbd064b1367045570b703fdbc7059cc7f9194ed34794d1db6</span></span> <span class="giallo-l"><span>00278,</span><span class="z-keyword">0xd9e0d7381580a9f3fa81e7a8f582967f09e1e87f0e4c5d08221edf0434053608</span></span> <span class="giallo-l"><span>00279,</span><span class="z-keyword">0xd20a7b7f9138afec7ab17bcc1fa4d77571d78f12bac193db64cbe046d0bcd1e6</span></span> <span class="giallo-l"><span>00280,</span><span class="z-keyword">0x54a85faaf00ddd99bf86faab4ddbd028b8d3f4e8f4492d1c7160aad9a03db638</span></span> <span class="giallo-l"><span>00281,</span><span class="z-keyword">0xf08b974956e8b7c14b335bf82add248bdf06a9626ecd6627ae0cc523359cad9f</span></span> <span class="giallo-l"><span>00282,</span><span class="z-keyword">0xa5912776593b35ee8dbca404e0c36497dc410062c0e5f4c6b40923232b17a8ab</span></span> <span class="giallo-l"><span>00283,</span><span class="z-keyword">0x8ee7ec35fab36575d9e5105303fa547ca8a03b6ecf731cbb64b9823250323d25</span></span> <span class="giallo-l"><span>00284,</span><span class="z-keyword">0x374996f2ff5de9c6262168bc93fe7548bc6cb94d45dd4dcce211a9be677ddcfd</span></span> <span class="giallo-l"><span>00285,</span><span class="z-keyword">0x9494258571f7dda74ed018ffed536e412f5272028442ce932677668613278035</span></span> <span class="giallo-l"><span>00286,</span><span class="z-keyword">0x6d47a23492f0ec9831f3536b4b542b1addaa041ab9f9cb6d2f6821a5f9ed6646</span></span> <span class="giallo-l"><span>00287,</span><span class="z-keyword">0xf9804151a4dbbe0c86e08b2109fc328a287ea4ac10abfbe01a9bcc866e7422b5</span></span> <span class="giallo-l"><span>00288,</span><span class="z-keyword">0x3724a8c948c728a89eb03af19c3be5e7e26abde6713e6e9ab5559dd21f8e095e</span></span> <span class="giallo-l"><span>00289,</span><span class="z-keyword">0x60d72bd902aef520fa3a0fd618cc230a50c8cd3951042f5a613b3d45f0b94c6d</span></span> <span class="giallo-l"><span>00290,</span><span class="z-keyword">0x64cca80b0eb18b315b2213ad5e2b53dfcbb1141ffa422ad46e7cb3586a200aeb</span></span> <span class="giallo-l"><span>00291,</span><span class="z-keyword">0x0dfa92f2d0ff334ed8306b33e6d3325720cc13aa0f046d53a2de144d89b9af92</span></span> <span class="giallo-l"><span>00292,</span><span class="z-keyword">0x9490598864a1e3ce2241136637de020cf275921f59545dbc4ecf4cf87f678b84</span></span> <span class="giallo-l"><span>00293,</span><span class="z-keyword">0x0d6c5812bd1b877d8715198580c66eab1ddaa78e1dc350e70eba0d59e633cf30</span></span> <span class="giallo-l"><span>00294,</span><span class="z-keyword">0xf6c5c94a2006aa624d007104ed8debbb32ec15423382e4759bc7a16a1357d5ed</span></span> <span class="giallo-l"><span>00295,</span><span class="z-keyword">0x4efa78d05a58e9b1e633443b058c9f8d447728e0ad64a50332f848199f8a4253</span></span> <span class="giallo-l"><span>00296,</span><span class="z-keyword">0x81c1446a12d42c3ce40f4a99326cf8e5a306ab72c773ac26f63a63cbe0a58064</span></span> <span class="giallo-l"><span>00297,</span><span class="z-keyword">0x08d13a3189fb2e18636d6beadbc137a79d03d9278c60f80829443348b8c560a4</span></span> <span class="giallo-l"><span>00298,</span><span class="z-keyword">0x3d1d6d89bcfb495fccee7bb0bd8f04715d84abe14f94fb36f870e5606c2cdf18</span></span> <span class="giallo-l"><span>00299,</span><span class="z-keyword">0x23728d43eeafdcff8f761c5a53e3f9373d25d17efb28347a91938484e03d07cf</span></span> <span class="giallo-l"><span>00300,</span><span class="z-keyword">0xde0332534e50154c9eac98068e56da4508d82ecf24ca3a275aeef3dee99b95e0</span></span> <span class="giallo-l"><span>00301,</span><span class="z-keyword">0x15a24df990de83affd9aa7cd9e67f4c558e1b3f306a6281385cc2e6409b9793a</span></span> <span class="giallo-l"><span>00302,</span><span class="z-keyword">0xba653536adb3464fdd46fe741d7daa1514a84f7555bf7ed91cb4d3bddc0a6f1b</span></span> <span class="giallo-l"><span>00303,</span><span class="z-keyword">0x35fde006dd9552f56250125ce80ad21476daf78f8727b432cdb370372c161a65</span></span> <span class="giallo-l"><span>00304,</span><span class="z-keyword">0x377bf395fc2a3ef98595766247a1c057a05d5fd3629bfd27d0bede0c6183a7f1</span></span> <span class="giallo-l"><span>00305,</span><span class="z-keyword">0x340a0b81056d5170e635ef43d952b8ec4ff7f3d5cf4ea1469750448d78f3e501</span></span> <span class="giallo-l"><span>00306,</span><span class="z-keyword">0x848e3d92711946156cd7c848947d2ba4ee4c0b39087ea30c90eb1e64f8aba773</span></span> <span class="giallo-l"><span>00307,</span><span class="z-keyword">0xa3ff791642f87c2bffb269a1da3d8e943a1828cafe10ea7a483a508f78ab54e6</span></span> <span class="giallo-l"><span>00308,</span><span class="z-keyword">0x48c7160cbf3a38ea7299edf971711e9d6875969dd38ce2086763389d9fac048c</span></span> <span class="giallo-l"><span>00309,</span><span class="z-keyword">0xe7948131b78ed9f05c0e18ff0497a192aaf8c5d3c1a56e1096570b3b45117253</span></span> <span class="giallo-l"><span>00310,</span><span class="z-keyword">0xdb22eaaf717a1a827a085d3960e2a477a2e9a73584bc4a293377ac50a492350f</span></span> <span class="giallo-l"><span>00311,</span><span class="z-keyword">0xf9e4fff98d04206dd4004f5ec146e676327dc8399dff7c7eb61d1d80f706d3ea</span></span> <span class="giallo-l"><span>00312,</span><span class="z-keyword">0xd95903d02e93dc935ce569153d9c88680972dd5e9156dc0a7f4da9a3435ff004</span></span> <span class="giallo-l"><span>00313,</span><span class="z-keyword">0x73f91876f19025335210705149eac61825673f8698bcf5aae285c00051fd6f6c</span></span> <span class="giallo-l"><span>00314,</span><span class="z-keyword">0x8e3397949f833d550ca3a268befa4c48c238f488572b2512f8cb5232d78dde24</span></span> <span class="giallo-l"><span>00315,</span><span class="z-keyword">0xe83123f07d6e146998f885c5c4f71988f472b9769e9c731d421327f3f4add351</span></span> <span class="giallo-l"><span>00316,</span><span class="z-keyword">0xe49c7af7a328992fb98e65057e28326f3684f84293a6b9825ef8297fb361a186</span></span> <span class="giallo-l"><span>00317,</span><span class="z-keyword">0xf3ae6a628ac464fc0f14f4654dedf31ab553c9750bbbc801e395ac858bbb619f</span></span> <span class="giallo-l"><span>00318,</span><span class="z-keyword">0x4bf5c84ae3ef17b5fb6455380d4708dba2da9c9224c4a31a0cb14ed4e8eb17f0</span></span> <span class="giallo-l"><span>00319,</span><span class="z-keyword">0x391837c44adbebf55ee138d56c65353612b31c66f1cc02663b7f088b80dde22f</span></span> <span class="giallo-l"><span>00320,</span><span class="z-keyword">0xbfd4677eb2bd0210ee172956700adfcf8b5164982b533a191907f62ac3f6ae1e</span></span> <span class="giallo-l"><span>00321,</span><span class="z-keyword">0x7189f4963254c00f349ebdb7f507638472c13e083cc525be744de2ce8374e1e9</span></span> <span class="giallo-l"><span>00322,</span><span class="z-keyword">0x344663aa7240ee9c312f31e5111dcb672451ef971ec1375fb8a298c676738c7f</span></span> <span class="giallo-l"><span>00323,</span><span class="z-keyword">0xe111bfc2e481e928c91b0d0a5868221c8699e22fbe87852b3bedb3124072659a</span></span> <span class="giallo-l"><span>00324,</span><span class="z-keyword">0xbe2b4b22f7c8c897ba0731eb6342e075c338b8feb2791c31be1d20c6c47f167d</span></span> <span class="giallo-l"><span>00325,</span><span class="z-keyword">0x441fdc4402e5b407058b634523f6318e2b6ac078414720bda9466129896e19c4</span></span> <span class="giallo-l"><span>00326,</span><span class="z-keyword">0x4297936031236c915aed0b391555294f1df7b346889ca02edd1313b8fbd73298</span></span> <span class="giallo-l"><span>00327,</span><span class="z-keyword">0x820afe74538d0b05b98e1d16604fb60bca79f04c56fa724e6d2af5532a5b45e1</span></span> <span class="giallo-l"><span>00328,</span><span class="z-keyword">0x08665862041221b6d297f4e7619b1044eadbdb92ec1415e916e9bc78558aafca</span></span> <span class="giallo-l"><span>00329,</span><span class="z-keyword">0xcc85d0d955b9068c848b56435b53e7eef8d2a1266cfd92c46544594a1b7c06fc</span></span> <span class="giallo-l"><span>00330,</span><span class="z-keyword">0x8ffabe96ffed7125caf2395331a37eeeaa016c1fbd0af6ddbaaeaa4ce3a75428</span></span> <span class="giallo-l"><span>00331,</span><span class="z-keyword">0x57c9aa448a060ee1cbe8a7b5236ef301c090d29baa0f644ccb23661b7933b4df</span></span> <span class="giallo-l"><span>00332,</span><span class="z-keyword">0x3135b7344e51ce37b6f82ad0e1ab5dde01a7cbf154ec76ae394c6e99fa866e68</span></span> <span class="giallo-l"><span>00333,</span><span class="z-keyword">0xef368f009534af83848b1ad36c874d1cd28cbf792663db122dd8f7f123506966</span></span> <span class="giallo-l"><span>00334,</span><span class="z-keyword">0x1c3457cf9b7bde27ad51086fb1ea494d78e82217cf2477f79ac8fc4cfa610f25</span></span> <span class="giallo-l"><span>00335,</span><span class="z-keyword">0xb191a95efc41af23eaf794aea75d4b4c9308a85647f6793201533b30b3d9d368</span></span> <span class="giallo-l"><span>00336,</span><span class="z-keyword">0xb5318d5c8c6f173084a7d838110e3e3de8739123b4ec387658c0b579cb87fcec</span></span> <span class="giallo-l"><span>00337,</span><span class="z-keyword">0xa84d51fe94498ad9c2f558ad6fe685d9aa73ef5ab52c794861277e690ff27d65</span></span> <span class="giallo-l"><span>00338,</span><span class="z-keyword">0xf0b5744f941d4eea8fa255edaa9f7af5028da4900c7fd0b2a1214b00c33f96fb</span></span> <span class="giallo-l"><span>00339,</span><span class="z-keyword">0x5a637c4c3cebacbb0caf5c8bb9080288270e8f2ad3106e50ce82a65bc27386a5</span></span> <span class="giallo-l"><span>00340,</span><span class="z-keyword">0x6bd16b95991a8cfb3671511c673093106b4aa7d626edd4558bc58ca67f8054c1</span></span> <span class="giallo-l"><span>00341,</span><span class="z-keyword">0xe0d9d5cba01b6dc8c430de66d0503e58b9be6195e7a767fc26e15277af7a08fa</span></span> <span class="giallo-l"><span>00342,</span><span class="z-keyword">0x203bc599777747671b50d1ddcc78edc4a180537d2e6fe14610426772d1caf926</span></span> <span class="giallo-l"><span>00343,</span><span class="z-keyword">0xa668f92ec27ced688ad1ce7eeb4f437996bdc213ab001f5d548f5e283f243754</span></span> <span class="giallo-l"><span>00344,</span><span class="z-keyword">0x9cfd6013d6c92d918e19c4b6118dcf5d73e9070af0c7300f8db0ccc7fef5e89a</span></span> <span class="giallo-l"><span>00345,</span><span class="z-keyword">0x54595ee743dc095ed8c3a82f1c0ae34ab2ef7ebb494286a990be0f6b9e85e6a8</span></span> <span class="giallo-l"><span>00346,</span><span class="z-keyword">0x2297e35e02ef969b43a787aa88feb7e101a21fb5d73a81af1c4bc06c57a7c3bf</span></span> <span class="giallo-l"><span>00347,</span><span class="z-keyword">0xdb8912b310472c79894387c19d79d84113709d05057c043380ec4ad8145991fc</span></span> <span class="giallo-l"><span>00348,</span><span class="z-keyword">0x1dde5ab9d554e74a5635f8042ccee5454b215eb598cfbf696a74a459fc1ec87f</span></span> <span class="giallo-l"><span>00349,</span><span class="z-keyword">0x7e25d7fe6b0e71c03d401537f46ea1628e91513cc3991171227d6ec165058e2e</span></span> <span class="giallo-l"><span>00350,</span><span class="z-keyword">0x2bce5715759f8e6f9f17a735408e410f9965ac3cfd27e2c710060f3778d662b2</span></span> <span class="giallo-l"><span>00351,</span><span class="z-keyword">0x112b61e1ad4e349919eadac971bb9128d385eb3f51668b2895cb978f148a83f2</span></span> <span class="giallo-l"><span>00352,</span><span class="z-keyword">0x2ffd764d428f87651d62f1a1113874042f1c77dee8b999524e896663e1a0e000</span></span> <span class="giallo-l"><span>00353,</span><span class="z-keyword">0x8d5ed81a06d6bb19866099c16d80a7dfe3ebf9c642236410a5f3f491fabab7b8</span></span> <span class="giallo-l"><span>00354,</span><span class="z-keyword">0x78c57cc6fa8c8eaee7bef3b0573faacf9a42783f39c9a307a3cebd4a66a56e37</span></span> <span class="giallo-l"><span>00355,</span><span class="z-keyword">0x55973475ad5f1404bca12aec3688d80cb5881796a9d0a9a917245f8ed9bed47b</span></span> <span class="giallo-l"><span>00356,</span><span class="z-keyword">0xc7493a6e7fcfb05ceb9f11b9af843556bea9f87883a2ee21ee76cbbb769204fb</span></span> <span class="giallo-l"><span>00357,</span><span class="z-keyword">0xe5dd91711b000ce8cd41d02ec760a50625f924fcf7a095353f6965322881fb94</span></span> <span class="giallo-l"><span>00358,</span><span class="z-keyword">0x60ed8451fe763621afb94803cbec04b48e9ab83c8d05e2ec1524e623dbe0decb</span></span> <span class="giallo-l"><span>00359,</span><span class="z-keyword">0xeeb9573da28cde717ede462163188da0c184c4aa61e166e9bc4ee047fa0c170b</span></span> <span class="giallo-l"><span>00360,</span><span class="z-keyword">0x277ba2fed1fae84aa2b23a43872100f00b7699326a22df5679115b1dd88c5206</span></span> <span class="giallo-l"><span>00361,</span><span class="z-keyword">0xfc97c47f7bf57fce450809d63a32e255db170aa3fbc94c88d9b15a09f22e2f8f</span></span> <span class="giallo-l"><span>00362,</span><span class="z-keyword">0x77f810e72a7d1aa4a164ba9f7bf0164b6f14842dda65d584508d7f403942c319</span></span> <span class="giallo-l"><span>00363,</span><span class="z-keyword">0x056ef66ff214f7a777abda23d7c32c1ed17e2d25f3e5e4299e11c22412bfb1df</span></span> <span class="giallo-l"><span>00364,</span><span class="z-keyword">0x374faafad27fc139a45b9a73cb5957de978227d494de6cbe4d9bb4d48fc26197</span></span> <span class="giallo-l"><span>00365,</span><span class="z-keyword">0xa959566e36f4790873b779f74d0b31b5c08b4177e844e430fee9c33c190839c2</span></span> <span class="giallo-l"><span>00366,</span><span class="z-keyword">0x905c4a521e63de87fdd413379e245a1c8c2aafd1cf92e5ed6394892a635e62a9</span></span> <span class="giallo-l"><span>00367,</span><span class="z-keyword">0xed4e7dab8d5ac5eb9d4e3b711be5a5074eaceee1936455fc145362871d64faae</span></span> <span class="giallo-l"><span>00368,</span><span class="z-keyword">0xb4a84335f5900e1df9ffd45af119abb6808b69960359257826702a0792dbb9c9</span></span> <span class="giallo-l"><span>00369,</span><span class="z-keyword">0x1f3be8331532a43391f286dce1908e750c2c1db4f40e04240df8a49b15077ffe</span></span> <span class="giallo-l"><span>00370,</span><span class="z-keyword">0xccf6672e6da5a00cd8ce25a1dcd7ac9701d10e13db51b249cec8a168fbc1fad3</span></span> <span class="giallo-l"><span>00371,</span><span class="z-keyword">0x1aa762ac08985e6a081e59742827fdcaa0194f37db5a03574bea395a548c1ae8</span></span> <span class="giallo-l"><span>00372,</span><span class="z-keyword">0x05d7f23c6cb10f2e5ea143504193e0c18799879225cc7bb9f548c2a7bca406a5</span></span> <span class="giallo-l"><span>00373,</span><span class="z-keyword">0x9a8322055f128164d9b1ae8be520dabd5aa9a78e6b38887d2d0ef1c29f8fe5fb</span></span> <span class="giallo-l"><span>00374,</span><span class="z-keyword">0xdab73b8e1681ad78f5948c11596f320dc9e37833a372a4bb75131ae27144789d</span></span> <span class="giallo-l"><span>00375,</span><span class="z-keyword">0xe97d6f9f8cf09791cfa7d844116e30f30c0c25a010500db0721e1a0794a0f0bd</span></span> <span class="giallo-l"><span>00376,</span><span class="z-keyword">0x6af73957e98a3366086abd58c1d750803706d7bc3ae2bbbab4eb6030d58cb244</span></span> <span class="giallo-l"><span>00377,</span><span class="z-keyword">0xfa0bd020aa5cff144e0c34ec5a67a63cd593c607905dfd7a8697796a7641385d</span></span> <span class="giallo-l"><span>00378,</span><span class="z-keyword">0x85b101eb40a52a559a3bffc4667c2fa220ad9cacca9a34c62c684e87cafa5e56</span></span> <span class="giallo-l"><span>00379,</span><span class="z-keyword">0xfbe01c0b7b7e3e3434a5a4723c3619f544c6fc91324421172c74b3aceb816f39</span></span> <span class="giallo-l"><span>00380,</span><span class="z-keyword">0x3e90265a2de6ab0f66324c687364be3c3a4bf46b96fb5dedc4da99c2a59c66f2</span></span> <span class="giallo-l"><span>00381,</span><span class="z-keyword">0x0b316492b1f48b2a578bf289dbfdcfeccc756410f0260e2b14b8b2bf972ab173</span></span> <span class="giallo-l"><span>00382,</span><span class="z-keyword">0xa02e585dc76ee230753d64e6f49d31f6c785e03834bba8acc2fe3f97b2b0de67</span></span> <span class="giallo-l"><span>00383,</span><span class="z-keyword">0x2198573b3c6f4e37218236277eb87d39d60646c6a46b7f516de4ee75f7eb57cd</span></span> <span class="giallo-l"><span>00384,</span><span class="z-keyword">0x0c367f630c9a45d6320139277a8d2f880118a31a856daea875c5a095986f50fa</span></span> <span class="giallo-l"><span>00385,</span><span class="z-keyword">0x8893c8da5a5e2df4e794962fd80bf6d4b8785de5ec445115f1851f601d92afc0</span></span> <span class="giallo-l"><span>00386,</span><span class="z-keyword">0x30637c5e41cbd7671b1b2744d5abde33576904c2fb999de2262dde69d552b4e5</span></span> <span class="giallo-l"><span>00387,</span><span class="z-keyword">0x069b5e283383b315d1a151162386e05161a9ae0704c2b5d3162d18fe91445c14</span></span> <span class="giallo-l"><span>00388,</span><span class="z-keyword">0x82890633807a55f66db32bbfbc7eddec26666cf69d927c6ec17d3e52839f3d3e</span></span> <span class="giallo-l"><span>00389,</span><span class="z-keyword">0xdef916eb755fd6d271775e79079003b9851e520c744dc2fc544599069a2f9a2b</span></span> <span class="giallo-l"><span>00390,</span><span class="z-keyword">0x00f646779628de768f0a78b66f79310092a7eed1b1f42d871bc14945b31c4dab</span></span> <span class="giallo-l"><span>00391,</span><span class="z-keyword">0x6055482350dcadf13a115468db04f05b533177f9cb92ce0d1174e80cf72ffe92</span></span> <span class="giallo-l"><span>00392,</span><span class="z-keyword">0x01eb08ec62a30cb0bc16493c077396adcf2921cf45e7fe07f8ad8a9eb3cb2486</span></span> <span class="giallo-l"><span>00393,</span><span class="z-keyword">0xa5b5b2ed61c5a22e51f28e7081d3c57657bfe1ee7ca90ba380e21b0c29bb871d</span></span> <span class="giallo-l"><span>00394,</span><span class="z-keyword">0xc96f2c65a9b708e26fb06146840df2ba2fee86811fc64b8b03cb8da0e864cf21</span></span> <span class="giallo-l"><span>00395,</span><span class="z-keyword">0xc7c791690e0a24e565ad4325f0916eacd1472c5c67ed9d08007f519ab5ea4751</span></span> <span class="giallo-l"><span>00396,</span><span class="z-keyword">0x98f01c73bc56a14d597f9a2fc522c1f9ce473d5aebcf9f025bf85e10ab5e69b2</span></span> <span class="giallo-l"><span>00397,</span><span class="z-keyword">0xece428f5e482195f4fc650d8ba4535cdc50da4bbd6daff83dabf40f0fc1cb264</span></span> <span class="giallo-l"><span>00398,</span><span class="z-keyword">0x15d52476e016b06a31965a6f867703d8e72de4d75952ea588619e24d16946860</span></span> <span class="giallo-l"><span>00399,</span><span class="z-keyword">0x07f402789b0a04c5c653605ae4a4d9b538575eb278790ee1fca13e1f47aa85a4</span></span> <span class="giallo-l"><span>00400,</span><span class="z-keyword">0x837a78da3c31e197110da75373e9161ec3630eac20956d4976bfdfe5a3f76705</span></span> <span class="giallo-l"><span>00401,</span><span class="z-keyword">0xf319bb85477c7540c8296e257ae3e9887477cc5ce6615e79ff465e67447ef449</span></span> <span class="giallo-l"><span>00402,</span><span class="z-keyword">0x28918ded462955d7564a1cf7515dcde37e47a0bf649af47ce19c1bd2f42420f2</span></span> <span class="giallo-l"><span>00403,</span><span class="z-keyword">0x8d3e10d5ddb059e88145c8a640d6f435b50abf014464ef4112bb7153172e8712</span></span> <span class="giallo-l"><span>00404,</span><span class="z-keyword">0x729d063ef003bc0cd25960f423adc378a96f94bf330e2894980e229c7f792827</span></span> <span class="giallo-l"><span>00405,</span><span class="z-keyword">0x3857def7fbba5ea6f0330f98e7810ff7efec3dec752c7a72961925ebb55935ab</span></span> <span class="giallo-l"><span>00406,</span><span class="z-keyword">0x7be7d5cd302192b0891e799f7fd3dc6214225bac396740ca00eab0987afa0e15</span></span> <span class="giallo-l"><span>00407,</span><span class="z-keyword">0x0a5da5b2bd5353f6dfccb3173ffc30d765f1abae1eb3fe1a2ba70a4c9e69144c</span></span> <span class="giallo-l"><span>00408,</span><span class="z-keyword">0x4ef48eb40d14a101421b182a44e62e46058b24a968731f9672658c2998359339</span></span> <span class="giallo-l"><span>00409,</span><span class="z-keyword">0xe4148ff741b9ad3ceebc501e8db8796f923b39918bc4e003164b490a0b61d9a7</span></span> <span class="giallo-l"><span>00410,</span><span class="z-keyword">0xb195d1d07cd0b541bde741b4086345048fc40eba5c36958db1e84b72f813f9ce</span></span> <span class="giallo-l"><span>00411,</span><span class="z-keyword">0xab2766df14efa74b0e28bb35708e39d6b1ca1d0bca5a94ef65b5aedfb53bb200</span></span> <span class="giallo-l"><span>00412,</span><span class="z-keyword">0x4fcf3d8ce7b02562b9f72decca131bda4095b44bff685e901c1a5b5d29ad1bdb</span></span> <span class="giallo-l"><span>00413,</span><span class="z-keyword">0x371970b092f836d650467a8ce9b049da8e286f73b4ef1063380be6ec1c07622a</span></span> <span class="giallo-l"><span>00414,</span><span class="z-keyword">0x7525f2eda283e525441c353da10bdc982c0b1ff04dea2c153b3543fdad000b73</span></span> <span class="giallo-l"><span>00415,</span><span class="z-keyword">0x4820498a2f344d87b28241909d366f5be00766e75b23645c45a09c75ec8dfdb4</span></span> <span class="giallo-l"><span>00416,</span><span class="z-keyword">0x55dcafa7fd60cb0110e64c6d5cc69db5f031a572e110368f9067151b0890a0f6</span></span> <span class="giallo-l"><span>00417,</span><span class="z-keyword">0x9a836ceab0f6c37b3523b9df29cd0434d420819221ef1063600765b3ca5f522f</span></span> <span class="giallo-l"><span>00418,</span><span class="z-keyword">0xc524844779cb06e98494028130b971a762f7e249dd1d79e08acfc33d7927aae8</span></span> <span class="giallo-l"><span>00419,</span><span class="z-keyword">0xaa00e84454c9ec2852bedc300676f8d20bda558c13442ec8b9a148fbe5d37098</span></span> <span class="giallo-l"><span>00420,</span><span class="z-keyword">0x1a718263b17245356ffb42bb178e9590283ea2e0a82ff52dab5f904da8951895</span></span> <span class="giallo-l"><span>00421,</span><span class="z-keyword">0xb7a7719554eabde85fa9f5bac7580c6f352f60a460f9a07fbe87fff47ba7c19d</span></span> <span class="giallo-l"><span>00422,</span><span class="z-keyword">0x05e01b82ba2d8b2fda2a7e149186ae56e933298b9251269a4e2eab1717f44fda</span></span> <span class="giallo-l"><span>00423,</span><span class="z-keyword">0x0c5c203528a51dc0cc9a0852cea64ed0debab06b3ac95d012870589a5ae4c0a0</span></span> <span class="giallo-l"><span>00424,</span><span class="z-keyword">0x7d31cd1ad7743f0c08549c8aba82c3914de61f8637f768725812dae0be1c3cf5</span></span> <span class="giallo-l"><span>00425,</span><span class="z-keyword">0x737fc2002808f4c81dbad877b69160a9ebdc3f8382b5e1f2f08defce897857ab</span></span> <span class="giallo-l"><span>00426,</span><span class="z-keyword">0xb042cd22b27a2d46775de19a0fe07ea0187139b69a8a5f9f8ad680b49a50e81c</span></span> <span class="giallo-l"><span>00427,</span><span class="z-keyword">0xa5f8fadbaf1e1b1c025e9ca7646d214d84afa0d2575026bfd188492553ad2dc9</span></span> <span class="giallo-l"><span>00428,</span><span class="z-keyword">0x2247adf42e4fabead0c52c18fd8d9c3d378b6a82dc3941e9f2e7c03a3e6a5316</span></span> <span class="giallo-l"><span>00429,</span><span class="z-keyword">0x1cae28d5c467521d0a2986ae1ab697c0137fb88a2cd57b7b65e1087002f4ca8b</span></span> <span class="giallo-l"><span>00430,</span><span class="z-keyword">0xab59cee6f8c573ce2e2abac2865d1590cdcc0e4289aa75144582810327d2bffd</span></span> <span class="giallo-l"><span>00431,</span><span class="z-keyword">0xed24090f25bc8dca7749c25f4d6a81a6c0421251b40e9fefaaf7896a49e1cec8</span></span> <span class="giallo-l"><span>00432,</span><span class="z-keyword">0xecfb2f473b32475d203492960f9c706024ad7be82ced8dd0f9506c2cedf3b29f</span></span> <span class="giallo-l"><span>00433,</span><span class="z-keyword">0xea10cb3faf85fe26801f5c5c6f963aa09936d48cc6070abdc86ef7c1ab93eb6b</span></span> <span class="giallo-l"><span>00434,</span><span class="z-keyword">0xed8823c84177d8ffabf104566f313a2b2a43d05304ba6c74c2f5555bae0ef329</span></span> <span class="giallo-l"><span>00435,</span><span class="z-keyword">0x1acee0de8d8fa5a692ca7fe4e6e6b6070264bbce1d27bae29aa96794a92fffaf</span></span> <span class="giallo-l"><span>00436,</span><span class="z-keyword">0xc3510bf4ec6f2561e65ef90ac5f69719835bd88ebc526470a11645a2c743696f</span></span> <span class="giallo-l"><span>00437,</span><span class="z-keyword">0xf2dcc620fcc9352d6e87c27c30f9dcbc38e05c66d4cc315a6b04b3007234821b</span></span> <span class="giallo-l"><span>00438,</span><span class="z-keyword">0x00f5e21daa244de11bbc15728bcda77c7c15fd858252459ad7c10c0ac877ae9c</span></span> <span class="giallo-l"><span>00439,</span><span class="z-keyword">0x5149508dee482fd1927f619b3984641ee6a4cd545e763475d97a759cdd6b9ce4</span></span> <span class="giallo-l"><span>00440,</span><span class="z-keyword">0x9feb91891bf0aa0981ae9b6d8a71dbec00cc4a2ebf9a94a0aecc1815d621b2c1</span></span> <span class="giallo-l"><span>00441,</span><span class="z-keyword">0x3f1832caadae9d68b7056679e7e36db138a48754d0bd69f0f7c369ecfff7763c</span></span> <span class="giallo-l"><span>00442,</span><span class="z-keyword">0x1d30de4aac58ef2504ba7fca3cdc0536a6129314efcf91c713578bebd2182e6f</span></span> <span class="giallo-l"><span>00443,</span><span class="z-keyword">0xea71b6f9916c2fe3cee071ccbbf4105935e111b40d71ecc3b327ae5a992a6d49</span></span> <span class="giallo-l"><span>00444,</span><span class="z-keyword">0xc56da958661c206315768f8f855721cce15e24ff1f350b294a1331eb29db56e2</span></span> <span class="giallo-l"><span>00445,</span><span class="z-keyword">0x02cff3d78ac49a70b6466ab49a54dd2695b8ae3a423b9e52dae2351864ad4e4d</span></span> <span class="giallo-l"><span>00446,</span><span class="z-keyword">0x2280f1cf6ebfeddf1211be1d8801bb188f0afb1626da2921ee603ede2bbcf926</span></span> <span class="giallo-l"><span>00447,</span><span class="z-keyword">0x3cff32e3d7dbda7c7efec80b3c9ceaf9c56b9d5d0c03b53cd12897c0ecb8a59a</span></span> <span class="giallo-l"><span>00448,</span><span class="z-keyword">0x7dd2c4f161ae53d17ee1bce79c6dc3a848fabc81c2ed01d08d768e02c7ae8b19</span></span> <span class="giallo-l"><span>00449,</span><span class="z-keyword">0x6d1d274b948411de02b87258045266f96be9a450a363da2482a1219aecf586cf</span></span> <span class="giallo-l"><span>00450,</span><span class="z-keyword">0x2b5e114981c6f32c8a3b78fa35ce6132d9ca9b597dd94ffd91b77657f5e51be2</span></span> <span class="giallo-l"><span>00451,</span><span class="z-keyword">0x4abe0e076ff522ec7b0eaf0d6751f9dfb7f164b42864e0255f1502a77315178c</span></span> <span class="giallo-l"><span>00452,</span><span class="z-keyword">0x42606107511944b1c7dc61fd2d3467fc43128e69092df1eef47479dbca67f3e8</span></span> <span class="giallo-l"><span>00453,</span><span class="z-keyword">0x23cdebe00f8b0071fe04101936e236e3dcb4e58b94a8101a0f449ec38aaf53b2</span></span> <span class="giallo-l"><span>00454,</span><span class="z-keyword">0xb2b5e5f97f7552d912156e250165b87cf670d32260186a1a41c47bd53e4b7f51</span></span> <span class="giallo-l"><span>00455,</span><span class="z-keyword">0x54943c8b31b13a4f0cc4f3472967383de372b4ca8f89979f6043d44ae330888b</span></span> <span class="giallo-l"><span>00456,</span><span class="z-keyword">0xcab079083dd2ddc43386c219d265ed110b97d315943e37e859764ddb5c380a2c</span></span> <span class="giallo-l"><span>00457,</span><span class="z-keyword">0x82d06ed1ec9bfb436ed64caeb0a1c99efdc719d79167ec9600fed7802c5cb1ba</span></span> <span class="giallo-l"><span>00458,</span><span class="z-keyword">0x2bff3cd79eed0180444dfcbfb8fb93579be52e5d0eb92fcd3ae6c70702a93254</span></span> <span class="giallo-l"><span>00459,</span><span class="z-keyword">0x29e03017ed0f32215c0705d87beff1ecde7afc804217ec41c250a0541e71dd67</span></span> <span class="giallo-l"><span>00460,</span><span class="z-keyword">0x6f2ddb12b11f17f35b123ca3692ac57b18043af935e33eb2f662fa0fe862a866</span></span> <span class="giallo-l"><span>00461,</span><span class="z-keyword">0x86535bae04792f1724aabb2201189ef0b12ca7624e1e9fd296d129d3ef1f74f7</span></span> <span class="giallo-l"><span>00462,</span><span class="z-keyword">0x3658342ed3dba9eedabc93cae0d6cc657bedef4d1dc6c631113af874dd65fb64</span></span> <span class="giallo-l"><span>00463,</span><span class="z-keyword">0x4f586d74db2e09c1ddb553421304a352ae8ca4dfcdd49cb9905c83184cd1050d</span></span> <span class="giallo-l"><span>00464,</span><span class="z-keyword">0x2da57d6c84f0f2de638453005d496136fac3d1a4957f0e6a8aca32070522c965</span></span> <span class="giallo-l"><span>00465,</span><span class="z-keyword">0xafdd52d62167b3f4a6e0c88d5bd5fffd1f4fa06a528e52f2cf3a095cf5f84fea</span></span> <span class="giallo-l"><span>00466,</span><span class="z-keyword">0x21cf05fbe816d55dc025ddc38f55aa7e66bcdb98ccff8abfd031c0832f69dd62</span></span> <span class="giallo-l"><span>00467,</span><span class="z-keyword">0x27685b9d5efe40fe088b50b9a1ea62e8dadeb0425171ad45e6bcc3c283af2acf</span></span> <span class="giallo-l"><span>00468,</span><span class="z-keyword">0x610466b6f8c2771439da2e8a7343c8d961a040e3bbc73ca6c661e4a13f977132</span></span> <span class="giallo-l"><span>00469,</span><span class="z-keyword">0x8c5751e2b93bc6f0ddffd243332a890e3794bb3de71a80ca45c95b971be88167</span></span> <span class="giallo-l"><span>00470,</span><span class="z-keyword">0x2e445b03b86127fe3149c740429382afdd2d0bd2e1ff0b1f05ece2e23470017c</span></span> <span class="giallo-l"><span>00471,</span><span class="z-keyword">0x7f37562302193a70baf1096ce39a616be3737721795d7a106ca321593f29af71</span></span> <span class="giallo-l"><span>00472,</span><span class="z-keyword">0x5f279db60b9c122ef92a239345b84ae0d9d6ab6399ef756e89078c9ded3df15c</span></span> <span class="giallo-l"><span>00473,</span><span class="z-keyword">0x5ae48eaec56b9a49cbb966ec90af455eaa03ee66604e50195cc6ca4dc3f0e1b6</span></span> <span class="giallo-l"><span>00474,</span><span class="z-keyword">0x8b70d9c82bf64392306a74b2075f1218f3e25ff143962e2c63d0300437bd9794</span></span> <span class="giallo-l"><span>00475,</span><span class="z-keyword">0xa8e53747848b2eee9050ce20905f07d99282ae9a35ce825ea1b7faf09677a468</span></span> <span class="giallo-l"><span>00476,</span><span class="z-keyword">0xdd34a7c17094183961aa4c17d9cd6e2e73daeac22f27af1f0d948772d9727e11</span></span> <span class="giallo-l"><span>00477,</span><span class="z-keyword">0x488d852ffe678ca5d7fd3b4f04afeb893595b929c6a968c2b8e6ff7204be27bd</span></span> <span class="giallo-l"><span>00478,</span><span class="z-keyword">0x232a4fc9a0cf3b37008375f24a562c44e25a0f54774e2384db37ea0acc0b599f</span></span> <span class="giallo-l"><span>00479,</span><span class="z-keyword">0x4b082f2481b4819595dba7d5f02505e200b32e78c59100241de37b51720217e1</span></span> <span class="giallo-l"><span>00480,</span><span class="z-keyword">0xb54b802e1b7923c298d222ff23b5f0d1c8b76b886c764b517a1e29bd4801ebe0</span></span> <span class="giallo-l"><span>00481,</span><span class="z-keyword">0x213ae81b453ef36e78b560492832c28c71db8bbb5d12816cf0477c16155ab8d6</span></span> <span class="giallo-l"><span>00482,</span><span class="z-keyword">0x5d09d6eed5b020f1268016d5117587d519d1aaea97b575c6ab24a85135daab13</span></span> <span class="giallo-l"><span>00483,</span><span class="z-keyword">0xf3c11c6e063ba5b267f6616529b2495424a633e08f6a78bedaa660496914ca81</span></span> <span class="giallo-l"><span>00484,</span><span class="z-keyword">0xcdc41b84ddcf6530555d2fd03651ca3fcc29981f4b9df53944efe410442174c4</span></span> <span class="giallo-l"><span>00485,</span><span class="z-keyword">0xb26f2e53df52942461b1c54800e6eb25858b1d86f9bee68c40b8f13ca1fb44bd</span></span> <span class="giallo-l"><span>00486,</span><span class="z-keyword">0x82b8c438d8704a976289eb09500c628a3c07ceaca62d081de94e345d14bf58af</span></span> <span class="giallo-l"><span>00487,</span><span class="z-keyword">0xd834f157ce0cabf68f199cabbda6fe5a47256b25acbfaabd376ee9d28d2366c3</span></span> <span class="giallo-l"><span>00488,</span><span class="z-keyword">0xfa3989a5ba10e3c27731de69a30136ee3ea9e603cb27d12e2a5f32afa60ddada</span></span> <span class="giallo-l"><span>00489,</span><span class="z-keyword">0x4db390c5cb4c32c03d7f9cd7b8823b700e9d64da825194b83e3df46ce5751864</span></span> <span class="giallo-l"><span>00490,</span><span class="z-keyword">0xb9ad2e4d9c6627f63d60befc8778777c829594a044f464f12956c904486f7691</span></span> <span class="giallo-l"><span>00491,</span><span class="z-keyword">0x6aa98f9f56f6ef66ad09f15071de716f61e203ab7a31a98737fd5c46649a14e2</span></span> <span class="giallo-l"><span>00492,</span><span class="z-keyword">0xebdcd70d9e477a11b4fc48d3258dd5bcf6c9222db25dfef74dff86487714b798</span></span> <span class="giallo-l"><span>00493,</span><span class="z-keyword">0x3079f6253e59035a7e4a039275e685c9017d7e1055252fcc7db8c4a5c9bac205</span></span> <span class="giallo-l"><span>00494,</span><span class="z-keyword">0x33f97b590b8f704670771f738f9df52e2037a876fb185f0cecb89fba754af618</span></span> <span class="giallo-l"><span>00495,</span><span class="z-keyword">0xee3904aea19ec5886c2f52956576a8e81fa4b2bacc4464257c1dc3190d6694bb</span></span> <span class="giallo-l"><span>00496,</span><span class="z-keyword">0xcdf13c18466bff16c454c4548995f6d11eb639ebfe71dc793b648066cbb23cb7</span></span> <span class="giallo-l"><span>00497,</span><span class="z-keyword">0x27f7ad957db315648dae2007f3c0c8d7ee81a6c7c3cba09119091325e7ffbf9b</span></span> <span class="giallo-l"><span>00498,</span><span class="z-keyword">0xfed48beb69c269ece25dd3b123aae953c66433728e03370df36a76624736b61f</span></span> <span class="giallo-l"><span>00499,</span><span class="z-keyword">0xd9c9a7333aded4d0f68412484ca0032f348c55ce9ecf21c986d22855625b3ba3</span></span> <span class="giallo-l"><span>00500,</span><span class="z-keyword">0xb11653db38e95638077c58252fa5695f38b933a229decc1bf3d1dd124c0d5f00</span></span> <span class="giallo-l"><span>00501,</span><span class="z-keyword">0xb202cc73bfc03b7f9f584614f21533221cbd0acc95409239090ddc52b5f27d9a</span></span> <span class="giallo-l"><span>00502,</span><span class="z-keyword">0x19ef7cc080401251d654b9529fe8018fb1bc1a58cc6b99e8a5a47a40872c5955</span></span> <span class="giallo-l"><span>00503,</span><span class="z-keyword">0x45f20620961362cc0f7f6e4f3fe15312150eb015de00fe77f6730383c79b9688</span></span> <span class="giallo-l"><span>00504,</span><span class="z-keyword">0x21e3a8f27e2686892a5cf54955dbf7509feb97114352d211efa8573dc344245d</span></span> <span class="giallo-l"><span>00505,</span><span class="z-keyword">0x6dd1ba5667a00e35a95d075c187344e3dd341c0b96e9d7c686b1cf8768e2d4ad</span></span> <span class="giallo-l"><span>00506,</span><span class="z-keyword">0xc0414076dded3d476fba3387ed8b0eb57402f1017dbd117dfaa64eebeb162f24</span></span> <span class="giallo-l"><span>00507,</span><span class="z-keyword">0xa7340f2eaab8704157b80028c86a7f0cb1fef4864da34554f08dfcb614cf4955</span></span> <span class="giallo-l"><span>00508,</span><span class="z-keyword">0xdde4c38d485ca458dcaf7dd54cbd451ee8c9eeae251d59b2f5fa6faa97280a14</span></span> <span class="giallo-l"><span>00509,</span><span class="z-keyword">0xfa5dc42a17a4f780caf728dfc049b9fd56455f05e2ea06202c763ec143b9fd6f</span></span> <span class="giallo-l"><span>00510,</span><span class="z-keyword">0xea2b8d47198cfdc653a2136b98df5615aee70388df0c64eb5cfb90cacd50a931</span></span> <span class="giallo-l"><span>00511,</span><span class="z-keyword">0xd5d2416f6a00df2713ec8fa6cc13ef973d1eb9d900d852903fe1046633599565</span></span> <span class="giallo-l"><span>00512,</span><span class="z-keyword">0xe2918e5026ffd68825dd25cad6ed824a9ab0a4fa4b85a35c4ecf4ef8e0544d08</span></span> <span class="giallo-l"><span>00513,</span><span class="z-keyword">0xd39eefadcb758f4e3c4e4b34eef2e976c6a3959432abcebdfc78d06bcc3148d4</span></span> <span class="giallo-l"><span>00514,</span><span class="z-keyword">0x8bd8f6bdf0226ae2173194ea147c71af760a5c0c661ff1f5ad7cac137b1b6d83</span></span> <span class="giallo-l"><span>00515,</span><span class="z-keyword">0x66d4642ecbc838dc65765a4fcecd474b20b9ae0637244181a84bb373b13d5601</span></span> <span class="giallo-l"><span>00516,</span><span class="z-keyword">0xed3b11872cdaf7b8feb4ba80cc6635e2123473ceec8e939eb46471c70872bb97</span></span> <span class="giallo-l"><span>00517,</span><span class="z-keyword">0x5ef487b21fd4c9f018e1c42787966f14f32ed2e1581fd159ea1e4259a6d73cc8</span></span> <span class="giallo-l"><span>00518,</span><span class="z-keyword">0x710270293ed9c587e43e725361f93c98be4769eace47c2016e4189ef59c5b7e4</span></span> <span class="giallo-l"><span>00519,</span><span class="z-keyword">0x218c3b62dc99a297a595e41cca22f5f8535ff99908dc03940c9e4a855104b61f</span></span> <span class="giallo-l"><span>00520,</span><span class="z-keyword">0x062e17197c2a5da9db37319b5a50917706cbb5b2f94436f231515944f5a533af</span></span> <span class="giallo-l"><span>00521,</span><span class="z-keyword">0x5b55367f4c641c3f847e97b9507772f3defe8e7a7b7e7ba7485a5350838e1786</span></span> <span class="giallo-l"><span>00522,</span><span class="z-keyword">0xdbca1ed318fb0b730386df7aa1e3093735b7579852cfc869c4ef4bc80cdd6564</span></span> <span class="giallo-l"><span>00523,</span><span class="z-keyword">0x297cf9d5925da0389d57e13787de1938ca0efbc4fdf2683d957e86f076191df4</span></span> <span class="giallo-l"><span>00524,</span><span class="z-keyword">0xf389f3b6336ac065daf31616b7dad80bf6e725ffa95b57da3cea36466c04fa47</span></span> <span class="giallo-l"><span>00525,</span><span class="z-keyword">0xd851e82289f5aeca6786aab0281c156e6e75cce90fb8689cbbbc6cff69f034bd</span></span> <span class="giallo-l"><span>00526,</span><span class="z-keyword">0xc69972a185d32c7419238da9577424406252b97d93001e401d8649fe6991809c</span></span> <span class="giallo-l"><span>00527,</span><span class="z-keyword">0x2c103256a2b901f09cd43ae21da8743d4b7c8e5c925d98a67de5579de1d89630</span></span> <span class="giallo-l"><span>00528,</span><span class="z-keyword">0x32a674ae21d37007a12f57639d299bd71d378c127c3b5bf80d9b7b72f8a89800</span></span> <span class="giallo-l"><span>00529,</span><span class="z-keyword">0x1bf711d19f7b6ee55cebb887105666aa7f30c594081b4b9bacca5b42c935d68c</span></span> <span class="giallo-l"><span>00530,</span><span class="z-keyword">0xaab9d4e3f1f4a07e2dc09ecd78ee8fdd50daf8ec5349ce42d33e93e73452e1c9</span></span> <span class="giallo-l"><span>00531,</span><span class="z-keyword">0x0f51dbcac068fc62805ec9b43a0b1b83c683b23f255eb63cd81ea3e2562953ca</span></span> <span class="giallo-l"><span>00532,</span><span class="z-keyword">0xb4c6703d6f10db4d87cfd07d94c45cdf6176fc42656997210ed219af1320df18</span></span> <span class="giallo-l"><span>00533,</span><span class="z-keyword">0xbb2932ed5e95ea609fc5a252cc60087f857230da2797d62330595e0647430f1f</span></span> <span class="giallo-l"><span>00534,</span><span class="z-keyword">0xc65d109d82fe28526fe4653452cf09db4db6a254c2c3054b8ce3d6cad489bc3e</span></span> <span class="giallo-l"><span>00535,</span><span class="z-keyword">0xbb367122e14176555be535edd3085bbffe0cfa73f3754ca9eaa10dcae6f60e82</span></span> <span class="giallo-l"><span>00536,</span><span class="z-keyword">0xfaadd066133e49dcb1a5fa2c92f376f3d165c3b276ac75e5881fe7012b2734dc</span></span> <span class="giallo-l"><span>00537,</span><span class="z-keyword">0x576b374c1d32e2db299b04073d838366c4525a766e1c10dd8fe0a79ac2ce45f4</span></span> <span class="giallo-l"><span>00538,</span><span class="z-keyword">0xd8eab6c1d289e8f853425d63e99768ba364012c21537e9be20e9b8999ed94eb8</span></span> <span class="giallo-l"><span>00539,</span><span class="z-keyword">0x2c32d06d103d4b1f9d31779131b008f404e149a5bd8a53f6805ad0331e592281</span></span> <span class="giallo-l"><span>00540,</span><span class="z-keyword">0xf3078a9b01c1741a63baca8c231bb4a482e62d835c4eb3ca3ef752154ef9454b</span></span> <span class="giallo-l"><span>00541,</span><span class="z-keyword">0x3063ad60f10b704d724c082e97a0145796854d3ce3d1550347309657dd36b8f9</span></span> <span class="giallo-l"><span>00542,</span><span class="z-keyword">0x90a242f8e1785389d27726dab026c0e30677713f67c4bc2747673358990aa4d9</span></span> <span class="giallo-l"><span>00543,</span><span class="z-keyword">0xbe9dd353aa0b026bc9363961397d25bb46f26570ea7f90ed982373d6a7115c72</span></span> <span class="giallo-l"><span>00544,</span><span class="z-keyword">0x1c5c761520401a356ed867ac5172ffcf59b1a9b9c6fda3908a4c9474ea075592</span></span> <span class="giallo-l"><span>00545,</span><span class="z-keyword">0xe6369239027eb6239ee703f7e9e6dfdb32dd1a94b70094dfcadc9fbe0154e4cd</span></span> <span class="giallo-l"><span>00546,</span><span class="z-keyword">0x2135141345bcdc69e19b4e3df1ce29a017c07fb80df9b27bc38287c2c5ccd628</span></span> <span class="giallo-l"><span>00547,</span><span class="z-keyword">0x0fd9e031326788cff66e44315940516bf926d51524e880548d90717d0da9d6c6</span></span> <span class="giallo-l"><span>00548,</span><span class="z-keyword">0xe318be79b341bdbc93f1900e82a5fff4f52df9b9a113edbe4bfaa512d1411189</span></span> <span class="giallo-l"><span>00549,</span><span class="z-keyword">0x2dde72e5e61c9eea6351d4ff14794a71685daefea6ed3cf9b62ca9aa99f9313f</span></span> <span class="giallo-l"><span>00550,</span><span class="z-keyword">0xd89b717d47ffb827b1490a37ffd97547694c6ad3dbdee5cd56a3583717962751</span></span> <span class="giallo-l"><span>00551,</span><span class="z-keyword">0xa8dfd8606b55c4f54453ccf9e48838bca6accabcb629be668755b0a13867a77c</span></span> <span class="giallo-l"><span>00552,</span><span class="z-keyword">0xd6a3521a5eaec4c47314a4b123701777fb7ab51af66093ad8c57bde9249bfe8a</span></span> <span class="giallo-l"><span>00553,</span><span class="z-keyword">0xf702584d8c87da3ca916ab9caac71d0a0922884cb8db05cf513d5b4144bac3a6</span></span> <span class="giallo-l"><span>00554,</span><span class="z-keyword">0x700d58da768be40c844feeadc5f42385dab83a5b758aafc432172fc150403739</span></span> <span class="giallo-l"><span>00555,</span><span class="z-keyword">0x41db6d144ada4684a7a61e108131d5d78d250b3e47c8cccc85b447e5b1088a8c</span></span> <span class="giallo-l"><span>00556,</span><span class="z-keyword">0x3503dd53c35d41dd5df98f30d4a4df5f7c4a456edb598cb5c2ecc91cc81198d3</span></span> <span class="giallo-l"><span>00557,</span><span class="z-keyword">0x02391085f2bdccf3e4774ffe1e0a7fdf318fdebd564f5015c64d6d1edefb34bb</span></span> <span class="giallo-l"><span>00558,</span><span class="z-keyword">0xed670fa946019be6e96bd20ec27eb5c92bd6177ae0a32fc9cbe2c179cf7f536c</span></span> <span class="giallo-l"><span>00559,</span><span class="z-keyword">0x63277435c400bbc4916dcf4d295ab0cb233d68834bcda11cc231e999996628cf</span></span> <span class="giallo-l"><span>00560,</span><span class="z-keyword">0xe89160d7dc2b0d06408df356eb166aad39c73e6fd51e97f5a64d1f6d57fa1686</span></span> <span class="giallo-l"><span>00561,</span><span class="z-keyword">0xf95c755f337bd6df5127911e601a763a36070bda95ec63ab8adbd1fbf148a35d</span></span> <span class="giallo-l"><span>00562,</span><span class="z-keyword">0x97a6fdba7ddb6462d9cae6ecaaf13c2ac670f7db6216547a5c20ef46a9a2af6b</span></span> <span class="giallo-l"><span>00563,</span><span class="z-keyword">0x8aa6ac0e68888875b0afe306759d787609bd56cbad19a9cdbed484cba64b15b6</span></span> <span class="giallo-l"><span>00564,</span><span class="z-keyword">0xba8486b8d3fc13f529e72ac00fddca459b530ff9a9ec0948a7838089401efc60</span></span> <span class="giallo-l"><span>00565,</span><span class="z-keyword">0x7cba894eacdce587e611f2740c3de0d15e3754efe0331e976e1cf0150035fb2b</span></span> <span class="giallo-l"><span>00566,</span><span class="z-keyword">0x54b3e34b615873aa7def6c73d8d45bab4e5f0ee5a9c8e503340ec9bf42e32cb3</span></span> <span class="giallo-l"><span>00567,</span><span class="z-keyword">0x40280a8567c1cab76c46ea7666b3f17b06a6b1d845922feb286020e7c3439091</span></span> <span class="giallo-l"><span>00568,</span><span class="z-keyword">0xad863b1e23e92bc3b1dfd81f66371f01eb200bb178d4c1659b39fecc1d5209e3</span></span> <span class="giallo-l"><span>00569,</span><span class="z-keyword">0xdcb283eaa11602480e3a38aec7563c48bd939a61149760408704f243062dffe0</span></span> <span class="giallo-l"><span>00570,</span><span class="z-keyword">0xfb9123623556bc897c2f316008fddb109a20ce6abbb666bf55d9f0e96aff0dc6</span></span> <span class="giallo-l"><span>00571,</span><span class="z-keyword">0xb65f3342d82ea682030d61222badd0d0032f03a44fb33454fd5965edfb57e9ab</span></span> <span class="giallo-l"><span>00572,</span><span class="z-keyword">0xdc59179d2daa0417c7f7879eee3d53a08066ad558a36cee1535a9b515b0d0cef</span></span> <span class="giallo-l"><span>00573,</span><span class="z-keyword">0x21aec308be98ab2777b0030e3b55220901ba3e4c2059a076086ef52e11e15e9c</span></span> <span class="giallo-l"><span>00574,</span><span class="z-keyword">0x55e72fc99ac693fb34bb00d1ed8611d53d6414693acaaa52fdabfd3099dfc88b</span></span> <span class="giallo-l"><span>00575,</span><span class="z-keyword">0xf6564eb58e1d7f625d3a634513ab089b913301c69a30faa1bb52730be7908721</span></span> <span class="giallo-l"><span>00576,</span><span class="z-keyword">0x923096d4ee10bb045085a46459592497f6314b580c75c62cda1e27c637f105df</span></span> <span class="giallo-l"><span>00577,</span><span class="z-keyword">0x5914605dadf8851cf40c7591ff45b182fc6751a233e8ded429a92df0fca49c5d</span></span> <span class="giallo-l"><span>00578,</span><span class="z-keyword">0x57d591a81cbbb89601aa972f81d25b61b88f534fa7fdbf207611ebb6aa1cc267</span></span> <span class="giallo-l"><span>00579,</span><span class="z-keyword">0x705b8e045b05fb96483e3356c8b0e0120cfef7a8e9649476bce35c26a8d25f95</span></span> <span class="giallo-l"><span>00580,</span><span class="z-keyword">0x5b210184902c591dc9dd3630edbe4d816137515009ff3447144360d49ee26317</span></span> <span class="giallo-l"><span>00581,</span><span class="z-keyword">0xd3dc3f99fc86600deabcc70f3bd7ef4fa9fe70da3a428b2b4ec622012b115d7e</span></span> <span class="giallo-l"><span>00582,</span><span class="z-keyword">0xd6b2c7ef628b2a4e0be27bba141b8f45946d18ad5d17255d9230b21555a377cd</span></span> <span class="giallo-l"><span>00583,</span><span class="z-keyword">0x434001606cc9da452057323ef3d56d1cf3505f9dd19aae59e918617e11e180e9</span></span> <span class="giallo-l"><span>00584,</span><span class="z-keyword">0x21b2682b8046bd14001c17d9a9feb7feda179d3a56f21a722df82042056dd1c9</span></span> <span class="giallo-l"><span>00585,</span><span class="z-keyword">0x02f0b1510358fee5dda91e345cfe38e0e0bdb0643d0165ebc51cd382fd0ed6fc</span></span> <span class="giallo-l"><span>00586,</span><span class="z-keyword">0x60d868cb6169cbec6c74545f6cc362b6b44290d889527a728b1af1f846e9230a</span></span> <span class="giallo-l"><span>00587,</span><span class="z-keyword">0x59cc91f73e2cb552ff57ac76eeb2de51c49f80f237e5e05302115e2d1500f668</span></span> <span class="giallo-l"><span>00588,</span><span class="z-keyword">0xefefa87ce3db08c5545fc2bb64021e8112434e06ec3760bed7b6440d852cd576</span></span> <span class="giallo-l"><span>00589,</span><span class="z-keyword">0x85c8dc20f625a20a8d969f1cd97a54a4c760817067763f9992be2e1e9d2d9e8b</span></span> <span class="giallo-l"><span>00590,</span><span class="z-keyword">0x2bd79cac465f01ebb1eb59886d2b7d2d1c7b7c1debb19d5cea88470aa13fadd9</span></span> <span class="giallo-l"><span>00591,</span><span class="z-keyword">0xd9b21bd9fc16529e92da39239593c1021e195231affab0eed3475b79e01d8c65</span></span> <span class="giallo-l"><span>00592,</span><span class="z-keyword">0x9dd2dc6ad9373a8e5e80ec6ec9eba8b0f2242692bf27a93678270986620a743e</span></span> <span class="giallo-l"><span>00593,</span><span class="z-keyword">0x0a9de411103269d9df322cc24c80bc49e30b0d0021f0a13c84e784a95c1412c6</span></span> <span class="giallo-l"><span>00594,</span><span class="z-keyword">0x54bb502669ff807c87513c7ac708c471efaf3782d0ff9b7dba577dbd5024a8d3</span></span> <span class="giallo-l"><span>00595,</span><span class="z-keyword">0x08fa26596e31b58ac3788844e300b057d53983911166d3848105b53c0b064993</span></span> <span class="giallo-l"><span>00596,</span><span class="z-keyword">0x5e2423f9905b980f953f2c35daf3385540333d41dddd46c710ab7dab864278f4</span></span> <span class="giallo-l"><span>00597,</span><span class="z-keyword">0x49b11d141d74f6eff4a99a858413e3ab5f3d3740c6ed5c705cd66070af051a63</span></span> <span class="giallo-l"><span>00598,</span><span class="z-keyword">0x050d0b97623cdfd0c8d202dc6bf4e0c3a73df861383ed307131163623422e0e0</span></span> <span class="giallo-l"><span>00599,</span><span class="z-keyword">0xa19b1a209ced8078ab2f240886f68b64cc67bd5806a08d472ba3cccefc5eb9e0</span></span> <span class="giallo-l"><span>00600,</span><span class="z-keyword">0xa81ae85fb6a0ebae94d8df6f34414ea890a7ec7621ac195c683a6d6c34a594a0</span></span> <span class="giallo-l"><span>00601,</span><span class="z-keyword">0x9e26205a26df3598d2ec6236069fb7a74c37fa84cf323c4fa09f4bf7412e687c</span></span> <span class="giallo-l"><span>00602,</span><span class="z-keyword">0x287136148ea36dabb0693ef81fe921e25974d96a2724ff0d86b10e3e78302ffe</span></span> <span class="giallo-l"><span>00603,</span><span class="z-keyword">0x9a115bef53f5237d03975ba6c2baf4377bf8e15ac54bf2093375681a38cbf19e</span></span> <span class="giallo-l"><span>00604,</span><span class="z-keyword">0xba62e0022781cddf46d8da27f2c69b7c1dcd33fc184b2329fd59cb187e351d3b</span></span> <span class="giallo-l"><span>00605,</span><span class="z-keyword">0x0d936f160c2fd830cfc16d6c17e87ca0cf6e6b28ec1f6b7d934100e82d61c59f</span></span> <span class="giallo-l"><span>00606,</span><span class="z-keyword">0xae859b842f320c06c3899683b50a2d37a32e1b07786c761fa092e10e572793ce</span></span> <span class="giallo-l"><span>00607,</span><span class="z-keyword">0x62d75fce6440773a1c0e6573ac37e429164c377aa00135c7e1c2e2f7b06a4759</span></span> <span class="giallo-l"><span>00608,</span><span class="z-keyword">0xd449c48d3ab67d1f1f15eaf0dcd5351f9c463f6aa103e6b4ce6a17a3b69bb523</span></span> <span class="giallo-l"><span>00609,</span><span class="z-keyword">0x7e60445e276f7e090b8ddc8a36a01bc4b66faa212588130c1175a5797a837bb6</span></span> <span class="giallo-l"><span>00610,</span><span class="z-keyword">0x2f230cba76af9df75862b04ecf554ad6bb46abd4be7a8e99dc468de6d5905408</span></span> <span class="giallo-l"><span>00611,</span><span class="z-keyword">0x290b8c2bbdea109cbf5209a39382993c21f9d520ff8fd07e85d273de90c5f587</span></span> <span class="giallo-l"><span>00612,</span><span class="z-keyword">0xb363f64740a275f7816130024de8ccfdbd67fae7526a015679bee407a5e5f485</span></span> <span class="giallo-l"><span>00613,</span><span class="z-keyword">0x80a4144c9bb6e7aba587a8a91a1362a5edf92e0fc4dbcd339a717a9200cf391a</span></span> <span class="giallo-l"><span>00614,</span><span class="z-keyword">0x20913bde281d7f10d729b290f509ab76ed07603f32033cb73071f43cef734092</span></span> <span class="giallo-l"><span>00615,</span><span class="z-keyword">0x8b6e7a1e1535c08d0457aacae6cc68c0385a62a35282179c726707090c84985f</span></span> <span class="giallo-l"><span>00616,</span><span class="z-keyword">0xbd35481ad334939158e73a3b0e8214993e9de1202e8a8ff567c5dbf88a3dccc1</span></span> <span class="giallo-l"><span>00617,</span><span class="z-keyword">0x624ad401fff7fe715ab546b1898e5f3e735f42c134d592d49b4615afd5b6d3e1</span></span> <span class="giallo-l"><span>00618,</span><span class="z-keyword">0xc70c6f7e13ccb5d9a1e56381ac39cabeb4c2e9f1693134d59599b7260bfd7954</span></span> <span class="giallo-l"><span>00619,</span><span class="z-keyword">0x1b807cedf382c87a6ee8cf00a7178eba5516948a0318aacb8176f3e577ce0a6a</span></span> <span class="giallo-l"><span>00620,</span><span class="z-keyword">0x850650230838e76460e4ddca3edc33bd286c3f8d40ad3a1ff89b35280cc6510f</span></span> <span class="giallo-l"><span>00621,</span><span class="z-keyword">0x385fbb21923e5bbca8952a90a3d861ba963d83ddd01c9730fe177341cdb25260</span></span> <span class="giallo-l"><span>00622,</span><span class="z-keyword">0x92fb5e57d123f079903c0f55481f913c45d490c7df412a721d38cbc528037875</span></span> <span class="giallo-l"><span>00623,</span><span class="z-keyword">0x642081dd761497e077b1aab32917656570396000b075f9c182ffeb34e905bf91</span></span> <span class="giallo-l"><span>00624,</span><span class="z-keyword">0x1d72d6273c3ce96a26a5442357d4bd58b84dad51a2eb39f25ec02929e55290dc</span></span> <span class="giallo-l"><span>00625,</span><span class="z-keyword">0xf7ca7cb8ad47a85c6dad965e8c89bf7b33af62fc5dbfae0f5e141ae4ae1c280c</span></span> <span class="giallo-l"><span>00626,</span><span class="z-keyword">0x4f92dd261b9f5a9ed03735dc46722963d949ad3038f66ce380e4a1aaec9997ce</span></span> <span class="giallo-l"><span>00627,</span><span class="z-keyword">0x06e70723c3b912cfe421cb2126e812684742e304f2b8f6d6eb57b1fa959b19e7</span></span> <span class="giallo-l"><span>00628,</span><span class="z-keyword">0x313cbe432878645b4d887d961d6ff1dcd3c75b508b9263c05ed385754b7c7709</span></span> <span class="giallo-l"><span>00629,</span><span class="z-keyword">0xe939c15140cdf455b99492b6259ecf0c93ff858719948940f54dcc0d202988bd</span></span> <span class="giallo-l"><span>00630,</span><span class="z-keyword">0x1fbd3e9af1082f0e99094876294f6a857d8162f32c1f583eba1618acd2099a17</span></span> <span class="giallo-l"><span>00631,</span><span class="z-keyword">0x333c0583cffee0f355a1e3ccb6aa6aa16c80ebdc789e698c5f0f17521fc75035</span></span> <span class="giallo-l"><span>00632,</span><span class="z-keyword">0xbd6027f363c5a6efaf7d6f483653d256c6038a628064927411e970280a7ada9e</span></span> <span class="giallo-l"><span>00633,</span><span class="z-keyword">0x2fc5d74d149d6b265a5f6ef7b220738da67423b7aa176bd97d8b1c0df694ea47</span></span> <span class="giallo-l"><span>00634,</span><span class="z-keyword">0x5b3c9d594d6329d06de454698372063fe7c17da6f5dedb0ed68d7220e51af8d0</span></span> <span class="giallo-l"><span>00635,</span><span class="z-keyword">0x95e4dedec09d095e65d74638d433817b736659254cfbb46483ff449a9a1414b6</span></span> <span class="giallo-l"><span>00636,</span><span class="z-keyword">0xf8124b1e4bc3e7715dcff4eac8fdfd594f035a5c37ed7e041c85928cb0f32a93</span></span> <span class="giallo-l"><span>00637,</span><span class="z-keyword">0x12daf758eb702d488f8ae9c61e89b165f4b1e4090dba46713796dd49866585dc</span></span> <span class="giallo-l"><span>00638,</span><span class="z-keyword">0x75957ec2b9f6cd5f4e74a8f9c7f87432ba90888af7eebd1cb621b4d8b002d113</span></span> <span class="giallo-l"><span>00639,</span><span class="z-keyword">0x7c4f218a868ac866144c6d3d76ce9418c7674546ed3dc36e8ef313dd58913d6a</span></span> <span class="giallo-l"><span>00640,</span><span class="z-keyword">0x3cdc61329614d0f9f495f56c7be93a89783786ec23004628348b62819a5db04c</span></span> <span class="giallo-l"><span>00641,</span><span class="z-keyword">0x471f9e808ae0a317cce604dd035331ef6409ba0c3b0b0bf36ed93946fcd0fe83</span></span> <span class="giallo-l"><span>00642,</span><span class="z-keyword">0x551764bd61137d2595500f29b441cf8588f4ed1f7e1023182ee72656ad70bae8</span></span> <span class="giallo-l"><span>00643,</span><span class="z-keyword">0x368d4f6f887c76cd7416b91139d0613952a137d983d7ade47602ea026edf5e04</span></span> <span class="giallo-l"><span>00644,</span><span class="z-keyword">0x81a7c3da06068fc345f11d7bc65b30d249f3bae56c476ef2c16a2d7a04e19112</span></span> <span class="giallo-l"><span>00645,</span><span class="z-keyword">0x2582b644739c464536ed4befe7d7bcf77bba70a416a74869934701eba0300a4e</span></span> <span class="giallo-l"><span>00646,</span><span class="z-keyword">0x7fd3548a22eafe728cfee056c100c5ec3622ee0280a79be7b7fb5cd1af2499b5</span></span> <span class="giallo-l"><span>00647,</span><span class="z-keyword">0x07e93c81557232d569357182dc05bbbcf7ff3f5b3786163cfb5df756e601d9d9</span></span> <span class="giallo-l"><span>00648,</span><span class="z-keyword">0x01a981a6bc6a5c30e9e24acbd2610094f612785ee1da40150ef6adf7759418a3</span></span> <span class="giallo-l"><span>00649,</span><span class="z-keyword">0x05bf160d3f11c285bd8d159e9a675bf04b17615fcadb4390e8f582246d52a263</span></span> <span class="giallo-l"><span>00650,</span><span class="z-keyword">0x119bef0c67ab4480ee8952c208c75959a4a98db6b646410d4276c650e107354f</span></span> <span class="giallo-l"><span>00651,</span><span class="z-keyword">0x4d3f0b82017c63839fe95826858a18ac4ae5376c004d04a23aba4d6d7a32b96f</span></span> <span class="giallo-l"><span>00652,</span><span class="z-keyword">0x730975c7bcbee5e2bc9299e12abb46dfc7f5b94416c94b6b103ae22d4a189049</span></span> <span class="giallo-l"><span>00653,</span><span class="z-keyword">0x2eb89f05e222461e22e437518949767e25e432862909e07df410c6ca237cb567</span></span> <span class="giallo-l"><span>00654,</span><span class="z-keyword">0x51b0bde3cc9eaf4d7ababa77e2e06e65b262864cd9894a8f9edf4b3483ee1d28</span></span> <span class="giallo-l"><span>00655,</span><span class="z-keyword">0x06381406a98b16d278488bbba3f91c0ec10c1ace930d75833f15ba9c73500a2d</span></span> <span class="giallo-l"><span>00656,</span><span class="z-keyword">0x0c07242390289d92c0deb8bf23da435720a753a07822a0bde0bfddc258c2ae90</span></span> <span class="giallo-l"><span>00657,</span><span class="z-keyword">0x4b0dfe65c189822fa4cd1648d3fbb1ecf75b8b5538383cde1b3f899caf1d1bb1</span></span> <span class="giallo-l"><span>00658,</span><span class="z-keyword">0xeafc91b6b61da1feb8af3c78fc9b7d01239962fdbfbd40c920a55f620ff74351</span></span> <span class="giallo-l"><span>00659,</span><span class="z-keyword">0x49e7399f27b5e26165b5603002b529ab4a974346259ba9aac2128387c0b6516a</span></span> <span class="giallo-l"><span>00660,</span><span class="z-keyword">0x376add4f0e8ed9e97c43c5e439d90b5742c913908bbd5ff6da3ea59ac381da92</span></span> <span class="giallo-l"><span>00661,</span><span class="z-keyword">0xa8a70e6e484c3180d23874a903ba032a1377e3bd53fa9818d7c11dae93883fa5</span></span> <span class="giallo-l"><span>00662,</span><span class="z-keyword">0xdffecb3c77a67ecd4d71ef3d16a47cb27dfeeda34126567620ad4bc0e6ff5961</span></span> <span class="giallo-l"><span>00663,</span><span class="z-keyword">0x6c4ef261baa1dc41e4e3f559e686ce4e340cb14cebebc5ec6cd2d8d11b4bb550</span></span> <span class="giallo-l"><span>00664,</span><span class="z-keyword">0x3eb2993dbbfdd451bf6ee204a1aa8363bccdf05442fb2d37283d0e9743c9548f</span></span> <span class="giallo-l"><span>00665,</span><span class="z-keyword">0x8f4067864f02001aa64082821d09b6fa8bd4f08eb10a97f2b3d725988dec18ef</span></span> <span class="giallo-l"><span>00666,</span><span class="z-keyword">0x4ed7ee7ff95fba3f7e26f8ba3dedd661c29cc693e39ac180fb1cf51cf06be01e</span></span> <span class="giallo-l"><span>00667,</span><span class="z-keyword">0xa6b898d4e160d6568325e5178aad53d3b1928eb26c0a6983e2e564787cb59169</span></span> <span class="giallo-l"><span>00668,</span><span class="z-keyword">0xc4a9d166c6bf0bf68df60ac3841b9dd7643261a1f680ebc4a3eb1e78a2bae263</span></span> <span class="giallo-l"><span>00669,</span><span class="z-keyword">0xd8d978428ae77afca8ea889e5e315b4840b2c03a2f9cf046e6809ab3cc2bb50b</span></span> <span class="giallo-l"><span>00670,</span><span class="z-keyword">0xbe3afc5ce9e69625defb1cef154c5ed21bd685b3b444f0bf18eb578438483e84</span></span> <span class="giallo-l"><span>00671,</span><span class="z-keyword">0xbf138a264139a579902a52806444d5b72e5a7d700b441fb3e48007d1d96badb4</span></span> <span class="giallo-l"><span>00672,</span><span class="z-keyword">0xbf106779ccffef7ba05420f4d363f699759225b5c63c0570c644684ed02a1a82</span></span> <span class="giallo-l"><span>00673,</span><span class="z-keyword">0xdefe7756ebd4bbb46d00e6a9ec83e0b448ad30cd07e8140e8d198a762e17bc9d</span></span> <span class="giallo-l"><span>00674,</span><span class="z-keyword">0xc6dc6388bc26f755dbc33c06ede33976846dc45cf406aaacc275f36bafbeb8a6</span></span> <span class="giallo-l"><span>00675,</span><span class="z-keyword">0x1e729aa1a7eba72fa1b394e8e02ac0b11ff5b52c45ade0e1dbe6cf94133d3d52</span></span> <span class="giallo-l"><span>00676,</span><span class="z-keyword">0xa5855d981860b945790cd878ab958c0c8f9d634e19eed4ffb6f2b6fb0bdac0b4</span></span> <span class="giallo-l"><span>00677,</span><span class="z-keyword">0xf3e17cb0fdfb1b6843f71e8371f3ec7943f3fe8c336f50eec94be6b3d7cc74c0</span></span> <span class="giallo-l"><span>00678,</span><span class="z-keyword">0x42e737249c54ec77b3e92f6e2ad6cefa998f950a04b6e86467096abe91018de1</span></span> <span class="giallo-l"><span>00679,</span><span class="z-keyword">0xf0fc97a52d48a5cd63c3a44569661bf5d52b37631aa5de0f9c43bf9fe2ac0e54</span></span> <span class="giallo-l"><span>00680,</span><span class="z-keyword">0xa6045d364b325ce7f818cda8750a79196c59419e2be015438e097fc8b52dfa0d</span></span> <span class="giallo-l"><span>00681,</span><span class="z-keyword">0x247222f0af90a8ec543ba8c04c847b648fce30a323ffb4cec28f0c1571f878a4</span></span> <span class="giallo-l"><span>00682,</span><span class="z-keyword">0xa6b3aedbef826280e9fb8ac59718ab16e5369cd11be51532675fc454d89d533a</span></span> <span class="giallo-l"><span>00683,</span><span class="z-keyword">0x19fcceed6516cae75fdec68f8d34a12c90b64c4d140c4576e724251e6ee6ebed</span></span> <span class="giallo-l"><span>00684,</span><span class="z-keyword">0x388b0bdc52a25713bd30615e094a873e633092c199bbe247c96c32a61fc12263</span></span> <span class="giallo-l"><span>00685,</span><span class="z-keyword">0xa2bcc3ddd6f1ec7a0e90f3faf0eb8418a297538a351f16523bf767951cdf179b</span></span> <span class="giallo-l"><span>00686,</span><span class="z-keyword">0xdf515337eccd495de4a93cfd27e7cd44bfdaaf7cad84ab831255b232d9c3dbad</span></span> <span class="giallo-l"><span>00687,</span><span class="z-keyword">0x8977442562e00f0c2d71e621848a4ed4b54dc37900075e31d4e945cc1ff9cd5a</span></span> <span class="giallo-l"><span>00688,</span><span class="z-keyword">0xa979df6fe13d81c5777eae13b0416a370a2c631c41446e51ffb060a8a6a71452</span></span> <span class="giallo-l"><span>00689,</span><span class="z-keyword">0x33e5fa30c4826bbd3448bbb05dd7273639f122e9c9cacaad987e1def1daa7c80</span></span> <span class="giallo-l"><span>00690,</span><span class="z-keyword">0x7c95061fb3cac78558039c1cebd4c7e70831f6f5a7906b9faa1a7554cbb43e28</span></span> <span class="giallo-l"><span>00691,</span><span class="z-keyword">0x062b4177522f6cbaebe9e708a4717d0f5218b21041f84b7eaa13293477135e10</span></span> <span class="giallo-l"><span>00692,</span><span class="z-keyword">0x945645ca1e3e1c23eade81c2c8e0a7cd428d3dc875b15fc9bbdbde163bc742a7</span></span> <span class="giallo-l"><span>00693,</span><span class="z-keyword">0x8c6754fdf4780c58461bb089f7d5cfce43a0c0b527b7044e27eda9852f34a7a0</span></span> <span class="giallo-l"><span>00694,</span><span class="z-keyword">0x222e02bcbbe7f319c293f0c4da042bf7cd9c3bf8c953f4319a14191e4f005966</span></span> <span class="giallo-l"><span>00695,</span><span class="z-keyword">0xcebc5a0e235e81bd4488436792b62e736be4cdbcc60f200326cc91b436808baa</span></span> <span class="giallo-l"><span>00696,</span><span class="z-keyword">0xf73fca1b251055ccf2966f306db54c0201bea107de603c1aac0f7b2914386dd8</span></span> <span class="giallo-l"><span>00697,</span><span class="z-keyword">0xcc3b18315c91ff81f2f9c76c74c0aec6f4bb76fc6cee9512ee81026de4f687aa</span></span> <span class="giallo-l"><span>00698,</span><span class="z-keyword">0x062461dfeaa7dc2a5a6e7149f2ba928b78aef2b9958605a31185bcd7f004522c</span></span> <span class="giallo-l"><span>00699,</span><span class="z-keyword">0x7dcae2e8fbc54bedb91edeb0c02141574a70e0412b2045e311330119491c2129</span></span> <span class="giallo-l"><span>00700,</span><span class="z-keyword">0x64f029a915ad77e37247bb296e4e3eca49dac180d5b91d5b9e1366cb5d02df74</span></span> <span class="giallo-l"><span>00701,</span><span class="z-keyword">0xc0ae757bd5b3d4a2a87884cfe45bd3ee2f11239b51f9dd5cfc05401c5c66bb8d</span></span> <span class="giallo-l"><span>00702,</span><span class="z-keyword">0xabe351f7c2bbfcbe08dc7bcdb0eeb08079046bb9f2c94a80ed7bf8e51bddeff4</span></span> <span class="giallo-l"><span>00703,</span><span class="z-keyword">0xddee734cacc8d4ef083d67efa4df54519a60e0101c0a43842eaf93af88ab3377</span></span> <span class="giallo-l"><span>00704,</span><span class="z-keyword">0x2ea464e978346b97200486d8994e77706f83622452eb3850a745b215b6351eab</span></span> <span class="giallo-l"><span>00705,</span><span class="z-keyword">0x9f0bc9d6161d69f28e3f342553c62fe53e281dee8c05002bd562b964c7abc1a6</span></span> <span class="giallo-l"><span>00706,</span><span class="z-keyword">0x58568eed1ab113f2d3305f595ff6306f9bd4a20dbc168388afce22679b648ccd</span></span> <span class="giallo-l"><span>00707,</span><span class="z-keyword">0x6aca18990b84a8ef483d70e93ef95a3fefd969b44162724e8d205b2e44a60e09</span></span> <span class="giallo-l"><span>00708,</span><span class="z-keyword">0x2478502ca3b5bd3787da2b2702e4ed470abc698594043bd7eefc6b0d200cfae9</span></span> <span class="giallo-l"><span>00709,</span><span class="z-keyword">0x07426af091dc9d0b455e6c0a6de13abd24f3eb3a8e7763538159bcd1bf141645</span></span> <span class="giallo-l"><span>00710,</span><span class="z-keyword">0xa70b753c132d447457a4a4c500a03afa9fc5a506cd08966303adf5439a183fd2</span></span> <span class="giallo-l"><span>00711,</span><span class="z-keyword">0x1146e2f9e5e7d485c0b97ed15f1f6a5d3ce2b829460d37cdb9ac49d7f6b2ee08</span></span> <span class="giallo-l"><span>00712,</span><span class="z-keyword">0x560a81199fb507f115ab5c06337c8c4dc0fe38d991a0057b88816849e2899ad0</span></span> <span class="giallo-l"><span>00713,</span><span class="z-keyword">0x54d9396ec97021ae660990c80c6a06075f9e7e2cb7520f242b8c4019f29fe4c3</span></span> <span class="giallo-l"><span>00714,</span><span class="z-keyword">0x8979cc56b72d0fa09ab853f0c94da9223e371e4e3a76d085a8d5e0ccfa812c9f</span></span> <span class="giallo-l"><span>00715,</span><span class="z-keyword">0x1a583ca6146142cd35125be61ebecf376f08db4cb907d613d8877b383a961923</span></span> <span class="giallo-l"><span>00716,</span><span class="z-keyword">0x4850905c37251bdd1612b0948a06170a335831bd753be7c62d0d50a8f10bfb34</span></span> <span class="giallo-l"><span>00717,</span><span class="z-keyword">0xf510edaada3d10661180eb5af717d93b8c5e39971c0c7b82245958bdc47d4359</span></span> <span class="giallo-l"><span>00718,</span><span class="z-keyword">0x511c0a35f990cf41f851e42863956b7fa20eb133503b7f5e8b7dcfd42ff57d8e</span></span> <span class="giallo-l"><span>00719,</span><span class="z-keyword">0x14409e14f0ae0f18d080c8f6bf0ae89e4817e214ac3b2c3e7625266375a502a1</span></span> <span class="giallo-l"><span>00720,</span><span class="z-keyword">0xcf91e8a7472e27a4172246ac5c5a761575f2f25650a2284ea607f8b607ece639</span></span> <span class="giallo-l"><span>00721,</span><span class="z-keyword">0xaa8695870b38dbd336c12ca05e61ae474fc3540e3780da64432d6cae23de1ed5</span></span> <span class="giallo-l"><span>00722,</span><span class="z-keyword">0x96e85fdbaab8e3e96a18a455b6f7c52dfc256146b15b4a17cd5349a1e05dd900</span></span> <span class="giallo-l"><span>00723,</span><span class="z-keyword">0x78bf01d3000e5bf37d29358748ec99c6e4eb1d6e3203dcb914b0b7009bb475b7</span></span> <span class="giallo-l"><span>00724,</span><span class="z-keyword">0xd7c27830b175b06d64f2c9e7f6533d396a6527aa8078030d35e2997805031dfe</span></span> <span class="giallo-l"><span>00725,</span><span class="z-keyword">0x8859c97fca028d013b18ac01644d4070df18cb369a380207c646808ee242d99e</span></span> <span class="giallo-l"><span>00726,</span><span class="z-keyword">0xa705da9bf450e3f38cbc0916a3430caf7b7c2e5b84b0eed30865c21417a787e9</span></span> <span class="giallo-l"><span>00727,</span><span class="z-keyword">0x58d8312647f7b4f93bb4e166ebefe27b4031924f7550d9ba1d2ab7fa58fbd547</span></span> <span class="giallo-l"><span>00728,</span><span class="z-keyword">0x2daec9311d82d342bf0a5f197beda1aa5bec47277d79baccc91d033c2151d583</span></span> <span class="giallo-l"><span>00729,</span><span class="z-keyword">0xfe141ac786b2e586770563dd5812bab7673e4939e29473e6c4a1a75d5217bf13</span></span> <span class="giallo-l"><span>00730,</span><span class="z-keyword">0x4ab51ad5fce5b07c3935e88c8a21e911e30fec10a5066b79e0d01df2737bd613</span></span> <span class="giallo-l"><span>00731,</span><span class="z-keyword">0x11b0f603bc13ce8a712ca6ef749c8c923097c455c6b86386f166b1e47daebfd9</span></span> <span class="giallo-l"><span>00732,</span><span class="z-keyword">0x3e648126f5543d814037eb55ff7d4079433fb586ec6b3a2bd0ed968f8fed9603</span></span> <span class="giallo-l"><span>00733,</span><span class="z-keyword">0x87195980bf623a55f7bb30e396648aecd839768429e6dc5ecd3417dc44c6521d</span></span> <span class="giallo-l"><span>00734,</span><span class="z-keyword">0x1a924a1baf8970146ef21e1ae77cbececbadcb975f4f950314313381d50fa823</span></span> <span class="giallo-l"><span>00735,</span><span class="z-keyword">0x34d9d6a7333d35e1f16458eb9bcac884e81f93dc421c3ad47b7a46ea6f929c7a</span></span> <span class="giallo-l"><span>00736,</span><span class="z-keyword">0x1569f88b5514b6f98302427c8ab4b4b6c020b517b290b2c7b1e8b6b9ee2b74f3</span></span> <span class="giallo-l"><span>00737,</span><span class="z-keyword">0x288181ee87c7c1f4c8052ae1692959d57f9f4b123014deebfeeb6df20dfaa424</span></span> <span class="giallo-l"><span>00738,</span><span class="z-keyword">0x28dbb0e5bd25ae20d92b68183f093bf002cb40e2d0e7b9597ea6e58478db184b</span></span> <span class="giallo-l"><span>00739,</span><span class="z-keyword">0x4bd79b88bf29f2048cff7bb28f048b67312009bb49d5c33e0a8df28fb26de7b7</span></span> <span class="giallo-l"><span>00740,</span><span class="z-keyword">0xc84ee78099163d07ff47d4e2f864338e0fcbdaa1298b6fa71352e6896655b918</span></span> <span class="giallo-l"><span>00741,</span><span class="z-keyword">0x2aacc622a545af97bb40c4d5decffd5142427c482ca5bb8ef7f29951e1807e4d</span></span> <span class="giallo-l"><span>00742,</span><span class="z-keyword">0x165aa7d2b8608774366225bc7252056104da64abd35ddbd1db832ae375bb6031</span></span> <span class="giallo-l"><span>00743,</span><span class="z-keyword">0x4505bedc2d45231f48b90817f82a686da0f8b362a79bb0d774cb396288491461</span></span> <span class="giallo-l"><span>00744,</span><span class="z-keyword">0x08785ac95582347c80d4321d003a4c31d343effc0cc8e8d4a32f8370996123c1</span></span> <span class="giallo-l"><span>00745,</span><span class="z-keyword">0x6ea3cb82c7125522aa5fe08d65c4edcd10e1823d312f13288c5ae9b69b2d2935</span></span> <span class="giallo-l"><span>00746,</span><span class="z-keyword">0x3ec58c854981ed2f44dd8516cf166b12232e5e32d2fbeddf070fa45a1d8cc638</span></span> <span class="giallo-l"><span>00747,</span><span class="z-keyword">0xaaaebe5b4f04d2085247c7c9855d1add2e8f0d7e545c532cde20b6145ea711fd</span></span> <span class="giallo-l"><span>00748,</span><span class="z-keyword">0x5ab3b22293636bc4bb517aac1a3c22fd297cdf1c8da5cab2353c7b657208f1d0</span></span> <span class="giallo-l"><span>00749,</span><span class="z-keyword">0x27aebfb9c574b6b4a90161369be8e3361b887534f6031f35654424c9d50e3efc</span></span> <span class="giallo-l"><span>00750,</span><span class="z-keyword">0xcc08abf8cae1d37837d395bfd9094e01b70dd66c8cfc9800fe8fecb4b2b09599</span></span> <span class="giallo-l"><span>00751,</span><span class="z-keyword">0x032ebacd972a00b4cd4fc81ee4e8499468ac379eabf1de2762e98aaa957e4cca</span></span> <span class="giallo-l"><span>00752,</span><span class="z-keyword">0xf09c12bf003999d4e98769faca1a7c12352abd26bfb290a048b846c669bbfc89</span></span> <span class="giallo-l"><span>00753,</span><span class="z-keyword">0x876733dd576846ad12f5967b4c131194b19013232b270faa88f816795c403e6b</span></span> <span class="giallo-l"><span>00754,</span><span class="z-keyword">0xf50f5eb285818911c3fc43b60174f25a9e5b9dcac9a5f3e6914d8b0af439234a</span></span> <span class="giallo-l"><span>00755,</span><span class="z-keyword">0x4d52bb12e70194eb981ae85c08a02d16b7e899262dc34e7b028eda0a123421a2</span></span> <span class="giallo-l"><span>00756,</span><span class="z-keyword">0x0af4e42bc526ccc68e29d057456f30076323afdb70a6aaecef47cb316a689c88</span></span> <span class="giallo-l"><span>00757,</span><span class="z-keyword">0xd1988f793da01c8d63bbd508befde9fe8ccc1f2f5974d9bdf0b2d8afa0b9f997</span></span> <span class="giallo-l"><span>00758,</span><span class="z-keyword">0xc66fcb070ebb36a3ef93360bb74079d15f8c4cad6fada6a408dc33f982308279</span></span> <span class="giallo-l"><span>00759,</span><span class="z-keyword">0xa6242a1ccc07f0b240026340ccc6d91d99396732364858d8dab438965f90545d</span></span> <span class="giallo-l"><span>00760,</span><span class="z-keyword">0x824af748696096e08232cea82a07f15a590908d73e4b72da6733ed3dce3ce648</span></span> <span class="giallo-l"><span>00761,</span><span class="z-keyword">0x76b41584de30eb80fd613f82c44d7fa70aff42a1760221e3852d8865923ce75f</span></span> <span class="giallo-l"><span>00762,</span><span class="z-keyword">0xb3ed5869910b3b75a102644af13fb642991e19aa885848ea9099f31091cffe0e</span></span> <span class="giallo-l"><span>00763,</span><span class="z-keyword">0x713aaaf6faa21e1ace76e89e35cb9cadc04e01a6808e264dc08075a0a4074e09</span></span> <span class="giallo-l"><span>00764,</span><span class="z-keyword">0x3a6de7d91da79fe7ceb3f9ab4634e88efb40832ef2e776624ffde6b3d37b6443</span></span> <span class="giallo-l"><span>00765,</span><span class="z-keyword">0x18b5d60216a44d195c8c533a95a82c1cf17184393db431accc269b8f759f6341</span></span> <span class="giallo-l"><span>00766,</span><span class="z-keyword">0x6b5ade6c06f8ba9ef42f64369a90145db95ee3f84c7ef2f4cc0bbd088d400287</span></span> <span class="giallo-l"><span>00767,</span><span class="z-keyword">0xa008476355318634f1f429e5921b41860e1f2b84a56f25bfc4d1bb3ad99e339d</span></span> <span class="giallo-l"><span>00768,</span><span class="z-keyword">0x8dc563b6cdbec477ab54634e7dbe0a986ea6f745e81d1fbe2d9ee2036222f50b</span></span> <span class="giallo-l"><span>00769,</span><span class="z-keyword">0xefd6696f77b898d126c7df1d9f481853086479c17279d5d138348e5202bce86d</span></span> <span class="giallo-l"><span>00770,</span><span class="z-keyword">0xd9db47f4de8d5d1c4700ea620d918e8ad0877e06d40183790fe55bf6a334748a</span></span> <span class="giallo-l"><span>00771,</span><span class="z-keyword">0x2aa70a70c541cd444fd2caf88968d737fa7df568af3e13526cb9efd7d0c340fb</span></span> <span class="giallo-l"><span>00772,</span><span class="z-keyword">0x44dcb9abd03e34d90516dfcf01de57529d8e5efe899d526fb222840547e98dd8</span></span> <span class="giallo-l"><span>00773,</span><span class="z-keyword">0xe4dcc8e85df47ef9e3e5ca5d5fa8bf8597cde9c9234f6ee5020260e69e911b2e</span></span> <span class="giallo-l"><span>00774,</span><span class="z-keyword">0x63f82331a80309f20bd3c9500671446c81923ce5023224f9502343c7db25d83b</span></span> <span class="giallo-l"><span>00775,</span><span class="z-keyword">0xf24f282ea23a59a5c6451e66987eca682686d8b5df910676b2fcac68e675a3da</span></span> <span class="giallo-l"><span>00776,</span><span class="z-keyword">0x382525f177efd6e19eb9949fdf8f31802f86c7754d43898dafc36eacdcf72db8</span></span> <span class="giallo-l"><span>00777,</span><span class="z-keyword">0x2d3a5e7ae6a0aa3498ff29bd9c01bb50be16608071cdc311690b08d54b81ceb4</span></span> <span class="giallo-l"><span>00778,</span><span class="z-keyword">0x9a24e96613beb77c7482edb95e3bd149f3a95df7fde1e01c23eff75a71f73dd7</span></span> <span class="giallo-l"><span>00779,</span><span class="z-keyword">0x0be7242c1c73f21c6912fe398bf625f142d4b00f260cd0169b82162c7b215da0</span></span> <span class="giallo-l"><span>00780,</span><span class="z-keyword">0x0b8c7a94e807b13c8053ee0c97d5f38f263e31d9fa703d9b11de00c7d4c7945d</span></span> <span class="giallo-l"><span>00781,</span><span class="z-keyword">0x6e9ae0809cf9e38136a64b629b4b58f37bcbf54b6744ef3121403abb14b1582b</span></span> <span class="giallo-l"><span>00782,</span><span class="z-keyword">0xe888e6c289f0734c57b9c61c1b6798e5d94139252173305a7764c8c4cc9da157</span></span> <span class="giallo-l"><span>00783,</span><span class="z-keyword">0x03027295eb991e1dd03d652ebc3ac786ee4c263504a78fe31398341844f235f4</span></span> <span class="giallo-l"><span>00784,</span><span class="z-keyword">0xb6efb516952e014d0e2197320e521f15d58f6eb8c88bae72fed90c570ec3bf85</span></span> <span class="giallo-l"><span>00785,</span><span class="z-keyword">0x79728b75e2cbcd3ec3a144ad474dd75eac9e1dd898fb3c97023c4edfe7d91890</span></span> <span class="giallo-l"><span>00786,</span><span class="z-keyword">0x0586eef4843820a247d8f8201c6b77e828096bc02c4c5bc3d2c3b83bf42ce549</span></span> <span class="giallo-l"><span>00787,</span><span class="z-keyword">0xa0d4c8c20e3a37f678959b563859677050107b0e63d043ca1930dd48a93c0311</span></span> <span class="giallo-l"><span>00788,</span><span class="z-keyword">0xa55feb48d4922a3189983989333d70c7fc6b18656446bce243eaf77fd21c54bb</span></span> <span class="giallo-l"><span>00789,</span><span class="z-keyword">0x9b95d3aa1408771b1e1e743db3216bf9e512a1fdaf6035f7a9f40e3019e9134c</span></span> <span class="giallo-l"><span>00790,</span><span class="z-keyword">0x4a62280eabc47623a8015bbbdb99a64521c554491b9ca4baee28def4c857cfa4</span></span> <span class="giallo-l"><span>00791,</span><span class="z-keyword">0x064776dafa35a56678a5574157b74c8e5f1433d823f8addfacd972e0d2dfa90b</span></span> <span class="giallo-l"><span>00792,</span><span class="z-keyword">0xe9a295429a1b3fe4ae05e4444fa3e7939ee234416505e5bb12533e45204ccce8</span></span> <span class="giallo-l"><span>00793,</span><span class="z-keyword">0x93ac12baf1d3519d2d6db741537a098b5b97e00c7044e96eb2c49900a7d3c3f4</span></span> <span class="giallo-l"><span>00794,</span><span class="z-keyword">0xb199a3097a3b71bb74286673315795e98805a6951174ec6957b80bcadddffe1b</span></span> <span class="giallo-l"><span>00795,</span><span class="z-keyword">0x284915ec1b0af683caaf90546c773bdb1e950f8923f9468192e160aa757a4869</span></span> <span class="giallo-l"><span>00796,</span><span class="z-keyword">0x80b8a59801157a40d10e17c3915a16f78eca8b03998466f59ce4c4f910ac0760</span></span> <span class="giallo-l"><span>00797,</span><span class="z-keyword">0x40e902aaa84d1fa5c8cfc7ec95846be5b541c785a9514f6886257431d7c7d5e7</span></span> <span class="giallo-l"><span>00798,</span><span class="z-keyword">0x25bb39c7596cf80eed1af44ca924abd9f738b386cc3604beb0cc0e139b570a5c</span></span> <span class="giallo-l"><span>00799,</span><span class="z-keyword">0x565a1bf8ee5e84e7e9ff397ee36a656ffa670321bacd7533e77eaf91ea104561</span></span> <span class="giallo-l"><span>00800,</span><span class="z-keyword">0x6723d6d967dab127477429efceb7f975d2cec28aad8ddb603fef54cc69fdc6b0</span></span> <span class="giallo-l"><span>00801,</span><span class="z-keyword">0x2c9057ba31e7f3ddad8a3324a066efb9353cbdce8e399ba3061531737b118713</span></span> <span class="giallo-l"><span>00802,</span><span class="z-keyword">0x75e347ad895b4b6dadad02d048f988ec7298298756d55d924a6605e3ce2bc9e6</span></span> <span class="giallo-l"><span>00803,</span><span class="z-keyword">0xafb8c20ffd497fd6ed9ce26ae25f7a83c66e30bfbae612cf83dd83972a75d7f3</span></span> <span class="giallo-l"><span>00804,</span><span class="z-keyword">0x472b0432e2d130803fee6986e35c0decf8989cb0d0645cce4848848a30cc990d</span></span> <span class="giallo-l"><span>00805,</span><span class="z-keyword">0xa00ad7738c5a78e98095ad2803f5f02736ddf5fc471940d4d01642317be7bafd</span></span> <span class="giallo-l"><span>00806,</span><span class="z-keyword">0x4fabbfd520862fb8c2a3cef755e30fab50f8e235460924f43eb239e3276738da</span></span> <span class="giallo-l"><span>00807,</span><span class="z-keyword">0xebadaa845247da44fad909d4bad16b43a5e63c6f48bc3eaffe2b98b27f9e1c3d</span></span> <span class="giallo-l"><span>00808,</span><span class="z-keyword">0x71a5a039aa5425f801492260210074426cf5deb420cb2ddf9defb3601564f0d5</span></span> <span class="giallo-l"><span>00809,</span><span class="z-keyword">0x2a78afe865f39dadda88e3d3d493b6be19af8374a62f0b48c3cc8b41e28227aa</span></span> <span class="giallo-l"><span>00810,</span><span class="z-keyword">0xddc911377e4dd2291f709e0243a6cc7331a49aa27aab1ef211470f4662c8e460</span></span> <span class="giallo-l"><span>00811,</span><span class="z-keyword">0x47305f69611d5c09e9f302c34c1a491b8166f950f14fa56ed0885c11257f0224</span></span> <span class="giallo-l"><span>00812,</span><span class="z-keyword">0x6492e81274651a77c064ac8a6cec00c509e58de9a951070770cab002658d662a</span></span> <span class="giallo-l"><span>00813,</span><span class="z-keyword">0x9ccf4c433a7e66762068756cbde59d2c603e1dc1d64cd0e61bd39bd636ddd877</span></span> <span class="giallo-l"><span>00814,</span><span class="z-keyword">0x02f878d63294625f5b8e01973359df0621504feeb548141ee1fabd1747bb2f4e</span></span> <span class="giallo-l"><span>00815,</span><span class="z-keyword">0xe97a4d00ec948995c670a9c30441ca9f510c6369f00ef2fb38624f14d8531eb8</span></span> <span class="giallo-l"><span>00816,</span><span class="z-keyword">0x13c60a90e71fbfa321264b1dfbcdf76d0b15f3adbed05f31b02848e4fddad79c</span></span> <span class="giallo-l"><span>00817,</span><span class="z-keyword">0x6f8e5552d9e7982de12d6cca3368f02671fa6b071f0618876d4a1e9a4d79a3ea</span></span> <span class="giallo-l"><span>00818,</span><span class="z-keyword">0x8143cae1101045cfd98b8202617280228a5b68c0d4f37180b79327d4fd555a61</span></span> <span class="giallo-l"><span>00819,</span><span class="z-keyword">0x3894e28cbfa568d39fa7db232e4954e9c14f36eccbcc4c1d35cb8562285fbcf2</span></span> <span class="giallo-l"><span>00820,</span><span class="z-keyword">0x97b69aecc1068e3d89e32195d6b0058b13a2b762cdfbecee7d54256e67bc4b81</span></span> <span class="giallo-l"><span>00821,</span><span class="z-keyword">0x22732c1861dceac8803885adf29e9c9b7758ee5c2de3660d175aec67e0deb2d8</span></span> <span class="giallo-l"><span>00822,</span><span class="z-keyword">0x6977fa0d3194c37772fb68df9929cc9974fd9441cd4881adf20e17408465d544</span></span> <span class="giallo-l"><span>00823,</span><span class="z-keyword">0x0d164934226bdbae6b1a9c2e284a02bfe3e7552ac901576e33aee614f8f4d9e1</span></span> <span class="giallo-l"><span>00824,</span><span class="z-keyword">0x0de9eb6ca895573dc439ff773e617cec54c9a3e83c8412ae6bed73594f51845c</span></span> <span class="giallo-l"><span>00825,</span><span class="z-keyword">0x14eaae6399e76bb8c66fbf9cf4333701bfeda482cc347590402ba802332e5610</span></span> <span class="giallo-l"><span>00826,</span><span class="z-keyword">0xe0848f10dad16982805b6bc7f6151605db509bb228fc49dc647bb472c0fdd83d</span></span> <span class="giallo-l"><span>00827,</span><span class="z-keyword">0x6846201d042855e80cd3e2a1b2f5f0a6360d499cd803900873c1900264e45448</span></span> <span class="giallo-l"><span>00828,</span><span class="z-keyword">0xe89c0e11010967dc5ceb97b9ef40a45f36ecd9390c82b58d95592deb04b6e746</span></span> <span class="giallo-l"><span>00829,</span><span class="z-keyword">0x3096af7600019e93e14000a119faa50fc3c60c4fedfab2b65ef7c5e76c40dd2c</span></span> <span class="giallo-l"><span>00830,</span><span class="z-keyword">0x55e8b4c2d3dc809690f3276cd43ddb11b907c7a975de41041a1cf47e6fd535b7</span></span> <span class="giallo-l"><span>00831,</span><span class="z-keyword">0xc501837ee2c215da498b734153628de1acc5d433179078696ce82a4f2fda42c1</span></span> <span class="giallo-l"><span>00832,</span><span class="z-keyword">0xf7000808e45b53416da880d5a8a6face40cb10a55fd1a9f4c07bc125da165ea6</span></span> <span class="giallo-l"><span>00833,</span><span class="z-keyword">0x5d73b97ad48b73368898a1e39b0f725c43ca3757b9224dacd2f8db81b90d6807</span></span> <span class="giallo-l"><span>00834,</span><span class="z-keyword">0xf240decca5d9b9a21a75948716f83b68499f5f260fba9e535320d7ad2b8f654f</span></span> <span class="giallo-l"><span>00835,</span><span class="z-keyword">0xfbd0a3686d9e771cbe2410e0eaaa2535d140a5b5628d2dc5b79afe2a54da0255</span></span> <span class="giallo-l"><span>00836,</span><span class="z-keyword">0xfbd2c4fe042a2c0c30942153fd2b2a148fd11275cda67d7e945ea50d8ce9588a</span></span> <span class="giallo-l"><span>00837,</span><span class="z-keyword">0x8bdc330460491a8d07586f41f6c980500b273533b9a98d0d0d180230a35abe43</span></span> <span class="giallo-l"><span>00838,</span><span class="z-keyword">0x2a2047ce16869ba58f7aa520202bc2c2345fac6bfca50e06194361165cedc4ad</span></span> <span class="giallo-l"><span>00839,</span><span class="z-keyword">0x84c88273e2546de530b060ff56c8c9fe3aef02cc968fbeac333fdc4de9c49cde</span></span> <span class="giallo-l"><span>00840,</span><span class="z-keyword">0xb96ae20a3f7c6cb7890d5f72037ba8a1a8be4e4f758be430f089ba62c9886887</span></span> <span class="giallo-l"><span>00841,</span><span class="z-keyword">0x5cfe6abdb5b075a8fc721d49e76d0c136de22d165ff61d27a7acf7050d84a31d</span></span> <span class="giallo-l"><span>00842,</span><span class="z-keyword">0xb7d8f3a61da1cf210b8d80336009634c26f97ec52375533406ac0f0f7e22f5fb</span></span> <span class="giallo-l"><span>00843,</span><span class="z-keyword">0xc14d7f51eb905c4e662965caae40a537cb7a85d85458a5508e91a2498e479fd4</span></span> <span class="giallo-l"><span>00844,</span><span class="z-keyword">0xc5eea731a2a18fbbc08066a06515c8f05d8838912d961c32b31ac31736d8e5df</span></span> <span class="giallo-l"><span>00845,</span><span class="z-keyword">0xaea57615f40fa35e4c73f273cee2b1f077838a18001e8ddb9e87d28286149014</span></span> <span class="giallo-l"><span>00846,</span><span class="z-keyword">0xbe228f4af7a96d9c1cbbd4e76864e68c332232ba5ce81de3e11c0d8b33bbf1ad</span></span> <span class="giallo-l"><span>00847,</span><span class="z-keyword">0x5721c5a99dfa32e02559d43450e95be7f59d245160fce626eb8e5c81c271be87</span></span> <span class="giallo-l"><span>00848,</span><span class="z-keyword">0x4f17a7ba2d98477f2d2b3ade28f2107d35516e8f953b636ac1f6014f4d1c2204</span></span> <span class="giallo-l"><span>00849,</span><span class="z-keyword">0x81731fd5dd5f8ba504c4c3bd1080eddb3e400e8655bfb1e93da5450177923ce8</span></span> <span class="giallo-l"><span>00850,</span><span class="z-keyword">0xc8596aa574934f8d7b7a0c938ce736d7da8c63dc40bda9719b1469d1ef93ba0d</span></span> <span class="giallo-l"><span>00851,</span><span class="z-keyword">0xd9d76d294b8224a90bd65300b2bb1c3c5e53441b3182c5b0d41011f626046a9f</span></span> <span class="giallo-l"><span>00852,</span><span class="z-keyword">0x3db9cab96ffd143cf6bf1c330e6cef7467783d82443e5122006e5d2fa200f1c2</span></span> <span class="giallo-l"><span>00853,</span><span class="z-keyword">0x05eacb145ed3b25a1949999d28e34eaf4aaf8cc033cea6569f8b53a4d49199cf</span></span> <span class="giallo-l"><span>00854,</span><span class="z-keyword">0x787444532a61379ba993a92688941b3fac90f64fcf9a32d022ef0cd78544f813</span></span> <span class="giallo-l"><span>00855,</span><span class="z-keyword">0xb042cdda0306e8678b89046603d24839002d4916d40849b5dc9e65f3124952f0</span></span> <span class="giallo-l"><span>00856,</span><span class="z-keyword">0xc3dd963be82c9bd8bd0a27cf846b0fc901d63b7a5de84844305385a2de4dcb57</span></span> <span class="giallo-l"><span>00857,</span><span class="z-keyword">0x1caf90ed8dc29fba89264af3ba07d0874e2f03c223cf387fec52bb0b7c4c5017</span></span> <span class="giallo-l"><span>00858,</span><span class="z-keyword">0x7d89c8e7e7bb553c60a7fff4c056575791ef965ece8adcbb8923c17c2ca42403</span></span> <span class="giallo-l"><span>00859,</span><span class="z-keyword">0xec9f0685cf4c7e59b45c2627b98afbf56f2d113415af631bd875962dabe376ba</span></span> <span class="giallo-l"><span>00860,</span><span class="z-keyword">0x608f5138cd3fdba7adca86cca1623b02d967a4ddfdabc1626298aef841f06e98</span></span> <span class="giallo-l"><span>00861,</span><span class="z-keyword">0xbc7139248334659528164fddc3c05f6933494abdbee4e82b5c16960461fb6bb9</span></span> <span class="giallo-l"><span>00862,</span><span class="z-keyword">0xf5d2654fda6b2a14dfe9f390fe8464887263d7415ab839418c21db6d00b75e02</span></span> <span class="giallo-l"><span>00863,</span><span class="z-keyword">0x29f0d1bd4ed36f2a8fcddc968249af476e48f49eafa8c1cb3ddaef3c9f6fbb5d</span></span> <span class="giallo-l"><span>00864,</span><span class="z-keyword">0xba09ed24136ed4ecce9e3aca125ba9cffdb949164e4ac0115a7e5636bae9ff81</span></span> <span class="giallo-l"><span>00865,</span><span class="z-keyword">0xef98f25e48fa78413bfcb8bc7d7bfede024ae12b74727667431d0b7b24c88197</span></span> <span class="giallo-l"><span>00866,</span><span class="z-keyword">0x62ec875a0d3529f36a0559e183518082de0a399e1b4840e3d5d23b4ea1e6adcc</span></span> <span class="giallo-l"><span>00867,</span><span class="z-keyword">0x6e38f92d9e902c7c4e46d334d8f15126fd82a220c3529cecddde6b7892187ada</span></span> <span class="giallo-l"><span>00868,</span><span class="z-keyword">0xada339e00fa18f5a7a48601c4d9db77332f4df313771b2a166bcdf02c07b5dad</span></span> <span class="giallo-l"><span>00869,</span><span class="z-keyword">0x687f70ac1c22d04c591b239219d4cea3fc899e22a15656cdadbfffee43900445</span></span> <span class="giallo-l"><span>00870,</span><span class="z-keyword">0x69305b6644efa1ddeffdbb7c5fbd55450e67237a3bb38fb8f08e81c567952569</span></span> <span class="giallo-l"><span>00871,</span><span class="z-keyword">0xdfb483577885f06bf36bda6c0918ddbb8ff30612412e6b4a67cc4bc867f2c44c</span></span> <span class="giallo-l"><span>00872,</span><span class="z-keyword">0x1fe0bd683f075a332f51a8d355282e02186aaa79a97f75c6a317dea751ed8b30</span></span> <span class="giallo-l"><span>00873,</span><span class="z-keyword">0x6754774ca2adf65caf7d126d0a1b7a3a9e9385968e96d8ed20389a3c3a96895b</span></span> <span class="giallo-l"><span>00874,</span><span class="z-keyword">0x89ed1e981eaab47a9b1afe89f4d8fd3eb60d208cd9cc2cd3c94c2a5e784f3bf0</span></span> <span class="giallo-l"><span>00875,</span><span class="z-keyword">0x918e70e47775c40e4aa6674b40d2f502e26dea08e7fdcc95fc612f9411268617</span></span> <span class="giallo-l"><span>00876,</span><span class="z-keyword">0xb174fe364a001d733d0ea0de0724d33c30d59ead3ba2f7c318322935c17b9027</span></span> <span class="giallo-l"><span>00877,</span><span class="z-keyword">0x1ee06c6001f96af9abdc53c79801ed63bac846f1de194b8e31fb0e99e6cb2dee</span></span> <span class="giallo-l"><span>00878,</span><span class="z-keyword">0xacf82dea7eff2b6749a07263ad51979a18d25e10191259c97531804deffe5f59</span></span> <span class="giallo-l"><span>00879,</span><span class="z-keyword">0x194ae19978f7ceff5b951ccc21ca69e4093db9f14b3dd735675b658614b50163</span></span> <span class="giallo-l"><span>00880,</span><span class="z-keyword">0x88dc77d7fb4be097712c34808ae6bb09f4adc13e82457e2bdb930cf79cbb08d3</span></span> <span class="giallo-l"><span>00881,</span><span class="z-keyword">0x291ee430fcbda963ea5ab68df639ea92ce325530844b6e5b43a306fbd3bf86e7</span></span> <span class="giallo-l"><span>00882,</span><span class="z-keyword">0xe0bd01b96a078f578b599838c06357e455d023c72381c0c9d96d2a57099f038a</span></span> <span class="giallo-l"><span>00883,</span><span class="z-keyword">0x24ee5653b2b7060f64b723f52723897140c6a39d07a35da8b362335a12fdda1e</span></span> <span class="giallo-l"><span>00884,</span><span class="z-keyword">0xf46491735b52306f745dc8a439441898c7a9dcfe6301ef0cb0f933c55d8b9432</span></span> <span class="giallo-l"><span>00885,</span><span class="z-keyword">0x18be58079d1320046e689e4fe43cc04d43cfa1794999974288fcf3625e6411a4</span></span> <span class="giallo-l"><span>00886,</span><span class="z-keyword">0x7b8e7f87674815b502a57c0797eca3288e0b5ade2a8ca7f78dd7ba632b127e25</span></span> <span class="giallo-l"><span>00887,</span><span class="z-keyword">0xebfbdc0207cea435c10b7052a0937c699721b2e7e41a2d925d0eab2ab81e9c8b</span></span> <span class="giallo-l"><span>00888,</span><span class="z-keyword">0x2911ec4630e2dd25d76cb86d8ad8427de4fca247c5e641ff2ae16038edb9ff52</span></span> <span class="giallo-l"><span>00889,</span><span class="z-keyword">0x7bc66f0a17605a2e0a082da2f3f99d6d424efa091d15c856e0bab50875629e07</span></span> <span class="giallo-l"><span>00890,</span><span class="z-keyword">0xde4cc0f167df6278f89a5cd047e8079d7e9368fed79d2ecb3e8b31537f744260</span></span> <span class="giallo-l"><span>00891,</span><span class="z-keyword">0x1aa1a5b9610ffa5b41fac5bd68fcc7f767d3434baaeea70e20f738d369a44315</span></span> <span class="giallo-l"><span>00892,</span><span class="z-keyword">0xb5354846b7a3b0764849ba2c006bbd7ab19d10f2479bd99c822442214eb135aa</span></span> <span class="giallo-l"><span>00893,</span><span class="z-keyword">0x75d76eeec8dd8ee7b5849b76e8e3c5b363adbf59fed68f0df8c89ced4106ff94</span></span> <span class="giallo-l"><span>00894,</span><span class="z-keyword">0x81aa556ec3ccd95dbb8e26a987f6e0434ca41766f68949258ce05f805f74a808</span></span> <span class="giallo-l"><span>00895,</span><span class="z-keyword">0x4704352715ff20066ba6150a55318d0e9066ae548b4375e4ce9b31e530598c61</span></span> <span class="giallo-l"><span>00896,</span><span class="z-keyword">0x1ab5749f22bdf79c27d6a073d93687b6e375b33f38cda1d8ea1b8aa794c0de76</span></span> <span class="giallo-l"><span>00897,</span><span class="z-keyword">0xb81f63bc9725916a88ddb5a5a6d7b7d558afb1d55bf29d57952da749e99ecbb2</span></span> <span class="giallo-l"><span>00898,</span><span class="z-keyword">0xac96c90242fbe989a37f1711dfed7051aaa38a13d8e8bc3ca5a518a90713cccd</span></span> <span class="giallo-l"><span>00899,</span><span class="z-keyword">0x922b1cf4946990d76e6aa05024474ffce4b71c683db79dcd7d08fdafe537d04c</span></span> <span class="giallo-l"><span>00900,</span><span class="z-keyword">0x0f8ce28573d070b2160ba328d9eaa3d81af5b60443acea676cee7cd234f0dc9a</span></span> <span class="giallo-l"><span>00901,</span><span class="z-keyword">0xf6f06a90999d172458e44c324081d1ee668709a2e4273a35fbfcf1312b913999</span></span> <span class="giallo-l"><span>00902,</span><span class="z-keyword">0x65bd2e95f8d26b9e2b3360b40175eb62b0881772fc80085a3d872a533362f5db</span></span> <span class="giallo-l"><span>00903,</span><span class="z-keyword">0x3b916edf62cfaa0bdca3d8b3f13b9654ace5f3a1c6c9a787dc07452b69cd985f</span></span> <span class="giallo-l"><span>00904,</span><span class="z-keyword">0x2ebf7c0d8151e785e5eb6ffbda1269e7d9d7f36545711099119ec1d486642994</span></span> <span class="giallo-l"><span>00905,</span><span class="z-keyword">0x9e7868aa92b87527f63245914226d675e3d09172ef63e3191562d1869ccfd5f2</span></span> <span class="giallo-l"><span>00906,</span><span class="z-keyword">0x6fe8a5a96b514f6763167cd7925516af89e4014baae26d735fbfa65dc9ee1fd8</span></span> <span class="giallo-l"><span>00907,</span><span class="z-keyword">0xfc681d3f63c0705f771f6f7cf8fbae11076db7aea57e4aa4db082fc82324eaf4</span></span> <span class="giallo-l"><span>00908,</span><span class="z-keyword">0x65f7339775a6fcd357411605348f51cf908f2a6bda04b392ce76132c1fc5a40f</span></span> <span class="giallo-l"><span>00909,</span><span class="z-keyword">0x38ce4f9f511d38303d855f92e28b6e096b749211b0861af2aee292fd34ab3af6</span></span> <span class="giallo-l"><span>00910,</span><span class="z-keyword">0xd44a929f41f40d97e7767775efbcf22213dd313c0bbbecbfe6130712b28b2fb2</span></span> <span class="giallo-l"><span>00911,</span><span class="z-keyword">0xfc91f464f9eae7f2fe1844bcd1c304c8467227c5df40b5518f2d262e14aeb011</span></span> <span class="giallo-l"><span>00912,</span><span class="z-keyword">0x9acf8a7ebab7d5ea23e59c7434b854b29d79a7d52153264f96886051df865c23</span></span> <span class="giallo-l"><span>00913,</span><span class="z-keyword">0x0790733786688f30e6d7d11388f7daf100afa105770f218e84321adc6427fd24</span></span> <span class="giallo-l"><span>00914,</span><span class="z-keyword">0x822dfb1aa7d617e0cdb16f997d992e643890aa048e9fbf89051e42349602ace9</span></span> <span class="giallo-l"><span>00915,</span><span class="z-keyword">0x62602cadc14d41fb1a9d1c682afdbdc3a535828fd89ab1474040dd571631207d</span></span> <span class="giallo-l"><span>00916,</span><span class="z-keyword">0x8b6dd223bb5846cf7af3766332bb4a3c7d0075b350f82c907db76a2765be8dbc</span></span> <span class="giallo-l"><span>00917,</span><span class="z-keyword">0xb309c46944a731132a289569e9cf52c57e9921b99cb00d02926f93fc83d6e86d</span></span> <span class="giallo-l"><span>00918,</span><span class="z-keyword">0x8974583a7b7ae104b867fa6ea76b999ddc399498dc070cd622df9b2eaadcf4a6</span></span> <span class="giallo-l"><span>00919,</span><span class="z-keyword">0xd139d7b42b3dc5b0316ec6e718f6ed470c2b8063357ca6a5525eaedfd77fe93a</span></span> <span class="giallo-l"><span>00920,</span><span class="z-keyword">0x5b83da490a1580b57e046be20c03b6f6b9378cfb8b8313a2d58cd10bac12884b</span></span> <span class="giallo-l"><span>00921,</span><span class="z-keyword">0x7a62f3b8756e0b45061ad40d0d08a4f400abcc7f8f9d21c4eac35d5eb3c69032</span></span> <span class="giallo-l"><span>00922,</span><span class="z-keyword">0x30f2071bcc7e743301be529cce48170478cf733c09f76bc7a007486e907b8d42</span></span> <span class="giallo-l"><span>00923,</span><span class="z-keyword">0x9f05e1511533dd79377f64581191380f2a4414538f9812bc978575ade32e4747</span></span> <span class="giallo-l"><span>00924,</span><span class="z-keyword">0x8d0da5014bf3664e6f3ee37a221447169bc7ef4cc2a98fd8141462fd4e6eeb28</span></span> <span class="giallo-l"><span>00925,</span><span class="z-keyword">0x9de1930ee287c457d1d7e31f789e7d73dbd9b2ae0b1db00a74a8ce7dcf8b022e</span></span> <span class="giallo-l"><span>00926,</span><span class="z-keyword">0xac17e41e8ebb278089444caf7fb6de4be8be17e0d2737713c19ee56e233b8052</span></span> <span class="giallo-l"><span>00927,</span><span class="z-keyword">0xad6865ca7acf691972f0906fa666ed8742cff9e41ccbf870f1c2e6c8566e1597</span></span> <span class="giallo-l"><span>00928,</span><span class="z-keyword">0x3feef311a950eb4f513f3f125bf4941b2664e7696c637c0998aaec146910944d</span></span> <span class="giallo-l"><span>00929,</span><span class="z-keyword">0x6e2d1f4b1c5ebbb67159e8db1774180c58e50b633117fa630e99025a4b648b12</span></span> <span class="giallo-l"><span>00930,</span><span class="z-keyword">0x228684d7571e71ed0dc00adc98f4ed6242dadbc65bffe61c131c91e396206d0e</span></span> <span class="giallo-l"><span>00931,</span><span class="z-keyword">0x2485471e5350c5da449bbd5b6cd731be0a47123f5b26becf1790b2a65e8ea608</span></span> <span class="giallo-l"><span>00932,</span><span class="z-keyword">0xf2f69e075dbae9462a935692b7dd566909e2d95734929376b0b7be14e0d42fd2</span></span> <span class="giallo-l"><span>00933,</span><span class="z-keyword">0x44eff5aecb4e111871225cc1b58c1c04786b1a4aba892784b7551b9e8ba90595</span></span> <span class="giallo-l"><span>00934,</span><span class="z-keyword">0xac8cf5be8f250e984277952c431a84b01c0ebd96e4d46cb1b456d0aabe2fa7e2</span></span> <span class="giallo-l"><span>00935,</span><span class="z-keyword">0xc052cdd4116d1987a3939c7cbfa2f266e8d181465561a8d0ade58075cce59ab0</span></span> <span class="giallo-l"><span>00936,</span><span class="z-keyword">0x0d1ce1ba874c0fe555d4c8d7a238c459d5cd3f93634abd7bf304eac7a225bd7d</span></span> <span class="giallo-l"><span>00937,</span><span class="z-keyword">0x20d0836298d617aab81be691f33cd1dc61546b081a1e913b7cf34e5afcb8c8d3</span></span> <span class="giallo-l"><span>00938,</span><span class="z-keyword">0xfb915a9512d1e0bb47c535ab0cc6e7ddaa439a720c4acd6d591be03ff738a402</span></span> <span class="giallo-l"><span>00939,</span><span class="z-keyword">0x2d5f2cb94ecafe782fc87c9a65f35a98a38b249bfe8a6c6483070d22f485c752</span></span> <span class="giallo-l"><span>00940,</span><span class="z-keyword">0x31a360b2a347dc2d8ff1e2ee51c8d487fb02b3ba20ea86104e8c0010e6840674</span></span> <span class="giallo-l"><span>00941,</span><span class="z-keyword">0x6247e765c7acc0135a2a1c8359ed9280836e63aa78bea7e5d489d44cfceda482</span></span> <span class="giallo-l"><span>00942,</span><span class="z-keyword">0xc352aa92f9ed89ebfc84d9bf131e0e386a26b3e6264cf3ef6e0d3262fc55df2c</span></span> <span class="giallo-l"><span>00943,</span><span class="z-keyword">0xb8b31db995add4b70a2637cc3e46d37b0f9bb608f63ed39b1676115569cc95e1</span></span> <span class="giallo-l"><span>00944,</span><span class="z-keyword">0x2a8be08321010d8fbc280fbe2ff0d9a9102738f588dccbb4401ec722067450fb</span></span> <span class="giallo-l"><span>00945,</span><span class="z-keyword">0x80961bb9747aa130e7b0f37c81951fb8d28bd916ac200bf5cf0ff8b4b5bb2bd1</span></span> <span class="giallo-l"><span>00946,</span><span class="z-keyword">0xcaefe64b2e4fb5f87ec1027d5ce8c9c545e116b687657c5b3789d195c29377c0</span></span> <span class="giallo-l"><span>00947,</span><span class="z-keyword">0xccd88affa72df06596b5ea6d9429fb5c0d3ffb7fb2ae2be3746463c4572841c4</span></span> <span class="giallo-l"><span>00948,</span><span class="z-keyword">0x11d91c258be65dae198f1301b2b3bbefc22d80a62dc3c789577a9d9584441322</span></span> <span class="giallo-l"><span>00949,</span><span class="z-keyword">0x209f845f27a7cfc68440e96a9a05f0bf9ffdfe3fa2b77f0b66ce46de6ee6a1df</span></span> <span class="giallo-l"><span>00950,</span><span class="z-keyword">0x4a9dede78effcd06746878f1ad7c1c255e7451ead558f94a610d64de9e84a569</span></span> <span class="giallo-l"><span>00951,</span><span class="z-keyword">0x6493fcf8ae0df3ba0344e3f3962cd9cedc50b435d278c680b1ad7fe580046213</span></span> <span class="giallo-l"><span>00952,</span><span class="z-keyword">0x611a2c464cb0aed5d1ff89013df62f77a4c66a4dbfbd1310b861e17c0821d850</span></span> <span class="giallo-l"><span>00953,</span><span class="z-keyword">0x81e7d01751bb41cf701d58e15e5e24af7cab732efa990fdfc807d04965a7949a</span></span> <span class="giallo-l"><span>00954,</span><span class="z-keyword">0x19895bb27f335092570be78e1c9e4390bc3165c12f3b4801c3386502dc1c14fb</span></span> <span class="giallo-l"><span>00955,</span><span class="z-keyword">0x443f9153e9d10aa291a75482f6ccb32b7f03e5ff28ffecbc218bfb0d17645c82</span></span> <span class="giallo-l"><span>00956,</span><span class="z-keyword">0x3dcb543b7fe04863694029ec36709cb2be65281eb77801ec7a43c47421b2f266</span></span> <span class="giallo-l"><span>00957,</span><span class="z-keyword">0xa2d2aa3950ccd9bd38664a108384da939a29e5bd3602b44f2e6d0f7e078f8181</span></span> <span class="giallo-l"><span>00958,</span><span class="z-keyword">0x24f3f044349785645a815ecae5ca634e5068415f3e47f83a4de78d1f5a0ae0a8</span></span> <span class="giallo-l"><span>00959,</span><span class="z-keyword">0x8fc647c479f7467e99986f5a67aeda9ffc96c49cc3b2d939adf2e02e6cb631f1</span></span> <span class="giallo-l"><span>00960,</span><span class="z-keyword">0x680241a45f3921d7038f95843ee7c15a97fac6acfffad14edd0b80cd52525b8d</span></span> <span class="giallo-l"><span>00961,</span><span class="z-keyword">0x759690ad2ec0fd1d75ef612e00b72ba25bc5c2cafa795df819ac5410fe245a45</span></span> <span class="giallo-l"><span>00962,</span><span class="z-keyword">0x12b37dfb28e1b19692de0b9ff9e4564d3712ba1abf0085cce006e61354f9b7c5</span></span> <span class="giallo-l"><span>00963,</span><span class="z-keyword">0x2b4168b786abedf1fd231b205fd827ce376aa3dfad7df2e8ffa37559c8aaa489</span></span> <span class="giallo-l"><span>00964,</span><span class="z-keyword">0xa7136656c0ac8a32a5cacdb85d35f7b1cfbf46add043b65d63870b7be188e662</span></span> <span class="giallo-l"><span>00965,</span><span class="z-keyword">0x8a62b4050b97c853f8b86c1a27865c5e8550689c699c7ac2cf18d534b4bb523a</span></span> <span class="giallo-l"><span>00966,</span><span class="z-keyword">0x73e45b2c1971c37f6bffd67467b444874a0168db85f916c4e1e1cc0d760a48e7</span></span> <span class="giallo-l"><span>00967,</span><span class="z-keyword">0x399424597ccba8d81b2fb6d2f5b16a310e43bbee1d546bc0a80450f7ab202a60</span></span> <span class="giallo-l"><span>00968,</span><span class="z-keyword">0xdce8aff6baa754aa1d9c385dfd56b5d0ff0c9644cb0756cdecf9c4b1dc75396b</span></span> <span class="giallo-l"><span>00969,</span><span class="z-keyword">0x49be47569890def0996f17dea252bad3c05e4f90c23a6b441e05db55deef4df3</span></span> <span class="giallo-l"><span>00970,</span><span class="z-keyword">0x68c57c6ab509c836dd5c5c0ce07cb41070698639ea7ea4b9faa07dd05d9ae9b4</span></span> <span class="giallo-l"><span>00971,</span><span class="z-keyword">0xc4f6b046bf04ee48a7360f9271b8507f13e222b37deab56d84090d8ad7071e40</span></span> <span class="giallo-l"><span>00972,</span><span class="z-keyword">0x13a7fe3ff99f61c26ce53cfad439b83aa50af5659ca5095a1666106ae43b178e</span></span> <span class="giallo-l"><span>00973,</span><span class="z-keyword">0x135d2ae11ee8c376d2ee5ca54ebe8ce915d133c5c9330f9669c3f870cdebe438</span></span> <span class="giallo-l"><span>00974,</span><span class="z-keyword">0x922bb3c21c999cafa708dbc7df398abd83cdb51aab98537adceb848b95b0531e</span></span> <span class="giallo-l"><span>00975,</span><span class="z-keyword">0x27b6441bb01ad4bcc2254fbbaea88e69e4adc75d9305a086085602eb971306af</span></span> <span class="giallo-l"><span>00976,</span><span class="z-keyword">0x63eafa02faf46070cc68eff888506aae7e0bb2a4ef9558fa2ab095bd30b95d4b</span></span> <span class="giallo-l"><span>00977,</span><span class="z-keyword">0x05bdc732d86d690e9fd8fe7fa8ee4077e92535202176ee37b9a2f124e7bd4212</span></span> <span class="giallo-l"><span>00978,</span><span class="z-keyword">0x95d7750a07f5423f61cbdd6797537c1316d250854bd865639df437ca3c70cbb8</span></span> <span class="giallo-l"><span>00979,</span><span class="z-keyword">0x8cf0d6245c51d3d854eb5a77b46562c4416f5dd64386eb5254036e44e189c9e1</span></span> <span class="giallo-l"><span>00980,</span><span class="z-keyword">0xa8768f5c3b2f7d860b55b71d01ededf8c4925a13c4f6eba25d2f1e9eb5232965</span></span> <span class="giallo-l"><span>00981,</span><span class="z-keyword">0xc4e8ddcfb6cf6972583902cb5e2d10c8be3ba895b076f7ba8e29c09de1a5e512</span></span> <span class="giallo-l"><span>00982,</span><span class="z-keyword">0xd4ecd7c319b9e27e4929f7c0e3ee7baa94b58604b55a0684832524f816124f41</span></span> <span class="giallo-l"><span>00983,</span><span class="z-keyword">0xd39b640f89b8d62e6a58bdda604a6931e5a97494270b8c13639c9291152a856c</span></span> <span class="giallo-l"><span>00984,</span><span class="z-keyword">0x22592d52da8f0eed167b072bd3f9d68708ac37af6884b76497f518e419efc4e3</span></span> <span class="giallo-l"><span>00985,</span><span class="z-keyword">0xe4e144f9d02c04d79c9d03a3141f6a90d3a9217d2f348a8b5f57ed50deba907f</span></span> <span class="giallo-l"><span>00986,</span><span class="z-keyword">0xb5e7db59cf4b1329d19cd7dec561c3eb7353eaf71f3f5eb92f1cfa9525425fd1</span></span> <span class="giallo-l"><span>00987,</span><span class="z-keyword">0x9316c767971e58e2fcfd1bfa386d6d678f05194403a9371194b26e160614f57c</span></span> <span class="giallo-l"><span>00988,</span><span class="z-keyword">0x871302efe9a899f706e248554a0a7834244e9b94db1aacad82a96f70d50ce3c8</span></span> <span class="giallo-l"><span>00989,</span><span class="z-keyword">0x1c3a761603d969947df6da3491d18a2f55dc67cad3d7ae813aca79089e8e4dee</span></span> <span class="giallo-l"><span>00990,</span><span class="z-keyword">0xa666b3895ff153f24a671fb6588494111eecd4c4482379b6bd662361f955de46</span></span> <span class="giallo-l"><span>00991,</span><span class="z-keyword">0x3154c955d0dc8f9ed8f5e7ebd476b549d5778600afc737a213ed6156765af846</span></span> <span class="giallo-l"><span>00992,</span><span class="z-keyword">0xd078def25dcdd2df52d7e37bc2910e598ac00c921473f8d93137a07d3a403edc</span></span> <span class="giallo-l"><span>00993,</span><span class="z-keyword">0x6b2615f1fe8043e3f4f06ff4f918c0b34bed01cf776b535a3a16530b81fc9d91</span></span> <span class="giallo-l"><span>00994,</span><span class="z-keyword">0x6ed3f90facb487fa49945d0ed5f987a03b8bf76b0377fe2980bfe9cac2a5b6dd</span></span> <span class="giallo-l"><span>00995,</span><span class="z-keyword">0xd3223ce7a69afde216dd1c957c6116cb76bc2d70895921c2ccd6b9d4f79038f0</span></span> <span class="giallo-l"><span>00996,</span><span class="z-keyword">0x016c769b453ee0995a23b0b20bb83c3870ec7754867b8676da1c3e4849511160</span></span> <span class="giallo-l"><span>00997,</span><span class="z-keyword">0xe19a4c9d8889c46240475ea0e669e967b4ca09dd35085c327dcf75e127093d3b</span></span> <span class="giallo-l"><span>00998,</span><span class="z-keyword">0x36c9ff39ced94ac5d4ce3c5d8ce14030ca154bcc2e99abdcbd71344e8b0fdfce</span></span> <span class="giallo-l"><span>00999,</span><span class="z-keyword">0x83c72fa27934098dbf8aea00c2491a9dba82ed6ae6f116f12ef96404f63ea6f2</span></span> <span class="giallo-l"><span>01000,</span><span class="z-keyword">0xddcc603638d6f6aca751013a22d42f0b3dc9e55794978e37f46c38b622fe0ce5</span></span> <span class="giallo-l"><span>01001,</span><span class="z-keyword">0x2d0fc419efdaf8f46067013cf528064da86116db18b5382289afb4b6e1cf2b9c</span></span> <span class="giallo-l"><span>01002,</span><span class="z-keyword">0xf69f7b396a816ec0b8a377e3e75ee054c47339cce83f24de1453561c04f24789</span></span> <span class="giallo-l"><span>01003,</span><span class="z-keyword">0x1763271040eea5424900aea6164448f842f699eb662f8409d95e5a5635cf20c2</span></span> <span class="giallo-l"><span>01004,</span><span class="z-keyword">0xfbfc02162b85f7c870dba66af17bdcbad0f5e6dbb8c7b0f2ef936a0858595077</span></span> <span class="giallo-l"><span>01005,</span><span class="z-keyword">0x584687a4b29aad825e7a6f106afe5f27a97ae104d3cdd7389fad0f44ad5cb101</span></span> <span class="giallo-l"><span>01006,</span><span class="z-keyword">0xdf8970e84c6c9134c98a890c83c4649fbae258db7cc5d3b1fc3c63cd6ab64708</span></span> <span class="giallo-l"><span>01007,</span><span class="z-keyword">0x2fbbff929c09f13110369d940831fde47cd6eef07d5449d4b3f9d353ca155dce</span></span> <span class="giallo-l"><span>01008,</span><span class="z-keyword">0x235c9a91c69ce2ce21267dfa82b595caacd3f9ee09d9ad725e5913c317a05646</span></span> <span class="giallo-l"><span>01009,</span><span class="z-keyword">0xfa09b4f1cabfd5bf65704b38982b06a536e316ef4b533db69a73ce2bf88a571b</span></span> <span class="giallo-l"><span>01010,</span><span class="z-keyword">0x3cacc95c0a0f16f81baca64b7331b81bb577b2ce6d451b9b3773f1770fb1a948</span></span> <span class="giallo-l"><span>01011,</span><span class="z-keyword">0xdbcb3c6423aa05a61c71ddbf3181af582e525b5a72a9ebb8e44913bb981acfb0</span></span> <span class="giallo-l"><span>01012,</span><span class="z-keyword">0x6ac002dda4b8f105f2bfcfe0be9f0dd8cd543abaf99e36340397026f68fb1210</span></span> <span class="giallo-l"><span>01013,</span><span class="z-keyword">0xdd1763be363eae6e854d82cf948ce79aa3903b24fb1bebf83efa5bb9ad8454c1</span></span> <span class="giallo-l"><span>01014,</span><span class="z-keyword">0xc4e0e059fb5489787f907324c81a46a400a87b3cc056601f8a9eb5fc88b1d32a</span></span> <span class="giallo-l"><span>01015,</span><span class="z-keyword">0xd2d13e5ed7819f3841af3e911c3516211bac48169a52d6c0f0525b94af603d61</span></span> <span class="giallo-l"><span>01016,</span><span class="z-keyword">0xa93277ff5640373ca1446607c231f0bed5bd15a096142e7376580f3fc78841c8</span></span> <span class="giallo-l"><span>01017,</span><span class="z-keyword">0x019e6db033ebcb56d9d51ba309d4f010fe79a0df9f6f3114b052390e273ec750</span></span> <span class="giallo-l"><span>01018,</span><span class="z-keyword">0x763ea921a273d3b92099e451f36949767992111073117536583f5fab34dff71d</span></span> <span class="giallo-l"><span>01019,</span><span class="z-keyword">0x45d2795144aa708f2aa6d5016635c887f97c9e609dd7eaa30fbdbe04ee2acfb9</span></span> <span class="giallo-l"><span>01020,</span><span class="z-keyword">0x37e8f37e7fe680451499d4cda814162837dd4e60b9dbcc1cb4a09d8aad95cb5d</span></span> <span class="giallo-l"><span>01021,</span><span class="z-keyword">0x6654a92dac9365e122dfbf52b5d2134dadf1d638aafa879893e50ee2da2152ad</span></span> <span class="giallo-l"><span>01022,</span><span class="z-keyword">0xb81a65c13cc3d54b281e9ad392e8792910ad09b39b8dcaf6ae8e3fbce06117a3</span></span> <span class="giallo-l"><span>01023,</span><span class="z-keyword">0xb72e8700d81b2d7c322dc74a3f37dfce6f3b08a487a92242fd0ec2b8bebe21fb</span></span> <span class="giallo-l"><span>01024,</span><span class="z-keyword">0x75f6d852198927b79d8ad8bd5505983052e9ac80b80d5dacebd4687d60d549e8</span></span> <span class="giallo-l"><span>01025,</span><span class="z-keyword">0xcd13479c8725155feebfed83954d53ffcb6725683f43c866acffbc6e9b97ccfe</span></span> <span class="giallo-l"><span>01026,</span><span class="z-keyword">0x1ff6a9b9fc585560ae6780a7c54170e8f501324a894f00f08828697d661ef0e2</span></span> <span class="giallo-l"><span>01027,</span><span class="z-keyword">0x6c76c020b3f3f95b9c50a8d6d7949cc9c9798522070f5e35e61c6521473e15e6</span></span> <span class="giallo-l"><span>01028,</span><span class="z-keyword">0x78f9905648fbb6eaaff40a458301f05a7bb753a6288eafc141c797ca01db044d</span></span> <span class="giallo-l"><span>01029,</span><span class="z-keyword">0x3dcb5e2a8b6791f5141c8ff08ac59a36030c9436e6ec6de8274be01fb81112c0</span></span> <span class="giallo-l"><span>01030,</span><span class="z-keyword">0x373e75f1325d787a5f7e66c6b888083a7b1b2e6250d2764bbe1b4f1145dd9b72</span></span> <span class="giallo-l"><span>01031,</span><span class="z-keyword">0xf06e62b5bde482371af35d2b3eb05bc4e9f80da90c64f9a36c8405bd0779f123</span></span> <span class="giallo-l"><span>01032,</span><span class="z-keyword">0x3f19793eebeb6aabbbaa055ef131d73f1186be249bd8bbe2b11af0dbd783cf7f</span></span> <span class="giallo-l"><span>01033,</span><span class="z-keyword">0xa9765c1c7bb916043bb42b1572cd96f905c3e2f5fdae49010a5102a9eb4a700c</span></span> <span class="giallo-l"><span>01034,</span><span class="z-keyword">0x1dcfe01766b650af58d6becf6de168e7da980e7058c7b6424da1b0c470a7ebca</span></span> <span class="giallo-l"><span>01035,</span><span class="z-keyword">0x946b550f1e19e68d272a10be6c0a1f9310da704cdbdf518c8a90b694748a8c29</span></span> <span class="giallo-l"><span>01036,</span><span class="z-keyword">0xb953b4b78c6b2446d60625b65ebdb25165d4c9a46916ee303b5daa16029257c6</span></span> <span class="giallo-l"><span>01037,</span><span class="z-keyword">0x8356dd445dc79c97a83819c8538aab5176664d436bfac3e9971b1c9cea78022f</span></span> <span class="giallo-l"><span>01038,</span><span class="z-keyword">0x3cefbeb9ce2ed071c7abb2b55fa1f8ced72cf1f2f9bcc24955a17aaf1eb99c29</span></span> <span class="giallo-l"><span>01039,</span><span class="z-keyword">0x4765ee428148e60b0038ce5034cbaa7259b0d85403d37936cff1f1f220c09419</span></span> <span class="giallo-l"><span>01040,</span><span class="z-keyword">0xc559659c692f7eefd643fcfdebf8697a04634c839b6e1724382b3bcdfcb15170</span></span> <span class="giallo-l"><span>01041,</span><span class="z-keyword">0x1b1f9767d845eef02506d6a6c54fffcce5bd6bc59b41b00f17ef06e4c63edede</span></span> <span class="giallo-l"><span>01042,</span><span class="z-keyword">0xed5a8fb5f2b0ab802832bb99d32a9ba463945ffbfce2f56f26e9c39fda1c3fe8</span></span> <span class="giallo-l"><span>01043,</span><span class="z-keyword">0xa396fcbd5b63936ec43b6bacaf2b0236783c638eacc72614daa29e792ffe1ac2</span></span> <span class="giallo-l"><span>01044,</span><span class="z-keyword">0x33bd34bdc9b4c51f344e476fb8c97fe80cfded7c90de437f100505b17823c66a</span></span> <span class="giallo-l"><span>01045,</span><span class="z-keyword">0xe62bdcaa8531750ae8fc247c76445a76670077643060efc80323e864c2c2c480</span></span> <span class="giallo-l"><span>01046,</span><span class="z-keyword">0x37db60cdd4270773f870c9cb8eb3368d0e1443789dc44cd653b0f423addab3c9</span></span> <span class="giallo-l"><span>01047,</span><span class="z-keyword">0xd02ff344a0e66526266e7ac1ef9269ee132e793c2a3eb2c20c95212665880232</span></span> <span class="giallo-l"><span>01048,</span><span class="z-keyword">0x27c44206ef714c1ebdfa21cd959c074063432f3fdcd7a3b0b2ec4375e12ba53e</span></span> <span class="giallo-l"><span>01049,</span><span class="z-keyword">0xd74dcd433ceba7a2a6702e807c68470b446772565b466b0878d4518983640500</span></span> <span class="giallo-l"><span>01050,</span><span class="z-keyword">0x583482c4b0a752dd12430176b663ff8ea5fd11f2eeebd8b956702d0eb473a748</span></span> <span class="giallo-l"><span>01051,</span><span class="z-keyword">0xb1375fb5970e469451f9e7b9a29f3b20ec0c583ec90b79fbbf38f9e981d9a9ea</span></span> <span class="giallo-l"><span>01052,</span><span class="z-keyword">0xfc68a5dbc89395b13fec398a9ad78b00d813fbbb259f005e6fba1eb1bdc7f2cb</span></span> <span class="giallo-l"><span>01053,</span><span class="z-keyword">0x038d0dc543117df0c46ca6cf4467721780eb951017373d51aa88ece1a380f56c</span></span> <span class="giallo-l"><span>01054,</span><span class="z-keyword">0xfc630d10c00e0f843cadfac7d24f8ad02f7603bc7555efb4fe7e6a33d42d8fca</span></span> <span class="giallo-l"><span>01055,</span><span class="z-keyword">0xdc564afcfef0c40d16d7fbfd90afc419bbc37fc750f790130acaffc32f985dad</span></span> <span class="giallo-l"><span>01056,</span><span class="z-keyword">0x75fba5d5c98ffc1f67f8a1ea520808f94a547003fa4fafa34ba7f9b2dfab7383</span></span> <span class="giallo-l"><span>01057,</span><span class="z-keyword">0xf2a347f31fba049b5994122c3d6de4d37196ce8fed6c7c7b5c2c6926c28811c1</span></span> <span class="giallo-l"><span>01058,</span><span class="z-keyword">0x7e00f70a6b91f77cdd78c01ca54d506dcc25f226fbbd13d56b0c80e8c80c2694</span></span> <span class="giallo-l"><span>01059,</span><span class="z-keyword">0x7c557845f4abf757fef7dbbd11b44e44c92025733d16b57ebdec6ae10f381f38</span></span> <span class="giallo-l"><span>01060,</span><span class="z-keyword">0xd6b988695e3c2a57b1d3038de5262349766cea46600f70b8cda2998ae395894c</span></span> <span class="giallo-l"><span>01061,</span><span class="z-keyword">0x7edcc464ec0b7bd04070e80a4795a4d59581d9d6d53756eef10ae5a38b40259b</span></span> <span class="giallo-l"><span>01062,</span><span class="z-keyword">0x84fae3dfe3699b7ab0c58b47c604799d1fa7a0088138efd63cd4603e79cae112</span></span> <span class="giallo-l"><span>01063,</span><span class="z-keyword">0x97a50adfaebf0ad4f60329d82fc6fd897416be8c698e6a6d3b6e7da8934a2f97</span></span> <span class="giallo-l"><span>01064,</span><span class="z-keyword">0x25e68a390fda36ad8fee616a22d79cfc531127e6c8cbc11710e8f5743399d9bc</span></span> <span class="giallo-l"><span>01065,</span><span class="z-keyword">0x88ea91bdc01e8bc0fdda51dd2abbf05a92a14c20052dcb563faef0bcaaf5d161</span></span> <span class="giallo-l"><span>01066,</span><span class="z-keyword">0x77a58ff5479dab194fa000221e98fa4e6dc77aec51aed889bcb852db57db3d03</span></span> <span class="giallo-l"><span>01067,</span><span class="z-keyword">0x95926dd93886d32de8692bda38da9e4ab10f9026ddc5b9ff69c30f55e0915ebd</span></span> <span class="giallo-l"><span>01068,</span><span class="z-keyword">0x9e4b22f0088519c08bfd6cefbe125caeefa43b83b451fffba1a87223dfbcc62f</span></span> <span class="giallo-l"><span>01069,</span><span class="z-keyword">0x5451d56c823a2e8d42ad39859e0758b8a4829a11daadd96ceb4ab2b29874c7b2</span></span> <span class="giallo-l"><span>01070,</span><span class="z-keyword">0xdd746cbf406b80fca7b25d95961640fb0ae5d411468001224c3770b2554b95ec</span></span> <span class="giallo-l"><span>01071,</span><span class="z-keyword">0xe7162b854ae8194deb0bd3a34eb77be0bf539ce76c566ae2e05207968a908b95</span></span> <span class="giallo-l"><span>01072,</span><span class="z-keyword">0xa0266c3199c30bb4c8ec4b5797d112795c89dbfac6478dd5d3b772a14158fd69</span></span> <span class="giallo-l"><span>01073,</span><span class="z-keyword">0xfb390415ebb31243ff63e550cf27cad325550dfee0b421c1c1be75a845319585</span></span> <span class="giallo-l"><span>01074,</span><span class="z-keyword">0x7d668fd503ab1327817d49218ba493e6174918a03b3120133126c453ca345e20</span></span> <span class="giallo-l"><span>01075,</span><span class="z-keyword">0x38bef7ff6fd5999f6446ad8abfdf10a24045ae1b837b0ab70e1db500eaf4cead</span></span> <span class="giallo-l"><span>01076,</span><span class="z-keyword">0x55f5a07a76490536966de1a99fee90d723ebae9e8d0806d9ed6f1580b2174db7</span></span> <span class="giallo-l"><span>01077,</span><span class="z-keyword">0x61a13d92beef22d97be7f3c1656cae6760fc08e36db7d381d5c96222fd50f864</span></span> <span class="giallo-l"><span>01078,</span><span class="z-keyword">0x227e71270b878bdc138b23386bb7b33cec9175875b461b04902f4af708c31580</span></span> <span class="giallo-l"><span>01079,</span><span class="z-keyword">0xf1a39e59434a97dce0d30cae7bd6feb571827cceb3ba57af6af183e953c24b6a</span></span> <span class="giallo-l"><span>01080,</span><span class="z-keyword">0x1b7d09908d41e6463da4ef25bc4a7e2545528671a510352110cd382f5b300d8d</span></span> <span class="giallo-l"><span>01081,</span><span class="z-keyword">0x679b43594ec30c0fde26f3a2e05561c7e110ebc15cce1ec5b6d7da2fc5a415c3</span></span> <span class="giallo-l"><span>01082,</span><span class="z-keyword">0x5e7dea252df625a366ac47bfcb1e8eb2df49d44d0be463f98ba95d256d6982d5</span></span> <span class="giallo-l"><span>01083,</span><span class="z-keyword">0xcdcb8e564e8695a687939ac1a0fd1a0cc5dbb352f9cd24427cde8360b2a9f200</span></span> <span class="giallo-l"><span>01084,</span><span class="z-keyword">0x5f2ca307599872cfc55256ad29009b53f3303d024b5b782a4abb591c8cbe5a57</span></span> <span class="giallo-l"><span>01085,</span><span class="z-keyword">0x12230dff9cefa72d522ebb791d84eee3ec55b5c4a4600209cab7c376171fa159</span></span> <span class="giallo-l"><span>01086,</span><span class="z-keyword">0x6eb5d461ec98068957cdab5b2028bbd8b1b2f7a221a8ea9c8011071da37d7b2d</span></span> <span class="giallo-l"><span>01087,</span><span class="z-keyword">0x45541bfe08784bc6d1298d97e0308241efaf18a47bffe4894dcc26ef776b7b0d</span></span> <span class="giallo-l"><span>01088,</span><span class="z-keyword">0x09f2f43ee828665d8d45859b5e36a8b9d31283550eccf4f73b1a87638e709803</span></span> <span class="giallo-l"><span>01089,</span><span class="z-keyword">0x4519917d2bb898a1810ede8b13275e678198aa773f7eef2b2c05c129942cb259</span></span> <span class="giallo-l"><span>01090,</span><span class="z-keyword">0x506362e6d66ca9341da4fb5706d690f94711b6673ab9b7d7ac22dbd39e0af8db</span></span> <span class="giallo-l"><span>01091,</span><span class="z-keyword">0x408e7c249b773c396ee2a412fdd8ef7e43fcb5538e026aedfd34d7b9b721e60d</span></span> <span class="giallo-l"><span>01092,</span><span class="z-keyword">0x4f1216d3d70323582c6544bf9c07bc6bf3582ddd01a52550b257b1e078dc12fa</span></span> <span class="giallo-l"><span>01093,</span><span class="z-keyword">0xf7943fdae6b71a9c1a6d7320a61ebb908c32b91e8c9679808b09da9f28774225</span></span> <span class="giallo-l"><span>01094,</span><span class="z-keyword">0xa2458aba8fb9a34aa4b4a5ac20b23f843e8b12929bdbf793499c0187de963643</span></span> <span class="giallo-l"><span>01095,</span><span class="z-keyword">0xc3174a59e85dd195642088336274f531f551c50dbadf407323d0d1d5ef961bff</span></span> <span class="giallo-l"><span>01096,</span><span class="z-keyword">0x5475a30e12c46b42b661a0932c94efe35bb76575dc0030255dae625933f32712</span></span> <span class="giallo-l"><span>01097,</span><span class="z-keyword">0xd2ce1e42bbb308bb9e0abb971cf5b4d9ab1cca8fbd73d11b3cfc19dd0b3b235e</span></span> <span class="giallo-l"><span>01098,</span><span class="z-keyword">0x5fb12ec44e61e8a76d79d4646c09a67627cccf3576e52206f580364cc03080de</span></span> <span class="giallo-l"><span>01099,</span><span class="z-keyword">0x1cd92052c419c186c329a14c7bab28a4496c23e243635d5a263a3ba34d0052c4</span></span> <span class="giallo-l"><span>01100,</span><span class="z-keyword">0x22b095d488d0fbd0f10e209b322ca59ad319975d6d3c90a81d1fd9b6d0243dc6</span></span> <span class="giallo-l"><span>01101,</span><span class="z-keyword">0x844b63b3997c0468086656f4733991f97ec42d5fb1b65c050113d515117bb756</span></span> <span class="giallo-l"><span>01102,</span><span class="z-keyword">0xbcce4dd3d6cd5b08a76bb8890eef30ad7df184972df8a271648de5269fe1ed26</span></span> <span class="giallo-l"><span>01103,</span><span class="z-keyword">0xc97117921c0dc002265d161013da1171084008fe5b51d046c695b5e626c9994b</span></span> <span class="giallo-l"><span>01104,</span><span class="z-keyword">0x5035027c4b5ec5e2df56117a2e012b79c9aafea7bc89a3015e9061e226893245</span></span> <span class="giallo-l"><span>01105,</span><span class="z-keyword">0x9331be3bcf98379d8a0e2f65a70785c10fd620d3fad050315c2a1e2f6c8bd6a7</span></span> <span class="giallo-l"><span>01106,</span><span class="z-keyword">0x901078cb9b1d4516ecbda207acb6e6e2891a134b0c80b647240fd8ad50016063</span></span> <span class="giallo-l"><span>01107,</span><span class="z-keyword">0xf8edc0d4190782ba1a6bb98105a33cedd5d71c25b22e0138d5bc5d902f9f5a34</span></span> <span class="giallo-l"><span>01108,</span><span class="z-keyword">0x42362545904d6792bb88ae2a9f7d29b10623e58260d0ec47749781227123a2d9</span></span> <span class="giallo-l"><span>01109,</span><span class="z-keyword">0xbc521ceaa2bd28faf23c9f256b2b24c98bfdb90a020d25216026f95d065eb0f7</span></span> <span class="giallo-l"><span>01110,</span><span class="z-keyword">0x199eeafe5585e55674bfa0a341988e470b65ef78061b3f20eade8d1e271ef3a6</span></span> <span class="giallo-l"><span>01111,</span><span class="z-keyword">0xd34462829eff8702ce5561c6b1b715e63c8a89b7f5eb274e8c5588cd15678ba1</span></span> <span class="giallo-l"><span>01112,</span><span class="z-keyword">0x1c93ba5b0b9c65421fb9cef8cd24cae654c4ba7d386a53b6036e4019eb517c55</span></span> <span class="giallo-l"><span>01113,</span><span class="z-keyword">0xbeafcef83fc5e6769d82b3c304c0cbd5a1add1277e1ac300f0bc5c7e2822f2df</span></span> <span class="giallo-l"><span>01114,</span><span class="z-keyword">0x71ec790b6d9c1f8e40159317162256dcd6f52a700215fc61d329587c64b248d9</span></span> <span class="giallo-l"><span>01115,</span><span class="z-keyword">0x6f6094bffde8d3ae31ac86b2ffa489481cb8b4b440d4613edb06f5e40f0effc7</span></span> <span class="giallo-l"><span>01116,</span><span class="z-keyword">0x053afb71d72d02a534cf646231ef23fbcb10a93ffbb85b43bf6364a1b6cc2015</span></span> <span class="giallo-l"><span>01117,</span><span class="z-keyword">0x98396ff4fbee74940a9a03c33032d84f7285608a0a3ee7c58e016ca8c42157cb</span></span> <span class="giallo-l"><span>01118,</span><span class="z-keyword">0x5747971200ae6086c2054eb6a3d0a5307b84a2c2e7ce4dd0b99fcf278b5b066a</span></span> <span class="giallo-l"><span>01119,</span><span class="z-keyword">0x1554c47385b828df19e22779047108210de2c8a34fd0346f77b9a80c630637a1</span></span> <span class="giallo-l"><span>01120,</span><span class="z-keyword">0x5db300fa117451b25a6f7a59a55e33947378c5216687ed6ba23f38a721cbc21e</span></span> <span class="giallo-l"><span>01121,</span><span class="z-keyword">0xb9aeb88a7f2c33e5ef7b0eb9e4001ce50b96bd4576f174ff5fbaf2aaa0ca3cff</span></span> <span class="giallo-l"><span>01122,</span><span class="z-keyword">0xa8849157cde19e3801e69291365f8fc095855ea313f1a6cf5b39d1f117ff166a</span></span> <span class="giallo-l"><span>01123,</span><span class="z-keyword">0x0b7bcf33f4e42502cf5f0c981f1103bbb8f9c98a0a4a02f3ac10baa8328906ea</span></span> <span class="giallo-l"><span>01124,</span><span class="z-keyword">0x224f4405f110ce6825bab6f6c209a4b5518894bf489795e92195a87013406ff6</span></span> <span class="giallo-l"><span>01125,</span><span class="z-keyword">0x0b6064b3c367b296c0a422c00bf4606867164d315c7ab16d89f1ad2957a4734c</span></span> <span class="giallo-l"><span>01126,</span><span class="z-keyword">0xc7344cf278e4f244a49689243aae7f3fe30e1ce07e5aba04ceac1cc40fa922cb</span></span> <span class="giallo-l"><span>01127,</span><span class="z-keyword">0xad12ba3851456ed8b37c7f21c8825c885a767cff2bb776be648cb8356946cb0b</span></span> <span class="giallo-l"><span>01128,</span><span class="z-keyword">0x3a386e6dc1d155d89af575c544cd88581c7d178bac55cc44f63b2ee888223764</span></span> <span class="giallo-l"><span>01129,</span><span class="z-keyword">0xc77dcea67936565fa9d9eb078ce575698500dd17988daf0a7a8f246ff5508833</span></span> <span class="giallo-l"><span>01130,</span><span class="z-keyword">0xa25a8fc183706411fa20ed4f3b2a68d96e0b161fc09468f33beb434c48f58bba</span></span> <span class="giallo-l"><span>01131,</span><span class="z-keyword">0x0225209e1b7c3463f869898432742732f32fd1e7c5f64e5ed74adaae2eace9e1</span></span> <span class="giallo-l"><span>01132,</span><span class="z-keyword">0x1ba9f77cea8694123218706715d4224221fdd5af2b022d015071d6443aa3a1aa</span></span> <span class="giallo-l"><span>01133,</span><span class="z-keyword">0x8e1c1d63b865ae597bfb51c82899e0aa4107a88dcc6ab180ebb568c6de993700</span></span> <span class="giallo-l"><span>01134,</span><span class="z-keyword">0x3197a1d6c72f1891609283366e120a1f4c61412f83835684f28901d35249a04a</span></span> <span class="giallo-l"><span>01135,</span><span class="z-keyword">0xd28f2c9f79253b151384e63f867a55278831d92575d63ea0a6b14f39f373161c</span></span> <span class="giallo-l"><span>01136,</span><span class="z-keyword">0x6cf8d26d850172c2e2bb9629792fa93afec55de913957c778fe0895734ae70d4</span></span> <span class="giallo-l"><span>01137,</span><span class="z-keyword">0x62215680c0a6143f5f66137de7a13356a0d1837fa842aca997aa6d4eeb1bd7d7</span></span> <span class="giallo-l"><span>01138,</span><span class="z-keyword">0x44e4142c95e4d04f4b598a4146c0fa04fde6db6afd78ddcc8be9fd16018ce72b</span></span> <span class="giallo-l"><span>01139,</span><span class="z-keyword">0x1a70666e7cc7d475d738b07cb5e2984097e0e30df160b1d9b0698f33a9048c83</span></span> <span class="giallo-l"><span>01140,</span><span class="z-keyword">0x9bef85d30bd7319c6ac73e9195d2fb5a87900b61f09eff71ff9aaf6dd39d6c8e</span></span> <span class="giallo-l"><span>01141,</span><span class="z-keyword">0x48066cf2b5c1a5a553ecd2ca62a466bd7e462a9836e3108fa9b9c50084109d71</span></span> <span class="giallo-l"><span>01142,</span><span class="z-keyword">0x112745d12d9f1ffe670ec1b1b1526ce0b586f0348788742af013d8b5ae8f1e50</span></span> <span class="giallo-l"><span>01143,</span><span class="z-keyword">0xc07f562554568dd0a8d7d83f4151cfa979abf944c364f627daacfe42d6c8e75f</span></span> <span class="giallo-l"><span>01144,</span><span class="z-keyword">0xff3489f3959c367261b35a4a8cd106e9b8e504da8f95c752126874757a68d8a6</span></span> <span class="giallo-l"><span>01145,</span><span class="z-keyword">0xaa9a507ed68dfe695d15723f7f31e32977b1aa74bb8a948c2edc27a55c6b377b</span></span> <span class="giallo-l"><span>01146,</span><span class="z-keyword">0xae05fa5d0e96ad9e6fdda36bcc44637b1a4b9822c275dd6b0fbb7471715fbc57</span></span> <span class="giallo-l"><span>01147,</span><span class="z-keyword">0x0dca795f11fbe372384ddae72721019ac51bb29767f1de14c808ca5278015b6b</span></span> <span class="giallo-l"><span>01148,</span><span class="z-keyword">0xb970027bb776fd436f03d55bfc77b43836eebe0391f2f2673a794e5d9648ab7c</span></span> <span class="giallo-l"><span>01149,</span><span class="z-keyword">0xb2f6f5174d78083b50511b907c2e86378294179e05d89fbd98baf0996055f8ba</span></span> <span class="giallo-l"><span>01150,</span><span class="z-keyword">0xae9dea31e94ecadfec8694ff8db30c1527a1b4deaabc042794cbf0f7ba068fc2</span></span> <span class="giallo-l"><span>01151,</span><span class="z-keyword">0x1cb2b8d45a6d2a7a1b43aacd57d78702ff161f96b9141d8489ada32fe1c8a705</span></span> <span class="giallo-l"><span>01152,</span><span class="z-keyword">0x28b41e3872cd3343b0901208ef472e26d98ee3facb64d2787e6f1196cda87d09</span></span> <span class="giallo-l"><span>01153,</span><span class="z-keyword">0x9cc1f6f0ae4b10e85063dbcd30cc2077a2eff89daadb9ee3391e9c460e39d1cc</span></span> <span class="giallo-l"><span>01154,</span><span class="z-keyword">0x1d470ae11e0f409328f29e315a1881c3eae67123d48019c748a01f4e4f381aee</span></span> <span class="giallo-l"><span>01155,</span><span class="z-keyword">0xb516307f14425bd9ee0434ccedb692092eff147562ee7805e0c6e0df0a475d7b</span></span> <span class="giallo-l"><span>01156,</span><span class="z-keyword">0x8c4c11190ca958c76cad26d8514fb383ee51183c49eb56ab2aa41704249b6ddb</span></span> <span class="giallo-l"><span>01157,</span><span class="z-keyword">0xd7bb8fbd3048f3b139a3c64191ecf38bf1a218dd9544903b8ef3d0e546cd8af1</span></span> <span class="giallo-l"><span>01158,</span><span class="z-keyword">0x12ec0becbbf83afd68392f4d9b67d5a8da89979557cce60530735a1465c0fc6c</span></span> <span class="giallo-l"><span>01159,</span><span class="z-keyword">0x4fafaf52d0c069b6f587ee7a519e715604f4de04fca1a19e726671ac56596b38</span></span> <span class="giallo-l"><span>01160,</span><span class="z-keyword">0xd0e1b363591af53d56c1c6a146bb78ecdfec21f12b34759aa832501c89c26a40</span></span> <span class="giallo-l"><span>01161,</span><span class="z-keyword">0xcaff530399938686e3364b6b228b3ac59e3b22f21b1c2b3450118170fb281836</span></span> <span class="giallo-l"><span>01162,</span><span class="z-keyword">0x070dea605d09f3096df0b0f76948df8a38831c90c4581ffcf6fed7bde0cc268a</span></span> <span class="giallo-l"><span>01163,</span><span class="z-keyword">0xd285b66ebcd5852a1911fe5599702a89a0dadda1405cf84dcf6d55bcfe0f9578</span></span> <span class="giallo-l"><span>01164,</span><span class="z-keyword">0x2eb4c50feff7659cdd8f3ef48b6f9175a2a4b891d09af13bd0b414bff9b0bcfc</span></span> <span class="giallo-l"><span>01165,</span><span class="z-keyword">0xff4e71c2c49d497341e7386bdca329ab892c94197d5fbbd18166cd48843de333</span></span> <span class="giallo-l"><span>01166,</span><span class="z-keyword">0x4116850a1bd36ed591c1e95e3cb1aace3675a61d1c86e1660da988d5faec71dd</span></span> <span class="giallo-l"><span>01167,</span><span class="z-keyword">0x5b6986455f3550b4faaa88fdccbffaf90f897971254d9b8f3ddec649b5260b5d</span></span> <span class="giallo-l"><span>01168,</span><span class="z-keyword">0xa23912b4a361e10bdd6093479763b042c8d09f8fc8a5909170b57b6aebd98339</span></span> <span class="giallo-l"><span>01169,</span><span class="z-keyword">0x0737b4e5ab8f9071f44e61b66da61df228dc0414f3ba5dde12b7a8fb10b2e618</span></span> <span class="giallo-l"><span>01170,</span><span class="z-keyword">0xdf35982e9c74b401291f2ae70a09ea99766219008b0e01880cf6302e9d62b60c</span></span> <span class="giallo-l"><span>01171,</span><span class="z-keyword">0xcc7466dda5723a0c33c326d1596717848dfd0256867df4d68deaa8adc3f61db9</span></span> <span class="giallo-l"><span>01172,</span><span class="z-keyword">0x9abdb4aeec79e7dfe79fdb6711da93c071c9099542344da75fe1d968009f98e1</span></span> <span class="giallo-l"><span>01173,</span><span class="z-keyword">0xcdbdfbc64a23515c0dcf517dfd71825cbe5d9fc98566f9c6b02f733e8a1ba3ef</span></span> <span class="giallo-l"><span>01174,</span><span class="z-keyword">0xd79c75b859479066f9caa316c37f67fb7728dfc01a0d94f6a27ef126ac0692cf</span></span> <span class="giallo-l"><span>01175,</span><span class="z-keyword">0x0d2dbfd717f62ea857069cde24b45df8fd214ef044057175265d747411304051</span></span> <span class="giallo-l"><span>01176,</span><span class="z-keyword">0x94adbb4c520dffca694df807f479af7b035da83f3de81f014e28ea2d34e70adc</span></span> <span class="giallo-l"><span>01177,</span><span class="z-keyword">0xd5e0dc5aa1b4441e615373ed2c8782ce41b20b2a7816e81ee4311c243d3b7be0</span></span> <span class="giallo-l"><span>01178,</span><span class="z-keyword">0x5c34962d525fd40d9c8bc44f522af67fd89111d332eb9ba5cc9b0f138a4059e6</span></span> <span class="giallo-l"><span>01179,</span><span class="z-keyword">0x1de75523ed57212207b3227983ba8bbed7607c3574300abdf11cd1a372136e40</span></span> <span class="giallo-l"><span>01180,</span><span class="z-keyword">0xaac82868aa7edb8173d1d41c6b0745b7eee734182d4fdfd54e6043350afc116d</span></span> <span class="giallo-l"><span>01181,</span><span class="z-keyword">0x5899663553cb5e7842e72b43a64d86113a4b76aaec2b0774021361171aeaee29</span></span> <span class="giallo-l"><span>01182,</span><span class="z-keyword">0x74b8aa4405d31335e0f8eb310028c7d05972831702b931b5f28d5afb3d52d854</span></span> <span class="giallo-l"><span>01183,</span><span class="z-keyword">0x38d8567174aadf1166952a632dcc85d4a4b8c20c946f2399878183141a10b561</span></span> <span class="giallo-l"><span>01184,</span><span class="z-keyword">0x2a82d902f0d2aedb663fe6998f7abaf0cd666aa3d6bea64e81d8d83c92b0351b</span></span> <span class="giallo-l"><span>01185,</span><span class="z-keyword">0x528d123a4c8b57d0b25864c5b3f673c21fbee2a1826dab6cd6ae9ee0024e85f5</span></span> <span class="giallo-l"><span>01186,</span><span class="z-keyword">0xdcefe6dde10acc340d071c61813392ec065800ade9040e5b721fb20fb8239a7e</span></span> <span class="giallo-l"><span>01187,</span><span class="z-keyword">0x25b5519cbb7efa28ff1b23d0f46e38f7b3b2c3fd96d493c5285991894e371f40</span></span> <span class="giallo-l"><span>01188,</span><span class="z-keyword">0xa8eec3288b23734dd343db2bf518380753dd2f602d80584c1a8247f2e2e3466f</span></span> <span class="giallo-l"><span>01189,</span><span class="z-keyword">0x0912534018135146db16c094d6a7a067062a455ba846f44be4d79e2c47094417</span></span> <span class="giallo-l"><span>01190,</span><span class="z-keyword">0x13085b0bb2b86b44d0fd7ea1476bee11b641b11dba8005afbf167cd3526855eb</span></span> <span class="giallo-l"><span>01191,</span><span class="z-keyword">0xe8d4138f22d8fb0fcb988bbded449ceb966203228554022e6e0564b9ed6ea1e4</span></span> <span class="giallo-l"><span>01192,</span><span class="z-keyword">0x7a4ee2172c8081d3f6dddf4bb6c561c8ce3f1af703ac6b591e448c762b8f1d9b</span></span> <span class="giallo-l"><span>01193,</span><span class="z-keyword">0x7c6dae3a659f3b4fad0b797c457a546ef174569dd60a71b6a4fc1e66d1e1f268</span></span> <span class="giallo-l"><span>01194,</span><span class="z-keyword">0x7d063ead7a3d4d51dc59256b72738faf2171d7844da6d5be42af7023f690d979</span></span> <span class="giallo-l"><span>01195,</span><span class="z-keyword">0x68a0b792e3b448d4c36f26611d9b7652585f23f216785bb73d5c27c0c0aed493</span></span> <span class="giallo-l"><span>01196,</span><span class="z-keyword">0x94c969763e706d0e7fba95c4c357b0e855c68be2dbed2e9a7cf7b5daaac5a08b</span></span> <span class="giallo-l"><span>01197,</span><span class="z-keyword">0xa6c39440cf6d60b35b0ebc651ab80a101b0f57d9163379474ccbeac8827d5fd2</span></span> <span class="giallo-l"><span>01198,</span><span class="z-keyword">0xf7a5ab53c462dba797a3b06ab177ba42b11a370240ce077b03fc1fa2b107f4ea</span></span> <span class="giallo-l"><span>01199,</span><span class="z-keyword">0x84b9e12ab6e9c0e7f41dcd01aae0ae2357ed252b3ebd78c0b2d95fff5e032724</span></span> <span class="giallo-l"><span>01200,</span><span class="z-keyword">0xa6b6a963488c4633e7f3af99047954e1c15fab24793fe43a4c9ec2c933031f01</span></span> <span class="giallo-l"><span>01201,</span><span class="z-keyword">0x4a0c7f03de3cfd31752d5100b70f028c31856efa2fd1a3b5a8cec4a342500d34</span></span> <span class="giallo-l"><span>01202,</span><span class="z-keyword">0x5486c645e895bc1bdc91291f74d5ce702e1c2c4d37f005c6c1968c96c4798a0c</span></span> <span class="giallo-l"><span>01203,</span><span class="z-keyword">0x08a5313b986a0428d49ab7b7f6cda4ede434efa3f6a69c5140ee7c46c977c30f</span></span> <span class="giallo-l"><span>01204,</span><span class="z-keyword">0x975103710d4d4cc0c9b337decbad38e6dd42449ad533b3c464801bf10a0f7f8d</span></span> <span class="giallo-l"><span>01205,</span><span class="z-keyword">0x7bbd5580e1faf3394083ed3a12ecc3efeec75b71b52f3c5d2527306d47d46c9c</span></span> <span class="giallo-l"><span>01206,</span><span class="z-keyword">0x61e11a8ca3db52b16ec4c025165e73542fea9eaed696dc528b1fc7d08bab6871</span></span> <span class="giallo-l"><span>01207,</span><span class="z-keyword">0x3745949046134c86ab95f8da5fac1e0b96e9146b8dfe976b95ea8adfdeb10fb0</span></span> <span class="giallo-l"><span>01208,</span><span class="z-keyword">0x4d0cc348ca8825a306f854475c04b618a82336c06150b936407f793bb132e1d9</span></span> <span class="giallo-l"><span>01209,</span><span class="z-keyword">0x2008dcc12d9eee29e24645e17c3a32c8b0fa82423b230b1bca74982ff32499ca</span></span> <span class="giallo-l"><span>01210,</span><span class="z-keyword">0x842d419500195cf77644f8d7f656e9e0c7044c7c0227eef116f0b54bd52b8456</span></span> <span class="giallo-l"><span>01211,</span><span class="z-keyword">0xa9c1369756e021602515ee071013086b92c4050c767db4f6952a5e875dc74415</span></span> <span class="giallo-l"><span>01212,</span><span class="z-keyword">0xa6435d49ee936444ea5411227769e4e92c9bdc5e353fb90feda369d0b357ca32</span></span> <span class="giallo-l"><span>01213,</span><span class="z-keyword">0x71e5659c8984140dac3efdb27964e2e36dabdf863d34d9a44509ab28ff76d3bf</span></span> <span class="giallo-l"><span>01214,</span><span class="z-keyword">0x1791e683cadd2556b588f262ed01f10dec8a17d0fac17264cde17dc821d61444</span></span> <span class="giallo-l"><span>01215,</span><span class="z-keyword">0xb250520d667d2585a11f8515bbc942dde5271dee48bb2079e94fdefb4cd12db7</span></span> <span class="giallo-l"><span>01216,</span><span class="z-keyword">0xa13eb7c2b5320556bec64b033af8d17d73880423b1aeefd6befe0a80516cfff9</span></span> <span class="giallo-l"><span>01217,</span><span class="z-keyword">0x5c83a392daf6735cbd58715ddad8b5ee5ffab29f0d90e9529cca55f1e5a9bf65</span></span> <span class="giallo-l"><span>01218,</span><span class="z-keyword">0xc13220ead135c3a3c44eb1f623db0231af2a830eba39328d3b0eeddba6590b32</span></span> <span class="giallo-l"><span>01219,</span><span class="z-keyword">0x5f56b030ea9674db988e0e19b92ca4f4d0172eddb66b88d1421b761f43f430fb</span></span> <span class="giallo-l"><span>01220,</span><span class="z-keyword">0x512900cbb649da6361f264485c211c79688543284d48129d978f50ee9110ed54</span></span> <span class="giallo-l"><span>01221,</span><span class="z-keyword">0x90c06f460cbaed5f47e45d4761dc4860400fcefcf38a4adc8dac265798ea82d6</span></span> <span class="giallo-l"><span>01222,</span><span class="z-keyword">0x096acd8679ab399726890ee06192292f292205150e75a75d8dbc24fb5b5c4e95</span></span> <span class="giallo-l"><span>01223,</span><span class="z-keyword">0x1a1baa666116d37631224699f89e17da92ae1d5df34857e3429b0eca71f473c2</span></span> <span class="giallo-l"><span>01224,</span><span class="z-keyword">0x34f529a2f72e1e83cd12adeb4dea7f2bdf3d7c96ff50249b27a0c6a65cadca90</span></span> <span class="giallo-l"><span>01225,</span><span class="z-keyword">0xad7198e0def6e143734a5dc947221958a8e506274daa782383fbe833e664d60c</span></span> <span class="giallo-l"><span>01226,</span><span class="z-keyword">0x2d858029db92532563a3dd2e05e63de9600abd032bc3402b598df65b03b96f45</span></span> <span class="giallo-l"><span>01227,</span><span class="z-keyword">0xbb9ed6f343eb8d8aac3a7190c4327752c136b8d2d7a9cc4cd58ce619f2541c50</span></span> <span class="giallo-l"><span>01228,</span><span class="z-keyword">0x024d8b0934652fece1c1009e992ffcd5a39c0bfaf4b9e464b492368fcae0b44e</span></span> <span class="giallo-l"><span>01229,</span><span class="z-keyword">0x4fbd23d89d82ef4034f1bdd888e2b20cd2338e5430326039cc82a8ee32242e3f</span></span> <span class="giallo-l"><span>01230,</span><span class="z-keyword">0xb70e3603aa922716ba38abca5dc445639eff218cbc2ace3e2352be344588676c</span></span> <span class="giallo-l"><span>01231,</span><span class="z-keyword">0x76e468cbc19d282a6075b218eafd19f63234beae51e46b0c2b81bb0b707b0632</span></span> <span class="giallo-l"><span>01232,</span><span class="z-keyword">0x7cd7b651d63b2e5a4f6684ae77ab9d3d913449a92eef5a716ecc947ba553b724</span></span> <span class="giallo-l"><span>01233,</span><span class="z-keyword">0xd077ca788a7927c7d2f8ca57710139fccb6e387c563fdc34aa9c8ca05ae0bf35</span></span> <span class="giallo-l"><span>01234,</span><span class="z-keyword">0xccf5a0f7216ad6bb2ddc6f59917c9d33ef237a7813b09052ce349a26bb21fb10</span></span> <span class="giallo-l"><span>01235,</span><span class="z-keyword">0xd7666847f3b02e9a581f7bbd41e906b894136b4f98503c2e2458718f08d319b3</span></span> <span class="giallo-l"><span>01236,</span><span class="z-keyword">0x3d10b1757feee8ce9ee56ab7d3e36b34895674fa7c6c90b2636e85f0a9e16368</span></span> <span class="giallo-l"><span>01237,</span><span class="z-keyword">0xcfc709d64aefa7fcd84780a576f8d229f3f093993a38b6271826efaba6b55b46</span></span> <span class="giallo-l"><span>01238,</span><span class="z-keyword">0xf6f1e083e51e96a0b399e5878186085e9ca7d12512822558c2ed1e156a72404b</span></span> <span class="giallo-l"><span>01239,</span><span class="z-keyword">0xcbeef9b07ca5099aa5f6bf79fb7d58a0e8418af292e992b4c1f1d9bf43f12aec</span></span> <span class="giallo-l"><span>01240,</span><span class="z-keyword">0x02688fe8520ef9c0a4bc424936bc9b710a973517598bf394274c2a44cc848289</span></span> <span class="giallo-l"><span>01241,</span><span class="z-keyword">0x20ebd6528acd0d0e507af27f82db0aef20556c9dd36f482dd78e12a39cf5855f</span></span> <span class="giallo-l"><span>01242,</span><span class="z-keyword">0xceb89cc1fff1a05d00b8cb8049f5ba68b4e0fc338a5b7593e1bbbbbf4fe7c3b1</span></span> <span class="giallo-l"><span>01243,</span><span class="z-keyword">0x6ca6a14a6edb58aa90fc386305b46048d24dd9b525e204b503970cad8c8864e3</span></span> <span class="giallo-l"><span>01244,</span><span class="z-keyword">0x40769f6cedf1218dd656126546473cdb24657724170f0bd71c0ccdac1edb3e97</span></span> <span class="giallo-l"><span>01245,</span><span class="z-keyword">0xf2f56ea6ddf8226f222ae389816836c60e8fe9bc55e630c93e8d6634a2babbe2</span></span> <span class="giallo-l"><span>01246,</span><span class="z-keyword">0xc0e897c05df5e53027934987158c81a2dab1a62638db704cbacc8a2eb0c3931f</span></span> <span class="giallo-l"><span>01247,</span><span class="z-keyword">0x58d2fe58f1fc86b6ed0e2f210e13723c8ed644dc8d32ffa4e55cc176b7bcbc3a</span></span> <span class="giallo-l"><span>01248,</span><span class="z-keyword">0xe2cdcc7c61fe867dcef5ed3854538fecccc3ee1501b6e66f3132596c79c41a93</span></span> <span class="giallo-l"><span>01249,</span><span class="z-keyword">0x379da93b0902e34eca8296446820ad2e24d3e4feebf1f0faa061e099bcca3366</span></span> <span class="giallo-l"><span>01250,</span><span class="z-keyword">0xafede008f90c6812f90e9cb5a5462e3dad70fe5f0d0fb383f833845659bf25e4</span></span> <span class="giallo-l"><span>01251,</span><span class="z-keyword">0xeeede50f94cb63b7e19cfddbcc3f25e3c06dc4c3a83b001804ca440540d37d43</span></span> <span class="giallo-l"><span>01252,</span><span class="z-keyword">0xc5b81847b51e4e59f89d6cf2361c42f64dc760fce9f0bbd332653de1f7474ef7</span></span> <span class="giallo-l"><span>01253,</span><span class="z-keyword">0x96748f6773bb94d740ab82734c26ffc9daeb4c87606403add65897512864e693</span></span> <span class="giallo-l"><span>01254,</span><span class="z-keyword">0x5c3badc9304a265385eba2afff786a1f9464737b71d9301035b758820354da66</span></span> <span class="giallo-l"><span>01255,</span><span class="z-keyword">0x2599ae05afdf5e1b2be57990d21f985c0133406a8141639dbf33d46e632bf6e7</span></span> <span class="giallo-l"><span>01256,</span><span class="z-keyword">0x2b44aee4e83d46ed4a02abb9ca11c1630073fc6b233c5aac3730f8d28e695859</span></span> <span class="giallo-l"><span>01257,</span><span class="z-keyword">0x4952c5127010c24a46460214617a2cd34a5430ec398ba635392762668b21a64f</span></span> <span class="giallo-l"><span>01258,</span><span class="z-keyword">0x713aba14cadeaaf4ac33853d6a33ae19c0ec40e02821d467577b61e371a53ce1</span></span> <span class="giallo-l"><span>01259,</span><span class="z-keyword">0x1ae7b5ef37e8a2151263bd517645f1336e0907ef1c840b41e8732369ef1d3cff</span></span> <span class="giallo-l"><span>01260,</span><span class="z-keyword">0x6f90c321b6915a06965c7804e6e28aed175cd6d62162eff3fea564fda50fced4</span></span> <span class="giallo-l"><span>01261,</span><span class="z-keyword">0x61d416a84d212bea9580d2eba99ca6cdb0a45ea809d540b49ae52e6a2d9c5f84</span></span> <span class="giallo-l"><span>01262,</span><span class="z-keyword">0xaee21385dd0720113fea63062d20dc69e979bfcb5f295131694752dbfff3dc97</span></span> <span class="giallo-l"><span>01263,</span><span class="z-keyword">0x9fa06b72e89a042853139708961c7114d3197bd3c98c1cef71ca0b34c01652bc</span></span> <span class="giallo-l"><span>01264,</span><span class="z-keyword">0x53a8cc3b6aac658c3b80f92e99521056c4035fc053b6abbd4068e5339dca35dc</span></span> <span class="giallo-l"><span>01265,</span><span class="z-keyword">0x1366aabf8693566d39e974a595eb7e681f57170fa8d98c68e1f7a4397a6f4cf7</span></span> <span class="giallo-l"><span>01266,</span><span class="z-keyword">0x2631621efb6f486a6c82b58c7cba7c37dda933bee528d982b1c25570a45df03e</span></span> <span class="giallo-l"><span>01267,</span><span class="z-keyword">0x3dd94158da7fecd20d03095ac40774de44befb72fcedb2f94ca801619b5aaef6</span></span> <span class="giallo-l"><span>01268,</span><span class="z-keyword">0xed99cb91c4babc2b4eefa48bfc1ab03f710aa2bd4c6e12c60e0bfe78e6a774e4</span></span> <span class="giallo-l"><span>01269,</span><span class="z-keyword">0x3e65584f39c73ae662991d6d27dcfe9563830c5210ea07a12bae36dfeec36436</span></span> <span class="giallo-l"><span>01270,</span><span class="z-keyword">0x69ccf142f770f0bc36ec796d3893b895d9b602100a30528dafa20e5a2c28da1d</span></span> <span class="giallo-l"><span>01271,</span><span class="z-keyword">0x66fbd4f182ada36bac2d86fbdb791807f55f3c2c010c79d8fab7abaa404fb002</span></span> <span class="giallo-l"><span>01272,</span><span class="z-keyword">0x7f448c5eace75539049635435d61193beca590922f7255ef040ebe6da1f29306</span></span> <span class="giallo-l"><span>01273,</span><span class="z-keyword">0x3db6b5ee4daeb3747abef5998ae0ec1def30f96ff98043bc40dfce86966fde81</span></span> <span class="giallo-l"><span>01274,</span><span class="z-keyword">0x63adf378c2182a75a6bbec3cba265ead7a1d31cfc37324a5cfbd44e70d3e2392</span></span> <span class="giallo-l"><span>01275,</span><span class="z-keyword">0x0c89bb3e1a35dd2748bec8ed667b9345d50726cff25f170637c86382abd82135</span></span> <span class="giallo-l"><span>01276,</span><span class="z-keyword">0x399bff6479203b0d07b9409e2adbe174c602acc5f4c2368b4fb399dae9227b5f</span></span> <span class="giallo-l"><span>01277,</span><span class="z-keyword">0x1b14df373ee827661a2c07e3796b21ae8879dbb62ee89588bb43e2843c70b624</span></span> <span class="giallo-l"><span>01278,</span><span class="z-keyword">0x7bb5b29535784cb002cef2e3e34d518d7baa14aa2242dd3cdfd9e6e2801faadb</span></span> <span class="giallo-l"><span>01279,</span><span class="z-keyword">0x4ba003f31b565407c69e13af897dd4acc225a71ca04599415f68ee839e34d799</span></span> <span class="giallo-l"><span>01280,</span><span class="z-keyword">0x2ab6865f17d91c52d0fe177d6b465575f83380ecd7d8c7f9bf31b2377ca0a1f2</span></span> <span class="giallo-l"><span>01281,</span><span class="z-keyword">0xa55982471099400711214ced393e9909d0e04c35e862b6319ada8e63fe9c5457</span></span> <span class="giallo-l"><span>01282,</span><span class="z-keyword">0x8357bfd95a67b8e01b0530b10daa926d6368de1f37ebb787a24893a1813d61b3</span></span> <span class="giallo-l"><span>01283,</span><span class="z-keyword">0xb502eea2d534a1d9646b8cdf01a0021a2fac7b298ae298adfcb18a8adb51bf09</span></span> <span class="giallo-l"><span>01284,</span><span class="z-keyword">0xf9cc24977a6a162a4f21fea4c588d8586d5cb96298a95364e3cb1b50f1878fd0</span></span> <span class="giallo-l"><span>01285,</span><span class="z-keyword">0x5ad4fdc89fbf4b2817a64648f37a14ec2908b58b24a621a12f941d7e3d4e6a66</span></span> <span class="giallo-l"><span>01286,</span><span class="z-keyword">0x4de64a70d6df12d28fcaa8d4fed874f5aab3f070552189ce5e24582539c9f875</span></span> <span class="giallo-l"><span>01287,</span><span class="z-keyword">0x1cd8e301efbf3554bee4a3699272b01033f3a1087a8ea789132a07e1d08bd20f</span></span> <span class="giallo-l"><span>01288,</span><span class="z-keyword">0x461721aa1fba0486391f01c6b60ec368e021573fcef4c62a0d91204470a732b5</span></span> <span class="giallo-l"><span>01289,</span><span class="z-keyword">0xd776cb85c9b392f75696d6bb5733b4aac5f1e83a73719620efaf40a385468200</span></span> <span class="giallo-l"><span>01290,</span><span class="z-keyword">0x873eb969707feb65aa18bb94c3bd32f40fd891708a0977ede54d80ebab7e17a6</span></span> <span class="giallo-l"><span>01291,</span><span class="z-keyword">0x3466a3703a10207162520e73c9350cc646eec8158a0f5913345e0232ec37fd44</span></span> <span class="giallo-l"><span>01292,</span><span class="z-keyword">0xf7c7ef3af85eb27ace55a2b8174ed8d5616f3d6d8457c51678f8c5ce5ff6df2b</span></span> <span class="giallo-l"><span>01293,</span><span class="z-keyword">0xeab36fbdb3f08b469d02903085a59c455c1f8693e76b7005832a872fc19bfc3d</span></span> <span class="giallo-l"><span>01294,</span><span class="z-keyword">0xd38b96b71d18f88b5eee096a8affaeae086170fa9636dbd6d81b7f0bf03d34da</span></span> <span class="giallo-l"><span>01295,</span><span class="z-keyword">0x9a8e547ac87505373cd0a850b2dbcf87fd17a958e86b91f431dfacf8faa1cf9c</span></span> <span class="giallo-l"><span>01296,</span><span class="z-keyword">0x044263f35cee7bbd103e6537a34ef16fa8075121c6b2ac6cb9ccc932de47261d</span></span> <span class="giallo-l"><span>01297,</span><span class="z-keyword">0x2a6fa8404ebef74fb534dd65a52008d9c451c8e133a111118c38b238963d8c60</span></span> <span class="giallo-l"><span>01298,</span><span class="z-keyword">0x25e8cecf4a4009a8a3dfcb6e414a52939dd8f0fec0cdfa43fbb88f6d93e84d90</span></span> <span class="giallo-l"><span>01299,</span><span class="z-keyword">0x4783a5b474945636c48b35187b5236790a932a6688eb9d57663cedbfcc35e96b</span></span> <span class="giallo-l"><span>01300,</span><span class="z-keyword">0x05128f5669874610a201918ac659f325cadd39c596246a946c95c17899f4525c</span></span> <span class="giallo-l"><span>01301,</span><span class="z-keyword">0xf8ad3107c0c201f6c9c855fa7fe31ace8ea37cf483e4466de7ee0cd8d4a1961e</span></span> <span class="giallo-l"><span>01302,</span><span class="z-keyword">0x564f335c0b20dae960b81c7fa6715da2a7a1f32186ee0d0fe6fc162f36a3630d</span></span> <span class="giallo-l"><span>01303,</span><span class="z-keyword">0x0dd93fff7d2ebb6031ca921ae529ff7f0fa881b0b64d0fde89b532250afcb3ff</span></span> <span class="giallo-l"><span>01304,</span><span class="z-keyword">0x20eaa74f7d74b90dd75bf7750d80ce428e75745d60b92500549b4039163e674f</span></span> <span class="giallo-l"><span>01305,</span><span class="z-keyword">0xd00fc022fe14cd175a8a593bd0fc6cf8076872c16fc3672313415760c659de09</span></span> <span class="giallo-l"><span>01306,</span><span class="z-keyword">0x1f67a41c83d8ba9d5206bd10389cc97b98c2b2b50d46c845728f67421c9a8b7d</span></span> <span class="giallo-l"><span>01307,</span><span class="z-keyword">0x2f77e7c868bfd36ad2e2b0864b665ab2ecd6671d8be22c1738d3c01376d0b34a</span></span> <span class="giallo-l"><span>01308,</span><span class="z-keyword">0x8eaf029a66086147ba2206ecdbea385029fa3ea27ae9d93be466ef702f9ef909</span></span> <span class="giallo-l"><span>01309,</span><span class="z-keyword">0x0e9134c94db5ca1f3f8df20c06242afcbc7c099282c1b5662b7528344fd49f83</span></span> <span class="giallo-l"><span>01310,</span><span class="z-keyword">0x36d0712a3ad4551da02c8fbcf6ffb7fc9105d8b651095af88f9168884fec0ae8</span></span> <span class="giallo-l"><span>01311,</span><span class="z-keyword">0xb196f52df231958730a92a4cf0468e2648750cb5665142e160d881bc14e37bfe</span></span> <span class="giallo-l"><span>01312,</span><span class="z-keyword">0x052a3539fc9f8bc4d117b49c1e06b3c2f6ff129297b39d25174c8f0b8144001a</span></span> <span class="giallo-l"><span>01313,</span><span class="z-keyword">0xed3d98e8ee4b3ac94e1bf4f158c783a8415ba5f497f9e33a32f1800d60cc524c</span></span> <span class="giallo-l"><span>01314,</span><span class="z-keyword">0x6711d975c455a06ffe37404f2c044b0212d05580535f0b696e01c40a38ed2e15</span></span> <span class="giallo-l"><span>01315,</span><span class="z-keyword">0xc90257ccd4b09a7a0b1cfafa86eae19b648f0f9ff4d5f9d935b45179c45679d2</span></span> <span class="giallo-l"><span>01316,</span><span class="z-keyword">0xd23ae50b11a0b68e4233b0743b3ba73f087d2e8d9e73f74c100faec8838bf4b4</span></span> <span class="giallo-l"><span>01317,</span><span class="z-keyword">0xb2c5b1b5c44801e3d93702395326af0a9e333f6faa72ec9836bc0c6da90af82c</span></span> <span class="giallo-l"><span>01318,</span><span class="z-keyword">0x803d224bcaa3b2d5d0ba2de2837b8b808215de356282c671fd92e94b4970bd37</span></span> <span class="giallo-l"><span>01319,</span><span class="z-keyword">0xf7082c225833a231427c3a2809a4f77fd79ddf88a94991e251336feba0eeeb89</span></span> <span class="giallo-l"><span>01320,</span><span class="z-keyword">0x66c7f0046df871f8a674e08f13d66ace77969519f44ad0eedf44bee0a543036f</span></span> <span class="giallo-l"><span>01321,</span><span class="z-keyword">0x04af06fa9d5d1b4d162b96a9e979d61028b349d2c474a34d16d0c62761252504</span></span> <span class="giallo-l"><span>01322,</span><span class="z-keyword">0x44c4c046785d0a1596bfa34133b74b47e16a4eea6607b7633d84e90ed816d4b4</span></span> <span class="giallo-l"><span>01323,</span><span class="z-keyword">0x570d0caa96bbae3e4b2afc7f01b62f3d90fe232cb3797cfe54b52c3840bba0be</span></span> <span class="giallo-l"><span>01324,</span><span class="z-keyword">0xd4cb7a0d9740bace6d20e145e01f654c3388393fbc655b41d8693de6bb960506</span></span> <span class="giallo-l"><span>01325,</span><span class="z-keyword">0xb10b22ec3ae6d7252bd04d9bd6f2aeb5759cd1c33df99d43230b5dc2812fb5cf</span></span> <span class="giallo-l"><span>01326,</span><span class="z-keyword">0xea52129a4b82c6183fc1713117ed5d1803135642c2544612dbdaa6fd06be1b25</span></span> <span class="giallo-l"><span>01327,</span><span class="z-keyword">0x4f88b08507b8fb608565635faa36f8b09902017b2dfefd8091b05cc698e072a5</span></span> <span class="giallo-l"><span>01328,</span><span class="z-keyword">0x83f1204e20b3770edb57289e7f64401d79365d0c0e02a84c9c2c33ffdc496693</span></span> <span class="giallo-l"><span>01329,</span><span class="z-keyword">0x572dcecfe36d6a5159f90810209186d900bd940b27e56a8d1150aa4760e5b99b</span></span> <span class="giallo-l"><span>01330,</span><span class="z-keyword">0x45db98fb860512b9cbfce82e225581bc15103e772c385102f63aecc98b3053ce</span></span> <span class="giallo-l"><span>01331,</span><span class="z-keyword">0x79ac113e80705dc36acef32fd3d844dcda82fde0962d92da38a07e585edfaf40</span></span> <span class="giallo-l"><span>01332,</span><span class="z-keyword">0x2e02ff938a46434155167db8bc7aab30bb1380b9e3e7a61605bb4b98312305be</span></span> <span class="giallo-l"><span>01333,</span><span class="z-keyword">0x1c8da535daab62298766c9eedb38110eeafe1d6c2fc0a6fe344486e50d23d57e</span></span> <span class="giallo-l"><span>01334,</span><span class="z-keyword">0x9983596d69c4ca9358001d6e1569a17f8c35a885ba9dc1629aca595c0475af7a</span></span> <span class="giallo-l"><span>01335,</span><span class="z-keyword">0x4143f16c56cdd171e39f8a54a3bb2d2dea69490672df9fa7e30378def8867730</span></span> <span class="giallo-l"><span>01336,</span><span class="z-keyword">0x2c80acab236f71b43e253b5268c172dc3f413cf145e0216d7f6c13065422a2bc</span></span> <span class="giallo-l"><span>01337,</span><span class="z-keyword">0x70afebf06271380039afba9d7b5157f905d89598d03042f4bf4cc827f1d7b200</span></span> <span class="giallo-l"><span>01338,</span><span class="z-keyword">0x0d957f43c8483a069456ccdf1c44cfbb355796198e5b35eb365d66189c934b07</span></span> <span class="giallo-l"><span>01339,</span><span class="z-keyword">0xa954d4bbfb037a0e8f081be2b609544df79fc5f84f346fe687c83055e86b785f</span></span> <span class="giallo-l"><span>01340,</span><span class="z-keyword">0xd259e3dbd24e5d08dbc1cf127159be9095f93cb2e035fc12cd4dd9df06ce4d91</span></span> <span class="giallo-l"><span>01341,</span><span class="z-keyword">0xa393c46b554c380371d5f395f99c878959168fb83b010ee586dd627ea5ac81f3</span></span> <span class="giallo-l"><span>01342,</span><span class="z-keyword">0xfebdbdcdc98e1286f41f504e2457d4b9ad17d1747bfd60a3b16fba723620efda</span></span> <span class="giallo-l"><span>01343,</span><span class="z-keyword">0xc205cffc694cd333edf5deb8023b04a96ae6563e1de4acb4d93f34ce095a50aa</span></span> <span class="giallo-l"><span>01344,</span><span class="z-keyword">0xe55d1bc51b81c62134e654fd69d9c13dc329454cef1328f1579d034178625187</span></span> <span class="giallo-l"><span>01345,</span><span class="z-keyword">0x18129517d6e589a3e497f93dbad3e63b013dae40ec88ef3e1f3910b655442848</span></span> <span class="giallo-l"><span>01346,</span><span class="z-keyword">0x62600923c76a890ebe7b693e545c5f316a329cc622325ff9159159322ba772f7</span></span> <span class="giallo-l"><span>01347,</span><span class="z-keyword">0xb7bc048ba653fbc6fa6590215174988a56bd0615952242f026700ae0ed9e44d0</span></span> <span class="giallo-l"><span>01348,</span><span class="z-keyword">0x63f08fbe35edc8666cd54f8b313029ccc744b622842266a11085320771a781f5</span></span> <span class="giallo-l"><span>01349,</span><span class="z-keyword">0xd8f90a763e74c5cbcc2f745cd41dfc34742eb9d91665d71b201e8f8d4cdde52a</span></span> <span class="giallo-l"><span>01350,</span><span class="z-keyword">0x3b7ca4efb889b761f25df46f30cb916074f5f80e5bfb4a500896747da243b54a</span></span> <span class="giallo-l"><span>01351,</span><span class="z-keyword">0xa5aeba3be9d1c93c5d8cf0ec419893fc0d2fd193cc9d60b52d2fd7abe6cf4820</span></span> <span class="giallo-l"><span>01352,</span><span class="z-keyword">0x75faba094a42b7e78000daf1ed774e8ed6ecf34bd142470238d1d16741003ae4</span></span> <span class="giallo-l"><span>01353,</span><span class="z-keyword">0x53743d70a74f3b85815f71200d6c3c044df0ffc75fe8dc56a8f9a3ad106d880c</span></span> <span class="giallo-l"><span>01354,</span><span class="z-keyword">0xdcc29cd5c2804269d16f68f212fa4318cd10f686761ba1e012a2bea667d8ed2b</span></span> <span class="giallo-l"><span>01355,</span><span class="z-keyword">0x73301488b070bb8268c358f07b89b07cb19d2ec612edbd30c10c7c83349f0439</span></span> <span class="giallo-l"><span>01356,</span><span class="z-keyword">0xc5358154fa2c30230dcb62a3ae16f03ddd07e3fb9ecb53b0813ba432aeaa6743</span></span> <span class="giallo-l"><span>01357,</span><span class="z-keyword">0x6ae35c6d816695c2e73892ddb5fa55282a108796ddfc1059a60d14ee87ed06ba</span></span> <span class="giallo-l"><span>01358,</span><span class="z-keyword">0x40401985fc52c0c38cc1951a0079728513e34711517fb89e8c8893f889f834a7</span></span> <span class="giallo-l"><span>01359,</span><span class="z-keyword">0x4f6b265815c3a8d1595aeb9e2039c9c73e06a69e746d06d3e4adbd09ade7ddfa</span></span> <span class="giallo-l"><span>01360,</span><span class="z-keyword">0xd0b1559c6907e19eec7b32ccf02f63bfe932f3ec95d28de33250f0e2929b18dc</span></span> <span class="giallo-l"><span>01361,</span><span class="z-keyword">0xef5b459d7ac7c2743f4c0fe6adee0d06a89971dcfb7d959f087b7b57f12c5d1e</span></span> <span class="giallo-l"><span>01362,</span><span class="z-keyword">0x08dfe9e3cf1e444d51c5a61d42a03d90f974513c237d2f9684995f399ce35d56</span></span> <span class="giallo-l"><span>01363,</span><span class="z-keyword">0x80f7dfd0b5347cde3ebd66b78dcb3cf55cfcdbbc019c75e2f69bf9f97e393263</span></span> <span class="giallo-l"><span>01364,</span><span class="z-keyword">0x4b47710e8532de589c562f34bfa75a8333a26937ba10f86d7327afcbf0514cfb</span></span> <span class="giallo-l"><span>01365,</span><span class="z-keyword">0xcc79e6c613537fdc17caef5f69d705741d3ea81e4bb6d277304d243aaae7f3c4</span></span> <span class="giallo-l"><span>01366,</span><span class="z-keyword">0xd76553f60e2e468719e30bd8cbfb967a00cf6841fc520c86d0aaf400db5defc5</span></span> <span class="giallo-l"><span>01367,</span><span class="z-keyword">0xd7efc68f4fdd73317255edf40a2be339ce739e5f0911f447511c763a494160b8</span></span> <span class="giallo-l"><span>01368,</span><span class="z-keyword">0x17ea70afa701eca1af56e1a15f3d1604a3fa7f9f32e8a60b52d41708d15d8020</span></span> <span class="giallo-l"><span>01369,</span><span class="z-keyword">0xf4a498dff013a59d243cfc41a176d2e7584d686d4ae44f6dfdde575d88529fe3</span></span> <span class="giallo-l"><span>01370,</span><span class="z-keyword">0x027e2a2d5bbcb6fd1867eebf440e44ac1f7ded4acd265d97ab1db0e5a1169cfb</span></span> <span class="giallo-l"><span>01371,</span><span class="z-keyword">0xb90ef17e2d9981a11ef0cd0a735c7116d9a233a825903096e2cb07ea8597ef0b</span></span> <span class="giallo-l"><span>01372,</span><span class="z-keyword">0xb47194832a5dc01344496c495b28e1d202ee22841c8ffa1857d05ce0944424cb</span></span> <span class="giallo-l"><span>01373,</span><span class="z-keyword">0xb999269e83d06f6df620c6f5f94964f5a643fbb64dd2c4d7f58eed88798cbd6c</span></span> <span class="giallo-l"><span>01374,</span><span class="z-keyword">0x662f1591b37f2982f426f3003ed9147f96014bb12963e49e63ad1b55e2cd78dc</span></span> <span class="giallo-l"><span>01375,</span><span class="z-keyword">0x108ccbefa9906c080c5115f77f9ecd63381b9ffb0930227cb2630f4b08d8a090</span></span> <span class="giallo-l"><span>01376,</span><span class="z-keyword">0x54d2962953fce8d8a641bb8cd1c9eaafe89f9ac9546b8b277d9b535fb35a0097</span></span> <span class="giallo-l"><span>01377,</span><span class="z-keyword">0x6d7bcae503db8d3f3771cf9e8038a1fdf3987beb6212755704560a0404118063</span></span> <span class="giallo-l"><span>01378,</span><span class="z-keyword">0xfd477f0bf18d87a2bd3ae3c329e468a7bb16a363ec3fbf658f55ecb98fc16d17</span></span> <span class="giallo-l"><span>01379,</span><span class="z-keyword">0x57b72b9a11da9b25c2bb52b648db7870e039a64439fd271fa320bd2fe789775b</span></span> <span class="giallo-l"><span>01380,</span><span class="z-keyword">0xbeacd779ff788ab12f79382ea205b1b180c7e43302e902c32fa577c0925144ce</span></span> <span class="giallo-l"><span>01381,</span><span class="z-keyword">0x4b6c00275a131aa994d1e86e9246196299930ad5fc218d09d0b66265234e32c6</span></span> <span class="giallo-l"><span>01382,</span><span class="z-keyword">0x485b0ed3728e693a618ca77659c55114a8f602ccd71fa6138e87e11b49814289</span></span> <span class="giallo-l"><span>01383,</span><span class="z-keyword">0x402cc664b8b4b8dcac9aeba636f3c902a713874d9fc6bd6c7dc338817c1eac76</span></span> <span class="giallo-l"><span>01384,</span><span class="z-keyword">0x547da0f4446ebbba63eba970ec761c7a08451eb11251c91cd6427cdf475bf00c</span></span> <span class="giallo-l"><span>01385,</span><span class="z-keyword">0x058c55b0a6a077ed8882d135e4cb364b250d392eba6ad4e578fe910c8c9f340d</span></span> <span class="giallo-l"><span>01386,</span><span class="z-keyword">0x951ddf6cc9c8cae358c63a8a8b5037a970cc5a3e9ad55fca7e4c85bf86c935a9</span></span> <span class="giallo-l"><span>01387,</span><span class="z-keyword">0x85a7797dd4dae08cae7218cc8c2497b580ad037427bf7e351f20f1edfd695d57</span></span> <span class="giallo-l"><span>01388,</span><span class="z-keyword">0x64376e672282c2691f4dd0a88ccdb12d561cd88612d689f2802744490e275e10</span></span> <span class="giallo-l"><span>01389,</span><span class="z-keyword">0x58445b6bcd79648c107c45ccfa2c2246b0bffbfc0c9c8750b934894144105f87</span></span> <span class="giallo-l"><span>01390,</span><span class="z-keyword">0x6a2d6ce478b520818b85e08d1beb56fb4d6d656aef8f26020cc9a1781a4cd96d</span></span> <span class="giallo-l"><span>01391,</span><span class="z-keyword">0x330e88ac3fd46d3b66946b2bd2e342e0906769ba42be06f01ed224dc7ae90640</span></span> <span class="giallo-l"><span>01392,</span><span class="z-keyword">0x3bf42cf0cd0e8199fffa9b453dea46a65409ec5430638e189e8f60132fbd19b0</span></span> <span class="giallo-l"><span>01393,</span><span class="z-keyword">0x239fa3d0c11c26d29efac03c04735050e83c55686975a8753bbbc83349316a48</span></span> <span class="giallo-l"><span>01394,</span><span class="z-keyword">0x76707dbf2c1a10e6f1aaa37be9374185d3eaa2253594e5ff3482e436841e6b50</span></span> <span class="giallo-l"><span>01395,</span><span class="z-keyword">0x4bcaea6c1d0723bab48d33acf6e6bcbb6016c405f710f19e8542290568510ec4</span></span> <span class="giallo-l"><span>01396,</span><span class="z-keyword">0xcc5b5c9a71d2e0b16153477cdb827aaf6feb3f0758218dccddebcf0e0f0bfb1b</span></span> <span class="giallo-l"><span>01397,</span><span class="z-keyword">0xce3fa54e8a5338bf4a395b0d522e35d60b473c9f8507d6def5dd7da739aa5317</span></span> <span class="giallo-l"><span>01398,</span><span class="z-keyword">0xd06c9a048e07da77ad07dfd45f48cdcab8eac2cd6ab44fe9db7778498d1200ac</span></span> <span class="giallo-l"><span>01399,</span><span class="z-keyword">0xe131599e0fa8cb136a8425b02becb4d42888bde686d9d88b6248216a583dbc87</span></span> <span class="giallo-l"><span>01400,</span><span class="z-keyword">0x1a628757bb1610b0c239ae56df58324c7cf5b5f3f18bbccea4dd67b1ff9be9a7</span></span> <span class="giallo-l"><span>01401,</span><span class="z-keyword">0xe7d4a88015acd605be12a616c899590059d306c69aff9a1876d47c276ea96231</span></span> <span class="giallo-l"><span>01402,</span><span class="z-keyword">0x85d3f3038ba81ba3c5c5a86cec0e55ecd3865f4bcb2e7bd9fb8390e06278ea2d</span></span> <span class="giallo-l"><span>01403,</span><span class="z-keyword">0xe1e41aa6c6d1cc5313c8f2a0ba5c50098c30f49b4a8ba5ea8d89e334be0ffd96</span></span> <span class="giallo-l"><span>01404,</span><span class="z-keyword">0xeba27a233d1a0b76360d1ec6793544482a197f01a47d29474b64982d043c9807</span></span> <span class="giallo-l"><span>01405,</span><span class="z-keyword">0xb0ddf49dcc80359d5bbbd56b5a1e53a8fa78fbb3563c806f1a8a91b51cc8d082</span></span> <span class="giallo-l"><span>01406,</span><span class="z-keyword">0x651ac24a55b66ed30dc6b260af6a9b6aff2c1e0e8433534a353d2b9463d650ee</span></span> <span class="giallo-l"><span>01407,</span><span class="z-keyword">0xa76ac2e092a5e5db97ef6af6656dff4aa47fbf036bfb5ca2dea8fe0dea9635e1</span></span> <span class="giallo-l"><span>01408,</span><span class="z-keyword">0x209624ba6ce8936b8a37223a76d35394b8a3e1c55f0e23dadd60da82e867fc81</span></span> <span class="giallo-l"><span>01409,</span><span class="z-keyword">0xaf729a25d80ddd3c0688e76207ff9ee0ef4960a696061fc1e32c39e69b40289a</span></span> <span class="giallo-l"><span>01410,</span><span class="z-keyword">0xa53b25ca9678e87be1fcef929c93d97ac456308f8405be0910fc8e917f264042</span></span> <span class="giallo-l"><span>01411,</span><span class="z-keyword">0x00cba9ae4ebb3a6e3876f16c22db9914e07a4a175b582fdeefbb60001dae465d</span></span> <span class="giallo-l"><span>01412,</span><span class="z-keyword">0xda3d50bfc90ee547701ab1777f4cc626aae0183fe5d1f42df31048ea85c2a626</span></span> <span class="giallo-l"><span>01413,</span><span class="z-keyword">0xfe77f727e1f01d1287955db0e75a11f8f1077ebe78a7c96ecaf808e22009fa9e</span></span> <span class="giallo-l"><span>01414,</span><span class="z-keyword">0x1053d23c71dc7e09a2250926009b353ea3f44a599953e347de0fd8347d677762</span></span> <span class="giallo-l"><span>01415,</span><span class="z-keyword">0x1f9ee40833afefffc10bd0f240252f1fc70ebd6bd9fe7894816a369f78f40940</span></span> <span class="giallo-l"><span>01416,</span><span class="z-keyword">0x162769df545470c247d848320910bb169a9c95859e676d531bcae4ff4eaac292</span></span> <span class="giallo-l"><span>01417,</span><span class="z-keyword">0x6904f50508e80bc3f8fd40550fb06c98df9da1f1fce47c95e81e47a030917002</span></span> <span class="giallo-l"><span>01418,</span><span class="z-keyword">0x668379548128b70fe1b31b174c6daa8a0915557d1769beb2bcfab9f95884baaa</span></span> <span class="giallo-l"><span>01419,</span><span class="z-keyword">0x55bb8c9a8b55e224e139cd6f93893700ac261f27a2eab8f2d493d734366d1749</span></span> <span class="giallo-l"><span>01420,</span><span class="z-keyword">0x37cb2c92be70871a49bcea2f3d90a6215a72609ef728c8e46922cbd6737c2c86</span></span> <span class="giallo-l"><span>01421,</span><span class="z-keyword">0x05b6cf1bb6f912a9a46dd729ba1ea392e517ad277bb69b758dc88ffb08313288</span></span> <span class="giallo-l"><span>01422,</span><span class="z-keyword">0xcf2496163a204528e56831eb7cad31b71b85aee9c8d584270c9728154e6a0bd1</span></span> <span class="giallo-l"><span>01423,</span><span class="z-keyword">0x8500cec01a3af6600559bd3f68e2607eeacf62fc773fe4ea467c0592c9cf650f</span></span> <span class="giallo-l"><span>01424,</span><span class="z-keyword">0xf9b23ca9378f773d6ce3ab66eee7f70e84b52cb82be13876d2cb7073dfc765c6</span></span> <span class="giallo-l"><span>01425,</span><span class="z-keyword">0x2e9e77d2e086db1a3b04a73d17cc79247012b93c4aead1462d688857c983b16c</span></span> <span class="giallo-l"><span>01426,</span><span class="z-keyword">0x8c07100577d5a565f3962df52798a8e7c74eded7237c57b6287308e30693fc31</span></span> <span class="giallo-l"><span>01427,</span><span class="z-keyword">0x53b8caf6ce7524bd3161dabdee75a7948cb6813045b9422f0243b91d1a8046d5</span></span> <span class="giallo-l"><span>01428,</span><span class="z-keyword">0x68be6c9f0b492c78b2598baf1e5a8d8c45a7738d41afd795fc57a6b9e5acf34c</span></span> <span class="giallo-l"><span>01429,</span><span class="z-keyword">0x12a34f393f9f0f3e7630b128ba992bcb8bd211f817a4e14869d78cf465aebfcc</span></span> <span class="giallo-l"><span>01430,</span><span class="z-keyword">0xff0a7be97f4019b220ec1afd81839cc10dc9c9d897a7131fc805393f82f998e8</span></span> <span class="giallo-l"><span>01431,</span><span class="z-keyword">0x64d4fc5bc06327b48928cfcfa93581a8f840c950551365ab35029583fed9b421</span></span> <span class="giallo-l"><span>01432,</span><span class="z-keyword">0x2205cdfc0fa6fd60df16cad0281d1321bb0727e0d9dda4e5695a415f8b0d25bc</span></span> <span class="giallo-l"><span>01433,</span><span class="z-keyword">0xe4ccf7437255286798c6e3c8181f1d4981ea17ba6560bd9e25a86a4a558ec60c</span></span> <span class="giallo-l"><span>01434,</span><span class="z-keyword">0x7720205861646892f7d4f654cbfb82e1efed9fa75fa779614a2d7f71a6a3546d</span></span> <span class="giallo-l"><span>01435,</span><span class="z-keyword">0x467addf009150a231cbf58b439c8ee6859807d2cc444b5391288e84b73437e78</span></span> <span class="giallo-l"><span>01436,</span><span class="z-keyword">0x8bd916a854e374573059266dd6eccc83a260c544a246cd8df022c12864d00a4a</span></span> <span class="giallo-l"><span>01437,</span><span class="z-keyword">0x332b343d821178fd9f67670662e7d60926135fbc724ac83e15f76ac77fada151</span></span> <span class="giallo-l"><span>01438,</span><span class="z-keyword">0x595d9cbeefcaf6ef0d0ca2e5b5e221777f7fb99a07f07f398759960a16ffedc4</span></span> <span class="giallo-l"><span>01439,</span><span class="z-keyword">0xaed3cc6afce54a6dd6c0b6a68532d860d99ad64abb3550594166f2a5d1086b58</span></span> <span class="giallo-l"><span>01440,</span><span class="z-keyword">0x41f0520f9167d87677b563d4652b1929a1cc45d49f59803bf30d288a1be2b06d</span></span> <span class="giallo-l"><span>01441,</span><span class="z-keyword">0xe2a38fbc4c762ce28ad95fcd0b38b461fc43cf005e1c0efaa1a95e8b08496fd1</span></span> <span class="giallo-l"><span>01442,</span><span class="z-keyword">0xef37dd9b1d91abce595f8e07f4b8200ff75af7d59811d7c222ddd0dcd5657b8b</span></span> <span class="giallo-l"><span>01443,</span><span class="z-keyword">0x145a661e91fd5f7e7004a06124642067355ac94d3812c17dd7e28ab63e2b3bef</span></span> <span class="giallo-l"><span>01444,</span><span class="z-keyword">0x9821beb8f5dcea100a98816920637fc5644bb4aae4d43e14056546177db2d2ff</span></span> <span class="giallo-l"><span>01445,</span><span class="z-keyword">0x728597bdf315ebb1b2ab95a2cc6bf7b4b4740e6e6cb73be78c0827c9791d614b</span></span> <span class="giallo-l"><span>01446,</span><span class="z-keyword">0x5ad80991f59ab3c3f5d9e4b0a64a0d1622a6f7201e6b4c9ab17425ef0e9c6328</span></span> <span class="giallo-l"><span>01447,</span><span class="z-keyword">0x6b884caccbb53424351a0707fd38ec1780332432704f637261d061ce81669fb0</span></span> <span class="giallo-l"><span>01448,</span><span class="z-keyword">0x869cb3c70c4fbab00ea39f9b8954bd0efc32ff9386d347d7731b482ea2fa1035</span></span> <span class="giallo-l"><span>01449,</span><span class="z-keyword">0x5cac1bcb33f6344780d0ae7effa537b4597e788655c7f0ca76f6427ee6951593</span></span> <span class="giallo-l"><span>01450,</span><span class="z-keyword">0xb92784114f94f68de5bc7ea7ff301e8123ad1ae21211d9fb843a809198f34732</span></span> <span class="giallo-l"><span>01451,</span><span class="z-keyword">0x32f5e0e5826dcafa56e2102e122b65f91f47edbe4fd164774c5db7b3163d749f</span></span> <span class="giallo-l"><span>01452,</span><span class="z-keyword">0xb43138d20c9f3a4ad12f1c6a14975528e934c45e0821fbbf924bd0e97c7ce091</span></span> <span class="giallo-l"><span>01453,</span><span class="z-keyword">0x34bcded8fb20b97fb638a8f0b0b88da53ee9e9ab8e31c2ffcecd7cd172532e20</span></span> <span class="giallo-l"><span>01454,</span><span class="z-keyword">0x11f80fd32648f792ece5e55a241f473f2733f6b2801df8be9679896d18947871</span></span> <span class="giallo-l"><span>01455,</span><span class="z-keyword">0x18ea77d047b2a9fb5aabac87543ec56952c28aac11ecee3af95a4aa559bfed49</span></span> <span class="giallo-l"><span>01456,</span><span class="z-keyword">0xf1aadb7cf016bd145d3abaaf1a285545e331a9878f8291692df22fa7ceb34ec6</span></span> <span class="giallo-l"><span>01457,</span><span class="z-keyword">0xd00e9e6ffbb61a46cb574900034b3ee2e8ab614b1182d29fb228603016385094</span></span> <span class="giallo-l"><span>01458,</span><span class="z-keyword">0x7ffab11d609947e556ac0f0aa0e92c8d1b7daae7c691e159e31bc2de3090e2d0</span></span> <span class="giallo-l"><span>01459,</span><span class="z-keyword">0x6039b280fddd6ba4e398335bf0fabb83cd421c12d6a18f18b9f60249e3456e65</span></span> <span class="giallo-l"><span>01460,</span><span class="z-keyword">0x8e889e14bc66328b31238cec0e5ca5de362bf8d995519de91c4c14a4f6dfd6db</span></span> <span class="giallo-l"><span>01461,</span><span class="z-keyword">0x773c0e114f7bb0a7cdca0a604b930a3c77b35d4033a7eebaa8d380121a2441f9</span></span> <span class="giallo-l"><span>01462,</span><span class="z-keyword">0xdf1babfea1ab0a8d9ae94988ffd97916576340ee9f76a697b4d783074a15cba8</span></span> <span class="giallo-l"><span>01463,</span><span class="z-keyword">0x6d328022fe6152777777c85775f267864398abdd880baa956659469fee4c22ec</span></span> <span class="giallo-l"><span>01464,</span><span class="z-keyword">0x1c7eb43c12aa64d6dbebe5f9946254cb7d4960e919112034b25cd78ba4c7fbf4</span></span> <span class="giallo-l"><span>01465,</span><span class="z-keyword">0x10ffef9e33b607326adbb5aabb35e832952a99fca4662af142510332b9033a16</span></span> <span class="giallo-l"><span>01466,</span><span class="z-keyword">0x7785bbd4cc92a53101de632d4335e09d7e3a7f8b8a2e5263d884c2e02f3541df</span></span> <span class="giallo-l"><span>01467,</span><span class="z-keyword">0xb09a9b8e7e62a4ec64bef12e9b6467b0f7276db516b270cfee9b8f30b59e9349</span></span> <span class="giallo-l"><span>01468,</span><span class="z-keyword">0x1919baf88fb35ea864c6e86c74db4a93ba81d8c573d53716fe6cb56804bb4c8d</span></span> <span class="giallo-l"><span>01469,</span><span class="z-keyword">0x6338bf7f5a36a7559ab4b7abf0b3882c81aa369425bcf4718ac690d237d6e53d</span></span> <span class="giallo-l"><span>01470,</span><span class="z-keyword">0x46fb7a9b26b5de93dfe8027aef0949cc8f81c523fcf3e578e6ac296acd396296</span></span> <span class="giallo-l"><span>01471,</span><span class="z-keyword">0x18fb7c8f934ec0bd79726a6dbcf9b1949eae47eb8e8a59fc60821d374e5cad5b</span></span> <span class="giallo-l"><span>01472,</span><span class="z-keyword">0x47a32b9d02c3f8fe8780885803d922d76e5ba346335f99c8b46bff9d33530a57</span></span> <span class="giallo-l"><span>01473,</span><span class="z-keyword">0x333b7e8665b4aa205cc4136efce2add43fb3803b43a7f33e9386790b0846dab2</span></span> <span class="giallo-l"><span>01474,</span><span class="z-keyword">0xfe24e3c1483ac948bb8e3ec3ace550f72726f2025abaf97dbee5997a2d7798f0</span></span> <span class="giallo-l"><span>01475,</span><span class="z-keyword">0x81c78370e6f8e1054f5492a086f354fdbbdee13fc5eb433d5b70f6bde808feea</span></span> <span class="giallo-l"><span>01476,</span><span class="z-keyword">0x857187a16d206dcf5ab6d0f375defe4689f638952e7be7e214a18ef95f612588</span></span> <span class="giallo-l"><span>01477,</span><span class="z-keyword">0xad00e0b4f49ca226ba794de114b83f21049c9678d956ecd0a9456509a4d33b65</span></span> <span class="giallo-l"><span>01478,</span><span class="z-keyword">0x8994eaa1d20c7865333115069f8f9b5d500b0ac5b77759a7938c4a9817e8a864</span></span> <span class="giallo-l"><span>01479,</span><span class="z-keyword">0xcf4abf0e245ee8096e0a34974636acedc772135d2f99a493e78e84171c30d4fe</span></span> <span class="giallo-l"><span>01480,</span><span class="z-keyword">0xae5f5367ea0f5fcae4b0cb50813b16611d4348211979e922c039849237dc7e0b</span></span> <span class="giallo-l"><span>01481,</span><span class="z-keyword">0xa121c10e9e5b9ebfd54ddf768c22b1f9a0d99b1d002f0c14133b9069271a577d</span></span> <span class="giallo-l"><span>01482,</span><span class="z-keyword">0x2110d171195a2de44d08df4b38a9ec39242e74e177a9a330137d2cfad24f0e6e</span></span> <span class="giallo-l"><span>01483,</span><span class="z-keyword">0x56ec2844150d5baf181784999e0f12eedab61b6d106be33e2e5f4ae7cd9923c7</span></span> <span class="giallo-l"><span>01484,</span><span class="z-keyword">0xba8ad4f1b96b86c81781dcd63aea4d8c817762f8950ad31b7b516ec86dbf9c56</span></span> <span class="giallo-l"><span>01485,</span><span class="z-keyword">0xc56c3ef61383b31fe0426d4e7e6101b3ee93e36f8743513d6f2827f6dc7443e2</span></span> <span class="giallo-l"><span>01486,</span><span class="z-keyword">0x57bc41042e73f44a9ffe5ad0ef0ed6a750b254d6174182d31210ec154bd5a6a2</span></span> <span class="giallo-l"><span>01487,</span><span class="z-keyword">0x122d8e0fb38045e75447d5d4b098ded50d3519ab133f407f16ce80b7811f59f9</span></span> <span class="giallo-l"><span>01488,</span><span class="z-keyword">0x42b25fd38e95b67a02cf2d2420f3baf74baf05cd3daa21c7d8422dd4ef082073</span></span> <span class="giallo-l"><span>01489,</span><span class="z-keyword">0xb1acea4e751f8ab84a1701a3810b7425d7bd25b9a11191b8439d9ef021a0ae99</span></span> <span class="giallo-l"><span>01490,</span><span class="z-keyword">0x34280f11add3d4fbc26f35a2bc3163e20bd68b0b2c5f5c977b3c5515f7f89c78</span></span> <span class="giallo-l"><span>01491,</span><span class="z-keyword">0x503bfdfdf60af3f68c00940ce18790b5a4b27708860b9397c247b65ea306f9ac</span></span> <span class="giallo-l"><span>01492,</span><span class="z-keyword">0x1b74997d1c74b3925d68bfb59f89532c82f8d40442462a20b8f8a247223217ee</span></span> <span class="giallo-l"><span>01493,</span><span class="z-keyword">0xedfb26fba9e0f118447e4f1a2f427cbfe9b42bf74c74c8c347718c2bb25de638</span></span> <span class="giallo-l"><span>01494,</span><span class="z-keyword">0xda405d1305cbe42530cf2a03f23706e2c2f0d5c4a8e3fe402026ac7cb9e00c7f</span></span> <span class="giallo-l"><span>01495,</span><span class="z-keyword">0x3efe0cdadae9231c400665a65dee22fccf36020f991fbc5fc80a692a15e04100</span></span> <span class="giallo-l"><span>01496,</span><span class="z-keyword">0x809b00b05e0da5745ec980caa06cd88004cd61873bee830f9da8d9cee061c0ce</span></span> <span class="giallo-l"><span>01497,</span><span class="z-keyword">0xc6923521f989fdf033fef5f95561230bf2bc872c3be7088a3a0986f40417cbc2</span></span> <span class="giallo-l"><span>01498,</span><span class="z-keyword">0x2ef9dbc94aeec86917f3545afcf139cb1092ae35566cb03667d71fa7b4a413e6</span></span> <span class="giallo-l"><span>01499,</span><span class="z-keyword">0x23a65ef9fa71a5631cb9be2f1108a6ae5a52fd9123102d43b167267c5c0b6d86</span></span> <span class="giallo-l"><span>01500,</span><span class="z-keyword">0x17e97c499981088f01ee7fd4110bc4e39552c70c535b2c01bfb825288c652cd1</span></span> <span class="giallo-l"><span>01501,</span><span class="z-keyword">0x38815f395760557cb4ceaf43f9bd59d7f3ae3438d98e2e8e89a1a985d77def48</span></span> <span class="giallo-l"><span>01502,</span><span class="z-keyword">0xc31ef6bf0361e3147b5cfa201a4296245cb801a4933e6e3c7c4040789fe39ebc</span></span> <span class="giallo-l"><span>01503,</span><span class="z-keyword">0xc5393ba2406bc0b84edc863f36c63116e6f3ce5b3af9063cda7516ed664feddf</span></span> <span class="giallo-l"><span>01504,</span><span class="z-keyword">0xb478f53b462aecc80018fc12f270409c9c21616d076a98f26dbb6bc76171fc03</span></span> <span class="giallo-l"><span>01505,</span><span class="z-keyword">0xb8013f87cc39daaafdcd88f6338920b22c471bf7d7b589963a6ada06bfaea470</span></span> <span class="giallo-l"><span>01506,</span><span class="z-keyword">0xf23ee99501bb670f523caf0761c956324dc590fed811bc4f6471b6c458805e5f</span></span> <span class="giallo-l"><span>01507,</span><span class="z-keyword">0x21b534cf9c9af1ea839aad996558e17bf8698d1c0b6d1ccdb858fb19bf78fdc9</span></span> <span class="giallo-l"><span>01508,</span><span class="z-keyword">0x9fbff7e7dce3188b5c5503deaa65b47c43c304c52f3f1f4fa5e8221759c75330</span></span> <span class="giallo-l"><span>01509,</span><span class="z-keyword">0xe5141a21f39698a7b78ffce400c185d65fc6145c08b97e5630b16fef5cfea317</span></span> <span class="giallo-l"><span>01510,</span><span class="z-keyword">0x87aec91b6b6a9b92dba7163b403a463f001693df580b79d1b630413de7c62540</span></span> <span class="giallo-l"><span>01511,</span><span class="z-keyword">0xb041bb19cce32e94aba5ab72f8b325fe14088e933331cb81c090dd64628e3276</span></span> <span class="giallo-l"><span>01512,</span><span class="z-keyword">0xe41b5ac2f66221e3e7486d2513c67051afc5530af04715e37c144c198240eb5e</span></span> <span class="giallo-l"><span>01513,</span><span class="z-keyword">0x56a669268cf40b4111afe73a823da07e8a09f6304f8ab890b4645d2dfd7cbb24</span></span> <span class="giallo-l"><span>01514,</span><span class="z-keyword">0x898d4f37bcd23ab1762aec11fd937e9b9843e74b3aa9c0b4ed5645b03fcbaf98</span></span> <span class="giallo-l"><span>01515,</span><span class="z-keyword">0x935b5d7aeec407a6cd83f7d0dc160edc53cc8b7f5f2e019c05fe619226a5b67a</span></span> <span class="giallo-l"><span>01516,</span><span class="z-keyword">0x4ad5c3e371e953f644173a234e019d8e14993f21100068a439bc901b164b0713</span></span> <span class="giallo-l"><span>01517,</span><span class="z-keyword">0xbe94d5d09346e617ac54ff3494a7923b43d7ea91d61fdfa4a1185af83e73fee0</span></span> <span class="giallo-l"><span>01518,</span><span class="z-keyword">0x40fa62d3a1d198625a85eb1afaea58c9644194914293db1246869aa4b7fcf547</span></span> <span class="giallo-l"><span>01519,</span><span class="z-keyword">0x110e8af3acb590972a4f633434221317d3ac98b9fba73452c02e9a88e9de32f2</span></span> <span class="giallo-l"><span>01520,</span><span class="z-keyword">0x6e412e20bae396e80928f28ec0179a1be7765947bd7e4765fe3b20524f60f2ca</span></span> <span class="giallo-l"><span>01521,</span><span class="z-keyword">0x8ffe28ad29fdd6e42ccae7faf81b1715fd4df21451ddeb305a3eead7a514a17c</span></span> <span class="giallo-l"><span>01522,</span><span class="z-keyword">0xe93cd0a078a29332cbd05e1570a988ad748db4a2b2f2dbc2c6bbab0bd3c8302b</span></span> <span class="giallo-l"><span>01523,</span><span class="z-keyword">0x77f19add028523159fac380f499a2193f29ffde2ae2eb043719b798e272d2b3b</span></span> <span class="giallo-l"><span>01524,</span><span class="z-keyword">0xf583c72783c0c5b90ab3a01c84eaf9ef04620259b4c1ccf074c9e74a22c98460</span></span> <span class="giallo-l"><span>01525,</span><span class="z-keyword">0x326bed4654c8a2f1bf96d345ef7ac8eb3868861e561603b5dc50c8f623cf6333</span></span> <span class="giallo-l"><span>01526,</span><span class="z-keyword">0x558f5bae98e6ad2e383096f2c381c126bdccfaa0c90cbbffb7480426f5803396</span></span> <span class="giallo-l"><span>01527,</span><span class="z-keyword">0x17af0f4e322b322401ff5f1c360a93aa4c14babc71203e78a3f9df4cf56f8f02</span></span> <span class="giallo-l"><span>01528,</span><span class="z-keyword">0xb3d28e9ba92278e4be3110b7813b95e05243fb026f3442e6961e686576399e5f</span></span> <span class="giallo-l"><span>01529,</span><span class="z-keyword">0x6ce3df5c684e6d291db88d672af9848f1c597d58ad4aeb154d7d812d69878e22</span></span> <span class="giallo-l"><span>01530,</span><span class="z-keyword">0x70b295e43e231b6edfb2ba45b14964ca609d06e596f65438c816a8919a141d38</span></span> <span class="giallo-l"><span>01531,</span><span class="z-keyword">0x5694754d0ac3a99b57cfa34aa9a6f37d7749675127deb9dd45d920a767104724</span></span> <span class="giallo-l"><span>01532,</span><span class="z-keyword">0xb7d62fb8035796a876d44ec6b484ecafb225782c12885d4cbd8768bfcc8648c5</span></span> <span class="giallo-l"><span>01533,</span><span class="z-keyword">0x1c4ea22b6b5b40c697b2048c59cec06701c032ef4fc245402d68ab614ef4749f</span></span> <span class="giallo-l"><span>01534,</span><span class="z-keyword">0x3f50bd7f0574c667cf8d6e4d96e8375e845f1bb58b5458a96fa4f13400978139</span></span> <span class="giallo-l"><span>01535,</span><span class="z-keyword">0x56e96bf3a208e13326e3ae64501a9f8aa2a2306551a22729f4cdc632a316dc37</span></span> <span class="giallo-l"><span>01536,</span><span class="z-keyword">0x4c0b5a25c4a9f692cb2d1d97cc2ed3a9c6be0263543702df9cfa818e67792ad1</span></span> <span class="giallo-l"><span>01537,</span><span class="z-keyword">0xb84376f6b504ac6eee8eb390c9431dce6d21ba91bf66860488b267e140503df9</span></span> <span class="giallo-l"><span>01538,</span><span class="z-keyword">0xa859e797a3880fcd290e20193e80d4cd6aac09cbe285520972863a0496ba9e5e</span></span> <span class="giallo-l"><span>01539,</span><span class="z-keyword">0xb8f7332814753428b30912ab8eca0e635d4060a7ef66fecc91b9963f0d2a9b5b</span></span> <span class="giallo-l"><span>01540,</span><span class="z-keyword">0x5075b4c47e8e56e7f17022c6c00170a30cdd7cf257d893dd917b6ae8725ef044</span></span> <span class="giallo-l"><span>01541,</span><span class="z-keyword">0xd9a68897ad38b7a6b7948e66b75312956c32f2d8e2b27fdf3df27bb1e523587c</span></span> <span class="giallo-l"><span>01542,</span><span class="z-keyword">0x4c44c323f56a00e42c55f8e08134019f4cfa635e945aab057be327146e41b193</span></span> <span class="giallo-l"><span>01543,</span><span class="z-keyword">0xba0d8406b4b7bdb1f2a3c8bf6cc79c49d1a1ecb99e9a289ac2febb3f062a31db</span></span> <span class="giallo-l"><span>01544,</span><span class="z-keyword">0xb730d9fb4712957266c8134e8ad45e064e9dde91be74a4bdba289dd2c1cd3b7f</span></span> <span class="giallo-l"><span>01545,</span><span class="z-keyword">0x2a36dd0adc9b0a8ed517b92ef73ee18072f2ad87d992eac9b163ed13701c2d40</span></span> <span class="giallo-l"><span>01546,</span><span class="z-keyword">0xcb6390d20de04adf9ca127b68f73fbbdde1ae451d3d5dd2e9deebed712c49122</span></span> <span class="giallo-l"><span>01547,</span><span class="z-keyword">0x7be294479d6f126c3da2e73d6ae008ba912d377135e43eefcc6ca65e4e2d9770</span></span> <span class="giallo-l"><span>01548,</span><span class="z-keyword">0xd42b2e596c43feb99b1a292cb65108e4d159699ce5399331ceedd101b37e8aa3</span></span> <span class="giallo-l"><span>01549,</span><span class="z-keyword">0x3259acc6ebca1ee7695b4748c89145bfb0962571f616b5e2da44ac571746369f</span></span> <span class="giallo-l"><span>01550,</span><span class="z-keyword">0x15c4efe66e352107540d4c8ce5d800c117a599da83ad34388cd17510682942bf</span></span> <span class="giallo-l"><span>01551,</span><span class="z-keyword">0x2d99a1dc1815eff9f0d697fb3c79a078645b573ad228ebe569384ec8f747fc98</span></span> <span class="giallo-l"><span>01552,</span><span class="z-keyword">0xccd34c1ecb8f3444c21ad2f645b5909fe2c44e9f282706205f45c102d68bd3b8</span></span> <span class="giallo-l"><span>01553,</span><span class="z-keyword">0x0f3371da1271d47e61ed8a04772fd68751b8c7ef16c316b8f4b1491449354a47</span></span> <span class="giallo-l"><span>01554,</span><span class="z-keyword">0x6acbe79cf6301c23a1202198de9abad6c1cf67718f48928176459a2e195839a3</span></span> <span class="giallo-l"><span>01555,</span><span class="z-keyword">0x975db585f0f663c6e62d41199c823b48e1be2f596effa9c56222d3b7fdd48d40</span></span> <span class="giallo-l"><span>01556,</span><span class="z-keyword">0xf8d968d981abe306802686c870f2d6071547604228bc7c8a9e26600cc13fc18f</span></span> <span class="giallo-l"><span>01557,</span><span class="z-keyword">0x5250d82f1f9476a10e99a6b6c8d4664c52d206286eb62e544c4d93b6c8141608</span></span> <span class="giallo-l"><span>01558,</span><span class="z-keyword">0x8817dc1dc6343f42591204b1036b8e8b9ac90aa6be40647b3c13fc48256b865f</span></span> <span class="giallo-l"><span>01559,</span><span class="z-keyword">0x16cbfdacbf89ab417c81734171a541d1ebf55b17e4d62474a9883f9aa3b9d992</span></span> <span class="giallo-l"><span>01560,</span><span class="z-keyword">0xcbaf55ad5cf0f88bfa5be589394b6a7ae0907116fdee9b447b4110ad76356049</span></span> <span class="giallo-l"><span>01561,</span><span class="z-keyword">0xa12fc593dbc327d7a61fa0e695f2e6bbd10b70ae3dd87d32802487380d67334e</span></span> <span class="giallo-l"><span>01562,</span><span class="z-keyword">0x310c6496b06f98c1553f27b9ef878db3e6b540a4008fb4de7d65cbb7b431f324</span></span> <span class="giallo-l"><span>01563,</span><span class="z-keyword">0x5345e3d4fb9fb5cfc1e3ab07b7963c5185b3758583fce54826b59c8f59fc2bb9</span></span> <span class="giallo-l"><span>01564,</span><span class="z-keyword">0x2280e4c1f8c9444f8a85a63a744b4d9cdaaaeec6c27a100b704c36ba1b27607a</span></span> <span class="giallo-l"><span>01565,</span><span class="z-keyword">0x893942f1ae02af922386a011d94aea458b000e6ae58ac5105469f15ef5ccb00b</span></span> <span class="giallo-l"><span>01566,</span><span class="z-keyword">0x237ef759964133b24b7d50fb860d3ef49f5b5473a5dfbb4deb12a9ee75e9d3c4</span></span> <span class="giallo-l"><span>01567,</span><span class="z-keyword">0x1aec3b6ed606a370df07ff07933d708e4b30892c5b34eb27a3c179089ff70c24</span></span> <span class="giallo-l"><span>01568,</span><span class="z-keyword">0xfc92fcf640f5c001fe4c37de77755ff442f5753d9500aba5636cad6cef432cba</span></span> <span class="giallo-l"><span>01569,</span><span class="z-keyword">0xeacd9d2bc6090407814082b59e363afa47cb9148ffa584c065136e11c62413e9</span></span> <span class="giallo-l"><span>01570,</span><span class="z-keyword">0xa22bf28892d91ec239139c3c7bb07a32887d7d42f9a097ee919e8f1333abe8be</span></span> <span class="giallo-l"><span>01571,</span><span class="z-keyword">0x1a439d0701e901619bf55f220dd81ad945b75883f0832eb9d1ffad360225825f</span></span> <span class="giallo-l"><span>01572,</span><span class="z-keyword">0x947ddced110265caee947bc7d343bafd17bafff910a68db5bcc0f46f0aee6fc7</span></span> <span class="giallo-l"><span>01573,</span><span class="z-keyword">0x3a831bed82ec33cfb63e2489ca28d1dabcab3326a310e117ed3ff4d91893ad5e</span></span> <span class="giallo-l"><span>01574,</span><span class="z-keyword">0x9028d18bb6a6f17c7d25c2c76c6faf7a9df0913107ee429b1cfa9e865cf3118a</span></span> <span class="giallo-l"><span>01575,</span><span class="z-keyword">0x598f030e236f72cf6eff6d43fb7f974f911b9fc603980b37f15614ec3cd779c5</span></span> <span class="giallo-l"><span>01576,</span><span class="z-keyword">0xf904329742dc4ffc14c96a9917c54d18a6fde0cb98c47d211e7f7ffb83956ae4</span></span> <span class="giallo-l"><span>01577,</span><span class="z-keyword">0x8a587dfcf7eaa992e28ff6c3504df916cd4e01fe66fd293129ae957fb4426425</span></span> <span class="giallo-l"><span>01578,</span><span class="z-keyword">0x43c1dcc3d038599b653d4863c7c9bb7cad97e7b7961695e8956e9bd42f2dc0b2</span></span> <span class="giallo-l"><span>01579,</span><span class="z-keyword">0x92a983f23849ce276e11172312cf40a7aee0e9bd34c92f66f95a2b55ea9f3cba</span></span> <span class="giallo-l"><span>01580,</span><span class="z-keyword">0x1c243107c6f0b4ef1b64cb91a8d1abe0dff736faf40a28e01448477799d7223b</span></span> <span class="giallo-l"><span>01581,</span><span class="z-keyword">0x1f943824eeb9f6e597dd06662f22d72c259fe15ca30f79f85108fce6f9465c80</span></span> <span class="giallo-l"><span>01582,</span><span class="z-keyword">0xde1cad895c807ccbc04c98614864decb0b4f438b79772508210e542de31a80d6</span></span> <span class="giallo-l"><span>01583,</span><span class="z-keyword">0x2d72b6e45e90548bead586dbbe36d30832196b923fc15981b7a75b4635835cad</span></span> <span class="giallo-l"><span>01584,</span><span class="z-keyword">0x393498cdb070387b507967acb20ca81ac651fc0112e6f8bf4275a998e87be113</span></span> <span class="giallo-l"><span>01585,</span><span class="z-keyword">0xfa098e6dd3f968cc805e7e32e67beb12ee8d5791c9ad3f4c4f97d8090c5d7532</span></span> <span class="giallo-l"><span>01586,</span><span class="z-keyword">0x379cb7fe8047796010944629cbaa6009c131882ada4df80b344f674a209a02ee</span></span> <span class="giallo-l"><span>01587,</span><span class="z-keyword">0x62641130ea31f0236a9a003332e891538e45fa7190e93f9af17f15fdaa0f73e5</span></span> <span class="giallo-l"><span>01588,</span><span class="z-keyword">0x63224c34401bb9cfd504b6527d4005cbe3d274af04571902b23f4623b177a276</span></span> <span class="giallo-l"><span>01589,</span><span class="z-keyword">0xa972b2e4d5472258ad38813f7ab77a0daac4a0796875b562a65a989c1cb57dfb</span></span> <span class="giallo-l"><span>01590,</span><span class="z-keyword">0x1370376c417b6f988efc6de15723eb81354087bb24b5be9affdd536f7eb5e878</span></span> <span class="giallo-l"><span>01591,</span><span class="z-keyword">0x3c5940a5c4b1ced8cfba620ef392e3bcaea154dd3ec56371ebb50f7d3955488b</span></span> <span class="giallo-l"><span>01592,</span><span class="z-keyword">0xfdcf0f058fd21fd4db98eec51153f4bc489fb41e08c1a8dbf8f1d7f3ffe01a0e</span></span> <span class="giallo-l"><span>01593,</span><span class="z-keyword">0x7779354bd2845311c515a0f22e8f032d09e69f3d10a14a013152ae46000edfd5</span></span> <span class="giallo-l"><span>01594,</span><span class="z-keyword">0xfc12f95bb18ce0bce9db6efa93b555b6108fc6f3241d56a25a2c07d8e18d4e6d</span></span> <span class="giallo-l"><span>01595,</span><span class="z-keyword">0x2118c3d09fa86752bd92dd89053b9afb26337edcf84098361d149f3d9a8eb9d2</span></span> <span class="giallo-l"><span>01596,</span><span class="z-keyword">0xf94bdd17711158be2e5aba2f31d933bca8e1d608a0aaee8d611255e5822072bb</span></span> <span class="giallo-l"><span>01597,</span><span class="z-keyword">0xaeb7c436d1407307f9daa397e49a35bb39d2b7612dcf4a40639643fdd06185cd</span></span> <span class="giallo-l"><span>01598,</span><span class="z-keyword">0xf56b793b792ea72e3e3f8c92ac085de3c0b6e2a04a11486599b92a86c6abd4f2</span></span> <span class="giallo-l"><span>01599,</span><span class="z-keyword">0x6cf982a28fdaf8ff3086f2ab622848b9a1cc92e347202b0c3b5bc8da8669ad9a</span></span> <span class="giallo-l"><span>01600,</span><span class="z-keyword">0xc6a9ee35cb2a1e7ace08025884a30c605db736d1b026cbca495b623cef531c78</span></span> <span class="giallo-l"><span>01601,</span><span class="z-keyword">0x0497bfd92c28ce3e12442ae4bafb6b8bb950448933fbfa5faf307a908385990b</span></span> <span class="giallo-l"><span>01602,</span><span class="z-keyword">0x9a50fff5ebacea0ef3d7d163034333d6c0c133718fae765896cc19513d0e3ed1</span></span> <span class="giallo-l"><span>01603,</span><span class="z-keyword">0xa1d88a2633e02e2c4e08d94c97fd1b76d7003800f78dc3323f9bcc5af6d00bb2</span></span> <span class="giallo-l"><span>01604,</span><span class="z-keyword">0x00e0c17d808088777af62a97fe1e63d0a1ea1433c5368c5e7427bde3e7677589</span></span> <span class="giallo-l"><span>01605,</span><span class="z-keyword">0x8fec155e0c69236d83d2c7039e0e904d800eba28c739bad9bfc5b4c3e616b1a5</span></span> <span class="giallo-l"><span>01606,</span><span class="z-keyword">0x7642a7d34a91eb38072e60a0b44d304de3f84d42928c44891b8768a2255696de</span></span> <span class="giallo-l"><span>01607,</span><span class="z-keyword">0x0a337fdbd42c275522b604f3cf7eebe86a7876ba0e93ad89fc725fa37bffa4b1</span></span> <span class="giallo-l"><span>01608,</span><span class="z-keyword">0x2b8f0227d5c0605529146c4b66cefdef9fded753b2f496b5d2232de3f0f0ff0d</span></span> <span class="giallo-l"><span>01609,</span><span class="z-keyword">0xceafb20105e86dad0aea7a8cd971d4960c6e675d677a4ff5b467c57072e1c324</span></span> <span class="giallo-l"><span>01610,</span><span class="z-keyword">0x99fdde4b6905f88a904c45a0fae519384c35cbf770ac691cc2f972bc91c9e92a</span></span> <span class="giallo-l"><span>01611,</span><span class="z-keyword">0x0d642ed657bd7c7bad338118f728552422e9d918fc5a6d45b276be73ee489fb6</span></span> <span class="giallo-l"><span>01612,</span><span class="z-keyword">0x01a109f9c1765421c41b740a0beeada7ec1527a116e075768051a865688abc4a</span></span> <span class="giallo-l"><span>01613,</span><span class="z-keyword">0x409c216ecee281bfa9d2292d1483c07a83af57ede1d306c3ef1357e6207bbc38</span></span> <span class="giallo-l"><span>01614,</span><span class="z-keyword">0x608abfc5fdaed326966359b7494e26fad1a0897d36404404cdd1e9d760a2cc63</span></span> <span class="giallo-l"><span>01615,</span><span class="z-keyword">0x546296f9bdd48f7a10748c5685047652d24ee0f5d9d5d39d00c138b5b72963a3</span></span> <span class="giallo-l"><span>01616,</span><span class="z-keyword">0x210f4a03fc1ad41169c1a2110e9881cb518e3a91920784a93790ec49b14ca899</span></span> <span class="giallo-l"><span>01617,</span><span class="z-keyword">0xf300016daf617180a864891d6e395a1d693586922d87b42012be8d01f21a08c6</span></span> <span class="giallo-l"><span>01618,</span><span class="z-keyword">0xd126355b8481e0ce290bcd7d8e59ea88d84464af126c0711c4aace2295d81ec6</span></span> <span class="giallo-l"><span>01619,</span><span class="z-keyword">0xfccf39eec398431f05ecebc058d0f7451b0601e47c8a32403f430fee1fa91b4b</span></span> <span class="giallo-l"><span>01620,</span><span class="z-keyword">0x62719ac2f5906f11574a39f6235b3d12052d2df36855880901e99ab7dc7671da</span></span> <span class="giallo-l"><span>01621,</span><span class="z-keyword">0xd410e2d782f4489c884bfca0410d81ec6376b2558e2fdaa4329d57739155b4e2</span></span> <span class="giallo-l"><span>01622,</span><span class="z-keyword">0x3a2643d146858acc75041baf09f47c0f2d25d4f102c12fc7d3db22f670be350f</span></span> <span class="giallo-l"><span>01623,</span><span class="z-keyword">0xb86b68f188d4f0d56f35bd8df010b9154c282c78ea9604ef6e94084e9c851b8d</span></span> <span class="giallo-l"><span>01624,</span><span class="z-keyword">0x79abcea66a1e7adfb03c8c047ccc1823881335a68f7221a13f057b9b812fa6eb</span></span> <span class="giallo-l"><span>01625,</span><span class="z-keyword">0x9d2445ad11ecdc91945bf0507eb97181e1a8d7373c3f68b0760959a45a32fd05</span></span> <span class="giallo-l"><span>01626,</span><span class="z-keyword">0xa0719f0293eda9efab5b6cd4fbe9be45f707761d77e089ab27c965058eed2737</span></span> <span class="giallo-l"><span>01627,</span><span class="z-keyword">0x3825eb62719002200fd1b8ece3f1fdcf80705657d68e418366eeae57b14acfbd</span></span> <span class="giallo-l"><span>01628,</span><span class="z-keyword">0x49d1a71da4a7a27348aefd008cc5227b28544ee604eb242e1c2b037f67c3abdb</span></span> <span class="giallo-l"><span>01629,</span><span class="z-keyword">0x1ec93093a36a54010ad1302caf7c5c24188c3d668ccfe895972a57ff6587850d</span></span> <span class="giallo-l"><span>01630,</span><span class="z-keyword">0xd52d9f3e99b17ef53cb1045db3488f149feb348547eaaa57f54bf7aaf6d18957</span></span> <span class="giallo-l"><span>01631,</span><span class="z-keyword">0x438a5c23f506d979268a2884664886c208526d050df78870f68c331625ee95d0</span></span> <span class="giallo-l"><span>01632,</span><span class="z-keyword">0xb811a1ab572962105e233bc72569ef1ef980ffaec0c58c62c0e08744fdb23a7d</span></span> <span class="giallo-l"><span>01633,</span><span class="z-keyword">0x2dba253d07386a24dac2fc5c78c557e25f4e521c2c5c37ebf514b9bbabd9f4f2</span></span> <span class="giallo-l"><span>01634,</span><span class="z-keyword">0xc0975217f67c73ea0f22c7475233b64524f228a7da61e6c531cfd932cee27109</span></span> <span class="giallo-l"><span>01635,</span><span class="z-keyword">0x926f0429fd3f751c428e5501e7ffbb006ad7048930e1820455b6fe404b7d8a17</span></span> <span class="giallo-l"><span>01636,</span><span class="z-keyword">0x88bc22af6003d122e5ac2b7981aefe48cc5e787777a77364dc12530b35d33397</span></span> <span class="giallo-l"><span>01637,</span><span class="z-keyword">0xd10229ae7c392518d3bcaa15f43ed0c2cca4f235cbe009e1aa711b109cded52c</span></span> <span class="giallo-l"><span>01638,</span><span class="z-keyword">0xf60a479f9ebd1a81e807ddaa404c8cc9b855eb08efa4481810529674214b8c84</span></span> <span class="giallo-l"><span>01639,</span><span class="z-keyword">0x45574d293ed9b0ade09f8b041efd0f9be629979743111520a7c0224e41c36213</span></span> <span class="giallo-l"><span>01640,</span><span class="z-keyword">0xf4d925c6aaeb0d96944b66a46324fd09815af73338fe9c58c332f77869473fff</span></span> <span class="giallo-l"><span>01641,</span><span class="z-keyword">0x055616453b16d6ff8caa12ea67e2543aa0fe47cb5c610699d5aded16ccdb72d2</span></span> <span class="giallo-l"><span>01642,</span><span class="z-keyword">0xbffe5d04ec76b2d00ec35af8ed488116f1d3d454b1476db9c68bc62590b91b62</span></span> <span class="giallo-l"><span>01643,</span><span class="z-keyword">0xdb04ce690ea5b0472a5f3d630336a0977e19517bb6c8443876e76d49f5876c98</span></span> <span class="giallo-l"><span>01644,</span><span class="z-keyword">0x836dd3c2e51dd27fdfc1aca4839218e9a40390bb8966c257d470c5e13d610d09</span></span> <span class="giallo-l"><span>01645,</span><span class="z-keyword">0xccdd4d3758c1b860176290f80a588cf9f8f257ee6a094019968b645969039e52</span></span> <span class="giallo-l"><span>01646,</span><span class="z-keyword">0xdf78d1aa527997f2f34dcc3df048e8273d4c2147867b13f009fff3fabe1227e6</span></span> <span class="giallo-l"><span>01647,</span><span class="z-keyword">0xbc1a2596d167f86f145df1c74a4ce5cdeb09e21c4f9077a7b7a75a026a9cd7e0</span></span> <span class="giallo-l"><span>01648,</span><span class="z-keyword">0xba4445506249f1cd7510b1159ba679867a8a721810502db35b871131a52f6e9b</span></span> <span class="giallo-l"><span>01649,</span><span class="z-keyword">0xc772985ee13356a7519f619cba370e0d30b2b17faac8e8779b34e77f319c2f21</span></span> <span class="giallo-l"><span>01650,</span><span class="z-keyword">0x0cd44f84d292e1d1a88b51fb885b084cb2e3e4e9ab284c6174e1277fdc808c12</span></span> <span class="giallo-l"><span>01651,</span><span class="z-keyword">0x108b81392c28178c4f4fb98ed3e03860ebad588e089fbf85a87ba9988e27c055</span></span> <span class="giallo-l"><span>01652,</span><span class="z-keyword">0x92dc53a4408de761c673c56bf0c52c88cd2cd65777b47f65ba27265dcf5a4b2e</span></span> <span class="giallo-l"><span>01653,</span><span class="z-keyword">0xac1c8ccb958d598d2591f82adcbce06cd05c5bc8c7714195f2808a42602cbd55</span></span> <span class="giallo-l"><span>01654,</span><span class="z-keyword">0x2f466ff62e6b2eb3193683dca7c0af52da1825c22cae69cfda8b187d2d719bfd</span></span> <span class="giallo-l"><span>01655,</span><span class="z-keyword">0x4dc5edd2150d175af8dd28927a1529a52080d0e0d2075d0c6f703ec2a527ef03</span></span> <span class="giallo-l"><span>01656,</span><span class="z-keyword">0x72d321b5204000c80fd39ccf2fe72a17cac0eea2195133632b987461a4939c1d</span></span> <span class="giallo-l"><span>01657,</span><span class="z-keyword">0xd0684723c2fcb39b6536736b92d24f7ca1bbb6b64c51c69ed69eae1ab22c83c7</span></span> <span class="giallo-l"><span>01658,</span><span class="z-keyword">0x651f1c70b5bd5638c095aeaee6313f1d4d2e28471ce7ce98aed045cec480d016</span></span> <span class="giallo-l"><span>01659,</span><span class="z-keyword">0x0013c08b64bf7e3afab80ad4f8ea9423f1a7d8b31a149fc3b832d7980719c60c</span></span> <span class="giallo-l"><span>01660,</span><span class="z-keyword">0x7825d5b222a31cadf8cc345ae34eff92e4d617659c3f630037821d5acf6a5cfa</span></span> <span class="giallo-l"><span>01661,</span><span class="z-keyword">0x84e21383079e4674dd0c63cb29cd89f0726ed8895aa83aa99febd249dc9620a4</span></span> <span class="giallo-l"><span>01662,</span><span class="z-keyword">0xa5681587c34c7e8d143b6332a98804a6940655b08c9764ee13f8362b929f15eb</span></span> <span class="giallo-l"><span>01663,</span><span class="z-keyword">0xc84283fad5c6405f6c9d51c0597b9908406ff09772233255fe61a1494e09cb2c</span></span> <span class="giallo-l"><span>01664,</span><span class="z-keyword">0xab3af7a0e7c174b428f865f4fbe6d49aab50b91a0cb5555687f2769c6c874836</span></span> <span class="giallo-l"><span>01665,</span><span class="z-keyword">0xd0adeec06347b843d108e4d349b50156dcaa131bc27c7752a1cc3c3035b230d2</span></span> <span class="giallo-l"><span>01666,</span><span class="z-keyword">0x827de27e4fa09f2ddd98223a7393881100fd9c533b55416b3839ad8f3b6835ec</span></span> <span class="giallo-l"><span>01667,</span><span class="z-keyword">0x558e21250bc559d5e9cbf0b5c9787f4607cd769a3d96d4c174b769907b8032f2</span></span> <span class="giallo-l"><span>01668,</span><span class="z-keyword">0x8d75bc100e6afde488e081895914ea1c5658115a0e028b439e2cb2d52c02a29c</span></span> <span class="giallo-l"><span>01669,</span><span class="z-keyword">0x84ccda7e5a2f253fee50e47559bdd8db96026897cec18ac128409ec405979de1</span></span> <span class="giallo-l"><span>01670,</span><span class="z-keyword">0x3490d679757169a0132ca44b3c408b53e9dbb23dfde34a6c8ad34ddd0f88ce78</span></span> <span class="giallo-l"><span>01671,</span><span class="z-keyword">0x4533f7b3dc71406ffa10a0af1fbb9b2d5cf61f7ae1d7a58c57734680984ef875</span></span> <span class="giallo-l"><span>01672,</span><span class="z-keyword">0xabf106295d76c72cbcc2b778712a1b954319d1b4a1365e19cbbf9ed0c39d7445</span></span> <span class="giallo-l"><span>01673,</span><span class="z-keyword">0xd67018bd3f840799601c348f8d2a55eb0d46ece00688a3ae5d7a699de71817a0</span></span> <span class="giallo-l"><span>01674,</span><span class="z-keyword">0x16b9e8771fd65164ad5b4344b67bbc519da70ca263c562c0088a9c30dde29cb9</span></span> <span class="giallo-l"><span>01675,</span><span class="z-keyword">0x35b0af7b1dfac60196dec285536cee1ff48d20579fe0df117be9566c78fd9404</span></span> <span class="giallo-l"><span>01676,</span><span class="z-keyword">0x2753d9cd14ed65494895baf136feef1f4c0096ac569e856a0b858c43046dbaf5</span></span> <span class="giallo-l"><span>01677,</span><span class="z-keyword">0xe40b2ea438c3da468e62d736f576e9c6bf89e7b2079569b11b7b63ab6b859e53</span></span> <span class="giallo-l"><span>01678,</span><span class="z-keyword">0xfcbdf0e3790abaa1ed31b64333b348ecdc15a15a213488f46d753ea77659d1b9</span></span> <span class="giallo-l"><span>01679,</span><span class="z-keyword">0xe5f342e28cd6a85862e29a8bc6ededb8ce9e5252f02db387ca6b27f234a1c8c4</span></span> <span class="giallo-l"><span>01680,</span><span class="z-keyword">0xaf511202a03e86af88d1a53657068bad1682ed4d3c3d446e4e553313c4183f91</span></span> <span class="giallo-l"><span>01681,</span><span class="z-keyword">0xd0e6d3d3842257da332754ff2e0ee2f28b630041e206da98093d60fd29cb2494</span></span> <span class="giallo-l"><span>01682,</span><span class="z-keyword">0x66ddcfa8295f3681fe0dc6fa254f4a86cd25127f247cde63ea7b310f8934f163</span></span> <span class="giallo-l"><span>01683,</span><span class="z-keyword">0x8887a5b6add7aad0916907bf209931a98364a7c2a74162ccbea586d2c95fc4fb</span></span> <span class="giallo-l"><span>01684,</span><span class="z-keyword">0xbb0ab38ced9c5de37409997ef703c79d0d0273d0599436d79c86fb19710f0580</span></span> <span class="giallo-l"><span>01685,</span><span class="z-keyword">0x64bf045d836bd1a99dd127859286752a1c09c20fb5b8a70d2c238c86d6565640</span></span> <span class="giallo-l"><span>01686,</span><span class="z-keyword">0x7a8fba5b00f60ce646da4ffa64981c334b927fbbbfa037890aab81f2ae5c65fc</span></span> <span class="giallo-l"><span>01687,</span><span class="z-keyword">0x26481dad4204488c03b357ab61f70c3e214800bd461be5b14a758caacbac5a94</span></span> <span class="giallo-l"><span>01688,</span><span class="z-keyword">0x05f0a17478f22868e8c1442a512807f1ba0f0ba7d2452c2ada4b0626b23b6019</span></span> <span class="giallo-l"><span>01689,</span><span class="z-keyword">0xac53e2ecad8e9ff6a20cd863627056469d0fe53c1e5ec3b590dffc853f36576e</span></span> <span class="giallo-l"><span>01690,</span><span class="z-keyword">0x9dbcd976d813101a23ea057a561d714c26264f42fec6b5f3dd2f06708423867a</span></span> <span class="giallo-l"><span>01691,</span><span class="z-keyword">0xbb315f50f96b903776ae3f1e1cac5b683d34104953c62bae500aa4b2a29d8a4e</span></span> <span class="giallo-l"><span>01692,</span><span class="z-keyword">0xb877548bc73b777200804316b2cf7081152f0fa8923908b8ce8715126fbb3963</span></span> <span class="giallo-l"><span>01693,</span><span class="z-keyword">0x3d2c2aad64a353e2400dd1141f9bd7bab23dfa8aec7c2e5c42a1c52c58fd7cd5</span></span> <span class="giallo-l"><span>01694,</span><span class="z-keyword">0xd42cdf89f6ddbc2f8a8bcd4f6786cf73b985399c41328fd76c08821dcb2cb39a</span></span> <span class="giallo-l"><span>01695,</span><span class="z-keyword">0x8d97b21795f44f7c853891c4f8007e2b9eeb7999c16ff0d81e744742f758dc7c</span></span> <span class="giallo-l"><span>01696,</span><span class="z-keyword">0x49e0b594a63361d8cb35b386558238731b5b206702a2b68050290948b97a2b90</span></span> <span class="giallo-l"><span>01697,</span><span class="z-keyword">0x01b23d087a4adf659d9a5f4c65eaf4a3164b46a7398dc516a52efd4f2f8ca77c</span></span> <span class="giallo-l"><span>01698,</span><span class="z-keyword">0x9c316b67ce5ae45a6ba25c46c1720b77741ce1bd7631e5da01fb509ca50ace2f</span></span> <span class="giallo-l"><span>01699,</span><span class="z-keyword">0xcea5c210e2ef00d919631ccb5e68b178fb9b480062d13cc8604ce3845d950362</span></span> <span class="giallo-l"><span>01700,</span><span class="z-keyword">0x3d9833e9df7243daa3904d9a41d3808841ba7ea07998eb140d63ad0b82f49d5f</span></span> <span class="giallo-l"><span>01701,</span><span class="z-keyword">0x073ad3dcaef6a4e5c3deec4d10a9795592dca55108e7fd3cf274ada351c290ae</span></span> <span class="giallo-l"><span>01702,</span><span class="z-keyword">0x9c454cbcd610aa388489e7db1f4849677840ce1f0a3679e88d9e102e2b646aa7</span></span> <span class="giallo-l"><span>01703,</span><span class="z-keyword">0x0d424bdb826419a44bbe1435dbf09f15e33b105a97d0c11741401fb5e151f306</span></span> <span class="giallo-l"><span>01704,</span><span class="z-keyword">0xc842662446daaba43a5dbc82bb9bc5735a21aba5fa7c6a0642a2a645d2fb06a9</span></span> <span class="giallo-l"><span>01705,</span><span class="z-keyword">0x850425a72ebd6cac965b15c5411581bb261a58e2e9f304fbbcc1f6ec56a3689a</span></span> <span class="giallo-l"><span>01706,</span><span class="z-keyword">0x5f7468d23fbeed676fe8188c346cc24453860c8e265373880ee3ca128e9f98b9</span></span> <span class="giallo-l"><span>01707,</span><span class="z-keyword">0x68199dcdf8d631885b4e264ef8160a64551e500f2f49aaac4e2966d6b42143fb</span></span> <span class="giallo-l"><span>01708,</span><span class="z-keyword">0x1bc39088aff2c8759c5f61190c8af3aeb48cc644a57ec061b6547c97395754a4</span></span> <span class="giallo-l"><span>01709,</span><span class="z-keyword">0xac6bdf4cbd7c785c68ed288da6c280a6d1b7340e882e1a71688e56b31d237970</span></span> <span class="giallo-l"><span>01710,</span><span class="z-keyword">0x616a421395c539814d92259f0dbdccc436b6be78d1ad264305abc632fae12c63</span></span> <span class="giallo-l"><span>01711,</span><span class="z-keyword">0x675a2efc56ef5c385bc82bd826482cd8247801e0556f38182d2d396d7af13474</span></span> <span class="giallo-l"><span>01712,</span><span class="z-keyword">0xb3466ce1c9c6c1f1c5c8681c13442c053bd73443ebd60b0443cccf95717fb756</span></span> <span class="giallo-l"><span>01713,</span><span class="z-keyword">0xefe87a15350ae4b7ea6136f27efba4c610f7d260cad4188771530e46a85d96ca</span></span> <span class="giallo-l"><span>01714,</span><span class="z-keyword">0x8a93b06d9b9e80fc6e21443ec976bbd3de80fa2ca50768e728598d44c6fce197</span></span> <span class="giallo-l"><span>01715,</span><span class="z-keyword">0xc53f6fe8560e2c1f79a629b335139dff42a166dba3a3f3cdd8b9f3c45c482cef</span></span> <span class="giallo-l"><span>01716,</span><span class="z-keyword">0xbeebbc85402356009b2eecfc3e808aa7d6b671ce58430bada153e2678890476a</span></span> <span class="giallo-l"><span>01717,</span><span class="z-keyword">0x2daba19a743ea4ca797c5c20fffea6f79979ebd83d0606fa86a38c02709d0425</span></span> <span class="giallo-l"><span>01718,</span><span class="z-keyword">0x69ddf701e288b58796af67a303745d123486204a9a7e0ac18b2afb25c4c9b61d</span></span> <span class="giallo-l"><span>01719,</span><span class="z-keyword">0xac2ebcf440ba3a2ef280e8004918a9b6d849e19b321823a57132d7799c21a147</span></span> <span class="giallo-l"><span>01720,</span><span class="z-keyword">0xc428eb527615d3acc4dbd68d2052fe6db27152c73bb2b22edfe4d9f13fd67ecf</span></span> <span class="giallo-l"><span>01721,</span><span class="z-keyword">0x940116cedc675ccdecfc2ace0d21817c7e13d57154dfbabd0ac759cb68fc7aed</span></span> <span class="giallo-l"><span>01722,</span><span class="z-keyword">0x1aff873b75f990bea4c06fd212d2862a06d28047e47592b8809eeb164826bdf8</span></span> <span class="giallo-l"><span>01723,</span><span class="z-keyword">0xf19dc7c143cd5aac499bab456496409958bc496ed1b807c209069e5fb78089a6</span></span> <span class="giallo-l"><span>01724,</span><span class="z-keyword">0x50ba9e2446defbca234aba740d15221152d261f9987e24f6e9ff3833d2422c88</span></span> <span class="giallo-l"><span>01725,</span><span class="z-keyword">0x6244c9ba553c0a9fdd9985673ec8dc94558b1208ea0b2c09cae8baec14ef04ef</span></span> <span class="giallo-l"><span>01726,</span><span class="z-keyword">0xd9ca0531bdadeb4a42bbbe600161d3bc0c29f6de35c37b584d463c87cc8929be</span></span> <span class="giallo-l"><span>01727,</span><span class="z-keyword">0x019f04b76df87f056d3e85bf6100ad35611dce5c332f9c885cf4ddf9e4b0df05</span></span> <span class="giallo-l"><span>01728,</span><span class="z-keyword">0x0bd9139ddae4c9e202aa11614fbe037609445363727e6057db969600bc442615</span></span> <span class="giallo-l"><span>01729,</span><span class="z-keyword">0xa85a5ebec5a89cea73285765cd253a54806b53af28dd7577198839114fc037a3</span></span> <span class="giallo-l"><span>01730,</span><span class="z-keyword">0xe07d8fc1ad730fc509989b081ff643430c4d25396853553dde4bc01e0a5c774c</span></span> <span class="giallo-l"><span>01731,</span><span class="z-keyword">0xcdeae685f4d356e7c5cd458638103aa02069a6ca2d8c459bbc49b9e3ac9f302f</span></span> <span class="giallo-l"><span>01732,</span><span class="z-keyword">0xd4b05748bb2981bff1958a4dba0b0f59559bfd5f8fd4e32b1d6c94d0902e1087</span></span> <span class="giallo-l"><span>01733,</span><span class="z-keyword">0x2b75c3c9e417a3ee775e3f6d8b333588c4c8eb482ad9c611c73b8de9fff3403c</span></span> <span class="giallo-l"><span>01734,</span><span class="z-keyword">0x0b51aa4b64600138e09022ba4fcd58449faf43f4b1f8a5e82d9450fec703516c</span></span> <span class="giallo-l"><span>01735,</span><span class="z-keyword">0x5b7da9fdc48dac8163f0a2620536639c95e1f3c35f5d09442cd077900ba3397e</span></span> <span class="giallo-l"><span>01736,</span><span class="z-keyword">0x2d581b4305c5b54aa72fbb2dea7f95fcd7ecd06dbafa7d1f52197cbb86cd7275</span></span> <span class="giallo-l"><span>01737,</span><span class="z-keyword">0x053468cbce94fcb5f0170028e0a585bb98000c005cbb0f9d8cdc0274cc3fdcf4</span></span> <span class="giallo-l"><span>01738,</span><span class="z-keyword">0xc4ea73550a711a24cdb631632d8b9826098f572e1dd0f5d338a7d571e40a0670</span></span> <span class="giallo-l"><span>01739,</span><span class="z-keyword">0x390296d239ff8e7ba83108c01143904890332e29c7fb89f287be70d9e446a4af</span></span> <span class="giallo-l"><span>01740,</span><span class="z-keyword">0x0bc99a43bd74f339e60b6cb7235925e6bd78a56014979d6dd161ad9e2f65c9db</span></span> <span class="giallo-l"><span>01741,</span><span class="z-keyword">0x831ca1406a51f08d9e8b7f9b4ae4e9b1562ec6b3a965e648f5fba403985d7c5f</span></span> <span class="giallo-l"><span>01742,</span><span class="z-keyword">0x6ea854bc3a2a1cad0e25a07bc1a13146837088263c4b906a86f3aff87748a250</span></span> <span class="giallo-l"><span>01743,</span><span class="z-keyword">0xcbe74e160ce637284edac7282156fd9a04638631e32dde566ef91abe19e9d7db</span></span> <span class="giallo-l"><span>01744,</span><span class="z-keyword">0xafde3d1a0a5c90a5b6a8ace6e0c51f287a7baa6cd52fbb530d5cd30d77d1a9e1</span></span> <span class="giallo-l"><span>01745,</span><span class="z-keyword">0x265425af9916bed0dd62a2456e7c7da2c9c0f07a25c8974425dc0f116865942f</span></span> <span class="giallo-l"><span>01746,</span><span class="z-keyword">0xffa83edd16de7ec3db737cea195c255b9711b59c21b1497e26747bed2e13f943</span></span> <span class="giallo-l"><span>01747,</span><span class="z-keyword">0x2d7f0f5ad114008c8bcb0c95c1368739149923d73651da238d74d6e4f2e3acb7</span></span> <span class="giallo-l"><span>01748,</span><span class="z-keyword">0x7b69dcfeced3aa613f02ad7933e543e8dd53bfaeee20d90f4f1bd38429dfacf0</span></span> <span class="giallo-l"><span>01749,</span><span class="z-keyword">0xc08c96110c4d40c906c9f31d2d959c22201f86eade534578a58c391900fa278f</span></span> <span class="giallo-l"><span>01750,</span><span class="z-keyword">0x6067e2dac2ea8b7d928570e0b358cb2bde6a09b5169325a6d553e6215ab5b5c6</span></span> <span class="giallo-l"><span>01751,</span><span class="z-keyword">0x50262a09aa1822e9da30e2dfd935d89e012d1d336a88f24d8db38e4ec1608284</span></span> <span class="giallo-l"><span>01752,</span><span class="z-keyword">0x0488926e04563f273a6ad741c30908764e8dac6e38d7032eb8d398a39b6e0f42</span></span> <span class="giallo-l"><span>01753,</span><span class="z-keyword">0x7477c0a14e3afe6b1210829b4fd571ddba704e062565ee06f8fc00631cc348ba</span></span> <span class="giallo-l"><span>01754,</span><span class="z-keyword">0x646def35e15739fb4e6b897511c4a71c34b323e0107a079a03ffe1be11480962</span></span> <span class="giallo-l"><span>01755,</span><span class="z-keyword">0x84f4fc01aa6c9e739865d63f71d6860875ba166ea67b4aa068de28cb1adffc8f</span></span> <span class="giallo-l"><span>01756,</span><span class="z-keyword">0x308e058035fe5998006d16d2b6f6fb289d120e402b96d10100c98e92efc86619</span></span> <span class="giallo-l"><span>01757,</span><span class="z-keyword">0x8b98854f27b4a6d80d520f8fe71c52fafbe55252d3df554a907a9c0c90f1de89</span></span> <span class="giallo-l"><span>01758,</span><span class="z-keyword">0x7c7bd9920cdb8efaed244a333152b7f205bfee6f2eff4e0da455d882b070ab6c</span></span> <span class="giallo-l"><span>01759,</span><span class="z-keyword">0xef9dd1ae52176b521f99f60ae0a16baa1832aec7ce2b95c0e6b20cbd0943b218</span></span> <span class="giallo-l"><span>01760,</span><span class="z-keyword">0xc908c0cba78857bee8eaac7c241106164154782cf8c712987f4b6eb687161ed5</span></span> <span class="giallo-l"><span>01761,</span><span class="z-keyword">0x4c223079fd963774b68c0c75835a4f73a591a7f6647c09fa5def8021344fd209</span></span> <span class="giallo-l"><span>01762,</span><span class="z-keyword">0x58e9482fe6e25ceccb977c5945db92bc2ff9fd044336dbfd13714e6f84d9c99a</span></span> <span class="giallo-l"><span>01763,</span><span class="z-keyword">0xe9b64e4399b811a832bea55ce15fb1a55718352899e8fed5cba324e196b4004e</span></span> <span class="giallo-l"><span>01764,</span><span class="z-keyword">0x69d58dfd877a727ac73429279bd99ba2562eb358598d6c7f2941cdac9f3307bb</span></span> <span class="giallo-l"><span>01765,</span><span class="z-keyword">0x565089600e60764e78b07382ce1e0acc93b255ac0d9e20b4ad585767be9e8ab4</span></span> <span class="giallo-l"><span>01766,</span><span class="z-keyword">0xe47ad77ca6b9d30cefda397443229cb1df5561c9a436fa9d94d3752dbab1b8cd</span></span> <span class="giallo-l"><span>01767,</span><span class="z-keyword">0xc92526a4d2bacdc047f4e86f6a2b159f6c72df8157178c4ca89cda1780245b1b</span></span> <span class="giallo-l"><span>01768,</span><span class="z-keyword">0x0f318bcdb0e0d78f54276c87b5be9aa21919381bf2e82205072e8c10cb8cbc21</span></span> <span class="giallo-l"><span>01769,</span><span class="z-keyword">0xcc56b7c7ff7ead6cf9f72199ed9ae0a94d5afcd7fc25ad93275a37cdde487e62</span></span> <span class="giallo-l"><span>01770,</span><span class="z-keyword">0x8a0d9bcdcf18b4038a4df3f96e0782f2bb1d4d84ef4932b73dd0f2655f1c9187</span></span> <span class="giallo-l"><span>01771,</span><span class="z-keyword">0x8c0c7922138320604c1287c6c0f87fdb37566752373a62c150c06653189cf070</span></span> <span class="giallo-l"><span>01772,</span><span class="z-keyword">0x490072e141e5099852008eb31e3b432bbc2d71cd988dd62a6872bd723f4464a9</span></span> <span class="giallo-l"><span>01773,</span><span class="z-keyword">0x441a3c8c2fe28eede2b4ed609cf3fca8740cac9638c5962e2214c00365a3a787</span></span> <span class="giallo-l"><span>01774,</span><span class="z-keyword">0x9d3c41ed132dc44de0d39c9d3dd4cc11c1e8a7f8f0316eb774991a9999c0f372</span></span> <span class="giallo-l"><span>01775,</span><span class="z-keyword">0x6023b5ad4e7a8f918fefab880f48288bd8e0da6b9e2e3880f17ab96e3ebcd618</span></span> <span class="giallo-l"><span>01776,</span><span class="z-keyword">0x848902b06524297d54f30c1ddb0c7629c03fb1ba49464244cfe8b198ff99dc26</span></span> <span class="giallo-l"><span>01777,</span><span class="z-keyword">0x56f9c62bb1fb7eb1575c94cf34a37b136b82db0979412504812d7bd21990d5a2</span></span> <span class="giallo-l"><span>01778,</span><span class="z-keyword">0x01a7fc06f4248e48ece709e46292bb7e0a69317fefbd38215c4c093a0d42e425</span></span> <span class="giallo-l"><span>01779,</span><span class="z-keyword">0x9ff0b05413db15b73284db1b8d1702ff095cce5810d44c6457693516ac3e4d65</span></span> <span class="giallo-l"><span>01780,</span><span class="z-keyword">0x0601be62d83f52db2fd5baa50940e9efb464596f0ed80d11722d2944f56bc38b</span></span> <span class="giallo-l"><span>01781,</span><span class="z-keyword">0xc73b916a7b1049230c965741275142bf554805f395feeddf9a8a84934fefce35</span></span> <span class="giallo-l"><span>01782,</span><span class="z-keyword">0x4ff9deb85b08cc30d36d12e391e9ee9bb72a7db2cb52679b62cbae6059a67a46</span></span> <span class="giallo-l"><span>01783,</span><span class="z-keyword">0x6dcf0704c8afbf5b87adf316a01ebff4f641cefff7ba33d672ed51f477a2cf8a</span></span> <span class="giallo-l"><span>01784,</span><span class="z-keyword">0x37725e0bd787534538108e890787fd1606569bd4db127d22da37f2a4f2373fde</span></span> <span class="giallo-l"><span>01785,</span><span class="z-keyword">0xbb264cc368c6866747b9a711e14933f8d96f905bdb0b25a07cfcfd2b094a5fa4</span></span> <span class="giallo-l"><span>01786,</span><span class="z-keyword">0x8f3dccda34ec0838afc97c36da3b66c7a3c804709ed64b4725809ede5248dbbf</span></span> <span class="giallo-l"><span>01787,</span><span class="z-keyword">0x8cae5bdc47bc087d43c41f973c4711ea0af9e5ae53fc5a2fa3ff104070524401</span></span> <span class="giallo-l"><span>01788,</span><span class="z-keyword">0x7e1c1704cf56b2e8cdf4ec7af790cdffcc0cfb3fa840a43ffd46d4fa0d0458a1</span></span> <span class="giallo-l"><span>01789,</span><span class="z-keyword">0xdb34d4b8ff52ebaaca16e0ee46cc56669773768e2c2473470d055004825f6024</span></span> <span class="giallo-l"><span>01790,</span><span class="z-keyword">0x0e2fc599445336cd593fe78469762a0eaef058edc4f9a10a7083b42578eb6b18</span></span> <span class="giallo-l"><span>01791,</span><span class="z-keyword">0x0dabc8f4f2cc029e70b238f3ba3f2478038729cbdab741e25e934f3828891e60</span></span> <span class="giallo-l"><span>01792,</span><span class="z-keyword">0x648d0dd207d0201595e12a8a30b247f7d51ee8385935ba68393db91c846459b6</span></span> <span class="giallo-l"><span>01793,</span><span class="z-keyword">0x77485ef35b5343f0b16fab3492a9565a3fabb6b97d3076f2877c489b0a808ad5</span></span> <span class="giallo-l"><span>01794,</span><span class="z-keyword">0xe291673e64217556218b47874f5d9d4c6bf392894f6cabd9f572cf4750bd4d47</span></span> <span class="giallo-l"><span>01795,</span><span class="z-keyword">0xd1d496b1a49c1b8f9e5a7e1146dca4e3c28ac4be22ec0d8764f56ff3ccda0e69</span></span> <span class="giallo-l"><span>01796,</span><span class="z-keyword">0x33a5546bb26b46559e6b72502faf6dfa1060fb41a69bf9fff988c463f6132aa0</span></span> <span class="giallo-l"><span>01797,</span><span class="z-keyword">0x34123297e57b8a075114c3698558387086e3a4b2acfdd54041901f952e7afb91</span></span> <span class="giallo-l"><span>01798,</span><span class="z-keyword">0x3ca0aeadff3449302ce20766cc4dc0b1628f85cbd26665a40b0f509493428f08</span></span> <span class="giallo-l"><span>01799,</span><span class="z-keyword">0xe949b50c73fe40ff59ab7e8b460a5c81a411b02931151d95eba96ba7e422b731</span></span> <span class="giallo-l"><span>01800,</span><span class="z-keyword">0x07cb6fc533ed260b5b01e470e4d874270270fc5332f423e620be1dd92b06ff6a</span></span> <span class="giallo-l"><span>01801,</span><span class="z-keyword">0x8edf5827b93f9dd727c25e4cdf558bdef0c8d1962c993666fb469082ae607e6e</span></span> <span class="giallo-l"><span>01802,</span><span class="z-keyword">0xf95306bb3bc429f9229f80e3fd50446435e98eb615bffdb379d202abcad65f98</span></span> <span class="giallo-l"><span>01803,</span><span class="z-keyword">0x4e1d05e25890a1b0b1f301452321893b91ec09ca755dea16b16fd8eb0d02a39d</span></span> <span class="giallo-l"><span>01804,</span><span class="z-keyword">0xa24b5a4a59adcc97ac586cf83a7314357ae74c48d9099ca9463954f8ca24db24</span></span> <span class="giallo-l"><span>01805,</span><span class="z-keyword">0x81d9a9522808c36c1845abcc5a080b237f69ec54c4f263c31c3fb2738bddbf38</span></span> <span class="giallo-l"><span>01806,</span><span class="z-keyword">0x66534ad9878fc2792c46d45c62a93320cdbd40c276025bcfb786dda3b53e775c</span></span> <span class="giallo-l"><span>01807,</span><span class="z-keyword">0x37ac18016b4a26060dde93000fe2b5614ae011c506725b391bdafaf9d613f8fa</span></span> <span class="giallo-l"><span>01808,</span><span class="z-keyword">0x3f1a883d82a05988793b449444221a6baa67a0975a8bdc20bd5c8044fb059bd7</span></span> <span class="giallo-l"><span>01809,</span><span class="z-keyword">0x45d0f53f5567f627b64e808129a7730badce39d542584ac3b4e392e549eebe9b</span></span> <span class="giallo-l"><span>01810,</span><span class="z-keyword">0x6ccaab76edecb5af607c5f4a741d30e9b9762ac77bfcac89b087ac9fdb51727f</span></span> <span class="giallo-l"><span>01811,</span><span class="z-keyword">0x9ab98ad907f0df327b31733e17eca703d44c5315e0f3f381dee38a6716e9bbb6</span></span> <span class="giallo-l"><span>01812,</span><span class="z-keyword">0x80d86e96ae3c138cb93d8b83e1aca9930c3aef9845f19e164076a319c12b3d29</span></span> <span class="giallo-l"><span>01813,</span><span class="z-keyword">0x1b4ae400e53cfcfe9027f84324909f496fdba244a748a8786a8b6f30126bedb6</span></span> <span class="giallo-l"><span>01814,</span><span class="z-keyword">0xe0064cce975cf20b2bf11f501c61e1cfc5df450c0231fea9b29df7d134b1b5cd</span></span> <span class="giallo-l"><span>01815,</span><span class="z-keyword">0xa2d0424093b6f41d5bc9c2d6bc63596e722f91e214f3453d692e27404d58cb31</span></span> <span class="giallo-l"><span>01816,</span><span class="z-keyword">0x9a493dd73536b40fe784e7710b23ead682163b5c2873d06fb634b41821df1d12</span></span> <span class="giallo-l"><span>01817,</span><span class="z-keyword">0xf534c5f3151aba70c4902307fd1d8cb8a9227ea3bfe00099879f9af4458f7cca</span></span> <span class="giallo-l"><span>01818,</span><span class="z-keyword">0xc34b86c65e0db470eb8f644fc648b5520546535adecff743126a2bb394fb474a</span></span> <span class="giallo-l"><span>01819,</span><span class="z-keyword">0x918b86fa5fabcbe1535ff25b9cc6bf18399033a10feab07b1b2a44e652c890c7</span></span> <span class="giallo-l"><span>01820,</span><span class="z-keyword">0x17e7111cf764fe48d55ae33eb9992d4fa0c443e17aba5ed8121665d09e719642</span></span> <span class="giallo-l"><span>01821,</span><span class="z-keyword">0xe118ce724863baafe5822a6df3eb6322f52b0efac93df5ce30f2890249a5301b</span></span> <span class="giallo-l"><span>01822,</span><span class="z-keyword">0xd7b7b15d51895e067d217712e532f4c1ca318bec69483371d584eca1fcd35dd9</span></span> <span class="giallo-l"><span>01823,</span><span class="z-keyword">0x3fe7a945dc87c69c3c018c68cc45a5ad9d5c76a9623a615305eb03b30bde5286</span></span> <span class="giallo-l"><span>01824,</span><span class="z-keyword">0x6ad87d358fe720d6207c7189c458f01246ef8fdbcebe5bf977590c5053395226</span></span> <span class="giallo-l"><span>01825,</span><span class="z-keyword">0x7f98124406ff6a0ac572d6cbedd187c905ab77a2957904ba9df742ddd37616d9</span></span> <span class="giallo-l"><span>01826,</span><span class="z-keyword">0xc17dc5a387763a48690eeff9f15e2c8a17d46585c0330f855207bf83db5ba7ca</span></span> <span class="giallo-l"><span>01827,</span><span class="z-keyword">0xfa5fbccba9509f70ed5a39bbc8148708230e37f26fb18b7a74aea1616e3e4609</span></span> <span class="giallo-l"><span>01828,</span><span class="z-keyword">0x540009e54254fad311b1b69490c7587db7dbf71ce7a15e62f94d49eaf22525e6</span></span> <span class="giallo-l"><span>01829,</span><span class="z-keyword">0x41ed6fe79b33dc5a32a019496131ea6805aef33a6aaf93982d37dd7653decb41</span></span> <span class="giallo-l"><span>01830,</span><span class="z-keyword">0x2afebfecd0c3c447d920747a1346c865aa846b0ae6f7eb900e25606c8d9ed725</span></span> <span class="giallo-l"><span>01831,</span><span class="z-keyword">0x7289db8d2960f6402252c8699465253d4e3efdc31c832a9ba82b535bbe39dfa1</span></span> <span class="giallo-l"><span>01832,</span><span class="z-keyword">0xb1198d248f79e07609cf29ef8984e2786258b474c17a982d2e4e9219af3d6592</span></span> <span class="giallo-l"><span>01833,</span><span class="z-keyword">0x0bef12618bd2905629f0c9d7427431884e203e70d78f5c9308a3215d79a28556</span></span> <span class="giallo-l"><span>01834,</span><span class="z-keyword">0xfdca337f0afcb8f508449dcfebafb6de99c44f1a468a0c162785b36b20c01446</span></span> <span class="giallo-l"><span>01835,</span><span class="z-keyword">0xa45d06eca259ea9bf79a23c0a8a50cd784fa072330050f7da63a0e4acd14b4f6</span></span> <span class="giallo-l"><span>01836,</span><span class="z-keyword">0x87fe297ba8e996cf2b1fdb854e86b043f485149eea31c3c74187402b58892cce</span></span> <span class="giallo-l"><span>01837,</span><span class="z-keyword">0xe26e40bdb2425b55bd59c814f5839f7ff9f74aa1aa86d23e95988048d319e64c</span></span> <span class="giallo-l"><span>01838,</span><span class="z-keyword">0xec6b0c035002b5d12e30ff8e3f97f281f562593eff842cf8905468c3d9c9777e</span></span> <span class="giallo-l"><span>01839,</span><span class="z-keyword">0x07950048304ce616f23f40789e4f7995ce30e164dc5e35d97ab241998924b825</span></span> <span class="giallo-l"><span>01840,</span><span class="z-keyword">0xe287972bf569570a6f2f8d3dd01ceebff3c9c849706e2ebe133ce72dbbbadcec</span></span> <span class="giallo-l"><span>01841,</span><span class="z-keyword">0x2a6039e5b858d952e07cbc9057a4506b30edd01944b253c0bb68fdc9e4616b6b</span></span> <span class="giallo-l"><span>01842,</span><span class="z-keyword">0x5567d80f36494b4f26232e2a26f06fc382bdddf8b9eb7a20d56087f13e1cd561</span></span> <span class="giallo-l"><span>01843,</span><span class="z-keyword">0x3153e10ad6830573f85e149d79579aaa27e4161239b5bef085dfe1c86d2d04cf</span></span> <span class="giallo-l"><span>01844,</span><span class="z-keyword">0x03b0963dd2f6917a141dcb843dcdc7b8fe71ffc51a29cf86b7f909ba9ff178b2</span></span> <span class="giallo-l"><span>01845,</span><span class="z-keyword">0x03b93b158737ecadc1a498bbe78e247ec652f5707571512674bb231e4c35593f</span></span> <span class="giallo-l"><span>01846,</span><span class="z-keyword">0x3e05673eeaabb4293f6eba4fc8597b21e935e72e7d614665480e881bba552938</span></span> <span class="giallo-l"><span>01847,</span><span class="z-keyword">0x2de5f285569a2744c7dc3b94d992c655037d370f4f8d8ca04a26b4f30ccbf5ed</span></span> <span class="giallo-l"><span>01848,</span><span class="z-keyword">0x113a0599656907adc266ada978194806c922455ded32bdb8578ddedcc0e31d8b</span></span> <span class="giallo-l"><span>01849,</span><span class="z-keyword">0x71675e40a1ede46ed372c411541b1a66c4d76d33fbfd97db91b9a3a96a45e669</span></span> <span class="giallo-l"><span>01850,</span><span class="z-keyword">0xeb0e8dced91d0329228af294e8273236ae0a4e6f8590ed770ce6b8ecb9d4e9b2</span></span> <span class="giallo-l"><span>01851,</span><span class="z-keyword">0x27b488ec8baa7adbc492e5c2311f57d1bb025e42fb362933096f7dbf66112277</span></span> <span class="giallo-l"><span>01852,</span><span class="z-keyword">0xa405f5f3d7c35326f18a1a85fcd88a897d5e3a31867791cee9489042b950375b</span></span> <span class="giallo-l"><span>01853,</span><span class="z-keyword">0xde7294f59c86cf434f1b51c11d36eec758c73de3e0cfdfb0d88f7ef4e6aaf946</span></span> <span class="giallo-l"><span>01854,</span><span class="z-keyword">0x1b3a9f72ed4d4521657db928917a7abdd71f4ba2cf1fa4915b68d1c840fe3eb8</span></span> <span class="giallo-l"><span>01855,</span><span class="z-keyword">0xbb9869151522b5034619c9983d1c21d253a8a46dfc03bdb7c4e8771faa4cd31d</span></span> <span class="giallo-l"><span>01856,</span><span class="z-keyword">0x10e8b0ee7a9e05e342cbdf4cc408d4d207163bf652e9d45a715f63a14079b558</span></span> <span class="giallo-l"><span>01857,</span><span class="z-keyword">0xe0a70c38b92eb6cda8f9b7e2253b88bb8a25833d34f1174e9d5a3dc11d709fb0</span></span> <span class="giallo-l"><span>01858,</span><span class="z-keyword">0x96299d525632a3677163bc6f18e98439e410f1c3f0a0e561bcbb63ed8022b860</span></span> <span class="giallo-l"><span>01859,</span><span class="z-keyword">0x056f7f9b622e013fd1a31107cddb7843babb80ad494781ecc0408a4551a6a04c</span></span> <span class="giallo-l"><span>01860,</span><span class="z-keyword">0xbe17dd25f8ad8b238b69e317126128e379aa87af72ab99cac240b4d6362ef148</span></span> <span class="giallo-l"><span>01861,</span><span class="z-keyword">0x31641a0876c1fef62d170f84f2c6113d88d4d38ce90538e30bed4565fc6a3027</span></span> <span class="giallo-l"><span>01862,</span><span class="z-keyword">0xdeb651e11a7f6e50e2c2adc32ec89af247c4c71763ab3d213bfca70b0e26c311</span></span> <span class="giallo-l"><span>01863,</span><span class="z-keyword">0x500103a06c6cf65606e2c734912c6448844b87904ee9d68c7be782ac5f6188ca</span></span> <span class="giallo-l"><span>01864,</span><span class="z-keyword">0x168be6df9d2a7ba553609c9235d1cef41b783323f60f7c59ca210f3e9db4d764</span></span> <span class="giallo-l"><span>01865,</span><span class="z-keyword">0xd69771c57985c9c43d6195e8be9d199c3b3ca206a682a0c6c2a274b8294b644a</span></span> <span class="giallo-l"><span>01866,</span><span class="z-keyword">0x3cf6a306ef85f605b6b8610c42f3200bc04bf7cfd1b325b8574ed2c28d4ffb62</span></span> <span class="giallo-l"><span>01867,</span><span class="z-keyword">0x69891a16fc79a0e6fd885f23b106806ecf71ad7b3e5d51a579193c4f2583dc5e</span></span> <span class="giallo-l"><span>01868,</span><span class="z-keyword">0xfb7b596a80d0782f73d11fae09d7da314be8143b471193a28901a36d6b58d8f1</span></span> <span class="giallo-l"><span>01869,</span><span class="z-keyword">0xd864488dca9ec72930dbba8d9f554af78dacec003a6f58fbe05cbeeaa8eaca21</span></span> <span class="giallo-l"><span>01870,</span><span class="z-keyword">0x3dc73a6d1c0433c0d98800a9877d3e0e9651e6eace71413ae0f52a7bf58616c8</span></span> <span class="giallo-l"><span>01871,</span><span class="z-keyword">0xca53dc21977789285d08334ce43b0469a5bd54cf890a4ed1e0cf4543b1575457</span></span> <span class="giallo-l"><span>01872,</span><span class="z-keyword">0xd571c79ae2f0b29d334f8c33b14b21a83491d21da2650ccd9d7e3f1b307ca7a4</span></span> <span class="giallo-l"><span>01873,</span><span class="z-keyword">0xc71b3cef8fd89a79abb07c140f1cf9b90f4afaffa3d269ba2dcc9e2831cd0c3b</span></span> <span class="giallo-l"><span>01874,</span><span class="z-keyword">0xb43aeeecf3e3603fc7f82cc03948d50a9cab2c30d26a371afa8d7b0526c20853</span></span> <span class="giallo-l"><span>01875,</span><span class="z-keyword">0x24fb77820016a3b7ff7cd3ec7407364b0b660fb2a6bb0e26e4b8da1deb6275c2</span></span> <span class="giallo-l"><span>01876,</span><span class="z-keyword">0x41ac34f85491e5d80275e95298185b3df6bc6e522b1b6e18a81b4a954573d27d</span></span> <span class="giallo-l"><span>01877,</span><span class="z-keyword">0x54983d685feaa65ccbaed699e5c85a9cc5fb2275ee5ecc15295fa056f35dff42</span></span> <span class="giallo-l"><span>01878,</span><span class="z-keyword">0x56db2145e5e6ffb8f46ab7fd0bf8192af4b7ee8701fc92e3066697fc7fdab1c1</span></span> <span class="giallo-l"><span>01879,</span><span class="z-keyword">0x793c08df7c9a354e39b31fa213f2944ea8361ed33203f0e1e438351e185d241a</span></span> <span class="giallo-l"><span>01880,</span><span class="z-keyword">0x0412a89eb5bf0325ce228aa64f66dcab0855c002db872dd94f3ee97496d41a1f</span></span> <span class="giallo-l"><span>01881,</span><span class="z-keyword">0x8d9912853e99f373036df7a07e47eff4dba631f7456c6fee1bb79a292f530c13</span></span> <span class="giallo-l"><span>01882,</span><span class="z-keyword">0x44df0aab52827e4608b4fab902457682fa019ad5cbbdf7502bb1ba74607078b7</span></span> <span class="giallo-l"><span>01883,</span><span class="z-keyword">0xbd172681ef1b3e781763591809db8067a65590760a1a823716d2afffcd893492</span></span> <span class="giallo-l"><span>01884,</span><span class="z-keyword">0x5732d988076cc1fedf316e07aa3a8567fd55a04ca989876d4bdc63681cbcce48</span></span> <span class="giallo-l"><span>01885,</span><span class="z-keyword">0x5480f07444c8ba60faf8b853c77b72b2e0aee4894a176f920d0965eb92df90f9</span></span> <span class="giallo-l"><span>01886,</span><span class="z-keyword">0xb5e8b2b00ba1708ec31ca0a7e64540c1b02d837991d4e12cdb19d6c75ed0da6b</span></span> <span class="giallo-l"><span>01887,</span><span class="z-keyword">0xdededef33d83e607868d87e8f058511a152de71d8a04b12499d5f1666b89071d</span></span> <span class="giallo-l"><span>01888,</span><span class="z-keyword">0xcdbce5e36cfff749d0ee9ccb6dc344a822ed097e4b8eb812ada19521890d5663</span></span> <span class="giallo-l"><span>01889,</span><span class="z-keyword">0x4a09fe43bd97064993f18d214062005a1ffc76d03495b2b7c65c6137d3dd055e</span></span> <span class="giallo-l"><span>01890,</span><span class="z-keyword">0xff7a1b1127af6429b799637ff6cffb9169aa5000f01b67a54e2c7f9a155e7027</span></span> <span class="giallo-l"><span>01891,</span><span class="z-keyword">0x0f7bffdd015be88c78d30778d5bd66b75e86f9867e221f857352d0cb95c927a1</span></span> <span class="giallo-l"><span>01892,</span><span class="z-keyword">0x9671b1edc7dc58206e18de1e4d107bf2e8508483017749146ff5c82c674408e6</span></span> <span class="giallo-l"><span>01893,</span><span class="z-keyword">0x1b07973b9e818e0e014e52c587149c9775fd44bd5ccd095dee3221ba7c7a9efe</span></span> <span class="giallo-l"><span>01894,</span><span class="z-keyword">0x804008940c025a4e8a00ea42a659b484ba32c14dff133e9d3b7bf3685c1e54de</span></span> <span class="giallo-l"><span>01895,</span><span class="z-keyword">0x3f81607c8cb3f0448a11cab8df0e504b605581f4891a9a35bd9c0dd37a71834f</span></span> <span class="giallo-l"><span>01896,</span><span class="z-keyword">0xe6ebe562c89bc8ecb94dc9b2889a27a816ec05d3d6bd1625acad72227071e721</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>The accumulator root should be verified by community members before being accepted. Although the accumulator root can be verified at anytime by anyone in the future, it is likely clients and other tooling will begin relying on proofs against the aforementioned root in the near term.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Jamehttps://github.com/ZWJKFLC https://wg-eips.ritovision.com/7637/

Modify the output value of EXTCODEHASH for EOA accounts to `0x`

<h2 id="abstract">Abstract</h2> <p>This proposal is an optimization for <a href="https://wg-eips.ritovision.com/1052/">EIP-1052</a>, For addresses with a balance, but without code, the codehash should still be <code>0x</code>.</p> <p>When an address <code>add.code == 0x</code> and <code>add.balance != 0</code>, <code>add.codehash==0</code> is required instead of <code>add.codehash==keccak256("")</code></p> <h2 id="motivation">Motivation</h2> <p>EIP-1052 was proposed to save gas fees. However, due to some flaws in the set specifications, in actual applications, due to safety concerns, they will not actually be used. In order for EIP-1052 to be truly useful, it should be optimized.</p> <p>If someone uses it based on the proposal of EIP-1052 and does not notice the change when <code>add.balance != 0</code>, there may be security issues.</p> <h2 id="specification">Specification</h2> <p>The behaviour of <code>EXTCODEHASH</code> is changed in the following way:</p> <ol> <li>When calling <code>EXTCODEHASH</code>, the codehash of the address with balance but no code is still <code>0x</code></li> </ol> <h2 id="rationale">Rationale</h2> <p>EIP-1052 In order to include the function of <code>BALANCE</code>, let the <code>EXTCODEHASH</code> of the address without balance be <code>0x</code>, and the <code>EXTCODEHASH</code> of the address with balance be <code>keccak256("")</code>.</p> <p>The contract address can be calculated in advance. Whether it is <code>CREATE</code> or <code>CREATE2</code>, it is possible that the contract is not created but has a balance. For security, You can actually only use <code>keccak256(add.code) == keccak256("")</code> or <code>add.code.length ==0</code> instead of <code>add.codehash == 0</code>,, which makes the original intention of EIP-1052 meaningless.</p> <p>For example, uniswap V2 uses stored addresses to determine whether a contract exists. If this <code>EXTCODEHASH</code> is optimized, can save a huge amount of gas.</p> <p>If someone uses a <code>add.codehash==0</code> to determine whether a contract has been created, due to intuition and the lack of details in many documents, they will not think that the codehash of an address with a balance will change from <code>0x</code> to <code>keccak256("")</code>. If someone maliciously attacks at this time, it will cause some bad effects.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Using codehash to determine whether a non-contract address has a balance will not be available</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>Code reference for execution-specs</p> <p>After modification</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> extcodehash</span><span>(</span><span class="z-variable z-parameter z-function">evm</span><span>:</span><span> Evm</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> address</span><span class="z-keyword"> =</span><span> to_address</span><span>(</span><span>pop</span><span>(</span><span>evm</span><span>.</span><span>stack</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> charge_gas</span><span>(</span><span>evm</span><span>,</span><span class="z-constant"> GAS_CODE_HASH</span><span>)</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>evm</span><span>.</span><span>env</span><span>.</span><span>state</span><span>,</span><span> address</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> account</span><span class="z-keyword"> ==</span><span class="z-constant"> EMPTY_ACCOUNT</span><span>:</span></span> <span class="giallo-l"><span> codehash</span><span class="z-keyword"> =</span><span> U256</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> codehash</span><span class="z-keyword"> =</span><span> U256</span><span>.</span><span>from_be_bytes</span><span>(</span><span>keccak256</span><span>(</span><span>account</span><span>.</span><span>code</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> codehash</span><span class="z-keyword"> ==</span><span> U256</span><span>(</span><span class="z-variable">hexstr</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> codehash</span><span class="z-keyword"> =</span><span> U256</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> push</span><span>(</span><span>evm</span><span>.</span><span>stack</span><span>,</span><span> codehash</span><span>)</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>pc</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span></code></pre> <p>Source code</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> extcodehash</span><span>(</span><span class="z-variable z-parameter z-function">evm</span><span>:</span><span> Evm</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> address</span><span class="z-keyword"> =</span><span> to_address</span><span>(</span><span>pop</span><span>(</span><span>evm</span><span>.</span><span>stack</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> charge_gas</span><span>(</span><span>evm</span><span>,</span><span class="z-constant"> GAS_CODE_HASH</span><span>)</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> get_account</span><span>(</span><span>evm</span><span>.</span><span>env</span><span>.</span><span>state</span><span>,</span><span> address</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> account</span><span class="z-keyword"> ==</span><span class="z-constant"> EMPTY_ACCOUNT</span><span>:</span></span> <span class="giallo-l"><span> codehash</span><span class="z-keyword"> =</span><span> U256</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> codehash</span><span class="z-keyword"> =</span><span> U256</span><span>.</span><span>from_be_bytes</span><span>(</span><span>keccak256</span><span>(</span><span>account</span><span>.</span><span>code</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> push</span><span>(</span><span>evm</span><span>.</span><span>stack</span><span>,</span><span> codehash</span><span>)</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>pc</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>Using codehash to determine whether a non-contract address has a balance will not be available</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-13T00:00:00+00:00 2026-02-11T14:49:28+00:00 Toni Wahrstätterhttps://github.com/nerolation Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7623/

Increase calldata cost to reduce maximum block size

<h2 id="abstract">Abstract</h2> <p>The current calldata pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller at around 100 KB. This EIP proposes adjusting the calldata cost to reduce the maximum possible block size and its variance without negatively impacting regular users. This is achieved by increasing calldata costs for transactions that predominantly post data.</p> <h2 id="motivation">Motivation</h2> <p>The block gas limit has not been increased since <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Moreover, calldata costs have remained unchanged since <a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a>. <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> introduces blobs as a preferred method for data availability (DA). This transition demands a reevaluation of calldata pricing, especially in order to address the disparity between average and maximum block sizes. By introducing a floor cost dependent on the ratio of gas spent on EVM operations to calldata, this proposal aims to reduce the maximum block size to make room for additional blobs or potential block gas limit increases.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>STANDARD_TOKEN_COST</code></td><td><code>4</code></td></tr> <tr><td><code>TOTAL_COST_FLOOR_PER_TOKEN</code></td><td><code>10</code></td></tr> </tbody></table> <p>Let <code>tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4</code>.</p> <p>Let <code>isContractCreation</code> be a boolean indicating the respective event.</p> <p>Let <code>execution_gas_used</code> be the gas used for EVM execution with the gas refund subtracted.</p> <p>Let <code>INITCODE_WORD_COST</code> be 2 as defined in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>.</p> <p>The current formula for determining the total gas used per transaction (<code>tx.gasUsed</code>) is equivalent to:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> isContractCreation</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">32000</span><span class="z-keyword"> +</span><span class="z-constant"> INITCODE_WORD_COST</span><span class="z-keyword"> *</span><span> words</span><span>(</span><span>calldata</span><span>)</span><span>)</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>The formula for determining the gas used per transaction changes to:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>tx</span><span>.</span><span>gasUsed</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span class="z-constant"> 21000</span></span> <span class="giallo-l"><span class="z-keyword"> +</span></span> <span class="giallo-l"><span class="z-support"> max</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> STANDARD_TOKEN_COST</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> execution_gas_used</span></span> <span class="giallo-l"><span class="z-keyword"> +</span><span> isContractCreation</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">32000</span><span class="z-keyword"> +</span><span class="z-constant"> INITCODE_WORD_COST</span><span class="z-keyword"> *</span><span> words</span><span>(</span><span>calldata</span><span>)</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> TOTAL_COST_FLOOR_PER_TOKEN</span><span class="z-keyword"> *</span><span> tokens_in_calldata</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Any transaction with a gas limit below <code>21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata</code> or below its intrinsic gas cost (take the maximum of these two calculations) is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where <code>gasUsed</code> will be below this floor price, but the floor price needs to be reserved in the transaction gas limit.</p> <h2 id="rationale">Rationale</h2> <p>The current maximum EL payload size is approximately 1.79 MB (<code>30_000_000/16</code>). It is possible to create payloads filled with zero bytes that expand to 7.15 MB. However, since blocks are typically compressed with Snappy at the P2P layer, zero-byte-heavy EL payloads generally compress to under 1.79 MB. The implementation of <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> increased the maximum possible compressed block size to approximately 2.54 MB.</p> <p>This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations relative to gas spent on calldata. This change will significantly reduce the maximum block size by limiting the size of data-heavy transactions that can fit into a single block. By increasing calldata costs from 4/16 to 10/40 gas per byte, for data-heavy transactions this EIP aims to reduce the possible EL payload size to approximately 0.72 MB (<code>30_000_000/40</code>) without affecting the majority of users. Other adversarial block constructions can have a non-compressible EL payload size of approximately 1.26MiB.</p> <p>Notably, regular users (e.g. sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.), who do not use calldata predominantly for DA, may remain unaffected. The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, so those transactions are unaffected.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically:</p> <ol> <li> <p><strong>Wallets</strong>: Wallets using <code>eth_estimateGas</code> MUST be updated to ensure that they correctly account for the <code>TOTAL_COST_FLOOR_PER_TOKEN</code> parameter. Failure to do so could result in underestimating gas, leading to failed transactions.</p> </li> <li> <p><strong>Node Software</strong>: RPC methods such as <code>eth_estimateGas</code> MUST incorporate the updated formula for gas calculation. Node developers MUST ensure compatibility with the updated calldata pricing logic.</p> </li> </ol> <p>Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p> <h2 id="security-considerations">Security Considerations</h2> <p>As the maximum possible block size is reduced, no security concerns have been raised.</p> <p>In some cases, it might seem advantageous to combine two transactions into one to reduce costs. For example, bundling a transaction that relies heavily on calldata but minimally on EVM resources with another that does the opposite. However, this is not a significant concern for several reasons:</p> <ol> <li>This type of bundling is already possible today. Merging multiple transactions can save the 21,000 gas cost for each additional transaction beyond the first, a feature explicitly supported in <a href="https://wg-eips.ritovision.com/4337/">ERC-4337</a>.</li> <li>Such bundling does not compromise the block size reduction objectives of this EIP.</li> <li>In practice, transaction bundling is often impractical due to challenges such as trust and coordination requirements.</li> </ol> <p>These factors ensure that transaction bundling does not pose a significant issue.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Andrei Maiborodahttps://github.com/gumb0 Piotr Dobaczewskihttps://github.com/pdobacz https://wg-eips.ritovision.com/7620/

Introduce `EOFCREATE` and `RETURNCODE` instructions

<h2 id="abstract">Abstract</h2> <p>EVM Object Format (EOF) removes the possibility to create contracts using <code>CREATE</code> or <code>CREATE2</code> instructions. We introduce a new/replacement method in form of pair of instructions : <code>EOFCREATE</code> and <code>RETURNCODE</code> to provide a way to create contracts using EOF containers.</p> <h2 id="motivation">Motivation</h2> <p>This EIP uses terminology from the <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> which introduces the EOF format.</p> <p>EOF aims to remove code observability, which is a prerequisite to legacy EVM contract creation logic using legacy-style create transactions, <code>CREATE</code> or <code>CREATE2</code>, because both the initcode and code are available to the EVM and can be manipulated. On the same premise, EOF removes opcodes like <code>CODECOPY</code> and <code>EXTCODECOPY</code>, introducing EOF subcontainers as a replacement to cater for factory contracts creating other contracts.</p> <p>The new instructions introduced in this EIP operate on EOF containers enabling factory contract use case that legacy EVM has.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Wherever not explicitly listed, the rules of EOF contract creation, as well as the <code>EOFCREATE</code> instruction, should be identical or analogous to those of <code>CREATE2</code> instruction. This includes but is not limited to:</p> <ul> <li>behavior on <code>accessed_addresses</code> and address collision (<a href="https://wg-eips.ritovision.com/684/">EIP-684</a> and <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>)</li> <li>EVM execution frame created for the <code>EOFCREATE</code> initcode - memory, account context etc.</li> <li>nonce bumping of the account of newly created contract <a href="https://wg-eips.ritovision.com/161/">EIP-161</a></li> <li>balance checking and transfer for the creation endowment (<code>value</code> argument)</li> </ul> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>TX_CREATE_COST</code></td><td>Defined as <code>32000</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork_types.py#L42">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>STACK_DEPTH_LIMIT</code></td><td>Defined as <code>1024</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/vm/interpreter.py#L60">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>GAS_CODE_DEPOSIT</code></td><td>Defined as <code>200</code> in the <a rel="external" href="https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/vm/gas.py#L44">Ethereum Execution Layer Specs</a></td></tr> <tr><td><code>MAX_CODE_SIZE</code></td><td>Defined as <code>24576</code> in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a></td></tr> </tbody></table> <p>We introduce two new instructions on the same block number <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is activated on:</p> <ol> <li><code>EOFCREATE</code> (<code>0xec</code>)</li> <li><code>RETURNCODE</code> (<code>0xee</code>)</li> </ol> <p>If the code is legacy bytecode, any of these instructions result in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <h3 id="execution-semantics">Execution Semantics</h3> <ul> <li>The instructions <code>CREATE</code>, <code>CREATE2</code> are made obsolete and rejected by validation in EOF contracts. They are only available in legacy contracts.</li> <li>If instructions <code>CREATE</code> and <code>CREATE2</code> have EOF code as initcode (starting with <code>EF00</code> magic) <ul> <li>deployment fails (returns 0 on the stack)</li> <li>caller's nonce is not updated and gas for initcode execution is not consumed</li> </ul> </li> </ul> <p>In the context of legacy bytecode execution any of these instructions (<code>EOFCREATE</code>, <code>RETURNCODE</code>) result in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <h4 id="overview-of-the-new-contract-creation-flow">Overview of the new contract creation flow</h4> <p>In EOF EVM, new bytecode is introduced to the state by means of <code>InitcodeTransaction</code> delivering an EOF container (<code>initcontainer</code>). Such a container may include arbitrarily deeply nesting subcontainers. The <code>initcontainer</code> and its subcontainers are recursively validated according to all the validation rules applicable for the EOF version in question. Next, the 0th code section of the <code>initcontainer</code> is executed and may eventually call a <code>RETURNCODE</code> instruction, which will refer to a subcontainer to be finally deployed to an address.</p> <p><code>InitcodeTransactions</code> are defined in detail in <a href="https://wg-eips.ritovision.com/7873/">EIP-7873</a>.</p> <p><code>EOFCREATE</code> instruction is in turn a replacement of the <code>CREATE</code> and <code>CREATE2</code> legacy instructions allowing factory contracts to create other contracts. The main difference to the <code>InitcodeTransaction</code> is that the <code>initcontainer</code> is selected to be one of the subcontainers of the EOF container calling <code>EOFCREATE</code> (and not one of <code>transaction.initcodes</code>). It is worth noting that no validation is performed at this point, as it has already been done when the factory contract containing <code>EOFCREATE</code> was deployed.</p> <p>Details on each instruction follow in the next sections.</p> <h4 id="eofcreate"><code>EOFCREATE</code></h4> <ul> <li>deduct <code>TX_CREATE_COST</code> gas</li> <li>halt with exceptional failure if the current frame is in <code>static-mode</code>.</li> <li>read immediate operand <code>initcontainer_index</code>, encoded as 8-bit unsigned value</li> <li>pop <code>salt</code>, <code>input_offset</code>, <code>input_size</code>, <code>value</code> from the operand stack</li> <li>perform (and charge for) memory expansion using <code>[input_offset, input_size]</code></li> <li>load initcode EOF subcontainer at <code>initcontainer_index</code> in the container from which <code>EOFCREATE</code> is executed <ul> <li>let <code>initcontainer</code> be that EOF container</li> </ul> </li> <li>check that current call depth is below <code>STACK_DEPTH_LIMIT</code> and that caller balance is enough to transfer <code>value</code> <ul> <li>in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed.</li> </ul> </li> <li>caller's memory slice <code>[input_offset:input_size]</code> is used as calldata</li> <li>execute the container and deduct gas for execution. The 63/64th rule from <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> applies.</li> <li>increment <code>sender</code> account's nonce</li> <li>calculate <code>new_address</code> as <code>keccak256(0xff || sender32 || salt)[12:]</code>, where <code>sender32</code> is the sender address left-padded to 32 bytes with zeros</li> <li>an unsuccessful execution of initcode results in pushing <code>0</code> onto the stack <ul> <li>can populate returndata if execution <code>REVERT</code>ed</li> </ul> </li> <li>a successful execution ends with initcode executing <code>RETURNCODE{deploy_container_index}(aux_data_offset, aux_data_size)</code> instruction (see below). After that: <ul> <li>load deploy EOF subcontainer at <code>deploy_container_index</code> in the container from which <code>RETURNCODE</code> is executed</li> <li>concatenate data section with <code>(aux_data_offset, aux_data_offset + aux_data_size)</code> memory segment and update data size in the header if needed.</li> <li>if updated deploy container size exceeds <code>MAX_CODE_SIZE</code> instruction exceptionally aborts</li> <li>set <code>state[new_address].code</code> to the updated deploy container</li> <li>push <code>new_address</code> onto the stack</li> </ul> </li> <li>deduct <code>GAS_CODE_DEPOSIT * deployed_code_size</code> gas</li> </ul> <h4 id="returncode"><code>RETURNCODE</code></h4> <ul> <li>read immediate operand <code>deploy_container_index</code>, encoded as 8-bit unsigned value</li> <li>pop two values from the operand stack: <code>aux_data_offset</code>, <code>aux_data_size</code> referring to memory section that will be appended to deployed container's data</li> <li>cost 0 gas + possible memory expansion for aux data</li> <li>ends initcode frame execution and returns control to EOFCREATE caller frame where <code>deploy_container_index</code> and <code>aux_data</code> are used to construct deployed contract (see above)</li> <li>instruction exceptionally aborts if after the appending, data section size would overflow the maximum data section size or underflow (i.e. be less than data section size declared in the header)</li> </ul> <h3 id="code-validation">Code Validation</h3> <p>We extend code section validation rules (as defined in <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>).</p> <ol> <li><code>EOFCREATE</code> <code>initcontainer_index</code> must be less than <code>num_container_sections</code></li> <li><code>EOFCREATE</code> the subcontainer pointed to by <code>initcontainer_index</code> must have its <code>len(data_section)</code> equal <code>data_size</code>, i.e. data section content is exactly as the size declared in the header (see <a href="https://wg-eips.ritovision.com/7620/#data-section-lifecycle">Data section lifecycle</a>)</li> <li><code>EOFCREATE</code> the subcontainer pointed to by <code>initcontainer_index</code> must not contain either a <code>RETURN</code> or <code>STOP</code> instruction</li> <li><code>RETURNCODE</code> <code>deploy_container_index</code> must be less than <code>num_container_sections</code></li> <li><code>RETURNCODE</code> the subcontainer pointed to <code>deploy_container_index</code> must not contain a <code>RETURNCODE</code> instruction</li> <li>It is an error for a container to contain both <code>RETURNCODE</code> and either of <code>RETURN</code> or <code>STOP</code></li> <li>It is an error for a subcontainer to never be referenced in its parent container</li> <li>It is an error for a given subcontainer to be referenced by both <code>RETURNCODE</code> and <code>EOFCREATE</code></li> <li><code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPV</code> immediate argument value (jump destination relative offset) validation: code section is invalid in case offset points to the byte directly following either <code>EOFCREATE</code> or <code>RETURNCODE</code> instruction.</li> </ol> <h3 id="data-section-lifecycle">Data Section Lifecycle</h3> <p><strong>For an EOF container which has not yet been deployed</strong>, the <code>data_section</code> is only a portion of the final <code>data_section</code> after deployment. Let's define it as <code>pre_deploy_data_section</code> and as <code>pre_deploy_data_size</code> the <code>data_size</code> declared in that container's header. <code>pre_deploy_data_size &gt;= len(pre_deploy_data_section)</code>, which anticipates more data to be appended to the <code>pre_deploy_data_section</code> during the process of deploying.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>pre_deploy_data_section</span></span> <span class="giallo-l"><span>| |</span></span> <span class="giallo-l"><span>\___________pre_deploy_data_size______/</span></span></code></pre> <p><strong>For a deployed EOF container</strong>, the final <code>data_section</code> becomes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>pre_deploy_data_section | static_aux_data | dynamic_aux_data</span></span> <span class="giallo-l"><span>| | | |</span></span> <span class="giallo-l"><span>| \___________aux_data___________/</span></span> <span class="giallo-l"><span>| | |</span></span> <span class="giallo-l"><span>\___________pre_deploy_data_size______/ |</span></span> <span class="giallo-l"><span>| |</span></span> <span class="giallo-l"><span>\________________________data_size_______________________/</span></span></code></pre> <p>where:</p> <ul> <li><code>aux_data</code> is the data which is appended to <code>pre_deploy_data_section</code> on <code>RETURNCODE</code> instruction.</li> <li><code>static_aux_data</code> is a subrange of <code>aux_data</code>, which size is known before <code>RETURNCODE</code> and equals <code>pre_deploy_data_size - len(pre_deploy_data_section)</code>.</li> <li><code>dynamic_aux_data</code> is the remainder of <code>aux_data</code>.</li> </ul> <p><code>data_size</code> in the deployed container header is updated to be equal <code>len(data_section)</code>.</p> <p>Summarizing, there are <code>pre_deploy_data_size</code> bytes in the final data section which are guaranteed to exist before the EOF container is deployed and <code>len(dynamic_aux_data)</code> bytes which are known to exist only after. This impacts the validation and behavior of data-section-accessing instructions: <code>DATALOAD</code>, <code>DATALOADN</code>, and <code>DATACOPY</code>, see <a href="https://wg-eips.ritovision.com/7480/">EIP-7480</a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="data-section-appending">Data section appending</h3> <p>The data section is appended to during contract creation and also its size needs to be updated in the header. Alternative designs were considered, where:</p> <ul> <li>additional section kinds for the data were introduced</li> <li>additional fields describing a subcontainer were introduced</li> <li>data section would be written over as opposed to being appended to, requiring it to be filled with 0 bytes prior to deployment</li> </ul> <p>All of these alternatives either complicated the otherwise simple data structures or took away useful features (like the dynamically sized portion of the data section).</p> <h3 id="keccak256-initcontainer-in-the-new-address-hashing-scheme"><code>keccak256(initcontainer)</code> in the <code>new_address</code> hashing scheme</h3> <p><code>new_address = keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]</code> was originally proposed as the way to calculate the address of newly created contract, similar, but not exactly equal, to what <code>CREATE2</code> uses.</p> <p>This alternative however goes against code non-observability, because it locks in the contents of the initcontainer e.g. preventing re-writing it in some future upgrade. It also seems unnecessarily expensive: <code>EOFCREATE</code> can only pick up one of its subcontainers, yet the hash value would need to be recalculated on every execution of <code>EOFCREATE</code>.</p> <p>Other ways of removing code observability, yet keeping some form of witness of the code, were considered. However, keeping only <code>sender</code> and <code>salt</code> allows the implementer of the factory contract (i.e. one containing the <code>EOFCREATE</code> instruction) to include the code witness via the <code>salt</code> anyway, if that's necessary for the particular use case. Therefore, keeping the <code>new_address</code> formula minimal is the most flexible approach with better separation of concerns.</p> <p>Leaving the <code>keccak256(initcontainer)</code> out of the <code>new_address</code> hash has also the benefit of making the <code>new_address</code> independent of the metadata section (proposed for the EOF in a separate EIP), which is a desired property. Unfortunately, if a factory wants to opt into committing to a particular <code>initcontainer</code>, it needs to include it in the <code>salt</code>, and that will include the metadata section.</p> <h3 id="eofcreate-stack-argument-order"><code>EOFCREATE</code> stack argument order</h3> <p><code>EXT*CALL</code> instructions from <a href="https://wg-eips.ritovision.com/7069/">EIP-7069</a> have had their stack argument order changed, as compared to that of legacy instructions <code>*CALL</code>. We follow the same change to have <code>EOFCREATE</code> stack arg order match those of <code>EXTCALL</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted), and the contract creation options do not change for legacy bytecode.</p> <p><code>CREATE</code> and <code>CREATE2</code> calls with <code>EF00</code> initcode fail early without executing the initcode. Previously, in both cases the initcode execution would begin and fail on the first undefined instruction <code>EF</code>.</p> <h2 id="test-cases">Test Cases</h2> <p>Creation transaction, <code>CREATE</code> and <code>CREATE2</code> cannot have its <em>code</em> starting with <code>0xEF</code>, but such cases are covered already in <a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>. However, new cases must be added where <code>CREATE</code> or <code>CREATE2</code> have its <em>initcode</em> being (validly or invalidly) EOF formatted:</p> <table><thead><tr><th>Initcode</th><th>Expected result</th></tr></thead><tbody> <tr><td><code>0xEF</code></td><td>initcode starts execution and fails</td></tr> <tr><td><code>0xEF01</code></td><td>initcode starts execution and fails</td></tr> <tr><td><code>0xEF5f</code></td><td>initcode starts execution and fails</td></tr> <tr><td><code>0xEF00</code></td><td><code>CREATE</code> / <code>CREATE2</code> fails early, returns 0 and keeps sender nonce intact</td></tr> <tr><td><code>0xEF0001</code></td><td>as above</td></tr> <tr><td>valid EOFv1 container</td><td>as above</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>It is the EOF <code>InitcodeTransaction</code> (specified in <a href="https://wg-eips.ritovision.com/7873/">EIP-7873</a>) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others:</p> <ol> <li>Is its complexity under control, ruling out any DoS attempts</li> <li>Is it correctly priced and always charged for</li> <li>Is the validation comprehensive and not allowing problematic code to be saved into the state</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gary Ronghttps://github.com/rjl493456442 Martin Holst Swendehttps://github.com/holiman https://wg-eips.ritovision.com/7610/

Revert contract creation if address already has the non-empty storage

<h2 id="abstract">Abstract</h2> <p>This EIP causes contract creation to throw an error when attempted at an address with pre-existing storage.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>If a contract creation is attempted due to a creation transaction, the <code>CREATE</code> opcode, the <code>CREATE2</code> opcode, or any other reason, and the destination address already has either a nonzero nonce, a nonzero code length, or non-empty storage, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.</p> <p>This EIP amends <a href="https://wg-eips.ritovision.com/684/">EIP-684</a> with one extra condition, requiring empty storage for contract deployment.</p> <p>This EIP will not affect <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a>, since the authority's nonce is always incremented after an authorization is applied, which conflicts with the condition required for contract deployment.</p> <h2 id="rationale">Rationale</h2> <p>EIP-684 defines two conditions for contract deployment: the destination address must have zero nonce and zero code length. Unfortunately, this is not sufficient. Before <a href="https://wg-eips.ritovision.com/161/">EIP-161</a> was applied, the nonce of a newly deployed contract remained set to zero. Therefore, it was entirely possible to create a contract with a zero nonce and zero code length but with non-empty storage, if slots were set in the constructor. There exists 28 such contracts on Ethereum mainnet at this time.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is an execution layer upgrade, and so it requires a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>There exists quite a number of tests in the ethereum tests repo as well as in the execution spec tests, which test the scenario of deployment to targets with non-empty storage. These tests have been considered problematic in the past; Reth and EELS both intentionally implement a version of the account reset solely to pass the tests. Py-evm declared the situation impossible and never implemented account reset.</p> <p>Refilling the existing tests will provide sufficient coverage for this EIP.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP is a security upgrade: it enforces the immutability of deployed code.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-02-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Charles Cooperhttps://github.com/charles-cooper James Prestwichhttps://github.com/prestwich brockelmorehttps://github.com/brockelmore https://wg-eips.ritovision.com/7609/

Improve the efficiency of TLOAD/TSTORE by decreasing the base cost and introducing a superlinear pricing model.

<h2 id="abstract">Abstract</h2> <p>Decrease the base cost of TLOAD/TSTORE while introducing a superlinear pricing model. This increases the efficiency of TLOAD/TSTORE for common use cases, while providing a pricing model to prevent DoS vectors.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a> introduces a new storage region, termed "transient storage". It behaves like storage (word-addressed and persists between call frames), but unlike storage it is wiped at the end of each transaction. During development of EIP-1153, the pricing was set to be the same as warm storage loads and stores. This was for two reasons: conceptual simplicity of the EIP, and it also addressed concerns about two related DoS vectors: being able to allocate too much transient storage, and the cost of rolling back state in the case of reverts.</p> <p>One of the most important use cases that EIP-1153 enables is cheap reentrancy protection. In fact, if transient storage is cheap enough for the first few slots, reentrancy protection can be enabled by default at the language level without too much burden to users, while simultaneously preventing the largest—and most expensive—class of smart contract vulnerabilities.</p> <p>Furthermore, it seems that transient storage is fundamentally overpriced. Its pricing does not interact with refunds, it only requires a new allocation on contract load (as opposed to memory, which requires a fresh allocation on every call), and has no interaction with the physical database.</p> <p>This EIP proposes a pricing model which charges additional gas per allocation, which is cheaper for common cases (fewer than ~95 slots are written per contract), while making DoS using transient storage prohibitively expensive.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>The gas cost for <code>TLOAD</code> is proposed to be 5 gas. The gas cost for <code>TSTORE</code> is proposed to be 8 gas + <code>expansion_cost</code>, where <code>expansion_cost</code> is calculated as <code>1 gas * len(transient storage mapping)</code> if the key is not yet in the transient storage mapping, and otherwise 0 gas.</p> <p>In pseudo-code:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">G_LOW</span><span class="z-keyword"> =</span><span class="z-constant"> 5</span></span> <span class="giallo-l"><span class="z-constant">G_MID</span><span class="z-keyword"> =</span><span class="z-constant"> 8</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">SLOPE</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> gas_tload</span><span>(</span><span class="z-variable z-parameter z-function">_key</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> G_LOW</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> gas_tstore</span><span>(</span><span class="z-variable z-parameter z-function">key</span><span>,</span><span class="z-variable z-parameter z-function"> transient_mapping</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> cost</span><span class="z-keyword"> =</span><span class="z-constant"> G_MID</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> key</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> transient_mapping</span><span>:</span></span> <span class="giallo-l"><span> cost</span><span class="z-keyword"> +=</span><span class="z-constant"> SLOPE</span><span class="z-keyword"> *</span><span> transient_mapping</span><span>.</span><span>size</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> cost</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="gas">Gas</h3> <p>In benchmarking, <code>TLOAD</code> was found to cost a similar amount of CPU time as <code>MUL</code>, while <code>TSTORE</code> was found to cost about 1.5x that. The values <code>G_low</code> and <code>G_mid</code> were therefore chosen for <code>TLOAD</code> and <code>TSTORE</code>, respectively.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The maximum number of transient slots which can be allocated on a single contract given 30m gas is approximately 7,739 (solution to <code>x(x-1)/2*1 + 8*x = 30_000_000</code>), which totals 248KB.</p> <p>The maximum number of transient slots which can be allocated in a transaction if you use the strategy of calling new contracts (which each are designed to maximize transient storage allocation) once the cost of <code>TSTORE</code> is more than the cost of calling a cold contract (2600 gas), can be solved for as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>solve for SLOPE * &lt;num slots&gt; == 2600, =&gt; num_slots == 2600</span></span> <span class="giallo-l"><span>gas_used_by_contract = 2600 + SLOPE * num_slots * (num_slots - 1) / 2 + G_MID * num_slots == 3402100</span></span> <span class="giallo-l"><span>block_gas_limit = 30_000_000</span></span> <span class="giallo-l"><span>num_calls_per_txn = block_gas_limit // gas_used_by_contract ~= 8.8</span></span> <span class="giallo-l"><span>max_transient_slots = num_calls_per_txn * num_slots == 22927</span></span></code></pre> <p>Thus, the maximum number of transient slots which can be allocated in a single transaction with this method is roughly 23,000, which totals 736KB. Compared to the current gas schedule (which allows allocating approximately <code>30_000_000 / 100 * 32 == 9.6MB</code> worth of memory), this is a net <em>reduction</em> in the total memory which can be allocated on a client using transient storage, so this EIP presents a stronger bound on the resources which can be used by transient storage. As a comparison point, the total amount of memory which can be allocated on a client by <code>SSTORE</code>s in a given transaction is <code>30_000_000 / 20_000 * 32</code>, or 48KB.</p> <p>Note that this cap scales linearly with the gas limit, which is a useful property when considering future block gas limit increases.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-01-25T00:00:00+00:00 2026-02-11T14:49:28+00:00 Guillaume Ballethttps://github.com/gballet Ansgar Dietrichshttps://github.com/adietrichs Ignacio Hagopianhttps://github.com/jsign Gottfried Heroldhttps://github.com/GottfriedHerold Jamie Lokierhttps://github.com/jlokier Tanishq Jasoriahttps://github.com/tanishqjasoria Parithosh Jayanthihttps://github.com/parithosh Gabriel Rocheleauhttps://github.com/gabrocheleau Karim Taamhttps://github.com/matkt https://wg-eips.ritovision.com/7612/

Describes the use of an overlay tree to use the verkle tree structure, while leaving the historical state untouched.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a method to switch the state tree tree format from hexary Merkle Patricia Tree (MPT) to a Verkle Tree (VKT): the MPT tree is frozen, and new writes to the state are stored in a VKT “laid over” the hexary MPT. The historical MPT state is left untouched and its eventual migration is handled at a later time.</p> <h2 id="motivation">Motivation</h2> <p>The Ethereum state is growing, and VKTs offer a good mitigation strategy to stem this growth and enable weak statelessness. Owing to the difficulty of translating contracts with large storage while they are being accessed, proposals for migrating the current MPT state are complex and will require client teams to undergo a long process of refactoring their code to handle this conversion.</p> <p>The bigger the state, the longer any conversion process will take. This has an impact both while the conversion is happening, as well as when full-syncing the chain if the conversion is part of consensus. Fullsync is used extensively by core dev teams to test the performance of new code. A conversion longer than a month will impact the release schedule of client teams who typically release at this rate. Nodes that cannot follow the conversion will need to wait longer to rejoin. The conversion will also make reorgs slower, so reducing its duration is desirable.</p> <p>This current proposal suggests to stop the MPT state growth in its tracks by activating a new “overlay” VKT, that all new state updates are written to. The “base” MPT is frozen in place, until all execution clients are ready to perform the full transition. Data is read first from the overlay tree, and if not found there, from the MPT.</p> <p>Whenever the block that freeze the MPT is finalized, internal node data can be deleted, in order to free up disk space.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Parameter</th><th>value</th><th>Description</th></tr></thead><tbody> <tr><td><code>FORK_TIME</code></td><td><code>TBD</code></td><td>Time at which the overlay tree is activated.</td></tr> </tbody></table> <h3 id="helper-functions">Helper functions</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Determine if `block` is the fork activation block</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> is_fork_block</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> block</span><span>.</span><span>parent</span><span>.</span><span>timestamp</span><span class="z-keyword"> &lt;</span><span class="z-constant"> FORK_TIME</span><span class="z-invalid z-illegal"> &amp;&amp;</span><span> block</span><span>.</span><span>timestamp</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_TIME</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Write an account in the verkle tree</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verkle_set_account</span><span>(</span><span class="z-variable z-parameter z-function">tree</span><span>:</span><span> VerkleTree</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes32</span><span>,</span><span class="z-variable z-parameter z-function"> account</span><span>:</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> account</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> basicdata</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Version</span></span> <span class="giallo-l"><span> basicdata</span><span class="z-keyword"> +=</span><span class="z-support"> bytes</span><span>(</span><span class="z-constant">4</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Reserved</span></span> <span class="giallo-l"><span> basicdata</span><span class="z-keyword"> +=</span><span class="z-support"> len</span><span>(</span><span>account</span><span>.</span><span>code</span><span>)</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">3</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> basicdata</span><span class="z-keyword"> +=</span><span> account</span><span>.</span><span>nonce</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">8</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> basicdata</span><span class="z-keyword"> +=</span><span> account</span><span>.</span><span>balance</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">16</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> tree</span><span>.</span><span>set</span><span>(</span><span>key</span><span>,</span><span> basicdata</span><span>)</span></span> <span class="giallo-l"><span> ckkey</span><span class="z-keyword"> =</span><span> key</span></span> <span class="giallo-l"><span> ckkey</span><span>[</span><span class="z-constant">31</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> CODEHASH_LEAF_KEY</span></span> <span class="giallo-l"><span> tree</span><span>.</span><span>set</span><span>(</span><span>ckkey</span><span>,</span><span> account</span><span>.</span><span>code_hash</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Reads an account from the verkle tree</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> verkle_get_account</span><span>(</span><span class="z-variable z-parameter z-function">tree</span><span>:</span><span> VerkleTree</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes32</span><span>)</span><span> -&gt;</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> basicdata_leaf</span><span class="z-keyword"> =</span><span> tree</span><span>.</span><span>get</span><span>(</span><span>key</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> basicdata_leaf</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> cs</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>basicdata_leaf</span><span>[</span><span class="z-constant">5</span><span>:</span><span class="z-constant">8</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> nonce</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>basicdata_leaf</span><span>[</span><span class="z-constant">8</span><span>:</span><span class="z-constant">16</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> balance</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>basicdata_leaf</span><span>[</span><span class="z-constant">16</span><span>:</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span> ckkey</span><span class="z-keyword"> =</span><span> key</span></span> <span class="giallo-l"><span> ckkey</span><span>[</span><span class="z-constant">31</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> CODEHASH_LEAF_KEY</span></span> <span class="giallo-l"><span> ck</span><span class="z-keyword"> =</span><span> tree</span><span>.</span><span>get</span><span>(</span><span>ckkey</span><span>)</span></span> <span class="giallo-l"><span> cskey</span><span class="z-keyword"> =</span><span> key</span></span> <span class="giallo-l"><span> cskey</span><span>[</span><span class="z-constant">31</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> CODE_SIZE_LEAF_KEY</span></span> <span class="giallo-l"><span> cs</span><span class="z-keyword"> =</span><span> tree</span><span>.</span><span>get</span><span>(</span><span>cskey</span><span>)</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> Account</span><span>(</span><span class="z-constant">0</span><span>,</span><span> balance</span><span>,</span><span> nonce</span><span>,</span><span> ck</span><span>,</span><span> cs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> account</span></span></code></pre><h3 id="changes-to-the-execution-spec">Changes to the execution spec</h3> <p>In the execution spec, modify the <code>State</code> class as such:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> State</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Contains all information that is preserved between transactions.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> _main_trie</span><span>:</span><span> Trie</span><span>[</span><span>Address</span><span>,</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> default_factory</span><span class="z-keyword">=</span><span class="z-storage z-type">lambda</span><span>:</span><span> Trie</span><span>(</span><span class="z-variable">secured</span><span class="z-keyword">=</span><span class="z-constant">True</span><span>,</span><span class="z-variable"> default</span><span class="z-keyword">=</span><span class="z-constant">None</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> _storage_tries</span><span>:</span><span> Dict</span><span>[</span><span>Address</span><span>,</span><span> Trie</span><span>[</span><span>Bytes</span><span>,</span><span> U256</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> default_factory</span><span class="z-keyword">=</span><span class="z-support">dict</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> _snapshots</span><span>:</span><span> List</span><span>[</span></span> <span class="giallo-l"><span> Tuple</span><span>[</span></span> <span class="giallo-l"><span> Trie</span><span>[</span><span>Address</span><span>,</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>]</span><span>,</span><span> Dict</span><span>[</span><span>Address</span><span>,</span><span> Trie</span><span>[</span><span>Bytes</span><span>,</span><span> U256</span><span>]</span><span>]</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> ]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">list</span><span>)</span></span> <span class="giallo-l"><span> _created_accounts</span><span>:</span><span> Set</span><span>[</span><span>Address</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">set</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Added in this EIP</span></span> <span class="giallo-l"><span> _overlay_tree</span><span>:</span><span> VerkleTree</span><span>[</span><span>Address</span><span>,</span><span> Bytes32</span><span>]</span></span></code></pre> <p>And the state access functions are modified as such:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_account_optional</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>)</span><span> -&gt;</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> account</span><span class="z-keyword"> =</span><span> verkle_get_account</span><span>(</span><span>state</span><span>.</span><span>_overlay_tree</span><span>,</span><span> get_tree_key_for_version</span><span>(</span><span>addr</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> account</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> account</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> trie_get</span><span>(</span><span>state</span><span>.</span><span>_main_trie</span><span>,</span><span> address</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> set_account</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> account</span><span>:</span><span> Optional</span><span>[</span><span>Account</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> verkle_set_account</span><span>(</span><span>state</span><span>.</span><span>_overlay_tree</span><span>,</span><span> get_tree_key_for_nonce</span><span>(</span><span>addr</span><span>)</span><span>,</span><span> account</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_storage</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> U256</span><span>:</span></span> <span class="giallo-l"><span> value</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>_overlay_tree</span><span>.</span><span>get</span><span>(</span><span>get_tree_key_for_storage_slot</span><span>(</span><span>addr</span><span>,</span><span> slot</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> value</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> value</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> trie</span><span class="z-keyword"> =</span><span> state</span><span>.</span><span>_storage_tries</span><span>.</span><span>get</span><span>(</span><span>address</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> trie</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> U256</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> value</span><span class="z-keyword"> =</span><span> trie_get</span><span>(</span><span>trie</span><span>,</span><span> key</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>value</span><span>,</span><span> U256</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> value</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> set_storage</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> key</span><span>:</span><span> Bytes</span><span>,</span><span class="z-variable z-parameter z-function"> value</span><span>:</span><span> U256</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_overlay_tree</span><span>.</span><span>set</span><span>(</span><span>get_tree_key_for_storage_slot</span><span>(</span><span>addr</span><span>,</span><span> slot</span><span>)</span><span>,</span><span> value</span><span>)</span></span></code></pre> <p>Add the following function which is used when storing a contract in the tree:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> state_set_codechunk</span><span>(</span><span class="z-variable z-parameter z-function">state</span><span>:</span><span> State</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>:</span><span> Address</span><span>,</span><span class="z-variable z-parameter z-function"> chunk_num</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> chunk</span><span>:</span><span> Bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>_overlay_tree</span><span>.</span><span>set</span><span>(</span><span>get_tree_key_for_code_chunk</span><span>(</span><span>addr</span><span>,</span><span> chunk_num</span><span>)</span><span>,</span><span> chunk</span><span>)</span></span></code></pre><h3 id="changes-to-the-block-header">Changes to the block header</h3> <p>At <code>FORK_TIME</code> the block header state root is changed from the MPT root to the VKT root.</p> <h2 id="rationale">Rationale</h2> <p>This approach doesn't convert the state, which is left to a subsequent EIP. This is meant as a stopgap in case we decide to push the conversion itself to a later time. It has the advantage of simplicity, which means that the Verge fork could happen at the same time as other, simpler EIPs. It also requires no change at the consensus layer.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <!-- This section is optional for non-Core EIPs. The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.) If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed TODO: Remove this comment before submitting --> <h2 id="reference-implementation">Reference Implementation</h2> <ul> <li><code>transition-post-genesis</code> branch in <code>github.com/gballet/go-ethereum</code> implements this when setting <code>--override.overlay-stride=0</code> on the command line.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <!-- All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. The current placeholder is acceptable for a draft. TODO: Remove this comment before submitting --> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-01-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danny Ryanhttps://github.com/djrtwo Dankrad Feisthttps://github.com/dankrad Francesco D'Amatohttps://github.com/fradamt Hsiao-Wei Wanghttps://github.com/hwwhww Alex Stokeshttps://github.com/ralexstokes https://wg-eips.ritovision.com/7594/

Introducing simple DAS utilizing gossip distribution and peer requests

<h2 id="abstract">Abstract</h2> <p>PeerDAS (Peer Data Availability Sampling) is a networking protocol that allows nodes to perform data availability sampling (DAS) to ensure that blob data has been made available while downloading only a subset of the data. PeerDAS utilizes gossip for distribution, discovery for finding peers of particular data custody, and peer requests for sampling.</p> <h2 id="motivation">Motivation</h2> <p>DAS is a method of scaling data availability beyond the levels of <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> by not requiring all nodes to download all data while still ensuring that all of the data has been made available.</p> <p>Providing additional data availability helps bring scale to Ethereum users in the context of layer 2 systems called "roll-ups" whose dominant bottleneck is layer 1 data availability.</p> <h2 id="specification">Specification</h2> <p>We extend the blobs introduced in EIP-4844 using a one-dimensional erasure coding extension. Each row consists of the blob data combined with its erasure code. It is subdivided into cells, which are the smallest units that can be authenticated with their respective blob's KZG commitments. Each column, associated with a specific gossip subnet, consists of the cells from all rows for a specific index. Each node is responsible for maintaining a deterministic set of column subnets and custodying their data as a function of their node ID.</p> <p>Nodes find and maintain a diverse peer set and sample columns from their peers to perform DAS every slot.</p> <p>A node can reconstruct the entire data matrix if it acquires at least 50% of all the columns. If a node has less than 50%, it can request the necessary columns from its peer nodes.</p> <p>Additionally, a limit of 6 blobs per transaction is introduced. Clients MUST enforce this limit when validating blob transactions at submission time, when received from the network, and during block production and processing.</p> <p>The detailed specifications are on <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/9d377fd53d029536e57cfda1a4d2c700c59f86bf/specs/fulu/">ethereum/consensus-specs</a>.</p> <p>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 and RFC 8174.</p> <h3 id="networking">Networking</h3> <p>This EIP introduces cell KZG proofs, which are used to prove that a KZG commitment opens to a cell at the given index. This allows downloading only specific cells from a blob, while still ensuring data integrity with respect to the corresponding KZG commitment, and is therefore a key component of data availability sampling. However, computing the cell proofs for a blob is an expensive operation, which a block producer would have to repeat for many blobs. Since proof verification is much cheaper than proof computation, and the proof size is negligible compared to cell size, we instead require blob transaction senders to compute the proofs themselves and include them in the EIP-4844 transaction pool wrapper for blob transactions.</p> <p>To this end, during transaction gossip responses (<code>PooledTransactions</code>), the wrapper is modified to:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>cell_proofs = [cell_proof_0, cell_proof_1, ...]</span></span></code></pre> <p>The <code>tx_payload_body</code>, <code>blobs</code> and <code>commitments</code> are as in EIP-4844, while the <code>proofs</code> field is replaced by <code>cell_proofs</code>, and a <code>wrapper_version</code> is added. These are defined as follows:</p> <ul> <li><code>wrapper_version</code> - one byte indicating which version of the wrapper is used. For the current version, it is set to <strong><code>1</code></strong>.</li> <li><code>cell_proofs</code> - list of cell proofs for all <code>blobs</code>, including the proofs for the extension indices, for a total of <code>CELLS_PER_EXT_BLOB</code> proofs per blob (<code>CELLS_PER_EXT_BLOB</code> is the number of cells for an extended blob, defined <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/9d377fd53d029536e57cfda1a4d2c700c59f86bf/specs/fulu/polynomial-commitments-sampling.md#cells">in the consensus specs</a>)</li> </ul> <p>Note that, while <code>cell_proofs</code> contain the proofs for all cells, including the extension cells, the blobs themselves are sent without being extended (<code>CELLS_PER_EXT_BLOB / 2</code> cells per blob). This is to avoid sending redundant data, which can quickly be computed by the receiving node. In other words, <code>cell_proofs[i * CELLS_PER_EXT_BLOB + j]</code> is the proof for cell <code>j</code> of <code>compute_cells(blobs[i])</code>, where <code>compute_cells(blob)</code> outputs all cells of <code>blob</code>, including the extension cells.</p> <p>The node MUST validate <code>tx_payload_body</code> and verify the wrapped data against it. To do so, ensure that:</p> <ul> <li>There are an equal number of <code>tx_payload_body.blob_versioned_hashes</code>, <code>blobs</code> and <code>commitments</code>.</li> <li><code>cell_proofs</code> contains exactly <code>CELLS_PER_EXT_BLOB * len(blobs)</code> cell proofs</li> <li>The KZG <code>commitments</code> hash to the versioned hashes, i.e. <code>kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]</code></li> <li>The KZG <code>commitments</code> match the corresponding <code>blobs</code> and <code>cell_proofs</code>. This requires computing the extension cells for all <code>blobs</code> (e.g. via <code>compute_cells</code>), and verifying all <code>cell_proofs</code>. (Note: all cell proofs can be batch verified at once, e.g. via <code>verify_cell_kzg_proof_batch</code>)</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-use-das-to-scale-the-da-layer">Why use DAS to scale the DA layer?</h3> <p>PeerDAS is a DAS scheme that requires nodes to only download a small constant fraction of the data to satisfy a local availability check. With the current parameters, this is 1/8 of the total data (i.e. blobs in a block), which can in the future be decreased to 1/16 or even 1/32 by reducing the size of samples (increasing the number of columns). In this way, PeerDAS allows for securely scaling the blob throughput of the network without compromising decentralization, i.e., without increasing node's bandwidth and storage requirements.</p> <h3 id="what-does-peer-sampling-provide">What does peer sampling provide?</h3> <p>PeerDAS takes the set of peers of a node on the network as a primitive to build a DAS scheme around. A focus on peers allows for redundancy in the mechanism (as a node generally has many peers, and peer count can also be cheaply increased) which both helps with theoretical security as detailed in the "Security Considerations" section, but also practical security of the implementation (e.g. if a single peer fails, a node can likely use another peer for the same sampling task).</p> <p>PeerDAS also has the nice property that any given node may voluntarily custody more of the data than the bare minimum which increases the performance of the mechanism. Alternative schemes do not readily support this "transparent" scaling property.</p> <h3 id="why-are-these-parameters-chosen">Why are these parameters chosen?</h3> <p>The parameters of PeerDAS given in the specs support network security while keeping node requirements sufficiently low. See the security argument below for further details.</p> <h3 id="why-do-validators-have-an-additional-custody-requirement-beyond-full-nodes">Why do validators have an additional custody requirement beyond full nodes?</h3> <p>Validators are assumed to have marginally higher requirements to participate on the network. PeerDAS introduces a custody requirement that scales with the validator count so that nodes with more resources can contribute to a more stable backbone that makes the global network more robust.</p> <h3 id="column-sampling-vs-row-sampling">Column sampling vs row sampling</h3> <p>PeerDAS defines a sample as a "column" which is a cross-section across <em>all</em> blobs, rather than a "row" which would be a full blob. The sampling scheme could be defined over rows but then any reconstruction strategy would need to work over "extension" blobs that do not a priori exist on the network. Reconstruction becomes much more tractable by working over columns as nodes can be assumed to have much more of the complete data by default (e.g. because most/all of the blobs are in the public mempool).</p> <p>Another benefit is that sampling over rows requires <em>column</em> extensions which would have to be done at the time of block construction, i.e. on the "critical path". Sampling over columns requires row extensions which can be done in advance (not on the critical path), and moreover proof computation can be outsourced to senders of blob transactions.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is fully backwards compatible with <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>.</p> <h2 id="test-cases">Test Cases</h2> <p>Refer to the consensus and execution spec tests for testing of this EIP.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The primary failure mode of a DAS scheme is a "data withholding" attack, where a block producer attempts to convince the network some data is available even when the block producer fails to provide the associated data. PeerDAS resolves withholding attacks by implementing a (pseudo)randomized sampling scheme that decreases the probability of a successful attack as the size of the network grows for a sublinear amount of data that must be downloaded.</p> <p>This intuition can be formalized as follows:</p> <p>Letting <code>n</code> be the total number of sampling nodes (i.e. the size of the network), <code>m</code> be the total number of samples possible (cf. <code>NUMBER_OF_CUSTODY_GROUPS</code> in the specs) and <code>k</code> be the minimum number of samples that a node must download (cf. <code>SAMPLES_PER_SLOT</code> in the specs), we have the following bound for the probability of convincing a fraction $\epsilon$ of the nodes that some data is available when it is withheld:</p> <p><img src="https://wg-eips.ritovision.com/7594/./assets/withholding-probability.svg" alt="withholding-probability" /></p> <p>The first term is the number of possible ways to choose a subset of $n\epsilon$ nodes whose sampling queries should be satisfied (i.e. the nodes to be tricked). The second term is the number of ways to choose a maximally large subset of samples to be made available to satisfy the sampling queries of the $n\epsilon$ nodes without allowing reconstruction of the full data. Finally, for any such choices, the third term is the probability of success, i.e. the probability that the sampling queries of all chosen $n\epsilon$ nodes are satisfied by the chosen subset up to the reconstruction threshold.</p> <p>For mainnet parameters given in the specs and assuming 10,000 nodes on the network, we can compute upper bounds of attack success for varying $\epsilon$:</p> <table><thead><tr><th style="text-align: center">$\epsilon$</th><th style="text-align: center">$n\epsilon$ (target nodes)</th><th style="text-align: center">Upper bound on $\mathbb{P}$</th></tr></thead><tbody> <tr><td style="text-align: center">0.01</td><td style="text-align: center">100</td><td style="text-align: center">$1$</td></tr> <tr><td style="text-align: center">0.02</td><td style="text-align: center">200</td><td style="text-align: center">$10^{-20.04}$</td></tr> <tr><td style="text-align: center">0.03</td><td style="text-align: center">300</td><td style="text-align: center">$10^{-101.55}$</td></tr> <tr><td style="text-align: center">0.04</td><td style="text-align: center">400</td><td style="text-align: center">$10^{-198.24}$</td></tr> <tr><td style="text-align: center">0.05</td><td style="text-align: center">500</td><td style="text-align: center">$10^{-306.34}$</td></tr> </tbody></table> <p>The table shows that the chances of a successful attack quickly drop to a negligible amount and so PeerDAS is considered secure to withholding attacks.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2024-01-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Marius van der Wijdenhttps://github.com/MariusVanDerWijden https://wg-eips.ritovision.com/7591/

Introduces a new transaction type signed with BLS signatures

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type that is signed with BLS signatures.</p> <h2 id="motivation">Motivation</h2> <p>The BLS signature scheme allows for easy aggregation and verification of aggregated signatures. If a substantial number of transactions on mainnet were BLS signed transactions, we can aggregate signatures in a block and batch-verify them. This will reduce growth of the chain history.</p> <h2 id="specification">Specification</h2> <p>BLS_TX_TYPE = Bytes1(0x04)</p> <h3 id="transaction-type">Transaction Type</h3> <p>The transaction type will have the following format:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender, signature]</span></span></code></pre> <p>with <code>sender</code> being the BLS public key of an account with address <code>address = [0:20](keccak256(sender))</code>.</p> <p>The signature value <code>signature</code> is calculated by constructing a BLS signature over the following digest:</p> <p><code>tx_hash = keccak256(BLS_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender]))</code>.</p> <h3 id="header-changes">Header changes</h3> <p>The block header will be amended with the <code>aggregated_sig</code> field, containing an aggregated signature of all BLS transactions in the block.</p> <p>The resulting RLP encoding of the header is therefore:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([</span></span> <span class="giallo-l"><span> parent_hash,</span></span> <span class="giallo-l"><span> 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash</span></span> <span class="giallo-l"><span> coinbase,</span></span> <span class="giallo-l"><span> state_root,</span></span> <span class="giallo-l"><span> txs_root,</span></span> <span class="giallo-l"><span> receipts_root,</span></span> <span class="giallo-l"><span> logs_bloom,</span></span> <span class="giallo-l"><span> 0, # difficulty</span></span> <span class="giallo-l"><span> number,</span></span> <span class="giallo-l"><span> gas_limit,</span></span> <span class="giallo-l"><span> gas_used,</span></span> <span class="giallo-l"><span> timestamp,</span></span> <span class="giallo-l"><span> extradata,</span></span> <span class="giallo-l"><span> prev_randao,</span></span> <span class="giallo-l"><span> 0x0000000000000000, # nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas,</span></span> <span class="giallo-l"><span> withdrawals_root,</span></span> <span class="giallo-l"><span> blob_gas_used,</span></span> <span class="giallo-l"><span> excess_blob_gas,</span></span> <span class="giallo-l"><span> aggregated_sig,</span></span> <span class="giallo-l"><span>])</span></span></code></pre><h3 id="block-changes">Block changes</h3> <p>The block building algorithm needs to be changed in order to built the aggregated signature of all BLS signed transactions in the block. All transactions in the block will be added without the signature field set.</p> <p>Blocks with transactions containing the <code>signature</code> field MUST be rejected.</p> <p>On block verification, the <code>verifyAggregate</code> algorithm is used as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>valid = verifyAggregate(sender_1, ... sender_n, tx_hash_1, ... tx_hash_n, aggregated_sig)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>Removing the ECDSA signature from a transaction saves 65 bytes. The BLS public key is 48 bytes, the aggregated signature is 96 bytes. Thus we save <code>-96 + (65-48)* #transactions</code> bytes per block. With ~7000 blocks per day, 1.000.000 transactions per day, the average block contains roughly 150 transactions.</p> <p>Thus we would save 2454 bytes or 2.4KB per block. This would equate to ~1.5% saving given an average block size of 160KB.</p> <p>In addition to the (admittedly meager) size savings for full nodes, the ability to add a new transaction type to utilize a different signature scheme does have some merit to it. This proposal shows that it would be possible to add for example a quantum safe signature scheme to ethereum.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the execution layer and introduces a new transaction type and a new header field. Thus a hardfork is needed.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The messages signed via BLS are distinct (no hash collisions on the txhash), thus the aggregation is secure even without a proof-of-possession. The public keys are not distinct which is not a problem in BLS.</p> <p>We assume that keccak256 and ECDSA and BLS are working as intended. Suppose we have two addresses <code>address_1 = keccak256(pk_ecdsa)</code> and <code>address_2 = keccak(pk_bls)</code> with <code>address_1 == address_2</code>. We know that <code>pk_ecdsa</code> must be equal to <code>pk_bls</code> (follows from keccak). This would mean that we would either be able to find <code>x</code> with <code>g_bls^x = y</code> for a given <code>y</code> (violates the security of BLS) or find <code>z</code> with <code>d_ecdsa^z = y</code> (violates the security of ECDSA).</p> <p>Thus it would be impossible (with greater than negligble probability) to find two private keys, one in ECDSA and one in BLS that control the same account.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-11-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 dapplionhttps://github.com/dapplion Mikhail Kalininhttps://github.com/mkalinin https://wg-eips.ritovision.com/7549/

Move committee index outside of the signed Attestation message

<h2 id="abstract">Abstract</h2> <p>Move the committee's <code>index</code> field outside of the signed Attestation message to allow aggregation of equal consensus votes.</p> <h2 id="motivation">Motivation</h2> <p>This proposal aims to make Casper FFG clients more efficient by reducing the average number of pairings needed to verify consensus rules. While all types of clients can benefit from this EIP, ZK circuits proving Casper FFG consensus will likely have the most impact.</p> <p>On a beacon chain network with at least 262144 active indices, it's necessary to verify a minimum of <code>ceil(32*64 * 2/3) = 1366</code> attestations to reach a 2/3 threshold. Participants cast two votes at once: LMD GHOST vote and Casper-FFG vote. However, the Attestation message contains three elements:</p> <ol> <li>LMD GHOST vote <code>(beacon_block_root, slot)</code>. Note: includes slot in the event (block, slot) voting is adopted.</li> <li>FFG vote <code>(source, target)</code></li> <li>Committee index <code>(index)</code></li> </ol> <p>Signing over the 3rd item causes tuples of equal votes to produce different signing roots. If the committee index is moved outside of the Attestation message, the minimum number of attestations to verify to reach a 2/3 threshold is reduced to <code>ceil(32 * 2/3) = 22</code> (a factor of 62).</p> <p>On-chain attestations can now be packed more space-efficiently into beacon blocks. This proposal allows for up to 8 slots worth of votes in a block, compared to 2 today. In other words, a chain with only 1/8 online proposers can still potentially include all votes on-chain.</p> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution layer</h3> <p>This requires no changes to the Execution Layer.</p> <h3 id="consensus-layer">Consensus layer</h3> <ul> <li>Set <code>index</code> field from <code>AttestationData</code> to a fixed value of zero</li> <li>Move committee indexing data to the outer <code>Attestation</code> container with <code>committee_bits</code></li> <li>Increase the capacity of <code>aggregation_bits</code> to all committees in a slot</li> </ul> <p>The full specification of the proposed change can be found in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/2c1f677187e6534aec77057a7d1cc746a40d3630/specs/electra/beacon-chain.md"><code>/specs/electra/beacon-chain.md</code></a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="deprecation-strategy">Deprecation strategy</h3> <p>The <code>index</code> field in <code>AttestationData</code> can be deprecated by:</p> <ol> <li>Removing the field</li> <li>Preserving the field and setting it to zero</li> <li>Changing the field type to Optional (from EIP-7495 StableContainer)</li> </ol> <p>This EIP chooses the second option to not complicate the inclusion of <code>AttesterSlashing</code> objects. While the <code>Attestation</code> container changes, <code>AttesterSlashing</code> includes indexed attestations without committee data.</p> <h3 id="max-attestations-value"><code>MAX_ATTESTATIONS</code> value</h3> <p>The maximum size of an attestation increases, with a bitfield 64 times larger on networks with maxed committees. <code>MAX_ATTESTATIONS</code> value is reduced to limit the beacon block size while still increasing the total capacity of votes. A value of 8 increases the voting capacity by 4 while having the same attestation space size with a network of 1.2M active indices. Read the details <a href="https://wg-eips.ritovision.com/7549/assets/complexity_analysis/">here</a>.</p> <h3 id="max-attester-slashings-value"><code>MAX_ATTESTER_SLASHINGS</code> value</h3> <p>On-chain <code>AttesterSlashing</code> includes a list of participants' indices. With this EIP, the worst-case size increases by 64 times, resulting in an uncompressed size of 488 KB per <code>AttesterSlashing</code> in a network of 1M validators. Snappy compression reduces it to 320 KB, which is still significant. To bound the maximum size of the block, this proposal reduces <code>MAX_ATTESTER_SLASHINGS</code> from 2 to 1, the minimum value. Read the details <a href="https://wg-eips.ritovision.com/7549/assets/complexity_analysis/">here</a>.</p> <h3 id="using-bitvector-for-committee-bits">Using <code>Bitvector</code> for <code>committee_bits</code></h3> <p>The <code>committee_bits</code> sequence has a variable length with the max size <code>MAX_COMMITTEES_PER_SLOT = 64</code>. Encoding of the <code>Bitlist</code> includes its actual length, which doubles the size of the <code>committee_bits</code> compared to the <code>Bitvector</code> type. Beacon chain state transition ensures correctness of the <code>committee_bits</code> when the effective number of committees in a slot is less than its max value.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward-incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="first-block-after-the-fork">First block after the fork</h3> <p>Because the on-chain <code>Attestation</code> container changes, attestations from the prior fork can't be included in post-Electra blocks. Therefore, the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via <code>on_attestation</code> handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the Electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain, so this proposal chooses not to address the issue.</p> <h3 id="mutation-over-gossip">Mutation over gossip</h3> <p>Moving the <code>index</code> field outside of the signed message allows malicious mutation only on the p2p gossip topic <code>beacon_attestation_${subnet_id}</code>. Everywhere else, the <code>Attestation</code> message is wrapped with an outer signature that prevents mutation.</p> <p>Gossip verification rules for the <code>beacon_attestation_${subnet_id}</code> topic include:</p> <blockquote> <ul> <li>[REJECT] The attester is a member of the committee -- i.e., <code>attestation.attester_index</code> in <code>get_beacon_committee(state, attestation.data.slot, index)</code></li> </ul> </blockquote> <p>If an attacker mutates the <code>index</code> field, the above rule verification will fail, and the message will be dropped. If implementations run the above check before registering the attestation in a 'first-seen' cache, there's no risk of cache pollution.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-10-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 mikehttps://github.com/michaelneuder Vitalikhttps://github.com/vbuterin Francescohttps://github.com/fradamt Terencehttps://github.com/terencechain potuzhttps://github.com/potuz Manavhttps://github.com/manav2401 https://wg-eips.ritovision.com/7547/

Add an inclusion list mechanism to allow forced transaction inclusion.

<h2 id="abstract">Abstract</h2> <p>Censorship resistance is a core value proposition of blockchains. Inclusion lists aim to provide a mechanism to improve the censorship resistance of Ethereum by allowing proposers to specify a set of transactions that must be promptly included for subsequent blocks to be considered valid.</p> <h2 id="motivation">Motivation</h2> <p>Since the merge, validators have started outsourcing almost all block production to a specialized set of builders who compete to extract the most MEV (this is commonly referred to as Proposer-Builder Separation). As of October 2023, nearly 95% of blocks are built by builders rather than the proposer. While it is great that all proposers have access to competitive blocks through the <code>mev-boost</code> ecosystem, a major downside of externally built blocks is the fact that the builders ultimately decide what transactions to include or exclude. Without any forced transaction inclusion mechanism, the proposer is faced with a difficult choice: they either have no say on the transactions that get included, or they build the block locally (thus have the final say on transactions) and sacrifice some MEV rewards.</p> <p>Inclusion lists aim to allow proposers to retain some authority by providing a mechanism by which transactions can be forcibly included. The simplest design is for the <code>slot N</code> proposer to specify a list of transactions that must be included in the block that is produced for their slot. However, this is not incentive-compatible because builders may choose to abstain from building blocks if the proposer sets some constraints on their behavior. This leads to the idea of "forward" inclusion lists, where the transactions specified by the <code>slot N</code> proposer are enforced in the <code>slot N+1</code> block. The naïve implementation of the forward inclusion lists presents a different issue of potentially exposing free data availability, which could be exploited to bloat the size of the chain without paying the requisite gas costs. The free data availability problem is solved with observations about nonce reuse and allowing multiple inclusion lists to be specified for each slot. With the incentive compatibility and free data availability problems addressed, we can more safely proceed with the implementation of inclusion lists.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAX_TRANSACTIONS_PER_INCLUSION_LIST</code></td><td><code>2**4 = 16</code></td></tr> <tr><td><code>MAX_GAS_PER_INCLUSION_LIST</code></td><td><code>2**21</code></td></tr> <tr><td><code>MIN_SLOTS_FOR_INCLUSION_LIST_REQUEST</code></td><td><code>1</code></td></tr> </tbody></table> <h4 id="reference-objects">Reference Objects</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class InclusionListSummaryEntry(Container):</span></span> <span class="giallo-l"><span> address: ExecutionAddress</span></span> <span class="giallo-l"><span> gas_limit: uint64</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class InclusionListSummary(Container)</span></span> <span class="giallo-l"><span> slot: Slot</span></span> <span class="giallo-l"><span> proposer_index: ValidatorIndex</span></span> <span class="giallo-l"><span> summary: List[InclusionListSummaryEntry, MAX_TRANSACTIONS_PER_INCLUSION_LIST]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class SignedInclusionListSummary(Container):</span></span> <span class="giallo-l"><span> message: InclusionListSummary</span></span> <span class="giallo-l"><span> signature: BLSSignature</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class InclusionList(Container)</span></span> <span class="giallo-l"><span> summary: SignedInclusionListSummary</span></span> <span class="giallo-l"><span> transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class ExecutionPayload(Container):</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> inclusion_list_summary: List[InclusionListSummaryEntry, MAX_TRANSACTIONS_PER_INCLUSION_LIST]</span></span> <span class="giallo-l"><span> inclusion_list_exclusions: List[uint64, MAX_TRANSACTIONS_PER_INCLUSION_LIST]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class ExecutionPayloadHeader(Container):</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> inclusion_list_summary_root: Root</span></span> <span class="giallo-l"><span> inclusion_list_exclusions_root: Root</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>class BeaconBlockBody(Container):</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> inclusion_list_summary: SignedInclusionListSummary</span></span></code></pre><h3 id="consensus-layer">Consensus layer</h3> <h4 id="high-level-overview">High-level overview</h4> <p><strong><code>slot N</code> proposal:</strong></p> <ul> <li>Proposer broadcasts a signed block and an inclusion list (summary and transactions objects) for <code>slot N+1</code>.</li> <li>Transactions will be included in <code>slot N</code> or <code>slot N+1</code>.</li> <li>Summaries include the originating address of the transactions and their respective gas limits.</li> <li>Summaries are signed, but transactions are not.</li> </ul> <p><strong><code>slot N</code> validation:</strong></p> <ul> <li>Validators only consider the block for validation and fork-choice if they have seen at least one inclusion list for that slot.</li> <li>They consider the block invalid if the inclusion list transactions are not executable at the start of <code>slot N</code> or if the transactions' <code>maxFeePerGas</code> are not at least 12.5% higher than the current slot (to ensure the transactions will be valid in <code>slot N+1</code>).</li> </ul> <p><strong><code>slot N+1</code> validation:</strong></p> <ul> <li>The proposer for <code>slot N+1</code> builds their block along with a signed summary from the <code>slot N</code> proposer.</li> <li>The payload includes a list of transaction indices from the <code>slot N</code> payload that satisfy some entry in the signed inclusion list summary.</li> <li>The payload is considered valid if: (a) the execution conditions are met, including satisfying the inclusion list summary and being executable from the execution layer perspective, and (b) the consensus conditions are met with a proposer signature of the previous block.</li> </ul> <h4 id="specific-changes">Specific Changes</h4> <p><strong>Beacon chain state transition spec:</strong></p> <ul> <li><em><strong>New</strong> <code>inclusion_list</code> object:</em> Introduce a new <code>inclusion_list</code> for the proposer to submit and nodes to process.</li> <li><em><strong>Modified</strong> <code>ExecutionPayload</code> and <code>ExecutionPayloadHeader</code> objects:</em> Update these objects to meet the inclusion list requirements.</li> <li><em><strong>Modified</strong> <code>BeaconBlockBody</code>:</em> Modified to cache the inclusion list summary.</li> <li><em><strong>Modified</strong> <code>process_execution_payload</code> function:</em> Update this process to include checks for the inclusion list summary satisfaction.</li> </ul> <p><strong>Beacon chain fork-choice spec:</strong></p> <ul> <li><em><strong>New</strong> <code>is_inclusion_list_available</code> check:</em> Introduce a new check to determine if the inclusion list is available within the visibility window.</li> <li><em><strong>New</strong> notification action:</em> Implement a new call to notify the Execution Layer (EL) client about a new inclusion list. The corresponding block is considered invalid if the EL client deems the inclusion list invalid.</li> </ul> <p><strong>Beacon chain P2P spec:</strong></p> <ul> <li><em><strong>New</strong> gossipnet and validation rules for inclusion list:</em> Define new rules for handling the inclusion list in the gossip network and validation.</li> <li><em><strong>New</strong> RPC request and response network for inclusion list:</em> Establish a new network for sending and receiving inclusion lists.</li> </ul> <p><strong>Validator spec:</strong></p> <ul> <li><em><strong>New</strong> duty for <code>inclusion_list</code>:</em> Proposer to prepare and sign the inclusion list.</li> <li><em><strong>Modified</strong> duty for <code>BeaconBlockBody</code>:</em> Update the duty to prepare the beacon block body to include the <code>inclusion_list_summary</code>.</li> </ul> <h3 id="execution-layer">Execution layer</h3> <ul> <li><em><strong>New</strong> <code>get_inclusion_list</code>:</em> Introduce a new function for proposers to retrieve inclusion lists.</li> <li><em><strong>New</strong> <code>new_inclusion_list</code>:</em> Define a new function for nodes to validate the execution side of the inclusion list.</li> <li><em><strong>Modified</strong> <code>forkchoice_updated</code>:</em> Update the function with a <code>payload_attribute</code> to include the inclusion list summary as part of the attribute.</li> <li><em><strong>Modified</strong> <code>new_payload</code>:</em> Update the function for EL clients to verify that <code>payload_transactions</code> satisfy <code>payload.inclusion_list_summary</code> and <code>payload.inclusion_list_exclusions</code>.</li> <li><em><strong>New</strong> validation rules:</em> Implement new validation rules based on the changes introduced in the Execution-API spec.</li> </ul> <h2 id="rationale">Rationale</h2> <p>We consider a few design decisions present in this EIP.</p> <ol> <li><code>ReducedSummary</code> versus <code>Summary</code> <ul> <li>The original proposal tries to improve data efficiency by using a <code>ReducedSummary</code> and a <code>Rebuilder</code>. This allows the full summary to be reconstructed.</li> <li>This adds a lot of complexity to the spec, so in this initial version, we should consider just using the regular <code>Summary</code> and including that in the subsequent block.</li> </ul> </li> <li>Gas limit vs no limit. <ul> <li>One consideration is whether the inclusion list should have a gas limit or use the block’s gas limit.</li> <li>Having a separate gas limit simplifies complexity but opens up the possibility for validators to outsource their inclusion list construction for side payments (e.g., if a block is full, the proposer could auction off space in the inclusion list for guaranteed inclusion in the subsequent block).</li> <li>Alternatively, inclusion lists could be part of the block gas limit and only satisfied if the block gas limit is not full. However, this could lead to situations where the next block proposer intentionally fills up the block to ignore the inclusion list, albeit at the potential expense of paying to waste the gas.</li> </ul> </li> <li>Inclusion list ordering. <ul> <li>We assume that the inclusion list is processed at the top of the <code>slot N</code> block. Transactions in the inclusion list are evaluated for the pre-state of <code>slot N</code> but are only guaranteed to be included in <code>slot N+1</code>.</li> </ul> </li> <li>Inclusion list transaction exclusion. <ul> <li>Inclusion list transactions proposed at <code>slot N</code> may be satisfied in the same slot (e.g., by being included in the <code>ExecutionPayload</code>). This is a side effect of validators using <code>mev-boost</code> because they don’t know the contents of the block they propose.</li> <li>Due to this, there exists an exclusion field, a node looks at each transaction in the payload’s <code>inclusion_list_exclusion</code> field and makes sure it matches with a transaction in the current inclusion list. When there’s a match, we remove that transaction from the inclusion list summary.</li> </ul> </li> <li><code>mev-boost</code> compatibility. <ul> <li>There are no significant changes to <code>mev-boost</code>. Like any other hard fork, <code>mev-boost</code>, relays, and builders must adjust their beacon nodes.</li> <li>Builders must know that execution payloads that don’t satisfy the inclusion list summary will be invalid.</li> <li>Relays may have additional duties to verify such constraints before passing them to validators for signing.</li> <li>When receiving the header, validators can check that the <code>inclusion_list_summary_root</code> matches their local version and skip building a block if there’s a mismatch, using the local block instead.</li> </ul> </li> <li>Syncing using by range or by root. <ul> <li>To consider a block valid, a node syncing to the latest head must also have an inclusion list.</li> <li>A block without an inclusion list cannot be processed during syncing.</li> <li>To address this, there is a parameter called <code>MIN_SLOTS_FOR_INCLUSION_LIST_REQUEST</code>. A node can skip inclusion list checks if the block’s slot plus this parameter is lower than the current slot.</li> <li>This is similar to <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>, where a node skips blob sidecar data availability checks if it’s outside the retention window.</li> </ul> </li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The main potential issue is around the incentivization of the inclusion lists. If the <code>slot N</code> proposer constructs an inclusion list that negatively impacts the rewards of the <code>slot N+1</code> proposer, the <code>slot N+1</code> proposer may attempt to bribe the <code>slot N</code> proposer to publish an empty list. This isn't a direct attack on the protocol, but rather a profit-sharing mechanism by which the inclusion list would go unutilized. It seems likely these commitment games could be played no matter the censorship resistance scheme in place, but this remains an active area of research.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-10-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 1m1https://github.com/1m1-github https://wg-eips.ritovision.com/7543/

This EIP adds OPCODEs to allow arbitrary precision decimal float calculation of all elementary functions with precise gas enumeration.

<h2 id="abstract">Abstract</h2> <p>This EIP adds <em>arbitrary precision decimal float</em> OPCODEs for arithmetic via DECADD, DECNEG, DECMUL, DECINV and expression of all elementary functions via DECEXP, DECLN, DECSIN. All decimal values upto the maximal precision allowed by a int256 coefficient and exponent are represented exactly, as c*10^q. All implemented algorithms converge for all inputs given enough precision, as chosen by the user. All calculations are deterministic and gas is precisely embedded bottom-up. Allowing arbitrary precision decimal elementary functions invites the worlds of mathematical finance, machine learning, science, digital art, games and others to Ethereum. The implementation is functional.</p> <h2 id="motivation">Motivation</h2> <p>Currently, to take a power, a^b, of non integer values, requires vast amounts of Solidity code. The simplest task in trading e.g. is to convert volatilities from yearly to daily, which involves taking the 16th root.</p> <p>Giving users/devs the same ability that scientific calculators have allows for the creation of apps with higher complexity.</p> <p>The files <a href="https://wg-eips.ritovision.com/7543/./assets/BlackScholes.yul">BlackScholes.yul</a> and <a href="https://wg-eips.ritovision.com/7543/./assets/Neuron.yul">Neuron.yul</a> demonstrate how these OPCODEs simplify numerical smart contract code.</p> <h3 id="why-decimal">Why decimal?</h3> <p>To represent a simple value like 0.1 in binary requires infinite many digits and is therefore not exactly represently in a finite binary machine. Decimal types are much closer to the vast majority of numerical calculations run by humans.</p> <h3 id="evm">eVm</h3> <p>The EVM is a virtual machine and thereby not restricted by hardware. Usually, assembly languages provide OPCODES that are mimic the ability of hardware. In a virtual machine, we have no such limitations and nothing stops us from adding more complex OPCODEs, as long as fair gas is provided. At the same time, we do not want to clutter the OPCODEs library. EXP, LN and SIN are universal functions that open the path to: powers, trigonometry, integrals, differential equations, machine learning, digital art, etc.</p> <h2 id="specification">Specification</h2> <h3 id="decimal">Decimal</h3> <p>A decimal is defined as</p> <p>c * 10^q</p> <p>where c and q are int256.</p> <p>Notationwise: a = ac * 10^aq b = bc * 10^bq etc.</p> <h3 id="opcode-defs">OPCODE defs</h3> <p>0xd0 DECADD a+b -&gt; c : (ac, aq, bc, bq, precision) -&gt; (cc, cq) 0xd1 DECNEG -a -&gt; b : (ac, aq) -&gt; (bc, bq) 0xd2 DECMUL a*b -&gt; c : (ac, aq, bc, bq, precision) -&gt; (cc, cq) 0xd3 DECINV 1/a -&gt; b : (ac, aq, precision) -&gt; (bc, bq) 0xd4 DECEXP exp(a) -&gt; b : (ac, aq, precision, steps) -&gt; (bc, bq) 0xd5 DECLN ln(a) -&gt; b : (ac, aq, precision, steps) -&gt; (bc, bq) 0xd6 DECSIN sin(a) -&gt; b : (ac, aq, precision, steps) -&gt; (bc, bq)</p> <p><code>precision</code> is the # of digits kept during all calculations. <code>steps</code> for DECEXP and DECSIN are the # of Taylor expansion steps. <code>steps</code> for DECLN is the depth of the continued fractions expansion.</p> <h3 id="why-these-functions">Why these functions?</h3> <p>The proposed functions (+,-,*,/,exp,ln,sin) form a small set that combined enable all calculation of all elementary functions, which includes the sets of sums, products, roots and compositions of finitely many polynomial, rational, trigonometric, hyperbolic, and exponential functions, including their inverse functions.</p> <p>a^b = exp(b * ln(a)) gives us powers and polynomials. cos(a) = sin(tau/4-a), tan(a)=sin(a)/cos(a), etc., gives us all of trigonometry.</p> <p>Together with arithmetic, we get all elementary functions.</p> <h3 id="decneg-instead-of-decsub">DECNEG instead of DECSUB</h3> <p>Negation is a more general operation vs subtraction. OPCODEs should be as fundamental as possible and as complex as desirable. For the same reason, we have DECINV instead of DECDIV.</p> <p>DECSUB(a,b) = DECADD(a,DECNEG(b)) DECDIV(a,b) = DECMUL(a,DECINV(b))</p> <h3 id="decexp-decsin-via-taylor-series">DECEXP, DECSIN via Taylor series</h3> <p>The Taylor series of exp and sin converge everywhere and fast. The error falls as fast as the factorial of steps.</p> <h3 id="decln-via-continued-fractions">DECLN via continued fractions</h3> <p>Ln converges fast using continued fractions within the interval ]0,2]. The implementation scales the input into this interval and scales the result back correctly.</p> <p>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 and RFC 8174.</p> <h2 id="rationale">Rationale</h2> <h3 id="gas">gas</h3> <p>All the above OPCODEs are deterministic, hence the gas cost can be determined. At the same time, the calculations are complex and depend on the input.</p> <p>It is crucial to have accurate gas costs to avoid energy attacks on nodes.</p> <p>To this end, the underlying uint256 lib can be wrapped with gas accumulation, as found in the reference implementation in ../assets/eip-EVM+/uint256_wrapped.go. This gives a bottom-up approach to calculating gas, by running the OPCODE.</p> <p>Because the EVM interprator expects the gas cost before actually running the OPCODE, we are running the OPCODE twice. the first run, identical to the second, is to get the bottom-up gas cost, which is then doubled to account for the actual run plus the gas calculation. On top, we add a fixed emulation cost.</p> <p>This gives an embedded gas calculation, which works well for complex OPCODEs (see gasEVMPlusEmulate in ../assets/eip-EVM+/gasEVMPlusEmulate.go).</p> <p>To remove the double gas, we could find an upper bound on gas usage dependent on the function inputs. Alternatively, a future EIP would suggest the following: allow contract code to run whilst accumulating gas (at runtime) and panicking in case of limit breach, without requiring the cost in advance. This only works for contract code that is pure, defined as code that only depends on the user input and the inner bytecode of the contract. Pure contracts cannot use state from the chain, nor make calls to other contracts. pure mathematical functions would e.g. be pure contracts. pure contracts are fully deterministic given the input, allowing a user to estimate gas costs offline (cheaper) and the EVM to panic at runtime, without knowing gas in advance.</p> <p>Since the costs depend on the input, a fuzzing would give us close to the worst cases (TODO).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <p>Since the EVM allows contracts to deploy with invalid code, there could be previously invalid code that becomes valid when adding a new OPCODE. The EVM could be designed to expect a version tag at the beginning of all bytecode or (not xor) to only deploy valid code. This is an issue for any new OPCODE.</p> <h2 id="test-cases">Test Cases</h2> <p>../assets/eip-EVM+/decimal_float_test.go</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>The reference implementation is found in ../assets/eip-EVM+/decimal_float.go</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no security considerations, as long as numerical correctness is guaranteed and gas is collected fairly.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-10-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Diederik Loerakkerhttps://github.com/protolambda https://wg-eips.ritovision.com/7545/

Add a precompile to help dapps verify verkle proofs

<h2 id="abstract">Abstract</h2> <p>This EIP proposes the addition of a precompiled contract to provide up-to-date state proof verification capabilities to smart contracts in a stateless Ethereum context.</p> <h2 id="motivation">Motivation</h2> <p>The proposed proof systems for stateless Ethereum require an upgrade to many tools and applications, that need a simple path to keep their proving systems up-to-date, without having to develop and deploy new proving libraries each time another proof format must be supported.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>A precompiled contract is added at address <code>0x21</code>, wrapping the stateless ethereum proof verification function.</p> <p>The precompile's <code>input</code> is the tightly packed concatenation of the following fields:</p> <ul> <li><code>version</code> (1 byte) specifies which version of the stateless proof verification function should be used. Version 0 is used for an MPT and version 1 is used for the polynomial commitment scheme multiproof used in <a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a>.</li> <li><code>state_root</code> (32 bytes) specifies the state root that the proof is proving against.</li> <li><code>proof_data</code> (arbitrary long) is the proof data.</li> </ul> <p>Pseudo-code behavior of the precompile:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> proof_verification_precompile</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> version</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span> state_root</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">1</span><span>:</span><span class="z-constant">33</span><span>]</span></span> <span class="giallo-l"><span> proof_data</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">33</span><span>:</span><span class="z-constant">33</span><span class="z-keyword">+</span><span>proof_data_size</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> version</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> proof</span><span class="z-keyword"> =</span><span> deserialize_proof</span><span>(</span><span>state_root</span><span>,</span><span> proof_data</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> verify_mpt_multiproof</span><span>(</span><span>proof</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> version</span><span class="z-keyword"> ==</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span> proof</span><span class="z-keyword"> =</span><span> deserialize_proof</span><span>(</span><span>state_root</span><span>,</span><span> proof_data</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> verify_pcs_multiproof</span><span>(</span><span>proof</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span></code></pre> <p>If <code>version</code> is <code>0</code> then the proof is expected to follow the SSZ format described in "the verge" proposal in the consensus spec.</p> <p>The precompile returns <code>1</code> if it was able to verify the proof, and <code>0</code> otherwise.</p> <h3 id="gas-costs">Gas costs</h3> <table><thead><tr><th>Constant name</th><th>cost</th></tr></thead><tbody> <tr><td><code>POINT_COST</code></td><td>TBD</td></tr> <tr><td><code>POLY_EVAL_COST</code></td><td>TBD</td></tr> </tbody></table> <p>The precompile cost is:</p> <p><code>cost = (POINT_COST + 1)*len(get_commitments(input)) + POLY_EVAL_COST * [leaf_depth(key, get_tree(input)) for key in get_keys(input))]</code></p> <p>where:</p> <ul> <li><code>get_commitments</code> extracts the list of commitments in the proof, as encoded in <code>input</code></li> <li><code>get_keys</code> extracts the list of keys in the proof, as encoded in <code>input</code></li> <li><code>leaf_depth</code> returns the depth of the leaf in the tree</li> <li><code>get tree</code> reconstruct a stateless view of the tree from <code>input</code></li> </ul> <h2 id="rationale">Rationale</h2> <p>Stateless Ethereum relies on proofs using advanced mathematical concepts and tools from a fast-moving area of cryptography. As a result, a soft-fork approach is currently favored in the choice of the proof format: proofs are going to be distributed outside of consensus, and in the future, stateless clients will be able to chose their favorite proof format.</p> <p>This introduces a burden on several application, e.g. bridges, as they will potentially need to support proof formats designed after the release of the bridge contract.</p> <p>Delegating the proof verification burden to a version-aware precompile will ensure that these applications can support newer proving primitives without having to upgrade their contracts.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>WIP</p> <ul> <li>First implementation in Optimism, pull request #192 of ethereum-optimism/op-geth by @protolambda</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-10-01T00:00:00+00:00 2026-02-11T14:49:28+00:00 Yoav Weisshttps://github.com/yoavw Alex Forshtathttps://github.com/forshtat Dror Tiroshhttps://github.com/drortirosh Shahaf Nacsonhttps://github.com/shahafn https://wg-eips.ritovision.com/7557/

Block-level warming of addresses and slots with access lists

<h2 id="abstract">Abstract</h2> <p>A mechanism for a fair distribution of the gas costs associated with access to addresses and storage slots among multiple transactions with shared items in their <code>accessList</code>.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/2929/">EIP-2929: Gas cost increases for state access opcodes</a> introduced a new gas cost model that differentiates between "cold" and "warm" access to accounts and storage slots.</p> <p>However, the cost of every cold access is borne by each transaction separately, even though the validator only needs to fetch the state object once for the entire block.</p> <p>When multiple transactions access the same state object in the same block the fees charged for these transactions do not accurately reflect the computations that block builders and validators perform for the blockchain state access during transaction execution.</p> <p><a href="https://wg-eips.ritovision.com/2930/">EIP-2930: Optional access lists</a> made it possible for transactions to pre-specify and pre-pay for the accounts and storage slots that the transaction plans to access, however, the cost is still paid repeatedly by each transaction rather than once at the block level.</p> <p>With the <a href="https://wg-eips.ritovision.com/6800/">EIP-6800: Ethereum state using a unified verkle tree</a> on the roadmap for inclusion, the cost of reading from the Ethereum state and especially the contract code is expected to increase.</p> <p>Especially affected by this upcoming change will be transactions that involve smart contracts with a high code size.</p> <p>Each such transaction in the block will be forced to pay the full "retail" price for loading smart contract bytecode during a transaction.</p> <p>The validators, however, only have to perform the actual reading from the Ethereum state once per block, and all subsequent reads of the values that were already referenced are significantly more efficient.</p> <p>If witnesses are introduced to Ethereum blocks, the same witness can be reused by multiple transactions. Requiring each transaction to pay regardless of the contents of the block is unfair and inefficient.</p> <p>Another change that may be on the roadmap for Ethereum is Account Abstraction. This change will see a large share of transactions being initiated by smart contracts directly. It is reasonable to expect many of these Smart Contract Accounts to rely on the same core wallet implementations. If each Account Abstraction transaction is charged a full gas cost of loading the Smart Contract Account code repeatedly, such transactions would become significantly overpriced.</p> <p>This difference is especially noticeable when compared to an EOA, which gets its validation logic loaded and executed for free.</p> <p>In this scenario, the base gas fees would be taken from the senders and burned needlessly while block proposers would be enjoying an unjustified excessive earning of priority gas fees.</p> <p>A major distinction between this proposal and alternatives, such as <a href="https://wg-eips.ritovision.com/7863/">EIP-7863</a>, lies in performing a fair distribution of gas savings between all participants - all transactions senders and the block builder.</p> <h2 id="specification">Specification</h2> <p>The <a href="https://wg-eips.ritovision.com/2930/">EIP-2930: Optional access lists</a> already introduced the first part of the solution. Each transaction can specify an array of <code>accessed_addresses</code> and <code>accessed_storage_keys</code> to announce its intention to read those values during the execution of the transaction.</p> <p>The sender of the transaction is then pre-charged with the cost of accessing this data but is given a small discount compared to unannounced access.</p> <p>The missing component is a mechanism to aggregate the gas costs of the cold access and redistribute the resulting savings amongst the participating transactions.</p> <h3 id="overview">Overview</h3> <p>During the transaction execution, the cost of all storage-related operations is not affected, and all rules from EIP-2929 and EIP-2930 continue to apply.</p> <p>There are no changes to the block header or the transaction payload and receipt.</p> <p>As the last operation of each block, the collected gas costs associated with storage access are redistributed among the senders of all transactions withing a block. This affects the balances of all these accounts in a way that only becomes observable in the next block.</p> <p>This reimbursement's amount is proportional to the amount paid for the access in the first place.</p> <h3 id="participant-transactions-mapping">Participant transactions mapping</h3> <p>After the block builder finalizes the contents of the block, it iterates over all included transactions to read the <code>accessList</code> component of each supported transaction.</p> <p>The block builder then constructs an array containing each accessed address and each accessed slot, and an array of transaction senders' addresses that initiated at least one access to the given address or slot, as well as the <code>priorityFeePerGas</code> that was paid for such access.</p> <p>A sample JSON representation of the data structure that represents such a structure and is used in the pseudocode below:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>[</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">address</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">accessors</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">1000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xFFcf8FDEE72ac11b5c542428B35EEF5769C409f0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">1000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xFFcf8FDEE72ac11b5c542428B35EEF5769C409f0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x22d491Bde2303f2f43325b2108D26f1eAbA1e32b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x22d491Bde2303f2f43325b2108D26f1eAbA1e32b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">3000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">slots</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">id</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0000000000000000000000000000000000000000000000000000000000000003</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">accessors</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">1000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x22d491Bde2303f2f43325b2108D26f1eAbA1e32b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x22d491Bde2303f2f43325b2108D26f1eAbA1e32b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">3000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">id</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0000000000000000000000000000000000000000000000000000000000000007</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">accessors</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xFFcf8FDEE72ac11b5c542428B35EEF5769C409f0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">1000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sender</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xFFcf8FDEE72ac11b5c542428B35EEF5769C409f0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">priorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2000</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"></span></code></pre><h3 id="calculating-a-reimbursement-of-the-burned-base-fee">Calculating a reimbursement of the burned base fee</h3> <p>Considering that the same amount of computation is needed to access an address or a slot regardless of the number of transactions using one, it is reasonable for the protocol to only burn the gas cost of the cold access once. As all transactions in the same block pay exactly the same <code>baseFeePerGas</code>, the single cost of accessing a cold item is divided evenly among all transactions containing such access and the rest of the burned base fee is reimbursed.</p> <h3 id="setting-an-absolute-minimal-cost-of-cold-state-access">Setting an absolute minimal cost of cold state access</h3> <p>If a large number of transactions all access the same addresses or slots, the cost of each cold access may get way too low which may represent a potential DoS attack vector.</p> <p>In order to prevent that, the gas cost of including an entity in the access list cannot be lower than <code>MIN_ACCESS_LIST_ENTRY_COST</code>, which is set to <code>32 gas</code>.</p> <p>This value is equivalent to the calldata cost of including two bytes long identifier of entries in <code>block_access_list</code>.</p> <h3 id="calculating-a-reimbursement-of-the-charged-priority-fee">Calculating a reimbursement of the charged priority fee</h3> <p>Each transaction pays an individual <code>priorityFeePerGas</code> value and redistributing this part of the cold access cost is more complex.</p> <p>We propose the following approach to a fair reimbursement of the paid <code>priorityFee</code>:</p> <ol> <li> <p>The validator gets paid the <code>priorityFee</code> for each cold access only once, but according to the highest <code>priorityFee</code> among the transactions containing the said cold access.</p> </li> <li> <p>The rest of the Ether that was charged by the validator as a <code>priorityFee</code> is redistributed back to all the senders of transactions containing the same cold access in proportion to their <strong>marginal contribution</strong> to the <strong>total gains</strong> of the transaction.</p> </li> <li> <p>The block builder is only paid for access once and the remaining value is reimbursed. So the <code>total reimbursement</code> value is a difference between the sum of value charged and the block builder's reward.</p> </li> <li> <p>The <code>total gains</code> of the transaction is defined by a sum of the <code>priorityFee</code> paid out to the block builder and <code>total reimbursement</code> made to all participants.</p> </li> <li> <p>Mathematically, the <code>marginal contribution</code> of a transaction to the <code>total gains</code> is defined as the difference between the sum <code>total gains</code> value calculated when all transactions in a block are included, and when all transactions are included except for this particular transaction. In practice this value always amounts to <code>priorityFee * gasCost</code>.</p> <blockquote> <p>𝑀𝐶𝑖 = 𝑣(𝑆 ∪ {𝑖}) − 𝑣(𝑆)</p> </blockquote> </li> </ol> <p>A single transaction accessing an address or a slot that is not shared by other transactions does not trigger a reimbursement, and therefore has a zero marginal contribution.</p> <h3 id="efficiently-storing-the-access-lists-in-the-block-history">Efficiently storing the access lists in the block history</h3> <p>The contents of the <code>accessList</code> parameter are part of the Ethereum history and the potential cost of keeping this data in the blockchain must be accounted for when implementing this change. There is currently no additional charge applied to the <code>accessList</code> parameter, due to the cost of including an address or a storage slot in the <code>accessList</code> being a constant value that is significantly higher than the potential cost of storing the <code>accessList</code> at the cost of a dynamically sized <code>calldata</code> field.</p> <p>With the block-level warming there is a change that makes it possible for a transaction sender to construct transactions with a large <code>accessList</code> that cost very little to be included, and this can be used to bloat the blockchain size.</p> <p>This potential bloating of the block size also presents a challenge for the propagation of the block in a P2P network.</p> <p>In order to minimize the cost of permanently storing access lists, we propose the following changes to the <code>execution_payload</code> structure:</p> <ol> <li>Add a new <code>block_access_list</code> field.</li> </ol> <p>The execution clients create a combined block-level "access list" that contains all unique entries from all transactions in the block. 2. All individual transaction <code>accessList</code> fields replace the full entries with a compact 2 bytes long reference to the <code>block_access_list</code> in the same order they appeared originally.</p> <p>With this approach shared entries in the access lists cannot cause sufficient bloating of the block size.</p> <p>There is no need to introduce any observable changes to the RPC API as this "compression" can be unwrapped by the clients in real time.</p> <h3 id="pseudocode-implementation-of-the-reimbursement-calculation-algorithm">Pseudocode implementation of the reimbursement calculation algorithm</h3> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-keyword">export</span><span class="z-storage z-type"> function</span><span class="z-entity z-name"> calculateBlockColdAccessReimbursement</span><span> (</span></span> <span class="giallo-l"><span class="z-variable"> baseFeePerGas</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> accessDetailsMap</span><span class="z-keyword">:</span><span class="z-entity z-name"> AddressAccessDetails</span><span>[</span><span>]</span></span> <span class="giallo-l"><span>)</span><span class="z-keyword">:</span><span class="z-entity z-name"> Map</span><span>&lt;</span><span class="z-support">string</span><span>,</span><span class="z-entity z-name"> reimbursement</span><span>&gt;</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursements</span><span class="z-keyword"> =</span><span class="z-keyword"> new</span><span class="z-entity z-name"> Map</span><span>&lt;</span><span class="z-support">string</span><span>,</span><span class="z-entity z-name"> Reimbursement</span><span>&gt;</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">const</span><span class="z-variable z-other z-constant"> accessDetail</span><span class="z-keyword"> of</span><span class="z-variable z-other"> accessDetailsMap</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-entity z-name"> calculateItemColdAccessReimbursement</span><span>(</span><span class="z-variable z-other">accessDetail</span><span>.</span><span class="z-variable z-other">accessors</span><span>,</span><span class="z-variable z-other"> baseFeePerGas</span><span>,</span><span class="z-variable z-other z-constant"> COLD_ACCOUNT_ACCESS_COST</span><span>,</span><span class="z-variable z-other"> reimbursements</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">const</span><span class="z-variable z-other z-constant"> slot</span><span class="z-keyword"> of</span><span class="z-variable z-other"> accessDetail</span><span>.</span><span class="z-variable z-other">slots</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-entity z-name"> calculateItemColdAccessReimbursement</span><span>(</span><span class="z-variable z-other">slot</span><span>.</span><span class="z-variable z-other">accessors</span><span>,</span><span class="z-variable z-other"> baseFeePerGas</span><span>,</span><span class="z-variable z-other z-constant"> COLD_SLOAD_COST</span><span>,</span><span class="z-variable z-other"> reimbursements</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-other"> reimbursements</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> calculateItemColdAccessReimbursement</span><span> (</span></span> <span class="giallo-l"><span class="z-variable"> unsortedAccessors</span><span class="z-keyword">:</span><span class="z-entity z-name"> AccessDetails</span><span>[</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> baseFeePerGas</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> accessGasCost</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> reimbursements</span><span class="z-keyword">:</span><span class="z-entity z-name"> Map</span><span>&lt;</span><span class="z-support">string</span><span>,</span><span class="z-entity z-name"> Reimbursement</span><span>&gt;</span></span> <span class="giallo-l"><span>)</span><span class="z-keyword">:</span><span class="z-support"> void</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> sortedAccessDetails</span><span class="z-keyword"> =</span><span class="z-variable z-other"> unsortedAccessors</span><span>.</span><span class="z-entity z-name">sort</span><span>(</span><span>(</span><span class="z-variable">a</span><span>,</span><span class="z-variable"> b</span><span>)</span><span class="z-storage z-type"> =&gt;</span><span> {</span><span class="z-keyword"> return</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">b</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> -</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">a</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span> }</span><span>)</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> addressAccessN</span><span class="z-keyword"> =</span><span class="z-variable z-other"> sortedAccessDetails</span><span>.</span><span class="z-support z-variable">length</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursementPercent</span><span class="z-keyword"> =</span><span> (</span><span class="z-variable z-other">addressAccessN</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> /</span><span class="z-variable z-other"> addressAccessN</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursementsFromCoinbase</span><span class="z-keyword"> =</span><span class="z-entity z-name"> calculatePriorityFeeReimbursements</span><span>(</span><span class="z-variable z-other">sortedAccessDetails</span><span>,</span><span class="z-variable z-other"> accessGasCost</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">let</span><span class="z-variable z-other"> i</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword"> &lt;</span><span class="z-variable z-other"> sortedAccessDetails</span><span>.</span><span class="z-support z-variable">length</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword">++</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> accessor</span><span class="z-keyword"> =</span><span class="z-variable z-other"> sortedAccessDetails</span><span>[</span><span class="z-variable z-other">i</span><span>]</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursement</span><span class="z-keyword"> =</span><span class="z-variable z-other"> reimbursements</span><span>.</span><span class="z-entity z-name">get</span><span>(</span><span class="z-variable z-other">accessor</span><span>.</span><span class="z-variable z-other">sender</span><span>)</span><span class="z-keyword"> ??</span><span> {</span><span> reimbursementFromBurn</span><span>:</span><span class="z-constant"> 0</span><span class="z-storage z-type">n</span><span>,</span><span> reimbursementFromCoinbase</span><span>:</span><span class="z-constant"> 0</span><span class="z-storage z-type">n</span><span> }</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> adjustedAccessGasCost</span><span class="z-keyword"> =</span><span class="z-variable z-other"> Math</span><span>.</span><span class="z-entity z-name">max</span><span>(</span><span class="z-variable z-other z-constant">MIN_ACCESS_LIST_ENTRY_COST</span><span>,</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">accessGasCost</span><span>)</span><span class="z-keyword"> *</span><span class="z-variable z-other"> reimbursementPercent</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursement</span><span>.</span><span class="z-variable z-other">reimbursementFromBurn</span><span class="z-keyword"> +=</span><span class="z-entity z-name"> BigInt</span><span>(</span><span class="z-variable z-other">adjustedAccessGasCost</span><span class="z-keyword"> *</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">baseFeePerGas</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursement</span><span>.</span><span class="z-variable z-other">reimbursementFromCoinbase</span><span class="z-keyword"> +=</span><span class="z-entity z-name"> BigInt</span><span>(</span><span class="z-variable z-other">reimbursementsFromCoinbase</span><span>[</span><span class="z-variable z-other">i</span><span>]</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursements</span><span>.</span><span class="z-entity z-name">set</span><span>(</span><span class="z-variable z-other">accessor</span><span>.</span><span class="z-variable z-other">sender</span><span>,</span><span class="z-variable z-other"> reimbursement</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">export</span><span class="z-storage z-type"> function</span><span class="z-entity z-name"> calculatePriorityFeeReimbursements</span><span> (</span><span class="z-variable">sortedAccesses</span><span class="z-keyword">:</span><span class="z-entity z-name"> AccessDetails</span><span>[</span><span>]</span><span>,</span><span class="z-variable"> accessGasCost</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Validator charge is based on the highest paid priority fee per gas</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> validatorFee</span><span class="z-keyword"> =</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>[</span><span class="z-constant">0</span><span>]</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> *</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">accessGasCost</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Accumulate the sum of all &quot;contributions&quot;, at least the top transaction contribution</span></span> <span class="giallo-l"><span class="z-storage z-type"> let</span><span class="z-variable z-other"> totalContributions</span><span class="z-keyword"> =</span><span class="z-variable z-other"> validatorFee</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Accumulate cost of gas paid to validator for accessing the same address/slot/chunk</span></span> <span class="giallo-l"><span class="z-storage z-type"> let</span><span class="z-variable z-other"> totalSendersCharged</span><span class="z-keyword"> =</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>[</span><span class="z-constant">0</span><span>]</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> *</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">accessGasCost</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Starting with `1` as element at `0` is explicitly shown here to be used as `validatorFee`</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">let</span><span class="z-variable z-other"> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword"> &lt;</span><span class="z-variable z-other"> sortedAccesses</span><span>.</span><span class="z-support z-variable">length</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword">++</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> charge</span><span class="z-keyword"> =</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>[</span><span class="z-variable z-other">i</span><span>]</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> *</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">accessGasCost</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> totalContributions</span><span class="z-keyword"> +=</span><span class="z-variable z-other"> charge</span></span> <span class="giallo-l"><span class="z-variable z-other"> totalSendersCharged</span><span class="z-keyword"> +=</span><span class="z-variable z-other"> charge</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Calculate the total amount of ether to be reimbursed for this access</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> totalReimbursement</span><span class="z-keyword"> =</span><span class="z-variable z-other"> totalSendersCharged</span><span class="z-keyword"> -</span><span class="z-variable z-other"> validatorFee</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">totalReimbursement</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> possible if only single transaction or if all priority fees are 0</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-entity z-name"> Array</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>.</span><span class="z-support z-variable">length</span><span>)</span><span>.</span><span class="z-entity z-name">fill</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Calculate actual charges and reimbursements</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursements</span><span class="z-keyword"> =</span><span> [</span><span class="z-variable z-other">Math</span><span>.</span><span class="z-entity z-name">floor</span><span>(</span><span class="z-variable z-other">totalReimbursement</span><span class="z-keyword"> *</span><span class="z-variable z-other"> topTransactionContribution</span><span class="z-keyword"> /</span><span class="z-variable z-other"> totalContributions</span><span>)</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">let</span><span class="z-variable z-other"> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword"> &lt;</span><span class="z-variable z-other"> sortedAccesses</span><span>.</span><span class="z-support z-variable">length</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword">++</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> charge</span><span class="z-keyword"> =</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>[</span><span class="z-variable z-other">i</span><span>]</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> *</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">accessGasCost</span><span>)</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> calldataCharge</span><span class="z-keyword"> =</span><span class="z-entity z-name"> parseInt</span><span>(</span><span class="z-variable z-other">sortedAccesses</span><span>[</span><span class="z-variable z-other">i</span><span>]</span><span>.</span><span class="z-variable z-other">priorityFeePerGas</span><span>)</span><span class="z-keyword"> *</span><span class="z-variable z-other z-constant"> MIN_ACCESS_LIST_ENTRY_COST</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursementToCalldata</span><span class="z-keyword"> =</span><span class="z-variable z-other"> charge</span><span class="z-keyword"> -</span><span class="z-variable z-other"> calldataCharge</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursementToContribution</span><span class="z-keyword"> =</span><span class="z-variable z-other"> Math</span><span>.</span><span class="z-entity z-name">floor</span><span>(</span><span class="z-variable z-other">totalReimbursement</span><span class="z-keyword"> *</span><span class="z-variable z-other"> charge</span><span class="z-keyword"> /</span><span class="z-variable z-other"> totalContributions</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursements</span><span>.</span><span class="z-entity z-name">push</span><span>(</span><span class="z-variable z-other">Math</span><span>.</span><span class="z-entity z-name">min</span><span>(</span><span class="z-variable z-other">reimbursementToCalldata</span><span>,</span><span class="z-variable z-other"> reimbursementToContribution</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-other"> reimbursements</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Note that two accumulating values, <code>reimbursementFromBurn</code> and <code>reimbursementFromCoinbase</code>, are necessary in light of <a href="https://wg-eips.ritovision.com/1559/">EIP-1559: Fee market change for ETH 1.0 chain</a> in order to differentiate between the Ether reimbursement that is originating from a reduced block gas burn, and from the reduced block proposer priority fee per gas reward.</p> <h3 id="future-eip-6800-gas-reform-support">Future EIP-6800 gas reform support</h3> <p>Once <a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a> is active, the cost of accessing a contract code for a cold address is expected to change.</p> <p>Instead of being a constant value of <code>COLD_ACCOUNT_ACCESS_COST</code> (currently 2600 gas), the total cost will be determined by the number of 31-byte "chunks" the code consists of. Each "chunk" of code will have a cost of <code>CODE_CHUNK_ACCESS_COST</code> (currently 200 gas).</p> <p>For a maximum contract size of <code>24576 bytes</code> defined by <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> the cost of accessing this contract surges from <code>2600</code> to <code>158600</code> gas.</p> <p>This change will likely require the <code>accessList</code> parameter of transactions to be adjusted for transactions to be able to specify which code chunks will be accessed.</p> <p>In such case the changes are reflected in the reimbursement function as well, which is updated by adding the following code in order to redistribute the shared cost of accessing the same code chunk in multiple transactions:</p> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-storage z-type">const</span><span class="z-variable z-other z-constant"> reimbursementsFromCoinbase</span><span class="z-keyword"> =</span><span class="z-entity z-name"> calculatePriorityFeeReimbursements</span><span>(</span><span class="z-variable z-other">sortedCodeChunkAccessDetails</span><span>,</span><span class="z-variable z-other z-constant"> CHUNK_ACCESS_COST</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">for</span><span> (</span><span class="z-storage z-type">let</span><span class="z-variable z-other"> i</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword"> &lt;</span><span class="z-variable z-other"> sortedAccessDetails</span><span>.</span><span class="z-support z-variable">length</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword">++</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> reimbursement</span><span class="z-keyword"> =</span><span class="z-variable z-other"> reimbursements</span><span>.</span><span class="z-entity z-name">get</span><span>(</span><span class="z-variable z-other">accessor</span><span>.</span><span class="z-variable z-other">sender</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursement</span><span>.</span><span class="z-variable z-other">reimbursementFromBurn</span><span class="z-keyword"> +=</span><span class="z-variable z-other z-constant"> CHUNK_ACCESS_COST</span><span class="z-keyword"> *</span><span class="z-variable z-other"> block</span><span>.</span><span class="z-variable z-other">baseFeePerGas</span><span class="z-keyword"> *</span><span class="z-variable z-other"> reimbursementPercent</span></span> <span class="giallo-l"><span class="z-variable z-other"> reimbursement</span><span>.</span><span class="z-variable z-other">reimbursementFromCoinbase</span><span class="z-keyword"> +=</span><span class="z-variable z-other"> reimbursementsFromCoinbase</span><span>[</span><span class="z-variable z-other">i</span><span>]</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="cost-redistribution-system-operation">Cost redistribution system operation</h3> <p>The <a href="https://wg-eips.ritovision.com/4895/">EIP-4895: Beacon chain push withdrawals as operations</a> sets a precedent by introducing a concept of a <code>system-level withdrawal operation</code>.</p> <p>We propose the introduction of yet another system-level operation called <code>cost redistribution</code>. The <code>redistributions</code> in an execution payload are processed after any user-level transactions are applied.</p> <p>The block builder or a validator prepares a list of reimbursement information.</p> <p>For each <code>redistribution</code> in the list, the implementation increases the balance of the address specified by the amount <code>reimbursementFromBurn + reimbursementFromCoinbase</code>.</p> <p>The balance of the <code>coinbase</code> is reduced by a sum of all <code>reimbursementFromCoinbase</code> values.</p> <h2 id="rationale">Rationale</h2> <h3 id="current-cold-storage-gas-cost-is-unfair">Current cold storage gas cost is unfair</h3> <p>As described in the <a href="https://wg-eips.ritovision.com/7557/#motivation">Motivation</a> section, the amount of gas that users spend on accessing the contract code does not reflect the actual cost of this access for the block builder or a validator.</p> <p>The more popular the contract code or a storage slot is, the more transactions in each block should share the cost. However, the current system multiplies the cost for the users instead of dividing it.</p> <h3 id="issuing-a-regular-gas-refund-after-a-transaction-is-not-possible">Issuing a regular gas refund after a transaction is not possible</h3> <p>There exists a list of EVM instructions that trigger both a gas charge and a gas refund. A notable example of such operations is the <code>0x55 SSTORE</code> opcode as defined in <a href="https://wg-eips.ritovision.com/1283/">EIP-1283: Net gas metering for SSTORE without dirty maps</a>. Intuitively it seems reasonable to issue the gas reimbursements for the shared cold storage access in the same fashion.</p> <p>However, this approach significantly complicates the block-building process. In this case, the inclusion or exclusion of a transaction at the end of the block triggers observable effects in transactions included at the beginning of the block, and this makes the job of finding a valid set of transactions for a block potentially computationally unsolvable.</p> <p>Therefore, we propose performing the reimbursements at the end of the block, where it cannot change the behavior of any transaction in the block.</p> <h3 id="weighting-priority-fee-reimbursement">Weighting priority fee reimbursement</h3> <p>A common game-theoretical answer to the problem of calculating a fair redistribution of the payoff of the results of the participants' cooperation is the use of Shapley values.</p> <p>However, we argue that the proposed distribution of the <code>priorityFee</code> reimbursements is sufficiently fair while being a lot easier to compute or articulate.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal does not introduce a change to any behavior that can be observed by a smart contract during its execution. The only effect this change has is a lower effective gas cost for the transaction senders.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The upper limit of storage reads in one block is not affected by this change as the gas charge is done with the full cost of <code>COLD_ACCOUNT_ACCESS_COST</code> or <code>COLD_SLOAD_COST</code>.</p> <p>The maximum amount of memory and computation required to calculate the reimbursements according to the specified algorithm is insignificant.</p> <p>It appears that this change does not have any negative security implications.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-09-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Peter Davieshttps://github.com/petertdavies https://wg-eips.ritovision.com/7523/

Prohibit empty accounts on post-merge networks

<h2 id="abstract">Abstract</h2> <p>This EIP prohibits the state of any post-merge network from containing empty accounts. Since no empty accounts exist outside the testsuite and no new ones can be created this requirement is already achieved in practice. An explicit ban reduces technical debt going forward.</p> <h2 id="motivation">Motivation</h2> <p>The possibility of empty accounts is a historical artifact of the early history of Ethereum. The only networks that have ever been capable of containing them are Ethereum Mainnet, the deprecated testnet Ropsten, Etheruem Classic Mainnet and various Ethereum Classic testnets. All remaining empty accounts on Mainnet were cleared in block <code>14049881</code> (transaction <code>0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d</code>) and a similar transaction was sent on Ethereum Classic. None of the other myriad EVM-compatible networks are old enough to have empty accounts and there is no realistic prospect that anyone will encounter an empty account in a production context.</p> <p>Despite empty accounts no longer existing, they still impose a legacy of technical debt. <a href="https://wg-eips.ritovision.com/161/">EIP-161</a> imposes complicated rules that require a client to delete an empty account when it is "touched". As the Ethereum specification continues to evolve new edgecases of the "touch" rules arise which must be debated, implemented, tested and documented. If a future client wishes to only support post-merge blocks it must implement unnecessary empty account support solely to pass the test suite.</p> <p>By prohibiting empty accounts on post-merge networks, this EIP frees designers and implementers of Ethereum and related blockchains from the burden of having to consider them going forward.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>An empty account is an account with has <strong>no code</strong> and <strong>zero nonce</strong> and <strong>zero balance</strong>. This is the same as the definition in <a href="https://wg-eips.ritovision.com/161/">EIP-161</a>.</p> <p>On networks that undergo the merge transition, the pre state of the merge block may not contain any empty accounts. For networks that are merged at genesis, none of the genesis accounts may be empty accounts.</p> <p>Rather than performing a scan of the state, clients MAY assume the following chains have no post-merge empty accounts:</p> <ol> <li> <p>The Mainnet chain whose merge block has hash <code>0x56a9bb0302da44b8c0b3df540781424684c3af04d0b7a38d72842b762076a664</code>.</p> </li> <li> <p>Any chain which satisfies all of the following:</p> <ul> <li> <p>has no empty accounts in the genesis.</p> </li> <li> <p>had a post Spurious Dragon fork at genesis.</p> </li> </ul> </li> </ol> <p>The Ethereum specification is declared to be undefined in the presence of an empty account in a post-merge context. Any testcase involving post-merge empty accounts is invalid.</p> <h2 id="rationale">Rationale</h2> <p>This EIP was drafted to be the simplest possible way of eliminating the long term technical debt imposed by empty accounts. The Merge was chosen as a natural easily identifiable cutoff point.</p> <p>Alternative approaches include:</p> <ul> <li> <p>Using an earlier cutoff point, such as block <code>14049881</code>.</p> </li> <li> <p>Identifying a wider range of edge case behaviour that never happened.</p> </li> </ul> <p>These approaches were rejected as being unnecessarily complicated.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As EIP does not change any behaviour that can occur outside the testsuite, it has no backwards compatibility consequences.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The validity of this EIP is dependent on the assertion that all empty accounts on Ethereum Mainnet were cleared prior to the merge. This should be subject to appropriate verification.</p> <p>Any networks artificially created with empty accounts will cause problems with tooling and clients.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-09-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/7519/

Add atomic operations for incrementing and decrementing storage slots

<h2 id="abstract">Abstract</h2> <p>Two new opcodes that atomically mutate smart contract storage are proposed: SCREDIT, which increments a storage slot by a specified value, and SDEBIT, which decrements a storage slot by a specified value. Overflow and underflow errors are enforced, reverting when an unsigned 256-bit integer would overflow or underflow.</p> <h2 id="motivation">Motivation</h2> <p>There has been a large amount of energy around parallel EVMs across multiple chains, however there is a lack of parallel primitives within the EVM to support any model other than optimistic concurrency control (OCC). By adding concurrent increment and decrement operations more advanced parallel environments can be introduced in Layer 2 networks.</p> <p>This also provides the opportunity to serve the principal use case of increment and decrement: token balances. We can introduce failures on overflow and underflow conditions and provide an operation that is also useful outside of parallel use cases.</p> <h2 id="specification">Specification</h2> <p>Two operations to atomically increment and decrement a storage will be introduced at <code>0xTBD</code>. Each operation takes two stack arguments and has no immediate arguments. Gas schedule will be the same as SSTORE.</p> <table><thead><tr><th>Mnemonic</th><th>Op</th><th>Input</th><th>Output</th></tr></thead><tbody> <tr><td><code>SCREDIT</code></td><td><code>0xTBD</code></td><td><code>2</code></td><td><code>0</code></td></tr> <tr><td><code>SDEBIT</code></td><td><code>0xTBD+1</code></td><td><code>2</code></td><td><code>0</code></td></tr> </tbody></table> <h3 id="scredit">SCREDIT</h3> <p><code>SCREDIT: slot, value</code></p> <h4 id="description">Description</h4> <p>Adds <code>value</code> to the value stored in contract storage <code>slot.</code> If an overflow would occur the operation halts exceptionally.</p> <h4 id="gas-charging">Gas Charging</h4> <p>Gas charging is identical to SSTORE. including interactions with the warm storage slot list. Any future modifications to the SSTORE gas charges will also apply to SCREDIT.</p> <h4 id="execution">Execution</h4> <p><em>Not valid python, not suitable for EELS yet</em></p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>slot = evm_stack.pop()</span></span> <span class="giallo-l"><span>value = evm_stack.pop()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>storage_value = read_contract_storage(slot)</span></span> <span class="giallo-l"><span>storage_value = storage_value + value</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if storage_value &gt;= 2**256 :</span></span> <span class="giallo-l"><span> raise Exception(&quot;scredit overflow&quot;)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>write_contract_storage(storage_value)</span></span></code></pre><h3 id="sdebit">SDEBIT</h3> <p><code>SDEBIT: slot, value</code></p> <h4 id="description-1">Description</h4> <p>Subtracts <code>value</code> to the value stored in contract storage <code>slot.</code> If an underflow would occur the operation halts exceptionally.</p> <h4 id="gas-charging-1">Gas Charging</h4> <p>Gas charging is identical to SSTORE, including interactions with the warm storage slot list. Any future modifications to the SSTORE gas charges will also apply to SDEBIT.</p> <h4 id="execution-1">Execution</h4> <p><em>Not valid python, not suitable for EELS yet</em></p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>slot = evm_stack.pop()</span></span> <span class="giallo-l"><span>value = evm_stack.pop()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>storage_value = read_contract_storage(slot)</span></span> <span class="giallo-l"><span>storage_value = storage_value - value</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if storage_value &lt; 0 :</span></span> <span class="giallo-l"><span> raise Exception(&quot;sdebit underflow&quot;)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>write_contract_storage(storage_value)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The primary consideration when choosing between alternatives is that the primary intended audiences is token contracts and other asset-tracking contracts combined with a desire to ship the minimum necessary changes to enable that use case. General concurrency controls is not a goal of this EIP.</p> <h3 id="enforcing-overflow-semantics">Enforcing Overflow Semantics</h3> <p>When allowing for out-of-order execution there needs to be mechanism to handle any possible order of execution. OCC handles this by validating pre- and post-conditions, and re-evaluating the transactions if those invariants did not hold. This technique breaks down around writing to balances and counters.</p> <p>Increment/decrement with rollover checking allows for simple handling of balances and counters while allowing for functional read support ensuring that sufficient balance or count exists without depending on the exact values. This allows for evaluation models where the only post-condition checked is to validate that the storage slots could handle all possible re-ordering of transactions.</p> <h3 id="gas-schedule">Gas Schedule</h3> <p>The decision to cost the operations at the exact same value as SSTORE is partly for ease of implementation and partly as an incentive to compilers and developers.</p> <p>These semantics could be implemented in the EVM today, but it would also include a SLOAD, DUP, LT, JUMPI and REVERT instructions. The EVM, however, can do these operations much more efficiently than via opcodes. First, each SSTORE always incurs a slot load in order to apply <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> gas calculation rules. This load is essential if there is no paired SLOAD. Math libraries for 256-bit numbers can all easily be made sensitive to overflow and underflow, if they are not already present. Conditional logic handling is also much faster in the operation logic as most of the overhead would be operation parsing and stack management when interpreted.</p> <p>The net impact of the most relevant operations to the most expensive evaluation (an ADD and LT operation, above the cost of a plain SSTORE) would be 4 gas, or 0.2% of the current cost of a SSTORE. Finally, database access costs dominate the real cost of the operation. A 0.2% overhead may disappear in I/O stalls.</p> <p>Keeping the cost the same makes implementations of gas charging vert simple.</p> <h3 id="storage-slots-only">Storage Slots Only</h3> <p>This most important use case for this EIP asset balances and not general concurrency controls. Hence, only enabling credit and debit operations on storage slots (which persist across transactions). Parallel execution within a transaction and more generic tools like locks and semaphores have very limited utility within this scope. The lack of in-transaction parallel execution also precludes the use of such primitives against transient storage (as defined in <a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a>).</p> <h3 id="opcode-instead-of-system-contract">Opcode Instead of System Contract</h3> <p>One alternative, particularly viable for Layer 2 chains, would be to implement SCREDIT and SDEBIT as system contracts. The primary objection to system contracts for other operations is the gas cost overhead of constructing a call. Because a SSTORE is always greater than the cost of a call it would be possible to build in a discount. However, there is no such accommodation that can be made for the code size needed to invoke such a call.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These opcodes are not simple replacements for SLOAD-(ADD|SUB)-SSTORE sequence because there is an overflow/underflow check</p> <p>There is no EVM functionality removed by this proposal.</p> <h2 id="test-cases">Test Cases</h2> <p>Test for overflow and non-overflow for the following values and values before and after:</p> <p>1, 2^8, 2^16, 2^32, 2^64, 2^128 2^255, 2^256-1.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>/# TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>The use of revert to handle over/underflow represents a new halt condition that auditors will need to consider when examining reentrancy concerns.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-09-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Carl Beekhuizenhttps://github.com/carlbeek https://wg-eips.ritovision.com/7516/

Instruction that returns the current data-blob base-fee

<h2 id="abstract">Abstract</h2> <p>Add a <code>BLOBBASEFEE (0x4a)</code> instruction that returns the value of the blob base-fee of the current block it is executing in. It is the identical to <a href="https://wg-eips.ritovision.com/3198/">EIP-3198</a> (<code>BASEFEE</code> opcode) except that it returns the blob base-fee as per <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>.</p> <h2 id="motivation">Motivation</h2> <p>The intended use case would be for contracts to get the value of the blob base-fee. This feature enables blob-data users to programmatically account for the blob gas price, eg:</p> <ul> <li>Allow rollup contracts to trustlessly account for blob data usage costs.</li> <li>Blob gas futures can be implemented based on it which allows for blob users to smooth out data blob costs.</li> </ul> <h2 id="specification">Specification</h2> <p>Add a <code>BLOBBASEFEE</code> instruction with opcode <code>0x4a</code>, with gas cost <code>2</code>.</p> <table><thead><tr><th>Op</th><th>Input</th><th>Output</th><th>Cost</th></tr></thead><tbody> <tr><td>0x4a</td><td>0</td><td>1</td><td>2</td></tr> </tbody></table> <p><code>BLOBBASEFEE</code> returns the result of the <code>get_blob_gasprice(header) -&gt; int</code> function as defined in <a href="https://wg-eips.ritovision.com/4844/#gas-accounting">EIP-4844 §Gas accounting</a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-cost">Gas cost</h3> <p>The value of the blob base-fee is needed to process data-blob transactions. That means its value is already available before running the EVM code. The instruction does not add extra complexity and additional read/write operations, hence the choice of <code>2</code> gas cost. This is also identical to <a href="https://wg-eips.ritovision.com/3198/">EIP-3198</a> (<code>BASEFEE</code> opcode)'s cost as it just makes available data that is in the header.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues with this instruction.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="nominal-case">Nominal Case</h3> <p>Assume calling <code>get_blob_gasprice(header)</code> (as defined in <a href="https://wg-eips.ritovision.com/4844/#gas-accounting">EIP-4844 §Gas accounting</a>) on the current block's header returns <code>7 wei</code>: <code>BLOBBASEFEE</code> should push the value <code>7</code> (left padded byte32) to the stack.</p> <p>Bytecode: <code>0x4900</code> (<code>BLOBBASEFEE, STOP</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>BLOBBASEFEE</td><td>2</td><td>[]</td><td>[]</td></tr> <tr><td>1</td><td>STOP</td><td>0</td><td>[7]</td><td>[]</td></tr> </tbody></table> <p>Output: 0x Consumed gas: <code>2</code></p> <h3 id="comprehensive-test-suite">Comprehensive Test Suite</h3> <p>A complete suite of tests can be found <a rel="external" href="https://github.com/ethereum/execution-spec-tests/blob/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip7516_blobgasfee/test_blobgasfee_opcode.py">here</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The value of the blob base-fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this instruction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-09-07T00:00:00+00:00 2026-02-11T14:49:27+00:00 dapplionhttps://github.com/dapplion Tim Beikohttps://github.com/timbeiko https://wg-eips.ritovision.com/7514/

Modify the churn limit function to upper bound it to a max value

<h2 id="abstract">Abstract</h2> <p>Update the maximum validator growth rate from an exponential to a linear increase by capping the epoch churn limit.</p> <h2 id="motivation">Motivation</h2> <p>This proposal aims to mitigate the negative externalities of very high level of total ETH supply staked before a proper solution is implemented. In other words, this proposal accepts the complexities of changing the rewards curve and is meant only to slow down growth.</p> <p>In the event that the deposit queue stays 100% full, the share of ETH supply staked will reach 50% by May 2024, 75% by September 2024, and 100% by December 2024. While rewards decrease as the validator set size increases, at 100% of ETH supply staked, yearly consensus rewards alone (excluding MEV/transaction fees) for validators still represent ~1.6% of their stake. This small yield does not necessarily dissuade additional capital staking due to the often much higher and unpredictable yields from MEV. As such, the equilibrium point of the validator set size can be close to its maximum possible. Liquid staking tokens (LSTs) also contribute to this, given stakers can use them as they use unstaked ETH.</p> <p>As the levels of ETH staked increase, more strain is put on the consensus layer. A larger number of validators leads to an increase in gossip messages, as well as a growing Beacon state size. Additionally, as the amount of stake grows, it's unclear how much marginal security benefits come from additional economic weight.</p> <p>The Beacon Chain validator reward function was chosen before its launch in 2020. PoS research and reward curve design were performed in a pre-MEV world. Much has changed since then, including the Beacon chain achieving unprecedented success, beyond the original intended targets of stake rate. In light of this, it is worth discussing whether Beacon chain validator rewards should be adjusted to better match today's reality, potentially to discourage staking past a certain point.</p> <p>This EIP does not attempt to do this, but to allow more time for the community to have these discussions. By limiting the epoch churn limit now, the time to reach critical milestones of total ETH supply staked are significantly delayed. This allows more time for research into more comprehensive solutions, and for community consensus around them to emerge.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code></td><td>8</td></tr> </tbody></table> <h3 id="execution-layer">Execution layer</h3> <p>This requires no changes to the Execution Layer.</p> <h3 id="consensus-layer">Consensus layer</h3> <ul> <li>Add <code>get_validator_activation_churn_limit</code> with upper bound <code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code></li> <li>Modify <code>process_registry_updates</code> to use bounded activation churn limit</li> </ul> <p>The full specification of the proposed change can be found in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/69d34dc4ee3d026ca437d1b6875b218e8aaf3a5c/specs/deneb/beacon-chain.md"><code>/specs/deneb/beacon-chain.md</code></a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="max-per-epoch-churn-limit-value"><code>MAX_PER_EPOCH_CHURN_LIMIT</code> value</h3> <p>Depending on the specific constant selection the churn can <em>decrease</em> at the activation fork epoch. The Beacon chain spec can handle this without issues. During 2023 Q4 (projected Dencun activation) the churn value will range 14-16. The table below compares the projected validator set assuming a continuous full deposit queue.</p> <h4 id="max-per-epoch-churn-limit-activation-date-dec-01-2023"><code>MAX_PER_EPOCH_CHURN_LIMIT</code> activation date: Dec 01, 2023</h4> <table><thead><tr><th style="text-align: right">Max Churn Limit</th><th style="text-align: left">50% ETH staked</th><th style="text-align: left">75% ETH staked</th><th style="text-align: left">100% ETH staked</th></tr></thead><tbody> <tr><td style="text-align: right">inf</td><td style="text-align: left">May 28, 2024</td><td style="text-align: left">Sep 25, 2024</td><td style="text-align: left">Dec 18, 2024</td></tr> <tr><td style="text-align: right">16</td><td style="text-align: left">Jul 23, 2024</td><td style="text-align: left">Apr 10, 2025</td><td style="text-align: left">Dec 26, 2025</td></tr> <tr><td style="text-align: right">12</td><td style="text-align: left">Oct 09, 2024</td><td style="text-align: left">Sep 21, 2025</td><td style="text-align: left">Sep 04, 2026</td></tr> <tr><td style="text-align: right">8</td><td style="text-align: left">Mar 15, 2025</td><td style="text-align: left">Aug 18, 2026</td><td style="text-align: left">Jan 21, 2028</td></tr> <tr><td style="text-align: right">6</td><td style="text-align: left">Aug 19, 2025</td><td style="text-align: left">Jul 14, 2027</td><td style="text-align: left">Jun 08, 2029</td></tr> <tr><td style="text-align: right">4</td><td style="text-align: left">Jun 29, 2026</td><td style="text-align: left">May 05, 2029</td><td style="text-align: left">Mar 12, 2032</td></tr> </tbody></table> <h4 id="max-per-epoch-churn-limit-activation-date-apr-01-2024"><code>MAX_PER_EPOCH_CHURN_LIMIT</code> activation date: Apr 01, 2024</h4> <table><thead><tr><th style="text-align: right">Max Churn Limit</th><th style="text-align: left">50% ETH staked</th><th style="text-align: left">75% ETH staked</th><th style="text-align: left">100% ETH staked</th></tr></thead><tbody> <tr><td style="text-align: right">inf</td><td style="text-align: left">May 28, 2024</td><td style="text-align: left">Sep 25, 2024</td><td style="text-align: left">Dec 18, 2024</td></tr> <tr><td style="text-align: right">16</td><td style="text-align: left">Jul 01, 2024</td><td style="text-align: left">Mar 18, 2025</td><td style="text-align: left">Dec 04, 2025</td></tr> <tr><td style="text-align: right">12</td><td style="text-align: left">Aug 01, 2024</td><td style="text-align: left">Jul 14, 2025</td><td style="text-align: left">Jun 26, 2026</td></tr> <tr><td style="text-align: right">8</td><td style="text-align: left">Oct 01, 2024</td><td style="text-align: left">Mar 05, 2026</td><td style="text-align: left">Aug 08, 2027</td></tr> <tr><td style="text-align: right">6</td><td style="text-align: left">Dec 01, 2024</td><td style="text-align: left">Oct 26, 2026</td><td style="text-align: left">Sep 20, 2028</td></tr> <tr><td style="text-align: right">4</td><td style="text-align: left">Apr 02, 2025</td><td style="text-align: left">Feb 07, 2028</td><td style="text-align: left">Dec 15, 2030</td></tr> </tbody></table> <p>Assuming that the earliest the next fork can happen is at the start of 2024 Q3, a value of 8 provides a significant reduction in projected size without causing a big drop in churn at a projected Dencun fork date. A value of 8 prevents reaching a level of 50% ETH staked for at least 1 full year even with a delayed dencun fork.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for this EIP can be found in the <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/2297c09b7e457a13f7b2261a28cb45777be82f83/tests/core/pyspec/eth2spec/test/deneb"><code>deneb</code></a> test suite of the <code>consensus-specs</code> repository.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP breaks the symmetry between the validator entry and exit queues, where the former is bound by <code>MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code> while the latter isn't.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-09-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 George Kadianakishttps://github.com/asn-d6 Justin Drakehttps://github.com/JustinDrake dapplionhttps://github.com/dapplion https://wg-eips.ritovision.com/7441/

Allow elected block proposers to remain private until block publishing, to prevent DoS attacks

<h2 id="abstract">Abstract</h2> <p>Upgrades the block proposer election mechanism to Whisk, a single secret leader election (SSLE) protocol. Currently, block proposers are publicly known in advance, sufficiently to allow sequential DoS attacks that could disable Ethereum. This upgrade allows the next block proposer to remain secret until its block is published.</p> <h2 id="motivation">Motivation</h2> <p>The beacon chain currently elects the next 32 block proposers at the beginning of each epoch. The results of this election are public and everyone gets to learn the identity of those future block proposers.</p> <p>This information leak enables attackers to launch DoS attacks against each proposer sequentially in an attempt to disable Ethereum.</p> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution layer</h3> <p>This requires no changes to the Execution Layer.</p> <h3 id="consensus-layer">Consensus layer</h3> <p>The protocol can be summarized in the following concurrent steps:</p> <ul> <li>Validators register a tracker and unique commitment on their first proposal after the fork</li> <li>At the start of a shuffling phase a list of candidate trackers is selected using public randomness from RANDAO</li> <li>During each shuffling phase each proposer shuffles a subset of the candidate trackers using private randomness</li> <li>After each shuffling phase an ordered list of proposer trackers is selected from the candidate set using RANDAO</li> </ul> <p>The full specification of the proposed change can be found in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/a39abe388bc2d1abd5b4fd62fd18aed497956b30/specs/_features/whisk/beacon-chain.md"><code>/_features/whisk/beacon-chain.md</code></a>. In summary:</p> <ul> <li>Update <code>BeaconState</code> with fields needed to track validator trackers, commitments, and the two rounds of candidate election.</li> <li>Add <code>select_whisk_candidate_trackers</code> to compute the next vector of candidates from the validator set.</li> <li>Add <code>select_whisk_proposer_trackers</code> to compute the next vector of proposers from current candidates.</li> <li>Add <code>process_whisk_updates</code> to epoch processing logic.</li> <li>Add <code>process_whisk_opening_proof</code> to validate block proposer has knowledge of this slot's elected tracker.</li> <li>Modify <code>process_block_header</code> to not assert proposer election with <code>get_beacon_proposer_index</code>, instead assert valid opening proof.</li> <li>Update <code>BeaconBlockBody</code> with fields to submit opening proof, shuffled trackers with proof, and tracker registration with proof.</li> <li>Add <code>get_shuffle_indices</code> to compute pre-shuffle candidate selection</li> <li>Add <code>process_shuffled_trackers</code> to submit shuffled candidate trackers.</li> <li>Add <code>process_whisk</code> to block processing logic.</li> <li>Modify <code>apply_deposit</code> to register an initial unique tracker and commitment without entropy.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="fields-per-validator">Fields per validator</h3> <p>Whisk requires having one tracker <code>(rG,krG)</code> and one unique commitment <code>kG</code> per validator. Both are updated only once on a validator's first proposal after the fork.</p> <p>Trackers are registered with a randomized base <code>(rG,krG)</code> to make it harder for adversaries to track them through shuffling gates. It can become an issue if the set of honest shufflers is small.</p> <h3 id="identity-binding">Identity binding</h3> <p>Each tracker must be bound to a validator's identity to prevent multiple parties to claim the same proposer slot. Otherwise, it would allow proposers to sell their proposer slot, and cause fork-choice issues if two competing blocks appear.</p> <p>Whisk does identity binding by storing a commitment to the tracker's secret <code>kG</code> in the validator record. Storing the commitment also ensures the uniqueness of <code>k</code>.</p> <p>Alternatively, identity binding can be achieved by forcing the hash prefix of <code>hash(kG)</code> to match its validator index. However, validators would have to brute force <code>k</code> making bootstrap of the system harder for participants with fewer computational resources.</p> <p>Identity binding can also be achieved by setting <code>k = hash(nonce + pubkey)</code>. However, proposers will need to reveal <code>k</code> and be de-anonymized for repeated proposals on adjacent shuffling phases.</p> <h3 id="alternative-non-single-secret-election">Alternative: non-single secret election</h3> <p>Secret non-single leader election could be based on protocol engineering rather than cryptography, thus much simpler and cheaper than Whisk. However, it complicates the fork-choice and opens it up to potential MEV time-buying attacks, making it an unsuitable option at the time of writing.</p> <h3 id="alternative-network-anonymity">Alternative: network anonymity</h3> <p>Privacy-preserving networking protocols like Dandelion or Dandelion++ increase the privacy of network participants but not sufficiently for Ethereum's use case.</p> <p>SASSAFRAS is a simpler alternative SSLE protocol consensus-wise, but it relies on a network anonymity layer. Its specific trade-offs do not fit Ethereum's overall threat model better than Whisk.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p> <p>PBS participants (e.g. builders) will not know the next proposer validator index to use a specific pre-registered fee recipient; unless the proposer chooses to reveal itself ahead of time. Block explorers and tooling will not be able to attribute missing slots to a specific validator index.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The shuffling strategy is analyzed in a companion paper and considered sufficiently safe for Whisk's use case. The data and computational complexity of this EIP are significant but constant, thus does not open new DoS vectors.</p> <h3 id="anonymity-set">Anonymity set</h3> <p>The anonymity set in Whisk is the set of 8,192 candidates that did not get selected as proposers. That count of validators corresponds to a smaller number of p2p nodes. Assuming a Pareto principle where "20% of the nodes run 80% of the validators" the anonymity corresponds to 2,108 nodes on average. A bigger candidate pool could make the shuffling strategy unsafe while shuffling more trackers per round would increase the cost of the ZK proofs.</p> <h3 id="randao-biasing">RANDAO biasing</h3> <p>Whisk uses RANDAO in the candidate selection and proposer selection events, and is susceptible to potential RANDAO biasing attacks by malicious proposers. Whisk security could be made identical to the status quo by spreading the selection events over an entire shuffling period. However, status quo security is not ideal either and it would complicate the protocol further.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-08-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Caymanhttps://github.com/wemeetagain https://wg-eips.ritovision.com/7495/

SSZ type for forward-compatible containers

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md">Simple Serialize (SSZ)</a> type to represent containers with forward-compatible Merkleization: A given field is always assigned the same stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> even when different container versions append new fields or drop existing fields.</p> <h2 id="motivation">Motivation</h2> <p>SSZ containers are frequently versioned, for example across fork boundaries. When the number of fields reaches a new power of two, or a field is removed or replaced with one of a different type, the shape of the underlying Merkle tree changes, breaking verifiers of Merkle proofs for these containers. Deploying a new verifier may involve security councils to upgrade smart contract logic, or require firmware updates for embedded devices. This effort is needed even when no semantic changes apply to the fields that the verifier is interested in.</p> <p>Progressive containers address these shortcomings by:</p> <ul> <li>Using the <a href="https://wg-eips.ritovision.com/7916/">progressive Merkle tree</a> structure to progressively grow to the actual field count with minimal overhead, ensuring provers remain valid as the field count changes.</li> <li>Assigning stable gindices for each field across all versions by allowing gaps in the Merkle tree where a field is absent.</li> <li>Serializing in a compact form where absent fields do not consume space.</li> </ul> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="progressivecontainer-active-fields"><code>ProgressiveContainer(active_fields)</code></h3> <p>A new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#composite-types">SSZ composite types</a> is defined:</p> <ul> <li> <p><strong>progressive container</strong>: ordered heterogeneous collection of values with stable Merkleization</p> <ul> <li>python dataclass notation with key-type pairs, e.g.</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Square</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> side</span><span>:</span><span> uint16</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Merkleized at field index #0 (location of first 1 in `active_fields`)</span></span> <span class="giallo-l"><span> color</span><span>:</span><span> uint8</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Merkleized at field index #2 (location of second 1 in `active_fields`)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Circle</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> radius</span><span>:</span><span> uint16</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Merkleized at field index #1 (location of first 1 in `active_fields`)</span></span> <span class="giallo-l"><span> color</span><span>:</span><span> uint8</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Merkleized at field index #2 (location of second 1 in `active_fields`)</span></span></code></pre></li> </ul> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#default-values">default value</a> is defined as:</p> <table><thead><tr><th>Type</th><th>Default Value</th></tr></thead><tbody> <tr><td><code>ProgressiveContainer(active_fields)</code></td><td><code>[default(type) for type in progressive_container]</code></td></tr> </tbody></table> <p>The following types are considered <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#illegal-types">illegal</a>:</p> <ul> <li><code>ProgressiveContainer</code> with no fields are illegal.</li> <li><code>ProgressiveContainer</code> with an <code>active_fields</code> configuration of more than 256 entries are illegal.</li> <li><code>ProgressiveContainer</code> with an <code>active_fields</code> configuration ending in <code>0</code> are illegal.</li> <li><code>ProgressiveContainer</code> with an <code>active_fields</code> configuration with a different count of <code>1</code> than fields are illegal.</li> </ul> <h4 id="serialization">Serialization</h4> <p>Serialization of <code>ProgressiveContainer(active_fields)</code> is identical to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#vectors-containers-lists"><code>Container</code></a>.</p> <h4 id="deserialization">Deserialization</h4> <p>Deserialization of <code>ProgressiveContainer(active_fields)</code> is identical to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#deserialization"><code>Container</code></a>.</p> <h4 id="json-mapping">JSON mapping</h4> <p>The canonical <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#json-mapping">JSON mapping</a> is updated:</p> <table><thead><tr><th>SSZ</th><th>JSON</th><th>Example</th></tr></thead><tbody> <tr><td><code>ProgressiveContainer(active_fields)</code></td><td>object</td><td><code>{ "field": ... }</code></td></tr> </tbody></table> <h4 id="merkleization">Merkleization</h4> <p>The <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/ad36024441cf910d428d03f87f331fbbd2b3e5f1/ssz/simple-serialize.md#merkleization">SSZ Merkleization specification</a> is extended with two helper functions:</p> <ul> <li><code>get_active_fields(value)</code>, where <code>value</code> is of type <code>ProgressiveContainer(active_fields)</code>: return <code>active_fields</code>.</li> <li><code>mix_in_active_fields</code>: Given a Merkle root <code>root</code> and an <code>active_fields</code> configuration return <code>hash(root, pack_bits(active_fields))</code>. Note that <code>active_fields</code> is restricted to ≤ 256 bits.</li> </ul> <p>The Merkleization definitions are extended.</p> <ul> <li><code>mix_in_active_fields(merkleize_progressive([hash_tree_root(element) for element in value]), get_active_fields(value))</code> if <code>value</code> is a progressive container.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-is-active-fields-limited-to-256-bits">Why is <code>active_fields</code> limited to 256 bits?</h3> <p>256 bits (1 word) allows the mix-in to be simple, consistent with the length mix-in for lists, and is practically sufficient. An alternate design with a <code>ProgressiveBitlist</code> mix-in was explored, however deemed too over-engineered as it would effectively require introducing caches to pre-compute the mix-in's <code>hash_tree_root</code> to avoid repeated computations, and also makes verifier logic more complex than necessary.</p> <p>Even though the 256 field limit includes all fields (including deprecated ones), it is unlikely that many progressive containers come close to reach 256 fields (<code>BeaconState</code> currently reaches around 40 fields). If that happens, one can add a <code>more</code> field with a nested <code>ProgressiveContainer</code>.</p> <h3 id="why-is-empty-progressivecontainer-an-illegal-type">Why is empty <code>ProgressiveContainer</code> an illegal type?</h3> <p>It would result in 0-length serialization, meaning that the length of a list of such a container cannot be determined from the serialization.</p> <h3 id="optional-type"><code>Optional[type]</code>?</h3> <p>Introducing <code>Optional</code> is not required by any current functionality and is deferred to a future EIP.</p> <p>The <code>active_fields</code> bitvector can be updated to also indicate optionality. Further, serialization for sparse lists should be explored.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>ProgressiveContainer(active_fields)</code> is a new SSZ type and does not conflict with existing types.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li><code>ethereum/remerkleable</code> contains static tests in <code>test_impl.py</code> and <code>test_typing.py</code>.</li> <li><code>ethereum/consensus-specs</code> releases contain random tests in <code>tests/general/phase0/ssz_generic</code>, generated according to a format defined in <code>tests/format/ssz_generic</code>.</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>See <code>ethereum/remerkleable</code>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Light client based verifiers and smart contracts (e.g., based on <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a>) do not update at the same cadence as Ethereum. If a future fork removes a field from a <code>ProgressiveContainer(active_fields)</code>, the <code>active_fields</code> mix-in enables such verifiers to distinguish absent fields from <code>0</code> values. Without <code>active_fields</code>, the <code>hash_tree_root</code> for these cases would collide.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-08-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Keyvan Kambakhshhttps://github.com/keyvank Hamid Batenihttps://github.com/irnb Amir Kahooria.kahoorizadeh@gmail.com Nobitex Labslabs@nobitex.ir 0xwormholehttps://github.com/0xwormhole https://wg-eips.ritovision.com/7503/

Enable minting of secretly burnt Ethers as a native privacy solution for Ethereum

<h2 id="abstract">Abstract</h2> <p>While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens reside in an account that are unspendable, without revealing the account.</p> <p>The EIP proposes to add a minting functionality to Ethereum, so that people can re-mint Ethers they have purposefully burnt. The mentioned privacy solution will bring strong levels of <em><strong>plausible deniability</strong></em> for the sender, since there is no way one can prove that the sender has been participating in a privacy protocol. This will also make an anonymity pool that includes all of the Ethereum accounts with zero outgoing transactions by default.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <ul> <li><code>MAGIC_ADDRESS</code>: <code>0xfe</code> (one byte)</li> <li><code>MAGIC_NULLIFIER</code>: <code>0x01</code> (one byte)</li> <li><code>MAGIC_POW</code>: <code>0x02</code> (one byte)</li> <li><code>MAGIC_CHANGE</code>: <code>0x0404040404040404040404040404040404040404040404040404040404040404</code></li> <li><code>POW_LOG_DIFFICULTY</code>: <code>24</code></li> <li><code>MAX_DEPOSIT</code>: <code>32 * 10**18</code> wei</li> <li><code>WormholeTxType</code>: <code>TBD</code></li> <li><code>WORMHOLE_NULLIFIER_ADDRESS</code>: <code>TBD</code></li> <li><code>RECEIPT_PREFIX</code>: <code>TBD</code> (datatype <code>List[bool]</code>)</li> </ul> <hr /> <p>We define a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type, where <code>TransactionType</code> is <code>WormholeTxType</code> and the <code>TransactionPayload</code> format is as follows:</p> <p><code>[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, data, access_list, root_beacon_block_number, proof]</code></p> <p>Verifying this type of transaction requires confirming that:</p> <ol> <li>The proof is a zero-knowledge proof: <ul> <li>Private inputs: <code>secret</code>, <code>main_index</code>, <code>main_branch</code>, <code>privacy_pool_index</code>, <code>privacy_pool_branch</code>, <code>deposit_value</code>, <code>deposit_sender</code>, <code>change_value_salt</code>, <code>change_value</code></li> <li>Public inputs: <code>beacon_block_root</code>, <code>nullifier</code>, <code>privacy_pool_root</code>, <code>withdraw_value</code>, <code>change_value_hash</code></li> <li>Function: verify all of the following conditions <ul> <li><code>verify_merkle_branch(root=beacon_block_root, index=RECEIPT_PREFIX + main_index, leaf=make_receipt_hash(deposit_sender, deposit_value, change_value_salt, secret), branch=main_branch)</code></li> <li><code>verify_merkle_branch(root=privacy_pool_root, index=privacy_pool_index, leaf=make_receipt_hash(deposit_sender, deposit_value, change_value_salt, secret), branch=privacy_pool_branch)</code></li> <li><code>nullifier == sha256(MAGIC_NULLIFIER + secret)</code></li> <li><code>sha256(MAGIC_POW + secret) % 2**POW_LOG_DIFFICULTY == 0</code></li> <li><code>change_value_hash == sha256(change_value_salt, change_value)</code></li> <li><code>change_value + withdraw_value == deposit_value</code> (all values are unsigned int, also need to confirm that there is no overflow)</li> <li><code>deposit_value &lt;= MAX_DEPOSIT</code></li> </ul> </li> </ul> </li> <li><code>SLOAD(WORMHOLE_NULLIFIER_ADDRESS, proof.nullifier) == 0</code></li> <li><code>get_beacon_block_root(root_beacon_block_number) == proof.beacon_block_root</code></li> </ol> <p>We define <code>make_receipt_hash</code> as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def make_receipt_hash(deposit_sender: Address, value: uint256, change_value_salt: bytes32, secret: bytes32):</span></span> <span class="giallo-l"><span> if deposit_sender != 0:</span></span> <span class="giallo-l"><span> to_address = sha256(MAGIC_ADDRESS + secret)[12:]</span></span> <span class="giallo-l"><span> topics = [MAGIC_EIP_7708, deposit_sender, to_address]</span></span> <span class="giallo-l"><span> logdata = int_to_bytes32(value)</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> topics = [MAGIC_CHANGE, hash(change_value_salt, value)]</span></span> <span class="giallo-l"><span> logdata = bytes([])</span></span> <span class="giallo-l"><span> return get_ssz_root_hash(Log(topics=topics, data=logdata))</span></span></code></pre> <p>The hash of the transaction (excluding proof) should be included in the randomness for generating the zero-knowledge proof. This ensures the proof serves as a signature.</p> <p>If the transaction is confirmed, generate <code>proof.withdraw_value</code> ether at address <code>WORMHOLE_NULLIFIER_ADDRESS</code>. Then proceed with a normal call from this address using that value. Before the call, set <code>SSTORE(WORMHOLE_NULLIFIER_ADDRESS, proof.nullifier, 1)</code>, and emit a log event where <code>topics = [MAGIC_CHANGE, proof.change_value_hash]</code> and <code>logdata = bytes([])</code>.</p> <h2 id="rationale">Rationale</h2> <p>In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is calculated (By multiplying the generator point with the scalar: $s \times G$). An Ethereum EOA-address is the keccak hash of a public-key.</p> <p>Also, the funds in an Ethereum address might be spendable by a smart-contract, if the keccak hash of the smart-contract's parameters is equal with that address.</p> <p>Therefore, an Ethereum address $A$ is spendable if and only if:</p> <ol> <li>A private-key $s$ exists. such that $A = keccak(s \times G)$.</li> <li>There exists a smart-contract $c$, such that $A = keccak(c_{params})$.</li> </ol> <p>The preimage resistance property of hash functions implies that, you can't find $x$ where $keccak(x)=r$, in case $r$ is a random value. So the funds sent to a random Ethereum address $r$ is unspendable, but how can other people be sure that $r$ is indeed random and not the result of calculating $s \times G$?</p> <p>A great source of randomness is a hash function. If the address is equal with the hash of a secret preimage $s$, we can conclude that the address is unspendable, since there isn't a polynomially bounded algorithm to find $x$ where $keccak(x)=h(s)$. This is only true if the second hash function is a different hash function, and it assumes it is impossible to find $x_1$ and $x_2$ such that $h_1(x_1)=h_2(x_2)$ in case $h_1$ and $h_2$ are different hash functions.</p> <p>Using the help of Zero-Knowledge proofs, we can hide the value of $s$! We just need to prove that we know a secret value $s$ where the address is $h(s)$. We can go even further. We can prove that an Ethereum accounts exists in the state-root, which holds some amount of ETH and is unspendable.</p> <p>By revealing this to the Ethereum blockchain and providing something like a nullifier (E.g. $h(s | 123)$ so that double minting of same burnt tokens are not possible), we can add a new <em><strong>minting</strong></em> functionality for ETH so that people can migrate their secretly burnt tokens to a completely new address, without any trace on the blockchain.</p> <p>Cryptocurrency mixers like TornadoCash can successfully obfuscate Ethereum transactions, but it's easy for the governments to ban usage of them. Anybody who has interactions with a mixer contract, whether the sender or receiver, can get marked. However this EIP tries to minimize the privacy leakage of the senders, by requiring zero smart-contract interactions in order to send money, so we only use plain EOA-to-EOA transfers. In order to have a "teleportation" mechanism we divide the set of all Secp256k1 points $E(K)$ into two subsets/address-spaces:</p> <ul> <li>The spendable address-space: $\{p \in \{0,1\}^{160} | \exists s : keccak(s \times G)=p \lor \exists c : keccak(c_{params})=p \}$</li> <li>The unspendable address-space: $\{p \in \{0,1\}^{160} | \nexists s : keccak(s \times G)=p \land \nexists c : keccak(c_{params})=p \}$</li> </ul> <p>The spendable/unspendable addresses are not distinguishable, so we can exploit this fact and define a spendability rule for the money sent to addresses that can't be spent using regular elliptic-curve signatures.</p> <p>Deposits are made by sending ether to an address <code>sha256(MAGIC_ADDRESS + secret)[12:]</code>, where you know the <code>secret</code>. This ensures that no one knows about the deposit unless you reveal it: a deposit onchain is not distinguishable from sending ether to a friend. Withdrawals use a zero-knowledge proof to prove knowledge of a previous deposit's <code>secret</code>.</p> <p>A deposit can come from two places: a standard deposit by sending ether, or a change deposit. A change deposit is automatically generated when withdrawing funds from another deposit (standard or change). The entire deposited amount does not have to be withdrawn; for example, if 20 ether was deposited and only 12 is withdrawn, the system will make a new change deposit of 8 ether. The value of this change deposit is hashed, so someone looking at the chain cannot calculate <code>change deposit value + withdrawal value = old deposit value</code> and use the value to expose the original deposit.</p> <p>This EIP requires that <a href="https://wg-eips.ritovision.com/7708/">EIP-7708</a> be in place along with an EIP to change receipts to SSZ format. This simplifies the proof as it only needs to verify a regular SHA256 Merkle branch verifying a log, there is no need to do verkle or RLP or other complex logic inside the proof. The log can be of two types: an EIP-7708 ETH transfer log, or a log generated by this EIP itself through the change mechanism.</p> <p>The EIP also includes a privacy pool <sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup> mechanism where you must provide a privacy pool root, which corresponds to a list of deposits, so you prove that your deposit is one of the deposits in that list. Since this second Merkle branch mechanism is integrated into the proof, the marginal cost for a user to use it is zero, ensuring maximum adoption and maximizing the chance that privacy will be used responsibly. The privacy pools paper explains in much more detail the value of this privacy pools mechanism, and the benefits of an ecosystem where almost all legitimate users use it.</p> <p>The built-in PoW and 32 ETH limit prevent hash collision attacks: if an attacker can find collision <code>(x1, x2)</code> such that <code>create2_address(..., x1) == sha256(MAGIC_ADDRESS + x2)</code>, the attacker could extract their ether twice (but only twice). Such an attack requires approximately <code>2**80</code> hashes. Adding 24 bits of PoW increases the difficulty to <code>2**92</code>. This many hashes can be computed but is very difficult; currently, mining a Bitcoin block takes around <code>2**79</code> hashes, so those with the capabilities to attack this mechanism have a much more lucrative opportunity in Bitcoin mining.</p> <h3 id="scalability-implications">Scalability Implications</h3> <p>In case the circuits are able to simultaneously re-mint the sum of multiple burns in a single-proof, merchants and CEXs will be able to accept their payments in burn-addresses and accumulate their funds in a single address by storing a single proof (And a bunch of nullifiers) on the blockchain, which significantly reduces the transaction count on the blockchain. The people who will use this EIP as a scalability solution, will also increase the privacy guarantees of the protocol.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The Ethers generated using the mint function should not have any difference with original Ethers. People should be able to use those minted Ethers for paying the gas fees.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>To be determined (TBD).</p> <h3 id="zk-snark-implementation">ZK-SNARK Implementation</h3> <p>Also TBD, but the implementation must meet the following conditions:</p> <ul> <li>Use a transparent setup; ideally reuse the <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> setup. Do not use Groth16 or other application-specific setups.</li> <li>The circuit should be directly verifiable without blindly trusting compilers like Circom. SHA256 is not too complicated and can be implemented using PLOOKUP with an 8-bit lookup table for arithmetic operations, which should suffice. There is no need to over-focus on prover efficiency.</li> <li>Elliptic curves must still be used; Stark is too large.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>In case of faulty implementation of this EIP, people may mint infinite amount of ETH, collapsing the price of Ethereum.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-1"> <p>Buterin, V., Illum, J., Nadler, M., Schär, F., &amp; Soleimani, A. (n.d.). <span style="font-style: italic;">Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium</span>. https://doi.org/<a href="https://doi.org/10.2139/ssrn.4563364">10.2139/ssrn.4563364</a> (Original work published 2023) <a href="#fr-1-1">↩</a></p> </li> </ol> </section> 2023-08-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Andrei Maiborodahttps://github.com/gumb0 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/7480/

Instructions to read data section of EOF container

<h2 id="abstract">Abstract</h2> <p>Four new instructions are introduced, that allow to read EOF container's data section: <code>DATALOAD</code> loads 32-byte word to stack, <code>DATALOADN</code> loads 32-byte word to stack where the word is addressed by a static immediate argument, <code>DATASIZE</code> loads data section size and <code>DATACOPY</code> copies a segment of data section to memory.</p> <h2 id="motivation">Motivation</h2> <p>Clear separation between code and data is one of the main features of EOF1. Data section may contain anything, e.g. compiler's metadata, but to make it useful for smart contracts, EVM has to have instructions that allow to read from data section. Previously existing instructions for bytecode inspection (<code>CODECOPY</code>, <code>CODESIZE</code> etc.) are deprecated in EOF1 and cannot be used for this purpose.</p> <p>The <code>DATALOAD</code>, <code>DATASIZE</code>, <code>DATACOPY</code> instruction pattern follows the design of existing instructions for reading other kinds of data (i.e. returndata and calldata).</p> <p><code>DATALOADN</code> is an optimized version of <code>DATALOAD</code>, where data offset to read is set at compilation time, and therefore need not be validated at run-time, which makes the instruction cheaper.</p> <h2 id="specification">Specification</h2> <p>We introduce four new instructions on the same block number <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is activated on:</p> <ol> <li><code>DATALOAD</code> (0xd0)</li> <li><code>DATALOADN</code> (0xd1)</li> <li><code>DATASIZE</code> (0xd2)</li> <li><code>DATACOPY</code> (0xd3)</li> </ol> <p>If the code is legacy bytecode, all of these instructions result in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <p>If the code is valid EOF1, the following execution rules apply:</p> <h3 id="dataload"><code>DATALOAD</code></h3> <ol> <li>Pops one value, <code>offset</code>, from the stack.</li> <li>Reads <code>[offset:offset+32]</code> segment from the data section and pushes it as 32-byte value to the stack.</li> <li>If <code>offset + 32</code> is greater than the data section size, bytes after the end of data section are set to 0.</li> <li>Deducts 4 gas.</li> </ol> <h3 id="dataloadn"><code>DATALOADN</code></h3> <ol> <li>Has one immediate argument,<code>offset</code>, encoded as a 16-bit unsigned big-endian value.</li> <li>Pops nothing from the stack.</li> <li>Reads <code>[offset:offset+32]</code> segment from the data section and pushes it as 32-byte value to the stack.</li> <li>Deducts 3 gas.</li> </ol> <p><code>[offset:offset+32]</code> is guaranteed to be within data bounds by <a href="https://wg-eips.ritovision.com/7480/#code-validation">code validation</a>.</p> <h3 id="datasize"><code>DATASIZE</code></h3> <ol> <li>Pops nothing from the stack.</li> <li>Pushes the size of the data section of the active container to the stack.</li> <li>Deducts 2 gas.</li> </ol> <h3 id="datacopy"><code>DATACOPY</code></h3> <ol> <li>Pops three values from the stack: <code>mem_offset</code>, <code>offset</code>, <code>size</code>.</li> <li>Performs memory expansion to <code>mem_offset + size</code> and deducts memory expansion cost.</li> <li>Deducts <code>3 + 3 * ((size + 31) // 32)</code> gas for copying.</li> <li>Reads <code>[offset:offset+size]</code> segment from the data section and writes it to memory starting at offset <code>mem_offset</code>.</li> <li>If <code>offset + size</code> is greater than data section size, 0 bytes will be copied for bytes after the end of the data section.</li> </ol> <h3 id="code-validation">Code Validation</h3> <p>We extend code section validation rules (as defined in <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>).</p> <ol> <li>Code section is invalid in case an immediate argument <code>offset</code> of any <code>DATALOADN</code> is such that <code>offset + 32</code> is greater than data section size, as indicated in the container header <em>before deployment</em>.</li> <li><code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPV</code> immediate argument value (jump destination relative offset) validation: code section is invalid in case offset points to one of two bytes directly following <code>DATALOADN</code> instruction.</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="zero-padding-on-out-of-bounds-access">Zero-padding on out of bounds access</h3> <p>Existing instructions for reading other kinds of data implicitly pad with zeroes on out of bounds access, with the only exception of return data copying.</p> <p>It is beneficial to avoid exceptional failures, because compilers can employ optimizations like removing a code that copies data, but never accesses this copy afterwards, but such optimization is possible only if instruction never has other side effects like exceptional abort.</p> <h3 id="lack-of-extdatacopy">Lack of <code>EXTDATACOPY</code></h3> <p><code>EXTCODECOPY</code> instruction is deprecated and rejected in EOF contracts and does not copy contract code when being called in legacy with an EOF contract as target. A replacement instruction <code>EXTDATACOPY</code> has been considered, but decided against in order to reduce the scope of changes.</p> <p>Data-only contracts which previously relied on <code>EXTCODECOPY</code> are thereby discouraged, but if there is a strong need, support for them can be easily brought back by introducing <code>EXTDATACOPY</code> in a future upgrade.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).</p> <h2 id="security-considerations">Security Considerations</h2> <p>Gas cost of these new opcodes is comparable to the legacy <code>CODECOPY</code> instruction. They must be carefully considered during the implementation of the EOF container validation algorithm.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-07-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guy Gorenhttps://github.com/guy-gorenguy.nahsholim@gmail.com https://wg-eips.ritovision.com/7378/

Using geometric weights to average past block sizes into consideration

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a new formula to update the base fee, derived from <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>. The existing base fee update formula,</p> <p>$$b[i+1]\triangleq b[i] \cdot \left( 1+\frac{1}{8} \cdot \frac{s[i]-s^* }{s^* }\right)$$</p> <p>only considers the last block size $s[i]$. This mechanism incentivizes proposers to collude with users to manipulate the base fee.</p> <p>We propose that even previous block sizes be considered by replacing the last block size with an exponential moving average. In particular, we suggest the following base fee update formula:</p> <p>$$b[i+1]\triangleq b[i] \cdot \left( 1+\frac{1}{8} \cdot \frac{s_{\textit{avg}}[i]-s^* }{s^* }\right)$$</p> <p>where $s_{\textit{avg}}[i]$ is defined by:</p> <p>$$s_{\textit{avg}}[i] \triangleq \alpha\sum_{k=1}^{\infty} (1-\alpha)^k\cdot s[i-k+1]$$</p> <p>and $\alpha\in(0,1)$ is a smoothing factor.</p> <h2 id="motivation">Motivation</h2> <p>To reduce bribe motivation when the demand for blockspace is high (see Incentive Considerations section) and to reduce oscillations, thus, having a more stable fee setting mechanism.</p> <p>Proposers use a mechanism described in EIP-1559 to determine which messages to include in a block. This mechanism includes a "base fee": a portion of the transaction fee that is burned. The base fee varies according to the fill rate of blocks. A target block size is defined. If a block exceeds the target size, the base fee increases, and if it is smaller, the base fee lowers.</p> <p>Research on the subject have revealed issues with this transaction fee mechanism. It has been shown to be <a href="https://wg-eips.ritovision.com/7378/./assets/LMRSP.pdf">unstable in cases</a>. Moreover, it has been shown that the dynamic nature of the base fee, which is influenced by the fill rate of blocks, opens the door for <a href="https://wg-eips.ritovision.com/7378/./assets/AGHH.pdf">manipulation by miners (proposers) and users</a>. The desired behavior of the system under a stable high demand, is for it to reach an equilibrium where the base fee -- $b$ -- is the significant part of the gas fee, and the tip is relatively small -- denoted $\varepsilon$ (for reference, Ethereum's base fee often has $\frac{b}{\varepsilon}\approx 20$). According to <a href="https://wg-eips.ritovision.com/7378/./assets/TR1559.pdf">Roughgarden</a> this is a rational equilibrium under the assumption that proposers do not think ahead. However, we expect a proposer to optimize its behavior by also considering its future payoffs. In essence, since neither the proposer nor the user are getting the burnt fee, by colluding they can both tap into the burnt fee for a win-win situation for them both.</p> <p>A <a href="https://wg-eips.ritovision.com/7378/./assets/AGHH.pdf">theoretical work</a> describes how both proposers and users can initiate such an attack. For example, we can imagine that users who wish to pay lower costs will coordinate the attack. Roughly, a user (or group of users) that has transactions with a total $g$ amount of gas bribes the proposer of the current block (no matter the proposer's power) to propose an empty block instead. The cost of such a bribe is only $\varepsilon \times {s^* }$ -- the tip times the target block size. Consequently, the base fee reduces in the next block. If we accept that EIP-1559 reaches its goals, e.g., users would typically use a simple and honest bidding strategy of reporting their maximal willingness to pay plus adding a small tip ($\varepsilon$), then in the honest users' steady state, gas proposals leave the proposers with an $\varepsilon$ tip. Given that other users are naive (or slow to react), our bribing user will include its transactions with any tip larger than $\varepsilon$ -- making the attack profitable whenever $g \frac{b^* }{8} &gt;s^* \varepsilon$.</p> <h2 id="specification">Specification</h2> <p>$s[i]$ is replaced by $s_{\textit{avg}}[i]$, where:</p> <p>$$s_{\textit{avg}}[i] \triangleq \alpha\sum_{k=1}^{\infty} (1-\alpha)^k\cdot s[i-k+1]$$</p> <p>which simplifies to the recursive form</p> <p>$$s_{\textit{avg}}[i] = \alpha\cdot s[i] + (1-\alpha)\cdot s_{\textit{avg}}[i-1]$$</p> <p>where $\alpha\in(0, 1)$ is the smoothing factor. A higher smoothing factor means that the average responds more quickly to changes in block size (e.g., if $\alpha = 1$ the proposed formula degenerates to the existing rule).</p> <h2 id="rationale">Rationale</h2> <p>An intuitive option for the Transaction Fee Mechanism (TFM) that adjusts supply and demand economically is <em>First price auction</em>, which is well known and studied. Nevertheless, the Ethereum network choice was to use EIP-1559 for the TFM (one stated reason was to try and simplify the fee estimation for users, and reduce the advantage of sophisticated users). In this proposal, our design goal is to improve the TFM (of EIP-1559) by mitigating known problems that it raises. It is important to note that these problems severity are in direct relation to the demand for block space, and currently only mildly impact the Ethereum network. If demand to use Ethereum increases, however, these problems are expected to exacerbate. We may want to prepare for this beforehand.</p> <p>The change is based on <a href="https://wg-eips.ritovision.com/7378/./assets/AGHH.pdf">this work</a> that described a rational strategy in which bribes are profitable. Choosing to average based on a geometric series weights results in two desired properties: (i) the computation and space complexity are both in O(1), and (ii) the average gradually phases out the impact of a single outlier block without causing significant future fluctuations in the base fee. Moreover, the theoretical analysis does not consider the income from classic MEV strategies. (Actually, the described strategy may be seen as another form of MEV.) The fact that classic MEV (sandwich, front running, etc.) are not included in the analysis, means that the proposed solutions to classic MEV (obscuring transactions etc.) will also not help against the described strategy. The problem that we tackle in this EIP is at the core of the base fee mechanism, with no further assumptions (such as MEV or predictability of randomness).</p> <p>Remark: An additional alternative strategy that is not fully discussed <a href="https://wg-eips.ritovision.com/7378/./assets/AGHH.pdf">here</a> but one may consider is to reduce the 'max change denominator' (the learning rate) from 1/8 to something smaller. However, this is problematic since it significantly affects the responsiveness of the base fee, making it slow to respond to actual persistent changes. The reason for using geometric series weights is precisely to achieve the favorable tradeoff of still responding quickly while mitigating incentive misalignments.</p> <h3 id="incentive-considerations">Incentive Considerations</h3> <p>The proposal is designed to improve the incentive compatibility of the TFM. A <a href="https://wg-eips.ritovision.com/7378/./assets/AGHH.pdf">game theoretic analysis</a> shows that the current TFM, which is based on EIP-1559, encourages bribes.</p> <p>One of the main goals of EIP-1559 was to simplify the bidding for users. It was articulated <a href="https://wg-eips.ritovision.com/7378/./assets/TR1559.pdf">theoretically by Roughgarden</a> as users bidding their honest valuations being an optimal strategy. In contrast, when using first price auctions for the TFM (as done by Bitcoin and previously in Ethereum), it is typically sub-optimal for a user to bid its honest valuation. In other words, a TFM that encourages users to not fully reveal their preferences is considered less good. However, one may argue that a TFM that encourages bribes is worse than a TFM that encourages not revealing one's full preferences.</p> <p>Although a first price auction is a safe bet regarding TFMs, the Ethereum network chose to use EIP-1559 and burn transaction fees (perhaps for reasons other than game-theoretic ones). We therefore suggest to mitigate the current incentives for bribes using the above proposal.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change requires a hard fork since the base fee is enforced (for blocks to be considered valid).</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-07-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 lightclienthttps://github.com/lightclient Sam Wilsonhttps://github.com/samwilsn Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/7377/

Allow EOAs to send a one-time transaction which deploys code at their account.

<h2 id="abstract">Abstract</h2> <p>Introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type with the format <code>0x04 || rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList, yParity, r, s])</code> which sets the sending account's <code>code</code> field in the state trie to the <code>code</code> value at <code>codeAddr</code> and applies the storage tuples to the sender's storage trie.</p> <h2 id="motivation">Motivation</h2> <p>Smart contract wallets have long been touted as the solution to Ethereum's user experience woes. As early as 2015, there were proposals for allowing smart contracts to originate transactions in hopes that new users would flock to smart contract wallets to store their assets. So far, only a fraction of users have elected to do so.</p> <p>Today, account abstraction is still an important goal in Ethereum and there are many efforts attempting to realize it. We're getting closer to succeeding at this, but unfortunately the years of failure have caused many users to simply rely on EOA.</p> <p>After a user has accumulated enough assets in an EOA, it is not tenable to migrate each individual asset to a new address. This is due both to the cost and to needing to manually sign and verify potentially hundreds of transactions.</p> <p>This is an overlooked piece of the problem. Converting <em>existing</em> users to smart contract wallets efficiently will expedite adoption and push forward better support and integrations for smart contract wallets. They will no longer be dismissed as a niche use case.</p> <p>Therefore, we must provide a mechanism, embedded in the protocol, to migrate EOAs to smart contracts. This EIP proposes such mechanism.</p> <h2 id="specification">Specification</h2> <p>At the fork block <code>X</code>, introduce the migration transaction type.</p> <h3 id="migration-transaction">Migration Transaction</h3> <h4 id="definition">Definition</h4> <table><thead><tr><th>field</th><th>type</th></tr></thead><tbody> <tr><td><code>chainId</code></td><td><code>uint256</code></td></tr> <tr><td><code>nonce</code></td><td><code>uint64</code></td></tr> <tr><td><code>maxFeePerGas</code></td><td><code>uint256</code></td></tr> <tr><td><code>maxPriorityFeePerGas</code></td><td><code>uint256</code></td></tr> <tr><td><code>gasLimit</code></td><td><code>uint64</code></td></tr> <tr><td><code>codeAddr</code></td><td><code>address</code></td></tr> <tr><td><code>storage</code></td><td><code>List[Tuple[uint256, uint256]]</code></td></tr> <tr><td><code>data</code></td><td><code>bytes</code></td></tr> <tr><td><code>value</code></td><td><code>uint256</code></td></tr> <tr><td><code>accessList</code></td><td><code>List[Tuple[address, List[uint256]]]</code></td></tr> <tr><td><code>yParity</code></td><td><code>uint8</code></td></tr> <tr><td><code>r</code></td><td><code>uint256</code></td></tr> <tr><td><code>s</code></td><td><code>uint256</code></td></tr> </tbody></table> <p>The EIP-2718 <code>TransactionType</code> is <code>0x04</code> and the <code>TransactionPayload</code> is <code>rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList, yParity, r, s])</code>.</p> <p>The transaction's signature hash is <code>keccak256(0x04 || rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList])</code></p> <h4 id="validation">Validation</h4> <p>A migration transaction is considered valid if the follow properties hold:</p> <ul> <li>all <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> properties, unless specified otherwise</li> <li>the code at <code>codeAddr</code> is less than the <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> limit of <code>24576</code></li> <li>the code at <code>codeAddr</code> must not have size <code>0</code></li> </ul> <p>The intrinsic gas calculation modified from <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> to be <code>21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count + 20000 * length of storage</code>.</p> <h4 id="processing">Processing</h4> <p>Executing a migration transaction has two parts.</p> <h5 id="contract-deployment">Contract Deployment</h5> <p>Unlike standard contract deployment, a migration transaction directly specifies what <code>code</code> value the sender's account should be set to.</p> <p>As the first step of processing the transaction, set the sender's <code>code</code> to <code>state[tx.codeAddr].code</code>. Next, for each tuple in <code>tx.storage</code> and the sender's storage trie, set <code>storage[t.first] = t.second</code>.</p> <h5 id="transaction-execution">Transaction Execution</h5> <p>Now instantiate an EVM call into the sender's account using the same rules as <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> and set the transaction's origin to be <code>keccak256(sender)[0..20]</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="no-to-address-field">No <code>to</code> address field</h3> <p>This transaction is only good for one-time use to migrate an EOA to a smart contract. It is designed to immediately call the deployed contract, which is at the sender's address, after deployment to allow the sender to do any kind of further processing.</p> <h3 id="code-pointer-for-deployment">Code pointer for deployment</h3> <p>Naively, one could design the migration transaction to have a field <code>code</code> of type <code>bytes</code>. However, there would be substantial duplication of code calldata, since many users will want to deploy the exact same thing (often a wallet). Using a pointer instead acknowledges this overwhelming use case for the transaction type, and exploits it as an optimization.</p> <h3 id="cheaper-storage">Cheaper storage</h3> <p>Since the storage is guaranteed to be empty, there is no need to read before write. This means only 20,000 gas is needed to pay for the <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> <code>SSTORE_SET_GAS</code> value. This is a small discount to the normal cost of <code>22,100</code>, which is <code>SSTORE_SET_GAS</code> plus the <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> <code>COLD_SLOAD_COST</code> of <code>2100</code>, because no load occurs.</p> <h3 id="intrinsic-does-not-account-for-contract-deployment">Intrinsic does not account for contract deployment</h3> <p>This takes advantage of the fact that clients tend to store a single, unique copy of code; no matter the number of deployments. Therefore, the only operation here is changing a pointer in the state trie to the desired code.</p> <p>Additionally, the EOA already exists because it has enough balance for the migration transaction to be considered valid. Therefore, we don't need to pay a premium for adding a new account into the state trie.</p> <h3 id="manipulating-transaction-origin">Manipulating transaction origin</h3> <p>Many applications have a security check <code>caller == origin</code> to verify the caller is an EOA. This is done to "protect" assets. While it is usually more of a bandage than an actual fix, we attempt to placate these projects by modifying the origin of the transaction so the check will continue performing its duty.</p> <h3 id="one-time-migration">One-time migration</h3> <p>There is no technical reason we couldn't allow EOAs to change their code at any time with this transaction type. The only inhibitor at the moment is <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a> which will cause migration transactions to be considered invalid if they come from an account with code already deployed. A functional reason for retaining this behavior though is that it makes it simpler to reason about contracts and their upgradability.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="blind-signing">Blind Signing</h3> <p>As with all sufficiently sophisticated account designs, if a user can be convinced to sign an arbitrary message, that message could be a migration transaction which is owned by a malicious actor instead of the user. This can generally be avoided if wallets treat these transactions with <em>extreme</em> care and create as much friction and verification as possible before completing the signature.</p> <h3 id="on-ecrecover">On <code>ecrecover</code></h3> <p>Applications standards such as <a href="https://wg-eips.ritovision.com/2612/">ERC-2612: Permit Extension</a> have exploited the cryptographic relationship between EOA addresses and their private keys. Many tokens today support this extension, allowing EOAs to approve the transfer of fund from their account using only a signature. Although collisions between EOAs and contract accounts are considered unlikely and <a href="https://wg-eips.ritovision.com/3607/">maybe impossible</a> given today's computing power, this EIP would make it common place for private keys to exist for contract accounts. There are some considerations here regarding security:</p> <ul> <li>The obvious attack is a defi protocol deploys some their contract using this EIP and later sign an <a href="https://wg-eips.ritovision.com/2612/">ERC-2612</a> message to steal the funds accrued in the contract. This can be avoided by wallets simply not allowing users to interact with protocols deployed in this manner.</li> <li>It's also worth mentioning that there are concerns around how this EIP will affect the cross chain experience. Ultimately a users private key may still have some control over the account's assets, depending on the exact protocols used on Ethereum and on other chains. It isn't really possible perfectly migrate the EOA at the same time, on all chains. The best thing that can be done is to educate the user that just because their account has been migrated doesn't mean that they are safe to now publicly reveal their private key. This seems like a reasonable request, especially since they'll want to retain the private key in case they want to use the address on any other EVM-like chain.</li> </ul> <p>Something that may alleviate these issues to some degree would be to add an <code>EXTCODEHASH</code> check in <code>ecrecover</code>. If the recovered account has code, the precompile will revert. This would disallow migrated EOAs from using standards like <a href="https://wg-eips.ritovision.com/2612/">ERC-2612</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-07-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 pcaversacciohttps://github.com/pcaversaccio https://wg-eips.ritovision.com/7266/

Remove the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort

<h2 id="abstract">Abstract</h2> <p>This EIP removes the <a href="https://wg-eips.ritovision.com/152/"><code>blake2f</code></a> (<code>0x09</code>) precompile by changing the precompile behaviour to result in an exceptional abort.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/152/">EIP-152</a> has never capitalised on a real-world use case. This fact is clearly reflected in the number of times the address <code>0x09</code> has been invoked (numbers from the date this EIP was created):</p> <ul> <li>The most recent call took place on 6 October 2022.</li> <li>Since its gone live as part of the Istanbul network upgrade on December 7 2019 (block number 9,069,000), <code>0x09</code> has been called only 22,131 times.</li> </ul> <p>One of the reasons why <a href="https://wg-eips.ritovision.com/152/">EIP-152</a> has failed is that the envisioned use cases were not validated before inclusion.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>All <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, and <code>STATICCALL</code> invocations to the <code>blake2f</code> precompile address <code>0x09</code> MUST result in an exceptional halting state that consumes all supplied gas and returns no data.</p> <h2 id="rationale">Rationale</h2> <p>The EVM should be optimised for simplicity and future-proofness. The original Yellow Paper states: <em>these are so-called 'precompiled' contracts, meant as a preliminary piece of architecture that may later become native extensions</em>. Considering that no use cases have been realised in the last 3.5 years, we can conclude that the precompile <code>blake2f</code> (<code>0x09</code>) will never transition into a native opcode. In that sense, the precompile <code>blake2f</code> (<code>0x09</code>) is an obsolete carry-along with no real-world traction and thus should be removed. This removal will simplify the EVM to the extent that it only consists of clear instructions with real-world use cases. Eventually, the precompile <code>blake2f</code> (<code>0x09</code>) can be safely used as a test run for the phase-out and removal of EVM functions.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork as it modifies the consensus rules. Note that very few applications are affected by this change and a lead time of 6-12 months can be considered sufficient.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known additional security considerations introduced by this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-07-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Erick Pacheco Pedrazahttps://github.com/eum602 Marcos Allendemallende@lacnet.com Diego Lopez Leóndieguitoll@gmail.com https://wg-eips.ritovision.com/7619/

Add precompiled contract that allows generic signature verifications using Falcon512 postquantum algorithm

<h2 id="abstract">Abstract</h2> <p>Include a precompiled signature verification function using Falcon-512. Falcon-512 is a candidate for standardization by the National Institute of Standards and Technology (NIST) and is quantum resistant with security level I.</p> <h2 id="motivation">Motivation</h2> <p>The advent of quantum computing threatens blockchain protocols and networks because they utilize non-quantum resistant cryptographic algorithms. When quantum computers become robust enough to run Shor’s algorithm (a quantum algorithm to find the prime factors of an integer) on a large scale, the most used asymmetric algorithms, utilized for digital signatures and message encryption, such as RSA, (EC)DSA, and (EC)DH, will be no longer secure. Quantum computers will be able to break them within a short period of time. Today, there are hundreds of billions of dollars denominated in cryptocurrencies and other digital assets that rely on blockchain ledgers as well as thousands of blockchain-based applications storing value in blockchain networks. Cryptocurrencies and blockchain-based applications require solutions that guarantee quantum resistance in order to preserve the integrity of data and assets in these public and immutable ledgers. Most proposals for quantum-resistant blockchain networks are theoretical, require large QKD (quantum key distribution, a secure communication method that implements a cryptographic protocol involving components of quantum mechanics) networks, or propose new quantum-resistant blockchain protocols to be built from scratch. This EIP is pioneer in proposing a solution compatible with current EVM blockchain protocols. It presents a simple mechanism to add a NIST-compliant post-quantum signature to blockchain transactions, making them quantum-resistant even when ECC (elliptic curve cryptography) cryptography becomes vulnerable against attacks by quantum computers. We have developed a Solidity implementation for the on-chain verification of this signatures, which does not scale due to the required high amount of gas. This is why <strong>this EIP is proposing a pre-compiled smart contract</strong> that allows to verify post-quantum signatures in a scalable manner.</p> <h2 id="specification">Specification</h2> <p>A clean implementation for Falcon-512 algorithm was brought from the PQClean project.</p> <p>The precompiled signature verification function runs at address <code>0x65</code>. The required inputs are:</p> <ul> <li><code>public key</code> - Falcon Public key of 897 bytes</li> <li><code>signature</code> - 666 bytes (max size)</li> <li><code>message</code> - an arbitrary number of bytes representing the message that was signed</li> </ul> <p>Those inputs are encoded according to:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[pubkey:897 bytes][signature:666 bytes][message: remainder]</span></span></code></pre> <p>Output is:</p> <ul> <li><code>result</code> - A successful signature verification returns <code>0000000000000000000000000000000000000000000000000000000000000001</code>, otherwise <code>0000000000000000000000000000000000000000000000000000000000000000</code> indicating all other failure cases where sufficient gas has been provided.</li> </ul> <p>The precompile will only revert in the case where insufficient gas has been provided. Data format errors, size errors, and invalid signatures will not cause the precompile to revert.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> Input: &quot;&quot;,</span></span> <span class="giallo-l"><span> Gas: 10,</span></span> <span class="giallo-l"><span> ExpectedError: &quot;out of gas&quot;,</span></span> <span class="giallo-l"><span> Name: &quot;empty input, too little gas&quot;,</span></span> <span class="giallo-l"><span> },</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> Input: &quot;111111110000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000032000000000000000000000000000000000000000000000000000000000000006e0&quot;,</span></span> <span class="giallo-l"><span> Gas: 1000000,</span></span> <span class="giallo-l"><span> Result: &quot;000000000000000000000000000000000000000000000000000000000000000000000000&quot;,</span></span> <span class="giallo-l"><span> Name: &quot;garbled input&quot;,</span></span> <span class="giallo-l"><span> }</span></span></code></pre><h3 id="example-usage-in-solidity">Example Usage in Solidity</h3> <p>The precompile can be wrapped in Solidity to provide a more development-friendly interface to <code>Falcon-512</code> signature verification.</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> verify</span><span>(</span></span> <span class="giallo-l"><span class="z-support"> bytes</span><span class="z-storage z-type"> calldata</span><span class="z-variable"> publicKey</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> bytes</span><span class="z-storage z-type"> calldata</span><span class="z-variable"> signature</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> bytes</span><span class="z-storage z-type"> calldata</span><span class="z-variable"> message</span></span> <span class="giallo-l"><span> )</span><span class="z-storage z-type"> public</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">bool</span><span class="z-variable"> isValid</span><span>)</span><span> {</span></span> <span class="giallo-l"><span> (</span><span class="z-support">bool</span><span> success</span><span>,</span><span class="z-support"> bytes</span><span class="z-storage z-type"> memory</span><span> verifies</span><span>)</span><span class="z-keyword"> =</span><span class="z-support"> address</span><span>(</span><span class="z-constant">0x0000000000000000000000000000000000000065</span><span>)</span></span> <span class="giallo-l"><span> .</span><span class="z-entity z-name">staticcall</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-language"> abi</span><span>.</span><span class="z-entity z-name">encodePacked</span><span>(</span></span> <span class="giallo-l"><span> publicKey</span><span>,</span></span> <span class="giallo-l"><span> signature</span><span>,</span></span> <span class="giallo-l"><span> message</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> )</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> require</span><span>(</span><span>success </span><span class="z-keyword">&amp;&amp;</span><span> verifies</span><span>.</span><span>length </span><span class="z-keyword">==</span><span class="z-constant"> 32</span><span>,</span><span class="z-string"> &quot;Invalid signature&quot;</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> verifies</span><span>[</span><span class="z-constant">31</span><span>]</span><span class="z-keyword"> ==</span><span class="z-constant"> 1</span><span>;</span></span> <span class="giallo-l"><span> }</span></span></code></pre><h3 id="gas-costs">Gas costs</h3> <p>Since data size is variable, each operation to execute the precompiled call will require:</p> <ul> <li>1465 base units of gas for each operation.</li> <li>6 units of gas for each word contained in the payload. These values are based on results presented at the <a href="https://wg-eips.ritovision.com/7619/#benchmarks">benchmarks</a> section.</li> </ul> <h2 id="rationale">Rationale</h2> <p>Falcon-512 is a good candidate for a new signature implementation. Key sizes in Falcon-512 are relatively small compared to other post-quantum signature algorithms.</p> <p>The following table shows a summary of the typical values for keys and the approximate amount of time taken per second to execute signature verifications as specified by the authors of Falcon algorithm:</p> <table><thead><tr><th><strong>variant</strong></th><th><strong>verify/s</strong></th><th><strong>pub size(bytes)</strong></th><th><strong>sig size(bytes)</strong></th></tr></thead><tbody> <tr><td>Falcon512</td><td>27933.0</td><td>897</td><td>666</td></tr> </tbody></table> <p>Falcon uses shake256 under the hood, an implementation made in solidity showed it is not viable to implement this algorithm at that layer, on the other hand the implementation of falcon-512 by using precompiles turned to be the best approach since the gas cost (as shown in the previous section) is relatively low.</p> <p>Implementing just the signature verification is sufficiently enough to open a wide range of use cases at the smart contract level. To give an example, this method can perfectly work with the Account Abstraction concept, where the authentication process would rely on Falcon and the account is a smart contract.</p> <h3 id="benchmarks">benchmarks</h3> <p>Assuming ecRecover precompile is perfectly priced, a set of benchmarks were executed comparing Falcon-512 signature verification function precompile with ecRecover precompile. For benchmarks, it was used 2.6 GHz Intel Core i7 64-bit machine.</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name">$</span><span class="z-string"> cat</span><span class="z-string"> /proc/cpuinfo</span><span class="z-keyword"> |</span><span class="z-entity z-name"> grep</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">model name</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-entity z-name">Intel(R</span><span>) Core(</span><span class="z-entity z-name">TM</span><span>) i7-10750H CPU @ 2.60GHz</span></span></code></pre><h4 id="5-seconds-benchmark">5 seconds benchmark</h4> <p>Based on <a href="https://wg-eips.ritovision.com/7619/assets/bench_vectors/">100 test vectors with valid signatures</a> a benchmark of 5 seconds, for each test vector, was performed, considering the following:</p> <ul> <li>the average time per operation (ns/op),</li> <li>each vector size increases in 33 bytes</li> <li>Ecrecover is well tested</li> </ul> <p>Benchmark results <a href="https://wg-eips.ritovision.com/7619/assets/benchmark_results/">here</a></p> <p>Then the 100 BenchmarkPrecompiledFalcon512 results were approximated to a linear equation dependent on the number of bytes in each test vector. From the approximation it was concluded that 1465 units of gas is the base requirement for any falcon-512 signature validation and 6 gas per word is additionally required.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at <code>0x65</code> being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li> <p>A set of test vectors, with valid signatures, for benchmarking on new implementations is located in a separate <a href="https://wg-eips.ritovision.com/7619/assets/bench_vectors/">file</a></p> </li> <li> <p>A set of test vectors, with invalid data, to verify some invalid signature cases is located in a separate <a href="https://wg-eips.ritovision.com/7619/assets/invalid_signature_test_vectors/">file</a></p> </li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Since the scope of this proposal is encapsulated at the contract level for verifying signatures it doesn't represent issues in regards to security.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-06-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 mikehttps://github.com/michaelneuder Francescohttps://github.com/fradamt dapplionhttps://github.com/dapplion Mikhailhttps://github.com/mkalinin Adityahttps://github.com/adiasg Justinhttps://github.com/justindrake lightclienthttps://github.com/lightclient Felix Langehttps://github.com/fjl https://wg-eips.ritovision.com/7251/

Allow validators to have larger effective balances, while maintaining the 32 ETH lower bound.

<h2 id="abstract">Abstract</h2> <p>Increases the constant <code>MAX_EFFECTIVE_BALANCE</code>, while keeping the minimum staking balance <code>32 ETH</code>. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.</p> <h2 id="motivation">Motivation</h2> <p>As of October 3, 2023, there are currently over 830,000 validators participating in the consensus layer. The size of this set continues to grow due, in part, to the <code>MAX_EFFECTIVE_BALANCE</code>, which limits the stake of a single validator to <code>32 ETH</code>. This leads to large amounts of "redundant validators", which are controlled by a single entity, possibly running on the same beacon node, but with distinct BLS signing keys. The limit on the <code>MAX_EFFECTIVE_BALANCE</code> is technical debt from the original sharding design, in which subcommittees (not the attesting committee but the committee calculated in <code>is_aggregator</code>) needed to be majority honest. As a result, keeping the weights of subcommittee members approximately equal reduced the risk of a single large validator containing too much influence. Under the current design, these subcommittees are only used for attestation aggregation, and thus only have a <code>1/N</code> honesty assumption.</p> <p>With the security model of the protocol no longer dependent on a low value for <code>MAX_EFFECTIVE_BALANCE</code>, we propose raising this value while keeping the minimum validator threshold of <code>32 ETH</code>. This increase aims to reduce the validator set size, thereby reducing the number of P2P messages over the network, the number of BLS signatures that need to be aggregated each epoch, and the <code>BeaconState</code> memory footprint. This change adds value for both small and large validators. Large validators can consolidate to run fewer validators and thus fewer beacon nodes. Small validators now benefit from compounding rewards and the ability to stake in more flexible increments (e.g., the ability to stake <code>40 ETH</code> instead of needing to accumulate <code>64 ETH</code> to run two validators today).</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <h4 id="execution-layer">Execution layer</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>CONSOLIDATION_REQUEST_TYPE</code></td><td><code>0x02</code></td><td>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> type prefix for consolidation request</td></tr> <tr><td><code>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code></td><td><code>0x0000BBdDc7CE488642fb579F8B00f3a590007251</code></td><td>Where to call and store relevant details about consolidation request mechanism</td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td><td>Address used to invoke system operation on contract</td></tr> <tr><td><code>EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</code></td><td><code>0</code></td><td></td></tr> <tr><td><code>CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</code></td><td><code>1</code></td><td></td></tr> <tr><td><code>CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</code></td><td><code>2</code></td><td>Pointer to the head of the consolidation request message queue</td></tr> <tr><td><code>CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</code></td><td><code>3</code></td><td>Pointer to the tail of the consolidation request message queue</td></tr> <tr><td><code>CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</code></td><td><code>4</code></td><td>The start memory slot of the in-state consolidation request message queue</td></tr> <tr><td><code>MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</code></td><td><code>2</code></td><td>Maximum number of consolidation requests that can be dequeued into a block</td></tr> <tr><td><code>TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</code></td><td><code>1</code></td><td></td></tr> <tr><td><code>MIN_CONSOLIDATION_REQUEST_FEE</code></td><td><code>1</code></td><td></td></tr> <tr><td><code>CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION</code></td><td><code>17</code></td><td></td></tr> <tr><td><code>EXCESS_INHIBITOR</code></td><td><code>2**256-1</code></td><td>Excess value used to compute the fee before the first system call</td></tr> </tbody></table> <h4 id="consensus-layer">Consensus layer</h4> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><code>COMPOUNDING_WITHDRAWAL_PREFIX</code></td><td><code>Bytes1('0x02')</code></td></tr> <tr><td><code>MIN_ACTIVATION_BALANCE</code></td><td><code>Gwei(2**5 * 10**9)</code> (32 ETH)</td></tr> <tr><td><code>MAX_EFFECTIVE_BALANCE_ELECTRA</code></td><td><code>Gwei(2**11 * 10**9)</code> (2048 ETH)</td></tr> </tbody></table> <h3 id="execution-layer-1">Execution layer</h3> <h4 id="consolidation-request">Consolidation request</h4> <p>The new consolidation request is an <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request with type <code>0x02</code> consisting of the following fields:</p> <ol> <li><code>source_address</code>: <code>Bytes20</code></li> <li><code>source_pubkey</code>: <code>Bytes48</code></li> <li><code>target_pubkey</code>: <code>Bytes48</code></li> </ol> <p>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> encoding of a consolidation request is as follows. Note we simply return the encoded request value as returned by the contract.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>request_type</span><span class="z-keyword"> =</span><span class="z-constant"> CONSOLIDATION_REQUEST_TYPE</span></span> <span class="giallo-l"><span>request_data</span><span class="z-keyword"> =</span><span> dequeue_consolidation_requests</span><span>(</span><span>)</span></span></code></pre><h4 id="consolidation-request-contract">Consolidation request contract</h4> <p>The contract has three different code paths, which can be summarized at a high level as follows:</p> <ol> <li>Add consolidation request - requires a <code>96</code> byte input, concatenated public keys of the source and the target validators.</li> <li>Fee getter - if the input length is zero, return the current fee required to add a consolidation request.</li> <li>System process - if called by system address, pop off the consolidation requests for the current block from the queue.</li> </ol> <h5 id="add-consolidation-request">Add Consolidation Request</h5> <p>If call data input to the contract is exactly <code>96</code> bytes, perform the following:</p> <ol> <li>Ensure enough ETH was sent to cover the current consolidation request fee (<code>msg.value &gt;= get_fee()</code>)</li> <li>Increase consolidation request count by <code>1</code> for the current block (<code>increment_count()</code>)</li> <li>Insert a consolidation request into the queue for the source address and pubkeys of the source and the target (<code>insert_consolidation_request_into_queue()</code>)</li> </ol> <p>Specifically, the functionality is defined in pseudocode as the function <code>add_consolidation_request()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> add_consolidation_request</span><span>(</span><span class="z-variable z-parameter z-function">Bytes48</span><span>:</span><span> source_pubkey</span><span>,</span><span class="z-variable z-parameter z-function"> Bytes48</span><span>:</span><span> target_pubkey</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Add consolidation request adds new request to the consolidation request queue, so long as a sufficient fee is provided.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sufficient fee was provided.</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span> get_fee</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>msg</span><span>.</span><span>value</span><span class="z-keyword"> &gt;=</span><span> fee</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Insufficient value for fee</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Increment consolidation request count.</span></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span> count</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Insert into queue.</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> queue_tail_index</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>,</span><span> msg</span><span>.</span><span>sender</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>,</span><span> source_pubkey</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>,</span><span> source_pubkey</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">48</span><span>]</span><span class="z-invalid z-illegal"> ++</span><span> target_pubkey</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">16</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 3</span><span>,</span><span> target_pubkey</span><span>[</span><span class="z-constant">16</span><span>:</span><span class="z-constant">48</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span> queue_tail_index</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span></code></pre><h6 id="fee-calculation">Fee calculation</h6> <p>The following pseudocode can compute the cost of an individual consolidation request, given a certain number of excess consolidation requests.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_fee</span><span>(</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>excess</span><span class="z-keyword"> !=</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Inhibitor still active</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_CONSOLIDATION_REQUEST_FEE</span><span>,</span></span> <span class="giallo-l"><span> excess</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> fake_exponential</span><span>(</span><span class="z-variable z-parameter z-function">factor</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> numerator</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> denominator</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> factor</span><span class="z-keyword"> *</span><span> denominator</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> numerator_accum</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> +=</span><span> numerator_accum</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> (</span><span>numerator_accum</span><span class="z-keyword"> *</span><span> numerator</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span>denominator</span><span class="z-keyword"> *</span><span> i</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> output</span><span class="z-keyword"> //</span><span> denominator</span></span></code></pre><h5 id="fee-getter">Fee Getter</h5> <p>When the input to the contract is length zero, interpret this as a get request for the current fee, i.e. the contract returns the result of <code>get_fee()</code>.</p> <h5 id="system-call">System Call</h5> <p>At the end of processing any execution block where this EIP is active (i.e. after processing all transactions and after performing the block body consolidation requests validations), call the contract at <code>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> as <code>SYSTEM_ADDRESS</code> with no calldata. The invocation triggers the following:</p> <ul> <li>The contract's queue is updated based on consolidation requests dequeued and the consolidation requests queue head/tail are reset if the queue has been cleared (<code>dequeue_consolidation_requests()</code>)</li> <li>The contract's excess consolidation requests are updated based on usage in the current block (<code>update_excess_consolidation_requests()</code>)</li> <li>The contract's consolidation requests count is reset to <code>0</code> (<code>reset_consolidation_requests_count()</code>)</li> </ul> <p>Each consolidation request must appear in the EIP-7685 requests list in the exact order returned by <code>dequeue_consolidation_requests()</code>.</p> <p>Additionally, the system call and the processing of that block must conform to the following:</p> <ul> <li>The call has a dedicated gas limit of <code>30_000_000</code>.</li> <li>Gas consumed by this call does not count against the block’s overall gas usage.</li> <li>Both the gas limit assigned to the call and the gas consumed are excluded from any checks against the block’s gas limit.</li> <li>The call does not follow <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> fee burn semantics — no value should be transferred as part of this call.</li> <li>If there is no code at <code>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code>, the corresponding block <strong>MUST</strong> be marked invalid.</li> <li>If the call to the contract fails or returns an error, the block <strong>MUST</strong> be invalidated.</li> </ul> <p>The functionality triggered by the system call is defined in pseudocode as the function <code>process_consolidation_requests()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Public function #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_consolidation_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> dequeue_consolidation_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> update_excess_consolidation_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> reset_consolidation_requests_count</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ssz</span><span>.</span><span>serialize</span><span>(</span><span>reqs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Helpers #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ConsolidationRequest</span><span>(</span><span class="z-support">object</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> source_address</span><span>:</span><span> Bytes20</span></span> <span class="giallo-l"><span> source_pubkey</span><span>:</span><span> Bytes48</span></span> <span class="giallo-l"><span> target_pubkey</span><span>:</span><span> Bytes48</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> dequeue_consolidation_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_head_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> num_in_queue</span><span class="z-keyword"> =</span><span> queue_tail_index</span><span class="z-keyword"> -</span><span> queue_head_index</span></span> <span class="giallo-l"><span> num_dequeued</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>num_in_queue</span><span>,</span><span class="z-constant"> MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>num_dequeued</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> (</span><span>queue_head_index</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 4</span></span> <span class="giallo-l"><span> source_address</span><span class="z-keyword"> =</span><span> address</span><span>(</span><span>sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">20</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> source_pubkey</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span class="z-keyword"> +</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">16</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> target_pubkey</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">16</span><span>:</span><span class="z-constant">32</span><span>]</span><span class="z-keyword"> +</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 3</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> req</span><span class="z-keyword"> =</span><span> ConsolidationRequest</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> source_address</span><span class="z-keyword">=</span><span>Bytes20</span><span>(</span><span>source_address</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> source_pubkey</span><span class="z-keyword">=</span><span>Bytes48</span><span>(</span><span>source_pubkey</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> target_pubkey</span><span class="z-keyword">=</span><span>Bytes48</span><span>(</span><span>target_pubkey</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> reqs</span><span>.</span><span>append</span><span>(</span><span>req</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_queue_head_index</span><span class="z-keyword"> =</span><span> queue_head_index</span><span class="z-keyword"> +</span><span> num_dequeued</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> new_queue_head_index</span><span class="z-keyword"> ==</span><span> queue_tail_index</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Queue is empty, reset queue pointers</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span> new_queue_head_index</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> reqs</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> update_excess_consolidation_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check if excess needs to be reset to 0 for first iteration after activation</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> ==</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</span><span>:</span></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span><span>,</span><span> new_excess</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> reset_consolidation_requests_count</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span></code></pre><h5 id="bytecode">Bytecode</h5> <pre class="giallo z-code"><code data-lang="asm"><span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push20 </span><span class="z-constant">0xfffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xd3</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x11</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x019a</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x68</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup5</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4d</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>swap4</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x88</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x019a</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x019a</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span>lt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x019a</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x40</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span>calldatacopy</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x74</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>log0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>stop</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xe7</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0129</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x74</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xe9</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x013b</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0146</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0173</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0188</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x018e</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x74</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span></code></pre><h5 id="deployment">Deployment</h5> <p>The consolidation requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">to</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x3d090</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gasPrice</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xe8d4a51000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxPriorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">value</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">input</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5561019e80602d5f395ff33373fffffffffffffffffffffffffffffffffffffffe1460d35760115f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff1461019a57600182026001905f5b5f82111560685781019083028483029004916001019190604d565b9093900492505050366060146088573661019a573461019a575f5260205ff35b341061019a57600154600101600155600354806004026004013381556001015f358155600101602035815560010160403590553360601b5f5260605f60143760745fa0600101600355005b6003546002548082038060021160e7575060025b5f5b8181146101295782810160040260040181607402815460601b815260140181600101548152602001816002015481526020019060030154905260010160e9565b910180921461013b5790600255610146565b90505f6002555f6003555b5f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff141561017357505f5b6001546001828201116101885750505f61018e565b01600190035b5f555f6001556074025ff35b5f5ffd</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">v</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">r</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x539</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">s</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xc0730f92dc275b663d377a7cbb141b6600052</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x379269d571beff3ed1d8eba3abb24076a7267b0eaf0cc66d728fb0544f5a690d</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Sender: 0x13d1913d623E6a9D8811736359E50fD31Fe54fCA</span></span> <span class="giallo-l"><span>Address: 0x0000BBdDc7CE488642fb579F8B00f3a590007251</span></span></code></pre><h3 id="consensus-layer-1">Consensus layer</h3> <p>The defining features of this EIP are:</p> <ol> <li><em><strong>Increasing the <code>MAX_EFFECTIVE_BALANCE</code>, while creating a <code>MIN_ACTIVATION_BALANCE</code>.</strong></em> The core feature of allowing variable size validators.</li> <li><em><strong>Allowing for multiple validator indices to be combined through the protocol.</strong></em> A mechanism by which large node operators can combine validators without cycling through the exit and activation queues.</li> <li><em><strong>Adding execution layer partial withdrawals (part of <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a>).</strong></em> Allowing Execution Layer messages to trigger partial withdrawals in addition to full exits (e.g., a <code>100 ETH</code> validator can remove up to <code>68 ETH</code> without exiting the validator).</li> <li><em><strong>Making the initial slashing penalty negligible.</strong></em> This reduces the risk of consolidation for large validators.</li> </ol> <p>The <a href="https://wg-eips.ritovision.com/7251/#rationale">Rationale</a> section contains an explanation for each of these proposed core features. A sketch of the resulting changes to the consensus layer is included below.</p> <ol> <li>Add <code>COMPOUNDING_WITHDRAWAL_PREFIX</code> and <code>MIN_ACTIVATION_BALANCE</code> constants, while introducing the updated value of <code>MAX_EFFECTIVE_BALANCE</code> (<code>MAX_EFFECTIVE_BALANCE_ELECTRA</code>).</li> <li>Create the <code>PendingDeposit</code> container, which is used to track incoming deposits in the weight-based rate limiting mechanism.</li> <li>Update the <code>BeaconState</code> with deposit and partial withdrawal queues, fields needed for deposit, and exit queue weight-based rate limiting.</li> <li>Modify <code>is_eligible_for_activation_queue</code> to check against <code>MIN_ACTIVATION_BALANCE</code> rather than <code>MAX_EFFECTIVE_BALANCE</code>.</li> <li>Modify <code>get_validator_churn_limit</code> to depend on the validator weight rather than the validator count.</li> <li>Create a helper <code>compute_exit_epoch_and_update_churn</code> to calculate the exit epoch based on the current pending withdrawals.</li> <li>Modify <code>initiate_validator_exit</code> to rate limit the exit queue by balance rather than the number of validators.</li> <li>Modify <code>initialize_beacon_state_from_eth1</code> to use <code>MIN_ACTIVATION_BALANCE</code>.</li> <li>Modify <code>process_registry_updates</code> to activate all eligible validators.</li> <li>Add a per-epoch helper, <code>process_pending_deposits</code>, to consume some of the pending deposits.</li> <li>Modify <code>get_validator_from_deposit</code> to initialize the effective balance to zero (it's updated by the pending deposit flow).</li> <li>Modify <code>process_deposit</code> to store incoming deposits in <code>state.pending_deposits</code>.</li> <li>Modify <code>compute_weak_subjectivity_period</code> to use the new churn limit function.</li> <li>Add <code>has_compounding_withdrawal_credential</code> to check for the <code>0x02</code> credential.</li> <li>Modify <code>is_fully_withdrawable_validator</code> to check for compounding credentials.</li> <li>Add <code>get_validator_excess_balance</code> to calculate the excess balance of validators.</li> <li>Modify <code>is_partially_withdrawable_validator</code> to check for excess balance.</li> <li>Modify <code>get_expected_withdrawals</code> to use excess balance and process pending partial withdrawals.</li> <li>Add <code>process_consolidation</code> to initiate in-protocol validator consolidation and switch a validator to compounding withdrawal credentials.</li> <li>Limits the usage of exit churn to 256 ETH (equivalent to 8 validators with 32 ETH effective balance), and defers the surplus of the churn to process consolidations.</li> </ol> <p>Full consensus layer specification can be found in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/834e40604ae4411e565bd6540da50b008b2496dc/specs/electra/beacon-chain.md"><code>./electra/beacon-chain.md</code></a></p> <h2 id="rationale">Rationale</h2> <p>This EIP aims to reduce the total number of validators without changing anything about the economic security of the protocol. It provides a mechanism by which large node operators who control significant amounts of stake can consolidate into fewer validators. We analyze the reasoning behind each of the core features.</p> <h3 id="increasing-the-max-effective-balance-while-creating-a-min-activation-balance">Increasing the <code>MAX_EFFECTIVE_BALANCE</code>, while creating a <code>MIN_ACTIVATION_BALANCE</code></h3> <p>While increasing the <code>MAX_EFFECTIVE_BALANCE</code> to allow larger-stake validators, it is important to keep the lower bound of <code>32 ETH</code> (by introducing a new constant – <code>MIN_ACTIVATION_BALANCE</code>) to encourage solo-staking.</p> <h3 id="allowing-for-multiple-validator-indices-to-be-combined-through-the-protocol">Allowing for multiple validator indices to be combined through the protocol</h3> <p>For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.</p> <h3 id="adding-execution-layer-partial-withdrawals-part-of-eip-7002">Adding execution layer partial withdrawals (part of <a href="https://wg-eips.ritovision.com/7002/">EIP-7002</a>)</h3> <p>For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.</p> <h3 id="making-the-initial-slashing-penalty-negligible">Making the initial slashing penalty negligible</h3> <p>To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of <code>1/32</code> of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.</p> <h3 id="consolidation-contract-parameter-values">Consolidation contract parameter values</h3> <p>The consolidation smart contract uses a fee mechanism to rate limit the number of requests per block. Details of the fee mechanism are available in <a href="https://wg-eips.ritovision.com/7002/#fee-update-rule">EIP-7002</a>.</p> <p><code>TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</code> is chosen to be <code>1</code> to rate limit consolidation requests as much as possible. <code>MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</code> is chosen to be <code>2</code> to allow for switching a validator to compounding credentials and requesting a consolidation in the same block.</p> <p>One consolidation per block is still higher than the size of consolidation churn which can lead to unbounded growth of the consolidation queue. Thus, there is a hard limit on the consolidation queue size equal to 262,144 requests which is <code>4 MB</code> of data in the beacon state.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the block validation rule set and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This change modifies committees and churn, but doesn't significantly impact the security properties.</p> <h3 id="security-of-attestation-committees">Security of attestation committees</h3> <p>Given full consolidation as the worst case, the probability of an adversarial takeover of a committee remains low. Even in a high consolidation scenario, the required share of honest validators remains well below the 2/3 supermajority needed for finality.</p> <h3 id="aggregator-selection">Aggregator selection</h3> <p>In the original sharding roadmap, subcommittees were required to be secure with extremely high probability. Now with the sole responsibility of attestation aggregation, we only require each committee to have at least one honest aggregator. Currently, aggregators are selected through a VRF lottery, targeting several validator units that can be biased by non-consolidated attackers. This proposal changes the VRF lottery to consider weight, so the probability of having at least one honest aggregator is not worse.</p> <h3 id="proposer-selection-probability">Proposer selection probability</h3> <p>Proposer selection is already weighted by the ratio of their effective balance to <code>MAX_EFFECTIVE_BALANCE</code>. Due to the lower probabilities, this change will slightly increase the time it takes to calculate the next proposer index.</p> <h3 id="sync-committee-selection-probability">Sync committee selection probability</h3> <p>Sync committee selection is also already weighted by effective balance, so this proposal does not require modifications to the sync protocol. Light clients can still check that a super-majority of participants have signed an update irrespective of their weights since we maintain a weight-based selection probability.</p> <h3 id="churn-invariants">Churn invariants</h3> <p>This proposal maintains the activation and exit churn invariants limiting active weight instead of validator count. Balance top-ups are now handled explicitly, being subject to the same activation queue as full deposits.</p> <h3 id="fee-overpayment">Fee Overpayment</h3> <p>Calls to the system contract require a fee payment defined by the current contract state. Overpaid fees are not returned to the caller. It is not generally possible to compute the exact required fee amount ahead of time. When adding a consolidation request from a contract, the contract can perform a read operation to check for the current fee and then pay exactly the required amount. Here is an example in Solidity:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function addConsolidation(bytes memory srcPubkey, bytes memory targetPubkey, uint64 requestFeeLimit) private {</span></span> <span class="giallo-l"><span> assert(srcPubkey.length == 48);</span></span> <span class="giallo-l"><span> assert(targetPubkey.length == 48);</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Read current fee from the contract.</span></span> <span class="giallo-l"><span> (bool readOK, bytes memory feeData) = ConsolidationsContract.staticcall(&#39;&#39;);</span></span> <span class="giallo-l"><span> if (!readOK) {</span></span> <span class="giallo-l"><span> revert(&#39;reading fee failed&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> uint256 fee = uint256(bytes32(feeData));</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Check the fee is not too high.</span></span> <span class="giallo-l"><span> if (fee &gt; requestFeeLimit) {</span></span> <span class="giallo-l"><span> revert(&#39;fee is too high&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Add the request.</span></span> <span class="giallo-l"><span> bytes memory callData = bytes.concat(srcPubkey, targetPubkey);</span></span> <span class="giallo-l"><span> (bool writeOK,) = ConsolidationsContract.call{value: fee}(callData);</span></span> <span class="giallo-l"><span> if (!writeOK) {</span></span> <span class="giallo-l"><span> revert(&#39;adding request failed&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Note: the system contract uses the EVM <code>CALLER</code> operation (Solidity: <code>msg.sender</code>) to get the address used in the consolidation request, i.e. the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.</p> <p>Note: the above code reverts if the fee is too high, the fee can change significantly between the creation of a consolidation request transaction and its inclusion into a block, thus, this check is very important to avoid overpayments.</p> <p>Using an EOA to request consolidations will always result in overpayment of fees. There is no way for an EOA to use a wrapper contract to request a consolidation. And even if a way existed, the gas cost of returning the overage would likely be higher than the overage itself. If requesting consolidations from an EOA to the system contract is desired, we recommend that users perform transaction simulations to estimate a reasonable fee amount to send.</p> <h3 id="consolidation-queue-hard-limit">Consolidation queue hard limit</h3> <p>Consolidations exceeding the hard limit of the consolidation queue (262,144 requests) will be discarded by the consensus layer and will need to be re-submitted, note that the fee is not refunded in this case.</p> <h3 id="system-call-failure">System Call failure</h3> <p>Although the likelihood of a failed system call to <code>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> is extremely low, the behavior in such cases is well-defined: the block is marked as invalid. This consideration directly follows from <a href="https://wg-eips.ritovision.com/7002/#system-call-failure">EIP-7002</a></p> <h3 id="empty-code-failure">Empty Code failure</h3> <p>This EIP should not have been activated if there is no code present at <code>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> (i.e., if the chain is not "ready"). This is also similar to the consideration in <a href="https://wg-eips.ritovision.com/7002/#empty-code-failure">EIP-7002</a></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lionhttps://github.com/dapplion https://wg-eips.ritovision.com/7044/

Lock voluntary exit signature domain on capella for perpetual validity

<h2 id="abstract">Abstract</h2> <p>Lock validator voluntary exit signature domain on Capella for perpetual validity. Currently, signed voluntary exits are only valid for two upgrades.</p> <h2 id="motivation">Motivation</h2> <p>Currently, signed voluntary exits are valid up-to only two upgrades for block inclusion due to the Beacon Chain state considering only the current and previous fork version. This limitation increases the complexity of some staking operations, specifically those in which the staking operator (holder of active key) is distinct from the owner of the funds (holder of the withdrawal credential). Because voluntary exits can only be signed by the active key, such a relationship requires the exchange of signed exits ahead of time for an unbounded number of forks.</p> <p>The limited validity of voluntary exits was originally motivated to isolate them in the event of a hard fork that results in two maintained chains. If fork A and B exist and a validator operates on both, if they send an exit, it will be replayable on both. However, this possibility is not sufficient to justify the UX degradation exposed above, as no funds are at risk and the staker can re-stake on one or both of the chains.</p> <h2 id="specification">Specification</h2> <h3 id="consensus-layer">Consensus Layer</h3> <p>Specification changes are built into the Consensus Specs Deneb upgrade.</p> <p>The specific makes one change to the state transition function:</p> <ul> <li>Modify <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/75971a8c218b1d76d605dd8b88a08d39c42de221/specs/deneb/beacon-chain.md#modified-process_voluntary_exit"><code>process_voluntary_exit</code></a> to compute the signing domain and root fixed on <code>CAPELLA_FORK_VERSION</code>.</li> </ul> <p>Additionally, the <code>voluntary_exit</code> gossip conditions are implicitly modified to support this change.</p> <p>To make the change backwards compatible the signature domain is locked on the Capella fork</p> <h3 id="execution-layer">Execution Layer</h3> <p>This specification does not require any changes to the Execution Layer.</p> <h2 id="rationale">Rationale</h2> <p>Perpetually valid signed voluntary exits allow simpler staking operation designs. It also aligns the UX of such objects to <code>BLSToExecutionChanges</code> and deposits, such that downstream tooling does not need to be updated with fork version information.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is backwards compatible to the Consensus Layer of Ethereum block processing logic.</p> <p>The expectation of future validity of exits is not forward compatible. Specifically, users who have already pre-signed exits utilizing the Deneb fork domain with an expectation of their validity should be aware that these pre-signed exits will no longer be recognized as valid. Consequently, users should adjust their approach moving forward. For continued validity across forks, including Deneb and subsequent forks, users should ensure that their exits are signed using the Capella fork domain.</p> <p>There are no forwards/backwards compatibility issues with the Execution Layer.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for this EIP can be found in the <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/2297c09b7e457a13f7b2261a28cb45777be82f83/tests/core/pyspec/eth2spec/test/deneb"><code>deneb</code></a> test suite of the <code>consensus-specs</code> repository.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The divergent signature domains across forked networks would previously have prevented the replay of VoluntaryExits after two hard forks. This specification change causes the replay protection to no longer exist. These potential replays could impact individual stakers on both sides of a fork, but does not put funds at risk and does not impact the security of the chain.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danny Ryanhttps://github.com/djrtwo https://wg-eips.ritovision.com/7045/

Increases max attestation inclusion slot to the last slot in `N+1` where `N` is the epoch containing the attestation's slot.

<h2 id="abstract">Abstract</h2> <p>Increases max attestation inclusion slot from <code>attestation.slot + SLOTS_PER_EPOCH</code> to the last slot of epoch <code>N+1</code> where <code>N</code> is the epoch containing the attestation slot.</p> <p>This increase is critical to the current LMD-GHOST security analysis as well as the confirmation rule.</p> <h2 id="motivation">Motivation</h2> <p>Attestations can currently be included after some minimum delay (<code>1</code> slot on mainnet) up until <code>SLOTS_PER_EPOCH</code> slots after the slot the attestation was created in. This rolling window of one epoch was decided upon during Phase 0 because the equal inclusion window for any attestation was assessed as "fair". The alternative considered path was to allow inclusion during the current and next epoch which means attestations created during the start of an epoch have more potential slots of inclusion than those at the end of the epoch.</p> <p>Since this decision, it has become apparent that the alternative design is critical for current LMD-GHOST security proofs as well as a new confirmation rule (which will allow for block confirmations in approximately 3-4 slots in normal mainnet conditions).</p> <p>This specification thus increases the max inclusion slot for attestations in accordance with the learned security proof and confirmation rule needs.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td><code>1710338135</code></td><td>Mainnet</td></tr> </tbody></table> <h3 id="execution-layer">Execution layer</h3> <p>This requires no changes to the Execution Layer.</p> <h3 id="consensus-layer">Consensus layer</h3> <p>Specification changes are built into the Consensus Specs Deneb upgrade.</p> <p>The specification makes two minor changes to the state transition function:</p> <ul> <li>Modify <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/beacon-chain.md#modified-process_attestation"><code>process_attestation</code></a> to not have an upper bound on the slot check and instead define the inclusion range via the minimum slot as well as the target epoch being in either current or previous epoch.</li> <li>Modify <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/beacon-chain.md#modified-get_attestation_participation_flag_indices"><code>get_attestation_participation_flag_indices</code></a> to set the <code>TIMELY_TARGET_FLAG</code> without consideration of <code>inclusion_delay</code> to ensure that the extended inclusion attestations have a non-zero reward.</li> </ul> <p>Additionally, the specification modifies the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/p2p-interface.md#beacon_attestation_subnet_id">attestation</a> and <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/p2p-interface.md#beacon_aggregate_and_proof">aggregate attestation</a> gossip conditions to allow for gossip during this extended range.</p> <h2 id="rationale">Rationale</h2> <h3 id="extended-max-inclusion-slot">Extended max inclusion slot</h3> <p>As discussed in the Motivation, extending this max inclusion slot to the end of the next epoch is critical for LMD-GHOST security proofs and confirmation rule.</p> <h3 id="removal-of-inclusion-delay-consideration-for-target-reward">Removal of <code>inclusion_delay</code> consideration for target reward</h3> <p>Previously, <code>get_attestation_participation_flag_indices</code> would only set the <code>TIMELY_TARGET_FLAG</code> (and thus reward for an attestation with correct target vote) if the attestation was included within a <code>SLOTS_PER_EPOCH</code> window.</p> <p>The <code>inclusion_delay</code> consideration for this flag is removed to ensure that whatever the valid inclusion window is for an attestation, it can receive a baseline non-zero reward for correct target. This ensures that clients will still attempt to pack such attestations into blocks which is important for the security analysis.</p> <p>Note, this was the intended behavior with the previously defined range which was equivalent to the max.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for this EIP can be found in the <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/2297c09b7e457a13f7b2261a28cb45777be82f83/tests/core/pyspec/eth2spec/test/deneb"><code>deneb</code></a> test suite of the <code>consensus-specs</code> repository.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This improves LMD-GHOST security as well as enables a fast confirmation rule.</p> <p>There are no known negative impacts to security.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danny Ryanhttps://github.com/djrtwo Mikhail Kalininhttps://github.com/mkalinin Ansgar Dietrichshttps://github.com/adietrichs Hsiao-Wei Wanghttps://github.com/hwwhww lightclienthttps://github.com/lightclient Felix Langehttps://github.com/fjl https://wg-eips.ritovision.com/7002/

Allow validators to trigger exits and partial withdrawals via their execution layer (0x01) withdrawal credentials

<h2 id="abstract">Abstract</h2> <p>Adds a new mechanism to allow validators to trigger withdrawals and exits from their execution layer (0x01) withdrawal credentials.</p> <p>These new execution layer exit messages are appended to the execution layer block and then processed by the consensus layer.</p> <h2 id="motivation">Motivation</h2> <p>Validators have two keys -- an active key and a withdrawal credential. The active key takes the form of a BLS key, whereas the withdrawal credential can either be a BLS key (0x00) or an execution layer address (0x01). The active key is "hot", actively signing and performing validator duties, whereas the withdrawal credential can remain "cold", only performing limited operations in relation to withdrawing and ownership of the staked ETH. Due to this security relationship, the withdrawal credential ultimately is the key that owns the staked ETH and any rewards.</p> <p>As currently specified, only the active key can initiate a validator exit. This means that in any non-standard custody relationship (i.e., the active key is a separate entity from the withdrawal credentials), the ultimate owner of the funds -- the possessor of the withdrawal credentials -- cannot independently choose to exit and begin the withdrawal process. This leads to either trust issues (e.g. ETH can be "held hostage" by the active key owner) or insufficient work-arounds such as pre-signed exits. Additionally, in the event that active keys are lost, a user should still be able to recover their funds by using their cold withdrawal credentials.</p> <p>To ensure that the withdrawal credentials (owned by both EOAs and smart contracts) can trustlessly control the destiny of the staked ETH, this specification enables exits triggerable by 0x01 withdrawal credentials.</p> <p>Note, 0x00 withdrawal credentials can be changed into 0x01 withdrawal credentials with a one-time signed message. Thus any functionality enabled for 0x01 credentials is defacto enabled for 0x00 credentials.</p> <h2 id="specification">Specification</h2> <h3 id="configuration">Configuration</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code></td><td><code>0x00000961Ef480Eb55e80D19ad83579A64c007002</code></td><td>Where to call and store relevant details about exit / partial withdrawal mechanism</td></tr> <tr><td><code>WITHDRAWAL_REQUEST_TYPE</code></td><td><code>0x01</code></td><td>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> type prefix for withdrawal request</td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td><td>Address used to invoke system operation on contract</td></tr> <tr><td><code>EXCESS_WITHDRAWAL_REQUESTS_STORAGE_SLOT</code></td><td>0</td><td></td></tr> <tr><td><code>WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT</code></td><td>1</td><td></td></tr> <tr><td><code>WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT</code></td><td>2</td><td>Pointer to head of the withdrawal request message queue</td></tr> <tr><td><code>WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT</code></td><td>3</td><td>Pointer to the tail of the withdrawal request message queue</td></tr> <tr><td><code>WITHDRAWAL_REQUEST_QUEUE_STORAGE_OFFSET</code></td><td>4</td><td>The start memory slot of the in-state withdrawal request message queue</td></tr> <tr><td><code>MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</code></td><td>16</td><td>Maximum number of withdrawal requests that can be dequeued into a block</td></tr> <tr><td><code>TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</code></td><td>2</td><td></td></tr> <tr><td><code>MIN_WITHDRAWAL_REQUEST_FEE</code></td><td>1</td><td></td></tr> <tr><td><code>WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION</code></td><td>17</td><td></td></tr> <tr><td><code>EXCESS_INHIBITOR</code></td><td><code>2**256-1</code></td><td>Excess value used to compute the fee before the first system call</td></tr> </tbody></table> <h3 id="execution-layer">Execution layer</h3> <h4 id="definitions">Definitions</h4> <ul> <li><strong><code>FORK_BLOCK</code></strong> -- the first block in a blockchain after this EIP has been activated.</li> </ul> <h4 id="withdrawal-request-operation">Withdrawal request operation</h4> <p>The new withdrawal request operation is an <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request with type <code>0x01</code> and consists of the following fields:</p> <ol> <li><code>source_address</code>: <code>Bytes20</code></li> <li><code>validator_pubkey</code>: <code>Bytes48</code></li> <li><code>amount</code>: <code>uint64</code></li> </ol> <p>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> encoding of a withdrawal request is computed as follows. Note that <code>amount</code> is returned by the contract little-endian, and must be encoded as such.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>request_type</span><span class="z-keyword"> =</span><span class="z-constant"> WITHDRAWAL_REQUEST_TYPE</span></span> <span class="giallo-l"><span>request_data</span><span class="z-keyword"> =</span><span> read_withdrawal_requests</span><span>(</span><span>)</span></span></code></pre><h4 id="withdrawal-request-contract">Withdrawal Request Contract</h4> <p>The contract has three different code paths, which can be summarized at a high level as follows:</p> <ol> <li>Add withdrawal request - requires a <code>56</code> byte input, the validator's public key concatenated with a big-endian <code>uint64</code> amount value.</li> <li>Fee getter - if the input length is zero, return the current fee required to add a withdrawal request.</li> <li>System process - if called by system address, pop off the withdrawal requests for the current block from the queue.</li> </ol> <h5 id="add-withdrawal-request">Add Withdrawal Request</h5> <p>If call data input to the contract is exactly <code>56</code> bytes, perform the following:</p> <ul> <li>Ensure enough ETH was sent to cover the current withdrawal request fee (<code>check_fee()</code>)</li> <li>Increase withdrawal request count by 1 for the current block (<code>increment_count()</code>)</li> <li>Insert a withdrawal request into the queue for the source address and validator pubkey (<code>insert_withdrawal_request_into_queue()</code>)</li> </ul> <p>Specifically, the functionality is defined in pseudocode as the function <code>add_withdrawal_request()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> add_withdrawal_request</span><span>(</span><span class="z-variable z-parameter z-function">Bytes48</span><span>:</span><span> validator_pubkey</span><span>,</span><span class="z-variable z-parameter z-function"> uint64</span><span>:</span><span> amount</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Add withdrawal request adds new request to the withdrawal request queue, so long as a sufficient fee is provided.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify sufficient fee was provided.</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span> get_fee</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>msg</span><span>.</span><span>value</span><span class="z-keyword"> &gt;=</span><span> fee</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Insufficient value for fee</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Increment withdrawal request count.</span></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span> count</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Insert into queue.</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> queue_tail_index</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>,</span><span> msg</span><span>.</span><span>sender</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>,</span><span> validator_pubkey</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>,</span><span> validator_pubkey</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">48</span><span>]</span><span class="z-invalid z-illegal"> ++</span><span> uint64_to_little_endian</span><span>(</span><span>amount</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span> queue_tail_index</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span></code></pre><h6 id="fee-calculation">Fee calculation</h6> <p>The following pseudocode can compute the cost of an individual withdrawal request, given a certain number of excess withdrawal requests.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_fee</span><span>(</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_WITHDRAWAL_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> require</span><span>(</span><span>excess</span><span class="z-keyword"> !=</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">Inhibitor still active</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_WITHDRAWAL_REQUEST_FEE</span><span>,</span></span> <span class="giallo-l"><span> excess</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> fake_exponential</span><span>(</span><span class="z-variable z-parameter z-function">factor</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> numerator</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> denominator</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> factor</span><span class="z-keyword"> *</span><span> denominator</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> numerator_accum</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> +=</span><span> numerator_accum</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> (</span><span>numerator_accum</span><span class="z-keyword"> *</span><span> numerator</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span>denominator</span><span class="z-keyword"> *</span><span> i</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> output</span><span class="z-keyword"> //</span><span> denominator</span></span></code></pre><h5 id="fee-getter">Fee Getter</h5> <p>When the input to the contract is length zero, interpret this as a get request for the current fee, i.e. the contract returns the result of <code>get_fee()</code>.</p> <h5 id="system-call">System Call</h5> <p>At the end of processing any execution block starting from the <code>FORK_BLOCK</code> (i.e. after processing all transactions and after performing the block body withdrawal requests validations), call <code>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code> as <code>SYSTEM_ADDRESS</code> with no calldata. The invocation triggers the following:</p> <ul> <li>The contract's queue is updated based on withdrawal requests dequeued and the withdrawal requests queue head/tail are reset if the queue has been cleared (<code>dequeue_withdrawal_requests()</code>)</li> <li>The contract's excess withdrawal requests are updated based on usage in the current block (<code>update_excess_withdrawal_requests()</code>)</li> <li>The contract's withdrawal requests count is reset to 0 (<code>reset_withdrawal_requests_count()</code>)</li> </ul> <p>Each withdrawal request must appear in the EIP-7685 requests list in the exact order returned by <code>dequeue_withdrawal_requests()</code>.</p> <p>Additionally, the system call and the processing of that block must conform to the following:</p> <ul> <li>The call has a dedicated gas limit of <code>30_000_000</code>.</li> <li>Gas consumed by this call does not count against the block’s overall gas usage.</li> <li>Both the gas limit assigned to the call and the gas consumed are excluded from any checks against the block’s gas limit.</li> <li>The call does not follow <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> fee burn semantics — no value should be transferred as part of this call.</li> <li>If there is no code at <code>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code>, the corresponding block <strong>MUST</strong> be marked invalid.</li> <li>If the call to the contract fails or returns an error, the block <strong>MUST</strong> be invalidated.</li> </ul> <p>The functionality triggered by the system call is defined in pseudocode as the function <code>read_withdrawal_requests()</code>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Public function #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##################</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> read_withdrawal_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> dequeue_withdrawal_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> update_excess_withdrawal_requests</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> reset_withdrawal_requests_count</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ssz</span><span>.</span><span>serialize</span><span>(</span><span>reqs</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Helpers #</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment">##########</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> little_endian_to_uint64</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> uint64</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> uint64</span><span>(</span><span class="z-support">int</span><span>.</span><span>from_bytes</span><span>(</span><span>data</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> uint64_to_little_endian</span><span>(</span><span class="z-variable z-parameter z-function">num</span><span>:</span><span> uint64</span><span>)</span><span> -&gt;</span><span class="z-support"> bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> num</span><span>.</span><span>to_bytes</span><span>(</span><span class="z-constant">8</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">little</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ValidatorWithdrawalRequest</span><span>(</span><span class="z-support">object</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> source_address</span><span>:</span><span> Bytes20</span></span> <span class="giallo-l"><span> validator_pubkey</span><span>:</span><span> Bytes48</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> dequeue_withdrawal_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_head_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> queue_tail_index</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span> num_in_queue</span><span class="z-keyword"> =</span><span> queue_tail_index</span><span class="z-keyword"> -</span><span> queue_head_index</span></span> <span class="giallo-l"><span> num_dequeued</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>num_in_queue</span><span>,</span><span class="z-constant"> MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> reqs</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> i</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>num_dequeued</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> queue_storage_slot</span><span class="z-keyword"> =</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> (</span><span>queue_head_index</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 3</span></span> <span class="giallo-l"><span> source_address</span><span class="z-keyword"> =</span><span> address</span><span>(</span><span>sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">20</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> validator_pubkey</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span class="z-keyword"> +</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">16</span><span>]</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> amount</span><span class="z-keyword"> =</span><span> little_endian_to_uint64</span><span>(</span><span>sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span> queue_storage_slot</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span>)</span><span>[</span><span class="z-constant">16</span><span>:</span><span class="z-constant">24</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> req</span><span class="z-keyword"> =</span><span> ValidatorWithdrawalRequest</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> source_address</span><span class="z-keyword">=</span><span>Bytes20</span><span>(</span><span>source_address</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> validator_pubkey</span><span class="z-keyword">=</span><span>Bytes48</span><span>(</span><span>validator_pubkey</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> amount</span><span class="z-keyword">=</span><span>uint64</span><span>(</span><span>amount</span><span>)</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> reqs</span><span>.</span><span>append</span><span>(</span><span>req</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_queue_head_index</span><span class="z-keyword"> =</span><span> queue_head_index</span><span class="z-keyword"> +</span><span> num_dequeued</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> new_queue_head_index</span><span class="z-keyword"> ==</span><span> queue_tail_index</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Queue is empty, reset queue pointers</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span><span>,</span><span> new_queue_head_index</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> reqs</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> update_excess_withdrawal_requests</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_WITHDRAWAL_REQUESTS_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> ==</span><span class="z-constant"> EXCESS_INHIBITOR</span><span>:</span></span> <span class="giallo-l"><span> previous_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> count</span><span class="z-keyword"> =</span><span> sload</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</span><span>:</span></span> <span class="giallo-l"><span> new_excess</span><span class="z-keyword"> =</span><span> previous_excess</span><span class="z-keyword"> +</span><span> count</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> EXCESS_WITHDRAWAL_REQUESTS_STORAGE_SLOT</span><span>,</span><span> new_excess</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> reset_withdrawal_requests_count</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> sstore</span><span>(</span><span class="z-constant">WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span><span>,</span><span class="z-constant"> WITHDRAWAL_REQUEST_COUNT_STORAGE_SLOT</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span></code></pre><h5 id="bytecode">Bytecode</h5> <pre class="giallo z-code"><code data-lang="asm"><span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push20 </span><span class="z-constant">0xfffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xcb</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x11</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x68</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup5</span></span> <span class="giallo-l"><span>dup4</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4d</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>swap4</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">div</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x88</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>callvalue</span></span> <span class="giallo-l"><span>lt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01f4</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span>calldatacopy</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>log0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>stop</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xdf</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0183</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x60</span></span> <span class="giallo-l"><span class="z-keyword">shl</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x14</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffff00000000000000000000000000000000</span></span> <span class="giallo-l"><span class="z-keyword">and</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x40</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x38</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x07</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x30</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x06</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x28</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x05</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x04</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x18</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x10</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x08</span></span> <span class="giallo-l"><span class="z-keyword">shr</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>mstore8</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0xe1</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap2</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>swap3</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x0195</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01a0</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x03</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>push32 </span><span class="z-constant">0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01cd</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span>dup3</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01e2</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span class="z-keyword">pop</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span class="z-keyword">push2</span><span class="z-constant"> 0x01e8</span></span> <span class="giallo-l"><span>jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x02</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span class="z-keyword">sub</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x01</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4c</span></span> <span class="giallo-l"><span class="z-keyword">mul</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span></code></pre><h5 id="deployment">Deployment</h5> <p>The withdrawal requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">to</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x3d090</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gasPrice</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xe8d4a51000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxPriorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">value</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">input</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f556101f880602d5f395ff33373fffffffffffffffffffffffffffffffffffffffe1460cb5760115f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff146101f457600182026001905f5b5f82111560685781019083028483029004916001019190604d565b909390049250505036603814608857366101f457346101f4575f5260205ff35b34106101f457600154600101600155600354806003026004013381556001015f35815560010160203590553360601b5f5260385f601437604c5fa0600101600355005b6003546002548082038060101160df575060105b5f5b8181146101835782810160030260040181604c02815460601b8152601401816001015481526020019060020154807fffffffffffffffffffffffffffffffff00000000000000000000000000000000168252906010019060401c908160381c81600701538160301c81600601538160281c81600501538160201c81600401538160181c81600301538160101c81600201538160081c81600101535360010160e1565b910180921461019557906002556101a0565b90505f6002555f6003555b5f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff14156101cd57505f5b6001546002828201116101e25750505f6101e8565b01600290035b5f555f600155604c025ff35b5f5ffd</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">v</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">r</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x539</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">s</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x5feeb084551e4e03a3581e269bc2ea2f8d0008</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x8ded54be89448d78d4bc97782c0187b099e45380ab681742f9d3754e405c2572</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Sender: 0x8646861A7cF453dDD086874d622b0696dE5b9674</span></span> <span class="giallo-l"><span>Address: 0x00000961Ef480Eb55e80D19ad83579A64c007002</span></span></code></pre><h3 id="consensus-layer">Consensus layer</h3> <p><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/7bf43d1bc4fdb91059f0e6f4f7f0f3349b144950/specs/electra/beacon-chain.md">Full specification</a></p> <p>Sketch of spec:</p> <ul> <li>New operation <code>ExecutionLayerWithdrawalRequest</code></li> <li>Will show up in <code>ExecutionPayload</code> as an SSZ List bound by length <code>MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</code></li> <li>New function that has similar functionality to <code>process_voluntary_exit</code> but can fail validations (e.g. validator is already exited) without the block failing (similar to deposit coming from EL)</li> <li>This function is called in <code>process_operations</code> for each <code>ExecutionLayerWithdrawalRequest</code> found in the <code>ExecutionPayload</code></li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="validator-pubkey-field"><code>validator_pubkey</code> field</h3> <p>Multiple validators can utilize the same execution layer withdrawal credential, thus the <code>validator_pubkey</code> field is utilized to disambiguate which validator is being exited.</p> <p>Note, <code>validator_index</code> also disambiguates validators. The problem is that smart contracts of some staking pools are not aware of the indices, because the index becomes known only after the validator has been created on the beacon chain, while the pubkey is available in advance.</p> <h3 id="message-queue">Message queue</h3> <p>The contract maintains an in-state queue of withdrawal request messages to be dequeued each block into the block and thus into the execution layer.</p> <p>The number of withdrawal requests that can be passed into the consensus layer are bound by <code>MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</code> to bound the load both on the block size as well as on the consensus layer processing. <code>16</code> has been chosen for <code>MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</code> to be in line with the bounds of similar operations on the beacon chain -- e.g. <code>VoluntaryExit</code> and <code>Deposit</code>.</p> <p>Although there is a maximum number of withdrawal requests that can be passed to the consensus layer each block, the execution layer gas limit can provide for far more calls to the withdrawal request predeploy contract at each block. The queue then allows for these calls to successfully be made while still maintaining a system rate limit.</p> <p>The alternative design considered was to have calls to the contract fail after <code>MAX_WITHDRAWAL_REQUESTS_PER_BLOCK</code> successful calls were made within the context of a single block. This would eliminate the need for the message queue, but would come at the cost of a bad UX of contract call failures in times of high exiting. The complexity to mitigate this bad UX is relatively low and is currently favored.</p> <h3 id="rate-limiting-using-a-fee">Rate limiting using a fee</h3> <p>Transactions are naturally rate-limited in the execution layer via the gas limit, but an adversary willing to pay market-rate gas fees (and potentially utilize builder markets to pay for front-of-block transaction inclusion) can fill up the exit operation limits for relatively cheap, thus griefing honest validators that want to make a withdrawal request.</p> <p>There are two general approaches to combat this griefing -- (a) only allow validators to send such messages and with a limit per time period or (b) utilize an economic method to make such griefing increasingly costly.</p> <p>Method (a) (not used in this EIP) would require <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> (the <code>BEACON_ROOT</code> opcode) against which to prove withdrawal credentials in relation to validator pubkeys as well as a data-structure to track requests per-unit-time (e.g. 4 months) to ensure that a validator cannot grief the mechanism by submitting many requests. The downsides of this method are that it requires another cross-layer EIP and that it is of higher cross-layer complexity (e.g. care that might need to be taken in future upgrades if, for example, the shape of the merkle tree of <code>BEACON_ROOT</code> changes, then the contract and proof structure might need to be updated).</p> <p>Method (b) has been utilized in this EIP to eliminate additional EIP requirements and to reduce cross-layer complexity to allow for correctness of this EIP (now and in the future) to be easier to analyze. The <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>-style mechanism with a dynamically adjusting fee mechanism allows for users to pay <code>MIN_WITHDRAWAL_REQUEST_FEE</code> for withdrawal requests in the normal case (fewer than 2 per block on average), but scales the fee up exponentially in response to high usage (i.e. potential abuse).</p> <h3 id="target-withdrawal-requests-per-block-configuration-value"><code>TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</code> configuration value</h3> <p><code>TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</code> has been selected as <code>2</code> such that the growth of the partial withdrawal queue in the beacon state is negligible under extreme scenarios of the exit churn congestion.</p> <h3 id="fee-update-rule">Fee update rule</h3> <p>The fee update rule is intended to approximate the formula <code>fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)</code>, where <code>excess</code> is the total "extra" amount of withdrawal requests that the chain has processed relative to the "targeted" number (<code>TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</code> per block).</p> <p>Like EIP-1559, it’s a self-correcting formula: as the excess goes higher, the <code>fee</code> increases exponentially, reducing usage and eventually forcing the excess back down.</p> <p>The block-by-block behavior is roughly as follows. If block <code>N</code> processes <code>X</code> requests, then at the end of block <code>N</code> <code>excess</code> increases by <code>X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK</code>, and so the <code>fee</code> in block <code>N+1</code> increases by a factor of <code>e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION)</code>. Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in the sense that it responds in the same way to the same total withdrawal requests regardless of how they are distributed over time.</p> <p>The parameter <code>WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION</code> controls the maximum downwards rate of change of the blob gas price. It is chosen to target a maximum downwards change rate of <code>e(TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) ≈ 1.125</code> per block.</p> <p>More detailed analysis of the fee mechanism is available <a href="https://wg-eips.ritovision.com/7002/assets/fee_analysis/">here</a>.</p> <h3 id="withdrawal-requests-inside-of-the-block">Withdrawal requests inside of the block</h3> <p>Withdrawal requests are placed into the actual body of the beacon block.</p> <p>There is a strong design requirement that the consensus layer and execution layer can execute independently of each other. This means, in this case, that the consensus layer cannot rely upon a synchronous call to the execution layer to get the required withdrawal requests for the current block. Instead, the requests must be embedded in the beacon block such that if the execution layer is offline, the consensus layer still has the requisite data to fully execute the consensus portion of the state transition function.</p> <h3 id="submitting-requests-via-execution-layer">Submitting requests via execution layer</h3> <p>Verifying <code>secp256k1</code> signatures from the consensus layer via Engine API is one of the alternatives to the proposed requests mechanism which engineering complexity is much lower. However, this approach would limit usage of withdrawal requests to a large extent by making it impossible for smart contracts owning validator withdrawal credentials to benefit from this functionality.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards incompatible changes to the block structure and block validation rule set. But neither of these changes break anything related to current user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="impact-on-existing-custody-relationships">Impact on existing custody relationships</h3> <p>There might be existing custody relationships and/or products that rely upon the assumption that the withdrawal credentials <em>cannot</em> trigger a withdrawal request. We are currently confident that the additional withdrawal credentials feature does not impact the security of existing validators because:</p> <ol> <li>The withdrawal credentials ultimately own the funds so allowing them to exit staking is natural with respect to ownership.</li> <li>We are currently not aware of any such custody relationships and/or products that do rely on the lack of this feature.</li> </ol> <p>In the event that existing validators/custodians rely on this, then the validators can be exited and restaked utilizing 0x01 withdrawal credentials pointing to a smart contract that simulates this behaviour.</p> <h3 id="fee-overpayment">Fee Overpayment</h3> <p>Calls to the system contract require a fee payment defined by the current contract state. Overpaid fees are not returned to the caller. It is not generally possible to compute the exact required fee amount ahead of time. When adding a withdrawal request from a contract, the contract can perform a read operation to check for the current fee and then pay exactly the required amount. Here is an example in Solidity:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function addWithdrawal(bytes memory pubkey, uint64 amount, uint64 requestFeeLimit) private {</span></span> <span class="giallo-l"><span> assert(pubkey.length == 48);</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Read current fee from the contract.</span></span> <span class="giallo-l"><span> (bool readOK, bytes memory feeData) = WithdrawalsContract.staticcall(&#39;&#39;);</span></span> <span class="giallo-l"><span> if (!readOK) {</span></span> <span class="giallo-l"><span> revert(&#39;reading fee failed&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> uint256 fee = uint256(bytes32(feeData));</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Check the fee is not too high.</span></span> <span class="giallo-l"><span> if (fee &gt; requestFeeLimit) {</span></span> <span class="giallo-l"><span> revert(&#39;fee is too high&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // Add the request.</span></span> <span class="giallo-l"><span> bytes memory callData = abi.encodePacked(pubkey, amount);</span></span> <span class="giallo-l"><span> (bool writeOK,) = WithdrawalsContract.call{value: fee}(callData);</span></span> <span class="giallo-l"><span> if (!writeOK) {</span></span> <span class="giallo-l"><span> revert(&#39;adding request failed&#39;);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Note: the system contract uses the EVM <code>CALLER</code> operation (Solidity: <code>msg.sender</code>) as the target address for withdrawals, i.e. the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.</p> <p>Note: the above code reverts if the fee is too high, the fee can change significantly between creation of a withdrawal request transaction and its inclusion into a block, thus, this check is very important to avoid overpayments.</p> <p>Using an EOA to request withdrawals will always result in overpayment of fees. There is no way for an EOA to use a wrapper contract to request a withdrawal. And even if a way existed, the gas cost of returning the overage would likely be higher than the overage itself. If requesting withdrawals to an EOA through the system contract is desired, we recommend that users perform transaction simulations to estimate a reasonable fee amount to send.</p> <h3 id="system-call-failure">System Call failure</h3> <p>Although the likelihood of a failed system call to <code>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code> is extremely low, the behavior in such cases is well-defined: the block is marked as invalid. However, if the failure results from processing a transaction within the block, the public mempool may still retain the transaction even after the block is invalidated. This can result in the offending transaction being included again, potentially causing one or more subsequent slots to go without valid blocks. To mitigate this, we recommend that the block producer implementation shuffle their transaction set to increase the chances of producing a valid block, without the offending transaction(s). The block producer implementation and/or the mempool should be aware of system call failure scenarios to enable this behavior.</p> <h3 id="empty-code-failure">Empty Code failure</h3> <p>This EIP should not have been activated if there is no code present at <code>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code> (i.e., if the chain is not "ready"). Doing so would cause the first and all subsequent blocks after <code>FORK_BLOCK</code> to be marked invalid.</p> <p>If this situation occurs on a live chain, the following are two potential recovery strategies:</p> <ul> <li>Deploy the contract code via a transaction and include it in a block. This block would become the first valid block, provided the system call to the contract does not fail. This works because the empty code validation occurs after block-transactions execution.</li> <li>Postpone the <code>FORK_BLOCK</code> activation point by updating the consensual fork timestamp or block number in the client implementation(s), then deploy the contract before the fork activates.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Danno Ferrinhttps://github.com/shemnon Andrei Maiborodahttps://github.com/gumb0 Charles Cooperhttps://github.com/charles-cooper https://wg-eips.ritovision.com/7069/

Introduce EXTCALL, EXTDELEGATECALL and EXTSTATICCALL with simplified semantics

<h2 id="abstract">Abstract</h2> <p>Introduce three new call instructions, <code>EXTCALL</code>, <code>EXTDELEGATECALL</code> and <code>EXTSTATICCALL</code>, with simplified semantics. Introduce another instruction, <code>RETURNDATALOAD</code> for loading a word from return data into stack. Modify the behavior of <code>RETURNDATACOPY</code> instruction executed within EOF formatted code (as defined by <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>). The existing <code>*CALL</code> instructions are rejected by EOF validation.</p> <p>The new instructions do not allow specifying a gas limit, but rather rely on the "63/64th rule" (<a href="https://wg-eips.ritovision.com/150/">EIP-150</a>) to limit gas. An important improvement is the rules around the "stipend" are simplified, and callers do not need to perform special calculation whether the value is sent or not.</p> <p>Furthermore, the obsolete functionality of specifying output buffer address is removed in favor of using <code>RETURNDATACOPY</code> instead. For cases which would previously <code>*CALL</code> output into a buffer and then <code>MLOAD</code> from the buffer, <code>RETURNDATALOAD</code> is provided instead.</p> <p>Lastly, instead of returning a boolean for execution status, an extensible list of status codes is returned: <code>0</code> for success, <code>1</code> for revert, <code>2</code> for failure.</p> <h2 id="motivation">Motivation</h2> <p>Observability of gas has been a problem for very long. The system of gas has been (and likely must be) flexible in adapting to changes to both how Ethereum is used as well as changes in underlying hardware.</p> <p>Unfortunately, in many cases compromises or workarounds had to be made to avoid affecting call instructions negatively, mostly due to the complex semantics and expectations of them.</p> <p>This change removes gas observability from the new instructions and opens the door for new classes of contracts that are not affected by repricings. Furthermore, the legacy call instructions are rejected within EOF contracts, making sure they are mostly unaffected by changes in gas fees. Because these operations are required for removing gas observability they are required for EOF in lieu of the existing legacy instructions.</p> <p>It is important to note that starting Solidity 0.4.21, the compiler already passes all remaining gas to calls (using <code>call(gas(), ...</code>), unless the developer uses the explicit override (<code>{gas: ...}</code>) in the language. This suggests most contracts don't rely on controlling gas.</p> <p>Besides the above, this change introduces a convenience feature of returning more detailed status codes: <code>success (0)</code>, <code>revert (1)</code>, <code>failure (2)</code>. This moves from the boolean option to codes, which are extensible in the future.</p> <p>Lastly, the introduction of the <code>RETURNDATA*</code> instructions (<a href="https://wg-eips.ritovision.com/211/">EIP-211</a>) has obsoleted the output parameters of calls, in a large number of cases rendering them unused. Using the output buffers have caused "bugs" in the past: in the case of <a href="https://wg-eips.ritovision.com/20/">ERC-20</a>, conflicting implementations caused a lot of trouble, where some would return something, while others would not. With relying on <code>RETURNDATA*</code> instructions this is implicitly clarified. This proposal also adds the "missing" <code>RETURNDATALOAD</code> instruction to round out returndata buffer access instructions.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td>WARM_STORAGE_READ_COST</td><td>100</td><td>From <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td>COLD_ACCOUNT_ACCESS</td><td>2600</td><td>From <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td>CALL_VALUE_COST</td><td>9000</td><td></td></tr> <tr><td>ACCOUNT_CREATION_COST</td><td>25000</td><td></td></tr> <tr><td>MIN_RETAINED_GAS</td><td>5000</td><td></td></tr> <tr><td>MIN_CALLEE_GAS</td><td>2300</td><td></td></tr> </tbody></table> <p>We introduce four new instructions:</p> <ul> <li><code>EXTCALL</code> (<code>0xf8</code>) with arguments <code>(target_address, input_offset, input_size, value)</code></li> <li><code>EXTDELEGATECALL</code> (<code>0xf9</code>) with arguments <code>(target_address, input_offset, input_size)</code></li> <li><code>EXTSTATICCALL</code> (<code>0xfb</code>) with arguments <code>(target_address, input_offset, input_size)</code></li> <li><code>RETURNDATALOAD</code> (<code>0xf7</code>) with argument <code>offset</code></li> </ul> <p>These four new instructions are undefined in legacy code and only available in EOF code.</p> <p>Execution semantics of <code>EXT*CALL</code>:</p> <ol> <li>Charge <code>WARM_STORAGE_READ_COST</code> gas.</li> <li>Pop required arguments from stack, halt with exceptional failure on stack underflow. <ul> <li><strong>NOTE</strong>: When implemented in EOF, stack underflow check is done during stack validation and runtime check is omitted.</li> </ul> </li> <li>If <code>value</code> is non-zero (only <code>EXTCALL</code>): <ul> <li>Halt with exceptional failure if the current frame is in <code>static-mode</code>.</li> <li>Charge <code>CALL_VALUE_COST</code> gas.</li> </ul> </li> <li>If <code>target_address</code> has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address) then halt with an exceptional failure.</li> <li>Perform (and charge for) memory expansion using <code>[input_offset, input_size]</code>.</li> <li>If <code>target_address</code> is not in the <code>warm_account_list</code>, charge <code>COLD_ACCOUNT_ACCESS - WARM_STORAGE_READ_COST</code> gas.</li> <li>If <code>target_address</code> is not in the state and the call configuration would result in account creation, charge <code>ACCOUNT_CREATION_COST</code> gas. <ul> <li>The only such case in this EIP is if <code>value</code> is non-zero (only <code>EXTCALL</code>).</li> </ul> </li> <li>Calculate the gas available to callee as caller's remaining gas reduced by <code>max(floor(gas/64), MIN_RETAINED_GAS)</code>.</li> <li>Clear the returndata buffer.</li> <li>Fail with status code <code>1</code> returned on stack if any of the following is true (only gas charged until this point is consumed): <ul> <li>Gas available to callee at this point is less than <code>MIN_CALLEE_GAS</code>.</li> <li>Balance of the current account is less than <code>value</code> (only <code>EXTCALL</code>).</li> <li>Current call stack depth equals <code>1024</code>.</li> <li>(only <code>EXTDELEGATECALL</code>) <code>target_address</code> account in the state doesn't have EOF code to execute (in particular, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> delegations should be resolved, as if <code>EXTCALL</code> was used)</li> </ul> </li> <li>Perform the call with the available gas and configuration.</li> <li>Push a status code on the stack: <ul> <li><code>0</code> if the call was successful.</li> <li><code>1</code> if the call has reverted (also can be pushed earlier in a light failure scenario described in step 10).</li> <li><code>2</code> if the call has failed (in case of general OOG failure or any scenario where all gas passed to the callee is burnt in case of an error).</li> </ul> </li> <li>Gas not used by the callee is returned to the caller.</li> </ol> <p>Execution semantics of <code>RETURNDATALOAD</code>:</p> <ol> <li>Charge <code>3</code> gas</li> <li>Pop 1 item from the stack, to be referred to as <code>offset</code></li> <li>Push 1 item onto the stack, the 32-byte word read from the returndata buffer starting at <code>offset</code>.</li> <li>If <code>offset + 32 &gt; len(returndata buffer)</code>, the result is zero-padded.</li> </ol> <p>Execution semantics of <code>RETURNDATACOPY</code> in EOF formatted code (<a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>) is modified as follows:</p> <ol> <li>Assume the 3 arguments popped from stack are <code>destOffset</code>, <code>offset</code> and <code>size</code>. <em>(no change)</em></li> <li>Performs memory expansion to <code>destOffset + size</code> and deducts memory expansion cost. <em>(no change)</em></li> <li>If <code>offset + size &gt; len(returndata buffer)</code> <strong>do not</strong> halt with exceptional failure, but instead set the <code>offset + size - len(returndata buffer)</code> memory bytes after the copied ones to zero.</li> <li>Gas charged for memory copying remains <code>3 * num_words(size)</code>, regardless of the number of bytes actually copied or set to zero.</li> </ol> <p>Execution of <code>RETURNDATACOPY</code> which is not in EOF formatted code (i.e. is in legacy code) is not changed.</p> <h2 id="rationale">Rationale</h2> <h3 id="removing-gas-selectability">Removing gas selectability</h3> <p>One major change from the original <code>CALL</code> series of instructions is that the caller has no control over the amount of gas passed in as part of the call. The number of cases where such a feature is essential are probably better served by direct protocol integration.</p> <p>Removing gas selectability also introduces a valuable property that future revisions to the gas schedule will benefit from: you can always overcome Out of Gas (OOG) errors by sending more gas as part of the transaction (subject to the block gas limit). Previously when raising storage costs (<a href="https://wg-eips.ritovision.com/1884/">EIP-1884</a>) some contracts that sent only a limited amount of gas to their calls were broken by the new costing.</p> <p>Hence some contracts had a gas ceiling they were sending to their next call, permanently limiting the amount of gas they could spend. No amount of extra gas could fix the issue as the call would limit the amount sent. The notion of a stipend floor is retained in this spec. This floor can be changed independent of the smart contracts and still preserve the feature that OOG halts can be fixed by sending more gas as part of the transaction.</p> <h3 id="stipend-and-63-64th-rule">Stipend and 63/64th rule</h3> <p>The purpose of the stipend is to have enough gas to emit logs (i.e. perform non-state-changing operations) when a "contract wallet" is called. The stipend is only added when the <code>CALL</code> instruction is used and the value is non-zero.</p> <p>The 63/64th rule has multiple purposes:</p> <p>a. to limit call depth, b. to ensure the caller has gas left to make state changes after a callee returns.</p> <p>Additionally, there is a call depth counter, and calls fail if the depth would exceed 1024.</p> <p>Before the 63/64th rule was introduced, it was required to calculate available gas semi-accurately on caller side. Solidity has a complicated ruleset where it tries to estimate how much it will cost on the caller side to perform the call itself, in order to set a reasonable gas value.</p> <p>We have changed the ruleset:</p> <p>The 63/64th rule is still applied, but</p> <ul> <li>At least <code>MIN_RETAINED_GAS</code> gas is retained prior to executing the callee,</li> <li>At least <code>MIN_CALLEE_GAS</code> gas is available to the callee.</li> </ul> <p>The <code>MIN_CALLEE_GAS</code> rule is a replacement for stipend: it simplifies the reasoning about the gas costs and is applied uniformly for all introduced <code>EXT*CALL</code> instructions. The following table visualizes the differences (note the discrepancy between <em>caller required gas</em> and <em>caller cost</em> for <code>CALL</code>).</p> <table><thead><tr><th></th><th>Caller required gas</th><th>Caller cost (burned gas)</th><th>Caller min retained gas</th><th>Callee min gas</th></tr></thead><tbody> <tr><td>CALL V=0</td><td>100</td><td>100</td><td>0</td><td>0</td></tr> <tr><td>CALL V≠0</td><td>100+9000</td><td>100+6700</td><td>0</td><td>2300</td></tr> <tr><td>DELEGATECALL</td><td>100</td><td>100</td><td>0</td><td>0</td></tr> <tr><td>STATICCALL</td><td>100</td><td>100</td><td>0</td><td>0</td></tr> <tr><td>EXTCALL V=0</td><td>100</td><td>100</td><td>5000</td><td>2300</td></tr> <tr><td>EXTCALL V≠0</td><td>100+9000</td><td>100+9000</td><td>5000</td><td>2300</td></tr> <tr><td>EXTDELEGATECALL</td><td>100</td><td>100</td><td>5000</td><td>2300</td></tr> <tr><td>EXTSTATICCALL</td><td>100</td><td>100</td><td>5000</td><td>2300</td></tr> </tbody></table> <ul> <li><strong>Caller required gas</strong>: the minimum amount of gas a caller is required to have to execute a call instruction, lower value causes caller's OOG,</li> <li><strong>Caller cost (burned gas)</strong>: the amount of gas deducted from the caller to execute the instruction, this amount is not available to the callee,</li> <li><strong>Caller min retained gas</strong>: the minimum amount of gas the caller is guaranteed to have after the call, if this cannot be guaranteed the call fails without even reaching the callee,</li> <li><strong>Callee min gas</strong>: the minimum gas limit for the callee's execution.</li> </ul> <p>Removing the call stack depth check was initially considered, but this would be incompatible with the original <code>*CALL</code> instructions, as well as <code>CREATE*</code> instructions, which can be intertwined with the new <code>EXT*CALL</code> instructions in the call stack. As such, keeping the call stack depth check involves no change affecting legacy code.</p> <p>Also, we find the simple (as opposed to the complex 63/64th rule) hard cap reassuring, that the call stack depth is limited, in case the gas rules can be bypassed. Lastly, the amount of gas to reach depth of 1024 is huge, but not absurdly huge, and we want to avoid constraining ourselves by dependency of this check on current gas limits.</p> <h3 id="output-buffers">Output buffers</h3> <p>The functionality of specifying output buffer address is removed, because it is added complexity and in a large number of cases implementers prefer to use <code>RETURNDATACOPY</code> instead. Even if they rely on the output buffer (like in the case of Vyper), they would still check the length with <code>RETURNDATASIZE</code>. In Solidity one exception is the case when the expected return size is known (i.e. non-dynamic return values), in this case Solidity still uses the output buffer. For these cases, <code>RETURNDATALOAD</code> is introduced, which simplifies the workflow of copying returndata into a (known) output buffer and using <code>MLOAD</code> from there; instead, <code>RETURNDATALOAD</code> can be used directly.</p> <h3 id="status-codes">Status codes</h3> <p>Current call instructions return a boolean value to signal success: 0 means failure, 1 means success. The Solidity compiler assumed this value is a boolean and thus uses the value as branch condition to status (<code>if iszero(status) { /* failure */ }</code>). This prevents us from introducing new status codes without breaking existing contracts. At the time of the design of <a href="https://wg-eips.ritovision.com/211/">EIP-211</a> the idea of return a specific code for revert was discussed, but ultimately abandoned for the above reason.</p> <p>We change the value from boolean to a status code, where <code>0</code> signals success and thus it will be possible to introduce more non-success codes in the future, if desired.</p> <p>Status code <code>1</code> is used for both reverts coming from the callee frame and light failures encountered (see step 10. of Execution Semantics) in the execution of the instructions. The reason for combining them is keeping the semantics similar to the original CALLs - both scenarios preserve unused gas and continue being indistinguishable to the caller.</p> <p>Status code <code>2</code> signals an exceptional failure in the callee execution, meaning an error occurred that consumed all remaining gas in the callee frame.</p> <h3 id="parameter-order">Parameter order</h3> <p>The order of parameters has been changed to move the <code>value</code> field to be the last. This allows the instructions to have identical encoding with the exception of the last parameter, and simplifies EVM and compiler implementations slightly.</p> <h3 id="opcode-encoding">Opcode encoding</h3> <p>Instead of introducing three new <code>EXT*CALL</code> opcodes we have discussed a version with an immediate configuration byte (flags). There are two main disadvantages to this:</p> <ol> <li>Some combination of flags may not be useful/be invalid, and this increases the testing/implementation surface.</li> <li>The instruction could take variable number of stack items (i.e. <code>value</code> for <code>EXTCALL</code>) would be a brand new concept no other instruction has.</li> </ol> <p>It is also useful to have these as new opcodes instead of modifying the existing CALL series inside of EOF. This creates an "escape hatch" in case gas observability needs to be restored to EOF contracts. This is done by adding the GAS and original CALL series opcodes to the valid EOF opcode list.</p> <h3 id="callcode"><code>CALLCODE</code></h3> <p>Since <code>CALLCODE</code> is deprecated, we do not introduce a counterpart here.</p> <h3 id="halting-when-target-address-is-not-a-20-byte-ethereum-addresses">Halting when <code>target_address</code> is not a 20-byte ethereum addresses</h3> <p>When existing <code>CALL</code> series operations encounter an address that does not fit into 20 bytes the current behavior is to mask the address so that it fits into 20 bytes, ignoring all high bytes. For the <code>EXT*CALL</code> operations a halt was chosen over treating the contract as empty for two reasons. First, it handles the case of sending value to an address that doesn't exist without having to create a special case. Second, it keeps the <code>warm_access_list</code> from needing to track anything that is not a 20-byte ethereum address.</p> <p>Smart contract developers should not rely on the operation reverting when such addresses are passed in. When a suitable proposal for the use of Address Space Extension is adopted it is expected that the <code>EXT*CALL</code> series of operations will adopt those changes.</p> <h3 id="new-instructions-undefined-in-legacy-this-eip-is-part-of-eof-only">New instructions undefined in legacy (this EIP is part of EOF only)</h3> <p>Initially an alternative scenario was considered to introduce these new instructions separately in the legacy EVM first to limit the scope of EOF change, but it was decided to include it as a part of the EOF upgrade and keep them undefined in the legacy EVM.</p> <h3 id="returndataload-and-returndatacopy-padding-behavior"><code>RETURNDATALOAD</code> and <code>RETURNDATACOPY</code> padding behavior</h3> <p>This EIP initially proposed keeping the halt-on-OOB behavior of legacy <code>RETURNDATACOPY</code>. This makes compilers optimizations harder, because unnecessary <code>RETURNDATA*</code> instructions cannot be optimized out without change to code semantics.</p> <p>It could be that only <code>RETURNDATALOAD</code> is given the padding behavior, but that would make it confusingly inconsistent with the closely related <code>RETURNDATACOPY</code> instruction.</p> <p>There also was the alternative to have <code>RETURNDATACOPY2</code> introduced with the padding behavior, available in EOF only, at the same time banning <code>RETURNDATACOPY</code> in EOF. This has been rejected in order to avoid multiplying opcodes, and also as suboptimal from the point of view of compiler implementation.</p> <h3 id="eof1-contracts-can-extdelegatecall-only-eof1-contracts">EOF1 contracts can <code>EXTDELEGATECALL</code> only EOF1 contracts</h3> <p>Legacy contracts can selfdestruct in three different ways (directly through <code>SELFDESTRUCT</code>, indirectly through <code>CALLCODE</code> and indirectly through <code>DELEGATECALL</code>). <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> disables the first two possibilities, however the third possibility remains. Allowing EOF1 contracts to <code>EXTDELEGATECALL</code> only other EOF1 contracts allows the following strong statement: EOF1 contract can never be destructed. Attacks based on <code>SELFDESTRUCT</code> completely disappear for EOF1 contracts. These include destructed library contracts (e.g. Parity Multisig).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No existing instructions are changed and so we do not think any backwards compatibility issues can occur.</p> <h2 id="security-considerations">Security Considerations</h2> <p>It is expected that the attack surface will not grow. All of these operations can be modeled by existing operations with fixed gas (all available) and output range (zero length at zero memory).</p> <p>When implemented in EOF (where the GAS opcode and the original CALL operations are removed) existing out of gas attacks will be slightly more difficult, but not entirely prevented. Transactions can still pass in arbitrary gas values and clever contract construction can still result in specific gas values being passed to specific calls. It is expected the same surface will remain in EOF, but the ease of exploitation will be reduced.</p> <p>The legacy <code>*CALL</code> instructions allow to pass gas available for the callee. This ability is used to prevent reentrancy attack but in case of potential future gas repricing proposal this pattern does not give this guarantee any longer. Protecting against reentrancy should be resolved by using <code>TSTORE/TLOAD</code> instructions introduced in <a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a> or other solutions which do not rely on current gas schedule.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin https://wg-eips.ritovision.com/6988/

Prevents a slashed validator from being elected as a block proposer

<h2 id="abstract">Abstract</h2> <p>Introduces a modification to the consensus layer specification which ensures that slashed validator cannot be elected as block proposer.</p> <h2 id="motivation">Motivation</h2> <p>A block proposed by a slashed validator is rejected by the corresponding validity check in the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/3115d1140b23dd4c9c23fbd9e2428186cf816bde/specs/phase0/beacon-chain.md#block-header"><code>phase0/process_block_header</code></a> function as defined in the consensus layer specification.</p> <p>At the same time the definition of the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/3115d1140b23dd4c9c23fbd9e2428186cf816bde/specs/phase0/beacon-chain.md#compute_proposer_index"><code>phase0/compute_proposer_index</code></a> allows for a slashed validator to be elected as a proposer. This contradiction effectively leads to a missed proposal if it is supposed to be made by a slashed validator.</p> <p>The impact of the proposed fix in the case of a single slashing on Ethereum Mainnet is negligible but it becomes significant in the case of correlated slashings. For instance, a correlated slashing of <code>1/10th</code> of a validator set can lead to <code>1/10th</code> of missed proposals in a number of epochs after the slashing.</p> <h2 id="specification">Specification</h2> <p>Specification of the proposed change can be found in <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/0ad3972725e7c22e8edf3bab2dd7730acbe3c272/specs/_features/eip6988/beacon-chain.md"><code>/_features/eip6988/beacon-chain.md</code></a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="modifying-get-beacon-proposer-index">Modifying <code>get_beacon_proposer_index</code></h3> <p>This function is modified to read a proposer index from a beacon state if a slot of a latest block header is the same as the <code>state.slot</code>.</p> <p>This modification is done to make the function return correct proposer index in the case when the proposer of a given block is being slashed during processing of the block.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This fix changes proposer election mechanism in a backwards incompatible way and requires a hard fork to be deployed.</p> <h2 id="test-cases">Test Cases</h2> <p>The following test cases were added to cover this change:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/0ad3972725e7c22e8edf3bab2dd7730acbe3c272/tests/core/pyspec/eth2spec/test/altair/block_processing/sync_aggregate/test_process_sync_aggregate.py#L712"><code>test_slashed_proposer_rewarded_for_sync_aggregate_inclusion</code></a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/0ad3972725e7c22e8edf3bab2dd7730acbe3c272/tests/core/pyspec/eth2spec/test/altair/block_processing/test_process_attestation.py#L17"><code>test_slashed_proposer_rewarded_for_attestation_inclusion</code></a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/0ad3972725e7c22e8edf3bab2dd7730acbe3c272/tests/core/pyspec/eth2spec/test/eip6988/unittests/validator/test_validator.py#L9"><code>test_slashed_validator_not_elected_for_proposal</code></a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/0ad3972725e7c22e8edf3bab2dd7730acbe3c272/tests/core/pyspec/eth2spec/test/phase0/unittests/validator/test_validator_unittest.py#L520"><code>test_slashed_validator_elected_for_proposal</code></a></li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>Reference implementation is in the same place as <a href="https://wg-eips.ritovision.com/6988/#specification">Specification</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no observed security issues introduced by the proposed change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-05-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Zak Colezak@numbergroup.xyz Zak Colehttps://github.com/zscole Kevin Owockikevin@supermodular.xyz lightclienthttps://github.com/lightclient https://wg-eips.ritovision.com/6968/

Contract Secured Revenue on an EVM based L2

<h2 id="abstract">Abstract</h2> <p>Contract Secured Revenue (CSR) allows smart contract developers to claim a percentage of all transaction fees paid by users when interacting with their smart contracts.</p> <p>This EIP proposes the introduction of CSR on EVM-based L2s which would provide smart contract developers who deploy on L2s access to revenue streams and/or public goods.</p> <h2 id="motivation">Motivation</h2> <p>Using protocol rewards of an L1 to fund smart contract development would be a big change to the way the current market works. This EIP <em>does not</em> advocate for any changes to the existing Ethereum L1.</p> <p>This EIP does advocate that L2s could begin to experiment with Contract Secured Revenue as a means of:</p> <ol> <li>creating a new revenue stream for smart contract developers</li> <li>creating a new way of funding public goods</li> <li>creating incentives for developers to deploy their dapps on your network</li> </ol> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td>REVENUE_SHARE_QUOTIENT</td><td>5</td></tr> </tbody></table> <h3 id="fee-mechanism">Fee Mechanism</h3> <p>The current <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> fee behavior is modified so that <code>header.base_fee_per_gas * REVENUE_SHARE_QUOTIENT</code> per gas is reallocated proportionally, based on gas used, to each contract executed during the transaction.</p> <p>Implicitly, this means that no fees are redistributed to externally owned accounts (EOA).</p> <h4 id="gas-tracking">Gas Tracking</h4> <p>In order to fairly distribute the fee revenue, a new transaction-wide gas tracker is defined.</p> <p>When executing a block, maintain a mapping <code>gas_used_by_address</code> of <code>address</code> to <code>uint64</code>. This will track the amount of gas used by each address. For every EVM instruction that does not instantiate a new execution frame (e.g. <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code>, <code>CREATE</code>, and <code>CREATE2</code>), add the cost of the instruction to the address' current sum in the mapping.</p> <p>For EVM instructions which do instantiate new frames, greater care must be taken to determine the cost of the instruction to the calling frame. For simplicity, this cost is defined to be the total cost of the operation minus the amount of gas passed to the child frame. The gas passed to the child frame is determined via <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>. The computed cost is added to the address' current sum in the mapping.</p> <p>Additionally:</p> <ul> <li>If the address does not exist in the mapping, it's total gas used is <code>0</code>.</li> <li>If the instructions throws an out-of-gas (OOG) error, all remaining gas allocated to execution frame is added to the current total gas used by the address.</li> <li>No other exceptional halt adds remaining gas to the counter for the address where the halt occurred.</li> </ul> <h4 id="setting-revenue-recipient">Setting Revenue Recipient</h4> <p>Revenue recipients are tracked via a new transaction wide mapping <code>revenue_recipient</code> of <code>address</code> to <code>address</code>. The default value for every key is the key itself. For example, unless set otherwise, the key <code>0xdead...beef</code> maps to the value <code>0xdead...beef</code>.</p> <p>To set a different revenue recipient, a new instruction <code>SETREVENUERECIPIENT</code> is introduced with the opcode <code>0x49</code>. The operation takes <code>1</code> stack element as input and outputs <code>0</code> stack elements.</p> <p>The <code>20</code> least significant bytes of the input stack element is the address of the new revenue recipient for the instruction's caller. The <code>revenue_recipient</code> entry is updated to reflect this.</p> <p>The instruction costs <code>3</code> gas.</p> <h4 id="dispersing-revenue">Dispersing Revenue</h4> <p>After a transaction completes, for every element (<code>addr</code>, <code>gas_used</code>) in <code>gas_used_by_address</code>, increase the balance of <code>revenue_recipient[addr]</code> by <code>gas_used * (header.base_fee_per_gas // REVENUE_SHARE_QUOTIENT)</code></p> <h2 id="rationale">Rationale</h2> <h3 id="tracking-gas-proportionally">Tracking Gas Proportionally</h3> <p>A simpler mechanism would be to send the full transaction revenue to the <code>to</code> value of the transaction. This, however, does not accurately reward the composition of many different smart contracts and applications. Additionally, it is not compatible with smart contract wallets which, by definition, are often the first destination of a transaction.</p> <p>Maintaining a transaction wide tracker of gas uses makes it possible to distribute revenue to contracts which are genuinely the most utilized.</p> <h3 id="ephemeral-revenue-recipient-mapping">Ephemeral Revenue Recipient Mapping</h3> <p>Constructing the revenue recipient mapping ephemerally during each transaction appears inefficient on the surface. This value is expected to be relatively static and even if it did need to change, the change could be facilitated by the recipient contract.</p> <p>Unfortunately such a change is much more invasive for the EVM. The recipient value would need to be stored somewhere. This would require a modification to the account structure in the state trie. Also, the recipient value would need to be set at some point. This would necessitate either a modification to the <code>CREATE*</code> opcodes or a new opcode, similar to <code>SETREVENUERECIPIENT</code>, that would be called by initcode to "initialize" the recipient value.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="increased-max-block-size-complexity">Increased Max Block Size/Complexity</h3> <p>Similar to EIP-1559, we must consider the effects this will have on block size. Depending on the method by which this is implemented, it could increase maximum block size in the event that a significant number of contracts opt-in to CSR.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/6913/

new instruction to replace code in-place

<h2 id="abstract">Abstract</h2> <p>Introduce the <code>SETCODE</code> (<code>0xfc</code>) instruction, which replaces the code of the executing account from memory.</p> <h2 id="motivation">Motivation</h2> <p>Many contracts are upgradeable in order to facilitate improvement or defer decisions without migrating to a new address. Contracts presently do this in several ways:</p> <p>The oldest method uses <code>CALL</code>. The limitation of this method is that internal state must be modifiable by all future implementations.</p> <p>Second, <code>DELEGATECALL</code> can proxy the implementation. Some proxies are minimal while others branch to many separate implementation accounts. This method can also bypass account code size limits.</p> <p>A third method uses <code>SELFDESTRUCT</code> and <code>CREATE2</code> to replace code in-place. This method improves upon the prior methods by removing the need to call into external contracts. One limitation of this method is that any internal state is removed by <code>SELFDESTRUCT</code>. Another limitation is that <code>SELFDESTRUCT</code> does not remove code until the end of the transaction, sacrificing availability until <code>CREATE2</code> can complete the upgrade.</p> <p>Given the upcoming deprecation of <code>SELFDESTRUCT</code>, <code>SETCODE</code> introduces a better method for replacing code in-place.</p> <h2 id="specification">Specification</h2> <p>When within a read-only execution scope like the recursive kind created by <code>STATICCALL</code>, <code>SETCODE</code> causes an exceptional abort.</p> <p>When the currently executing code does not equal the code of the executing account, such as can happen inside of <code>DELEGATECALL</code> or <code>CREATE</code>, <code>SETCODE</code> causes an exceptional abort.</p> <p>Otherwise, <code>SETCODE</code> consumes two words from the stack: offset and length. These specify a range of memory containing the new code. Any validations that would be performed on the result of <code>CREATE</code> or <code>CREATE2</code> occur immediately, potentially causing failure with exceptional abort. The operations <code>EXTCODESIZE</code> and <code>EXTCODECOPY</code> now query the updated code, and message-calls such as <code>DELEGATECALL</code>, <code>CALLCODE</code>, <code>CALL</code>, and <code>STATICCALL</code> now execute the updated code. Any execution scopes already executing replaced code, including the one that <code>SETCODE</code>, will continue executing the prior code. Inside such scopes, <code>CODESIZE</code> and <code>CODECOPY</code> continue to query the executing code.</p> <p>Like <code>SSTORE</code>, this account modification will be reverted if the current scope or any parent scope reverts or aborts.</p> <p>Unlike <code>SELFDESTRUCT</code>, <code>SETCODE</code> does not clear account balance, nonce, or storage.</p> <h3 id="gas">Gas</h3> <p>The gas cost of this operation is the sum of <code>Gselfdestruct</code> and the product of <code>Gcodedeposit</code> and the number of bytes in the new code.</p> <h2 id="rationale">Rationale</h2> <p>The behavior of <code>CODECOPY</code>, <code>CODESIZE</code>, <code>EXTCODESIZE</code>, and <code>EXTCODECOPY</code> match the behavior of <code>DELEGATECALL</code> and <code>CREATE</code>, where it is also possible for executing code to differ from the code of the executing account.</p> <p>The gas cost of <code>SETCODE</code> is comparable to <code>CREATE</code> but excludes <code>Gcreate</code> because no execution context is created, nor any new account. Other account modification costs are accounted for outside of execution gas.</p> <p>Unlike <code>SELFDESTRUCT</code>, execution proceeds normally after <code>SETCODE</code> in order to allow validation and return data. Post-update validation can undo a <code>SETCODE</code> operation with <code>REVERT</code>, or with a recursive <code>SETCODE</code>, but <code>REVERT</code> uses less gas.</p> <p>Preventing <code>SETCODE</code> within most <code>DELEGATECALL</code> allows static analysis to easily identify mutable code. Account code not containing the <code>SETCODE</code> operation can be safely assumed to be immutable. Code observed in a non-reverting context to be immutable will remain immutable, allowing on-chain static analysis for immutability.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The only prior operation changing code is <code>SELFDESTRUCT</code>. As code modification via <code>SELFDESTRUCT</code> is deferred until the end of the transaction, its interactions with <code>SETCODE</code> are well-defined.</p> <h2 id="test-cases">Test Cases</h2> <table><thead><tr><th>CodeStart</th><th>CallData</th><th>CodeResult</th><th>Gas</th></tr></thead><tbody> <tr><td>365f5f37365ffc00</td><td>365f5f37365ffc00</td><td>365f5f37365ffc00</td><td>6613</td></tr> <tr><td>365f5f37365ffc00</td><td>00</td><td>00</td><td>5213</td></tr> <tr><td>365f5f37365ffc00</td><td></td><td></td><td>5013</td></tr> <tr><td>365f5f37365ffc595ffd</td><td>365f5f37365ffc00</td><td>365f5f37365ffc595ffd</td><td>6617</td></tr> <tr><td>365f5f37365ffcfe</td><td>365f5f37365ffc00</td><td>365f5f37365ffcfe</td><td>all</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>Risks related to <code>SETCODE</code> similarly apply to other upgrade patterns.</p> <p>Most contracts should never be replaced and should not be upgradeable. Any upgrade mechanism can risk permanent failure. The possibility of upgrade perpetuates such risk.</p> <p>Access to upgrade operations should be restricted. Upgrades should never be performed in a hurry or when tired. Upgrades should be tested under as similar conditions to production as possible; discrepancies are sources of unexpected results. When possible, multiple engineers should preview and independently verify pending upgrade procedures.</p> <p>Block explorers, wallets, and other interfaces should flag upgradeable code. Client software should warn against approving <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> or <a href="https://wg-eips.ritovision.com/721/">ERC-721</a> tokens for upgradeable accounts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Lionhttps://github.com/dapplion Danny Ryanhttps://github.com/djrtwo https://wg-eips.ritovision.com/6914/

Reuse fully withdrawn and safe to reuse validator indices for new beacon chain deposits.

<h2 id="abstract">Abstract</h2> <p>Reuse fully withdrawn validator indices after a sufficient safe-to-reuse period has passed to eliminate the unbounded growth of the beacon chain validator list as the validator set churns.</p> <h2 id="motivation">Motivation</h2> <p>The beacon chain maintains a list of validators and a separate list of balances associated with each validator. When a new deposit for a new validator occurs, the current mechanism only appends, rather than reusing previously fully withdrawn validator indices. As validators fully withdraw and new validators enter, this means the two lists will grow unbounded.</p> <p>This specification allows for the reuse of validator indices in the event that it is safe to do so, eliminating the concerns around the unbounded validator list growth.</p> <h2 id="specification">Specification</h2> <h3 id="consensus-layer">Consensus Layer</h3> <p>The configuration values and mechanics of the specification can be found in the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/1a38b83e5db8638ee01c9461cccf11e7d8a3ebce/specs/_features/eip6914">Consensus Layer specs</a>.</p> <p>Note that validator indices are reused in the event that the validator has been fully withdrawn <em>and</em> that the validator has been withdrawable for a sufficient safe period.</p> <h3 id="execution-layer">Execution Layer</h3> <p>This specification does not require any changes to the Execution Layer.</p> <h2 id="rationale">Rationale</h2> <p>The <code>validators</code> and <code>balances</code> lists are currently appended to each time a new Deposit for a new pubkey comes into the beacon chain. Due to the natural mechanics of stakers entering and leaving consensus over long time spans, these lists, thus the state size, will grow unbounded.</p> <p>Increased state size represents load and/or complexity in client implementations. This comes in the form of client memory footprint, state root calculations, validator set scans, and more. This is a relatively simple clean-up within the state transition that will prevent the unnecessary load and complexity of the otherwise unbounded lists.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible change to the Consensus Layer of Ethereum and must be scheduled with a hard fork.</p> <p>There are no forwards/backwards compatibility issues with the Execution Layer</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases are work-in-progress within the standard Consensus Layer tests.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Validator indices cannot be immediately reused but instead must wait <code>SAFE_EPOCHS_TO_REUSE_INDEX</code> epochs to ensure that attestations cannot be "poisoned" with withdrawn validator signatures -- thus non-slashable -- for at least the weak subjectivity period.</p> <p>The attestation poisoning attack hinges upon two facts:</p> <ul> <li>The reuse of a validator index overwrites the previous validator's pubkey from the beacon state.</li> <li><code>AttesterSlashing</code>s includes validator indices to reconstruct signature participants.</li> </ul> <h3 id="details-of-the-attack">Details of the attack</h3> <p>Assume a 1/3 attacker. Attacker exits N validators on the honest chain, where N is a small fraction of the validator set. These validators leave the exit queue and are withdrawable within a few days. Now, N new deposits come in and overwrite the validators and most importantly their pubkeys.</p> <p>The attacker then constructs an alternative attacker chain from before any of the N voluntary exits, such that the original N validators are not exited and withdrawn. N is large enough such that at least one of the N keys is on average in every committee of the attacker chain. The attacker double-signs in an attempt to finalize the attacker chain but ensures that one of the N keys is mixed into any revealed double-signed aggregate attestation -- the individual attestations are unavailable, only aggregates. These malicious attestations are <em>not</em> includable in the honest chain because <code>AttesterSlashing</code>s rely upon mapping validator indices to particular pubkeys, thus breaking accountable safety.</p> <h3 id="mitigation">Mitigation</h3> <p>Not overwriting withdrawn validators for <code>SAFE_EPOCHS_TO_REUSE_INDEX</code> epochs (3x the max weak subjectivity period) ensures that attestations cannot be poisoned within the accountable safety security window.</p> <h3 id="alternative">Alternative</h3> <p>Note that if <code>AttesterSlashing</code>s included a list of pubkeys instead of validator indices, then this would not be an issue. However, this would require more breaking changes and would increase the data requirement of an <code>AttesterSlashing</code>, the largest Consensus Layer data type, by a factor of 6.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Renan Rodrigues de Souzahttps://github.com/RenanSouza2 https://wg-eips.ritovision.com/6888/

Check for math overflows and division by zero at EVM level

<h2 id="abstract">Abstract</h2> <p>This EIP adds arithmetics checks to EVM arithmetic and a new opcode jump conditionally if there were events. The list of check includes overflows, division by zero.</p> <h2 id="motivation">Motivation</h2> <p>The importance of math checks in smart contract projects is very clear. It was an OpenZeppelin library and then incorporated in Solidity's default behavior. Bringing this to EVM level can combine both gas efficiency and safety.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Starting from <code>BLOCK_TIMESTAMP &gt;= HARDFORK_TIMESTAMP</code></p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Constant</th><th>Type</th><th>Value</th></tr></thead><tbody> <tr><td><code>HARDFORK_TIMESTAMP</code></td><td><code>uint64</code></td><td><code>TBD</code></td></tr> <tr><td><code>UINT_MAX</code></td><td><code>uint256</code></td><td><code>2 ** 256 - 1</code></td></tr> <tr><td><code>INT_MIN</code></td><td><code>int256</code></td><td><code>-(2**255)</code></td></tr> </tbody></table> <h3 id="flags">Flags</h3> <table><thead><tr><th>Variable</th><th>Type</th><th style="text-align: left">Initial Value</th></tr></thead><tbody> <tr><td><code>carry</code></td><td><code>bool</code></td><td style="text-align: left">false</td></tr> <tr><td><code>overflow</code></td><td><code>bool</code></td><td style="text-align: left">false</td></tr> </tbody></table> <p>Two new flags are added to the EVM state: unsigned warning (<code>carry</code>) and signed warning (<code>overflow</code>). The scope of those flags are the same as the program counter.</p> <h3 id="definitions">Definitions</h3> <p>From this point forward <code>a</code>, <code>b</code> and <code>c</code> references the arguments in a math operation and <code>res</code> the output. <code>c</code> is only used if the operation takes 3 inputs.</p> <p>The function <code>sign(x)</code> is defined in the set of <code>uint256 -&gt; {NEGATIVE, ZERO, POSITIVE}</code></p> <h3 id="contidions">Contidions</h3> <p>The <code>carry</code> flag MUST be set in the following circumstances:</p> <ul> <li>When opcode is <code>ADD</code> (<code>0x01</code>) and <code>res &lt; a</code></li> <li>When opcode is <code>MUL</code> (<code>0x02</code>) and <code>a != 0 ∧ res / a != b</code></li> <li>When opcode is <code>SUB</code> (<code>0x03</code>) and <code>b &gt; a</code></li> <li>When opcode is <code>DIV</code> (<code>0x04</code>) or <code>MOD</code> (<code>0x06</code>); and <code>b == 0</code></li> <li>When opcode is <code>ADDMOD</code> (<code>0x08</code>) and <code>c == 0</code></li> <li>When opcode is <code>MULMOD</code> (<code>0x08</code>) and <code>c == 0</code></li> <li>When opcode is <code>EXP</code> (<code>0x0A</code>) and <code>a ** b &gt; UINT_MAX</code></li> <li>When opcode is <code>SHL</code> (<code>0x1b</code>) and <code>res &gt;&gt; a != b</code></li> </ul> <p>The <code>overflow</code> flag MUST be set in the following circumstances:</p> <ul> <li>When opcode is <code>ADD</code> (<code>0x01</code>) and <code>a != 0 ∧ b != 0 ∧ sign(a) == sign(b) ∧ sign(a) != sign(res)</code></li> <li>When opcode is <code>SUB</code> (<code>0x03</code>) and <code>(a != 0 ∧ b != 0 ∧ sign(a) != sign(b) ∧ sign(a) != sign(res)) ∨ (a == 0 ^ b == INT_MIN)</code></li> <li>When opcode is <code>MUL</code> (<code>0x02</code>) and <code>(a == -1 ∧ b == INT_MIN) ∨ (a == INT_MIN ∧ b == -1) ∨ (a != 0 ∧ (res / a != b))</code> (this <code>/</code> represents <code>SDIV</code>)</li> <li>When opcode is <code>SDIV</code> (<code>0x05</code>) or <code>SMOD</code> (<code>0x06</code>); and <code>b == 0 ∨ (a == INT_MIN ∧ b == -1)</code></li> <li>When opcode is <code>SHL</code> (<code>0x1b</code>) and <code>res &gt;&gt; a != b</code> (this <code>&gt;&gt;</code> represents <code>SAR</code>)</li> </ul> <h3 id="opcodes">Opcodes</h3> <h4 id="jumpc"><code>JUMPC</code></h4> <p>Consumes one argument from the stack, the possible pc dest, Conditionally alter the program counter depending on the <code>carry</code> flag. <code>J_JUMPC = carry ? µ_s[0] : µ_pc + 1</code> Clears both flags. <code>carry = overflow = false</code></p> <h4 id="jumpo"><code>JUMPO</code></h4> <p>Consumes one argument from the stack, the possible pc dest, Conditionally alter the program counter depending on the <code>ovewflow</code> flag. <code>J_JUMPO = carry ? µ_s[0] : µ_pc + 1</code> Clears both flags. <code>carry = overflow = false</code></p> <h3 id="gas">gas</h3> <p>The gas cost for both instructions is <code>G_high</code>, the same as <code>JUMPI</code>.</p> <h2 id="rationale">Rationale</h2> <p>EVM uses two's complement for negative numbers. The opcodes listed above triggers one or two flags depending if they are used for signed and unsigned numbers.</p> <p>The conditions described for each opcode is made with implementation friendliness in mind. The only exception is EXP as it is hard to give a concise test as most of the others relied on the inverse operation and there is no native <code>LOG</code>. Most <code>EXP</code> implementations will internally use <code>MUL</code> so the flag <code>carry</code> can be drawn from that instruction, not the <code>overflow</code>.</p> <p>Both flags are cleaned at the same time because the instructions are expected to be used when transitioning between codes where numbers are treated as signed or unsigned.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new opcode and changes int EVM behavior.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>This is a new EVM behavior but each code will decide how to interact with it.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet https://wg-eips.ritovision.com/6873/

Execution clients must retain the preimages of addresses and slots accessed between the fork preceding the verge, and the verge itself.

<h2 id="abstract">Abstract</h2> <p>Enforce preimage collection by every node on the network from the fork preceding the verge, up to the fork. This is needed in case each node is responsible for their own conversion.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>Let <code>T_p</code> be the timestamp of the fork preceding the verge, and <code>T_v</code> the timestamp of the verge.</p> <ul> <li> <p>EL clients MUST save the preimage of each address and slot hashes they produce during the execution of all blocks produced between <code>T_p</code> and <code>T_v</code></p> </li> <li> <p>EL clients MAY start storing preimages outside of this time range as well</p> </li> <li> <p>Given a hash produced between <code>T_p</code> and <code>T_v</code>, EL clients SHOULD be able to show they have the preimage for that hash in their database</p> </li> <li> <p>EL clients SHOULD be able to download the preimages of the address and slot hashes that were produced before <code>T_v</code> from a publicly-available datastore</p> </li> </ul> <h2 id="rationale">Rationale</h2> <p>Switching to verkle trees require a complete rehashing of all tree keys. Most execution clients store all keys hashed, without their preimages, which as the time of print take up 70GB on mainnet. In order to make these preimages available to everyone, the following course of action are available to each user:</p> <ul> <li>Restart a full-sync with preimage retention enabled</li> <li>Download the preimages as a file</li> </ul> <p>The second option is the only acceptable option in practice, as a full-sync requires the syncing machine to be offline for several days, and therefore should not be simultaneously imposed to the entire network. A file download, however, poses a problem of data obsolescence as new preimages will immediately need to be added to the list as the chain progresses and new addresses are accessed. Updating the preimage file is not sufficient, since it takes more than a slot time to download over 70GB.</p> <p>To guarantee a timely availability of all preimages around the verkle transition time, each node is therefore responsible for updating the list of preimages between the fork preceding the Verge, and the Verge itself.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward compatibility issues found.</p> <!-- ## Test Cases TODO --> <h2 id="reference-implementation">Reference Implementation</h2> <p>All clients already implement preimage retention, at least as an option.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion. <!-- TODO --></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mário Havelhttps://github.com/taxmeifyoucan pk910https://github.com/pk910 Rémy Royhttps://github.com/remyroy Holly Atkinsonhttps://github.com/atkinsonholly Tereza Burianovahttps://github.com/T-ess https://wg-eips.ritovision.com/6916/

A testnet network that periodically rolls back to genesis

<h2 id="abstract">Abstract</h2> <p>This EIP proposes a specification for an automatically reset testnet, a novel approach to testnets that can be implemented within Ethereum clients. It enables a single testing infrastructure consisting of ephemeral networks with deterministic parameters. Each network iteration is created by a specified function which deterministically generates genesis states.</p> <h2 id="motivation">Motivation</h2> <p>A testnet which automatically resets can provide an alternative environment for short-term testing of applications, validators and also breaking changes in client implementations. It avoids issues of long running testnets which suffer from state bloat, lack of testnet funds or consensus issues. Periodically resetting the network back to genesis cleans the validator set and returns funds back to faucets while keeping the network reasonably small for easy bootstrapping.</p> <h2 id="specification">Specification</h2> <p>The testnet is set to always reset after a predefined time period. The reset means the generation of the next genesis, discarding the old one and starting a new network. This is possible by introducing functions for the genesis generation and the client reset.</p> <h3 id="genesis">Genesis</h3> <p>To connect to the current instance of the network, the client must implement the genesis function. This function defines how the client stores information about the testnet and generates the current genesis. With each reset, the network starts from a new genesis which needs to be built based on given parameters and correspond in EL and CL clients.</p> <p>The network always starts from a genesis which is deterministically created based on the original one - this very first genesis is hardcoded and we can call it <code>genesis 0</code>. Terminal time, the expiration of each genesis, is the addition of the start time of that genesis <code>MIN_GENESIS_TIME</code> and the testnet lifetime <code>period</code>, where <code>period</code> is a constant defining the length of time a single ephemeral network runs. Therefore, once the current slot timestamp reaches the terminal time of the ephemeral network, it has to switch to a new genesis. The main changes in each new genesis iteration are chainId, genesis time and the withdrawal credentials of the first validator.</p> <p>Clients shall include a hardcoded <code>genesis 0</code> parameters, much like other networks predefined in clients. However, this genesis shall be used directly, only at the very beginning of the testnet's existence, in its first iteration where <code>i</code> equals <code>0</code>. Later on, with iteration <code>i</code> equal to <code>1</code> and above, the client does not initialize this genesis but uses it to derive the current one. When <code>i&gt;0</code>, given a known <code>period</code> and current slot timestamp, the client always calculates the number of lifecycle iterations from <code>genesis 0</code> and creates a new genesis with the latest parameters.</p> <p>When the client starts with the option of an ephemeral testnet, it checks whether a genesis for the network is present. If it doesn't exist or the current slot timestamp is older than <code>current_genesis.genesis_time + period</code>, it triggers the generation of a new genesis. This new genesis, derived from <code>genesis 0</code>, will be written to the database and used to run the current network.</p> <h4 id="execution-client">Execution client</h4> <p>The EL client includes the hardcoded <code>genesis 0</code> serving as a preimage for generating the current one. Iteration of variables is done as follows:</p> <ul> <li>Number of iterations: <ul> <li><code>i</code> = <code>int((current_slot_timestamp</code> - <code>genesis_0.genesis_time) / period)</code></li> </ul> </li> <li>Genesis time of current genesis: <ul> <li><code>current_genesis.genesis_time</code> = <code>period</code> * <code>i</code> + <code>genesis_0.genesis_time</code></li> </ul> </li> <li>Current EL ChainId: <ul> <li><code>chainId</code> = <code>genesis_0.chainId</code> + <code>i</code></li> </ul> </li> </ul> <h4 id="consensus-client">Consensus client</h4> <p>Genesis generation in the CL client includes config with iterated values, similarly to EL, but also requires the updated genesis state. The state in SSZ format can be either generated by the client or downloaded from an external source. It includes validators with deposits ready to launch a merged network with the validator set created by trusted entities within the community.</p> <p><code>MIN_GENESIS_TIME</code> is set to the latest genesis time and defines when the current period starts. It is recommended to add a small <code>GENESIS_DELAY</code>, for example 15 minutes, to avoid issues while infrastructure is restarting with the new genesis.</p> <p>To ensure a successful reset, <code>ForkDigest</code> needs to be unique for each iteration. In order to keep the <code>ForkVersions</code> of the network static for better tooling support, the withdrawal credentials of the first validator in the validator set need to be overridden by a calculated value.</p> <ul> <li><code>genesis.validators[0].withdrawal_credentials</code> = <code>0x0100000000000000000000000000000000000000000000000000000000000000</code> + <code>i</code></li> <li><code>genesis.genesis_validators_root</code> = <code>hash_tree_root(genesis.validators)</code></li> </ul> <p>The update of <code>genesis.validators[0]</code> changes the state, therefore, clients have to be able to generate or download the latest genesis state. Generating the genesis ssz is not considered a standard client feature and adding it enables to trustlessly create the latest genesis state at the price of certain complexity. An alternative solution is to obtain it from a third party, either by downloading the ssz file from a server or using the checkpoint sync feature with an endpoint serving the genesis state. This became an accepted practice with Holešky testnet and existing features of checkpoint sync can be used for obtaining genesis states for automatically reset testnets. It also allows maintainers to update the genesis validator set without requiring new client releases. The full implementation of the recommended practice for obtaining the latest CL state should behave as follows:</p> <ul> <li>When the testnet flag is provided and client supports checkpoint sync of genesis, automatically use the hardcoded checkpoint endpoint to download the latest genesis state using the checkpoint sync feature <ul> <li>If user provides a custom checkpoint sync flag, override the default option and use the endpoint provided by user</li> </ul> </li> <li>Include a backup download option pointing to an url with the latest testnet release, a publicly distributed ssz file, and trigger this option if the checkpoint state sync fails or make it the default if client doesn't support genesis checkpoint sync</li> <li>If the client includes a feature for generating the genesis or some of its parameters, use it to verify parameters in the downloaded state and issue an error if values or checksum don't correspond</li> </ul> <p>It's important to note that <code>genesis_validators_root</code> is normally predefined in the client but in this case it's not known in advance which can potentially break certain architectures. For example light clients which are relying on hardcoded <code>genesis_validators_root</code> won't work.</p> <h3 id="reset">Reset</h3> <p>The reset function defines an automatic process of throwing away the old data and starting with a new genesis. It depends on the previously defined function for genesis generation which the client must implement in order to be able to automatically follow the latest network iteration.</p> <p>For the reset function, we can introduce the <code>terminal_timestamp</code> value which defines the network expiry time of an iteration. It can be the same as the genesis time of the next iteration (without the genesis delay) or can be calculated simply as <code>terminal_timestamp = current_genesis.genesis_time + period</code>.</p> <p>When the network reaches a slot with a timestamp <code>&gt;= terminal_timestamp</code>:</p> <ul> <li>Client stops accepting/creating new blocks <ul> <li>Shutdown client services running the network, e.g. p2p communication, beacon service, execution environment</li> <li>This feature should be implemented alongside Genesis even without further reset functions just to create a basic support which is always safe from forking</li> </ul> </li> <li>Client calls a function which discards the current genesis, all chain or beacon data <ul> <li>Clients already include db tools including for purging the database which could be used here</li> <li>It might be beneficial to include an additional flag, e.g. <code>--retain-ephemeral-data</code>, which would first export the existing data in a standard format before removing the database</li> </ul> </li> <li>Client triggers the Genesis function (as defined above): <ul> <li>Behaves like a regular client startup when genesis is not present</li> <li>New genesis is written into db and initialized</li> </ul> </li> <li>Main network services are started again pointing to the updated genesis</li> <li>After the new genesis time is reached, the network starts again from the new genesis</li> </ul> <p>For a full reset implementation, clients should be able to perform the above actions without requiring manual restart, operating the network fully independently and with minimal downtime.</p> <p>Note that depending on the client architecture, it may not be feasible to fully implement such an internal reset mechanism, e.g. if the client doesn't support a graceful shutdown. The reset feature is considered an advanced level of support and is mainly needed by infrastructure providers and genesis validators. The assumption is that even if the client doesn't implement reset, advanced users can achieve similar behavior with external scripts handling the client by system tools.</p> <h2 id="rationale">Rationale</h2> <p>Ephemeral testnets with deterministic parameters provide a sustainable alternative to traditional testnets, with the same infrastructure. At each reset, the validator set is cleared, faucets are filled again and the database is kept small.</p> <p>Upon reset the whole state is purged, which, on the one hand keeps the network small and easy to bootstrap but introduces problems for testing longer term / advanced applications. However, basic contract infrastructure can be automatically deployed after each reset by any user. Generally, using the network is recommended for short term testing, deploying <code>Hello World</code> kinds of contracts that don't need to stay forever on a long term testnet. However, there can be an offchain mechanism that automatically deploys standard contract primitives after each reset so application developers can also utilize the network more.</p> <p>By defining two mechanisms for Genesis and Reset, this EIP enables two levels of how a client implementation can support the testnet;</p> <ul> <li>Basic support requires the client to determine the current network specs and enables only connecting to the network. <ul> <li>This means support of the Genesis mechanism defined above</li> <li>Enough to participate in the network for short term testing</li> <li>To follow the latest iteration, the user has to manually shut down the client and delete the database</li> <li>It's still recommended to add a feature for terminating the network</li> </ul> </li> <li>Full support enables the client to follow the reset process and always sync the latest chain iteration <ul> <li>This also requires the client to implement an inherent Reset feature</li> <li>Needed for running persistent infrastructure, genesis validators and bootnodes</li> <li>It might be more complex to implement due to client architecture of clients</li> </ul> </li> </ul> <p>The design is also compatible with nodes managed by external tooling, i.e. even if the client doesn't implement these features, it can run on the same network as other nodes which are automatically reset by scripts. Any client supporting a custom network can be used for the testnet.</p> <h3 id="network-parameters">Network parameters</h3> <p>Constants and variables defining testnet properties are arbitrary but need to be crafted considering certain limitations and security properties set out below.</p> <h4 id="reset-period">Reset Period</h4> <p>The <code>period</code> is a constant, hardcoded in the client defining the period of time after which the network resets.</p> <p>It can be defined based on users' needs but for security reasons, it also depends on the number of validators in genesis. Considering the time to activate a validator, the number of trusted validators should be high enough so the network cannot be overtaken by a malicious actor.</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name">Genesis</span><span class="z-string"> Validators</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-string"> Epochs</span><span class="z-string"> until</span><span class="z-keyword"> &lt;</span><span class="z-string"> 66%</span><span class="z-string"> majority</span></span> <span class="giallo-l"><span class="z-entity z-name">10k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 1289</span><span class="z-string"> Epochs</span><span> (5,7</span><span class="z-string"> days</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name">50k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 6441</span><span class="z-string"> Epochs</span><span> (28,6</span><span class="z-string"> days</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name">75k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 9660</span><span class="z-string"> Epochs</span><span> (42,9</span><span class="z-string"> days</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name">100k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 12877</span><span class="z-string"> Epochs</span><span> (57,2</span><span class="z-string"> days</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name">150k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 19323</span><span class="z-string"> Epochs</span><span> (85,9</span><span class="z-string"> days</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name">200k</span><span> =</span><span class="z-keyword">&gt;</span><span class="z-constant"> 25764</span><span class="z-string"> Epochs</span><span> (114,5</span><span class="z-string"> days</span><span>)</span></span></code></pre><h4 id="chainid">ChainId</h4> <p>ChainId is a variable because it needs to keep changing with each new genesis to avoid replay attack. The function for the new ChainId value is a simple incrementation (+1). The ChainId in <code>genesis 0</code> is a hardcoded constant. This constant is used by the client with each new genesis to derive a new ChainId for that network iteration.</p> <p>New ChainIds shouldn't collide with any other existing public EVM chain even after many iterations. Consequently, low ChainId values are discouraged.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The network itself is providing a secure environment thanks to regular resets. Even if some sort of vulnerability is exploited, it will be cleared on the next reset. This is also a reason to keep periods relatively short (weeks/months opposed to months/years) with a big enough genesis validator set to keep an honest majority.</p> <p>Changes in clients caused by the implementation of features for resetting networks need to be reviewed together with standard security procedures. Especially the mechanism for triggering reset which must be separated from other networks that are not configured as ephemeral.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/6810/

Allow transactions to be reversed after confirmation

<h2 id="abstract">Abstract</h2> <p>A new transaction type reverts one of a sender's prior transactions, and other transactions dependent on that state, recursively.</p> <h2 id="motivation">Motivation</h2> <p>While Ethereum has the capability of reversible transactions through smart contracts, instant settlement is the default. But sometimes users make mistakes. Most mistakes are discovered quickly. However, once the transaction is confirmed, it is settled. There are many use cases for reverting settled transactions. Some of the most-common mistakes are listed below.</p> <ul> <li>Wrong recipient</li> <li>Unintended consequences</li> <li>Got scammed</li> </ul> <p>This feature addresses these issues and more, ending all regret.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <p>A new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> <code>0x5a</code>. The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is <code>rlp([chainId, nonce, revertNonce, budget, signatureYParity, signatureR, signatureS])</code>. The <code>signatureYParity, signatureR, signatureS</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(0x5a || rlp([chainId, nonce, revertNonce, budget]))</code>. The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, budgetUsed, removedLogsBloom, [newReceiptPayloads]])</code>, where <code>newReceiptPayloads</code> is a sequential array of the updated receipts of all reverted transactions.</p> <h3 id="block-gas-limit">Block gas limit</h3> <p>A transaction of type <code>0x5a</code> shall be the only transaction in its block.</p> <h3 id="cascading-revert-operation">Cascading revert operation</h3> <p>A transaction fee budget is initialized to the value specified by <code>budget</code>, denominated in ether. This budget is the transaction fee for this type of transaction. Reverted transaction fees are refunded from this budget. Should the budget be insufficient, the Ex Post Facto Cascading Revert transaction fails and the entire budget is paid to the <code>COINBASE</code> specified in the block header. Otherwise, the remainder of the budget after all transactions are reverted is paid to the <code>COINBASE</code> account.</p> <p>The state is rolled back to the start of the transaction specified by <code>revertNonce</code>. An access list is initialized empty. Any state previously modified by a reverted transaction is added to the access list. Any subsequent transaction reading or using state included in the access list must also be reverted. This operation cascades forward until the current block.</p> <p>State includes:</p> <ul> <li>ether balance</li> <li>contract code</li> <li>account nonce</li> <li>storage keys</li> </ul> <h3 id="snap-sync">Snap sync</h3> <p>Due to the large amount of state that may be modified by such a transaction, slower clients should use snap sync to load the new state.</p> <h2 id="rationale">Rationale</h2> <p>The transaction must fill the entire block to prevent MEV attacks.</p> <p>While some cascading reverts are highly consequential, others are considerably simpler. The budget ensures the full network cost of the operation is paid. For example, reversing a token transfer to the wrong recipient would be relatively cheap. On the other hand, it would be prohibitively expensive to revert all deposits to a custodial exchange.</p> <p>Transaction fees must be refunded from this budget rather than the prior block reward in order to protect the security of the consensus protocol.</p> <p>Snap sync should be safe because if the state root is invalid then the block producer could get slashed.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>If we find any backwards compatibility issue we can maybe reverse those transactions. If that doesn't work idk maybe need another hard fork.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>Reverting a transaction that ever funded an account reverts all of that account's subsequent transactions.</li> <li>Reverting the transaction that deploys a contract reverts all transactions interacting with that contract.</li> <li>Reverting a transfer to a new account does not revert other transactions.</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>Seems simple enough. TODO this later; should only take a few hours, tops.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This specification has been audited by Illinois Senator Robert Peters. No exploits were found.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-04-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Pandapip1https://github.com/Pandapip1 https://wg-eips.ritovision.com/6811/

Increases the block time to facilitate finality over cosmic distances

<h2 id="abstract">Abstract</h2> <p>This EIP makes a minimal number of changes to allow Ethereum to be used on the moon and other potentially habitable bodies in Earth's solar system. It changes the time between blocks, the per-block validator reward, and the number of blocks per epoch.</p> <h2 id="motivation">Motivation</h2> <p>It is impossible for today's Ethereum to literally "go to the moon" due to a limitation in the protocol: the block length. Should validators attempt to validate on the surface of the moon, they would find that the ~1.25 second communication delay (caused by the speed of light) might cause issues with synchronization, considering the 12-second timer between blocks. The validators would eventually be ejected on the terrestrial chain after leaking. If however a substantial number of validators are displaced (think 1/3), they might follow their own fork and would eventually eject the terrestrial to finalize their own chain.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <ul> <li>The time between blocks MUST be changed from 12 seconds to 600 seconds (10 minutes).</li> <li>The per-block validator reward MUST be multiplied by 50</li> <li>The number of blocks per epoch MUST be reduced from 4 to 2</li> </ul> <h2 id="rationale">Rationale</h2> <ul> <li>The block gas limit is multiplied by fifty to compensate for the time between blocks being multiplied by fifty.</li> <li>The per-block validator reward is also multiplied by fifty to compensate for the time between blocks being multiplied by fifty.</li> <li>Epochs are changed to be 2 blocks long so that finality can be reached in a reasonable amount of time.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Many applications expect mainnet transactions to be included in a short amount of time. This would clearly no longer be the case. Such applications should switch to planetary rollups. Syncing rollups across heavenly bodies is outside the scope of this proposal.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Definitely needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-03-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad https://wg-eips.ritovision.com/6780/

SELFDESTRUCT will recover all funds to the target but not delete the account, except when called in the same transaction as creation

<h2 id="abstract">Abstract</h2> <p>This EIP changes the functionality of the <code>SELFDESTRUCT</code> opcode. The new functionality will be only to send all Ether in the account to the target, except that the current behaviour is preserved when <code>SELFDESTRUCT</code> is called in the same transaction a contract was created.</p> <h2 id="motivation">Motivation</h2> <p>The <code>SELFDESTRUCT</code> opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account.</p> <p>This EIP implements this change. Applications that only use <code>SELFDESTRUCT</code> to retrieve funds will still work. Applications that only use <code>SELFDESTRUCT</code> in the same transaction as they created a contract will also continue to work without any changes.</p> <h2 id="specification">Specification</h2> <p>The behaviour of <code>SELFDESTRUCT</code> is changed in the following way:</p> <ol> <li> <p>When <code>SELFDESTRUCT</code> is executed in a transaction that is not the same as the contract calling <code>SELFDESTRUCT</code> was created:</p> <ul> <li>The current execution frame halts.</li> <li><code>SELFDESTRUCT</code> does not delete any data (including storage keys, code, or the account itself).</li> <li><code>SELFDESTRUCT</code> transfers the entire account balance to the target.</li> <li>Note that if the target is the same as the contract calling <code>SELFDESTRUCT</code> there is no net change in balances. Unlike the prior specification, Ether will not be burnt in this case.</li> <li>Note that no refund is given since <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a>.</li> <li>Note that the rules of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> regarding <code>SELFDESTRUCT</code> remain unchanged.</li> </ul> </li> <li> <p>When <code>SELFDESTRUCT</code> is executed in the same transaction as the contract was created:</p> <ul> <li><code>SELFDESTRUCT</code> continues to behave as it did prior to this EIP, this includes the following actions <ul> <li>The current execution frame halts.</li> <li><code>SELFDESTRUCT</code> deletes data as previously specified.</li> <li><code>SELFDESTRUCT</code> transfers the entire account balance to the target</li> <li>The account balance of the contact calling <code>SELFDESTRUCT</code> is set to <code>0</code>.</li> </ul> </li> <li>Note that if the target is the same as the contract calling <code>SELFDESTRUCT</code> that Ether will be burnt.</li> <li>Note that no refund is given since <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a>.</li> <li>Note that the rules of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> regarding <code>SELFDESTRUCT</code> remain unchanged.</li> </ul> </li> </ol> <p>A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract's new address it is still considered to be a contract creation.</p> <p>The <code>SELFDESTRUCT</code> opcode remains deprecated as specified in <a href="https://wg-eips.ritovision.com/6049/">EIP-6049</a>. Any use in newly deployed contracts is strongly discouraged even if this new behaviour is taken into account, and future changes to the EVM might further reduce the functionality of the opcode.</p> <h2 id="rationale">Rationale</h2> <p>Getting rid of the <code>SELFDESTRUCT</code> opcode has been considered in the past, and there are currently no strong reasons to use it. This EIP implements a behavior that will attempt to leave some common uses of <code>SELFDESTRUCT</code> working, while reducing the complexity of the change on EVM implementations that would come from contract versioning.</p> <p>Handling the account creation and contract creation as two distinct and possibly separate events is needed for use cases such as counterfactual accounts. By allowing the <code>SELFDESTRUCT</code> to delete the account at contract creation time it will not result in stubs of counterfactually instantiated contracts that never had any on-chain state other than a balance prior to the contract creation. These accounts would never have any storage and thus the trie updates to delete the account would be limited to the account node, which is the same impact a regular transfer of ether would have.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork, since it modifies consensus rules.</p> <p>Contracts that depended on re-deploying contracts at the same address using <code>CREATE2</code> (after a <code>SELFDESTRUCT</code>) will no longer function properly if the created contract does not call <code>SELFDESTRUCT</code> within the same transaction.</p> <p>Previously it was possible to burn ether by calling <code>SELFDESTRUCT</code> targeting the executing contract as the beneficiary. If the contract existed prior to the transaction the ether will not be burned. If the contract was newly created in the transaction the ether will be burned, as before.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for this EIP can be found in the Execution Spec Tests suite <a rel="external" href="https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip6780_selfdestruct"><code>eip6780_selfdestruct</code></a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The following applications of <code>SELFDESTRUCT</code> will be broken and applications that use it in this way are not safe anymore:</p> <ol> <li> <p>Where <code>CREATE2</code> is used to redeploy a contract in the same place in order to make a contract upgradable. This is not supported anymore and <a href="https://wg-eips.ritovision.com/2535/">ERC-2535</a> or other types of proxy contracts should be used instead.</p> </li> <li> <p>Where a contract depended on burning Ether via a <code>SELFDESTRUCT</code> with the contract as beneficiary, in a contract not created within the same transaction.</p> </li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-03-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Renan Rodrigues de Souzahttps://github.com/RenanSouza2 https://wg-eips.ritovision.com/684/

Revert contract creation if address already has code

<h2 id="abstract">Abstract</h2> <p>This EIP causes contract creation to throw an error when attempted at an address with pre-existing code. This prevents an attack consisting of deploying contract code and later changing the code arbitrarily by "creating" an account at that existing address.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>If a contract creation is attempted due to a creation transaction, the <code>CREATE</code> opcode, the <code>CREATE2</code> opcode, or any other reason, and the destination address already has either a nonzero nonce, or a nonzero code length, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.</p> <h2 id="rationale">Rationale</h2> <p>One of the core tenets of smart contracts is that their code will not change. However with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is an execution layer upgrade, and so it requires a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Given a genesis allocation of</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Address : 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5,</span></span> <span class="giallo-l"><span>Balance : 1000000000000000000, // 1 ether</span></span> <span class="giallo-l"><span>Nonce : 0,</span></span> <span class="giallo-l"><span>code : &quot;&quot;,</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>Address : 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826,</span></span> <span class="giallo-l"><span>Balance : 0,</span></span> <span class="giallo-l"><span>Nonce : 1,</span></span> <span class="giallo-l"><span>Code : &quot;0xB0B0FACE&quot;,</span></span></code></pre> <p>A contract created in the first transaction from EOA <code>0xd0bBEc6...</code> (<code>227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59</code>), with no salt, should revert.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP is a security upgrade: it enforces the immutability of deployed code.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-03-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad Kevaundray Wedderburnhttps://github.com/kevaundray Guillaume Ballethttps://github.com/gballet Piper Merriamhttps://github.com/pipermerriam Gottfried Heroldhttps://github.com/GottfriedHerold Ignacio Hagopianhttps://github.com/jsign Tanishq Jasoriahttps://github.com/tanishqjasoria Gajinder Singhhttps://github.com/g11tech Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/6800/

This introduces a new Verkle state tree alongside the existing MPT.

<h2 id="abstract">Abstract</h2> <p>Introduce a new Verkle state tree alongside the existing hexary Patricia tree. After the hard fork, the Verkle tree stores all edits to state and a copy of all accessed state, and the hexary Patricia tree can no longer be modified. This is a first step in a multi-phase transition to Ethereum exclusively relying on Verkle trees to store execution state.</p> <h2 id="motivation">Motivation</h2> <p>Verkle trees solve a key problem standing in the way of Ethereum being stateless-client-friendly: witness sizes. A witness accessing an account in today’s hexary Patricia tree is, in the average case, close to 3 kB, and in the worst case it may be three times larger. Assuming a worst case of 6000 accesses per block (15m gas / 2500 gas per access), this corresponds to a witness size of ~18 MB, which is too large to safely broadcast through a p2p network within a 12-second slot. Verkle trees reduce witness sizes to ~200 bytes per account in the average case, allowing stateless client witnesses to be acceptably small.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="verkle-tree-definition">Verkle tree definition</h3> <p>We define a Verkle tree here by providing the function to compute the root commitment given a set of 32-byte keys and 32-byte values. Algorithms for updating and inserting values are up to the implementer; the only requirement is that the root commitment after the update must continue to match the value computed from this specification. We will then define an embedding that provides the 32-byte key at which any particular piece of state information (account headers, code, storage) should be stored.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span># Bandersnatch curve order</span></span> <span class="giallo-l"><span>BANDERSNATCH_MODULUS = \</span></span> <span class="giallo-l"><span>13108968793781547619861935127046491459309155893440570251786403306729687672801</span></span> <span class="giallo-l"><span># Bandersnatch Pedersen basis of length 256</span></span> <span class="giallo-l"><span>PEDERSEN_BASIS = [....]</span></span> <span class="giallo-l"><span>VERKLE_NODE_WIDTH = len(PEDERSEN_BASIS)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def group_to_scalar_field(point: Point) -&gt; int:</span></span> <span class="giallo-l"><span> # Not collision resistant. Not random oracle. </span></span> <span class="giallo-l"><span> # Binding for Pedersen commitments.</span></span> <span class="giallo-l"><span> assert isinstance(point, Point)</span></span> <span class="giallo-l"><span> if point == bandersnatch.Z:</span></span> <span class="giallo-l"><span> return 0</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> return point.map_to_base_field() % BANDERSNATCH_MODULUS</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>def compute_commitment_root(children: Sequence[int]) -&gt; Point:</span></span> <span class="giallo-l"><span> o = bandersnatch.Z</span></span> <span class="giallo-l"><span> for generator, child in zip(PEDERSEN_BASIS, children):</span></span> <span class="giallo-l"><span> o = bandersnatch.add(o, bandersnatch.mul(generator, child))</span></span> <span class="giallo-l"><span> return o</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def extension_and_suffix_tree(stem: bytes31, values: Dict[byte, bytes32]) -&gt; int:</span></span> <span class="giallo-l"><span> sub_leaves = [0] * 512</span></span> <span class="giallo-l"><span> for suffix, value in values.items():</span></span> <span class="giallo-l"><span> sub_leaves[2 * suffix] = int.from_bytes(value[:16], &#39;little&#39;) + 2**128</span></span> <span class="giallo-l"><span> sub_leaves[2 * suffix + 1] = int.from_bytes(value[16:], &#39;little&#39;)</span></span> <span class="giallo-l"><span> C1 = compute_commitment_root(sub_leaves[:256])</span></span> <span class="giallo-l"><span> C2 = compute_commitment_root(sub_leaves[256:])</span></span> <span class="giallo-l"><span> return compute_commitment_root([1, # Extension marker</span></span> <span class="giallo-l"><span> int.from_bytes(stem, &quot;little&quot;),</span></span> <span class="giallo-l"><span> group_to_scalar_field(C1),</span></span> <span class="giallo-l"><span> group_to_scalar_field(C2)] +</span></span> <span class="giallo-l"><span> [0] * 252)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def compute_main_tree_root(data: Dict[bytes32, int],</span></span> <span class="giallo-l"><span> prefix: bytes) -&gt; int:</span></span> <span class="giallo-l"><span> # Empty subtree: 0</span></span> <span class="giallo-l"><span> if len(data) == 0:</span></span> <span class="giallo-l"><span> return 0</span></span> <span class="giallo-l"><span> elif len(data) == 1:</span></span> <span class="giallo-l"><span> return list(data.values())[0]</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> sub_commitments = [</span></span> <span class="giallo-l"><span> compute_main_tree_root({</span></span> <span class="giallo-l"><span> key: value for key, value in data.items() if</span></span> <span class="giallo-l"><span> key[:len(prefix) + 1] == prefix + bytes([i])</span></span> <span class="giallo-l"><span> }, prefix + bytes([i]))</span></span> <span class="giallo-l"><span> for i in range(VERKLE_NODE_WIDTH)</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> return group_to_scalar_field(compute_commitment_root(sub_commitments))</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def compute_verkle_root(data: Dict[bytes32, bytes32]) -&gt; Point:</span></span> <span class="giallo-l"><span> stems = set(key[:-1] for key in data.keys())</span></span> <span class="giallo-l"><span> data_as_stems = {}</span></span> <span class="giallo-l"><span> for stem in stems:</span></span> <span class="giallo-l"><span> commitment_data = Dict[byte, bytes32]()</span></span> <span class="giallo-l"><span> for i in range(VERKLE_NODE_WIDTH):</span></span> <span class="giallo-l"><span> if stem + bytes([i]) in data:</span></span> <span class="giallo-l"><span> commitment_data[i] = data[stem + bytes([i])]</span></span> <span class="giallo-l"><span> data_as_stems[stem] = extension_and_suffix_tree(stem, commitment_data)</span></span> <span class="giallo-l"><span> sub_commitments = [</span></span> <span class="giallo-l"><span> compute_main_tree_root({</span></span> <span class="giallo-l"><span> key: value for key, value in data.items() if</span></span> <span class="giallo-l"><span> key[0] == i</span></span> <span class="giallo-l"><span> }, bytes([i]))</span></span> <span class="giallo-l"><span> for i in range(VERKLE_NODE_WIDTH)</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> return compute_commitment_root(sub_commitments)</span></span></code></pre> <p>Note that a value of zero is not the same thing as a position being empty; a position being empty is represented as 0 in the bottom layer commitment, but a position being zero is represented by a different value in the suffix tree commitment (2**128 is added to value_lower to distinguish it from empty). This distinction between zero and empty is not a property of the existing Patricia tree, but it is a property of the proposed Verkle tree.</p> <p>In the rest of this document, saving or reading a number at some position in the Verkle tree will mean saving or reading the 32-byte little-endian encoding of that number.</p> <h3 id="illustration">Illustration</h3> <p>This is an illustration of the tree structure.</p> <p><img src="https://wg-eips.ritovision.com/6800/./assets/tree_structure.png" alt="tree structure" /></p> <h3 id="tree-embedding">Tree embedding</h3> <p>Instead of a two-layer structure as in the Patricia tree, in the Verkle tree we will embed all information into a single <code>key: value</code> tree. This section specifies which tree keys store the information (account header data, code, storage) in the state.</p> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td>BASIC_DATA_LEAF_KEY</td><td>0</td></tr> <tr><td>CODE_HASH_LEAF_KEY</td><td>1</td></tr> <tr><td>HEADER_STORAGE_OFFSET</td><td>64</td></tr> <tr><td>CODE_OFFSET</td><td>128</td></tr> <tr><td>VERKLE_NODE_WIDTH</td><td>256</td></tr> <tr><td>MAIN_STORAGE_OFFSET</td><td>256**31</td></tr> </tbody></table> <p><em>It’s a required invariant that <code>VERKLE_NODE_WIDTH &gt; CODE_OFFSET &gt; HEADER_STORAGE_OFFSET</code> and that <code>HEADER_STORAGE_OFFSET</code> is greater than the leaf keys. Additionally, <code>MAIN_STORAGE_OFFSET</code> must be a power of <code>VERKLE_NODE_WIDTH</code>.</em></p> <p>Note that addresses are always passed around as an <code>Address32</code>. To convert existing addresses to <code>Address32</code>, prepend with 12 zero bytes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def old_style_address_to_address32(address: Address) -&gt; Address32:</span></span> <span class="giallo-l"><span> return b&#39;\x00&#39; * 12 + address</span></span></code></pre><h4 id="header-values">Header values</h4> <p>These are the positions in the tree at which block header fields of an account are stored.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def hash_point_to_bytes(point: Point) -&gt; int:</span></span> <span class="giallo-l"><span> return group_to_scalar_field(point).to_bytes(32, &#39;little&#39;)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def pedersen_hash(inp: bytes) -&gt; bytes32:</span></span> <span class="giallo-l"><span> assert len(inp) &lt;= 255 * 16</span></span> <span class="giallo-l"><span> # Interpret input as list of 128 bit (16 byte) integers</span></span> <span class="giallo-l"><span> ext_input = inp + b&quot;\0&quot; * (255 * 16 - len(inp))</span></span> <span class="giallo-l"><span> ints = [2 + 256 * len(inp)] + \</span></span> <span class="giallo-l"><span> [int.from_bytes(ext_input[16 * i:16 * (i + 1)], &#39;little&#39;) for i in range(255)]</span></span> <span class="giallo-l"><span> return compute_commitment_root(ints).hash_point_to_bytes()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def get_tree_key(address: Address32, tree_index: int, sub_index: int):</span></span> <span class="giallo-l"><span> # Assumes VERKLE_NODE_WIDTH = 256</span></span> <span class="giallo-l"><span> return (</span></span> <span class="giallo-l"><span> pedersen_hash(address + tree_index.to_bytes(32, &#39;little&#39;))[:31] +</span></span> <span class="giallo-l"><span> bytes([sub_index])</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>def get_tree_key_for_basic_data(address: Address32):</span></span> <span class="giallo-l"><span> return get_tree_key(address, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span># Backwards compatibility for EXTCODEHASH </span></span> <span class="giallo-l"><span>def get_tree_key_for_code_hash(address: Address32):</span></span> <span class="giallo-l"><span> return get_tree_key(address, 0, CODE_HASH_LEAF_KEY)</span></span></code></pre> <p>An account's <code>version</code>, <code>balance</code>, <code>nonce</code> and <code>code_size</code> fields are packed with big-endian encoding in the value found at <code>BASIC_DATA_LEAF_KEY</code>:</p> <table><thead><tr><th>Name</th><th>Offset</th><th>Size</th></tr></thead><tbody> <tr><td><code>version</code></td><td>0</td><td>1</td></tr> <tr><td><code>code_size</code></td><td>5</td><td>3</td></tr> <tr><td><code>nonce</code></td><td>8</td><td>8</td></tr> <tr><td><code>balance</code></td><td>16</td><td>16</td></tr> </tbody></table> <p>Bytes <code>1..4</code> are reserved for future use.</p> <p>The current layout and encoding allow for an extension of <code>code_size</code> to 4 bytes without changing the account version.</p> <p>When any account header field is set, the <code>version</code> field is also set to zero. The <code>codehash</code> and <code>code_size</code> fields are set upon contract or EoA creation.</p> <h4 id="code">Code</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_tree_key_for_code_chunk(address: Address32, chunk_id: int):</span></span> <span class="giallo-l"><span> return get_tree_key(</span></span> <span class="giallo-l"><span> address,</span></span> <span class="giallo-l"><span> (CODE_OFFSET + chunk_id) // VERKLE_NODE_WIDTH,</span></span> <span class="giallo-l"><span> (CODE_OFFSET + chunk_id) % VERKLE_NODE_WIDTH</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>Chunk <code>i</code> stores a 32 byte value, where bytes 1…31 are bytes <code>i*31...(i+1)*31 - 1</code> of the code (ie. the i’th 31-byte slice of it), and byte 0 is the number of leading bytes that are part of PUSHDATA (eg. if part of the code is <code>...PUSH4 99 98 | 97 96 PUSH1 128 MSTORE...</code> where <code>|</code> is the position where a new chunk begins, then the encoding of the latter chunk would begin <code>2 97 96 PUSH1 128 MSTORE</code> to reflect that the first 2 bytes are PUSHDATA).</p> <p>For precision, here is an implementation of code chunkification:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH_OFFSET = 95</span></span> <span class="giallo-l"><span>PUSH1 = PUSH_OFFSET + 1</span></span> <span class="giallo-l"><span>PUSH32 = PUSH_OFFSET + 32</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def chunkify_code(code: bytes) -&gt; Sequence[bytes32]:</span></span> <span class="giallo-l"><span> # Pad to multiple of 31 bytes</span></span> <span class="giallo-l"><span> if len(code) % 31 != 0:</span></span> <span class="giallo-l"><span> code += b&#39;\x00&#39; * (31 - (len(code) % 31))</span></span> <span class="giallo-l"><span> # Figure out how much pushdata there is after+including each byte</span></span> <span class="giallo-l"><span> bytes_to_exec_data = [0] * (len(code) + 32)</span></span> <span class="giallo-l"><span> pos = 0</span></span> <span class="giallo-l"><span> while pos &lt; len(code):</span></span> <span class="giallo-l"><span> if PUSH1 &lt;= code[pos] &lt;= PUSH32:</span></span> <span class="giallo-l"><span> pushdata_bytes = code[pos] - PUSH_OFFSET</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> pushdata_bytes = 0</span></span> <span class="giallo-l"><span> pos += 1</span></span> <span class="giallo-l"><span> for x in range(pushdata_bytes):</span></span> <span class="giallo-l"><span> bytes_to_exec_data[pos + x] = pushdata_bytes - x</span></span> <span class="giallo-l"><span> pos += pushdata_bytes</span></span> <span class="giallo-l"><span> # Output chunks</span></span> <span class="giallo-l"><span> return [</span></span> <span class="giallo-l"><span> bytes([min(bytes_to_exec_data[pos], 31)]) + code[pos: pos+31]</span></span> <span class="giallo-l"><span> for pos in range(0, len(code), 31)</span></span> <span class="giallo-l"><span> ]</span></span></code></pre><h4 id="storage">Storage</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def get_tree_key_for_storage_slot(address: Address32, storage_key: int):</span></span> <span class="giallo-l"><span> if storage_key &lt; (CODE_OFFSET - HEADER_STORAGE_OFFSET):</span></span> <span class="giallo-l"><span> pos = HEADER_STORAGE_OFFSET + storage_key</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> pos = MAIN_STORAGE_OFFSET + storage_key</span></span> <span class="giallo-l"><span> return get_tree_key(</span></span> <span class="giallo-l"><span> address,</span></span> <span class="giallo-l"><span> pos // VERKLE_NODE_WIDTH,</span></span> <span class="giallo-l"><span> pos % VERKLE_NODE_WIDTH</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>Note that storage slots in the same size <code>VERKLE_NODE_WIDTH</code> range (ie. a range the form <code>x*VERKLE_NODE_WIDTH ... (x+1)*VERKLE_NODE_WIDTH-1)</code> are all, with the exception of the <code>HEADER_STORAGE_OFFSET</code> special case, part of a single commitment. This is an optimization to make witnesses more efficient when related storage slots are accessed together. If desired, this optimization can be exposed to the gas schedule, making it more gas-efficient to make contracts that store related slots together (however, Solidity already stores in this way by default).</p> <h4 id="fork">Fork</h4> <p>Described in <a href="https://wg-eips.ritovision.com/7612/">EIP-7612</a>.</p> <h4 id="access-events">Access events</h4> <p>Described in <a href="https://wg-eips.ritovision.com/4762/">EIP-4762</a>.</p> <h2 id="rationale">Rationale</h2> <p>This implements all of the logic in transitioning to a Verkle tree, and at the same time reforms gas costs, but does so in a minimally disruptive way that does not require simultaneously changing the whole tree structure. Instead, we add a new Verkle tree that starts out empty, and only new changes to state and copies of accessed state are stored in the tree. The Patricia tree continues to exist, but is frozen.</p> <p>This sets the stage for a future hard fork that swaps the Patricia tree in-place with a Verkle tree storing the same data. Unlike <a href="https://wg-eips.ritovision.com/2584/">EIP-2584</a>, this replacement Verkle tree does not need to be computed by clients in real time. Instead, because the Patricia tree would at that point be fixed, the replacement Verkle tree can be computed off-chain.</p> <h3 id="verkle-tree-design">Verkle tree design</h3> <p>The Verkle tree uses a single-layer tree structure with 32-byte keys and values for several reasons:</p> <ul> <li><strong>Simplicity</strong>: working with the abstraction of a key/value store makes it easier to write code dealing with the tree (eg. database reading/writing, caching, syncing, proof creation and verification) as well as to upgrade it to other trees in the future. Additionally, witness gas rules can become simpler and clearer.</li> <li><strong>Uniformity</strong>: the state is uniformly spread out throughout the tree; even if a single contract has many millions of storage slots, the contract’s storage slots are not concentrated in one place. This is useful for state syncing algorithms. Additionally, it helps reduce the effectiveness of unbalanced tree filling attacks.</li> <li><strong>Extensibility</strong>: account headers and code being in the same structure as storage makes it easier to extend the features of both, and even add new structures if later desired.</li> </ul> <h3 id="gas-reform">Gas reform</h3> <p>Gas costs for reading storage and code are reformed to more closely reflect the gas costs under the new Verkle tree design. WITNESS_CHUNK_COST is set to charge 6.25 gas per byte for chunks, and WITNESS_BRANCH_COST is set to charge ~13,2 gas per byte for branches on average (assuming 144 byte branch length) and ~2.5 gas per byte in the worst case if an attacker fills the tree with keys deliberately computed to maximize proof length.</p> <p>The main differences from gas costs in Berlin are:</p> <ul> <li>200 gas charged per 31 byte chunk of code. This has been estimated to increase average gas usage by ~6-12%</li> <li>Cost for accessing adjacent storage slots (<code>key1 // 256 == key2 // 256</code>) decreases from 2100 to 200 for all slots after the first in the group,</li> <li>Cost for accessing storage slots 0…63 decreases from 2100 to 200, including the first storage slot. This is likely to significantly improve performance of many existing contracts, which use those storage slots for single persistent variables.</li> </ul> <p>Gains from the latter two properties have not yet been analyzed, but are likely to significantly offset the losses from the first property. It’s likely that once compilers adapt to these rules, efficiency will increase further.</p> <p>The precise specification of when access events take place, which makes up most of the complexity of the gas repricing, is necessary to clearly specify when data needs to be saved to the period 1 tree.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The main backwards-compatibility-breaking changes are:</p> <ul> <li>(1) Gas costs for code chunk access making some applications less economically viable</li> <li>(2) Tree structure change makes in-EVM proofs of historical state no longer work</li> </ul> <p>(1) can be mitigated by increasing the gas limit at the same time as implementing this EIP, reducing the risk that applications will no longer work at all due to transaction gas usage rising above the block gas limit.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="reference-implementation">Reference Implementation</h2> <ul> <li>github.com/gballet/go-ethereum, branch beverly-hills-just-after-pbss - a geth implementation</li> <li>github.com/NethermindEth/nethermind, branch verkle/tree - a nethermind implementation</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-03-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Jared Wasingerhttps://github.com/jwasinger Alex Beregszaszihttps://github.com/axic Vitalik Buterinhttps://github.com/vbuterin Radosław Zagórowiczhttps://github.com/rodiazet Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/6690/

Expanded-width, efficient modular arithmetic operations for the EVM

<h2 id="abstract">Abstract</h2> <p>This EIP proposes new EVM modular arithmetic opcodes which support operations on odd or power-of-two moduli between 3 and 2**768-1</p> <h2 id="motivation">Motivation</h2> <p>Current opcodes for modular arithmetic only support values up to 256 bits wide. In addition, they are permissive and accept any representable value for the inputs.</p> <p>Many cryptographic operations are heavily-bottlenecked by modular arithmetic. To expand the range of cryptographic primitives that can be implemented efficiently as EVM contracts, we propose new modular arithmetic opcodes designed for efficiency.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>COST_SETMODX_BASE</code></td><td>1</td><td>static cost component for the <code>SETMODX</code> opcode</td></tr> <tr><td><code>COST_STOREX_BASE</code></td><td>1</td><td>static cost for the <code>STOREX</code> opcode</td></tr> <tr><td><code>COST_LOADX_BASE</code></td><td>1</td><td>static cost for the <code>LOADX</code> opcode</td></tr> </tbody></table> <h3 id="conventions">Conventions</h3> <ol> <li>The use of <code>assert</code> implies that if the assertion fails, the current call frame will consume all call gas and terminate call execution in an exceptional state.</li> <li>Unless otherwise stated, the implied unit for size is bytes.</li> </ol> <h3 id="overview">Overview</h3> <p>The execution state of an EVM call frame is modified to include a mapping of <code>id</code> (a number 0-256) to a field context. A field context comprises a modulus and an allocated space of virtual registers to perform modular arithmetic operations on.</p> <p>An executing contract uses a new instruction <code>SETMODX</code> to set the active field context, allocating a new one in the mapping if it does not already exist for <code>id</code>.</p> <p>New arithmetic opcodes perform modular addition, subtraction and multiplication with inputs/outputs from virtual registers of the active field context.</p> <p>New load/store opcodes copy values to and from EVM memory and the virtual registers allocated by the active field context.</p> <h3 id="new-opcodes">New Opcodes</h3> <h4 id="setmodx-0xc0"><code>SETMODX(0xc0)</code></h4> <p><strong>Input</strong>: <code>&lt;top of stack&gt; id modulus_offset modulus_size alloc_count</code>.</p> <p><strong>Output</strong>: none</p> <h5 id="execution">Execution</h5> <p>Charge <code>COST_SETMODX_BASE</code>.</p> <p>Assert <code>0 &lt;= id &lt;= 256</code>.</p> <p>If a field context for <code>id</code> exists in this call scope:</p> <ul> <li>Set it as the active one.</li> </ul> <p>Otherwise:</p> <ul> <li>Assert <code>modulus_size &lt;= 96</code>.</li> <li>Assert that the byte range<code>[modulus_offset, modulus_offset+modulus_size]</code> falls within EVM memory.</li> <li>Load the byte range from EVM memory, interpreting it as a big endian <code>modulus</code>.</li> <li>Assert <code>modulus</code> is odd or is a power of two.</li> <li>Assert <code>3 &lt;= modulus &lt;= 2**768 - 1</code>.</li> <li>Assert <code>0 &lt; alloc_count &lt;= 256</code>.</li> <li>Define the size of elements stored in virtual registers: <code>element_size</code> as the size needed to represent the modulus padded to be a multiple of 64 bits. Implementations will align virtual register values along system-word lines.</li> <li>assert that the new size of all virtual registers allocated in the current call-context does not exceed 24576 bytes.</li> <li>Charge EVM memory expansion cost to expand memory by <code>alloc_count * element_size</code> bytes:.</li> <li>if the modulus is odd, charge the dynamic cost component (defined below)</li> <li>Allocate the new field context with <code>alloc_count</code> initially-zeroed registers. Associate it with <code>id</code> in the mapping.</li> <li>The new field context is now set as the active one.</li> </ul> <h5 id="dynamic-cost-component-for-odd-moduli">Dynamic Cost Component for Odd Moduli</h5> <table><thead><tr><th>Modulus size (padded to nearest 64 bits)</th><th>cost</th></tr></thead><tbody> <tr><td>64 bits</td><td>23</td></tr> <tr><td>128 bits</td><td>26</td></tr> <tr><td>192 bits</td><td>29</td></tr> <tr><td>256 bits</td><td>32</td></tr> <tr><td>320 bits</td><td>36</td></tr> <tr><td>384 bits</td><td>39</td></tr> <tr><td>448 bits</td><td>42</td></tr> <tr><td>512 bits</td><td>45</td></tr> <tr><td>576 bits</td><td>48</td></tr> <tr><td>640 bits</td><td>51</td></tr> <tr><td>704 bits</td><td>54</td></tr> <tr><td>768 bits</td><td>58</td></tr> </tbody></table> <p>The values in this table are based on the following linear cost model:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def cost_setmodx_dynamic(modulus_size: int) -&gt; int:</span></span> <span class="giallo-l"><span> limb_count = (modulus_size + 7) / 8</span></span> <span class="giallo-l"><span> return round(limb_count * 3.13 + 19.94)</span></span></code></pre><h4 id="arithmetic-opcodes">Arithmetic Opcodes</h4> <p>Opcodes <code>ADDMODX(0xc3)</code>, <code>SUBMODX(0xc4)</code>, <code>MULMODX(0xc5)</code> take a 7 byte immediate interpreted as byte values <code>out_idx</code>, <code>out_stride</code>, <code>x_idx</code>, <code>x_stride</code>, <code>y_idx</code>, <code>y_stride</code>, <code>count</code>.</p> <p>Define cost tables for each arithmetic operation based on the modulus:</p> <table><thead><tr><th>Modulus size (padded to nearest 64 bits)</th><th>cost per add/sub</th><th>cost per mul</th></tr></thead><tbody> <tr><td>64</td><td>1</td><td>1</td></tr> <tr><td>128</td><td>1</td><td>1</td></tr> <tr><td>192</td><td>1</td><td>1</td></tr> <tr><td>256</td><td>1</td><td>2</td></tr> <tr><td>320</td><td>1</td><td>2</td></tr> <tr><td>384</td><td>1</td><td>3</td></tr> <tr><td>448</td><td>1</td><td>4</td></tr> <tr><td>512</td><td>2</td><td>5</td></tr> <tr><td>576</td><td>2</td><td>7</td></tr> <tr><td>640</td><td>2</td><td>8</td></tr> <tr><td>704</td><td>2</td><td>10</td></tr> <tr><td>768</td><td>2</td><td>12</td></tr> </tbody></table> <p>The values in this table correspond to the following cost models:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def cost_add_or_sub(modulus_size: int) -&gt; int:</span></span> <span class="giallo-l"><span> limb_count = (modulus_size + 7) // 8</span></span> <span class="giallo-l"><span> return round(limb_count * 0.12 + 0.58)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span>def cost_mul(modulus_size: int) -&gt; int:</span></span> <span class="giallo-l"><span> limb_count = (modulus_size + 7) // 8</span></span> <span class="giallo-l"><span> return round((0.08 * limb_count**2) + (-0.06 * limb_count) + 0.75)</span></span></code></pre> <p>Execution asserts:</p> <ul> <li>all accessed values fall within bounds: <code>max([out_idx + (out_stride * count), x_idx + (x_stride * count), y_idx + (y_stride * count)]) &lt; len(field_context.registers)</code></li> <li><code>out_stride != 0</code></li> <li><code>count != 0</code></li> <li>an active field context <code>active_ctx</code> is set.</li> </ul> <p>Then, charge <code>count * operation_cost</code> where <code>operation_cost</code> is drawn from the cost table. Compute:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>for i in range(count):</span></span> <span class="giallo-l"><span> active_ctx.registers[out_idx+i*out_stride] = operation(active_ctx.registers[x_idx+i*x_stride], active_ctx.registers[y_idx+i*y_stride])</span></span></code></pre> <p>Where <code>operation</code> computes modular addition, subtraction or multiplication depending on the opcode.</p> <p>Note: Inputs/outputs can overlap. <code>active_ctx.registers</code> is not modified until all operations in the loop have completed.</p> <h4 id="data-transfer-opcodes">Data Transfer Opcodes</h4> <p>Note: serialization format for values in EVM memory: big-endian padded to <code>active_ctx.element_size</code> bytes.</p> <h5 id="loadx-0xc1"><code>LOADX(0xc1)</code></h5> <p><strong>Stack in</strong>: <code>(top of stack) dest source count</code></p> <p><strong>Stack out</strong>: none</p> <p><strong>Description</strong>: copies values from registers in the currently-active field context to EVM memory.</p> <h6 id="execution-1">Execution</h6> <ul> <li>Assert that a field context is set as active in the current call frame.</li> <li>Assert that the range <code>[source, source + count]</code> falls within the active field context's zero-indexed value space.</li> <li>Assert that the range <code>[dest, dest + count * active_ctx.element_size]</code> falls entirely within EVM memory.</li> <li>If modulus is a power of two: <ul> <li>charge <code>(active_ctxt.element_size + 31) // 32 * 3</code> gas (the same as the memory copying component for the <code>MCOPY</code> opcode)</li> </ul> </li> <li>If modulus is odd: <ul> <li>charge <code>count * operation_cost</code> gas, where <code>operation_cost</code> is looked up from the multiplication cost table, given <code>active_ctxt.element_size</code>.</li> </ul> </li> <li>copy virtual register values <code>[source, source + count]</code> to memory <code>[dest, dest + count * active_ctx.element_size]</code>.</li> </ul> <h5 id="storex-0xc2"><code>STOREX(0xc2)</code></h5> <p><strong>Stack in</strong>: <code>dest source count</code></p> <p><strong>Stack out</strong>: none</p> <p><strong>Description</strong>: copies values from EVM memory into registers of the currently-active field context.</p> <h6 id="execution-2">Execution</h6> <ul> <li>Assert that a field context is set as active in the current call frame.</li> <li>Assert <code>dest + count</code> is less than or equal to the number of the active field context's virtual registers.</li> <li>If modulus of the active context is a power of two: <ul> <li>charge <code>cost_mem_copy(count * active_ctx.element_size)</code> (TBD: deliberately didn't choose <code>mcopy</code> gas model to see if this can consider a cheaper one).</li> </ul> </li> <li>Else if modulus of the active context is odd: <ul> <li>charge <code>count * operation_cost</code> gas, where <code>operation_cost</code> is looked up from the multiplication cost table, given <code>active_ctxt.element_size</code>.</li> </ul> </li> <li>Assert that <code>[source, source + count * active_context.element_size]</code> falls entirely within EVM memory. Interpret it as <code>count</code> number of values, asserting that each is less than the modulus and storing them in the registers <code>[dest, dest + count]</code>.</li> </ul> <h3 id="evm-memory-expansion-cost-modification">EVM Memory Expansion Cost Modification</h3> <p>When expanding EVM memory or allocating a new field context via <code>SETMODX</code>, expansion cost will now consider the size of all allocated virtual registers in the current call frame.</p> <h2 id="rationale">Rationale</h2> <h3 id="separation-of-evm-memory-and-evmmax-virtual-register-space">Separation of EVM Memory and EVMMAX Virtual Register Space</h3> <p>It is assumed that optimized implementations will not store values in EVM-compatible big-endian serialization format, but instead convert them to an internal working representation. The costs in the spec explicitly reflect the choice of Montgomery form as an optimal internal representation.</p> <p>Values represented in Montgomery form can make use of optimized modular reduction for multiplication. See the dedicated section on Montgomery multiplication in the rationale for more details.</p> <h3 id="total-virtual-register-allocation-cap">Total Virtual Register Allocation Cap</h3> <p>24576 bytes is chosen as the per-call-context allocation limit with the goal of ensuring that the virtual register space can be contained in the L1 CPU data cache of most machines (with room to spare), in order that arithmetic operation costs do not have to account for memory access latency.</p> <h3 id="setmodx-cost">SETMODX cost</h3> <p>For odd moduli, <code>SETMODX</code> precomputes two values used for optimized modular multiplication via Montgomery reduction. This is dominated by a modular reduction by the modulus, so the cost model is assumed to be linear.</p> <p>Power-of-two moduli require no precomputation for optimized modular arithmetic.</p> <h3 id="loadx-storex-costs">LOADX/STOREX costs</h3> <p>For power-of-two moduli, <code>LOADX</code>/<code>STOREX</code> are assumed to copy values directly between EVM/EVMMAX memories without measurable conversion cost to convert between EVM big-endian serialization and whatever internal representation is used.</p> <p>For odd moduli, the spec assumes that the internal representation is Montgomery form. Conversion between canonical/Montgomery form requires one modular multiplication per value per direction. The cost of memory copying is baked in to the multiplication price model.</p> <h3 id="arithmetic-costs">Arithmetic Costs</h3> <p>Addition/subtraction/multiplication are assumed to have constant-time implementations. Addition/subtraction can be implemented with linear complexity, while multiplication is quadratic in the size of the modulus.</p> <p>The costs for power-of-two modular multiplication are provisional, and likely be brought down when an optimized arithmetic implementation is rolled out and benchmarked.</p> <h3 id="montgomery-modular-multiplication">Montgomery Modular Multiplication</h3> <p>For a value <code>A</code>, an odd modulus <code>M</code> and a value <code>R</code> (must be coprime and greater than <code>M</code>, chosen as a power of two for efficient performance), the Montgomery representation is <code>A * R % M</code>.</p> <p>Define the Montgomery modular multiplication of two values <code>A</code> and <code>B</code>: <code>mulmont(A, B, M): A * B * R**-1 % M</code> where <code>R**-1 % M</code> is the modular inverse of <code>R</code> with respect to <code>M</code>. There is various literature and algorithms for computing <code>mulmont</code> which have been published since 1985, and the operation is used ubiquitously where execution is bottlenecked by operations over odd moduli.</p> <p>Note that normal modular addition and subtraction algorithms work for Montgomery form values.</p> <h4 id="conversion-of-canonical-to-montgomery-representation">Conversion of Canonical to Montgomery Representation</h4> <p><code>mulmont(canon_val, R**2 % M, M) = mont_val</code></p> <h4 id="conversion-from-montgomery-to-canonical-representation">Conversion from Montgomery to Canonical representation</h4> <p><code>mulmont(mont_val, 1, M) = canon_val</code></p> <h4 id="implementation">Implementation</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span># Basic Montgomery Multiplication</span></span> <span class="giallo-l"><span># x, y, mod (int) - x &lt; mod and y &lt; mod</span></span> <span class="giallo-l"><span># mod (int) - an odd modulus</span></span> <span class="giallo-l"><span># R (int) - a power of two, and greater than mod</span></span> <span class="giallo-l"><span># mont_const (int) - pow(-mod, -1, R), precomputed</span></span> <span class="giallo-l"><span># output:</span></span> <span class="giallo-l"><span># (x * y * pow(R, -1, mod)) % mod</span></span> <span class="giallo-l"><span>#</span></span> <span class="giallo-l"><span>def mulmont(x: int, y: int, mod: int, mont_const: int, R: int) -&gt; int:</span></span> <span class="giallo-l"><span> t = x * y</span></span> <span class="giallo-l"><span> m = ((t % R) * mont_const) % R</span></span> <span class="giallo-l"><span> t = t + m * mod</span></span> <span class="giallo-l"><span> t /= R</span></span> <span class="giallo-l"><span> if t &gt;= mod:</span></span> <span class="giallo-l"><span> t -= mod</span></span> <span class="giallo-l"><span> return t</span></span></code></pre> <p>There are various optimized algorithms for computing Montgomery Multiplication of bigint numbers expressed as arrays of system words.</p> <p>These all use a different precomputed constant <code>mont_const = pow(-mod, -1, 2**SYSTEM_WORD_SIZE_BITS)</code>.</p> <h2 id="test-cases">Test Cases</h2> <p>There are tests contained in the Geth implementation. However, no cross-client tests exist yet.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>There is an implementation of this EIP in an open PR to Go Ethereum.</p> <h2 id="security-considerations">Security Considerations</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-02-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech Matt Garnetthttps://github.com/lightclient Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/6493/

Signature scheme for native SSZ transactions

<h2 id="abstract">Abstract</h2> <p>This EIP defines a signature scheme for native <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md">Simple Serialize (SSZ)</a> encoded transactions.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/6404/">EIP-6404</a> introduces SSZ transactions by converting from RLP transactions. Defining a signature scheme for native SSZ transactions further reduces required conversions and unlocks the forward compatibility benefits of SSZ <a href="https://wg-eips.ritovision.com/7495/"><code>ProgressiveContainer</code></a>.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="transaction-signature-scheme">Transaction signature scheme</h3> <p>Native SSZ transactions are based on the <code>TransactionPayload</code> defined in <a href="https://wg-eips.ritovision.com/6404/">EIP-6404</a> and emit an <a href="https://wg-eips.ritovision.com/6466/">EIP-6466</a> <code>Receipt</code>. To distinguish native SSZ transactions from those converted from RLP, native SSZ transactions do not contain the RLP <code>TransactionType</code> field in their <code>TransactionPayload</code>.</p> <p>All native SSZ transactions follow a scheme based on <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md#merkleization"><code>hash_tree_root</code></a> to compute their signing hash (<code>sig_hash</code>). Likewise, native SSZ authorizations use such a scheme to derive their signing hash (<code>auth_hash</code>).</p> <p>Additional information is mixed into <code>sig_hash</code> and <code>auth_hash</code> to uniquely identify the underlying specification and avoid hash collisions across different signature kinds. Vendor-defined networks MUST use a different <code>DomainType</code> for signing custom transaction or authorization types.</p> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>DOMAIN_TX_SSZ</code></td><td><code>DomainType('0x01000008')</code></td><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#custom-types"><code>DomainType</code></a> for signing native SSZ transactions compatible with this EIP</td></tr> <tr><td><code>DOMAIN_AUTH_SSZ</code></td><td><code>DomainType('0x02000008')</code></td><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#custom-types"><code>DomainType</code></a> for signing native SSZ authorizations compatible with this EIP</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionSigningData</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> object_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span> domain_type</span><span>:</span><span> DomainType</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_ssz_sig_hash</span><span>(</span><span class="z-variable z-parameter z-function">payload</span><span>:</span><span> SszTransactionPayload</span><span>)</span><span> -&gt;</span><span> Hash32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Hash32</span><span>(</span><span>ExecutionSigningData</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> object_root</span><span class="z-keyword">=</span><span>payload</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> domain_type</span><span class="z-keyword">=</span><span class="z-constant">DOMAIN_TX_SSZ</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_ssz_auth_hash</span><span>(</span><span class="z-variable z-parameter z-function">payload</span><span>:</span><span> SszAuthorizationPayload</span><span>)</span><span> -&gt;</span><span> Hash32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Hash32</span><span>(</span><span>ExecutionSigningData</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> object_root</span><span class="z-keyword">=</span><span>payload</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> domain_type</span><span class="z-keyword">=</span><span class="z-constant">DOMAIN_AUTH_SSZ</span><span>,</span></span> <span class="giallo-l"><span> )</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span><span>)</span></span></code></pre><h3 id="native-transactions">Native transactions</h3> <p>New <a href="https://wg-eips.ritovision.com/7495/">EIP-6404</a> <code>TransactionPayload</code> definitions are introduced to represent native SSZ transactions:</p> <ul> <li><code>BasicTransactionPayload</code> and <code>CreateTransactionPayload</code> share the functionality of <a href="https://wg-eips.ritovision.com/1559/#specification">EIP-1559</a> fee market transactions</li> <li><code>BlobTransactionPayload</code> shares the functionality of <a href="https://wg-eips.ritovision.com/4844/#parameters">EIP-4844</a> blob transactions</li> <li><code>SetCodeTransactionPayload</code> shares the functionality of <a href="https://wg-eips.ritovision.com/7702/#parameters">EIP-7702</a> set code transactions; native SSZ types are introduced for authorizations</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BasicTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> CreateTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BlobTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BlobFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> blob_versioned_hashes</span><span>:</span><span> ProgressiveList</span><span>[</span><span>VersionedHash</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ReplayableBasicAuthorizationPayload</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BasicAuthorizationPayload</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SetCodeAuthorizationPayload</span><span>(</span><span class="z-entity">CompatibleUnion</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span><span>:</span><span> RlpReplayableBasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span><span>:</span><span> RlpBasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in EIP-6493]</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">11</span><span>:</span><span> ReplayableBasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">12</span><span>:</span><span> BasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SetCodeAuthorization</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> SetCodeAuthorizationPayload</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> ExecutionSignature</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SetCodeTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> authorization_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>SetCodeAuthorization</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>SszTransactionPayload</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> BasicTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> CreateTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> BlobTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> SetCodeTransactionPayload</span></span> <span class="giallo-l"><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>SszAuthorizationPayload</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> ReplayableBasicAuthorizationPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> BasicAuthorizationPayload</span></span> <span class="giallo-l"><span>)</span></span></code></pre><h4 id="transaction-helpers">Transaction helpers</h4> <p>The helpers from <a href="https://wg-eips.ritovision.com/6404/">EIP-6404</a> are updated to support native SSZ transactions.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> TransactionPayload</span><span>(</span><span class="z-entity">CompatibleUnion</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span><span>:</span><span> RlpLegacyReplayableBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span><span>:</span><span> RlpLegacyReplayableCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">03</span><span>:</span><span> RlpLegacyBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">04</span><span>:</span><span> RlpLegacyCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">05</span><span>:</span><span> RlpAccessListBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">06</span><span>:</span><span> RlpAccessListCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">07</span><span>:</span><span> RlpBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">08</span><span>:</span><span> RlpCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">09</span><span>:</span><span> RlpBlobTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">0a</span><span>:</span><span> RlpSetCodeTransactionPayload</span><span>,</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [New in EIP-6493]</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">11</span><span>:</span><span> BasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">12</span><span>:</span><span> CreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">13</span><span>:</span><span> BlobTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">14</span><span>:</span><span> SetCodeTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span></code></pre><h3 id="json-rpc">JSON-RPC</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>SSZ_TX_TYPE</code></td><td><code>TransactionType(0x1f)</code></td><td>Endpoint specific SSZ object</td></tr> </tbody></table> <p>Certain JSON-RPC endpoints such as <code>eth_getTransactionByHash</code> indicate the corresponding <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> envelope type prefix in a <code>type</code> field.</p> <p>When representing native SSZ transactions on such endpoints, <code>SSZ_TX_TYPE</code> SHOULD be indicated as their <code>type</code>. Omitting the <code>type</code> is NOT RECOMMENDED as certain client applications could confuse the omission with untyped <code>LegacyTransaction</code>.</p> <h3 id="unique-transaction-identifier">Unique transaction identifier</h3> <p>The unique RPC transaction identifier <code>tx_hash</code> for native SSZ transactions is defined to match the <a href="https://wg-eips.ritovision.com/6404/#unique-transaction-identifier">EIP-6404</a> <code>tx_root</code> value.</p> <h2 id="rationale">Rationale</h2> <p>The SSZ signature scheme reduces hashing overhead and ensures that <code>tx_hash</code> commitments are available on-chain. It also provides a flexible basis for future transaction functionality.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The new transaction signature scheme is solely used for native SSZ transactions and is representable using a unique <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> envelope type prefix (<code>SSZ_TX_TYPE</code>) different from existing RLP transactions.</p> <h2 id="security-considerations">Security Considerations</h2> <p>SSZ signatures MUST NOT collide with RLP transaction and message hashes.</p> <p>As RLP messages are hashed using keccak256, and all SSZ objects are hashed using SHA256. These two hashing algorithms are both considered cryptographically secure and are based on fundamentally different approaches, minimizing the risk of hash collision between those two hashing algorithms.</p> <p>Furthermore, RLP messages are hashed linearly across their serialization, while SSZ objects are hashed using a recursive Merkle tree. Having a different mechanism further reduces the risk of hash collisions.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-02-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Zahary Karadjovhttps://github.com/zah https://wg-eips.ritovision.com/6475/

New SSZ type to represent optional values

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/67c2f9ee9eb562f7cc02b2ff90d92c56137944e1/ssz/simple-serialize.md">Simple Serialize (SSZ) type</a> to represent <code>Optional[T]</code> values.</p> <h2 id="motivation">Motivation</h2> <p>Optional values are currently only representable in SSZ using workarounds. Adding proper support provides these benefits:</p> <ol> <li> <p><strong>Better readability:</strong> SSZ structures with optional values can be represented with idiomatic types of the underlying programming language, e.g., <code>Optional[T]</code> in Python, making them easier to interact with.</p> </li> <li> <p><strong>Compact serialization:</strong> SSZ serialization can rely on the binary nature of optional values; they either exist or they don't. This allows more compact serialization than using alternative approaches based on workarounds.</p> </li> </ol> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="type-definition">Type definition</h3> <p><code>Optional[T]</code> is defined as a type that can represent:</p> <ul> <li>A value of SSZ type <code>T</code></li> <li>Absence of a value, indicated by <code>None</code></li> </ul> <h3 id="default-value">Default value</h3> <p>The default value of <code>Optional[T]</code> is <code>None</code>.</p> <h3 id="serialization">Serialization</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> value</span><span class="z-keyword"> is</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\x01</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> +</span><span> serialize</span><span>(</span><span>value</span><span>)</span></span></code></pre><h3 id="deserialization">Deserialization</h3> <p>The deserialization of an <code>Optional[T]</code> depends on the input length:</p> <ul> <li>If the input length is 0, the value is <code>None</code>.</li> <li>Otherwise, the first byte of the deserialization scope must be checked to be <code>0x01</code>, the remainder of the scope is deserialized same as <code>T</code>.</li> </ul> <h3 id="merkleization">Merkleization</h3> <p>An <code>Optional[T]</code> is merkleized as a <code>List[T, 1]</code>.</p> <ul> <li>If the value is <code>None</code>, the list length is <code>0</code>.</li> <li>Otherwise, the list length is <code>1</code>, and the first list element contains the underlying value.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="why-not-union-none-t">Why not <code>Union[None, T]</code>?</h3> <p><code>Union[None, T]</code> leaves ambiguity about the intention whether the type may be extended in the future, i.e., <code>Union[None, T, U]</code>.</p> <p>Furthermore, SSZ Union types are currently not used in any final Ethereum specification and do not have a finalized design themselves. If the only use case is a workaround for lack of <code>Optional[T]</code>, the simpler <code>Optional[T]</code> type is sufficient, and support for general unions could be delayed until really needed. Note that the design of <code>Optional[T]</code> could be used as basis for a more general <code>Union</code>.</p> <h3 id="why-not-list-t-1">Why not <code>List[T, 1]</code>?</h3> <p>The serialization is less compact for variable-length <code>T</code>, due to the extra offset table at the beginning of the list to indicate the list length.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>Union[None, T]</code> and <code>List[T, 1]</code> workarounds are not used at this time to represent <code>Optional[T]</code>.</p> <h2 id="test-cases">Test Cases</h2> <p>See <a href="https://wg-eips.ritovision.com/6475/./assets/tests.py">EIP assets</a>.</p> <h2 id="reference-implementation">Reference Implementation</h2> <ul> <li><strong>Python:</strong> See <a href="https://wg-eips.ritovision.com/6475/./assets/optional.py">EIP assets</a>, based on <code>protolambda/remerkleable</code></li> <li><strong>Nim:</strong> <code>status-im/nim-ssz-serialization</code></li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-02-08T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Mikhail Kalininhttps://github.com/mkalinin https://wg-eips.ritovision.com/6465/

Migration of withdrawals MPT commitment to SSZ

<h2 id="abstract">Abstract</h2> <p>This EIP defines a migration process of the existing Merkle Patricia Trie (MPT) commitment for withdrawals to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md">Simple Serialize (SSZ)</a>.</p> <h2 id="motivation">Motivation</h2> <p>While the consensus <code>ExecutionPayloadHeader</code> and the execution block header map to each other conceptually, they are encoded differently. This EIP aims to align the encoding of the <code>withdrawals_root</code>, taking advantage of the more modern SSZ format. This brings several advantages:</p> <ol> <li> <p><strong>Reducing complexity:</strong> The proposed design reduces the number of use cases that require support for Merkle Patricia Trie (MPT).</p> </li> <li> <p><strong>Reducing ambiguity:</strong> The name <code>withdrawals_root</code> is currently used to refer to different roots. While the execution block header refers to a Merkle Patricia Trie (MPT) root, the consensus <code>ExecutionPayloadHeader</code> instead refers to an SSZ root. With these changes, <code>withdrawals_root</code> consistently refers to the same SSZ root.</p> </li> </ol> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="existing-definitions">Existing definitions</h3> <p>Definitions from existing specifications that are used throughout this document are replicated here for reference.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th></tr></thead><tbody> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>ValidatorIndex</code></a></td><td><code>uint64</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Gwei</code></a></td><td><code>uint64</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#custom-types"><code>ExecutionAddress</code></a></td><td><code>Bytes20</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#custom-types"><code>WithdrawalIndex</code></a></td><td><code>uint64</code></td></tr> </tbody></table> <h3 id="withdrawals">Withdrawals</h3> <p>New withdrawals use a normalized SSZ representation. The existing consensus <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#withdrawal"><code>Withdrawal</code></a> SSZ container is migrated to <a href="https://wg-eips.ritovision.com/7495/">EIP-7495 <code>ProgressiveContainer</code></a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Withdrawal</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> index</span><span>:</span><span> WithdrawalIndex</span></span> <span class="giallo-l"><span> validator_index</span><span>:</span><span> ValidatorIndex</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span> Gwei</span></span></code></pre><h3 id="execution-block-header-changes">Execution block header changes</h3> <p>The <a rel="external" href="https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/caps/eth.md#block-encoding-and-validity">execution block header's <code>withdrawals-root</code></a> is transitioned from MPT to SSZ.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>withdrawals</span><span class="z-keyword"> =</span><span> ProgressiveList</span><span>[</span><span>Withdrawal</span><span>]</span><span>(</span></span> <span class="giallo-l"><span> withdrawal_0</span><span>,</span><span> withdrawal_1</span><span>,</span><span> withdrawal_2</span><span>,</span><span class="z-constant"> ...</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>block_header</span><span>.</span><span>withdrawals_root</span><span class="z-keyword"> =</span><span> withdrawals</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span></span></code></pre><h3 id="consensus-executionpayload-changes">Consensus <code>ExecutionPayload</code> changes</h3> <p>When building a consensus <code>ExecutionPayload</code>, the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/beacon-chain.md#executionpayload"><code>withdrawals</code></a> list is based on the new progressive container type.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayload</span><span>(</span><span class="z-constant">...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> withdrawals</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Withdrawal</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre> <p>The state transition function is updated to limit withdrawals to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/capella/beacon-chain.md#execution"><code>MAX_WITHDRAWALS_PER_PAYLOAD</code></a>.</p> <h2 id="rationale">Rationale</h2> <p>This change was originally a candidate for inclusion in Shanghai, but was postponed to accelerate the rollout of withdrawals.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Applications that rely on the replaced MPT <code>withdrawals_root</code> in the block header require migration to the SSZ <code>withdrawals_root</code>.</p> <p>RLP and SSZ withdrawals may clash when encoded. It is essential to use only a single format within one channel. The block header corresponding to the withdrawals can be consulted to identify the underlying fork.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-02-08T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/6466/

Migration of RLP receipts to SSZ

<h2 id="abstract">Abstract</h2> <p>This EIP defines a migration process of <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> Recursive-Length Prefix (RLP) receipts to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/ssz/simple-serialize.md">Simple Serialize (SSZ)</a></p> <h2 id="motivation">Motivation</h2> <p>RLP receipts have a number of shortcomings:</p> <ol> <li> <p><strong>Limited proving support:</strong> Due to receipt data being linearly hashed as part of the <code>receipts_root</code> Merkle-Patricia Trie (MPT), it is not possible to efficiently proof individual parts of receipts, such as logs. Requiring the full receipt data to be present can be prohibitive for smart contract based applications such as L2 fraud proofs or client applications verifying log data.</p> </li> <li> <p><strong>Incomplete data:</strong> JSON-RPC provides <code>from</code>, <code>gasUsed</code>, and <code>contractAddress</code> fields for receipts, but the on-chain receipt does not contain the required information to verify them.</p> </li> </ol> <p>This EIP defines a universal receipt format based on SSZ to address these concerns.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="existing-definitions">Existing definitions</h3> <p>Definitions from existing specifications that are used throughout this document are replicated here for reference.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th></tr></thead><tbody> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#custom-types"><code>Root</code></a></td><td><code>Bytes32</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/bellatrix/beacon-chain.md#custom-types"><code>ExecutionAddress</code></a></td><td><code>Bytes20</code></td></tr> <tr><td><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>GasAmount</code></a></td><td><code>uint64</code></td></tr> </tbody></table> <h3 id="logs">Logs</h3> <p>Logs are represented as an SSZ <code>Container</code>.</p> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>MAX_TOPICS_PER_LOG</code></td><td><code>4</code></td><td><code>LOG0</code> through <code>LOG4</code> opcodes allow 0-4 topics per log</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Log</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> topics</span><span>:</span><span> List</span><span>[</span><span>Bytes32</span><span>,</span><span class="z-constant"> MAX_TOPICS_PER_LOG</span><span>]</span></span> <span class="giallo-l"><span> data</span><span>:</span><span> ProgressiveByteList</span></span></code></pre><h3 id="receipts">Receipts</h3> <p>New receipts use a normalized SSZ representation.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Receipt</span><span>(</span><span class="z-entity">CompatibleUnion</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span><span>:</span><span> BasicReceipt</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span><span>:</span><span> CreateReceipt</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">03</span><span>:</span><span> SetCodeReceipt</span><span>,</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span></code></pre><h4 id="basic-receipts">Basic receipts</h4> <p>This receipt is emitted for these transactions:</p> <ul> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpLegacyReplayableBasicTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpLegacyBasicTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpAccessListBasicTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpBasicTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpBlobTransaction</code></a></li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BasicReceipt</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> from_</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> logs</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Log</span><span>]</span></span> <span class="giallo-l"><span> status</span><span>:</span><span> boolean</span></span></code></pre><h4 id="create-receipts">Create receipts</h4> <p>This receipt is emitted for these transactions:</p> <ul> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpLegacyReplayableCreateTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpLegacyCreateTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpAccessListCreateTransaction</code></a></li> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpCreateTransaction</code></a></li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> CreateReceipt</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> from_</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> contract_address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> logs</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Log</span><span>]</span></span> <span class="giallo-l"><span> status</span><span>:</span><span> boolean</span></span></code></pre><h4 id="eip-7702-set-code-receipts">EIP-7702 set code receipts</h4> <p>This receipt is emitted for these transactions:</p> <ul> <li><a href="https://wg-eips.ritovision.com/6404/#normalized-transactions"><code>RlpSetCodeTransaction</code></a></li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> SetCodeReceipt</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> from_</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> logs</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Log</span><span>]</span></span> <span class="giallo-l"><span> status</span><span>:</span><span> boolean</span></span> <span class="giallo-l"><span> authorities</span><span>:</span><span> ProgressiveList</span><span>[</span><span>ExecutionAddress</span><span>]</span></span></code></pre><h3 id="receipt-construction"><code>Receipt</code> construction</h3> <p>Receipts are constructed as follows.</p> <table><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody> <tr><td><code>from</code></td><td>The transaction sender's address</td></tr> <tr><td><code>gas_used</code></td><td>How much gas this individual transaction used</td></tr> <tr><td><code>contract_address</code></td><td>For transactions deploying a contract, the new contract address. Present only in <code>CreateReceipt</code></td></tr> <tr><td><code>logs</code></td><td>Logs emitted during transaction execution</td></tr> <tr><td><code>status</code></td><td><a href="https://wg-eips.ritovision.com/658/">EIP-658</a> transaction status code</td></tr> <tr><td><code>authorities</code></td><td>For transactions with an authorization list, the list of <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> <code>authority</code> addresses. Non-successful authorizations are represented with an all-zero address</td></tr> </tbody></table> <p>The <code>logs_bloom</code>, intermediate state <code>root</code> (Homestead scheme), and <code>cumulative_gas_used</code> (pre <a href="https://wg-eips.ritovision.com/8116/">EIP-8116</a>) fields are not present in SSZ receipts.</p> <h3 id="execution-block-header-changes">Execution block header changes</h3> <p>The <a rel="external" href="https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/caps/eth.md#block-encoding-and-validity">execution block header's <code>receipts-root</code></a> is transitioned from MPT to SSZ.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>receipts</span><span class="z-keyword"> =</span><span> ProgressiveList</span><span>[</span><span>Receipt</span><span>]</span><span>(</span></span> <span class="giallo-l"><span> receipt_0</span><span>,</span><span> receipt_1</span><span>,</span><span> receipt_2</span><span>,</span><span class="z-constant"> ...</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>block_header</span><span>.</span><span>receipts_root</span><span class="z-keyword"> =</span><span> receipts</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span></span></code></pre><h3 id="json-rpc-api">JSON-RPC API</h3> <p>Transaction receipt objects in the context of the JSON-RPC API are extended to include:</p> <ul> <li><code>authorities</code>: <code>Array of DATA|null</code> - Array of <code>DATA</code> entries each containing 20 Bytes, corresponding to the receipt's <code>authorities</code> field</li> </ul> <p>The <code>logsBloom</code> field is no longer returned for new receipts. It continues to be returned for historical receipts conforming to earlier schemes.</p> <p><code>from</code>, <code>gasUsed</code>, and <code>contractAddress</code> are already provided via JSON-RPC and are left unchanged. For <code>BasicReceipt</code> and <code>SetCodeReceipt</code>, <code>contractAddress</code> will be <code>null</code> as these receipt types do not contain the <code>contract_address</code> field. <code>logIndex</code> indicates the log index position in the individual receipt (rather than the entire block), as defined in <a href="https://wg-eips.ritovision.com/8116/">EIP-8116</a>.</p> <h3 id="consensus-executionpayload-changes">Consensus <code>ExecutionPayload</code> changes</h3> <p>When building a consensus <code>ExecutionPayload</code>, the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/deneb/beacon-chain.md#executionpayload"><code>receipts_root</code></a> is now based on the <code>Receipt</code> type, changing the type of <code>receipts_root</code> from an MPT <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#custom-types"><code>Hash32</code></a> to an SSZ <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b3e83f6691c61e5b35136000146015653b22ed38/specs/phase0/beacon-chain.md#custom-types"><code>Root</code></a>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayload</span><span>(</span><span class="z-constant">...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> receipts_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayloadHeader</span><span>(</span><span class="z-constant">...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> receipts_root</span><span>:</span><span> Root</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>payload_header</span><span>.</span><span>receipts_root</span><span class="z-keyword"> =</span><span> payload</span><span>.</span><span>receipts_root</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="forward-compatibility">Forward compatibility</h3> <p>All receipts share the same Merkle tree shape with a stable <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/merkle-proofs.md#generalized-merkle-tree-index">generalized index (gindex)</a> assigned to each field. Future transaction features can introduce additional receipt fields or drop existing fields without breaking verifiers.</p> <h3 id="verifier-improvements">Verifier improvements</h3> <p>Committing to <code>from</code>, <code>contract_address</code> and <code>authorities</code> in the receipt allows efficient verification without the expensive <code>ecrecover</code> mechanism. This allows future EIPs to change how these addresses are computed without breaking verifiers, e.g., when future signature schemes are introduced.</p> <h3 id="execution-client-improvements">Execution client improvements</h3> <p>Execution Layer implementations no longer need access to the transaction and additional indices when serving receipts based on SSZ.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Applications that rely on the replaced MPT <code>receipts_root</code> in the block header require migration to the SSZ <code>receipts_root</code>.</p> <p>RLP and SSZ receipts may clash when encoded. It is essential to use only a single format within one channel. When requesting receipts by hash over the network, the block header corresponding to the containing receipts root can be consulted to identify the underlying fork.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2023-01-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Etan Kisslinghttps://github.com/etan-status Gajinder Singhhttps://github.com/g11tech Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/6404/

Migration of RLP transactions to SSZ

<h2 id="abstract">Abstract</h2> <p>This EIP defines a migration process of <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> Recursive-Length Prefix (RLP) transactions to <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/ssz/simple-serialize.md">Simple Serialize (SSZ)</a>.</p> <h2 id="motivation">Motivation</h2> <p>RLP transactions have a number of shortcomings:</p> <ol> <li> <p><strong>Linear hashing:</strong> The signing hash (<code>sig_hash</code>) and unique identifier (<code>tx_hash</code>) of an RLP transaction are computed by linear keccak256 hashes across its serialization. Even if only partial data is of interest, linear hashes require the full transaction data to be present, including potentially large calldata or access lists. This also applies when computing the <code>from</code> address of a transaction based on the <code>sig_hash</code>.</p> </li> <li> <p><strong>Inefficient inclusion proofs:</strong> The Merkle-Patricia Trie (MPT) backing the execution block header's <code>transactions_root</code> is constructed from the serialized transactions, internally prepending a prefix to the transaction data before it is keccak256 hashed into the MPT. Due to this prefix, there is no on-chain commitment to the <code>tx_hash</code> and inclusion proofs require the full transaction data to be present.</p> </li> <li> <p><strong>Incompatible representation:</strong> As part of the consensus <code>ExecutionPayload</code>, the RLP serialization of transactions is hashed using SSZ merkleization. These SSZ hashes are incompatible with both the <code>tx_hash</code> and the MPT <code>transactions_root</code>.</p> </li> <li> <p><strong>Technical debt:</strong> All client applications and smart contracts handling RLP transactions have to correctly deal with caveats such as <code>LegacyTransaction</code> lacking a prefix byte, the inconsistent <code>chain_id</code> and <code>v</code> / <code>y_parity</code> semantics, and the introduction of <code>max_priority_fee_per_gas</code> between other fields instead of at the end. As existing transaction types tend to remain valid perpetually, this technical debt builds up over time.</p> </li> <li> <p><strong>Inappropriate opaqueness:</strong> The Consensus Layer treats RLP transaction data as opaque, but requires validation of consensus <code>blob_kzg_commitments</code> against transaction <code>blob_versioned_hashes</code>, resulting in a more complex than necessary engine API.</p> </li> </ol> <p>This EIP addresses these by defining a lossless conversion mechanism to normalize transaction representation across both Consensus Layer and Execution Layer while retaining support for processing RLP transaction types.</p> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <h3 id="existing-definitions">Existing definitions</h3> <p>Definitions from existing specifications that are used throughout this document are replicated here for reference.</p> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/polynomial-commitments.md#constants"><code>BYTES_PER_FIELD_ELEMENT</code></a></td><td><code>uint64(32)</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/polynomial-commitments.md#blob"><code>FIELD_ELEMENTS_PER_BLOB</code></a></td><td><code>uint64(4096)</code></td></tr> </tbody></table> <table><thead><tr><th>Name</th><th>SSZ equivalent</th></tr></thead><tbody> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/phase0/beacon-chain.md#custom-types"><code>Hash32</code></a></td><td><code>Bytes32</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/bellatrix/beacon-chain.md#custom-types"><code>ExecutionAddress</code></a></td><td><code>Bytes20</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/beacon-chain.md#custom-types"><code>VersionedHash</code></a></td><td><code>Bytes32</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/polynomial-commitments.md#custom-types"><code>KZGCommitment</code></a></td><td><code>Bytes48</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/polynomial-commitments.md#custom-types"><code>KZGProof</code></a></td><td><code>Bytes48</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/polynomial-commitments.md#custom-types"><code>Blob</code></a></td><td><code>ByteVector[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB]</code></td></tr> </tbody></table> <h3 id="signatures">Signatures</h3> <p>Transaction signatures are represented by their native, opaque representation, prefixed by a value indicating their algorithm.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th></tr></thead><tbody> <tr><td><code>ExecutionSignature</code></td><td><code>ProgressiveByteList</code></td></tr> <tr><td><code>ExecutionSignatureAlgorithm</code></td><td><code>uint8</code></td></tr> </tbody></table> <h4 id="secp256k1">Secp256k1</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>SECP256K1_ALGORITHM</code></td><td><code>uint8(0xFF)</code></td><td>Defined from <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a></td></tr> </tbody></table> <h4 id="verification">Verification</h4> <p>The following functions are imported from <a href="https://wg-eips.ritovision.com/7932/">EIP-7932</a>:</p> <ul> <li><code>calculate_penalty</code></li> <li><code>validate_signature</code></li> <li><code>verify_signature</code></li> <li><code>pubkey_to_address</code></li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_signature_gas_cost</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span> ExecutionSignature</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> sig_hash</span><span>:</span><span> Hash32</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> expected_algorithm</span><span>:</span><span> Optional</span><span>[</span><span>ExecutionSignatureAlgorithm</span><span>]</span><span class="z-keyword">=</span><span class="z-constant">None</span></span> <span class="giallo-l"><span>)</span><span> -&gt;</span><span> uint</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> expected_algorithm</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> ==</span><span> expected_algorithm</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> calculate_penalty</span><span>(</span><span>signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> sig_hash</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_execution_signature</span><span>(</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> signature</span><span>:</span><span> ExecutionSignature</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-parameter z-function"> expected_algorithm</span><span>:</span><span> Optional</span><span>[</span><span>ExecutionSignatureAlgorithm</span><span>]</span><span class="z-keyword">=</span><span class="z-constant">None</span><span>,</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>signature</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> expected_algorithm</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> ==</span><span> expected_algorithm</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> validate_signature</span><span>(</span><span>signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> recover_execution_signer</span><span>(</span><span class="z-variable z-parameter z-function">signature</span><span>:</span><span> ExecutionSignature</span><span>,</span><span class="z-variable z-parameter z-function"> sig_hash</span><span>:</span><span> Hash32</span><span>)</span><span> -&gt;</span><span> ExecutionAddress</span><span>:</span></span> <span class="giallo-l"><span> public_key</span><span class="z-keyword"> =</span><span> verify_signature</span><span>(</span><span>sig_hash</span><span>,</span><span> signature</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> pubkey_to_address</span><span>(</span><span>public_key</span><span>,</span><span> signature</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span></span></code></pre><h3 id="gas-fees">Gas fees</h3> <p>The different kinds of gas fees are combined into a single structure.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th><th>Description</th></tr></thead><tbody> <tr><td><code>FeePerGas</code></td><td><code>uint256</code></td><td>Fee per unit of gas</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BasicFeesPerGas</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> regular</span><span>:</span><span> FeePerGas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> BlobFeesPerGas</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> regular</span><span>:</span><span> FeePerGas</span></span> <span class="giallo-l"><span> blob</span><span>:</span><span> FeePerGas</span></span></code></pre><h3 id="normalized-transactions">Normalized transactions</h3> <p>RLP transactions are converted to a normalized SSZ representation. Their original RLP <code>TransactionType</code> is retained to enable recovery of their original RLP representation and associated <code>sig_hash</code> and historical <code>tx_hash</code> values.</p> <table><thead><tr><th>Name</th><th>SSZ equivalent</th><th>Description</th></tr></thead><tbody> <tr><td><code>TransactionType</code></td><td><code>uint8</code></td><td><a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type, range <code>[0x00, 0x7F]</code></td></tr> <tr><td><code>ChainId</code></td><td><code>uint256</code></td><td><a href="https://wg-eips.ritovision.com/155/">EIP-155</a> chain ID</td></tr> <tr><td><code>GasAmount</code></td><td><code>uint64</code></td><td>Amount in units of gas</td></tr> </tbody></table> <h4 id="replayable-legacy-transactions">Replayable legacy transactions</h4> <p>The original RLP representation of these transactions is replayable across networks with different chain ID.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpLegacyReplayableBasicTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x00</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpLegacyReplayableCreateTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x00</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span></code></pre><h4 id="eip-155-legacy-transactions">EIP-155 legacy transactions</h4> <p>These transactions are locked to a single <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> chain ID.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpLegacyBasicTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x00</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpLegacyCreateTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x00</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span></code></pre><h4 id="legacy-transactions">Legacy transactions</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>RlpLegacyTransactionPayload</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> RlpLegacyReplayableBasicTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> RlpLegacyReplayableCreateTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> RlpLegacyBasicTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> RlpLegacyCreateTransactionPayload</span></span> <span class="giallo-l"><span>)</span></span></code></pre><h4 id="eip-2930-access-list-transactions">EIP-2930 access list transactions</h4> <p>These transactions support specifying an <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> access list.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> AccessTuple</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> storage_keys</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Hash32</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpAccessListBasicTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x01</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpAccessListCreateTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x01</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>RlpAccessListTransactionPayload</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> RlpAccessListBasicTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> RlpAccessListCreateTransactionPayload</span></span> <span class="giallo-l"><span>)</span></span></code></pre><h4 id="eip-1559-fee-market-transactions">EIP-1559 fee market transactions</h4> <p>These transactions support specifying <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> priority fees.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpBasicTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x02</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpCreateTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x02</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>RlpFeeMarketTransactionPayload</span><span class="z-keyword"> =</span><span> (</span></span> <span class="giallo-l"><span> RlpBasicTransactionPayload</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span> RlpCreateTransactionPayload</span></span> <span class="giallo-l"><span>)</span></span></code></pre><h4 id="eip-4844-blob-transactions">EIP-4844 blob transactions</h4> <p>These transactions support specifying <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a> blobs.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpBlobTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x03</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BlobFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> blob_versioned_hashes</span><span>:</span><span> ProgressiveList</span><span>[</span><span>VersionedHash</span><span>]</span></span></code></pre><h4 id="eip-7702-set-code-transactions">EIP-7702 set code transactions</h4> <p>These transactions support specifying an <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> authorization list.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpReplayableBasicAuthorizationPayload</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> magic</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x05</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpBasicAuthorizationPayload</span><span>(</span><span class="z-entity">ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> magic</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x05</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> address</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpSetCodeAuthorizationPayload</span><span>(</span><span class="z-entity">CompatibleUnion</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span><span>:</span><span> RlpReplayableBasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span><span>:</span><span> RlpBasicAuthorizationPayload</span><span>,</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpSetCodeAuthorization</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> RlpSetCodeAuthorizationPayload</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> ExecutionSignature</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpSetCodeTransactionPayload</span><span>(</span></span> <span class="giallo-l"><span class="z-entity"> ProgressiveContainer</span><span>(</span><span class="z-variable">active_fields</span><span class="z-keyword">=</span><span>[</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>)</span><span>:</span></span> <span class="giallo-l"><span> type_</span><span>:</span><span> TransactionType</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 0x04</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span> ChainId</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span> uint64</span></span> <span class="giallo-l"><span> max_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> gas</span><span>:</span><span> GasAmount</span></span> <span class="giallo-l"><span> to</span><span>:</span><span> ExecutionAddress</span></span> <span class="giallo-l"><span> value</span><span>:</span><span> uint256</span></span> <span class="giallo-l"><span> input_</span><span>:</span><span> ProgressiveByteList</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>AccessTuple</span><span>]</span></span> <span class="giallo-l"><span> max_priority_fees_per_gas</span><span>:</span><span> BasicFeesPerGas</span></span> <span class="giallo-l"><span> authorization_list</span><span>:</span><span> ProgressiveList</span><span>[</span><span>RlpSetCodeAuthorization</span><span>]</span></span></code></pre><h4 id="transaction-helpers">Transaction helpers</h4> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> TransactionPayload</span><span>(</span><span class="z-entity">CompatibleUnion</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span><span>:</span><span> RlpLegacyReplayableBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span><span>:</span><span> RlpLegacyReplayableCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">03</span><span>:</span><span> RlpLegacyBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">04</span><span>:</span><span> RlpLegacyCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">05</span><span>:</span><span> RlpAccessListBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">06</span><span>:</span><span> RlpAccessListCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">07</span><span>:</span><span> RlpBasicTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">08</span><span>:</span><span> RlpCreateTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">09</span><span>:</span><span> RlpBlobTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">0a</span><span>:</span><span> RlpSetCodeTransactionPayload</span><span>,</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Transaction</span><span>(</span><span class="z-entity">Container</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> TransactionPayload</span></span> <span class="giallo-l"><span> signature</span><span>:</span><span> ExecutionSignature</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> RlpTxType</span><span>(</span><span class="z-entity">IntEnum</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> LEGACY</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">00</span></span> <span class="giallo-l"><span class="z-constant"> ACCESS_LIST</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">01</span></span> <span class="giallo-l"><span class="z-constant"> FEE_MARKET</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">02</span></span> <span class="giallo-l"><span class="z-constant"> BLOB</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">03</span></span> <span class="giallo-l"><span class="z-constant"> SET_CODE</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">04</span></span> <span class="giallo-l"><span class="z-constant"> SET_CODE_MAGIC</span><span class="z-keyword"> =</span><span class="z-storage z-type"> 0x</span><span class="z-constant">05</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calculate_transaction_intrinsic_gas</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> uint</span><span>:</span></span> <span class="giallo-l"><span> tx_data</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>payload</span><span>.</span><span>data</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-keyword"> FIXME</span><span class="z-comment">: Should this be defined from another EIP?</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> hasattr</span><span>(</span><span>tx_data</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">authorization_list</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> auth</span><span class="z-keyword"> in</span><span> tx_data</span><span>.</span><span>authorization_list</span><span>:</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span> get_signature_gas_cost</span><span>(</span><span>auth</span><span>.</span><span>signature</span><span>,</span><span class="z-variable"> expected_algorithm</span><span class="z-keyword">=</span><span>expected_signature_algorithm</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span> get_signature_gas_cost</span><span>(</span><span>tx</span><span>.</span><span>signature</span><span>,</span><span class="z-variable"> expected_algorithm</span><span class="z-keyword">=</span><span>expected_signature_algorithm</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> gas_cost</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_transaction</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> tx_data</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>payload</span><span>.</span><span>data</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> expected_signature_algorithm</span><span class="z-keyword"> =</span><span class="z-constant"> None</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> hasattr</span><span>(</span><span>tx_data</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">type_</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> expected_signature_algorithm</span><span class="z-keyword"> =</span><span class="z-constant"> SECP256K1_ALGORITHM</span></span> <span class="giallo-l"><span class="z-keyword"> match</span><span> tx_data</span><span>.</span><span>type_</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> RlpTxType</span><span>.</span><span class="z-constant">LEGACY</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>tx_data</span><span>,</span><span> RlpLegacyTransactionPayload</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> RlpTxType</span><span>.</span><span class="z-constant">ACCESS_LIST</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>tx_data</span><span>,</span><span> RlpAccessListTransactionPayload</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> RlpTxType</span><span>.</span><span class="z-constant">FEE_MARKET</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>tx_data</span><span>,</span><span> RlpFeeMarketTransactionPayload</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> RlpTxType</span><span>.</span><span class="z-constant">BLOB</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>tx_data</span><span>,</span><span> RlpBlobTransactionPayload</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> RlpTxType</span><span>.</span><span class="z-constant">SET_CODE</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>tx_data</span><span>,</span><span> RlpSetCodeTransactionPayload</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span> _</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> hasattr</span><span>(</span><span>tx_data</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">authorization_list</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> auth</span><span class="z-keyword"> in</span><span> tx_data</span><span>.</span><span>authorization_list</span><span>:</span></span> <span class="giallo-l"><span> auth_data</span><span class="z-keyword"> =</span><span> auth</span><span>.</span><span>payload</span><span>.</span><span>data</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> hasattr</span><span>(</span><span>auth_data</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">magic</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> auth_data</span><span>.</span><span>magic</span><span class="z-keyword"> ==</span><span> RlpTxType</span><span>.</span><span class="z-constant">SET_CODE_MAGIC</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> hasattr</span><span>(</span><span>auth_data</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">chain_id</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> auth_data</span><span>.</span><span>chain_id</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> validate_execution_signature</span><span>(</span><span>auth</span><span>.</span><span>signature</span><span>,</span><span> compute_auth_hash</span><span>(</span><span>auth</span><span>)</span><span>,</span><span class="z-variable"> expected_algorithm</span><span class="z-keyword">=</span><span>expected_signature_algorithm</span><span>)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> validate_execution_signature</span><span>(</span><span>tx</span><span>.</span><span>signature</span><span>,</span><span> compute_sig_hash</span><span>(</span><span>tx</span><span>)</span><span>,</span><span class="z-variable"> expected_algorithm</span><span class="z-keyword">=</span><span>expected_signature_algorithm</span><span>)</span></span> <span class="giallo-l"></span></code></pre><h3 id="execution-block-header-changes">Execution block header changes</h3> <p>The <a rel="external" href="https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/caps/eth.md#block-encoding-and-validity">execution block header's <code>txs-root</code></a> is transitioned from MPT to SSZ.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>transactions</span><span class="z-keyword"> =</span><span> ProgressiveList</span><span>[</span><span>Transaction</span><span>]</span><span>(</span></span> <span class="giallo-l"><span> tx_0</span><span>,</span><span> tx_1</span><span>,</span><span> tx_2</span><span>,</span><span class="z-constant"> ...</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>block_header</span><span>.</span><span>transactions_root</span><span class="z-keyword"> =</span><span> transactions</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span></span></code></pre><h3 id="engine-api">Engine API</h3> <p>In the engine API, the semantics of the <code>transactions</code> field in <code>ExecutionPayload</code> versions adopting this EIP are changed to emit transactions using SSZ serialization.</p> <ul> <li><code>transactions</code> - <code>Array</code> of <code>DATA</code> - Array of transaction objects, each object is a byte list (<code>DATA</code>) representing <code>ssz.serialize(tx)</code></li> </ul> <h3 id="consensus-executionpayload-changes">Consensus <code>ExecutionPayload</code> changes</h3> <p>When building a consensus <code>ExecutionPayload</code>, the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/b5c3b619887c7850a8c1d3540b471092be73ad84/specs/deneb/beacon-chain.md#executionpayload"><code>transactions</code></a> list is no longer opaque and uses the new <code>Transaction</code> type, aligning the <code>transactions_root</code> across execution blocks and execution payloads.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> ExecutionPayload</span><span>(</span><span class="z-constant">...</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"><span> transactions</span><span>:</span><span> ProgressiveList</span><span>[</span><span>Transaction</span><span>]</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h3 id="unique-transaction-identifier">Unique transaction identifier</h3> <p>For each transaction, an additional identifier <code>tx_root</code> SHALL be assigned:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_tx_root</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span> Hash32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Hash32</span><span>(</span><span>tx</span><span>.</span><span>hash_tree_root</span><span>(</span><span>)</span><span>)</span></span></code></pre> <p>Note that this <code>tx_root</code> differs from the existing <code>tx_hash</code>. Existing APIs based on <code>tx_hash</code> remain available.</p> <h2 id="rationale">Rationale</h2> <h3 id="forward-compatibility">Forward compatibility</h3> <p>The proposed transaction design is extensible with new fee types, new signature types, and entirely new transaction features (e.g., CREATE2), while retaining compatibility with the proposed transactions.</p> <h3 id="verifier-improvements">Verifier improvements</h3> <p>The <code>transactions_root</code> is effectively constructed from the list of <code>tx_root</code>, enabling transaction inclusion proofs. Further, partial data becomes provable, such as destination / amount without requiring the full calldata. This can reduce gas cost or zk proving cost when verifying L2 chain data in an L1 smart contract.</p> <h3 id="consensus-client-improvements">Consensus client improvements</h3> <p>Consensus Layer implementations may drop invalid blocks early if consensus <code>blob_kzg_commitments</code> do not validate against transaction <code>blob_versioned_hashes</code> and no longer need to query the Execution Layer for that validation. Future versions of the engine API could be simplified to drop the transfers of <code>blob_kzg_commitments</code> to the EL.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Applications that rely on the replaced MPT <code>transactions_root</code> in the block header require migration to the SSZ <code>transactions_root</code>.</p> <p>While there is no on-chain commitment of the <code>tx_hash</code>, it is widely used in JSON-RPC and the <a rel="external" href="https://github.com/ethereum/devp2p/blob/bc76b9809a30e6dc5c8dcda996273f0f9bcf7108/caps/eth.md">Ethereum Wire Protocol</a> to uniquely identify transactions. The conversion from RLP transactions to SSZ is lossless. The original RLP <code>sig_hash</code> and <code>tx_hash</code> can be recovered from the SSZ representation.</p> <p>RLP and SSZ transactions may clash when encoded. It is essential to use only a single format within one channel.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-12-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Andrei Maiborodahttps://github.com/gumb0 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Matt Garnetthttps://github.com/lightclient https://wg-eips.ritovision.com/6206/

Introduces instruction for chaining function calls.

<h2 id="abstract">Abstract</h2> <p>This EIP allows for tail call optimizations in EOF functions (<a href="https://wg-eips.ritovision.com/4750/">EIP-4750</a>) by introducing a new instruction <code>JUMPF</code>, which jumps to a code section without adding a new return stack frame.</p> <p>Additionally the format of the type sections is extended to allow declaring sections as non-returning, with simplified stack validation for <code>JUMPF</code> to such section.</p> <h2 id="motivation">Motivation</h2> <p>It is common for functions to make a call at the end of the routine only to then return. <code>JUMPF</code> optimizes this behavior by changing code sections without needing to update the return stack.</p> <p>Knowing at validation time that a function will never return control allows for <code>JUMPF</code> to such function to be treated similar to terminating instructions, where extra items may be left on the operand stack at execution termination. This provides opportunities for compilers to generate more optimal code, both in code size and in spent gas. It is particularly beneficial for small error handling helpers, that end execution with <code>REVERT</code>: they are commonly reused in multiple branches and extracting them into a helper function is efficient, when there is no need to pop extra stack items before <code>JUMPF</code> to such helper.</p> <h2 id="specification">Specification</h2> <h3 id="type-section-changes">Type section changes</h3> <p>We define a non-returning section as one that cannot return control to its caller section.</p> <p>Type section <code>outputs</code> field contains a special value <code>0x80</code> when corresponding code section is non-returning. See <a href="https://wg-eips.ritovision.com/6206/#non-returning-status-validation">Non-returning status validation</a> below for validation details.</p> <p>The first code section MUST have 0 inputs and be non-returning.</p> <h3 id="execution-semantics">Execution Semantics</h3> <p>A new instruction, <code>JUMPF (0xe5)</code>, is introduced.</p> <ol> <li><code>JUMPF</code> has one immediate argument, <code>target_section_index</code>, encoded as a 16-bit unsigned big-endian value.</li> <li>If the operand stack size exceeds <code>1024 - type[target_section_index].max_stack_increase</code> (i.e. if the called function may exceed the global stack height limit), execution results in an exceptional halt. This guarantees that the target function does not exceed global stack height limit.</li> <li><code>JUMPF</code> sets <code>current_section_index</code> to <code>target_section_index</code> and <code>PC</code> to <code>0</code>, but does not change the return stack. Execution continues in the target section.</li> <li><code>JUMPF</code> costs 5 gas.</li> <li><code>JUMPF</code> neither pops nor pushes anything to the operand stack.</li> </ol> <p>If the code is legacy bytecode, <code>JUMPF</code> instruction results in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <h3 id="code-validation">Code Validation</h3> <p>Let the definition of <code>type[i]</code> be inherited from <a href="https://wg-eips.ritovision.com/4750/">EIP-4750</a> and define <code>stack_height_min</code> and <code>stack_height_max</code> to be the stack height bounds at a certain instruction during the instruction flow traversal.</p> <ul> <li>The immediate argument of <code>JUMPF</code> MUST be less than the total number of code sections.</li> <li>For each <code>JUMPF</code> instruction: <ul> <li>either <code>type[current_section_index].outputs</code> MUST be greater or equal <code>type[target_section_index].outputs</code>,</li> <li>or <code>type[target_section_index].outputs</code> MUST be <code>0x80</code></li> </ul> </li> <li>The stack height validation at <code>JUMPF</code> depends on whether the target section is non-returning: <ul> <li><code>JUMPF</code> into returning section (<code>type[target_section_index].outputs</code> does not equal <code>0x80</code>): <code>stack_height_min</code> and <code>stack_height_max</code> MUST be equal to <code>type[current_section_index].outputs - type[target_section_index].outputs + type[target_section_index].inputs</code>. This means that target section can output less stack elements than the original code section called by the top element on the return stack, if the current code section leaves the delta <code>type[current_section_index].outputs - type[target_section_index].outputs</code> element(s) on the stack.</li> <li><code>JUMPF</code> into non-returning section (<code>type[target_section_index].outputs</code> equals <code>0x80</code>): <code>stack_height_min</code> MUST be greater than or equal to <code>type[target_section_index].inputs</code>.</li> </ul> </li> <li>Stack overflow check at <code>JUMPF</code>: <code>stack_height_max</code> MUST be less than or equal to <code>1024 - types[target_section_index].max_stack_increase</code>.</li> <li><code>JUMPF</code> is considered terminating instruction, i.e. does not have successor instructions in code validation and MAY be final instruction in the section.</li> <li>The code validation defined in <a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a> also fails if any <code>RJUMP*</code> offset points to one of the two bytes directly following a <code>JUMPF</code> instruction.</li> </ul> <p><code>CALLF</code> instruction validation is extended to include the rule:</p> <ul> <li>Code section is invalid in case an immediate argument <code>target_section_index</code> of any <code>CALLF</code> targets a non-returning section, i.e. <code>type[target_section_index].outputs</code> equals <code>0x80</code>.</li> </ul> <h4 id="non-returning-status-validation">Non-returning status validation</h4> <p>Section type MUST be non-returning if and only if the section contains no <code>RETF</code> instructions and no <code>JUMPF</code> instructions targeting returning sections (target section's status is checked via its output value in type section.) <em>Note: This implies that section containing only <code>JUMPF</code>s into non-returning sections is non-returning itself.</em></p> <h2 id="rationale">Rationale</h2> <h3 id="allowing-jumpf-to-section-with-less-outputs">Allowing <code>JUMPF</code> to section with less outputs</h3> <p>An alternative rule for <code>JUMPF</code> stack validation could require the target section's outputs to be exactly equal to the current section's outputs. Under such rule, a particular target section (a shared "helper" piece of code) would only "match" sections (requiring some shared "helper" code to execute before returning) <em>with the same number of outputs</em>.</p> <p>Instead, we allow a given <code>JUMPF</code> target section to be called from sections with more outputs, as long as these sections provide these extra stack elements (the "delta") themselves. This will reduce duplicated code as it will allow compilers more flexibility during code generation such that certain helpers can be used generically by functions, regardless of their output values.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is backward compatible as EOF does not allow undefined instructions to be used or deployed, meaning no contracts will be affected.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This new instruction needs to be carefully considered during implementation of the EOF container validation algorithm.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-12-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gavin Johnhttps://github.com/Pandapip1 https://wg-eips.ritovision.com/6188/

Caps the nonce at 2^64-2

<h2 id="abstract">Abstract</h2> <p>This EIP caps the nonce at <code>2^64-2</code>, reserving it for contracts with unusual behavior, as defined in other EIPs.</p> <h2 id="motivation">Motivation</h2> <p>This EIP is not terribly useful on its own, as it adds additional computation without any useful side effects. However, it can be used by other EIPs.</p> <h2 id="specification">Specification</h2> <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p> <h3 id="eoa-transactions">EOA Transactions</h3> <p>The nonce of a transaction originating from an EOA MUST be less than <code>2^64-2</code>. If the nonce is either <code>2^64-1</code> or <code>2^64-2</code>, the transaction MUST be invalid.</p> <h3 id="create-and-create2"><code>CREATE</code> and <code>CREATE2</code></h3> <p>If a nonce would be incremented to <code>2^64-1</code> by <code>CREATE</code> or <code>CREATE2</code>, it is instead set to <code>2^64-2</code>. <code>2^64-1</code> is reserved for alias or other special contracts.</p> <h2 id="rationale">Rationale</h2> <p>Capping a nonce allows for contracts with special properties to be created, with their functionality based on their contract code. As such, only one nonce needs to be reserved.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a protocol upgrade, since it modifies consensus rules. The further restriction of nonce should not have an effect on accounts, as reaching a nonce of <code>2^64-2</code> is difficult.</p> <h2 id="security-considerations">Security Considerations</h2> <p>As it is not feasible for contract accounts to get to the nonce limit, any potential problems with opcodes that depend on the value of an account's nonce can be safely ignored.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-12-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gavin Johnhttps://github.com/Pandapip1 https://wg-eips.ritovision.com/6189/

Allows the creation of contracts that forward calls to other contracts

<h2 id="abstract">Abstract</h2> <p>This EIP allows contracts to be turned into "alias contracts" using a magic nonce. Alias contracts automatically forward calls to other contracts.</p> <h2 id="motivation">Motivation</h2> <p>This EIP is not terribly useful on its own, as it adds additional computation and gas costs without any useful side effects. However, in conjunction with <a href="https://wg-eips.ritovision.com/6190/">EIP-6190</a>, it can be used to make SELFDESTRUCT compatible with Verkle trees.</p> <h2 id="specification">Specification</h2> <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p> <h3 id="definitions">Definitions</h3> <p>A contract is an alias contract if its nonce is <code>2^64-1</code>, and its contract code is equal to <code>0x1</code>.</p> <h3 id="prerequisites">Prerequisites</h3> <p><a href="https://wg-eips.ritovision.com/6188/">EIP-6188</a> MUST be used to protect the magic nonce value of <code>2^64-1</code>.</p> <h3 id="opcode-changes">Opcode Changes</h3> <h4 id="call-callcode-delegatecall-staticcall-pay-and-eoa-transactions"><code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code>, <code>PAY</code>, and EOA Transactions</h4> <p>The "callee" refers to the account that is being called or being paid.</p> <p>If the nonce of the callee is <code>2^64-1</code>, the call MUST be forwarded to the address stored in the <code>0</code>th storage slot of the callee (as if the callee was the address stored in the <code>0</code>th storage slot of the callee). This MUST repeat until a non-alias contract is reached. The <code>CALLER</code> MUST remain unchanged.</p> <p>If there is more than one alias contract in the chain, the original callee and all subsequent callees (except the last one) MUST have their <code>0</code>th storage slot set to the address of the final non-alias contract. Then, the call MUST be forwarded as usual. <strong>This MUST occur, even in a read-only context like <code>STATICCALL</code>.</strong></p> <p>For example, if <code>A</code> is an alias contract that forwards calls to <code>B</code>, which is an alias contract that forwards calls to <code>C</code>, then <code>A</code>'s <code>0</code>th storage slot is set to <code>C</code>'s address. Then, the call is forwarded to <code>C</code>.</p> <p>Finally, the opcode MUST proceed as usual, using the final non-alias contract.</p> <p>The <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, and <code>STATICCALL</code> opcodes and EOA Transactions MUST cost an <code>25</code> gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>). For every account whose <code>0</code>th storage slot is updated, those opcodes MUST also cost an additional <code>5000</code> gas.</p> <p>If an infinite loop occurs, the transaction MUST run out of gas and revert.</p> <h4 id="extcodehash-extcodecopy-extcodesize-and-balance"><code>EXTCODEHASH</code>, <code>EXTCODECOPY</code>, <code>EXTCODESIZE</code>, and <code>BALANCE</code></h4> <p>The "accessed account" refers to the account that is being accessed (i.e. the account whose code is being accessed, or the account whose balance is being accessed).</p> <p>Similar to the <code>CALL</code> family of opcodes, if the nonce of the accessed account is <code>2^64-1</code>, the accessed account's address MUST be replaced with the address stored in the <code>0</code>th storage slot of the accessed account. This MUST repeat until a non-alias contract is reached.</p> <p>If there is more than one alias contract in the chain, the original accessed account and all subsequent accessed accounts (except the last one) MUST have their <code>0</code>th storage slot set to the address of the final non-alias contract. Then, the accessed account MUST be replaced as usual. <strong>This MUST occur, even in a read-only context like <code>STATICCALL</code>.</strong></p> <p>Finally, the opcode MUST proceed as usual, using the final non-alias contract.</p> <p>The <code>EXTCODEHASH</code>, <code>EXTCODECOPY</code>, <code>EXTCODESIZE</code>, and <code>BALANCE</code> opcodes MUST cost an <code>25</code> gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>). For every account whose <code>0</code>th storage slot is updated, those opcodes MUST also cost an additional <code>5000</code> gas.</p> <p>If an infinite loop occurs, the transaction MUST run out of gas and revert.</p> <h4 id="create-and-create2"><code>CREATE</code> and <code>CREATE2</code></h4> <p>If <code>CREATE</code> or <code>CREATE2</code> would create (or fail to create, depending on which EIPs are used) an account at an address, and that account's code is <code>0x1</code>, and its nonce is <code>2^64-1</code>, then instead of reverting, an attempt MUST be made to create a contract at the address stored in the <code>0</code>th storage slot of the existing account. This MUST repeat until a non-alias contract is reached.</p> <p>If there is more than one alias contract in the chain, the original accessed account and all subsequent accessed accounts (except the last one) MUST have their <code>0</code>th storage slot set to the address of the final non-alias contract.</p> <p>Finally, the opcode MUST proceed as usual, returning the address of the newly-created contract.</p> <p>The <code>CREATE</code> and <code>CREATE2</code> opcodes MUST cost an <code>25</code> gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>). For every account whose <code>0</code>th storage slot is updated, those opcodes must also cost an additional <code>5000</code> gas.</p> <p>If an infinite loop occurs, the transaction runs out of gas and reverts.</p> <h4 id="address"><code>ADDRESS</code></h4> <p>This opcode remains unchanged; <code>ADDRESS</code> points to the address that doesn't have a nonce of <code>2^64-1</code>.33</p> <h3 id="transfers-to-the-zero-address">Transfers to the zero address</h3> <p>Transfers to the zero address continue to have the same effect as the <code>CREATE</code> opcode, and will cost extra gas as discussed in the <a href="https://wg-eips.ritovision.com/6189/#create-and-create2"><code>CREATE</code> and <code>CREATE2</code></a> section.</p> <h3 id="transaction-validity">Transaction Validity</h3> <p>The "origin" refers to the account that sent the transaction to be validated.</p> <p>If the nonce of the origin is <code>2^64-1</code>, the origin MUST be updated to the address stored in the <code>0</code>th storage slot of the current origin (as if the origin was the address stored in the <code>0</code>th storage slot of the current origin). This MUST repeat until a non-alias contract is reached.</p> <p>If there is more than one alias contract in the chain, the original origin and all subsequent origins (except the last one) MUST have their <code>0</code>th storage slot set to the address of the final non-alias contract. Then, the call MUST be forwarded as usual.</p> <p>An additional <code>25</code> gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>) is added to the validation costs. For every account whose <code>0</code>th storage slot is updated, it also costs an additional <code>5000</code> gas.</p> <p>Finally, validation proceeds as normal.</p> <h3 id="rpc-endpoint-changes">RPC Endpoint Changes</h3> <h4 id="eth-getstorageat"><code>eth_getStorageAt</code></h4> <p>The <code>eth_getStorageAt</code> RPC endpoint must error if the target contract has a contract code of <code>0x1</code> and a nonce of <code>2^64-1</code>.</p> <h2 id="rationale">Rationale</h2> <p>The additional gas cost of <code>25</code> represents the cost of fetching the nonce and comparing it to the given value.</p> <p><code>eth_getStorageAt</code> was modified to throw an error because of alias contracts' special behavior.</p> <p>The nonce of <code>2^64-1</code> was chosen since it is the nonce protected by <a href="https://wg-eips.ritovision.com/6188/">EIP-6188</a>.</p> <p>The contract code of <code>0x1</code> was chosen arbitrarily. A nonzero code was chosen just in case a non-alias contract with nonce <code>2^64-1</code> somehow had its code set to <code>0x0</code>, or an EOA had its nonce set to <code>2^64-1</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a protocol upgrade, since it modifies consensus rules. No existing contracts should be affected, as they will not have a nonce of <code>2^64-1</code>, nor will they have the contract code <code>0x1</code>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The additional gas costs may cause potential DoS attacks if they access an arbitrary contract's data or make frequent contract deactivations. Contract authors must be aware and design contracts accordingly. There may be an effect on existing deployed code performing autonomous destruction and revival.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-12-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gavin Johnhttps://github.com/Pandapip1 https://wg-eips.ritovision.com/6190/

Changes SELFDESTRUCT to only cause a finite number of state changes

<h2 id="abstract">Abstract</h2> <p>Changes <code>SELFDESTRUCT</code> to only cause a finite number of state changes.</p> <h2 id="motivation">Motivation</h2> <p>The <code>SELFDESTRUCT</code> instruction has a fixed price, but is unbounded in storage/account changes (it needs to delete all keys). This has been an outstanding concern for some time.</p> <p>Furthermore, with <em>Verkle trees</em> accounts will be organised differently. Account properties, including storage, would have individual keys. It would not be possible to traverse and find all used keys. This makes <code>SELFDESTRUCT</code> very challenging to support in Verkle trees. This EIP is a step towards supporting <code>SELFDESTRUCT</code> in Verkle trees.</p> <h2 id="specification">Specification</h2> <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p> <h3 id="prerequisites">Prerequisites</h3> <p><a href="https://wg-eips.ritovision.com/6188/">EIP-6188</a> and <a href="https://wg-eips.ritovision.com/6189/">EIP-6189</a> must be used for this EIP to function correctly.</p> <h3 id="selfdestruct-behaviour"><code>SELFDESTRUCT</code> Behaviour</h3> <p>Instead of destroying the contract at the end of the transaction, instead, the following will occur at the end of the transaction in which it is invoked:</p> <ol> <li>The contract's code is set to <code>0x1</code>, and its nonce is set to <code>2^64-1</code>.</li> <li>The contract's <code>0</code>th storage slot is set to the address that would be issued if the contract used the <code>CREATE</code> opcode (<code>keccak256(contractAddress, nonce)</code>). Note that the nonce is always <code>2^64-1</code>.</li> <li>If the contract was self-destructed after the call being forwarded by one or more alias contracts, the alias contract's <code>0</code>th storage slot is set to the address calculated in step 2.</li> <li>The contract's balance is transferred, in its entirety, to the address on the top of the stack.</li> <li>The top of the stack is popped.</li> </ol> <h3 id="gas-cost-of-selfdestruct">Gas Cost of <code>SELFDESTRUCT</code></h3> <p>The base gas cost of <code>SELFDESTRUCT</code> is set to <code>5000</code>. The gas cost of <code>SELFDESTRUCT</code> is increased by <code>5000</code> for each alias contract that forwarded to the contract being self-destructed. Finally, the <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> gas cost increase is applied.</p> <h2 id="rationale">Rationale</h2> <p>This EIP is designed to be a step towards supporting <code>SELFDESTRUCT</code> in Verkle trees while making the minimum amount of changes.</p> <p>The <code>5000</code> base gas cost and additional alias contracts represents the cost of setting the account nonce and first storage slot. The <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> gas cost increase is preserved for the reasons mentioned in said EIP's Rationale.</p> <p>The nonce of <code>2^64-1</code> was chosen since it is the nonce protected by <a href="https://wg-eips.ritovision.com/6188/">EIP-6188</a>. The account code of <code>0x1</code> was chosen since it was the code specified in <a href="https://wg-eips.ritovision.com/6189/">EIP-6189</a>.</p> <p>The address being the same as the one created by <code>CREATE</code> is designed to reduce possible attack vectors by not introducing a new mechanism by which accounts can be created at specific addresses.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a protocol upgrade, since it modifies consensus rules.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-12-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin Danny Ryanhttps://github.com/djrtwo Peter Davieshttps://github.com/petertdavies https://wg-eips.ritovision.com/6110/

Provides validator deposits as a list of deposit operations added to the Execution Layer block

<h2 id="abstract">Abstract</h2> <p>Appends validator deposits to the Execution Layer block structure. This shifts responsibility of deposit inclusion and validation to the Execution Layer and removes the need for deposit (or <code>eth1data</code>) voting from the Consensus Layer.</p> <p>Validator deposits list supplied in a block is obtained by parsing deposit contract log events emitted by each deposit transaction included in a given block.</p> <h2 id="motivation">Motivation</h2> <p>Validator deposits are a core component of the proof-of-stake consensus mechanism. This EIP allows for an in-protocol mechanism of deposit processing on the Consensus Layer and eliminates the proposer voting mechanism utilized currently. This proposed mechanism relaxes safety assumptions and reduces complexity of client software design, contributing to the security of the deposits flow. It also improves validator UX.</p> <p>Advantages of in-protocol deposit processing consist of, but are not limited to, the following:</p> <ul> <li>Significant increase of deposits security by supplanting proposer voting. With the proposed in-protocol mechanism, an honest online node can't be convinced to process fake deposits even when more than 2/3 portion of stake is adversarial.</li> <li>Decrease of delay between submitting deposit transaction on Execution Layer and its processing on Consensus Layer. That is, ~13 minutes with in-protocol deposit processing compared to ~12 hours with the existing mechanism.</li> <li>Eliminate beacon block proposal dependency on JSON-RPC API data polling that suffers from failures caused by inconsistencies between JSON-RPC API implementations and dependency of API calls processing on the inner state (e.g. syncing) of client software.</li> <li>Eliminate requirement to maintain and distribute deposit contract snapshots (<a href="https://wg-eips.ritovision.com/4881/">EIP-4881</a>).</li> <li>Reduction of design and engineering complexity of Consensus Layer client software on a component that has proven to be brittle.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="execution-layer">Execution Layer</h3> <h4 id="constants">Constants</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>DEPOSIT_REQUEST_TYPE</code></td><td><code>b'0'</code></td><td>The <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request type byte for deposit operation</td></tr> </tbody></table> <h4 id="configuration">Configuration</h4> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>DEPOSIT_CONTRACT_ADDRESS</code></td><td><code>0x00000000219ab540356cbb839cbe05303d7705fa</code></td><td>Mainnet</td></tr> <tr><td><code>DEPOSIT_EVENT_SIGNATURE_HASH</code></td><td><code>0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5</code></td><td></td></tr> </tbody></table> <p><code>DEPOSIT_CONTRACT_ADDRESS</code>, <code>DEPOSIT_EVENT_SIGNATURE_HASH</code> parameters <strong>MUST</strong> be included into client software binary distribution.</p> <h4 id="definitions">Definitions</h4> <ul> <li><strong><code>FORK_BLOCK</code></strong> -- the first block in a blockchain after this EIP has been activated.</li> </ul> <h4 id="deposit-request">Deposit request</h4> <p>The structure denoting the new deposit request consists of the following fields:</p> <ol> <li><code>pubkey: Bytes48</code></li> <li><code>withdrawal_credentials: Bytes32</code></li> <li><code>amount: uint64</code></li> <li><code>signature: Bytes96</code></li> <li><code>index: uint64</code></li> </ol> <p>Deposits are a type of <a href="https://wg-eips.ritovision.com/7685/">EIP-7685</a> request, with the following encoding:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>request_type</span><span class="z-keyword"> =</span><span class="z-constant"> DEPOSIT_REQUEST_TYPE</span></span> <span class="giallo-l"><span>request_data</span><span class="z-keyword"> =</span><span> get_deposit_request_data</span><span>(</span><span>block</span><span>.</span><span>receipts</span><span>)</span></span></code></pre><h4 id="block-validity">Block validity</h4> <p>Beginning with the <code>FORK_BLOCK</code>, each deposit accumulated in the block <strong>MUST</strong> appear in the EIP-7685 requests list in the order they appear in the logs. To illustrate:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> parse_deposit_data</span><span>(</span><span class="z-variable z-parameter z-function">deposit_event_data</span><span>)</span><span> -&gt;</span><span> bytes</span><span>[</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Parses deposit data from DepositContract.DepositEvent data</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> is_valid_deposit_event_data</span><span>(</span><span class="z-variable z-parameter z-function">deposit_event_data</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> bool</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verifies the layout of the DepositEvent. Returns `False` if the layout is unsupported,</span></span> <span class="giallo-l"><span class="z-string"> `True` if the layout is of the expected format.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>deposit_event_data</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 576</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> pubkey_offset</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span class="z-constant">0</span><span>:</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> withdrawal_credentials_offset</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">64</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> amount_offset</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span class="z-constant">64</span><span>:</span><span class="z-constant">96</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> signature_offset</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span class="z-constant">96</span><span>:</span><span class="z-constant">128</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> index_offset</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span class="z-constant">128</span><span>:</span><span class="z-constant">160</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span> pubkey_offset</span><span class="z-keyword"> !=</span><span class="z-constant"> 160</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> withdrawal_credentials_offset</span><span class="z-keyword"> !=</span><span class="z-constant"> 256</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> amount_offset</span><span class="z-keyword"> !=</span><span class="z-constant"> 320</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> signature_offset</span><span class="z-keyword"> !=</span><span class="z-constant"> 384</span></span> <span class="giallo-l"><span class="z-keyword"> or</span><span> index_offset</span><span class="z-keyword"> !=</span><span class="z-constant"> 512</span></span> <span class="giallo-l"><span> )</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> These sizes are the sizes of the relevant data</span></span> <span class="giallo-l"><span> pubkey_size</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span>pubkey_offset</span><span>:</span><span>pubkey_offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> withdrawal_credentials_size</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span>withdrawal_credentials_offset</span><span>:</span><span>withdrawal_credentials_offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> amount_size</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span>amount_offset</span><span>:</span><span>amount_offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> signature_size</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span>signature_offset</span><span>:</span><span>signature_offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"><span> index_size</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>.</span><span>from_bytes</span><span>(</span><span>deposit_event_data</span><span>[</span><span>index_offset</span><span>:</span><span>index_offset</span><span class="z-keyword">+</span><span class="z-constant">32</span><span>]</span><span>,</span><span class="z-variable"> byteorder</span><span class="z-keyword">=</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">big</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> signed</span><span class="z-keyword">=</span><span class="z-constant">False</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span></span> <span class="giallo-l"><span> pubkey_size</span><span class="z-keyword"> ==</span><span class="z-constant"> 48</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> withdrawal_credentials_size</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> amount_size</span><span class="z-keyword"> ==</span><span class="z-constant"> 8</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> signature_size</span><span class="z-keyword"> ==</span><span class="z-constant"> 96</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> index_size</span><span class="z-keyword"> ==</span><span class="z-constant"> 8</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> event_data_to_deposit_request</span><span>(</span><span class="z-variable z-parameter z-function">deposit_event_data</span><span>)</span><span> -&gt;</span><span class="z-support"> bytes</span><span>:</span></span> <span class="giallo-l"><span> deposit_data</span><span class="z-keyword"> =</span><span> parse_deposit_data</span><span>(</span><span>deposit_event_data</span><span>)</span></span> <span class="giallo-l"><span> pubkey</span><span class="z-keyword"> =</span><span> Bytes48</span><span>(</span><span>deposit_data</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> withdrawal_credentials</span><span class="z-keyword"> =</span><span> Bytes32</span><span>(</span><span>deposit_data</span><span>[</span><span class="z-constant">1</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> amount</span><span class="z-keyword"> =</span><span> deposit_data</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 8 bytes uint64 LE</span></span> <span class="giallo-l"><span> signature</span><span class="z-keyword"> =</span><span> Bytes96</span><span>(</span><span>deposit_data</span><span>[</span><span class="z-constant">3</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> index</span><span class="z-keyword"> =</span><span> deposit_data</span><span>[</span><span class="z-constant">4</span><span>]</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 8 bytes uint64 LE</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> pubkey</span><span class="z-keyword"> +</span><span> withdrawal_credentials</span><span class="z-keyword"> +</span><span> amount</span><span class="z-keyword"> +</span><span> signature</span><span class="z-keyword"> +</span><span> index</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_deposit_request_data</span><span>(</span><span class="z-variable z-parameter z-function">receipts</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Retrieve all deposits made in the block</span></span> <span class="giallo-l"><span> deposit_requests</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> receipt</span><span class="z-keyword"> in</span><span> receipts</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> log</span><span class="z-keyword"> in</span><span> receipt</span><span>.</span><span>logs</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> log</span><span>.</span><span>address</span><span class="z-keyword"> ==</span><span class="z-constant"> DEPOSIT_CONTRACT_ADDRESS</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>log</span><span>.</span><span>topics</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span> log</span><span>.</span><span>topics</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> ==</span><span class="z-constant"> DEPOSIT_EVENT_SIGNATURE_HASH</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> is_valid_deposit_event_data</span><span>(</span><span>log</span><span>.</span><span>data</span><span>)</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid deposit log: unsupported data layout</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"><span> deposit_request</span><span class="z-keyword"> =</span><span> event_data_to_deposit_request</span><span>(</span><span>log</span><span>.</span><span>data</span><span>)</span></span> <span class="giallo-l"><span> deposit_requests</span><span>.</span><span>append</span><span>(</span><span>deposit_request</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Concatenate list of deposit request data</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-punctuation z-definition z-string">&#39;</span><span>.</span><span>join</span><span>(</span><span>deposit_requests</span><span>)</span></span></code></pre><h3 id="consensus-layer">Consensus layer</h3> <p>Consensus layer changes can be summarized into the following list:</p> <ol> <li><code>ExecutionRequests</code> is extended with a new <code>deposit_requests</code> field to accommodate deposit requests list.</li> <li><code>BeaconState</code> is appended with <code>deposit_requests_start_index</code> used to switch from the former deposit mechanism to the new one.</li> <li>As a part of transition logic a new beacon block validity condition is added to constrain the usage of <code>Eth1Data</code> poll.</li> <li>A new <code>process_deposit_request</code> function is added to the block processing routine to handle <code>deposit_requests</code> processing.</li> <li>Validator guide provides a logic switching off <code>Eth1Data</code> poll once transition is completed.</li> </ol> <p>Detailed consensus layer specification can be found in following documents:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/eba62dbf00132dfdc97fbfab663a99cb23b9e8f1/specs/electra/beacon-chain.md"><code>electra/beacon-chain.md</code></a> -- state transition.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/eba62dbf00132dfdc97fbfab663a99cb23b9e8f1/specs/electra/validator.md"><code>electra/validator.md</code></a> -- validator guide.</li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/eba62dbf00132dfdc97fbfab663a99cb23b9e8f1/specs/electra/fork.md"><code>electra/fork.md</code></a> -- EIP activation.</li> </ul> <h4 id="validator-index-invariant">Validator index invariant</h4> <p>Due to the large follow distance of <code>Eth1Data</code> poll an index of a new validator assigned during deposit processing remains the same across different branches of a block tree, i.e. with existing mechanism <code>(pubkey, index)</code> cache utilized by consensus layer clients is re-org resilient. The new deposit machinery breaks this invariant and consensus layer clients will have to deal with a fact that a validator index becomes fork dependent, i.e. a validator with the same <code>pubkey</code> can have different indexes in different block tree branches.</p> <p>Detailed <a href="https://wg-eips.ritovision.com/6110/assets/pubkey_to_index_cache_analysis/">analysis</a> shows that <code>process_deposit</code> function is <em>the only</em> place requiring a fork dependent <code>(pubkey, index)</code> cache.</p> <h4 id="eth1data-poll-deprecation"><code>Eth1Data</code> poll deprecation</h4> <p>Consensus layer clients will be able to remove <code>Eth1Data</code> poll mechanism in an uncoordinated fashion once transition period is finished. The transition period is considered as finished when a network reaches the point where <code>state.eth1_deposit_index == state.deposit_requests_start_index</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="index-field"><code>index</code> field</h3> <p>Deposit <code>index</code> is used to deterministically initialize <code>deposit_requests_start_index</code> in the <code>BeaconState</code>, this prevents same deposit from being applied twice during <code>Eth1Data</code> poll deprecation.</p> <h3 id="not-limiting-the-size-of-deposit-operations-list">Not limiting the size of deposit operations list</h3> <p>The list is unbounded because of negligible data complexity and absence of potential DoS vectors. See <a href="https://wg-eips.ritovision.com/6110/#security-considerations">Security Considerations</a> for more details.</p> <h3 id="filtering-events-by-deposit-contract-address-and-deposit-event-signature-hash">Filtering events by <code>DEPOSIT_CONTRACT_ADDRESS</code> and <code>DEPOSIT_EVENT_SIGNATURE_HASH</code></h3> <p>Depending on the design, Deposit smart contract can emit different type of events when deposit is being processed. For instance, Deposit smart contract on Sepolia emits <code>Transfer</code> in addition to <code>DepositEvent</code>. Thus it is important to filter out irrelevant events.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards incompatible changes to the block structure and block validation rule set. But neither of these changes break anything related to user activity and experience.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="data-complexity">Data complexity</h3> <p>At the time of the latest update of this document, the total number of submitted deposits is 1,899,120 which is 348MB of deposit data. Assuming frequency of deposit transactions remains the same, historic chain data complexity induced by this EIP can be estimated as 84MB per year which is negligible in comparison to other historical data.</p> <p>After the beacon chain launch in December 2020, the biggest observed spike in a number of submitted deposits was on June 1, 2023. More than 12,000 deposit transactions were submitted during 24 hours which on average is less than 2 deposit, or 384 bytes of data, per block.</p> <p>Considering the above, we conclude that data complexity introduced by this proposal is negligible.</p> <h3 id="dos-vectors">DoS vectors</h3> <p>The code in the deposit contract costs 15,650 gas to run in the cheapest case (when all storage slots are hot and only a single leaf has to be modified). Some deposits in a batch deposit are more expensive, but those costs, when amortized over a large number of deposits, are small at around ~1,000 gas per deposit. Under current gas pricing rules an extra 6,900 gas is charged to make a <code>CALL</code> that transfers ETH, this is a case of inefficient gas pricing and may be reduced in the future. For future robustness the beacon chain needs to be able to withstand 1,916 deposits in a 30M gas block (15,650 gas per deposit). The limit under current rules is less than 1,271 deposits in a 30M gas block.</p> <h4 id="execution-layer-1">Execution layer</h4> <p>With 1 ETH as a minimum deposit amount, the lowest cost of a byte of deposit data is 1 ETH/192 ~ 5,208,333 Gwei. This is several orders of magnitude higher than the cost of a byte of transaction's calldata, thus adding deposit operations to a block does not increase DoS attack surface of the execution layer.</p> <h4 id="consensus-layer-1">Consensus layer</h4> <p>The most consuming computation of deposit processing is signature verification. Its complexity is bounded by a maximum number of deposits per block which is around 1,271 with 30M gas block at the moment. So, it is ~1,271 signature verifications which is roughly ~1.2 seconds of processing (without optimisations like batched signatures verification). An attacker would need to spend 1,000 ETH to slow down block processing by a second which isn't sustainable and viable attack long term.</p> <p>An optimistically syncing node may be susceptible to a more severe attack scenario. Such a node can't validate a list of deposits provided in a payload which makes it possible for attacker to include as many deposits as the limitation allows to. Currently, it is 8,192 deposits (1.5MB of data) with rough processing time of 8s. Considering an attacker would need to sign off on this block with its crypto economically viable signature (which requires building an alternative chain and feeding it to a syncing node), this attack vector is not considered as viable as it can't result in a significant slow down of a sync process.</p> <h3 id="optimistic-sync">Optimistic sync</h3> <p>An optimistically syncing node has to rely on the honest majority assumption. That is, if adversary is powerful enough to finalize a deposit sequence, a syncing node will have to apply these deposits disregarding the validity of deposit requests with respect to the execution of a given block. Thus, an adversary that can finalize an invalid chain can also convince an honest node to accept fake deposits. The same is applicable to the validity of execution layer world state today and a new deposit processing design is within boundaries of the existing security model in that regard.</p> <p>Online nodes can't be tricked into this situation because their execution layer validates supplied deposits with respect to the block execution.</p> <h3 id="weak-subjectivity-period">Weak subjectivity period</h3> <p>This EIP removes a hard limit on a number of deposits per epoch and makes a block gas limit the only limitation on this number. That is, the limit on deposits per epoch shifts from <code>MAX_DEPOSITS * SLOTS_PER_EPOCH = 512</code> to <code>max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ~ 32,768</code> at 30M gas block (we consider <code>max_deposits_per_30m_gas_block = 1,024</code> for simplicity).</p> <p>This change affects a number of top ups per epoch which is one of the inputs to the weak subjectivity period computation. One can top up own validators to instantly increase a portion of stake it owns with respect to those validators that are leaking. <a href="https://wg-eips.ritovision.com/6110/assets/ws_period_analysis/">The analysis</a> does not demonstrate significant reduction of a weak subjectivity period sizes. Moreover, such an attack is not considered as viable because it requires a decent portion of stake to be burned as one of preliminaries.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-11-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/6046/

Change SELFDESTRUCT to not delete storage keys and use a special value in the account nonce to signal deactivation

<h2 id="abstract">Abstract</h2> <p>Change <code>SELFDESTRUCT</code> to not delete all storage keys, and to use a special value in the account nonce to signal <em>deactivated</em> accounts. Because the semantics of revival change (storage keys may exists), we also rename the instruction to <code>DEACTIVATE</code>.</p> <h2 id="motivation">Motivation</h2> <p>The <code>SELFDESTRUCT</code> instruction currently has a fixed price, but is unbounded in terms of how many storage/account changes it performs (it needs to delete all keys). This has been an outstanding concern for some time.</p> <p>Furthermore, with <em>Verkle trees</em>, accounts will be organised differently: account properties, including storage, will have individual keys. It will not be possible to traverse and find all used keys. This makes <code>SELFDESTRUCT</code> very challenging to support in Verkle trees.</p> <h2 id="specification">Specification</h2> <ol> <li> <p>Change the rules introduced by <a href="https://wg-eips.ritovision.com/2681/">EIP-2681</a> such that regular nonce increase is bound by <code>2^64-2</code> instead of <code>2^64-1</code>. This applies from genesis.</p> </li> <li> <p>The behaviour of <code>SELFDESTRUCT</code> is changed such that:</p> </li> </ol> <ul> <li>Does not delete any storage keys and also leave the account in place.</li> <li>Transfer the account balance to the target <strong>and</strong> set account balance to <code>0.</code></li> <li>Set the account nonce to <code>2^64-1</code>.</li> <li>Note that no refund is given since <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a>.</li> <li>Note that the rules of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> regarding <code>SELFDESTRUCT</code> remain unchanged.</li> </ul> <ol start="2"> <li>Modify account execution (triggered both via external transactions or CALL* instructions), such that execution succeeds and returns an empty buffer if the nonce equals <code>2^64-1</code>.</li> </ol> <ul> <li>Note that the account can still receive non-executable value transfers (such as coinbase transactions or other <code>SELFDESTRUCT</code>s).</li> </ul> <ol start="3"> <li>Modify <code>CREATE2</code> such that it allows account creation if the nonce equals <code>2^64-1</code>.</li> </ol> <ul> <li>Note that the account (especially code and storage) might not be empty prior to <code>CREATE2</code>.</li> <li>Note that a successful <code>CREATE2</code> will change the account code, nonce and potentially balance.</li> </ul> <ol start="4"> <li>Rename the <code>SELFDESTRUCT</code> instruction to <code>DEACTIVATE</code>, because the semantics of "account revival" are changed: the old storage items will remain, and newly deployed code must be aware of this.</li> </ol> <h2 id="rationale">Rationale</h2> <p>There have been various proposals of removing <code>SELFDESTRUCT</code> and many would just outright remove the deletion capability. This breaks certain usage patterns, which the <em>deactivation</em> option leaves intact, albeit with minor changes. This only affects <em>newly</em> deployed code, and not existing one.</p> <p>All the proposals would leave data in the state, but this proposal provides the flexibility to reuse or remove storage slots one-by-one should the revived contract choose to do so.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a protocol upgrade, since it modifies consensus rules. The further restriction of nonce should not have an effect on accounts, as <code>2^64-2</code> is an unfeasibly high limit.</p> <p>Contracts using the revival pattern will still work, but the code deployed during revival may need to be made aware that storage keys can already exist in the account.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The new behaviour of preserving storage has a potential effect on security. Contract authors must be aware and design contracts accordingly. There may be an effect on existing deployed code performing autonomous destruction and revival.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-11-15T00:00:00+00:00 2026-02-11T14:49:28+00:00 Abdelhamid Bakhtahttps://github.com/abdelhamidbakhta Eli Ben Sassonhttps://github.com/Elistark Avihu Levyhttps://github.com/avihu28 David Levit Gurevichhttps://github.com/DavidLevitGurevich https://wg-eips.ritovision.com/5988/

Add a precompiled contract which implements the hash function used in the Poseidon cryptographic hashing algorithm

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new precompiled contract which implements the hash function used in the Poseidon cryptographic hashing algorithm, for the purpose of allowing interoperability between the EVM and ZK / Validity rollups, as well as introducing more flexible cryptographic hash primitives to the EVM.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/5988/./assets/papers/poseidon_paper.pdf">Poseidon</a> is an arithmetic hash function that is designed to be efficient for Zero-Knowledge Proof Systems. Ethereum adopts a rollup centric roadmap and hence must adopt facilities for L2s to be able to communicate with the EVM in an optimal manner.</p> <p>ZK-Rollups have particular needs for cryptographic hash functions that can allow for efficient verification of proofs.</p> <p>The Poseidon hash function is a set of permutations over a prime field, which makes it particularly well-suited for the purpose of building efficient ZK / Validity rollups on Ethereum.</p> <p>Poseidon is one of the most efficient hashing algorithms that can be used in this context. Moreover it is compatible with all major proof systems (SNARKs, STARKs, Bulletproofs, etc...). This makes it a good candidate for a precompile that can be used by many different ZK-Rollups.</p> <p>An important point to note is that ZK rollups using Poseidon have chosen different sets of parameters, which makes it harder to build a single precompile for all of them.</p> <p>However, we can still build a generic precompile that supports arbitrary parameters, and allow the ZK rollups to choose the parameters they want to use.</p> <p>This is the approach that we have taken in this EIP.</p> <h2 id="specification">Specification</h2> <p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLKNUM</code></td><td><code>TBD</code></td></tr> <tr><td><code>GAS_COST</code></td><td><code>TBD</code></td></tr> <tr><td><code>POSEIDON_PRECOMPILE_ADDRESS</code></td><td><code>0xA</code></td></tr> </tbody></table> <p>Here are the Poseidon parameters that the precompile will support:</p> <table><thead><tr><th>Parameter name</th><th>Description</th><th>Encoding size (in bytes)</th><th>Comments</th></tr></thead><tbody> <tr><td><code>p</code></td><td>Prime field modulus</td><td>32</td><td></td></tr> <tr><td><code>security_level</code></td><td>Security level measured in bits. Denoted <code>M</code> in the Poseidon paper</td><td>2</td><td></td></tr> <tr><td><code>alpha</code></td><td>Power of S-box</td><td>1</td><td></td></tr> <tr><td><code>input_rate</code></td><td>Size of input</td><td>2</td><td></td></tr> <tr><td><code>t</code></td><td>Size of the state</td><td>1</td><td></td></tr> <tr><td><code>full_round</code></td><td>Number of full rounds. Denoted as <code>R_F</code> in the Poseidon paper.</td><td>1</td><td></td></tr> <tr><td><code>partial_round</code></td><td>Number of partial rounds. Denoted as <code>R_P</code> in the Poseidon paper.</td><td>1</td><td></td></tr> <tr><td><code>input</code></td><td>Input to the hash function</td><td><code>input_rate</code> * 32</td><td></td></tr> </tbody></table> <p>The encoding of the precompile input is the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[32 bytes for p][2 bytes for security_level][1 byte for alpha][2 bytes for input_rate][1 byte for t][1 byte for full_round][1 byte for partial_round][input_rate * 32 bytes for input]</span></span></code></pre> <p>The precompile should compute the hash function as <a href="https://wg-eips.ritovision.com/5988/./assets/papers/poseidon_paper.pdf">specified in the Poseidon paper</a> and return hash output.</p> <!--### Example Usage in Solidity The precompile can be wrapped easily in Solidity to provide a more development-friendly interface to `poseidon_hash` function. ```solidity // TODO: Add solidity example ```--> <!--### Gas Costs ``` TODO: Fill gas costs section ```--> <h2 id="rationale">Rationale</h2> <p>TODO: Add rationale</p> <p>TODO: Add rationale for gas cost e.g. benchmark and computation cost estimation.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at <code>0xPOSEIDON_PRECOMPILE_ADDRESS</code> being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision.</p> <h2 id="test-cases">Test Cases</h2> <p>The Poseidon reference implementation contains test vectors that can be used to test the precompile. Those tests are available <a href="https://wg-eips.ritovision.com/5988/./assets/test/poseidon/test_vectors.txt">here</a>.</p> <!--## Reference Implementation TODO: Add initial Geth implementation--> <h2 id="security-considerations">Security Considerations</h2> <p>Quoting Vitalik Buterin from <code>Arithmetic hash based alternatives to KZG for proto-danksharding</code> thread on EthResearch:</p> <blockquote> <p>The Poseidon hash function was officially introduced in 2019. Since then it has seen considerable attempts at cryptanalysis and optimization. However, it is still very young compared to popular “traditional” hash functions (eg. SHA256 and Keccak), and its general approach of accepting a high level of algebraic structure to minimize constraint count is relatively untested. There are layer-2 systems live on the Ethereum network and other systems that already rely on these hashes for their security, and so far they have seen no bugs for this reason. Use of Poseidon in production is still somewhat “brave” compared to decades-old tried-and-tested hash functions, but this risk should be weighed against the risks of proposed alternatives (eg. pairings with trusted setups) and the risks associated with centralization that might come as a result of dependence on powerful provers that can prove SHA256.</p> </blockquote> <p>It is true that arithmetic hash functions are relatively untested compared to traditional hash functions. However, Poseidon has been thoroughly tested and is considered secure by multiple independent research groups and layers 2 systems are already using it in production (StarkWare, Polygon, Loopring) and also by other projects (e.g. Filecoin).</p> <p>Moreover, the impact of a potential vulnerability in the Poseidon hash function would be limited to the rollups that use it.</p> <p>We can see the same rationale for the KZG ceremony in the <a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>, arguing that the risk of a vulnerability in the KZG ceremony is limited to the rollups that use it.</p> <p>List of projects (non exhaustive) using Poseidon:</p> <ul> <li>StarkWare plans to use Poseidon as the main hash function for StarkNet, and to add a Poseidon built-in in Cairo.</li> <li>Filecoin employs POSEIDON for Merkle tree proofs with different arities and for two-value commitments.</li> <li>Dusk Network uses POSEIDON to build a Zcash-like protocol for securities trading.11 It also uses POSEIDON for encryption as described above.</li> <li>Sovrin uses POSEIDON for Merkle-tree based revocation.</li> <li>Loopring uses POSEIDON for private trading on Ethereum.</li> <li>Polygon uses Poseidon for Hermez ZK-EVM.</li> </ul> <p>In terms of security, the choice of parameters is important.</p> <h3 id="security-of-the-poseidon-parameters">Security of the Poseidon parameters</h3> <h4 id="choice-of-the-mds-matrix">Choice of the MDS matrix</h4> <p>The MDS matrix is a square matrix of size <code>t</code> * <code>t</code> that is used to mix the state.</p> <p>This matrix is used during the <code>MixLayer</code> phase of the Poseidon hash function.</p> <p>The matrix must be chosen s.t. no subspace trail with inactive/active S-boxes can be set up for more than <code>t -1</code> rounds.</p> <p>There are some efficient algorithms to detect weak MDS matrices.</p> <p>Those algorithms are described in the <a href="https://wg-eips.ritovision.com/5988/./assets/papers/proving_resistance_linear_layer.pdf">Proving Resistance Against Infinitely Long Subspace Trails: How to Choose the Linear Layer</a> paper.</p> <p>The process of the generation of the matrix should look like this, as recommended in the Poseidon paper:</p> <ol> <li>Generate a random matrix.</li> <li>Check if the matrix is secure using Algorithm 1, Algorithm 2, and Algorithm 3 provided <a href="https://wg-eips.ritovision.com/5988/./assets/papers/proving_resistance_linear_layer.pdf">Proving Resistance Against Infinitely Long Subspace Trails: How to Choose the Linear Layer</a> paper.</li> <li>If the matrix is not secure, go back to step 1.</li> </ol> <h3 id="papers-and-research-related-to-poseidon-security">Papers and research related to Poseidon security</h3> <ul> <li><a href="https://wg-eips.ritovision.com/5988/./assets/papers/poseidon_paper.pdf">Poseidon: A New Hash Function for Zero-Knowledge Proof Systems</a></li> <li><a href="https://wg-eips.ritovision.com/5988/./assets/papers/security_poseidon_non_binary_differential_attacks.pdf">Security of the Poseidon Hash Function Against Non-Binary Differential and Linear Attacks</a></li> <li><a href="https://wg-eips.ritovision.com/5988/./assets/papers/report_security_stark_friendly_hash.pdf">Report on the Security of STARK-friendly Hash Functions</a></li> <li><a href="https://wg-eips.ritovision.com/5988/./assets/papers/practical_algebraic_attacks.pdf">Practical Algebraic Attacks against some Arithmetization-oriented Hash Functions</a></li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-10-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Hadrien Crouboishttps://github.com/Amxx https://wg-eips.ritovision.com/5806/

Adds a new transaction type that allows EOAs to execute arbitrary code through delegation

<h2 id="abstract">Abstract</h2> <p>This EIP adds a new transaction type that allows EOAs to execute arbitrary code using a delegate-call-like mechanism.</p> <h2 id="motivation">Motivation</h2> <p>EOA are the most widely used type of account, yet their ability to perform operations is limited to deploying contracts and sending "call" transactions. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interactions users can have with the blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as <a href="https://wg-eips.ritovision.com/4337/">ERC-4337</a> hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications.</p> <p>While smart contract wallets have a lot to offer in terms of UX, it is unlikely that all users will migrate any time soon because of the associated cost and the fact that some EOAs have custody of non-transferable assets.</p> <p>This EIP proposes an approach to allow the execution of arbitrary code by EOAs, with minimal change over the EVM, and using the same security model users are used to. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using <a href="https://wg-eips.ritovision.com/7/">EIP-7</a>), EOAs will be able to have more control over what operations they want to execute. This proposal's goal is NOT to provide an account abstraction primitive.</p> <p>By performing a delegate call to a multicall contract (such as the one deployed to <code>0xcA11bde05977b3631167028862bE2a173976CA11</code>), EOAs would be able to batch multiple transactions into a single one (being the <code>msg.sender</code> of all the sub calls). This would provide a better UX for users that want to interact with protocols (no need for multiple transactions, with variable gas prices and 21k gas overhead) and increase the security of such interactions (by avoiding unsafe token approvals being exploited between an <code>approval</code> and the following <code>transferFrom</code>).</p> <p>Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes emitting events.</p> <p>This EIP doesn't aim to replace other account abstraction proposals. It hopes to be an easy-to-implement alternative that would significantly improve the user experience of EOA owners in the near future.</p> <h2 id="specification">Specification</h2> <p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code> = <code>TBD</code></li> <li><code>TX_TYPE</code> = TBD, &gt; 0x03 (<a href="https://wg-eips.ritovision.com/4844/">EIP-4844</a>)</li> </ul> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> = <code>TX_TYPE(TBD)</code>.</p> <p>The intrinsic cost of the new transaction is inherited from <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, specifically <code>21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s])</span></span></code></pre> <p>The definitions of all fields follow the same semantics as <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>. Note the absence of <code>amount</code> field in this transaction!</p> <p>The <code>to</code> field deviates slightly from the semantics with the exception that it MUST NOT be nil and therefore must always represent a 20-byte address. This means that delegate transactions cannot have the form of a create transaction.</p> <p>The <code>signature_y_parity, signature_r, signature_s</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list]))</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <p>The execution of this new transaction type is equivalent to the delegate call mechanism introduced in <a href="https://wg-eips.ritovision.com/7/">EIP-7</a>, but performed by an EOA (the transaction sender). This implies that the code present at <code>destination</code>, if any, should be executed in the context of the sender. As a consequence, such a transaction emit an event from the EOA or use <code>Create2</code> with the address of the EOA as the creator. This transaction includes some restrictions though.</p> <h3 id="opcode-restriction">Opcode restriction</h3> <p>For security reasons, some opcodes should not be executed in the context of an EOA:</p> <ul> <li> <p><code>SSTORE</code> (0x55): Setting storage under an EOA breaks many assumptions. In particular storage set through a delegate transaction could cause issues if the accounts later "migrates" using <a href="https://wg-eips.ritovision.com/7377/">EIP-7377</a> or similar. Additionally, storage may be a source of conflicts if a single EOA uses delegate transactions to target codes that interpret the storage layout under this account differently. For all these reasons, EOA should be forbidden from performing <code>SSTORE</code> in the context of a delegate transaction. If a delegate transaction performs a CALL, the target of the call is free to manipulate storage normally.</p> </li> <li> <p><code>CREATE</code> (0xF0), <code>CREATE2</code> (0xF5) and <code>SELFDESTRUCT</code> (0xFF): There may be an expectation that transactions from a given sender should have consecutive nonces. This assumption would be broken if an EOA was able to execute one or multiple operations that alter the sender account's nonce. Consequently, EOA performing a delegate transaction should not be able to use the <code>CREATE</code>, <code>CREATE2</code> or <code>SELFDESTRUCT</code> opcodes. If a delegate transaction performs a CALL, the target of the call is free to create contracts normally.</p> </li> </ul> <p>Any attempts to make execute one of these restricted operations will instead throw an exception.</p> <h2 id="rationale">Rationale</h2> <p>EOAs are the most widely used type of wallet.</p> <p>This EIP would drastically expand the ability of EOAs to interact with smart contracts by using the pre-existing and well-understood delegation mechanism introduced in <a href="https://wg-eips.ritovision.com/7/">EIP-7</a> and without adding new complexity to the EVM.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known backward compatibility issues thanks to the transaction envelope (<a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a>).</p> <p>Due to the inclusion logic and the gas cost being similar to type 2 transactions, it should be possible to include this new transaction type in the same mempool.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The nonce mechanism, already used in other transaction types, prevents replay attacks. Similar to existing transaction types, a delegate transaction can be cancelled by replacing it with a dummy transaction that pays more fees.</p> <p>Since the object signed by the wallet is a transaction and not a signature that could potentially be processed in many ways (as is the case for <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a>), the risks associated with the miss-use of the signature are reduced. A wallet could simulate the execution of this delegate transaction and provide good guarantees that the operation that the user signs won't be manipulated.</p> <p>Contracts being called through this mechanism can execute any operation on behalf of the signer. As with other transaction types, signers should be extremely careful when signing a delegate transaction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-08-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Qi Zhouhttps://github.com/qizhou https://wg-eips.ritovision.com/5478/

Reducing the gas cost of contract creation with existing code

<h2 id="abstract">Abstract</h2> <p>Adding a new opcode, <code>CREATE2COPY</code>, that is identical to <code>CREATE2</code> but with potentially much lower gas cost by accepting an additional argument <code>existing_contract_address</code> that already stored the code of the new contract.</p> <h2 id="motivation">Motivation</h2> <p>This EIP aims to reduce the smart contract creation cost of account abstraction (AA) contracts that have identical code.</p> <p>The major cost of creating an AA contract is the contract creation cost, especially data gas. For example, creating an AA contract with 10,000 bytes will consume 2,000,000 data gas. Considering the code for each user's AA contract is the same, <code>CREATE2COPY</code> can reduce the data gas cost to 2600 (cold account) or even 100 (warm account) if the contract code already exists in the local storage.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLKNUM</code></td><td>TBD</td></tr> <tr><td><code>CREATE_DATA_GAS_PER_BYTE</code></td><td>200</td></tr> <tr><td><code>COLD_ACCOUNT_ACCESS_COST</code></td><td>2600</td></tr> <tr><td><code>WARM_ACCOUNT_ACCESS_COST</code></td><td>100</td></tr> </tbody></table> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, a new opcode is added (<code>CREATE2COPY</code>) at <code>0xf6</code>, which takes 5 stack arguments: <code>endowment</code>, <code>memory_start</code>, <code>memory_length</code>, <code>salt</code>, <code>existing_contract_address</code>. <code>CREATE2COPY</code> behaves identically to <code>CREATE2</code> (<code>0xf5</code> as defined in <a href="https://wg-eips.ritovision.com/1014/">EIP-1014</a>), except that the code hash of the creating contract MUST be the same as that of <code>existing_contract_address</code>.</p> <p><code>CREATE2COPY</code> has the same <code>gas</code> schema as <code>CREATE2</code>, but replacing the data gas from <code>CREATE_DATA_GAS_PER_BYTE * CONTRACT_BYTES</code> to the gas cost of <code>EXTCODEHASH</code> opcode, which is <code>COLD_ACCOUNT_ACCESS_COST</code> if the <code>existing_contract_address</code> is first-time accessed in the transaction or <code>WARM_ACCOUNT_ACCESS_COST</code> if <code>existing_contract_address</code> is already in the access list according to <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>.</p> <p>If the code of the contract returned from the init code differs from that of <code>existing_contract_address</code>, the creation fails with the error "mismatched contract creation code with existing code", and will burn all gas for the contract creation.</p> <h2 id="rationale">Rationale</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-08-12T00:00:00+00:00 2026-02-11T14:49:28+00:00 Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast Alex Beregszaszihttps://github.com/axic Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/5450/

Deploy-time validation of stack usage for EOF functions.

<h2 id="abstract">Abstract</h2> <p>Introduce extended validation of EOF code sections to guarantee that neither stack underflow nor overflow can happen during execution of validated contracts.</p> <h2 id="motivation">Motivation</h2> <p>The current EVM performs a number of validity checks for each executed instruction, such as checking for instruction being defined, stack overflow and underflow, and enough amount of gas remaining.</p> <p>This EIP minimizes the number of such checks required at run-time by verifying that no exceptional conditions can happen and preventing the execution and deployment of any invalid code.</p> <p>The operand stack validation provides several benefits:</p> <ul> <li>removes the run-time stack underflow check for all instructions,</li> <li>removes the run-time stack overflow check for all instructions except <code>CALLF</code> and <code>JUMPF</code> (<code>JUMPF</code> introduced in a separate EIP) ,</li> <li>ensures that execution terminates with one of the terminating instructions,</li> <li>prevents deployment of code with unreachable instructions, thereby discouraging the use of code sections for data storage.</li> </ul> <p>It also has some disadvantages:</p> <ul> <li>adds constraints to the code structure (similar to JVM, CPython bytecode, WebAssembly, SPIR-V and others); however, these constraints can be lifted in a backward-compatible manner if they are shown to be user-unfriendly,</li> <li>it is natural to implement stack validation as a second validation pass; however, it is not strictly required and validation's computational and space complexity remains linear in any implementation variant.</li> </ul> <p>The guarantees created by these validation rules also improve the feasibility of Ahead-Of-Time and Just-In-Time compilation of EVM code. Single pass transpilation passes can be safely executed with the code validation and advanced stack/register handling can be applied with the stack height validations. While not as impactful to a Mainnet validator node that is bound mostly by storage state sizes, these can significantly speed up witness validation and other non-Mainnet use cases.</p> <h2 id="specification">Specification</h2> <h3 id="code-validation">Code validation</h3> <p><em>Remark:</em> We rely on the notions of <em>operand stack</em> and <em>type section</em> as defined by <a href="https://wg-eips.ritovision.com/4750/">EIP-4750</a>.</p> <p>Each code section is validated independently.</p> <h4 id="instructions-validation">Instructions validation</h4> <p>In the first validation phase defined in <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> (and extended by <a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a> and <a href="https://wg-eips.ritovision.com/4750/">EIP-4750</a>) instructions are inspected independently to check if their opcodes and immediate values are valid.</p> <h4 id="operand-stack-validation">Operand stack validation</h4> <p>In the second validation phase control-flow analysis is performed on the code.</p> <p><em>Operand stack height</em> here refers to the number of stack values accessible by this function, i.e. it does not take into account values of caller functions' frames (but does include this function's inputs). Note that validation procedure does not require actual operand stack implementation, but only to keep track of its height.</p> <p><em>Terminating instructions</em> refers to the instructions either:</p> <ul> <li>ending function execution: <code>RETF</code>, <code>JUMPF</code>, or</li> <li>ending call frame execution: <code>STOP</code>, <code>RETURN</code>, <code>RETURNCODE</code>, <code>REVERT</code>, <code>INVALID</code>.</li> </ul> <p><em>note: <code>JUMPF</code> and <code>RETURNCODE</code> are introduced in separate EIPs.</em></p> <p><em>Forward jump</em> refers to any of <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> instruction with relative offset greater than or equal to 0. <em>Backwards jump</em> refers to any of <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> instruction with relative offset less than 0, including jumps to the same jump instruction.</p> <p>Instructions in the code are scanned in a single linear pass over the code. For each instruction the operand stack height bounds are recorded as <code>stack_height_min</code> and <code>stack_height_max</code>.</p> <p>The first instruction's recorded stack height bounds are initialized to be equal to the number of inputs to the function type matching the code (<code>stack_height_min = stack_height_max = type[code_section_index].inputs</code>).</p> <p>For each instruction:</p> <ol> <li><strong>Check</strong> if this instruction has recorded stack height bounds. If it does not, it means it was neither referenced by previous forward jump, nor is part of sequential instruction flow, and this code fails validation. <ul> <li>It is a prerequisite to validation algorithm, and code generators are required to order code basic blocks in a way that no block is referenced only by backwards jump. Any program can satisfy this requirement by ordering code basic blocks by the reverse postorder.</li> </ul> </li> <li>Determine the effect the instruction has on the operand stack: <ol> <li><strong>Check</strong> if the recorded stack height bounds satisfy the instruction requirements. Specifically: <ul> <li>for <code>CALLF</code> instruction the recorded stack height lower bound must be at least the number of inputs of the called function according to its type defined in the type section,</li> <li>for <code>RETF</code> instruction both the recorded lower and upper bound must be equal and must be exactly the number of outputs of the function matching the code,</li> <li>for <code>JUMPF</code> into returning function both the recorded lower and upper bound must equal exactly <code>type[current_section_index].outputs + type[target_section_index].inputs - type[target_section_index].outputs</code>,</li> <li>for <code>JUMPF</code> into non-returning function the recorded stack height lower bound must be at least the number of inputs of the target function according to its type defined in the type section,</li> <li>for any other instruction the recorded stack height lower bound must be at least the number of inputs required by instruction,</li> <li>there is no additional check for terminating instructions other than <code>RETF</code> and <code>JUMPF</code>, this implies that extra items left on stack at instruction ending EVM execution are allowed.</li> </ul> </li> <li>For <code>CALLF</code> and <code>JUMPF</code> <strong>check</strong> for possible stack overflow: if recorded stack height upper bound is greater than <code>1024 - types[target_section_index].max_stack_increase</code>, validation fails.</li> <li>Compute new stack height bounds after the instruction execution. Upper and lower bound are updated by the same value: <ul> <li>after <code>CALLF</code> stack height bounds are adjusted by adding <code>types[target_section_index].outputs - types[target_section_index].inputs</code>,</li> <li>after any other non-terminating instruction stack height bounds are adjusted by subtracting the number of instruction inputs and adding the number of instruction outputs,</li> <li>terminating instructions do not need to update stack height bounds.</li> </ul> </li> </ol> </li> <li>Determine the list of successor instructions that can follow the current instructions: <ol> <li>The next instruction if the current instruction is not a terminating instruction nor unconditional jump (<code>RJUMP</code>).</li> <li>All the current instruction targets if the current instruction is a conditional (<code>RJUMPI</code> or <code>RJUMPV</code>) or unconditional jump (<code>RJUMP</code>).</li> </ol> </li> <li>For each successor instruction: <ol> <li><strong>Check</strong> if the instruction is present in the code (i.e. execution must not "fall off" the code).</li> <li>If the successor is reached via forwards jump or sequential flow from previous instruction: <ol> <li>If the instruction does not have stack height bounds recorded (being visited for the first time), record the instruction stack height bound as the value computed in 2.3.</li> <li>Otherwise, instruction has been already visited (by previously seen forward jump). Update this instruction's recorded stack height bounds so that they contain the bounds computed in 2.3, i.e. <code>target_stack_min = min(target_stack_min, current_stack_min)</code> and <code>target_stack_max = max(target_stack_max, current_stack_max)</code>, where <code>(target_stack_min, target_stack_max)</code> are successor bounds and <code>(current_stack_min, current_stack_max)</code> are bounds computed in 2.3.</li> </ol> </li> <li>If the successor is reached via backwards jump, <strong>check</strong> if the recorded stack height bounds equal the value computed in 2.3. Validation fails if they are not equal, i.e. we see backwards jump to a different stack height.</li> </ol> </li> </ol> <p>After all instructions are visited, determine the function maximum operand stack height increase:</p> <ol> <li>Compute the maximum stack height <code>max_stack_height</code> as the maximum of all recorded stack height upper bounds.</li> <li>Compute the maximum stack height increase <code>max_stack_increase</code> as <code>max_stack_height - type[current_section_index].inputs</code>.</li> <li><strong>Check</strong> if the maximum stack height increase <code>max_stack_increase</code> matches the value corresponding code section's within the type section: <code>types[current_section_index].max_stack_increase</code>.</li> </ol> <p><em>Note: Although we check only that <code>max_stack_increase</code> matches the type section definition, which guarantees that it does not exceed 1023 by EOF header definition, it is also guaranteed that <code>max_stack_height</code> does not exceed 1024, because otherwise validation of <code>CALLF</code> and <code>JUMPF</code> into this section would fail at operand stack overflow check. Every section is required to have <code>CALLF</code> or <code>JUMPF</code> targeting it, except 0th section (non-reachable sections are not allowed). 0th section is required to have 0 inputs, which implies <code>max_stack_increase</code> equals <code>max_stack_height</code>.</em></p> <p>The computational and space complexity of this pass is <em>O(len(code))</em>. Each instruction is visited at most once.</p> <h3 id="execution">Execution</h3> <p>Given the deploy-time validation guarantees, an EVM implementation is not required anymore to have run-time stack underflow nor overflow checks for each executed instruction. The exception is the <code>CALLF</code> and <code>JUMPF</code> performing operand stack overflow check for the entire called function.</p> <h2 id="rationale">Rationale</h2> <h3 id="properties-of-validated-code">Properties of validated code</h3> <p>Any code section validated according to operand stack validation has the following properties:</p> <ol> <li>There are no unreachable instructions</li> <li>There are no instructions reachable only via backwards jump</li> <li>Operand stack underflow cannot happen.</li> <li>Operand stack overflow can only happen at <code>CALLF</code> or <code>JUMPF</code> instruction.</li> <li>Multiple forward jump instructions executing at different stack heights may target the same instruction; the stack of target basic block is validated for all possible heights.</li> <li>Any backwards jump instruction can only target an instruction that is executed with equal stack height; this prevents deployment of the loops with unbounded stack pushing or popping.</li> <li>Final instruction in the code section is either terminating instruction or <code>RJUMP</code>.</li> </ol> <h3 id="stack-overflow-check-only-in-callf-jumpf">Stack overflow check only in CALLF/JUMPF</h3> <p>In this EIP, we provide a more efficient variant of the EVM where stack overflow check is performed only in <code>CALLF</code> and <code>JUMPF</code> instructions using the called function's <code>max_stack_height</code> information. This decreases flexibility of an EVM program because <code>max_stack_height</code> corresponds to the worst-case control-flow path in the function.</p> <h3 id="unreachable-code">Unreachable code</h3> <p>The operand stack validation algorithm rejects any code having any unreachable instructions. This check can be performed very cheaply. It prevents deploying degenerated code. Moreover, it enables combining instruction validation and operand stack validation into single pass.</p> <h3 id="clean-stack-upon-termination">Clean stack upon termination</h3> <p>It is currently required that the operand stack is empty (in the current function context) after the <code>RETF</code> instruction. Otherwise, the <code>RETF</code> semantic would be more complicated. For <code>n</code> function outputs and <code>s</code> the stack height at <code>RETF</code> the EVM would have to erase <code>s-n</code> non-top stack items and move the <code>n</code> stack items to the place of erased ones. Cost of such operation may be relatively cheap but is not constant. However, lifting the requirement and modifying the <code>RETF</code> semantic as described above is backward compatible and can be easily introduced in the future.</p> <h3 id="more-restrictive-stack-validation">More restrictive stack validation</h3> <p>Originally another variant of stack validation was proposed, where instead of linear scan of the code section, all code paths were examined by following the target(s) of every jump instruction in a breadth-first-search manner, tracking stack height for each visited instruction and checking that for every possible code path to a particular instruction its stack height remains constant.</p> <p>The advantage of this variant would be somewhat simpler algorithm (we would not need to track stack height bounds, but only a single stack height value for each instruction) and no extra requirement for ordering of code basic blocks (see below).</p> <p>However, compiler teams opposed to such restrictive stack height requirements. One prominent pattern used by compilers which wouldn't be possible is jumping to terminating helpers (code blocks ending with <code>RETURN</code> or <code>REVERT</code>) from different stack heights. This is common for example for a series of <code>assert</code> statements, each one compiled to a <code>RJUMPI</code> into a shared terminating helper. Enforcing constant stack requirement would mean that before jumping to such helper, extra items on the stack have to be popped, and this noticeably increases code size and consumed gas, and would defeat the purpose of extracting these common terminating sequences into a helper.</p> <h3 id="ordering-of-basic-blocks">Ordering of basic blocks</h3> <p>The prerequisite to stack validation algorithm is ordering of code basic blocks in a way that no block is referenced only by backwards jump.</p> <p>This is required to make it possible to examine each instruction in one linear pass over the code section. Forward pass over the code section allows for the algorithm to "expand" each forward jump target's stack height bounds and still keep the complexity linear. Trying to do jump target stack bounds expansion while scanning the code in the breadth-first-search manner would require to re-examine entire code path after its stack height bounds are expanded, which would result in quadratic complexity.</p> <p>This requirement is not unique to EOF but also present is some low-level IRs like SPIR-V and LLVM MIR.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change requires a "network upgrade," since it modifies consensus rules.</p> <p>It poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).</p> <h2 id="security-considerations">Security Considerations</h2> <p>As mentioned above, the proposed validation algorithm has linear computational and space complexity and its cost is covered by the transaction data costs <a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-07-17T00:00:00+00:00 2026-02-11T14:49:28+00:00 Sergio D. Lernerhttps://github.com/SergioDemianLerner https://wg-eips.ritovision.com/5283/

A Precompile-based parallelizable reentrancy protection using the call stack

<h2 id="abstract">Abstract</h2> <p>This EIP proposes adding a precompiled contract that provides a semaphore function for creating a new type of reentrancy protection guard (RPG). This function aims to replace the typical RPG based on modifying a contract storage cell. The benefit is that the precompile-based RPG does not write to storage, and therefore it enables contracts to be forward-compatible with all designs that provide fine-grained (i.e. cell level) parallelization for the multi-threaded execution of EVM transactions.</p> <h2 id="motivation">Motivation</h2> <p>The typical smart contract RPG uses a contract storage cell. The algorithm is simple: the code checks that a storage cell is 0 (or any other predefined constant) on entry, aborting if not, and then sets it to 1. After executing the required code, it resets the cell back to 0 before exiting. This is the algorithm implemented in OpenZeppelin's ReentrancyGuard. The algorithm results in a read-write pattern on the RPG's storage cell. This pattern prevents the parallelization of the execution of the smart contract for all known designs that try to provide fine-grained parallelization (detecting conflicts at the storage cell level).</p> <p>Several EVM-based blockchains have successfully tested designs for the parallelization of the EVM. The best results have been obtained with fine-grained parallelization where conflicts are detected by tracking writes and reads of individual storage cells. The designs based on tracking the use of accounts or contracts provide only minor benefits because most transactions use the same <a href="https://wg-eips.ritovision.com/20/">EIP-20</a> contracts.</p> <p>To summarize, the only available RPG construction today is based on using a contract storage cell. This construction is clean but it is not forward-compatible with transaction execution parallelization.</p> <h2 id="specification">Specification</h2> <p>Starting from an activation block (TBD) a new precompiled contract <code>Semaphore</code> is created at address <code>0x0A</code>. When <code>Semaphore</code> is called, if the caller address is present more than once in the call stack, the contract behaves as if the first instruction had been a <code>REVERT</code>, therefore the CALL returns 0. Otherwise, it executes no code and returns 1. The gas cost of the contract execution is set to 100, which is consumed independently of the call result.</p> <h2 id="rationale">Rationale</h2> <p>The address <code>0x0A</code> is the next one available within the range defined by <a href="https://wg-eips.ritovision.com/1352/">EIP-1352</a>.</p> <h3 id="sample-usage">Sample usage</h3> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-keyword">pragma</span><span class="z-entity z-name z-tag"> solidity</span><span class="z-constant"> ^0.8.0</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">abstract</span><span class="z-storage z-type"> contract</span><span class="z-entity z-name"> ReentrancyGuard2</span><span> {</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> uint8</span><span class="z-storage z-type"> constant</span><span> SemaphoreAddress </span><span class="z-keyword">=</span><span class="z-constant"> 0x0A</span><span>;</span></span> <span class="giallo-l"><span class="z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@dev</span><span class="z-comment"> Prevents a contract from calling itself, directly or indirectly.</span></span> <span class="giallo-l"><span class="z-comment"> * Calling a `nonReentrant` function from another `nonReentrant`</span></span> <span class="giallo-l"><span class="z-comment"> * function is supported. </span></span> <span class="giallo-l"><span class="z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage z-type"> modifier</span><span class="z-entity z-name"> nonReentrant</span><span>(</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-entity z-name"> _nonReentrantBefore</span><span>(</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-constant"> _</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> _nonReentrantBefore</span><span>(</span><span>)</span><span class="z-storage z-type"> private</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> assembly</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-entity z-name"> iszero</span><span>(</span><span class="z-entity z-name">staticcall</span><span>(</span><span class="z-constant">1000</span><span>,</span><span>SemaphoreAddress</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> revert</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="parallelizable-storage-based-rpgs">Parallelizable storage-based RPGs</h3> <p>The only way to parallelize preexistent contracts that are using the storage RPG construction is that the VM automatically detects that a storage variable is used for the RPG, and proves that it works as required. This requires static code analysis. This is difficult to implement in consensus for two reasons. First, the CPU cost of detection and/or proving may be high. Second, some contract functions may not be protected by the RPG, meaning that some execution paths do not alter the RPG, which may complicate proving. Therefore this proposal aims to protect future contracts and let them be parallelizable, rather than to parallelize already deployed ones.</p> <h3 id="alternatives">Alternatives</h3> <p>There are alternative designs to implement RPGs on the EVM:</p> <ol> <li>Transient storage opcodes (<code>TLOAD</code>/<code>TSTORE</code>) provide contract state that is kept between calls in the same transaction but it is not committed to the world state afterward. These opcodes also enable fine-grained parallelization.</li> <li>An opcode <code>SSTORE_COUNT</code> that retrieves the number of <code>SSTORE</code> instructions executed. It enables also fine-grained execution parallelization, but <code>SSTORE_COUNT</code> is much more complex to use correctly as it returns the number <code>SSTORE</code> opcodes executed, not the number of reentrant calls. Reentrancy must be deducted from this value.</li> <li>A new <code>LOCKCALL</code> opcode that works similar to <code>STATICALL</code> but only blocks storage writes in the caller contract. This results in cheaper RPG, but it doesn't allow some contract functions to be free of the RPG.</li> </ol> <p>All these alternative proposals have the downside that they create new opcodes, and this is discouraged if the same functionality can be implemented with the same gas cost using precompiles. A new opcode requires modifying compilers, debuggers and static analysis tools.</p> <h3 id="gas-cost">Gas cost</h3> <p>A gas cost of 100 represents a worst-case resource consumption, which occurs when the stack is almost full (approximately 400 addresses) and it is fully scanned. As the stack is always present in RAM, the scanning is fast.</p> <p>Note: Once code is implemented in geth, it can be benchmarked and the cost can be re-evaluated, as it may result to be lower in practice. As a precompile call currently costs 700 gas, the cost of stack scanning has a low impact on the total cost of the precompile call (800 gas in total).</p> <p>The storage-based RPG currently costs 200 gas (because of the savings introduced in <a href="https://wg-eips.ritovision.com/1283/">EIP-1283</a>. Using the <code>Semaphore</code> precompile as a reentrancy check would currently cost 800 gas (a single call from one of the function modifiers). While this cost is higher than the traditional RPG cost and therefore discourages its use, it is still much lower than the pre-EIP-1283 cost. If a reduction in precompile call cost is implemented, then the cost of using the <code>Semaphore</code> precompile will be reduced to approximately 140 gas, below the current 200 gas consumed by a storage-based RPG. To encourage to use of the precompile-based RPG, it is suggested that this EIP is implemented together with a reduction in precompile calls cost.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change requires a hard fork and therefore all full nodes must be updated.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">contract</span><span class="z-entity z-name"> Test</span><span class="z-storage"> is</span><span class="z-entity z-name"> ReentrancyGuard2</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> second</span><span>(</span><span>)</span><span class="z-storage z-type"> external</span><span class="z-entity z-name"> nonReentrant</span><span> {</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> first</span><span>(</span><span>)</span><span class="z-storage z-type"> external</span><span class="z-entity z-name"> nonReentrant</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-entity z-name">second</span><span>(</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>A call to <code>second()</code> directly from a transaction does not revert, but a call to <code>first()</code> does revert.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Needs discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-06-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Tomasz Kajetan Stanczakhttps://github.com/tkstanczak Eric Marti Hayneshttps://github.com/ericmartihaynes Josh Klopfensteinhttps://github.com/joshklop Abhimanyu Naghttps://github.com/AbhiMan1601 https://wg-eips.ritovision.com/5133/

Delays the difficulty bomb by a further 700000 blocks, to the middle of September 2022.

<h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLOCK_NUMBER</code> the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 11,400,000 blocks later than the actual block number.</p> <h2 id="motivation">Motivation</h2> <p>To avoid network degradation due to a premature activation of the difficulty bomb.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>fake_block_number</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">0</span><span>,</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> 11_400_000</span><span>)</span><span class="z-keyword"> if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_BLOCK_NUMBER</span><span class="z-keyword"> else</span><span> block</span><span>.</span><span>number</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The following script predicts the bomb will go off at block 15530314, which is expected to be mined around mid-September.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">import</span><span> math</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> predict_bomb_block</span><span>(</span><span class="z-variable z-parameter z-function">current_difficulty</span><span>,</span><span class="z-variable z-parameter z-function"> diff_adjust_coeff</span><span>,</span><span class="z-variable z-parameter z-function"> block_adjustment</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span class="z-string"> Predicts the block number at which the difficulty bomb will become noticeable.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-string"> current_difficulty: the current difficulty</span></span> <span class="giallo-l"><span class="z-string"> diff_adjust_coeff: intuitively, the percent increase in work that miners have to exert to find a PoW</span></span> <span class="giallo-l"><span class="z-string"> block_adjustment: the number of blocks to delay the bomb by</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> round</span><span>(</span><span>block_adjustment</span><span class="z-keyword"> +</span><span class="z-constant"> 100000</span><span class="z-keyword"> *</span><span> (</span><span class="z-constant">2</span><span class="z-keyword"> +</span><span> math</span><span>.</span><span>log2</span><span>(</span><span>diff_adjust_coeff</span><span class="z-keyword"> *</span><span> current_difficulty</span><span class="z-keyword"> //</span><span class="z-constant"> 2048</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> current_difficulty = 13891609586928851 (Jun 01, 2022)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> diff_adjust_coeff = 0.1 (historically, the bomb is noticeable when the coefficient is &gt;= 0.1)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> block_adjustment = 11400000</span></span> <span class="giallo-l"><span class="z-support">print</span><span>(</span><span>predict_bomb_block</span><span>(</span><span class="z-constant">13891609586928851</span><span>,</span><span class="z-constant"> 0.1</span><span>,</span><span class="z-constant"> 11400000</span><span>)</span><span>)</span></span></code></pre> <p>Precise increases in block times are very difficult to predict (especially after the bomb is noticeable). However, based on past manifestations of the bomb, we can anticipate 0.1s delays by mid-September and 0.6-1.2s delays by early October.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known backward compatibility issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Misjudging the effects of the difficulty can mean longer blocktimes than anticipated until a hardfork is released. Wild shifts in difficulty can affect this number severely. Also, gradual changes in blocktimes due to longer-term adjustments in difficulty can affect the timing of difficulty bomb epochs. This affects the usability of the network but unlikely to have security ramifications.</p> <p>In this specific instance, it is possible that the network hashrate drops considerably before The Merge, which could accelerate the timeline by which the bomb is felt in block times. The offset value chosen aims to take this into account.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-05-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Zainan Victor Zhouhttps://github.com/xinbenlv Nick Johnsonhttps://github.com/Arachnid Konrad Feldmeierkonrad@brainbot.com https://wg-eips.ritovision.com/5081/

This EIP adds a new transaction type of that includes expiration with a blocknum

<h2 id="abstract">Abstract</h2> <p>This EIP adds a new transaction type of that includes expiration with a blocknum.</p> <h2 id="motivation">Motivation</h2> <p>When a user sends a transaction <code>tx0</code> with a low gas price, sometimes it might not be high enough to be executed. A common resolution is for the user to submit the transaction again with the same nonce and higher gas price.</p> <p>That previous <code>tx0</code> can theoretically be included in any time in the future unless a <code>tx</code> with the exact same nonce is already executed.</p> <p>When network is congested, gas price are high, for critical transactions user might try gas price that is much higher than an average day. This cause the <code>tx0</code> choice might be very easy to executed in the average day.</p> <p>If user already uses a <code>tx1</code> with different nonce or from another account to execute the intended transaction, there is currently no clean way to cancel it, except for signing a new <code>tx0'</code> that shares the same nonce but with higher gas fee hoping that it will execute to <em>preempt</em>- than <code>tx0</code>.</p> <p>Given <code>tx0</code> was already high gas price, the current way of <em>preempting</em> <code>tx0</code> could be both unreliable and very costly.</p> <p>TODO(@xinbenlv): to include in the motivation:</p> <ul> <li> <p>Expiring transactions are transactions that have low time preference, but can easily become invalid in the future. For example, you may want to do a swap on an AMM but you don't want to pay a very high fee for it so you set the max fee to a low number. However, your transaction will almost certainly fail if it takes longer than a couple minutes to be mined. In this scenario, you would rather fail cheaply if your transaction doesn't get included quickly.</p> </li> <li> <p>Similarly, there are situations where there is a limited window of availability of some asset and if your transaction doesn't mine within that period you know with certainty that it will fail. In these cases, it would be nice to be able to express that to the system and not waste unnecessary resources just to have the transaction fail.</p> </li> </ul> <h2 id="specification">Specification</h2> <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code> = <code>TBD</code></li> <li><code>CHAIN_ID</code> = <code>TBD</code></li> <li><code>TX_TYPE</code> = TBD, &gt; 0x02 (<a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>)</li> </ul> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> = <code>TX_TYPE(TBD)</code>.</p> <p>The intrinsic cost of the new transaction is inherited from <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, specifically <code>21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([chain_id, expire_by, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])</span></span></code></pre> <p>The definition of <code>expire_by</code> is a block number the latest possible block to execute this transaction. Any block with a block number <code>block_num &gt; expire_by</code> MUST NOT execute this transaction.</p> <p>The definitions of all other fields share the same meaning with <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a></p> <p>The <code>signature_y_parity, signature_r, signature_s</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(0x02 || rlp([chain_id, expire_by, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list]))</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <h2 id="rationale">Rationale</h2> <p>TODO</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <ol> <li> <p>If <code>current_block_num</code> is available, client MUST drop and stop propagating/broadcasting any transactions that has a <code>transaction_type == TX_TYPE</code> AND <code>current_block_num &gt; expire_by</code></p> </li> <li> <p>It is suggested but not required that a <code>currentBlockNum</code> SHOULD be made available to client. Any client doing PoW calculation on blocks expire tx or propagating such are essentially penalized for wasting of work, mitigating possible denial of service attack.</p> </li> <li> <p>It is suggested but not required that client SHOULD introduce a <code>gossip_ttl</code> in unit of block_num as a safe net so that it only propagate a tx if <code>current_block_num + gossip_ttl &lt;= expire_by</code>. Backward compatibility: for nodes that doesn't have <code>current_block_num</code> or <code>gossip_ttl</code> available, they should be presumed to be <code>0</code>.</p> </li> <li> <p>It is suggested by not required that any propagating client SHOULD properly deduct the <code>gossip_ttl</code> based on the network environment it sees fit.</p> </li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-04-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mudit Guptahttps://github.com/maxsam4 https://wg-eips.ritovision.com/5065/

Instruction for just transferring ether without transferring the flow of execution

<h2 id="abstract">Abstract</h2> <p>Add a new instruction that transfers ether to a destination address without handing over the flow of execution to it. It should work similarly to how <code>SELFDESTRUCT (0xFF)</code> transfers ether to the destination without making a call to it.</p> <h2 id="motivation">Motivation</h2> <p>From an architectural point of view, execution flow should never be handed over to an untrusted contract. Ethereum currently does not have any ideal way to transfer ether without transferring the flow of execution. People have come up with reentrancy guards and similar solutions to prevent some types of attacks but it's not an ideal solution. The only way to transfer ether from smart contracts without triggering a call is to create a dummy contract, send the precise amount of ether to it and then call <code>SELFDESTRUCT (0xFF)</code> from it.</p> <h2 id="specification">Specification</h2> <p>Introduce a new instruction, <code>AIRDROP</code> (<code>0xFG</code>) that transfers ether to the destination without making a call to it.</p> <h3 id="stack-input">Stack input</h3> <p>address: the account to send ether to. value: value in wei to send to the account.</p> <h3 id="gas">Gas</h3> <p>The total gas cost should be the sum of a static cost + address_access_cost + value_to_empty_account_cost.</p> <ul> <li>Static cost: 6700</li> <li>Dynamic cost: <ol> <li>address_access_cost: If the target is not in <code>accessed_addresses</code>, charge <code>COLD_ACCOUNT_ACCESS_COST</code> gas, and add the address to <code>accessed_addresses</code>. Otherwise, charge <code>WARM_STORAGE_READ_COST</code> gas. Currently, <code>COLD_ACCOUNT_ACCESS_COST</code> is 2600 while <code>WARM_STORAGE_READ_COST</code> is 100.</li> <li>value_to_empty_account_cost: If value is not 0 and the address given points to an empty account, then value_to_empty_account_cost is the account creation gas cost which currently is 25000. An account is empty if its balance is 0, its nonce is 0 and it has no code.</li> </ol> </li> </ul> <h2 id="rationale">Rationale</h2> <p>This behavior is already possible by deploying a new contract that does <code>SELFDESTRUCT (0xFF)</code> but it is prohibitively expensive. In most scenarios, the contract author only wants to transfer ether rather than transferring control of the execution. ERC20 can be used as a case study for this where most users transfer funds without a post-transfer hook.</p> <p>This instruction allows contracts to safely pass ether to an untrusted address without worrying about reentrancy or other malicious things an untrusted contract can do on.</p> <p>The static gas cost is derived by subtracting the gas stipend (2300) from the positive_value_cost of <code>CALL (0xF1)</code> opcode which is currently set to 9000.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known issues as this is a new instruction that does not affect any old instructions and does not break any valid assumptions since it make not anything impossible possible.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="security-considerations">Security Considerations</h2> <p>No known security risks.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a rel="external" href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p> 2022-04-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Qi Zhouhttps://github.com/qizhou https://wg-eips.ritovision.com/5027/

Change the limit on contract size from 24576 to infinity

<h2 id="abstract">Abstract</h2> <p>Remove the limit on the contract code size, i.e., only limit the contract code size by block gas limit, with minimal changes to existing code and proper gas metering adjustment to avoid possible attacks.</p> <h2 id="motivation">Motivation</h2> <p>The motivation is to remove the limit on the code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts.</p> <p>With the dramatic growth of dApplications, the functionalities of smart contracts are becoming more and more complicated, and thus, the sizes of newly developed contracts are steadily increasing. As a result, we are facing more and more issues with the 24576-bytes contract size limit. Although several techniques such as splitting a large contract into several sub-contracts can alleviate the issue, these techniques inevitably increase the burden of developing/deploying/maintaining smart contracts.</p> <p>The proposal implements a solution to remove the existing 24576-bytes limit of the code size. Further, the proposal aims to minimize the changes in the client implementation (e.g., Geth) with</p> <ul> <li>proper gas metering to avoid abusing the node resources for contract-related opcodes, i.e, <code>CODESIZE (0x38)/CODECOPY (0x39)/EXTCODESIZE (0x3B)/EXTCODECOPY (0x3C)/EXTCODEHASH (0x3F)/DELEGATECALL (0xF4)/CALL (0xF1)/CALLCODE (0xF2)/STATICCALL (0xFA)/CREATE (0xF0)/CREATE2 (0xF5)</code>; and</li> <li>no change to the existing structure of the Ethereum state.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLKNUM</code></td><td>TBD</td></tr> <tr><td><code>CODE_SIZE_UNIT</code></td><td>24576</td></tr> <tr><td><code>COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT</code></td><td>2600</td></tr> <tr><td><code>CREATE_DATA_GAS</code></td><td>200</td></tr> </tbody></table> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, the contract creation initialization can return data with any length, but the contract-related opcodes will take extra gas as defined below:</p> <ul> <li> <p>For <code>CODESIZE/CODECOPY/EXTCODESIZE/EXTCODEHASH</code>, the gas is unchanged.</p> </li> <li> <p>For CREATE/CREATE2, if the newly created contract size &gt; <code>CODE_SIZE_UNIT</code>, the opcodes will take extra write gas as</p> </li> </ul> <p><code>(CODE_SIZE - CODE_SIZE_UNIT) * CREATE_DATA_GAS</code>.</p> <ul> <li>For <code>EXTCODECOPY/CALL/CALLCODE/DELEGATECALL/STATICCALL</code>, if the contract code size &gt; <code>CODE_SIZE_UNIT</code>, then the opcodes will take extra gas as</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(CODE_SIZE - 1) // CODE_SIZE_UNIT * COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT</span></span></code></pre> <p>if the contract is not in <code>accessed_code_in_addresses</code> or <code>0</code> if the contract is in <code>accessed_code_in_addresses</code>, where <code>//</code> is the integer divide operator, and <code>accessed_code_in_addresses: Set[Address]</code> is a transaction-context-wide set similar to <code>access_addresses</code> and <code>accessed_storage_keys</code>.</p> <p>When a transaction execution begins, <code>accessed_code_in_addresses</code> will include <code>tx.sender</code>, <code>tx.to</code>, and all precompiles.</p> <p>When <code>CREATE/CREATE2/EXTCODECOPY/CALL/CALLCODE/DELEGATECALL/STATICCALL</code> is called, immediately add the address to <code>accessed_code_in_addresses</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-metering">Gas Metering</h3> <p>The goal is to measure the CPU/IO cost of the contract read/write operations reusing existing gas metering so that the resources will not be abused.</p> <ul> <li> <p>For code-size-related opcodes (<code>CODESIZE</code>/<code>EXTCODESIZE</code>), we would expect the client to implement a mapping from the hash of code to the size, so reading the code size of a large contract should still be O(1).</p> </li> <li> <p>For <code>CODECOPY</code>, the data is already loaded in memory (as part of <code>CALL/CALLCODE/DELEGATECALL/STATICCALL</code>), so we do not charge extra gas.</p> </li> <li> <p>For <code>EXTCODEHASH</code>, the value is already in the account, so we do not charge extra gas.</p> </li> <li> <p>For <code>EXTCODECOPY/CALL/CALLCODE/DELEGATECALL/STATICCALL</code>, since it will read extra data from the database, we will additionally charge <code>COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT</code> per extra <code>CODE_SIZE_UNIT</code>.</p> </li> <li> <p>For <code>CREATE/CREATE2</code>, since it will create extra data to the database, we will additionally charge <code>CREATE_DATA_GAS</code> per extra bytes.</p> </li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>All existing contracts will not be impacted by the proposal.</p> <p>Only contracts deployed before <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> could possibly be longer than the current max code size, and the reference implementation was able to successfully import all blocks before that fork.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>The reference implementation on Geth is available at <a href="https://wg-eips.ritovision.com/5027/./assets/0001-unlimit-code-size.patch">0001-unlimit-code-size.patch</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Greenhttps://github.com/greenlucid https://wg-eips.ritovision.com/5022/ <h3 id="abstract">Abstract</h3> <p>Increase the price of the SSTORE opcode from <code>20_000</code> gas to <code>40_000</code> gas when the original slot is zero and the resultant slot is non-zero.</p> <h3 id="motivation">Motivation</h3> <p>The cost of creating a piece of new state increases as state is larger. However, the price for creating every new storage slot has not increased. All resources are merged into the same pricing mechanism. If the price for creating new storage slots is fixed, then it needs to be manually changed.</p> <p>One of the main reasons for not increasing gas limit is the increase of state. In that regard, because the cost of creating storage is higher than its price, all the users of all the other opcodes are subsidizing the creation of state. If state creation was more precisely priced, raising gas limit would be more feasible, and would benefit the users.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-not-also-raise-the-cost-of-non-zero-to-non-zero">Why not also raise the cost of non-zero to non-zero?</h3> <p>Rewriting storage does not affect state growth, which is the main issue this EIP is addressing. Rewriting storage may also be underpriced. Increasing the price of state growth will, at least, incentivize developers to reuse storage instead.</p> <h3 id="why-not-also-increase-the-gas-refund-from-setting-non-zero-to-zero">Why not also increase the gas refund from setting non-zero to zero?</h3> <p>More discussion is needed on this.</p> <h3 id="why-not-a-better-state-solution">Why not a better state solution?</h3> <p>Whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. So, it is desirable to patch pricing for the short term. Opcode repricing has been done before, so it should not impose a large development time investment for clients.</p> <h3 id="why-was-that-specific-amount-chosen">Why was that specific amount chosen?</h3> <p>The current pricing was made off a naive approach of benchmarking opcodes in a laptop. Not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. This price is closer to what the naive original benchmark should have been. It could go higher, but that may be too disruptive.</p> <h3 id="is-this-too-disruptive">Is this too disruptive?</h3> <p>This change will severely impact the gas cost of many applications. The network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network.</p> <h3 id="specification">Specification</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> <tr><td><code>NEW_STORAGE_PRICE</code></td><td><code>40_000</code></td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, a new gas schedule applies. Make <code>SSTORE_SET_GAS</code>, the price when a slot is set from zero to non-zero, equal <code>NEW_STORAGE_PRICE</code>. All other costs remain the same.</p> <h3 id="backwards-compatibility">Backwards compatibility</h3> <p>Contracts that depend on hardcoded gas costs will break if they create state.</p> <p>It is a gas schedule change, so transactions from an epoch before FORK_BLOCK should be treated with previous gas costs.</p> <h2 id="implementation">Implementation</h2> <p>https://github.com/ethereum/go-ethereum/pull/24725</p> <h2 id="security-considerations">Security considerations</h2> <p>TODO</p> 2022-03-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dan Finlayhttps://github.com/danfinlay Sam Wilsonhttps://github.com/SamWilsn https://wg-eips.ritovision.com/5003/

Allow migrating away from ECDSA by deploying code in place of an externally owned account.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new opcode, <code>AUTHUSURP</code>, which deploys code at an <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> authorized address. For externally owned accounts (EOAs), together with <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a>, this effectively revokes the original signing key's authority.</p> <h2 id="motivation">Motivation</h2> <p>EOAs currently hold a significant amount of user-controlled value on Ethereum blockchains, but are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one's own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.</p> <p>New users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-layer account abstraction (like <a href="https://wg-eips.ritovision.com/4337/">EIP-4337</a>), but these would neglect the vast majority of existing Ethereum users' accounts. These users exist today, and they also need a path to achieving their security goals.</p> <p>Those added benefits would mostly come along with EIP-3074 itself, but with one significant shortcoming: the original signing key has ultimate authority for the account. While an EOA could delegate its authority to some <em>additional</em> contract, the key itself would linger, continuing to provide an attack vector, and a constantly horrifying question lingering: have I been leaked? In other words, EIP-3074 can only grant authority to additional actors, but never revoke it.</p> <p>Today's EOAs have no option to rotate their keys. A leaked private key (either through phishing, or accidental access) cannot be revoked. A prudent user concerned about their key security might migrate to a new secret recovery phrase but at best this requires a transaction per asset (making it extremely expensive), and at worst, some powers (like hard-coded owners in a smart contract) might not be transferable at all.</p> <p>We know that EOAs cannot provide ideal user experience or safety, and there is a desire in the community to change the norm to contract-based accounts, but if that transition is designed without regard for the vast majority of users today—for whom Ethereum has always meant EOAs—we will be continually struggling against the need to support both of these userbases. This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.</p> <p>This proposal combines well with, but is distinct from, <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a>, which provides opcodes that could enable any externally owned account (EOA) to delegate its signing authority to an arbitrary smart contract. It allows an EOA to authorize a contract account to act on its behalf <em>without forgoing its own powers</em>, while this EIP provides a final migration path off the EOA's original signing key.</p> <h2 id="specification">Specification</h2> <p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p> <h3 id="conventions">Conventions</h3> <ul> <li><strong><code>top - N</code></strong> - the <code>N</code>th most recently pushed value on the EVM stack, where <code>top - 0</code> is the most recent.</li> <li><strong>invalid execution</strong> - execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump).</li> <li><strong>empty account</strong> - account where its balance is 0, its nonce is 0, and it has no code.</li> </ul> <h3 id="authusurp-0xf8"><code>AUTHUSURP</code> (<code>0xf8</code>)</h3> <p>A new opcode <code>AUTHUSURP</code> shall be created at <code>0xf8</code>. It shall take two stack elements and return one stack element.</p> <h4 id="input">Input</h4> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>offset</code></td></tr> <tr><td><code>top - 1</code></td><td><code>length</code></td></tr> </tbody></table> <h4 id="output">Output</h4> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>address</code></td></tr> </tbody></table> <h4 id="behavior">Behavior</h4> <p><code>AUTHUSURP</code> behaves identically to <code>CREATE</code> (<code>0xf0</code>), except as described below:</p> <ul> <li>If <code>authorized</code> (as defined in EIP-3074) is unset, execution is invalid.</li> <li>If <code>authorized</code> points to an empty account, then <code>static_gas</code> remains 32,000. Otherwise, <code>static_gas</code> shall be 7,000.</li> <li><code>AUTHUSURP</code> does not check the nonce of the <code>authorized</code> account.</li> <li>The initcode runs at the address <code>authorized</code>.</li> <li>If the initcode returns no bytes, its execution frame must be reverted, and <code>AUTHUSURP</code> returns zero.</li> <li>After executing the initcode, but before the returned code is deployed, if the account's code is non-empty, the initcode's execution frame must be reverted, and <code>AUTHUSURP</code> returns zero.</li> <li>The code is deployed into the account with the address <code>authorized</code>.</li> </ul> <h2 id="rationale">Rationale</h2> <p><code>AUTHUSURP</code> does not check the nonce of the <code>authorized</code> account because it must work with accounts that have previously sent transactions.</p> <p>When using <code>AUTHUSURP</code>, if the initcode were to deploy a zero-length contract, there would be no way to prevent using <code>AUTHUSURP</code> again later.</p> <p>The account's code must be checked immediately before deploying to catch the situation where the initcode attempts to <code>AUTHUSURP</code> at the same address. This is unnecessary with other deployment instructions because they increment and check the account's nonce.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>AUTHUSURP</code> with EIP-3607 revokes the authority of the original ECDSA signature to send transactions from the account. This is completely new behavior, although it is somewhat similar to the <code>CREATE2</code> opcode.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Contracts using ECDSA signatures outside of transactions will not be aware that the usurped account is no longer controlled by a private key. This means that, for example, the private key will <em>always</em> have access to the <code>permit</code> function on token contracts. This can—and should—be mitigated by modifying the <code>ecrecover</code> pre-compiled contract.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-03-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Harikrishnan Mulackalhttps://github.com/hrkrshnn Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/5000/

Introduce a new instruction to perform x * y / z in 512-bit precision

<h2 id="abstract">Abstract</h2> <p>Introduce a new instruction, <code>MULDIV(x, y, z)</code>, to perform <code>((x * y) / z) % 2**256</code> in 512-bit precision. <code>z = 0</code> is a special case for <code>(x * y) / 2**256</code>.</p> <h2 id="motivation">Motivation</h2> <p>Fixed point operations in high level languages are very commonly used on Ethereum, especially in the domain of financial applications.</p> <p>While fixed point addition and subtraction can be done with merely <code>add</code> and <code>sub</code> respectively, being able to efficiently do fixedpoint multiplication and division is a very sought after feature. A commonly used workaround relies on a <code>mulmod</code>-based, rather complex implementation (taking around 50 instructions, excluding stack manipulation). This instruction reduces that to a single opcode.</p> <p>A secondary use case is likely in cryptographic applications, where the <code>muldiv</code> instruction allows full precision 256x256-&gt;512 multiplication. <code>mul(x y)</code> (or <code>muldiv(x, y, 1)</code>) computes the lower order 256 bits and <code>muldiv(x, y, 0)</code> computes the higher order 256 bits.</p> <p>Finally we aimed to provide an instruction which can be efficiently used both in <em>checked</em> and <em>unchecked arithmetic</em> use cases. By <em>checked</em> we mean to abort on conditions including division-by-zero and wrapping behaviour.</p> <h2 id="specification">Specification</h2> <p>A new instruction is introduced: <code>MULDIV</code> (<code>0x1e</code>).</p> <ul> <li>Pops 3 values from the stack, first <code>x</code>, then <code>y</code> and <code>z</code>.</li> <li>If <code>z == 0</code>, <code>r = (uint512(x) * y) / 2**256</code>.</li> <li>Otherwise <code>r = (uint512(x) * y / z) % 2**256</code>, where the intermediate calculation is performed with 512-bit precision.</li> <li>Pushes <code>r</code> on the stack.</li> </ul> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> operations `*` and `//` are done in 512 bit precision</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> muldiv</span><span>(</span><span class="z-variable z-parameter z-function">x</span><span>,</span><span class="z-variable z-parameter z-function"> y</span><span>,</span><span class="z-variable z-parameter z-function"> z</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> z</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>x</span><span class="z-keyword"> *</span><span> y</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span class="z-constant">2</span><span class="z-keyword">**</span><span class="z-constant">256</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>(</span><span>x</span><span class="z-keyword"> *</span><span> y</span><span>)</span><span class="z-keyword"> //</span><span> z</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span class="z-constant">2</span><span class="z-keyword">**</span><span class="z-constant">256</span><span>)</span></span></code></pre> <p>The cost of the instruction is 8 gas (aka <code>mid</code>), the same as for <code>addmod</code> and <code>mulmod</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="the-special-0-case">The special 0 case</h3> <p>All the arithmetic instructions in EVM handle division or modulo 0 specially: the instructions return 0. We have decided to break consistency in order to provide a flexible opcode, which can be used to detect wrapping behaviour.</p> <p>Alternate options include:</p> <ul> <li>Returning a flag for wrapping</li> <li>Returning two stack items, higher and lower order bits</li> <li>Compute the higher order 256 bits in EVM:</li> </ul> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-comment">///</span><span class="z-comment"> Returns `hi` such that `x × y = hi × 2**256 + mul(x, y)`</span></span> <span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> hob</span><span>(</span><span class="z-support">uint</span><span class="z-variable"> x</span><span>,</span><span class="z-support"> uint</span><span class="z-variable"> y</span><span>)</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">uint</span><span class="z-variable"> hi</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint</span><span> uint_max </span><span class="z-keyword">=</span><span class="z-variable z-language"> type</span><span>(</span><span class="z-support">uint</span><span>)</span><span>.</span><span>max</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> assembly</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> let</span><span> lo </span><span class="z-keyword">:=</span><span class="z-entity z-name"> mul</span><span>(</span><span>x</span><span>,</span><span> y</span><span>)</span></span> <span class="giallo-l"><span class="z-storage z-type"> let</span><span> mm </span><span class="z-keyword">:=</span><span class="z-support"> mulmod</span><span>(</span><span>x</span><span>,</span><span> y</span><span>,</span><span> uint_max</span><span>)</span></span> <span class="giallo-l"><span> hi </span><span class="z-keyword">:=</span><span class="z-entity z-name"> sub</span><span>(</span><span class="z-entity z-name">sub</span><span>(</span><span>mm</span><span>,</span><span> lo</span><span>)</span><span>,</span><span class="z-entity z-name"> lt</span><span>(</span><span>mm</span><span>,</span><span> lo</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>While this feature is clever and useful, callers must be aware that unlike other EVM instructions, passing 0 will have a vastly different behaviour.</p> <h3 id="argument-ordering">Argument ordering</h3> <p>The order of arguments matches <code>addmod</code> and <code>mulmod</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a new instruction not present prior.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>MULDIV</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>MULDIV</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000de0b6b3a7640000</span></span> <span class="giallo-l"><span>PUSH 0x000000000000000000000000000000000000000000000000016345785d8a0000</span></span> <span class="giallo-l"><span>PUSH 0x00000000000000000000000000000000000000000000d3c21bcecceda1000000</span></span> <span class="giallo-l"><span>MULDIV</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x00000000000000000000000000000000000000000000152d02c7e14af6800000</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-03-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gavin Johnhttps://github.com/Pandapip1 Zainan Victor Zhouhttps://github.com/xinbenlv Sam Wilsonhttps://github.com/SamWilsn Jochem Brouwerhttps://github.com/jochem-brouwer Charles Cooperhttps://github.com/charles-cooper https://wg-eips.ritovision.com/5920/

Introduces a new opcode, PAY, to send ether to an address without calling any of its functions

<h2 id="abstract">Abstract</h2> <p>This EIP introduces a new opcode, <code>PAY</code>, taking two stack parameters, <code>addr</code> and <code>val</code>, that transfers <code>val</code> wei to the address <code>addr</code> without calling any of its functions.</p> <h2 id="motivation">Motivation</h2> <p>Currently, to send ether to an address requires you to call into that address, which transfers execution context to that address, which creates several issues:</p> <ul> <li>First of all, it opens a reentrancy attack vector, as the recipient can call back into the sender. More generally, the recipient can unilaterally execute arbitrary state changes, limited only by the gas forwarded, which is not desirable from the point of view of the sender. <ul> <li>In practice, when calling into another account and sending ether, 2300 gas (the "gas stipend") is always available "for free" in the newly created call frame. Although it is currently not possible to make storage state changes with the 2300 gas stipend (see the last minute rejection of <a href="https://wg-eips.ritovision.com/1283/">EIP-1283</a> from Constantinople to be replaced with the "gas stipend safe" <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> version in Istanbul), it is possible to do this with transient storage (<a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a>). This is a security risk where potentially the transient storage gets changed unintentionally. The goal is to send ether, and not have to consider these potential unintuitive security problems.</li> </ul> </li> <li>Secondly, it opens a DoS vector. Contracts wanting to send ether must be cognizant of the possibility that the recipient will run out of gas or revert.</li> <li>Future potential call-like opcodes may not provide a way to restrict the amount of gas being forwarded to the recipient, so the meager mitigation against unintended side effects in use today (gas limit) is not guaranteed to be available.</li> <li>The <code>CALL</code> and <code>EXTCALL</code> opcodes will execute code on the recipient, which is unintended when wanting to send ether and which could lead to unintentional operations. The code execution also has to be paid for in gas, even when the intention is to only send ether, which is thus an unnecessary waste of gas.</li> <li>Finally, <a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> allows to delegate externally owned accounts (EOAs) to other accounts, which breaks the invariant that EOAs cannot contain code. Therefore, calling such EOA with the intention to send ether will thus also execute code and cost unnecessary gas.</li> </ul> <p>Having a dedicated opcode for ether transfers solves all of these issues, and would be a useful addition to the EVM.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Constant</th><th>Definition</th></tr></thead><tbody> <tr><td><code>WARM_STORAGE_READ_COST</code></td><td><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td><code>COLD_ACCOUNT_ACCESS_COST</code></td><td><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a></td></tr> <tr><td><code>GAS_NEW_ACCOUNT</code></td><td><a rel="external" href="https://github.com/ethereum/execution-specs/blob/4d953035fb0cceda7cf21d71b2ab7a9a6f4632f0/src/ethereum/frontier/vm/gas.py#L52">EELS</a></td></tr> <tr><td><code>GAS_CALL_VALUE</code></td><td><a rel="external" href="https://github.com/ethereum/execution-specs/blob/4d953035fb0cceda7cf21d71b2ab7a9a6f4632f0/src/ethereum/frontier/vm/gas.py#L53">EELS</a></td></tr> </tbody></table> <h3 id="behavior">Behavior</h3> <p>A new opcode is introduced: <code>PAY</code> (<code>0xfc</code>), which:</p> <ul> <li>Halt with exceptional failure if the current frame is static, as defined in <a href="https://wg-eips.ritovision.com/214/">EIP-214</a>.</li> <li>Pops two values from the stack: <code>addr</code> then <code>val</code>.</li> <li>Exceptionally halts if <code>addr</code> has any of the high 12 bytes set to a non-zero value (i.e. it does not contain a 20-byte address).</li> <li>Charges the gas cost detailed below.</li> <li>Marks <code>addr</code> as warm (adding <code>addr</code> to <code>accessed_addresses</code>).</li> <li>Transfers <code>val</code> wei from the current address to the address <code>addr</code>, only if the current address has a balance greater than or equal to <code>val</code>.</li> <li>Push <code>1</code> on the stack if the <code>PAY</code> operation was successful, or <code>0</code> if it failed. <ul> <li>Currently only insufficient balance would produce a <code>0</code> return value.</li> </ul> </li> </ul> <h3 id="gas-cost">Gas Cost</h3> <p>The gas cost for <code>PAY</code> is the sum of the following:</p> <ul> <li>Is <code>addr</code> in <code>accessed_addresses</code>? <ul> <li>If yes, <code>WARM_STORAGE_READ_COST</code>;</li> <li>Otherwise, <code>COLD_ACCOUNT_ACCESS_COST</code>.</li> </ul> </li> <li>Does <code>addr</code> exist or is <code>val</code> zero? <ul> <li>If yes to either, zero;</li> <li>Otherwise, <code>GAS_NEW_ACCOUNT</code>.</li> </ul> </li> <li>Is <code>val</code> zero? <ul> <li>If yes, zero;</li> <li>Otherwise, <code>GAS_CALL_VALUE</code>.</li> </ul> </li> </ul> <p><code>PAY</code> cannot be implemented on networks with empty accounts (see <a href="https://wg-eips.ritovision.com/7523/">EIP-7523</a>).</p> <h2 id="rationale">Rationale</h2> <h3 id="argument-order">Argument order</h3> <p>The order of arguments mimics that of <code>CALL</code>, which pops <code>addr</code> before <code>val</code>. Beyond consistency, though, this ordering aids validators pattern-matching MEV opportunities, so <code>PAY</code> always appears immediately after <code>COINBASE</code>.</p> <h3 id="halting-for-invalid-address">Halting for invalid address</h3> <p>The halting behavior is designed to allow for Address Space Extension. If the high bytes were truncated, as in <code>CALL</code>, contracts could depend on the truncating behavior. If the address space were extended beyond 20 bytes, <code>PAY</code> would either not be able to target those accounts, or code expecting truncation could send ether to the wrong address.</p> <p>Because this behavior may be changed, contracts should not rely on this halting behavior and use methods designated to intentionally halt (such as the <a href="https://wg-eips.ritovision.com/141/"><code>INVALID</code></a> opcode).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change requires a hard fork.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Existing contracts should not rely on their balance being under their control, since it is already possible to send ether to an address without calling it, by using the <code>SELFDESTRUCT</code> opcode (somewhat restricted in <a href="https://wg-eips.ritovision.com/6780/">EIP-6780</a>). It is also possible to involuntarily fund an account with priority fees sent to a <code>block.coinbase</code>. However, this opcode does make this process cheaper and easier. It thus does not break an invariant.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-03-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Stokeshttps://github.com/ralexstokes Danny Ryanhttps://github.com/djrtwo https://wg-eips.ritovision.com/4895/

Support validator withdrawals from the beacon chain to the EVM via a new "system-level" operation type.

<h2 id="abstract">Abstract</h2> <p>Introduce a system-level "operation" to support validator withdrawals that are "pushed" from the beacon chain to the EVM.</p> <p>These operations create unconditional balance increases to the specified recipients.</p> <h2 id="motivation">Motivation</h2> <p>This EIP provides a way for validator withdrawals made on the beacon chain to enter into the EVM. The architecture is "push"-based, rather than "pull"-based, where withdrawals are required to be processed in the execution layer as soon as they are dequeued from the consensus layer.</p> <p>Withdrawals are represented as a new type of object in the execution payload -- an "operation" -- that separates the withdrawals feature from user-level transactions. This approach is more involved than the prior approach introducing a new transaction type but it cleanly separates this "system-level" operation from regular transactions. The separation simplifies testing (so facilitates security) by reducing interaction effects generated by mixing this system-level concern with user data.</p> <p>Moreover, this approach is more complex than "pull"-based alternatives with respect to the core protocol but does provide tighter integration of a critical feature into the protocol itself.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>constants</th><th>value</th><th>units</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td>1681338455</td><td></td></tr> </tbody></table> <p>Beginning with the execution timestamp <code>FORK_TIMESTAMP</code>, execution clients <strong>MUST</strong> introduce the following extensions to payload validation and processing:</p> <h3 id="system-level-operation-withdrawal">System-level operation: withdrawal</h3> <p>Define a new payload-level object called a <code>withdrawal</code> that describes withdrawals that have been validated at the consensus layer. <code>Withdrawal</code>s are syntactically similar to a user-level transaction but live in a different domain than user-level transactions.</p> <p><code>Withdrawal</code>s provide key information from the consensus layer:</p> <ol> <li>a monotonically increasing <code>index</code>, starting from 0, as a <code>uint64</code> value that increments by 1 per withdrawal to uniquely identify each withdrawal</li> <li>the <code>validator_index</code> of the validator, as a <code>uint64</code> value, on the consensus layer the withdrawal corresponds to</li> <li>a recipient for the withdrawn ether <code>address</code> as a 20-byte value</li> <li>a nonzero <code>amount</code> of ether given in Gwei (1e9 wei) as a <code>uint64</code> value.</li> </ol> <p><em>NOTE</em>: the <code>index</code> for each withdrawal is a global counter spanning the entire sequence of withdrawals.</p> <p><code>Withdrawal</code> objects are serialized as a RLP list according to the schema: <code>[index, validator_index, address, amount]</code>.</p> <h3 id="new-field-in-the-execution-payload-withdrawals">New field in the execution payload: withdrawals</h3> <p>The execution payload gains a new field for the <code>withdrawals</code> which is an RLP list of <code>Withdrawal</code> data.</p> <p>For example:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>withdrawal_0</span><span class="z-keyword"> =</span><span> [</span><span>index_0</span><span>,</span><span> validator_index_0</span><span>,</span><span> address_0</span><span>,</span><span> amount_0</span><span>]</span></span> <span class="giallo-l"><span>withdrawal_1</span><span class="z-keyword"> =</span><span> [</span><span>index_1</span><span>,</span><span> validator_index_1</span><span>,</span><span> address_1</span><span>,</span><span> amount_1</span><span>]</span></span> <span class="giallo-l"><span>withdrawals</span><span class="z-keyword"> =</span><span> [</span><span>withdrawal_0</span><span>,</span><span> withdrawal_1</span><span>]</span></span></code></pre> <p>This new field is encoded after the existing fields in the execution payload structure and is considered part of the execution payload's body.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>execution_payload_rlp</span><span class="z-keyword"> =</span><span> RLP</span><span>(</span><span>[</span><span>header</span><span>,</span><span> transactions</span><span>,</span><span> [</span><span>]</span><span>,</span><span> withdrawals</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>execution_payload_body_rlp</span><span class="z-keyword"> =</span><span> RLP</span><span>(</span><span>[</span><span>transactions</span><span>,</span><span> [</span><span>]</span><span>,</span><span> withdrawals</span><span>]</span><span>)</span></span></code></pre> <p>NOTE: the empty list in this schema is due to <a href="https://wg-eips.ritovision.com/3675/">EIP-3675</a> that sets the <code>ommers</code> value to a fixed constant.</p> <h3 id="new-field-in-the-execution-payload-header-withdrawals-root">New field in the execution payload header: withdrawals root</h3> <p>The execution payload header gains a new field committing to the <code>withdrawals</code> in the execution payload.</p> <p>This commitment is constructed identically to the transactions root in the existing execution payload header by inserting each withdrawal into a Merkle-Patricia trie keyed by index in the list of <code>withdrawals</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> compute_trie_root_from_indexed_data</span><span>(</span><span class="z-variable z-parameter z-function">data</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> trie</span><span class="z-keyword"> =</span><span> Trie</span><span>.</span><span class="z-keyword">from</span><span>(</span><span>[</span><span>(</span><span>i</span><span>,</span><span> obj</span><span>)</span><span class="z-keyword"> for</span><span> i</span><span>,</span><span> obj</span><span class="z-keyword"> in</span><span class="z-support"> enumerate</span><span>(</span><span>data</span><span>)</span><span>]</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> trie</span><span>.</span><span>root</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>execution_payload_header</span><span>.</span><span>withdrawals_root</span><span class="z-keyword"> =</span><span> compute_trie_root_from_indexed_data</span><span>(</span><span>execution_payload</span><span>.</span><span>withdrawals</span><span>)</span></span></code></pre> <p>The execution payload header is extended with a new field containing the 32 byte root of the trie committing to the list of withdrawals provided in a given execution payload.</p> <p>To illustrate:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>execution_payload_header_rlp</span><span class="z-keyword"> =</span><span> RLP</span><span>(</span><span>[</span></span> <span class="giallo-l"><span> parent_hash</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ommers hash</span></span> <span class="giallo-l"><span> coinbase</span><span>,</span></span> <span class="giallo-l"><span> state_root</span><span>,</span></span> <span class="giallo-l"><span> txs_root</span><span>,</span></span> <span class="giallo-l"><span> receipts_root</span><span>,</span></span> <span class="giallo-l"><span> logs_bloom</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 0</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> difficulty</span></span> <span class="giallo-l"><span> number</span><span>,</span></span> <span class="giallo-l"><span> gas_limit</span><span>,</span></span> <span class="giallo-l"><span> gas_used</span><span>,</span></span> <span class="giallo-l"><span> timestamp</span><span>,</span></span> <span class="giallo-l"><span> extradata</span><span>,</span></span> <span class="giallo-l"><span> prev_randao</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">0000000000000000</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas</span><span>,</span></span> <span class="giallo-l"><span> withdrawals_root</span><span>,</span></span> <span class="giallo-l"><span>]</span><span>)</span></span></code></pre> <p>NOTE: field names and constant value in this example reflect <a href="https://wg-eips.ritovision.com/3675/">EIP-3675</a> and <a href="https://wg-eips.ritovision.com/4399/">EIP-4399</a>. Refer to those EIPs for further information.</p> <h3 id="execution-payload-validity">Execution payload validity</h3> <p>Assuming the execution payload is well-formatted, the execution client has an additional payload validation to ensure that the <code>withdrawals_root</code> matches the expected value given the list in the payload.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">assert</span><span> execution_payload_header</span><span>.</span><span>withdrawals_root</span><span class="z-keyword"> ==</span><span> compute_trie_root_from_indexed_data</span><span>(</span><span>execution_payload</span><span>.</span><span>withdrawals</span><span>)</span></span></code></pre><h3 id="state-transition">State transition</h3> <p>The <code>withdrawals</code> in an execution payload are processed <strong>after</strong> any user-level transactions are applied.</p> <p>For each <code>withdrawal</code> in the list of <code>execution_payload.withdrawals</code>, the implementation increases the balance of the <code>address</code> specified by the <code>amount</code> given.</p> <p>Recall that the <code>amount</code> is given in units of Gwei so a conversion to units of wei must be performed when working with account balances in the execution state.</p> <p>This balance change is unconditional and <strong>MUST</strong> not fail.</p> <p>This operation has no associated gas costs.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-not-a-new-transaction-type">Why not a new transaction type?</h3> <p>This EIP suggests a new type of object -- the "withdrawal operation" -- as it has special semantics different from other existing types of EVM transactions.</p> <p>Operations are initiated by the overall system, rather than originating from end users like typical transactions.</p> <p>An entirely new type of object firewalls off generic EVM execution from this type of processing to simplify testing and security review of withdrawals.</p> <h3 id="why-no-gas-costs-for-the-withdrawal-type">Why no (gas) costs for the withdrawal type?</h3> <p>The maximum number of withdrawals that can reach the execution layer at a given time is bounded (enforced by the consensus layer) and this limit has been chosen so that any execution layer operational costs are negligible in the context of the broader payload execution.</p> <p>This bound applies to both computational cost (only a few balance updates in the state) and storage/networking cost as the additional payload footprint is kept small (current parameterizations put the additional overhead at ~1% of current average payload size).</p> <h3 id="why-only-balance-updates-no-general-evm-execution">Why only balance updates? No general EVM execution?</h3> <p>More general processing introduces the risk of failures, which complicates accounting on the beacon chain.</p> <p>This EIP suggests a route for withdrawals that provides most of the benefits for a minimum of the (complexity) cost.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Consensus-layer validation of withdrawal transactions is critical to ensure that the proper amount of ETH is withdrawn back into the execution layer. This consensus-layer to execution-layer ETH transfer does not have a current analog in the EVM and thus deserves very high security scrutiny.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Stokeshttps://github.com/ralexstokes Danny Ryanhttps://github.com/djrtwo https://wg-eips.ritovision.com/4863/

Support validator withdrawals from the beacon chain to the EVM via a new "push-style" transaction type.

<h2 id="abstract">Abstract</h2> <p>Introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718 transaction type</a> to support validator withdrawals that are "pushed" from the beacon chain to the EVM.</p> <p>Add block validations to ensure the withdrawal transactions are sound with respect to withdrawal processing on the beacon chain.</p> <h2 id="motivation">Motivation</h2> <p>This EIP provides a way for validator withdrawals made on the beacon chain to enter into the EVM. The architecture is "push"-based, rather than "pull"-based, where withdrawals are required to be processed in the execution block as soon as they are dequeued from the beacon chain.</p> <p>This approach is more involved than "pull"-based alternatives (e.g. <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> + user-space withdrawal contract) with respect to the core protocol (by providing a new transaction type with special semantics) but does provide tighter integration of a critical feature into the protocol itself.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>constants</th><th>value</th><th>units</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td>TBD</td><td></td></tr> <tr><td><code>WITHDRAWAL_TX_TYPE</code></td><td><code>0x3</code></td><td>byte</td></tr> </tbody></table> <p>Beginning with the execution timestamp <code>FORK_TIMESTAMP</code>, execution clients <strong>MUST</strong> introduce the following extensions to transaction processing and block validation:</p> <h3 id="new-transaction-type">New transaction type</h3> <p>Define a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type with <code>TransactionType</code> <code>WITHDRAWAL_TX_TYPE</code>.</p> <p>The <code>TransactionPayload</code> is an RLP-encoded list <code>RLP([index, address, amount])</code> where the <code>index</code> is a 64-bit value uniquely labeling a specific withdrawal, the <code>address</code> refers to an execution layer account and the <code>amount</code> refers to an ether value given in units of wei.</p> <p>These values are provided by the consensus layer.</p> <h3 id="block-validity">Block validity</h3> <p>If a block contains <em>any</em> transactions with <code>WITHDRAWAL_TX_TYPE</code> type, they <strong>MUST</strong> come after <strong>ALL</strong> other transactions in the block.</p> <p>If the execution client receives a block where this is not the case, it <strong>MUST</strong> consider the block invalid.</p> <h3 id="transaction-processing">Transaction processing</h3> <p>When processing a transaction with <code>WITHDRAWAL_TX_TYPE</code> type, the implementation should increase the balance of the <code>address</code> specified by the <code>WithdrawalTransaction</code> by the <code>amount</code> of wei specified.</p> <p>This balance change is unconditional and <strong>MUST</strong> not fail.</p> <p>This transaction type has no associated gas costs.</p> <p>TODO: add logs?</p> <h2 id="rationale">Rationale</h2> <h3 id="push-vs-pull-approach">Push vs pull approach</h3> <p>This push approach gives validators a small subsidy with respect to processing, in lieu of needing to buy gas via normal EVM processing that would be required for a pull-based approach.</p> <p>This style also happens automatically when the requisite conditions are met on the beacon chain which is nicer UX for validators.</p> <h3 id="why-a-new-transaction-type">Why a new transaction type?</h3> <p>This EIP suggests a new transaction type as it has special semantics different from other existing types of EVM transactions.</p> <p>An entirely new transaction type firewalls off generic EVM execution from this type of processing to simplify testing and security review of withdrawals.</p> <h3 id="why-no-gas-costs-for-new-transaction-type">Why no (gas) costs for new transaction type?</h3> <p>The maximum number of this transaction type that can reach the execution layer at a given time is bounded (enforced by the consensus layer) and this limit is kept small so that any execution layer operational costs are negligible in the context of the broader block execution.</p> <h3 id="why-only-balance-updates-no-general-evm-execution">Why only balance updates? No general EVM execution?</h3> <p>More general processing introduces the risk of failures, which complicates accounting on the beacon chain.</p> <p>This EIP suggests a route for withdrawals that provides most of the benefits for a minimum of the (complexity) cost.</p> <h3 id="why-new-block-validations">Why new block validations?</h3> <p>The beacon chain must be able to efficiently validate that the withdrawal transactions in a given execution block are the ones expected based on its own internal scheduling logic to maintain the soundness of the withdrawal mechanism.</p> <p>By requiring all withdrawal transactions to be at the back of every block where they are applicable, the algorithm to check consistency becomes a straightforward linear walk from the start of the set until a known, bounded (small) number.</p> <p>Having a simple ordering scheme like this facilitates optimizations clients may do with respect to withdrawal processing, which would be hampered if withdrawal transactions could be placed in the block freely.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Consensus-layer validation of withdrawal transactions is critical to ensure that the proper amount of ETH is withdrawn back into the execution layer. This consensus-layer to execution-layer ETH transfer does not have a current analog in the EVM and thus deserves very high security scrutiny.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad Diederik Loerakkerhttps://github.com/protolambda George Kadianakishttps://github.com/asn-d6 Matt Garnetthttps://github.com/lightclient Mofi Taiwohttps://github.com/Inphi Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/4844/

Shard Blob Transactions scale data-availability of Ethereum in a simple, forwards-compatible manner.

<h2 id="abstract">Abstract</h2> <p>Introduce a new transaction format for "blob-carrying transactions" which contain a large amount of data that cannot be accessed by EVM execution, but whose commitment can be accessed. The format is intended to be fully compatible with the format that will be used in full sharding.</p> <h2 id="motivation">Motivation</h2> <p>Rollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum. Transaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups. Rollups are significantly reducing fees for many Ethereum users: Optimism and Arbitrum frequently provide fees that are ~3-8x lower than the Ethereum base layer itself, and ZK rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer.</p> <p>However, even these fees are too expensive for many users. The long-term solution to the long-term inadequacy of rollups by themselves has always been data sharding, which would add ~16 MB per block of dedicated data space to the chain that rollups could use. However, data sharding will still take a considerable amount of time to finish implementing and deploying.</p> <p>This EIP provides a stop-gap solution until that point by implementing the <em>transaction format</em> that would be used in sharding, but not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded by all consensus nodes (but can be deleted after only a relatively short delay). Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>BLOB_TX_TYPE</code></td><td><code>Bytes1(0x03)</code></td></tr> <tr><td><code>BYTES_PER_FIELD_ELEMENT</code></td><td><code>32</code></td></tr> <tr><td><code>FIELD_ELEMENTS_PER_BLOB</code></td><td><code>4096</code></td></tr> <tr><td><code>BLS_MODULUS</code></td><td><code>52435875175126190479447740508185965837690552500527637822603658699938581184513</code></td></tr> <tr><td><code>VERSIONED_HASH_VERSION_KZG</code></td><td><code>Bytes1(0x01)</code></td></tr> <tr><td><code>POINT_EVALUATION_PRECOMPILE_ADDRESS</code></td><td><code>Bytes20(0x0A)</code></td></tr> <tr><td><code>POINT_EVALUATION_PRECOMPILE_GAS</code></td><td><code>50000</code></td></tr> <tr><td><code>MAX_BLOB_GAS_PER_BLOCK</code></td><td><code>786432</code></td></tr> <tr><td><code>TARGET_BLOB_GAS_PER_BLOCK</code></td><td><code>393216</code></td></tr> <tr><td><code>MIN_BASE_FEE_PER_BLOB_GAS</code></td><td><code>1</code></td></tr> <tr><td><code>BLOB_BASE_FEE_UPDATE_FRACTION</code></td><td><code>3338477</code></td></tr> <tr><td><code>GAS_PER_BLOB</code></td><td><code>2**17</code></td></tr> <tr><td><code>HASH_OPCODE_BYTE</code></td><td><code>Bytes1(0x49)</code></td></tr> <tr><td><code>HASH_OPCODE_GAS</code></td><td><code>3</code></td></tr> <tr><td><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/4de1d156c78b555421b72d6067c73b614ab55584/configs/mainnet.yaml#L148"><code>MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS</code></a></td><td><code>4096</code></td></tr> </tbody></table> <h3 id="type-aliases">Type aliases</h3> <table><thead><tr><th>Type</th><th>Base type</th><th>Additional checks</th></tr></thead><tbody> <tr><td><code>Blob</code></td><td><code>ByteVector[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB]</code></td><td></td></tr> <tr><td><code>VersionedHash</code></td><td><code>Bytes32</code></td><td></td></tr> <tr><td><code>KZGCommitment</code></td><td><code>Bytes48</code></td><td>Perform IETF BLS signature "KeyValidate" check but do allow the identity point</td></tr> <tr><td><code>KZGProof</code></td><td><code>Bytes48</code></td><td>Same as for <code>KZGCommitment</code></td></tr> </tbody></table> <h3 id="cryptographic-helpers">Cryptographic Helpers</h3> <p>Throughout this proposal we use cryptographic methods and classes defined in the corresponding <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb">consensus 4844 specs</a>.</p> <p>Specifically, we use the following methods from <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md"><code>polynomial-commitments.md</code></a>:</p> <ul> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_kzg_proof"><code>verify_kzg_proof()</code></a></li> <li><a rel="external" href="https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_blob_kzg_proof_batch"><code>verify_blob_kzg_proof_batch()</code></a></li> </ul> <h3 id="helpers">Helpers</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> kzg_to_versioned_hash</span><span>(</span><span class="z-variable z-parameter z-function">commitment</span><span>:</span><span> KZGCommitment</span><span>)</span><span> -&gt;</span><span> VersionedHash</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> VERSIONED_HASH_VERSION_KZG</span><span class="z-keyword"> +</span><span> sha256</span><span>(</span><span>commitment</span><span>)</span><span>[</span><span class="z-constant">1</span><span>:</span><span>]</span></span></code></pre> <p>Approximates <code>factor * e ** (numerator / denominator)</code> using Taylor expansion:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> fake_exponential</span><span>(</span><span class="z-variable z-parameter z-function">factor</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> numerator</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> denominator</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> factor</span><span class="z-keyword"> *</span><span> denominator</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> numerator_accum</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> output</span><span class="z-keyword"> +=</span><span> numerator_accum</span></span> <span class="giallo-l"><span> numerator_accum</span><span class="z-keyword"> =</span><span> (</span><span>numerator_accum</span><span class="z-keyword"> *</span><span> numerator</span><span>)</span><span class="z-keyword"> //</span><span> (</span><span>denominator</span><span class="z-keyword"> *</span><span> i</span><span>)</span></span> <span class="giallo-l"><span> i</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> output</span><span class="z-keyword"> //</span><span> denominator</span></span></code></pre><h3 id="blob-transaction">Blob transaction</h3> <p>We introduce a new type of <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction, "blob transaction", where the <code>TransactionType</code> is <code>BLOB_TX_TYPE</code> and the <code>TransactionPayload</code> is the RLP serialization of the following <code>TransactionPayloadBody</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]</span></span></code></pre> <p>The fields <code>chain_id</code>, <code>nonce</code>, <code>max_priority_fee_per_gas</code>, <code>max_fee_per_gas</code>, <code>gas_limit</code>, <code>value</code>, <code>data</code>, and <code>access_list</code> follow the same semantics as <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>.</p> <p>The field <code>to</code> deviates slightly from the semantics with the exception that it MUST NOT be <code>nil</code> and therefore must always represent a 20-byte address. This means that blob transactions cannot have the form of a create transaction.</p> <p>The field <code>max_fee_per_blob_gas</code> is a <code>uint256</code> and the field <code>blob_versioned_hashes</code> represents a list of hash outputs from <code>kzg_to_versioned_hash</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <h4 id="signature">Signature</h4> <p>The signature values <code>y_parity</code>, <code>r</code>, and <code>s</code> are calculated by constructing a secp256k1 signature over the following digest:</p> <p><code>keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes]))</code>.</p> <h3 id="header-extension">Header extension</h3> <p>The current header encoding is extended with two new 64-bit unsigned integer fields:</p> <ul> <li><code>blob_gas_used</code> is the total amount of blob gas consumed by the transactions within the block.</li> <li><code>excess_blob_gas</code> is a running total of blob gas consumed in excess of the target, prior to the block. Blocks with above-target blob gas consumption increase this value, blocks with below-target blob gas consumption decrease it (bounded at 0).</li> </ul> <p>The resulting RLP encoding of the header is therefore:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([</span></span> <span class="giallo-l"><span> parent_hash,</span></span> <span class="giallo-l"><span> 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash</span></span> <span class="giallo-l"><span> coinbase,</span></span> <span class="giallo-l"><span> state_root,</span></span> <span class="giallo-l"><span> txs_root,</span></span> <span class="giallo-l"><span> receipts_root,</span></span> <span class="giallo-l"><span> logs_bloom,</span></span> <span class="giallo-l"><span> 0, # difficulty</span></span> <span class="giallo-l"><span> number,</span></span> <span class="giallo-l"><span> gas_limit,</span></span> <span class="giallo-l"><span> gas_used,</span></span> <span class="giallo-l"><span> timestamp,</span></span> <span class="giallo-l"><span> extradata,</span></span> <span class="giallo-l"><span> prev_randao,</span></span> <span class="giallo-l"><span> 0x0000000000000000, # nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas,</span></span> <span class="giallo-l"><span> withdrawals_root,</span></span> <span class="giallo-l"><span> blob_gas_used,</span></span> <span class="giallo-l"><span> excess_blob_gas,</span></span> <span class="giallo-l"><span>])</span></span></code></pre> <p>The value of <code>excess_blob_gas</code> can be calculated using the parent header.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_excess_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">parent</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> &lt;</span><span class="z-constant"> TARGET_BLOB_GAS_PER_BLOCK</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> parent</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> +</span><span> parent</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> -</span><span class="z-constant"> TARGET_BLOB_GAS_PER_BLOCK</span></span></code></pre> <p>For the first post-fork block, both <code>parent.blob_gas_used</code> and <code>parent.excess_blob_gas</code> are evaluated as <code>0</code>.</p> <h3 id="gas-accounting">Gas accounting</h3> <p>We introduce blob gas as a new type of gas. It is independent of normal gas and follows its own targeting rule, similar to EIP-1559. We use the <code>excess_blob_gas</code> header field to store persistent data needed to compute the blob gas base fee. For now, only blobs are priced in blob gas.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> calc_blob_fee</span><span>(</span><span class="z-variable z-parameter z-function">header</span><span>:</span><span> Header</span><span>,</span><span class="z-variable z-parameter z-function"> tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> get_total_blob_gas</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> *</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>header</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_total_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> GAS_PER_BLOB</span><span class="z-keyword"> *</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_base_fee_per_blob_gas</span><span>(</span><span class="z-variable z-parameter z-function">header</span><span>:</span><span> Header</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fake_exponential</span><span>(</span></span> <span class="giallo-l"><span class="z-constant"> MIN_BASE_FEE_PER_BLOB_GAS</span><span>,</span></span> <span class="giallo-l"><span> header</span><span>.</span><span>excess_blob_gas</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> BLOB_BASE_FEE_UPDATE_FRACTION</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>The block validity conditions are modified to include blob gas checks (see the <a href="https://wg-eips.ritovision.com/4844/#execution-layer-validation">Execution layer validation</a> section below).</p> <p>The actual <code>blob_fee</code> as calculated via <code>calc_blob_fee</code> is deducted from the sender balance before transaction execution and burned, and is not refunded in case of transaction failure.</p> <h3 id="opcode-to-get-versioned-hashes">Opcode to get versioned hashes</h3> <p>We add an instruction <code>BLOBHASH</code> (with opcode <code>HASH_OPCODE_BYTE</code>) which reads <code>index</code> from the top of the stack as big-endian <code>uint256</code>, and replaces it on the stack with <code>tx.blob_versioned_hashes[index]</code> if <code>index &lt; len(tx.blob_versioned_hashes)</code>, and otherwise with a zeroed <code>bytes32</code> value. The opcode has a gas cost of <code>HASH_OPCODE_GAS</code>.</p> <h3 id="point-evaluation-precompile">Point evaluation precompile</h3> <p>Add a precompile at <code>POINT_EVALUATION_PRECOMPILE_ADDRESS</code> that verifies a KZG proof which claims that a blob (represented by a commitment) evaluates to a given value at a given point.</p> <p>The precompile costs <code>POINT_EVALUATION_PRECOMPILE_GAS</code> and executes the following logic:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> point_evaluation_precompile</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span> Bytes</span><span>)</span><span> -&gt;</span><span> Bytes</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-string"> Verify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof.</span></span> <span class="giallo-l"><span class="z-string"> Also verify that the provided commitment matches the provided versioned_hash.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &quot;&quot;&quot;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The data is encoded as follows: versioned_hash | z | y | commitment | proof | with z and y being padded 32 byte big endian values</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 192</span></span> <span class="giallo-l"><span> versioned_hash</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span>:</span><span class="z-constant">32</span><span>]</span></span> <span class="giallo-l"><span> z</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">32</span><span>:</span><span class="z-constant">64</span><span>]</span></span> <span class="giallo-l"><span> y</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">64</span><span>:</span><span class="z-constant">96</span><span>]</span></span> <span class="giallo-l"><span> commitment</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">96</span><span>:</span><span class="z-constant">144</span><span>]</span></span> <span class="giallo-l"><span> proof</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">144</span><span>:</span><span class="z-constant">192</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify commitment matches versioned_hash</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> kzg_to_versioned_hash</span><span>(</span><span>commitment</span><span>)</span><span class="z-keyword"> ==</span><span> versioned_hash</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Verify KZG proof with z and y in big endian format</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> verify_kzg_proof</span><span>(</span><span>commitment</span><span>,</span><span> z</span><span>,</span><span> y</span><span>,</span><span> proof</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Return FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS as padded 32 byte big endian values</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> Bytes</span><span>(</span><span>U256</span><span>(</span><span class="z-constant">FIELD_ELEMENTS_PER_BLOB</span><span>)</span><span>.</span><span>to_be_bytes32</span><span>(</span><span>)</span><span class="z-keyword"> +</span><span> U256</span><span>(</span><span class="z-constant">BLS_MODULUS</span><span>)</span><span>.</span><span>to_be_bytes32</span><span>(</span><span>)</span><span>)</span></span></code></pre> <p>The precompile MUST reject non-canonical field elements (i.e. provided field elements MUST be strictly less than <code>BLS_MODULUS</code>).</p> <h3 id="consensus-layer-validation">Consensus layer validation</h3> <p>On the consensus layer the blobs are referenced, but not fully encoded, in the beacon block body. Instead of embedding the full contents in the body, the blobs are propagated separately, as "sidecars".</p> <p>This "sidecar" design provides forward compatibility for further data increases by black-boxing <code>is_data_available()</code>: with full sharding <code>is_data_available()</code> can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.</p> <p>Note that the consensus layer is tasked with persisting the blobs for data availability, the execution layer is not.</p> <p>The <code>ethereum/consensus-specs</code> repository defines the following consensus layer changes involved in this EIP:</p> <ul> <li>Beacon chain: process updated beacon blocks and ensure blobs are available.</li> <li>P2P network: gossip and sync updated beacon block types and new blob sidecars.</li> <li>Honest validator: produce beacon blocks with blobs; sign and publish the associated blob sidecars.</li> </ul> <h3 id="execution-layer-validation">Execution layer validation</h3> <p>On the execution layer, the block validity conditions are extended as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check that the excess blob gas was updated correctly</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>header</span><span>.</span><span>excess_blob_gas</span><span class="z-keyword"> ==</span><span> calc_excess_blob_gas</span><span>(</span><span>block</span><span>.</span><span>parent</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> blob_gas_used</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> tx</span><span class="z-keyword"> in</span><span> block</span><span>.</span><span>transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> modify the check for sufficient balance</span></span> <span class="giallo-l"><span> max_total_fee</span><span class="z-keyword"> =</span><span> tx</span><span>.</span><span>gas</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>max_fee_per_gas</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> get_tx_type</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span> max_total_fee</span><span class="z-keyword"> +=</span><span> get_total_blob_gas</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>max_fee_per_blob_gas</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signer</span><span>(</span><span>tx</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> &gt;=</span><span> max_total_fee</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> add validity logic specific to blob txs</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> get_tx_type</span><span>(</span><span>tx</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> BLOB_TX_TYPE</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> there must be at least one blob</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>tx</span><span>.</span><span>blob_versioned_hashes</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> all versioned blob hashes must start with VERSIONED_HASH_VERSION_KZG</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> h</span><span class="z-keyword"> in</span><span> tx</span><span>.</span><span>blob_versioned_hashes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> h</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> ==</span><span class="z-constant"> VERSIONED_HASH_VERSION_KZG</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ensure that the user was willing to at least pay the current blob base fee</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> tx</span><span>.</span><span>max_fee_per_blob_gas</span><span class="z-keyword"> &gt;=</span><span> get_base_fee_per_blob_gas</span><span>(</span><span>block</span><span>.</span><span>header</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> keep track of total blob gas spent in the block</span></span> <span class="giallo-l"><span> blob_gas_used</span><span class="z-keyword"> +=</span><span> get_total_blob_gas</span><span>(</span><span>tx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ensure the total blob gas spent is at most equal to the limit</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> blob_gas_used</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> MAX_BLOB_GAS_PER_BLOCK</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ensure blob_gas_used matches header</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>header</span><span>.</span><span>blob_gas_used</span><span class="z-keyword"> ==</span><span> blob_gas_used</span></span> <span class="giallo-l"></span></code></pre><h3 id="networking">Networking</h3> <p>Blob transactions have two network representations. During transaction gossip responses (<code>PooledTransactions</code>), the EIP-2718 <code>TransactionPayload</code> of the blob transaction is wrapped to become:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>rlp([tx_payload_body, blobs, commitments, proofs])</span></span></code></pre> <p>Each of these elements are defined as follows:</p> <ul> <li><code>tx_payload_body</code> - is the <code>TransactionPayloadBody</code> of standard EIP-2718 <a href="https://wg-eips.ritovision.com/4844/#blob-transaction">blob transaction</a></li> <li><code>blobs</code> - list of <code>Blob</code> items</li> <li><code>commitments</code> - list of <code>KZGCommitment</code> of the corresponding <code>blobs</code></li> <li><code>proofs</code> - list of <code>KZGProof</code> of the corresponding <code>blobs</code> and <code>commitments</code></li> </ul> <p>The node MUST validate <code>tx_payload_body</code> and verify the wrapped data against it. To do so, ensure that:</p> <ul> <li>There are an equal number of <code>tx_payload_body.blob_versioned_hashes</code>, <code>blobs</code>, <code>commitments</code>, and <code>proofs</code>.</li> <li>The KZG <code>commitments</code> hash to the versioned hashes, i.e. <code>kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]</code></li> <li>The KZG <code>commitments</code> match the corresponding <code>blobs</code> and <code>proofs</code>. (Note: this can be optimized using <code>verify_blob_kzg_proof_batch</code>, with a proof for a random evaluation at a point derived from the commitment and blob data for each blob)</li> </ul> <p>For body retrieval responses (<code>BlockBodies</code>), the standard EIP-2718 blob transaction <code>TransactionPayload</code> is used.</p> <p>Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced using <code>NewPooledTransactionHashes</code> messages, and can then be manually requested via <code>GetPooledTransactions</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="on-the-path-to-sharding">On the path to sharding</h3> <p>This EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification. This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot, with a separate fee market allowing fees to be very low while usage of this system is limited.</p> <p>The core goal of rollup scaling stopgaps is to provide temporary scaling relief, without imposing extra development burdens on rollups to take advantage of this relief. Today, rollups use calldata. In the future, rollups will have no choice but to use sharded data (also called "blobs") because sharded data will be much cheaper. Hence, rollups cannot avoid making a large upgrade to how they process data at least once along the way. But what we <em>can</em> do is ensure that rollups need to <em>only</em> upgrade once. This immediately implies that there are exactly two possibilities for a stopgap: (i) reducing the gas costs of existing calldata, and (ii) bringing forward the format that will be used for sharded data, but not yet actually sharding it. Previous EIPs were all a solution of category (i); this EIP is a solution of category (ii).</p> <p>The main tradeoff in designing this EIP is that of implementing more now versus having to implement more later: do we implement 25% of the work on the way to full sharding, or 50%, or 75%?</p> <p>The work that is already done in this EIP includes:</p> <ul> <li>A new transaction type, of the exact same format that will need to exist in "full sharding"</li> <li><em>All</em> of the execution-layer logic required for full sharding</li> <li><em>All</em> of the execution / consensus cross-verification logic required for full sharding</li> <li>Layer separation between <code>BeaconBlock</code> verification and data availability sampling blobs</li> <li>Most of the <code>BeaconBlock</code> logic required for full sharding</li> <li>A self-adjusting independent base fee for blobs</li> </ul> <p>The work that remains to be done to get to full sharding includes:</p> <ul> <li>A low-degree extension of the <code>commitments</code> in the consensus layer to allow 2D sampling</li> <li>An actual implementation of data availability sampling</li> <li>PBS (proposer/builder separation), to avoid requiring individual validators to process 32 MB of data in one slot</li> <li>Proof of custody or similar in-protocol requirement for each validator to verify a particular part of the sharded data in each block</li> </ul> <p>This EIP also sets the stage for longer-term protocol cleanups. For example, its (cleaner) gas base fee update rule could be applied to the primary basefee calculation.</p> <h3 id="how-rollups-would-function">How rollups would function</h3> <p>Instead of putting rollup block data in transaction calldata, rollups would expect rollup block submitters to put the data into blobs. This guarantees availability (which is what rollups need) but would be much cheaper than calldata. Rollups need data to be available once, long enough to ensure honest actors can construct the rollup state, but not forever.</p> <p>Optimistic rollups only need to actually provide the underlying data when fraud proofs are being submitted. The fraud proof can verify the transition in smaller steps, loading at most a few values of the blob at a time through calldata. For each value it would provide a KZG proof and use the point evaluation precompile to verify the value against the versioned hash that was submitted before, and then perform the fraud proof verification on that data as is done today.</p> <p>ZK rollups would provide two commitments to their transaction or state delta data: the blob commitment (which the protocol ensures points to available data) and the ZK rollup's own commitment using whatever proof system the rollup uses internally. They would use a proof of equivalence protocol, using the point evaluation precompile, to prove that the two commitments refer to the same data.</p> <h3 id="versioned-hashes-precompile-return-data">Versioned hashes &amp; precompile return data</h3> <p>We use versioned hashes (rather than commitments) as references to blobs in the execution layer to ensure forward compatibility with future changes. For example, if we need to switch to Merkle trees + STARKs for quantum-safety reasons, then we would add a new version, allowing the point evaluation precompile to work with the new format. Rollups would not have to make any EVM-level changes to how they work; sequencers would simply have to switch over to using a new transaction type at the appropriate time.</p> <p>However, the point evaluation happens inside a finite field, and it is only well defined if the field modulus is known. Smart contracts could contain a table mapping the commitment version to a modulus, but this would not allow smart contract to take into account future upgrades to a modulus that is not known yet. By allowing access to the modulus inside the EVM, the smart contract can be built so that it can use future commitments and proofs, without ever needing an upgrade.</p> <p>In the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also "free" in that the caller can just ignore this part of the return value without incurring an extra cost -- systems that remain upgradable for the foreseeable future will likely use this route for now.</p> <h3 id="base-fee-per-blob-gas-update-rule">Base fee per blob gas update rule</h3> <p>The base fee per blob gas update rule is intended to approximate the formula <code>base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)</code>, where <code>excess_blob_gas</code> is the total "extra" amount of blob gas that the chain has consumed relative to the "targeted" number (<code>TARGET_BLOB_GAS_PER_BLOCK</code> per block). Like EIP-1559, it's a self-correcting formula: as the excess goes higher, the <code>base_fee_per_blob_gas</code> increases exponentially, reducing usage and eventually forcing the excess back down.</p> <p>The block-by-block behavior is roughly as follows. If block <code>N</code> consumes <code>X</code> blob gas, then in block <code>N+1</code> <code>excess_blob_gas</code> increases by <code>X - TARGET_BLOB_GAS_PER_BLOCK</code>, and so the <code>base_fee_per_blob_gas</code> of block <code>N+1</code> increases by a factor of <code>e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_BASE_FEE_UPDATE_FRACTION)</code>. Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in the sense that it responds in the same way to the same total usage regardless of how it's distributed.</p> <p>The parameter <code>BLOB_BASE_FEE_UPDATE_FRACTION</code> controls the maximum rate of change of the base fee per blob gas. It is chosen to target a maximum change rate of <code>e**(TARGET_BLOB_GAS_PER_BLOCK / BLOB_BASE_FEE_UPDATE_FRACTION) ≈ 1.125</code> per block.</p> <h3 id="throughput">Throughput</h3> <p>The values for <code>TARGET_BLOB_GAS_PER_BLOCK</code> and <code>MAX_BLOB_GAS_PER_BLOCK</code> are chosen to correspond to a target of 3 blobs (0.375 MB) and maximum of 6 blobs (0.75 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h3 id="blob-non-accessibility">Blob non-accessibility</h3> <p>This EIP introduces a transaction type that has a distinct mempool version and execution-payload version, with only one-way convertibility between the two. The blobs are in the network representation and not in the consensus representation; instead, they are coupled with the beacon block. This means that there is now a part of a transaction that will not be accessible from the web3 API.</p> <h3 id="mempool-issues">Mempool issues</h3> <p>Blob transactions have a large data size at the mempool layer, which poses a mempool DoS risk, though not an unprecedented one as this also applies to transactions with large amounts of calldata.</p> <p>By only broadcasting announcements for blob transactions, receiving nodes will have control over which and how many transactions to receive, allowing them to throttle throughput to an acceptable level. <a href="https://wg-eips.ritovision.com/5793/">EIP-5793</a> will give further fine-grained control to nodes by extending the <code>NewPooledTransactionHashes</code> announcement messages to include the transaction type and size.</p> <p>In addition, we recommend including a 1.1x base fee per blob gas bump requirement to the mempool transaction replacement rules.</p> <h2 id="test-cases">Test Cases</h2> <p>Execution layer test cases for this EIP can be found in the <a rel="external" href="https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip4844_blobs"><code>eip4844_blobs</code></a> of the <code>ethereum/execution-spec-tests</code> repository. Consensus layer test cases can be found <a rel="external" href="https://github.com/ethereum/consensus-specs/tree/2297c09b7e457a13f7b2261a28cb45777be82f83/tests/core/pyspec/eth2spec/test/deneb">here</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP increases the bandwidth requirements per beacon block by a maximum of ~0.75 MB. This is 40% larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth. Post-merge, block times are static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.</p> <p>The <em>sustained</em> load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited, because there is no expectation that the blobs need to be stored for as long as an execution payload. This makes it possible to implement a policy that these blobs must be kept for at least a certain period. The specific value chosen is <code>MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS</code> epochs, which is around 18 days, a much shorter delay compared to proposed (but yet to be implemented) one-year rotation times for execution payload history.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Stokeshttps://github.com/ralexstokes Ansgar Dietrichshttps://github.com/adietrichs Danny Ryanhttps://github.com/djrtwo Martin Holst Swendehttps://github.com/holiman lightclienthttps://github.com/lightclient https://wg-eips.ritovision.com/4788/

Expose beacon chain roots in the EVM

<h2 id="abstract">Abstract</h2> <p>Commit to the hash tree root of each beacon chain block in the corresponding execution payload header.</p> <p>Store each of these roots in a smart contract.</p> <h2 id="motivation">Motivation</h2> <p>Roots of the beacon chain blocks are cryptographic accumulators that allow proofs of arbitrary consensus state. Exposing these roots inside the EVM allows for trust-minimized access to the consensus layer. This functionality supports a wide variety of use cases that improve trust assumptions of staking pools, restaking constructions, smart contract bridges, MEV mitigations and more.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>constants</th><th>value</th></tr></thead><tbody> <tr><td><code>FORK_TIMESTAMP</code></td><td><code>1710338135</code></td></tr> <tr><td><code>HISTORY_BUFFER_LENGTH</code></td><td><code>8191</code></td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td></tr> <tr><td><code>BEACON_ROOTS_ADDRESS</code></td><td><code>0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02</code></td></tr> </tbody></table> <h3 id="background">Background</h3> <p>The high-level idea is that each execution block contains the parent beacon block's root. Even in the event of missed slots since the previous block root does not change, we only need a constant amount of space to represent this "oracle" in each execution block. To improve the usability of this oracle, a small history of block roots are stored in the contract.</p> <p>To bound the amount of storage this construction consumes, a ring buffer is used that mirrors a block root accumulator on the consensus layer.</p> <h3 id="block-structure-and-validity">Block structure and validity</h3> <p>Beginning at the execution timestamp <code>FORK_TIMESTAMP</code>, execution clients <strong>MUST</strong> extend the header schema with an additional field: the <code>parent_beacon_block_root</code>. This root consumes 32 bytes and is exactly the <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/fa09d896484bbe240334fa21ffaa454bafe5842e/ssz/simple-serialize.md#merkleization">hash tree root</a> of the parent beacon block for the given execution block.</p> <p>The resulting RLP encoding of the header is therefore:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>rlp</span><span>(</span><span>[</span></span> <span class="giallo-l"><span> parent_hash</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ommers hash</span></span> <span class="giallo-l"><span> coinbase</span><span>,</span></span> <span class="giallo-l"><span> state_root</span><span>,</span></span> <span class="giallo-l"><span> txs_root</span><span>,</span></span> <span class="giallo-l"><span> receipts_root</span><span>,</span></span> <span class="giallo-l"><span> logs_bloom</span><span>,</span></span> <span class="giallo-l"><span class="z-constant"> 0</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> difficulty</span></span> <span class="giallo-l"><span> number</span><span>,</span></span> <span class="giallo-l"><span> gas_limit</span><span>,</span></span> <span class="giallo-l"><span> gas_used</span><span>,</span></span> <span class="giallo-l"><span> timestamp</span><span>,</span></span> <span class="giallo-l"><span> extradata</span><span>,</span></span> <span class="giallo-l"><span> prev_randao</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">0000000000000000</span><span>,</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> nonce</span></span> <span class="giallo-l"><span> base_fee_per_gas</span><span>,</span></span> <span class="giallo-l"><span> withdrawals_root</span><span>,</span></span> <span class="giallo-l"><span> blob_gas_used</span><span>,</span></span> <span class="giallo-l"><span> excess_blob_gas</span><span>,</span></span> <span class="giallo-l"><span> parent_beacon_block_root</span><span>,</span></span> <span class="giallo-l"><span>]</span><span>)</span></span></code></pre> <p>Validity of the parent beacon block root is guaranteed from the consensus layer, much like how withdrawals are handled.</p> <p>When verifying a block, execution clients <strong>MUST</strong> ensure the root value in the block header matches the one provided by the consensus client.</p> <p>For a genesis block with no existing parent beacon block root the 32 zero bytes are used as a root placeholder.</p> <h4 id="beacon-roots-contract">Beacon roots contract</h4> <p>The beacon roots contract has two operations: <code>get</code> and <code>set</code>. The input itself is not used to determine which function to execute, for that the result of <code>caller</code> is used. If <code>caller</code> is equal to <code>SYSTEM_ADDRESS</code> then the operation to perform is <code>set</code>. Otherwise, <code>get</code>.</p> <h5 id="get"><code>get</code></h5> <ul> <li>Callers provide the <code>timestamp</code> they are querying encoded as 32 bytes in big-endian format.</li> <li>If the input is not exactly 32 bytes, the contract must revert.</li> <li>If the input is equal to 0, the contract must revert.</li> <li>Given <code>timestamp</code>, the contract computes the storage index in which the timestamp is stored by computing the modulo <code>timestamp % HISTORY_BUFFER_LENGTH</code> and reads the value.</li> <li>If the <code>timestamp</code> does not match, the contract must revert.</li> <li>Finally, the beacon root associated with the timestamp is returned to the user. It is stored at <code>timestamp % HISTORY_BUFFER_LENGTH + HISTORY_BUFFER_LENGTH</code>.</li> </ul> <h5 id="set"><code>set</code></h5> <ul> <li>Caller provides the parent beacon block root as calldata to the contract.</li> <li>Set the storage value at <code>header.timestamp % HISTORY_BUFFER_LENGTH</code> to be <code>header.timestamp</code></li> <li>Set the storage value at <code>header.timestamp % HISTORY_BUFFER_LENGTH + HISTORY_BUFFER_LENGTH</code> to be <code>calldata[0:32]</code></li> </ul> <h5 id="pseudocode">Pseudocode</h5> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> evm</span><span>.</span><span>caller</span><span class="z-keyword"> ==</span><span class="z-constant"> SYSTEM_ADDRESS</span><span>:</span></span> <span class="giallo-l"><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span> get</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>evm</span><span>.</span><span>calldata</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>revert</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> to_uint256_be</span><span>(</span><span>evm</span><span>.</span><span>calldata</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>revert</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> timestamp_idx</span><span class="z-keyword"> =</span><span> to_uint256_be</span><span>(</span><span>evm</span><span>.</span><span>calldata</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> HISTORY_BUFFER_LENGTH</span></span> <span class="giallo-l"><span> timestamp</span><span class="z-keyword"> =</span><span> storage</span><span>.</span><span>get</span><span>(</span><span>timestamp_idx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> timestamp</span><span class="z-keyword"> !=</span><span> evm</span><span>.</span><span>calldata</span><span>:</span></span> <span class="giallo-l"><span> evm</span><span>.</span><span>revert</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> root_idx</span><span class="z-keyword"> =</span><span> timestamp_idx</span><span class="z-keyword"> +</span><span class="z-constant"> HISTORY_BUFFER_LENGTH</span></span> <span class="giallo-l"><span> root</span><span class="z-keyword"> =</span><span> storage</span><span>.</span><span>get</span><span>(</span><span>root_idx</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> evm</span><span>.</span><span class="z-keyword">return</span><span>(</span><span>root</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-support"> set</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> timestamp_idx</span><span class="z-keyword"> =</span><span> to_uint256_be</span><span>(</span><span>evm</span><span>.</span><span>timestamp</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> HISTORY_BUFFER_LENGTH</span></span> <span class="giallo-l"><span> root_idx</span><span class="z-keyword"> =</span><span> timestamp_idx</span><span class="z-keyword"> +</span><span class="z-constant"> HISTORY_BUFFER_LENGTH</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> storage</span><span>.</span><span>set</span><span>(</span><span>timestamp_idx</span><span>,</span><span> evm</span><span>.</span><span>timestamp</span><span>)</span></span> <span class="giallo-l"><span> storage</span><span>.</span><span>set</span><span>(</span><span>root_idx</span><span>,</span><span> evm</span><span>.</span><span>calldata</span><span>)</span></span></code></pre><h5 id="bytecode">Bytecode</h5> <p>The exact contract bytecode is shared below.</p> <pre class="giallo z-code"><code data-lang="asm"><span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push20 </span><span class="z-constant">0xfffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x4d</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x24</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>dup1</span></span> <span class="giallo-l"><span>iszero</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x49</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push3 </span><span class="z-constant">0x001fff</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>mod</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x3c</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push3 </span><span class="z-constant">0x001fff</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 </span><span class="z-constant">0x20</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push3 </span><span class="z-constant">0x001fff</span></span> <span class="giallo-l"><span>timestamp</span></span> <span class="giallo-l"><span>mod</span></span> <span class="giallo-l"><span>timestamp</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>push3 </span><span class="z-constant">0x001fff</span></span> <span class="giallo-l"><span class="z-keyword">add</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>stop</span></span></code></pre><h4 id="deployment">Deployment</h4> <p>The beacon roots contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">to</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x3d090</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gasPrice</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xe8d4a51000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxPriorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">value</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">input</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">v</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">r</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x539</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">s</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1b9b6eb1f0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xdf52c2d3bbe38820fff7b5eaab3db1b91f8e1412b56497d88388fb5d4ea1fde0</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Note, the input in the transaction has a simple constructor prefixing the desired runtime code.</p> <p>The sender of the transaction can be calculated as <code>0x0B799C86a49DEeb90402691F1041aa3AF2d3C875</code>. The address of the first contract deployed from the account is <code>rlp([sender, 0])</code> which equals <code>0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02</code>. This is how <code>BEACON_ROOTS_ADDRESS</code> is determined. Although this style of contract creation is not tied to any specific initcode like create2 is, the synthetic address is cryptographically bound to the input data of the transaction (e.g. the initcode).</p> <h3 id="block-processing">Block processing</h3> <p>At the start of processing any execution block where <code>block.timestamp &gt;= FORK_TIMESTAMP</code> (i.e. before processing any transactions), call <code>BEACON_ROOTS_ADDRESS</code> as <code>SYSTEM_ADDRESS</code> with the 32-byte input of <code>header.parent_beacon_block_root</code>, a gas limit of <code>30_000_000</code>, and <code>0</code> value. This will trigger the <code>set()</code> routine of the beacon roots contract. This is a system operation and therefore:</p> <ul> <li>the call must execute to completion</li> <li>the call does not count against the block's gas limit</li> <li>the call does not follow the <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> burn semantics - no value should be transferred as part of the call</li> <li>if no code exists at <code>BEACON_ROOTS_ADDRESS</code>, the call must fail silently</li> </ul> <p>Clients may decide to omit an explicit EVM call and directly set the storage values. Note: While this is a valid optimization for Ethereum mainnet, it could be problematic on non-mainnet situations in case a different contract is used.</p> <p>If this EIP is active in a genesis block, the genesis header's <code>parent_beacon_block_root</code> must be <code>0x0</code> and no system transaction may occur.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-not-repurpose-blockhash">Why not repurpose <code>BLOCKHASH</code>?</h3> <p>The <code>BLOCKHASH</code> opcode could be repurposed to provide the beacon root instead of some execution block hash. To minimize code change, avoid breaking changes to smart contracts, and simplify deployment to mainnet, this EIP suggests leaving <code>BLOCKHASH</code> alone and adding new functionality with the desired semantics.</p> <h3 id="beacon-block-root-instead-of-state-root">Beacon block root instead of state root</h3> <p>Block roots are preferred over state roots so there is a constant amount of work to do with each new execution block. Otherwise, skipped slots would require a linear amount of work with each new payload. While skipped slots are quite rare on mainnet, it is best to not add additional load under what would already be nonfavorable conditions.</p> <p>Use of block root over state root does mean proofs will require a few additional nodes but this cost is negligible (and could be amortized across all consumers, e.g. with a singleton state root contract that caches the proof per slot).</p> <h3 id="why-two-ring-buffers">Why two ring buffers?</h3> <p>The first ring buffer only tracks <code>HISTORY_BUFFER_LENGTH</code> worth of roots and so for all possible timestamp values would consume a constant amount of storage. However, this design opens the contract to an attack where a skipped slot that has the same value modulo the ring buffer length would return an old root value, rather than the most recent one.</p> <p>To nullify this attack while retaining a fixed memory footprint, this EIP keeps track of the pair of data <code>(parent_beacon_block_root, timestamp)</code> for each index into the ring buffer and verifies the timestamp matches the one originally used to write the root data when being read. Given the fixed size of storage slots (only 32 bytes), the requirement to store a pair of values necessitates two ring buffers, rather than just one.</p> <h3 id="size-of-ring-buffers">Size of ring buffers</h3> <p>The ring buffer data structures are sized to hold 8191 roots from the consensus layer. Using a prime number as the ring buffer size ensures that no value is overwritten until the entire ring buffer has been saturated and thereafter, each value will be updated once per iteration. This also means that even if the slot times were to change, we would continue to use at most 8191 storage slots.</p> <p>Given the current mainnet values, 8191 roots provides about a day of coverage. This gives users plenty of time to make a transaction with a verification against a specific root and get the transaction included on-chain.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No issues.</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>N/A</p> <h2 id="security-considerations">Security Considerations</h2> <p>N/A</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad https://wg-eips.ritovision.com/4758/

Deactivate SELFDESTRUCT by changing it to SENDALL, which does recover all funds to the caller but does not delete any code or storage.

<h2 id="abstract">Abstract</h2> <p>This EIP renames the <code>SELFDESTRUCT</code> opcode to <code>SENDALL</code>, and replaces its functionality. The new functionality will be only to send all Ether in the account to the caller.</p> <h2 id="motivation">Motivation</h2> <p>The <code>SELFDESTRUCT</code> opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account.</p> <p>This EIP implements this change. Applications that only use <code>SELFDESTRUCT</code> to retrieve funds will still work.</p> <h2 id="specification">Specification</h2> <ul> <li>The <code>SELFDESTRUCT</code> opcode is renamed to <code>SENDALL</code>, and now only immediately moves all ETH in the account to the target; it no longer destroys code or storage or alters the nonce</li> <li>All refunds related to <code>SELFDESTRUCT</code> are removed</li> </ul> <h2 id="rationale">Rationale</h2> <p>Getting rid of the <code>SELFDESTRUCT</code> opcode has been considered in the past, and there are currently no strong reasons to use it. Disabling it will be a requirement for statelessness.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork, since it modifies consensus rules.</p> <p>Few applications are affected by this change. The only use that breaks is where a contract is re-created at the same address using <code>CREATE2</code> (after a <code>SELFDESTRUCT</code>).</p> <h2 id="security-considerations">Security Considerations</h2> <p>The following applications of <code>SELFDESTRUCT</code> will be broken and applications that use it in this way are not safe anymore:</p> <ol> <li>Any use where <code>SELFDESTRUCT</code> is used to burn non-ETH token balances, such as <a href="https://wg-eips.ritovision.com/20/">EIP-20</a>), inside a contract. We do not know of any such use (since it can easily be done by sending to a burn address this seems an unlikely way to use <code>SELFDESTRUCT</code>)</li> <li>Where <code>CREATE2</code> is used to redeploy a contract in the same place. There are two ways in which this can fail: <ul> <li>The destruction prevents the contract from being used outside of a certain context. For example, the contract allows anyone to withdraw funds, but <code>SELFDESTRUCT</code> is used at the end of an operation to prevent others from doing this. This type of operation can easily be modified to not depend on <code>SELFDESTRUCT</code>.</li> <li>The <code>SELFDESTRUCT</code> operation is used in order to make a contract upgradable. This is not supported anymore and delegates should be used.</li> </ul> </li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad https://wg-eips.ritovision.com/4760/

Deactivate SELFDESTRUCT by changing it to SENDALL and stage this via a stage of exponential gas cost increases.

<h2 id="abstract">Abstract</h2> <p>This EIP renames the <code>SELFDESTRUCT</code> opcode to <code>SENDALL</code>, and replaces its functionality. The new functionality will be only to send all Ether in the account to the caller.</p> <p>In order to give apps more warning even if their developers are completely unaware of the EIP process, this version will exponentially increase the gas costs of the opcode, so any developer has time to see this change and react by implementing a version of their contract that does not rely on <code>SELFDESTRUCT</code> .</p> <h2 id="motivation">Motivation</h2> <p>The <code>SELFDESTRUCT</code> opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account.</p> <p>This EIP implements this change. Applications that only use <code>SELFDESTRUCT</code> to retrieve funds will still work.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td><code>OLD_SELFDESTRUCT_COST</code></td><td>5000</td><td>Current gas cost of <code>SELFDESTRUCT</code> opcode</td></tr> <tr><td><code>HARD_FORK_BLOCK</code></td><td>TBD</td><td>(Shanghai HF block height)</td></tr> <tr><td><code>DOUBLING_SLOTS</code></td><td><code>2**16</code></td><td>(Time for gas price to double, ca. 9 days)</td></tr> <tr><td><code>DOUBLINGS_BEFORE_SENDALL</code></td><td><code>13</code></td><td><code>SELFDESTRUCT</code> will be converted to <code>SENDALL</code> at <code>HARD_FORK_BLOCK + DOUBLING_SLOTS * DOUBLINGS_BEFORE_SENDALL</code></td></tr> </tbody></table> <ul> <li>If <code>HARD_FORK_BLOCK &lt;= slot &lt; HARD_FORK_BLOCK + DOUBLING_SLOTS * DOUBLINGS_BEFORE_SENDALL</code> <ul> <li><code>SELFDESTRUCT</code> functionality remains unchanged</li> <li><code>SELFDESTRUCT</code> gas cost is now <code>OLD_SELFDESTRUCT_COST * 2 ** ((slot - HARD_FORK_BLOCK) // DOUBLING_SLOTS)</code></li> </ul> </li> <li>For <code>slot &gt;= HARD_FORK_BLOCK + DOUBLING_SLOTS * DOUBLINGS_BEFORE_SENDALL</code> <ul> <li>The cost reverts back to <code>OLD_SELFDESTRUCT_COST</code></li> <li>The <code>SELFDESTRUCT</code> opcode is renamed to <code>SENDALL</code>, and now only immediately moves all ETH in the account to the target; it no longer destroys code or storage or alters the nonce</li> <li>All refunds related to <code>SELFDESTRUCT</code> are removed</li> </ul> </li> </ul> <h2 id="rationale">Rationale</h2> <p>The idea behind this EIP is to disable <code>SELFDESTRUCT</code> in a way that gives ample warning to Dapp developers. Many developers do not watch the EIP process closely and can therefore be caught by surprise when an opcode is deactivated and does not fulfill its original purpose anymore. However, at least if the smart contract has regular use, then users will notice the price of the operation going up tremendously. The period over which this is happening (<code>HARD_FORK_BLOCK + DOUBLING_SLOTS * DOUBLINGS_BEFORE_SENDALL</code>) is chosen to be long enough (ca. 4 months) such that it gives developers time to react to this change and prepare their application.</p> <h2 id="backward-compatibility">Backward Compatibility</h2> <p>This EIP requires a hard fork, since it modifies consensus rules.</p> <p>Few applications are affected by this change. The only use that breaks is where a contract is re-created at the same address using <code>CREATE2</code> (after a <code>SELFDESTRUCT</code>). The only application that is significantly affected (and where code can be analyzed) is able to switch to a different model, and should have ample time to do so.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The following applications of <code>SELFDESTRUCT</code> will be broken and applications that use it in this way are not safe anymore:</p> <ol> <li> <p>Any use where <code>SELFDESTRUCT</code> is used to burn non-ETH token balances, such as ERC20, inside a contract. We do not know of any such use (since it can easily be done by sending to a burn address this seems an unlikely way to use <code>SELFDESTRUCT</code>)</p> </li> <li> <p>Where <code>CREATE2</code> is used to redeploy a contract in the same place. There are two ways in which this can fail:</p> <ul> <li>The destruction prevents the contract from being used outside of a certain context. For example, the contract allows anyone to withdraw funds, but <code>SELFDESTRUCT</code> is used at the end of an operation to prevent others from doing this. This type of operation can easily be modified to not depend on <code>SELFDESTRUCT</code>.</li> <li>The <code>SELFDESTRUCT</code> operation is used in order to make a contract upgradable. This is not supported anymore and delegates should be used.</li> </ul> </li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Vitalik Buterinhttps://github.com/vbuterin Dankrad Feisthttps://github.com/dankrad Ignacio Hagopianhttps://github.com/jsign Tanishq Jasoriahttps://github.com/tanishqjasoria Gajinder Singhhttps://github.com/g11tech https://wg-eips.ritovision.com/4762/

Changes the gas schedule to reflect the costs of creating a witness by requiring clients update their database layout to match.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces changes in the gas schedule to reflect the costs of creating a witness. It requires clients to update their database layout to match this, so as to avoid potential DoS attacks.</p> <h2 id="motivation">Motivation</h2> <p>The introduction of Verkle trees into Ethereum requires fundamental changes and as a preparation, this EIP is targeting the fork coming right before the verkle tree fork, in order to incentivize Dapp developers to adopt the new storage model, and ample time to adjust to it. It also incentivizes client developers to migrate their database format ahead of the verkle fork.</p> <h2 id="specification">Specification</h2> <h3 id="helper-functions">Helper functions</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> get_storage_slot_tree_keys</span><span>(</span><span class="z-variable z-parameter z-function">storage_key</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> storage_key</span><span class="z-keyword"> &lt;</span><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> -</span><span class="z-constant"> HEADER_STORAGE_OFFSET</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> HEADER_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> storage_key</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> MAIN_STORAGE_OFFSET</span><span class="z-keyword"> +</span><span> storage_key</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> //</span><span class="z-constant"> 256</span><span>,</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> %</span><span class="z-constant"> 256</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h3 id="access-events">Access events</h3> <p>Whenever the state is read, one or more of the access events of the form <code>(address, sub_key, leaf_key)</code> take place, determining what data is being accessed. We define access events as follows:</p> <h4 id="access-events-for-account-headers">Access events for account headers</h4> <p>When:</p> <ol> <li>a non-precompile which is also not a system contract is the target of a <code>*CALL</code>, <code>CALLCODE</code>, <code>SELFDESTRUCT</code>, <code>EXTCODESIZE</code>, or <code>EXTCODECOPY</code> opcode,</li> <li>a non-precompile which is also not a system contract is the target address of a contract creation whose initcode starts execution,</li> <li>any address is the target of the <code>BALANCE</code> opcode</li> <li>a <em>deployed</em> contract calls <code>CODECOPY</code></li> </ol> <p>process this access event:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(address, 0, BASIC_DATA_LEAF_KEY)</span></span></code></pre> <p>Note: a non-value-bearing <code>SELFDESTRUCT</code>, <code>*CALL</code> or <code>CALLCODE</code>, targeting a precompile or a system contract, will not cause the <code>BASIC_DATA_LEAF_KEY</code> to be added to the witness.</p> <p>If a <code>*CALL</code>, <code>CALLCODE</code> or <code>SELFDESTRUCT</code> is value-bearing (ie. it transfers nonzero wei), whether or not the <code>callee</code> is a precompile or a system contract, process this additional access event:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(caller, 0, BASIC_DATA_LEAF_KEY)</span></span></code></pre> <p>Note: when checking for the existence of the <code>callee</code>, the existence check is done by validating that there is an extension-and-suffix tree at the corresponding stem, and does not rely on <code>CODEHASH_LEAF_KEY</code>.</p> <p>When calling <code>EXTCODEHASH</code>, process the access event:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(address, 0, CODEHASH_LEAF_KEY)</span></span></code></pre> <p>Note that precompiles and system contracts are excluded, as their hashes are known to the client.</p> <p>When a contract is created, process these access events:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(contract_address, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"><span>(contract_address, 0, CODEHASH_LEAF_KEY)</span></span></code></pre><h4 id="access-events-for-storage">Access events for storage</h4> <p><code>SLOAD</code> and <code>SSTORE</code> opcodes with a given address and key process an access event of the form</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(address, tree_key, sub_key)</span></span></code></pre> <p>Where <code>tree_key</code> and <code>sub_key</code> are computed as <code>tree_key, sub_key = get_storage_slot_tree_keys(key)</code></p> <h4 id="access-events-for-code">Access events for code</h4> <p>In the conditions below, “chunk chunk_id is accessed” is understood to mean an access event of the form</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(address, (chunk_id + 128) // 256, (chunk_id + 128) % 256)</span></span></code></pre> <ul> <li>At each step of EVM execution, if and only if <code>PC &lt; len(code)</code>, chunk <code>PC // CHUNK_SIZE</code> (where <code>PC</code> is the current program counter) of the callee is accessed. In particular, note the following corner cases: <ul> <li>The destination of a <code>JUMP</code> (or positively evaluated <code>JUMPI</code>) is considered to be accessed, even if the destination is not a jumpdest or is inside pushdata</li> <li>The destination of a <code>JUMPI</code> is not considered to be accessed if the jump conditional is <code>false</code>.</li> <li>The destination of a jump is not considered to be accessed if the execution gets to the jump opcode but does not have enough gas to pay for the gas cost of executing the <code>JUMP</code> opcode (including chunk access cost if the <code>JUMP</code> is the first opcode in a not-yet-accessed chunk)</li> <li>The destination of a jump is not considered to be accessed if it is beyond the code (<code>destination &gt;= len(code)</code>)</li> <li>If code stops execution by walking past the end of the code, <code>PC = len(code)</code> is not considered to be accessed</li> </ul> </li> <li>If the current step of EVM execution is a <code>PUSH{n}</code>, all chunks <code>(PC // CHUNK_SIZE) &lt;= chunk_index &lt;= ((PC + n) // CHUNK_SIZE)</code> of the callee are accessed.</li> <li>If a nonzero-read-size <code>CODECOPY</code> or <code>EXTCODECOPY</code> read bytes <code>x...y</code> inclusive, all chunks <code>(x // CHUNK_SIZE) &lt;= chunk_index &lt;= (min(y, code_size - 1) // CHUNK_SIZE)</code> of the accessed contract are accessed. <ul> <li>Example 1: for a <code>CODECOPY</code> with start position 100, read size 50, <code>code_size = 200</code>, <code>x = 100</code> and <code>y = 149</code></li> <li>Example 2: for a <code>CODECOPY</code> with start position 600, read size 0, no chunks are accessed</li> <li>Example 3: for a <code>CODECOPY</code> with start position 1500, read size 2000, <code>code_size = 3100</code>, <code>x = 1500</code> and <code>y = 3099</code></li> </ul> </li> <li><code>CODESIZE</code>, <code>EXTCODESIZE</code> and <code>EXTCODEHASH</code> do NOT access any chunks. When a contract is created, access chunks <code>0 ... (len(code)+30)//31</code></li> </ul> <h3 id="write-events">Write Events</h3> <p>We define <strong>write events</strong> as follows. Note that when a write takes place, an access event also takes place (so the definition below should be a subset of the definition of access events). A write event is of the form <code>(address, sub_key, leaf_key)</code>, determining what data is being written to.</p> <h4 id="write-events-for-account-headers">Write events for account headers</h4> <p>When a nonzero-balance-sending <code>CALL</code>, <code>CALLCODE</code> or <code>SELFDESTRUCT</code> with a given sender and recipient takes place, process these write events:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(caller, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"><span>(callee, 0, BASIC_DATA_LEAF_KEY)</span></span></code></pre> <p>if no account exists at <code>callee_address</code>, also process:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(callee, 0, CODEHASH_LEAF_KEY)</span></span></code></pre> <p>When a contract creation is initialized, process these write events:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(contract_address, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"><span>(contract_address, 0, CODEHASH_LEAF_KEY)</span></span></code></pre><h4 id="write-events-for-storage">Write events for storage</h4> <p><code>SSTORE</code> opcodes with a given <code>address</code> and <code>key</code> process a write event of the form</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(address, tree_key, sub_key)</span></span></code></pre> <p>Where <code>tree_key</code> and <code>sub_key</code> are computed as <code>tree_key, sub_key = get_storage_slot_tree_keys(key)</code></p> <h4 id="write-events-for-code">Write events for code</h4> <p>When a contract is created, process the write events:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>(</span></span> <span class="giallo-l"><span> address</span><span>,</span></span> <span class="giallo-l"><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> VERKLE_NODE_WIDTH</span><span>,</span></span> <span class="giallo-l"><span> (</span><span class="z-constant">CODE_OFFSET</span><span class="z-keyword"> +</span><span> i</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> VERKLE_NODE_WIDTH</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>For <code>i</code> in <code>0 ... (len(code)+30)//31</code>.</p> <p>Note: since no access list existed for code up until this EIP, note that no warm costs are charged for code accesses.</p> <h3 id="transaction">Transaction</h3> <h4 id="access-events-1">Access events</h4> <p>For a transaction, make these access events:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(tx.origin, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"><span>(tx.origin, 0, CODEHASH_LEAF_KEY)</span></span> <span class="giallo-l"><span>(tx.target, 0, BASIC_DATA_LEAF_KEY)</span></span> <span class="giallo-l"><span>(tx.target, 0, CODEHASH_LEAF_KEY)</span></span></code></pre><h4 id="write-events-1">Write events</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(tx.origin, 0, BASIC_DATA_LEAF_KEY)</span></span></code></pre> <p>If <code>value</code> is non-zero:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(tx.target, 0, BASIC_DATA_LEAF_KEY)</span></span></code></pre><h3 id="witness-gas-costs">Witness gas costs</h3> <p>Remove the following gas costs:</p> <ul> <li>Increased gas cost of <code>CALL</code> if it is nonzero-value-sending</li> <li><a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> <code>SSTORE</code> gas costs except for the <code>SLOAD_GAS</code></li> <li>200 per byte contract code cost</li> <li>All <code>CALLCODE</code> costs related to nonzero-value-sending</li> </ul> <p>Reduce gas cost:</p> <ul> <li><code>CREATE</code>/<code>CREATE2</code> to 1000</li> </ul> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>WITNESS_BRANCH_COST</code></td><td>1900</td></tr> <tr><td><code>WITNESS_CHUNK_COST</code></td><td>200</td></tr> <tr><td><code>SUBTREE_EDIT_COST</code></td><td>3000</td></tr> <tr><td><code>CHUNK_EDIT_COST</code></td><td>500</td></tr> <tr><td><code>CHUNK_FILL_COST</code></td><td>6200</td></tr> </tbody></table> <p>When executing a transaction, maintain four sets:</p> <ul> <li><code>accessed_subtrees: Set[Tuple[address, int]]</code></li> <li><code>accessed_leaves: Set[Tuple[address, int, int]]</code></li> <li><code>edited_subtrees: Set[Tuple[address, int]]</code></li> <li><code>edited_leaves: Set[Tuple[address, int, int]]</code></li> </ul> <p>When an <strong>access</strong> event of <code>(address, sub_key, leaf_key)</code> occurs, perform the following checks:</p> <ul> <li>Perform the following steps unless event is a <em>Transaction access event</em>;</li> <li>If <code>(address, sub_key)</code> is not in <code>accessed_subtrees</code>, charge <code>WITNESS_BRANCH_COST</code> gas and add that tuple to <code>accessed_subtrees</code>.</li> <li>If <code>leaf_key</code> is not <code>None</code> and <code>(address, sub_key, leaf_key)</code> is not in <code>accessed_leaves</code>, charge <code>WITNESS_CHUNK_COST</code> gas and add it to <code>accessed_leaves</code></li> </ul> <p>When a <strong>write</strong> event of <code>(address, sub_key, leaf_key)</code> occurs, perform the following checks:</p> <ul> <li>If event is <em>Transaction write event</em>, skip the following steps.</li> <li>If <code>(address, sub_key)</code> is not in <code>edited_subtrees</code>, charge <code>SUBTREE_EDIT_COST</code> gas and add that tuple to <code>edited_subtrees</code>.</li> <li>If <code>leaf_key</code> is not <code>None</code> and <code>(address, sub_key, leaf_key)</code> is not in <code>edited_leaves</code>, charge <code>CHUNK_EDIT_COST</code> gas and add it to <code>edited_leaves</code> <ul> <li>Additionally, if there was no value stored at <code>(address, sub_key, leaf_key)</code> (ie. the state held <code>None</code> at that position), charge <code>CHUNK_FILL_COST</code></li> </ul> </li> </ul> <p>Note that tree keys can no longer be emptied: only the values <code>0...2**256-1</code> can be written to a tree key, and 0 is distinct from <code>None</code>. Once a tree key is changed from <code>None</code> to not-<code>None</code>, it can never go back to <code>None</code>.</p> <p>Note that values should only be added to the witness if there is sufficient gas to cover their associated event costs. If there is not enough gas to cover the event costs, all the remaining gas should be consumed.</p> <p><code>CREATE*</code> and <code>*CALL</code> reserve 1/64th of the gas before the nested execution. In order to match the behavior of this charge with the pre-fork behavior of access lists:</p> <ul> <li>this minimum 1/64th gas reservation is checked <strong>AFTER</strong> charging the witness costs when performing a <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code> or <code>STATICCALL</code></li> <li>this 1/64th of the gas is subtracted <strong>BEFORE</strong> charging the witness costs when performing a <code>CREATE</code> or <code>CREATE2</code></li> </ul> <h3 id="block-level-operations">Block-level operations</h3> <p>None of:</p> <ul> <li>Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call,</li> <li>The coinbase account</li> <li>Withdrawal accounts</li> </ul> <p>are warm at the start of a transaction.</p> <h3 id="system-contracts">System contracts</h3> <p>When (and only when) calling a system contract either</p> <ul> <li><em>via a system call</em> or</li> <li><em>to resolve a precompile/opcode</em>,</li> </ul> <p>the system contract's <em>code chunks</em> and <em>account headers</em> accesses should not appear in the witness as these should be known/cached in the clients. However any other accesses and all writes should appear in the witness.</p> <p>Also corresponding witness costs need to be charged for <em>precompile/opcode resolution</em> but are not charged in the <em>system call</em>.</p> <h3 id="account-abstraction">Account abstraction</h3> <p>TODO : still waiting on a final decision between 7702 and 3074</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-reform">Gas reform</h3> <p>Gas costs for reading storage and code are reformed to more closely reflect the gas costs under the new Verkle tree design. <code>WITNESS_CHUNK_COST</code> is set to charge 6.25 gas per byte for chunks, and <code>WITNESS_BRANCH_COST</code> is set to charge ~13,2 gas per byte for branches on average (assuming 144 byte branch length) and ~2.5 gas per byte in the worst case if an attacker fills the tree with keys deliberately computed to maximize proof length.</p> <p>The main differences from gas costs in Berlin are:</p> <ul> <li>200 gas charged per 31 byte chunk of code. This has been estimated to increase average gas usage by ~6-12% (suggesting 10-20% gas usage increases at a 350 gas per chunk level).</li> <li>Cost for accessing adjacent storage slots (<code>key1 // 256 == key2 // 256</code>) decreases from 2100 to 200 for all slots after the first in the group,</li> <li>Cost for accessing storage slots 0…63 decreases from 2100 to 200, including the first storage slot. This is likely to significantly improve performance of many existing contracts, which use those storage slots for single persistent variables.</li> </ul> <p>Gains from the latter two properties have not yet been analyzed, but are likely to significantly offset the losses from the first property. It’s likely that once compilers adapt to these rules, efficiency will increase further.</p> <p>The precise specification of when access events take place, which makes up most of the complexity of the gas repricing, is necessary to clearly specify when data needs to be saved to the period 1 tree.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork, since it modifies consensus rules.</p> <p>The main backwards-compatibility-breaking change is the gas costs for code chunk access making some applications less economically viable. It can be mitigated by increasing the gas limit at the same time as implementing this EIP, reducing the risk that applications will no longer work at all due to transaction gas usage rising above the block gas limit.</p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP will mean that certain operations, mostly reading and writing several elements in the same suffix tree, become cheaper. If clients retain the same database structure as they have now, this would result in a DOS vector.</p> <p>So some adaptation of the database is required in order to make this work:</p> <ul> <li>In all possible futures, it is important to logically separate the commitment scheme from data storage. In particular, no traversal of the commitment scheme tree should be necessary to find any given state element</li> <li>In order to make accesses to the same stem cheap as required for this EIP, the best way is probably to store each stem in the same location in the database. Basically the 256 leaves of 32 bytes each would be stored in an 8kB BLOB. The overhead of reading/writing this BLOB is small because most of the cost of disk access is seeking and not the amount transferred.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Peter Davieshttps://github.com/petertdavies https://wg-eips.ritovision.com/4747/

Simplify EIP-161 and retroactively deprecate unused aspects of it

<h2 id="abstract">Abstract</h2> <p>Simplify the definition of <a href="https://wg-eips.ritovision.com/161/">EIP-161</a>, removing the requirement for implementors to support edge cases that are impossible on Ethereum Mainnet.</p> <h2 id="motivation">Motivation</h2> <p>EIP-161 is overly complex and has a number of edge cases that are poorly documented and tested. This EIP takes advantage of the complete removal of all remaining empty accounts in block 14049881 (tx <code>0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d</code>) to clarify it, and allows implementors to not implement various edge cases that never occurred and are not possible in the future.</p> <p>In particular, this EIP permits implementors who do not wish to support historical blocks to not implement state clearing at all.</p> <h2 id="specification">Specification</h2> <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p> <p>Retroactively replace EIP-161, starting from its introduction in block 2675000, with the following rules:</p> <p>a. When creating an account, set it's nonce to <code>1</code> prior to executing initcode.</p> <p>b. When performing EVM execution treat all empty accounts as if they do not exist. Any operation that would create an empty account instead leaves it non-existent.</p> <p>c. If one of the following events happens to an empty account <code>X</code>, it is deleted:</p> <ol> <li><code>X</code> receives a zero value <code>CALL</code>.</li> <li><code>X</code> is the recipient of a zero value transaction.</li> <li><code>X</code> is the beneficiary of a <code>SELFDESTRUCT</code> with zero value.</li> </ol> <p>If the transaction, <code>CALL</code> or <code>SELFDESTRUCT</code> is reverted, then the state clearing is also reverted. As a special case on Ethereum Mainnet, in block 2675119 (tx <code>0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba</code>), an empty call is made to an empty account at <code>RIPEMD160</code> (precompile <code>0x3</code>), the call fails out of gas, but the empty account is removed anyway.</p> <p>The deletion MAY happen immediately or be processed at the end of the transaction. A client may assume that <code>STATICCALL</code>s to empty accounts never occur and that <code>CALL</code>s to empty accounts in <code>STATICCALL</code> contexts never occur.</p> <p>On Ethereum Mainnet, the only state clearing events after the start of Byzantium are the two listed below. Clients MAY implement post Byzantium state clearing by hardcoding those events.</p> <ul> <li> <p>In block 4457731 (tx <code>0x63791f962e13e6b01ec13d38a8ab66c87c2f5a1768276f866300d900cca808fe</code>), <code>0xd29DFe5aE95B5C067a91F472Dac0d9be6700A4A9</code> receives a zero value <code>SELFDESTRUCT</code> and is cleared.</p> </li> <li> <p>In block 14049881 (tx <code>0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d</code>), the following accounts receive zero value calls and are cleared.</p> <details> <summary>Accounts cleared</summary> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0x01a3dd7d158e3b4c9d8d2af0ddcf3df0f5e14463</span></span> <span class="giallo-l"><span>0x0366c731dd7c095dc08896806765a649c6c0885a</span></span> <span class="giallo-l"><span>0x056c68da52395f1d42c5ba15c4fb956146a4f2c1</span></span> <span class="giallo-l"><span>0x070ba92497cd4b88a8a9a60795ca7d7f7de0faa3</span></span> <span class="giallo-l"><span>0x07a1648ce2bed6721a5d25de3c228a296d03fd52</span></span> <span class="giallo-l"><span>0x07b14ba68f474529cc0bd6a9bffee2bc4090d185</span></span> <span class="giallo-l"><span>0x07ea32232e37d44134a3071319d228bdab249a60</span></span> <span class="giallo-l"><span>0x096b7382500fa11c22c54c0422c5e38899a2e933</span></span> <span class="giallo-l"><span>0x09f3200441bd60522bcf28f3666f8e8dbd19fb62</span></span> <span class="giallo-l"><span>0x0ad0f3c60696adece09367a9a11c968fb88560bb</span></span> <span class="giallo-l"><span>0x0af6181e1db22071f38fc162e1610e29d288de04</span></span> <span class="giallo-l"><span>0x0cdc7fef8f8d0ee77360060930aada1263b26ff7</span></span> <span class="giallo-l"><span>0x0dac3d571eb5b884a2550db2791d5ac1efca306b</span></span> <span class="giallo-l"><span>0x0ec857faba49392080b68dd5074d85f34724d04a</span></span> <span class="giallo-l"><span>0x0f5054f9c674b37d15915ca8925f231edb3afa8c</span></span> <span class="giallo-l"><span>0x0f78d535e1faad9a982dca2a76d16da4649f7021</span></span> <span class="giallo-l"><span>0x104c5b235166f26df54f52666d5e77d9e03e353e</span></span> <span class="giallo-l"><span>0x106b47175965b6d607008544267c91490672a54f</span></span> <span class="giallo-l"><span>0x1223d5c03b4d52ebed43f781251098c9138c3dd7</span></span> <span class="giallo-l"><span>0x1251d13cde439378349f039379e83c2641b6269f</span></span> <span class="giallo-l"><span>0x12c814cebee6bb08a5d1b9d009332bf8b536d645</span></span> <span class="giallo-l"><span>0x150c63df3da35e590a6d2f7accf2e6f241ea5f1a</span></span> <span class="giallo-l"><span>0x15ddf20e4eb8b53b823bc45c9bad2670aad907dd</span></span> <span class="giallo-l"><span>0x1712b1c428f89bc695b1871abfff6b5097350150</span></span> <span class="giallo-l"><span>0x178df2e27b781f024e90ab0abe9cff7e2f66a5fc</span></span> <span class="giallo-l"><span>0x1c2bd83dc29095173c4bcc14927811f5141c1373</span></span> <span class="giallo-l"><span>0x1d12f2fad3603ea871fcb13ac3e30674f9ad903f</span></span> <span class="giallo-l"><span>0x1f7391b6881b6f025aef25cff737ff3fcb9d7660</span></span> <span class="giallo-l"><span>0x219a3d724f596a4b75656e9b1569289c71782804</span></span> <span class="giallo-l"><span>0x21a7fd9228c46ec72f926978f791fc8bfcd277fa</span></span> <span class="giallo-l"><span>0x23acb760cebd01fe7c92361274a4077d37b59f4c</span></span> <span class="giallo-l"><span>0x23b249eeeeedd86bc40349f8bb8e2df34bd28f78</span></span> <span class="giallo-l"><span>0x28d006b1a2309e957005ee575f422af8034f93df</span></span> <span class="giallo-l"><span>0x28ef72d5614b2833d645aecf8ef7add075eb21e2</span></span> <span class="giallo-l"><span>0x292966802ffedb6f34f2c8c59df35c9d8f612c24</span></span> <span class="giallo-l"><span>0x2c2661ddd320017138075aba06999440a902695f</span></span> <span class="giallo-l"><span>0x2c632be2dc2f47affd07bfce91bd4a27c02f4563</span></span> <span class="giallo-l"><span>0x2f86de22ced85a7dd0d680fc4266929a72775e27</span></span> <span class="giallo-l"><span>0x2fa04f15123025ab487dce71668f5265649d0598</span></span> <span class="giallo-l"><span>0x30f78fd12c17855453e0db166fecf684bb239b8c</span></span> <span class="giallo-l"><span>0x31534e95353323209cd18ad35c22c2528db6d164</span></span> <span class="giallo-l"><span>0x336e0e1a14e0136c02bf8dcf0a9a3fe408548262</span></span> <span class="giallo-l"><span>0x340399588bba5b843883d1ad7afd771a3651447a</span></span> <span class="giallo-l"><span>0x341d2b82d0924ef42d75ce053654295d34839459</span></span> <span class="giallo-l"><span>0x34c2b8975b47e13818f496cf80b40566798cf968</span></span> <span class="giallo-l"><span>0x370e67f45db9c18d6551000e6c0918bc8d346ebf</span></span> <span class="giallo-l"><span>0x37149dae898296173d309f1de6981922ec1dc495</span></span> <span class="giallo-l"><span>0x377cb0d3427af7f06df47d2ab420458834bed1fc</span></span> <span class="giallo-l"><span>0x3d473af3e6ce45183c781b414e8a9edcb8b26f72</span></span> <span class="giallo-l"><span>0x42794c1d807079e16735e47e193825cec80ee28c</span></span> <span class="giallo-l"><span>0x45603aa97b67965b42b38ddc8884373edbcf2d56</span></span> <span class="giallo-l"><span>0x465cb9df2f6d3c8a1c1ce3f2338823f0638fefa5</span></span> <span class="giallo-l"><span>0x49fbe69c2897bce0340b5983a0f719213a8c6e6f</span></span> <span class="giallo-l"><span>0x4a84cbd3ef642e301aa59bedf4fa4d28e24e6204</span></span> <span class="giallo-l"><span>0x4d4d551bd6244b854e732572902f19f4ccaa6996</span></span> <span class="giallo-l"><span>0x4f62af4ec150ea121859b3368e6a61fb7bcf9002</span></span> <span class="giallo-l"><span>0x4fd1c530f73ddfff5c609a4a8b25af6ca489d1fd</span></span> <span class="giallo-l"><span>0x50010a4f0e429b398c66876dea7694d5f8b1a639</span></span> <span class="giallo-l"><span>0x522c9f65bc77ad9eed6bcdc3ec220236451c9583</span></span> <span class="giallo-l"><span>0x52b30ca3c2f8656e2c022e896bef7fad9a0449ca</span></span> <span class="giallo-l"><span>0x537a7030ecd9d159e8231ce31b0c2e83b4f9ed75</span></span> <span class="giallo-l"><span>0x5483a4c5583d5ba3db23676a3db346f47ba357e1</span></span> <span class="giallo-l"><span>0x55ec1a78a1187428dc0c67cbb77ae9fbdd61cc2a</span></span> <span class="giallo-l"><span>0x56cc1c0aadc2b8beb71f1ac61f03645483abe165</span></span> <span class="giallo-l"><span>0x58bea8cea61fad5c453731aaeed377f3d77a04cc</span></span> <span class="giallo-l"><span>0x58f632327fbc4f449bda3bd51e13f590e67a8627</span></span> <span class="giallo-l"><span>0x59d122afcbd68c731de85c2597004c6ddafbc7ed</span></span> <span class="giallo-l"><span>0x5da0228024cc084b9475470a7b7ae1d478d51bb7</span></span> <span class="giallo-l"><span>0x5e51d6621883afcbd4e999b93180a96909bdc766</span></span> <span class="giallo-l"><span>0x5e9a0a1bdfdd868706f4554aae21bb2c46da32c2</span></span> <span class="giallo-l"><span>0x5f3f0d3215db85faa693d99acfb03cca66556671</span></span> <span class="giallo-l"><span>0x5f6aa25f22edb2347b464312e2508cbc4c6e0162</span></span> <span class="giallo-l"><span>0x6006f79e4104850ab7c9b0f75918c1e2cf6311df</span></span> <span class="giallo-l"><span>0x60f5da58bccb716f58b5759a06fc2167fe237c26</span></span> <span class="giallo-l"><span>0x62d3a444d0af59f9de79f8abeb5c942fcfbfbef5</span></span> <span class="giallo-l"><span>0x630ea66c8c5dc205d45a978573fa86df5af1fe7a</span></span> <span class="giallo-l"><span>0x6464f0f96a29934087a955c67a6b53d5ed852e49</span></span> <span class="giallo-l"><span>0x6653cedb0b7f51c4b0c44079eb45c514df24ecfd</span></span> <span class="giallo-l"><span>0x66d69ac12b573299f36b108792be75a1e2ccdfdc</span></span> <span class="giallo-l"><span>0x690ed837d25b46dbf46727fcda7392d997c2bc97</span></span> <span class="giallo-l"><span>0x696eecbc97189c5b2a8245a8e32517db9960c171</span></span> <span class="giallo-l"><span>0x69aaff0b7babe85e0a95adfc540e689399db7f24</span></span> <span class="giallo-l"><span>0x6b71d2ceab5678b607aa1e69b6781f5c7abc9aaf</span></span> <span class="giallo-l"><span>0x6e03d9cce9d60f3e9f2597e13cd4c54c55330cfd</span></span> <span class="giallo-l"><span>0x6e278cfecfe96fa5e6d5411ba6eeb765dff4f118</span></span> <span class="giallo-l"><span>0x6e557f01c9dcb573b03909c9a5b3528aec263472</span></span> <span class="giallo-l"><span>0x6ec268f8bef9c685d7e04d5cdb61fbb544869a9f</span></span> <span class="giallo-l"><span>0x6f2ba051b3ce06a90705c22e0241c2b7e32c1af0</span></span> <span class="giallo-l"><span>0x7063732ced55cfa08aea520f3fe200c39b3df0f5</span></span> <span class="giallo-l"><span>0x7073a17a0172dfb1e46a62f054d11a775aeac32e</span></span> <span class="giallo-l"><span>0x71d3718cfa0f9ee8173688fe52bb499e1f36534b</span></span> <span class="giallo-l"><span>0x74e20aec156674945894d404f8dea602570e62f5</span></span> <span class="giallo-l"><span>0x783e45c2989e675ffc9d067914d7de3ff68aee58</span></span> <span class="giallo-l"><span>0x7a5f843f884bb15d070806e1ff59b6c6f74bbe2d</span></span> <span class="giallo-l"><span>0x7c6b1706c86ea76a0e232324f249e1508ca2dfda</span></span> <span class="giallo-l"><span>0x7d23a23584c83c1f6636124255cfd8e9cfc0e529</span></span> <span class="giallo-l"><span>0x7e8b5df0dec9168741c93d52d7045aca7ea632d3</span></span> <span class="giallo-l"><span>0x7ec5da0f1036750688084252b802befe41551205</span></span> <span class="giallo-l"><span>0x82c9fcef4dd2d374b000063d4899a38a7219cdc7</span></span> <span class="giallo-l"><span>0x82fa2ab30a566ceeac987eb5510485be9382f130</span></span> <span class="giallo-l"><span>0x83d927aca3266f94e8163eaa32700c70e9b76e6e</span></span> <span class="giallo-l"><span>0x8476f7e193c930f21e88dae84888e0d8bfaf3ed8</span></span> <span class="giallo-l"><span>0x85ec166cb81f5010b4a8d365821473dac0c0aa88</span></span> <span class="giallo-l"><span>0x8883c55943d5caf06b6484de9c1d73da8307cd82</span></span> <span class="giallo-l"><span>0x8c07456cffd4254c89aaaa9d4e95c8b3e36c2a3b</span></span> <span class="giallo-l"><span>0x8fef965e5db6f7f1a165008499e8b7901cd766b2</span></span> <span class="giallo-l"><span>0x9018e2967c15e1faed9b5d6439522f075535a683</span></span> <span class="giallo-l"><span>0x903f1d8a086c6af1afe24648b6409aade83c4340</span></span> <span class="giallo-l"><span>0x9127c398827d8db6b6d5f17b71f5db69d06e8b74</span></span> <span class="giallo-l"><span>0x917b5be6e3acd96d40a33c13e6748e4a88576c6d</span></span> <span class="giallo-l"><span>0x91edfd05112f0bc9d6cd43b65361713a50e9eb7f</span></span> <span class="giallo-l"><span>0x93026a2c4a0bc69de31515070bf086e0c1f789e5</span></span> <span class="giallo-l"><span>0x94863bbbc12ec5be148f60a7020fd49236fc1937</span></span> <span class="giallo-l"><span>0x94befc001e203f141462f16bde60873bcefae401</span></span> <span class="giallo-l"><span>0x94c408cf5934f241d4fdd55ff3825131635c6af2</span></span> <span class="giallo-l"><span>0x94cfdec548de92301735dc0b82d8e1f79404ff94</span></span> <span class="giallo-l"><span>0x96527f3311f44340887c926acc16f0997eb3b955</span></span> <span class="giallo-l"><span>0x974117faf194885c01513e8d87b38a2291083ed5</span></span> <span class="giallo-l"><span>0x993424827a5fb2fa97818814ea4027e28150f187</span></span> <span class="giallo-l"><span>0x9a6f30a5cb46840076edd780da2dbb4bc7c39f24</span></span> <span class="giallo-l"><span>0x9a74a096b0bb82adfd28494107f2c07f4545723e</span></span> <span class="giallo-l"><span>0x9af82ec46185641c0ea44679aac8a7e7570be202</span></span> <span class="giallo-l"><span>0x9e2287a60ed85f6bd80c62c1b7b4130ea1b521dd</span></span> <span class="giallo-l"><span>0x9fee5b81ee0cbf34c18c52061f1b257d4ccb2702</span></span> <span class="giallo-l"><span>0xa017226377e775af8e56450301cc035ae72267f8</span></span> <span class="giallo-l"><span>0xa1b423e024daf925f25296ea2efcf009cc328873</span></span> <span class="giallo-l"><span>0xa23c0cbfe59e8650277ffa635c59f287cece9087</span></span> <span class="giallo-l"><span>0xa340b7625eec76b372f2c317fe08a7733f05d09c</span></span> <span class="giallo-l"><span>0xa4cb6be13c2eace6c0f1157553e3c446f7b38b10</span></span> <span class="giallo-l"><span>0xa54326267784fae3ffd6800af38099753bb7f470</span></span> <span class="giallo-l"><span>0xa580086125d040fddd3af9d563285bd0ec4d13e3</span></span> <span class="giallo-l"><span>0xa88fc7a34ca36b952aa45d94c1e13155042b5e7d</span></span> <span class="giallo-l"><span>0xac8f4ce2e4eff39c738bf1941350b3b57e8eec4f</span></span> <span class="giallo-l"><span>0xacb17dca110db022b1aceb5399acba1e9bf577e3</span></span> <span class="giallo-l"><span>0xae0b03c8d8bf9cf71eda758e9e8b59c70a3b4580</span></span> <span class="giallo-l"><span>0xae365ff4b0c64413baf6f7dfdb5cd3fb65ad1376</span></span> <span class="giallo-l"><span>0xaf7e60d02b425b54730b7281a97d1640233704b0</span></span> <span class="giallo-l"><span>0xaf9846f8098656e7c2f0e53e9ff7d38ec7b7f679</span></span> <span class="giallo-l"><span>0xb2784c0a95e9b6b865aca13556fb32e2f37cb775</span></span> <span class="giallo-l"><span>0xb385fa211cd08326ff84b0d4f37cc8c3735aa3aa</span></span> <span class="giallo-l"><span>0xb3fb883cbbccb0551daf1507f87426fd38da087e</span></span> <span class="giallo-l"><span>0xb6515cfb82fa877fbadae5a87006a8d3deeeb7c9</span></span> <span class="giallo-l"><span>0xb78c4f0b8c9ec0b3058724eca65292d0d65586b9</span></span> <span class="giallo-l"><span>0xba25f341e16ee81ab80ea246d45bdead7cc339e5</span></span> <span class="giallo-l"><span>0xbab14024437285c2e3b3c521abff96b0ef2e919f</span></span> <span class="giallo-l"><span>0xbaf0996297cc70fca1bee30162eabcd892f0574a</span></span> <span class="giallo-l"><span>0xbb01ea95321a94242c89479995b7e3f264cb46a0</span></span> <span class="giallo-l"><span>0xc1b37a3b7f76947e24cc2470e0e948aab0181346</span></span> <span class="giallo-l"><span>0xc24431c1a1147456414355b1f1769de450e524da</span></span> <span class="giallo-l"><span>0xc467b893e29277f9b62b4ed6c9ba054bd8225bff</span></span> <span class="giallo-l"><span>0xc4bc101a168ea2228973a65564a7d40a68528dd2</span></span> <span class="giallo-l"><span>0xc784626571c2c25cd2cfe24192a149cad86d40d8</span></span> <span class="giallo-l"><span>0xc7acf90a9f442855b8f291288bb5fb612536ed9b</span></span> <span class="giallo-l"><span>0xc9956593dbfb46cfd24686a365b34051a55abce6</span></span> <span class="giallo-l"><span>0xca2eb2af7dd7a90777c8c6456efcc00fe56dbd6f</span></span> <span class="giallo-l"><span>0xcb4bb078edaae9393c8da27b809aa9c0f4c920b7</span></span> <span class="giallo-l"><span>0xcc8f68e8e2d8196e2ecd0caf2f35b1611739a21f</span></span> <span class="giallo-l"><span>0xcd67903318a805d63fe79bf9b8401c1b79c6babf</span></span> <span class="giallo-l"><span>0xcd7a2fe9cb80c95b03950daf5b6d476bec9ac24d</span></span> <span class="giallo-l"><span>0xd09476f5ee7979becca8ffe6dc22a72565fc3cea</span></span> <span class="giallo-l"><span>0xd1c4bd2b583f445354d1b644ea4b8353f2d23048</span></span> <span class="giallo-l"><span>0xd32bb8bceafc89ff59ba43ce8b6cd65bb06dd7b0</span></span> <span class="giallo-l"><span>0xd49e9fa792db9d9398c57eabf94ba1b2c709ace7</span></span> <span class="giallo-l"><span>0xd6b862cf0d009bde0f020ab9d8f96e475069c5c6</span></span> <span class="giallo-l"><span>0xd747c05d9c8057db608ef7aedabf07e4db0bbe97</span></span> <span class="giallo-l"><span>0xdb9b40d1b691ced3680e539261b6bc195388b3c0</span></span> <span class="giallo-l"><span>0xdbcc502093cadd0feb709708c633e2427aeb9c2d</span></span> <span class="giallo-l"><span>0xdc53001181ddc6a279deea6419443ea0ac0aec9c</span></span> <span class="giallo-l"><span>0xde3b38cb1050e7b5db39b4cbb2b2b63a1e32cbf6</span></span> <span class="giallo-l"><span>0xdf1b687a99216ad4ebf9176983bf165be7b25bbe</span></span> <span class="giallo-l"><span>0xe000662c02a02d8b40aabfcd661594312992311d</span></span> <span class="giallo-l"><span>0xe30c59e4dc19d7c9ed6eb10d734d4d7ef28403ac</span></span> <span class="giallo-l"><span>0xe415114089b4b4933e542a5c79af4b6e6cd7abc9</span></span> <span class="giallo-l"><span>0xe47f0a0e93241d390fe9b99de852682522e847bc</span></span> <span class="giallo-l"><span>0xe54abbd51e324bf8cf349b6b31c01b043d1ee0e4</span></span> <span class="giallo-l"><span>0xe57838f777b11fdc428d9e7e67f1187d6251ba1f</span></span> <span class="giallo-l"><span>0xe5e4b26325d0fbf551367f2cf3b5d01caed6abcf</span></span> <span class="giallo-l"><span>0xe6655208bd812d833238b560e847014b0aab3b51</span></span> <span class="giallo-l"><span>0xe6e16a1023af4a8fe54669f3fce7c406801bb333</span></span> <span class="giallo-l"><span>0xe727bba699fbe82a731dad9476b5234d0038cfa1</span></span> <span class="giallo-l"><span>0xec361d34a55e24e2f77de7121ae2b7bf11ed0d65</span></span> <span class="giallo-l"><span>0xed3bf94976eb11d55b955d1369a478620872b57c</span></span> <span class="giallo-l"><span>0xee93ad447fe6a0e2bbac4952e651b21c0175acad</span></span> <span class="giallo-l"><span>0xefc5d9cabc0bda8124e1b821e8c86c7e7bf1e4bc</span></span> <span class="giallo-l"><span>0xf272f72a00f166f491d994642c8243099b72d2cd</span></span> <span class="giallo-l"><span>0xf45f642034bbce869e31b05d1da919125c7331ee</span></span> <span class="giallo-l"><span>0xf4883b21724405b19e240f3309a64d16dd89adc7</span></span> <span class="giallo-l"><span>0xf5cb2a87ff1095f6d93e7b4bfc1bc47542380550</span></span> <span class="giallo-l"><span>0xf6ddd386c4f7f0b460032c8055d7f9c3503d7140</span></span> <span class="giallo-l"><span>0xf72093096c81b3e9e991f5b737baec9570a56927</span></span> <span class="giallo-l"><span>0xf7412232a7a731bca2e5554c8ee051274373c17c</span></span> <span class="giallo-l"><span>0xfc2321dc32c2e6e96a0e41c911fb73a7b278d5c8</span></span> <span class="giallo-l"><span>0xfc4dc782bf7e81a2ed5cc0519f80de36e7931bd9</span></span> <span class="giallo-l"><span>0xfcde1c261eb257e14491b4e7cb1949a7623c00c5</span></span> <span class="giallo-l"><span>0xfd17a22fd80075f2716e93268aa01bcdd7d70b22</span></span></code></pre> </details> </li> </ul> <h2 id="rationale">Rationale</h2> <p>EIP-161 provides that empty accounts (accounts that have zero nonce, zero balance and no code, but that might have storage) can no longer be created and provides mechanism to remove old empty accounts. The last empty accounts were removed in block 14049881 (tx <code>0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d</code>).</p> <p>The complete removal of all empty accounts ensures that certain edgecases of EIP-161 can never occur on Ethereum Mainnet. Continuing to define and test those cases as part of the Ethereum Specification burdens future client implementors with unnecessary technical debt. This EIP declares those cases undefined and leaves clients free to assume they will not occur.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is identical to EIP-161 except for the following differences, none of which affect Ethereum Mainnet. The differences are:</p> <h3 id="potentially-state-changing-operations">"Potentially state-changing operations"</h3> <p>EIP-161 specifies 11 "potentially state-changing operations" that trigger state clearing. All but the 3 listed in this EIP are irrelevant, for the following reasons:</p> <h4 id="impossible">Impossible</h4> <ul> <li>Receiving zero value mining reward/fees (this would become possible after the merge).</li> </ul> <h4 id="cannot-happen-to-an-empty-account">Cannot happen to an empty account</h4> <ul> <li>Being the source of a <code>CREATE</code>.</li> <li>Being the source of a <code>CALL</code>.</li> <li>Being refunded by a <code>SELFDESTRUCT</code></li> </ul> <h4 id="causes-the-account-to-become-non-empty">Causes the account to become non-empty</h4> <ul> <li>Being the sender of a message call transaction.</li> <li>Being the sender of a contract creation transaction.</li> <li>Being created by a <code>CREATE</code>.</li> <li>Being created by a contract creation transaction.</li> </ul> <h3 id="interaction-with-staticcall">Interaction with <code>STATICCALL</code></h3> <p>The interaction between <code>STATICCALL</code> and account clearing has never been specified in an EIP. The Ethereum currently testsuite requires that <code>STATICCALL</code> triggers state clearing.</p> <p>This EIP formally undefines all interactions between <code>STATICCALL</code> and state clearing as it has never happened on Ethereum Mainnet and cannot happen in future.</p> <h3 id="at-the-end-of-the-transaction">"At the end of the transaction"</h3> <p>This only makes a difference if an account is deleted and later recreated in the same transaction. This never happens on Ethereum Mainnet.</p> <h3 id="test-cases">Test Cases</h3> <p>All test cases involving empty accounts in the Ethereum execution layer test suite shall be removed unless they relate to the Spurious Dragon Hardfork. If a Spurious Dragon test relates involved deprecated edgecase the test must be removed or reworked.</p> <h3 id="other-networks">Other networks</h3> <p>Ropsten had empty accounts seeded at genesis. They appear to have been cleared early in Ropsten's history before the Byzantium hardfork. Ropsten has never been checked for edgecases occurring. All other Ethereum testnets have had EIP-161 from genesis.</p> <p>As a security precaution all empty accounts on Ethereum Classic have been cleared, but no checks for edgecases occurring have been done. Due to EIP-161's age the vast majority of EVM compatible networks have supported it from genesis.</p> <h2 id="security-considerations">Security considerations</h2> <p>This EIP is only equivalent to EIP-161 on Ethereum Mainnet if the following facts are true:</p> <ol> <li>No empty accounts are ever touched and then reinstated in the same transaction.</li> <li>The transactions in the Appendix are the only state clearing transactions on Ethereum Mainnet after block 4370000 (start of Byzantium).</li> <li>All empty accounts have been removed on Ethereum Mainnet.</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-02-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/4803/

Valid transactions must have a reasonable gas limit

<h2 id="abstract">Abstract</h2> <p>Limit transaction gas to be between <code>0</code> and <code>2^63-1</code>.</p> <h2 id="motivation">Motivation</h2> <p>The gas limit field in the transaction is specified to be an arbitrary long unsigned integer, but various clients put limits on this value. This EIP brings a reasonable limit into consensus.</p> <h2 id="specification">Specification</h2> <p>Introduce one new restriction retroactively from genesis: any transaction is invalid and not includeable in a block, where the gas limit exceeds <code>2^63-1</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="2-63-1-vs-2-64-1"><code>2^63-1</code> vs <code>2^64-1</code></h3> <p><code>2^63-1</code> is chosen because it allows representing the gas value as a signed integer, and so the out of gas check can be done as a simple "less than zero" check after subtraction.</p> <h3 id="consider-2-31-1">Consider <code>2^31-1</code></h3> <p>An alternative is considering a lower limit, because this can be handled easily in Javascript, since it handles numbers as floating point (the actual upper bound is <code>2^53-1</code>).</p> <h3 id="current-limit">Current limit</h3> <p>Due to the nature of RLP encoding, there is no fixed upper bound for the value, but most implementations limit it to 256-bits. Furthermore, most client implementations (such as geth) internally handle gas as a 64-bit value.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>While this is a breaking change, no actual effect should be visible.</p> <p>Before <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> it was possible to include transactions with <code>gasPrice = 0</code> and thus the <code>gasLimit * gasPrice &lt;= accountBalance</code> calculation could have allowed for arbitrarily large values of <code>gasLimit</code>. However, the rule that the transaction list cannot exceed the block gas limit, and the strict rules about how the block gas limit can change, prevented arbitrarily large values of <code>gasLimit</code> to be in the historical state.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2022-01-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Andrei Maiborodahttps://github.com/gumb0 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/4750/

Individual sections for functions with `CALLF` and `RETF` instructions

<h2 id="abstract">Abstract</h2> <p>Introduce the ability to have several code sections in EOF-formatted (<a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>) bytecode, each one representing a separate subroutine/function. Two new opcodes,<code>CALLF</code> and <code>RETF</code>, are introduced to call and return from such a function. Dynamic jump instructions are disallowed.</p> <h2 id="motivation">Motivation</h2> <p>Currently, in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, <code>PUSHn .. JUMP</code>). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.</p> <p><a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a> introduces static jump instructions, which remove the need for <em>most</em> dynamic jump use cases, but not everything can be solved with them.</p> <p>This EIP aims to remove the need and disallow dynamic jumps as it offers the most important feature those are used for: calling into and returning from functions.</p> <p>Furthermore, it aims to improve analysis opportunities by encoding the number of inputs and outputs for each given function, and isolating the stack of each function (i.e. a function cannot read the stack of the caller/callee).</p> <h2 id="specification">Specification</h2> <h3 id="type-section">Type Section</h3> <p>The type section of EOF containers must adhere to following requirements:</p> <ol> <li>The section is a list of metadata where the metadata index in the type section corresponds to a code section index. Therefore, the type section size MUST be <code>n * 4</code> bytes, where <code>n</code> is the number of code sections.</li> <li>Each metadata item has 3 attributes: a uint8 <code>inputs</code>, a uint8 <code>outputs</code>, and a uint16 <code>max_stack_increase</code>. <em>Note:</em> This implies that there is a limit of 255 stack for the input and in the output. This is further restricted to 127 stack items, because the upper bit of both the input and output bytes are reserved for future use (<code>outputs == 0x80</code> is already used in EOF1 to denote non-returning functions, as introduced in a separate EIP). <code>max_stack_increase</code> is further defined in <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a>.</li> <li>The 0th code section MUST have 0 inputs and be non-returning.</li> </ol> <p>Refer to <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> to see the full structure of a well-formed EOF bytecode.</p> <h3 id="new-execution-state-in-evm">New execution state in EVM</h3> <p>A return stack is introduced, separate from the operand stack. It is a stack of items representing execution state to return to after function execution is finished. Each item is comprised of code section index and offset in the code section (PC value).</p> <p>Note: Implementations are free to choose particular encoding for a stack item. In the specification below we assume that representation is two unsigned integers: <code>code_section_index</code>, <code>offset</code>.</p> <p>The return stack is limited to a maximum of <code>1024</code> items.</p> <p>Additionally, EVM keeps track of the index of currently executing section - <code>current_section_index</code>.</p> <h3 id="new-instructions">New instructions</h3> <p>We introduce two new instructions:</p> <ol> <li><code>CALLF</code> (<code>0xe3</code>) - call a function</li> <li><code>RETF</code> (<code>0xe4</code>) - return from a function</li> </ol> <p>If the code is legacy bytecode, any of these instructions results in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <p>First we define several helper values:</p> <ul> <li><code>type[i].inputs = type_section_contents[i * 4]</code> - number of inputs of ith code section</li> <li><code>type[i].outputs = type_section_contents[i * 4 + 1]</code> - number of outputs of ith code section</li> <li><code>type[i].max_stack_increase = type_section_contents[i * 4 + 2:i * 4 + 4]</code> - maximum operand stack height increase of ith code section</li> </ul> <p>If the code is valid EOF1, the following execution rules apply:</p> <h4 id="callf"><code>CALLF</code></h4> <ol> <li> <p>Has one immediate argument,<code>target_section_index</code>, encoded as a 16-bit unsigned big-endian value.</p> </li> <li> <p><em>Note:</em> EOF validation <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a> guarantees that operand stack has enough items to use as callee's inputs.</p> </li> <li> <p>If operand stack size exceeds <code>1024 - type[target_section_index].max_stack_increase</code> (i.e. if the called function may exceed the global stack height limit), execution results in exceptional halt. This also guarantees that the stack height after the call is within the limits.</p> </li> <li> <p>If return stack already has <code>1024</code> items, execution results in exceptional halt.</p> </li> <li> <p>Charges <code>5</code> gas.</p> </li> <li> <p>Pops nothing and pushes nothing to operand stack.</p> </li> <li> <p>Pushes to return stack an item:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(code_section_index = current_section_index, </span></span> <span class="giallo-l"><span>offset = PC_post_instruction)</span></span></code></pre> <p>Under <code>PC_post_instruction</code> we mean the PC position after the entire immediate argument of <code>CALLF</code>.</p> <p><em>Note:</em> EOF validation <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a> guarantees there is always an instruction following <code>CALLF</code> (since terminating instruction or unconditional jump is required to be final one in the section), therefore <code>PC_post_instruction</code> always points to an instruction inside section bounds.</p> </li> <li> <p>Sets <code>current_section_index</code> to <code>target_section_index</code> and <code>PC</code> to <code>0</code>, and execution continues in the called section.</p> </li> </ol> <h4 id="retf"><code>RETF</code></h4> <ol> <li>Does not have immediate arguments.</li> <li><em>Note:</em> EOF validation <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a> guarantees that operand stack has exact number of items to use as outputs.</li> <li>Charges <code>3</code> gas.</li> <li>Pops nothing and pushes nothing to operand stack.</li> <li>Pops an item from return stack and sets <code>current_section_index</code> and <code>PC</code> to values from this item.</li> </ol> <p><em>Note:</em> EOF validation requirement for 0th code section to be non-returning (non-returning sections introduced in a separate EIP) guarantees that return stack cannot be empty before <code>RETF</code>.</p> <h3 id="code-validation">Code Validation</h3> <p>In addition to container format validation rules above, we extend code section validation rules (as defined in <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>).</p> <ol> <li>Code validation rules of <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> are applied to every code section.</li> <li>Code section is invalid in case an immediate argument of any <code>CALLF</code> is greater than or equal to the total number of code sections.</li> <li><code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPV</code> immediate argument value (jump destination relative offset) validation: <ol> <li>Code section is invalid in case offset points to a position outside of section bounds.</li> <li>Code section is invalid in case offset points to one of two bytes directly following <code>CALLF</code> instruction.</li> </ol> </li> <li>No unreachable code sections are allowed, i.e. every code section can be reached from the 0th code section with a series of <code>CALLF</code> / <code>JUMPF</code> (<code>JUMPF</code> introduced in a separate EIP) instructions (0th code section is always reachable).</li> </ol> <h3 id="disallowed-instructions">Disallowed instructions</h3> <p>Dynamic jump instructions <code>JUMP</code> (<code>0x56</code>) and <code>JUMPI</code> (<code>0x57</code>) are invalid and their opcodes are undefined.</p> <p><code>JUMPDEST</code> (<code>0x5b</code>) instruction is renamed to <code>NOP</code> ("no operation") without the change in behaviour: it pops nothing and pushes nothing to operand stack and has no other effects except for <code>PC</code> increment and charging 1 gas.</p> <p><code>PC</code> (0x58) instruction becomes invalid and its opcode is undefined.</p> <p><em>Note:</em> This change implies that JUMPDEST analysis is no longer required for EOF code.</p> <h3 id="execution">Execution</h3> <ol> <li>Execution starts at the first byte of the 0th code section, and <code>PC</code> is set to <code>0</code>.</li> <li>Return stack is initialized empty.</li> <li>Stack underflow check is not performed anymore. <em>Note:</em> EOF validation <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a> guarantees that it cannot happen at run-time.</li> <li>Stack overflow check is not performed anymore, except during <code>CALLF</code> as specified above.</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="retf-in-the-top-frame-ends-execution-vs-exceptionally-halts-vs-is-not-allowed-during-validation"><code>RETF</code> in the top frame ends execution vs exceptionally halts vs is not allowed during validation</h3> <p>Alternative logic for <code>RETF</code> in the top frame could be to allow it during code validation and make it either:</p> <ul> <li>end execution if the return stack is emptied by the <code>RETF</code> or</li> <li>exceptionally halt if the return stack is empty before the <code>RETF</code>.</li> </ul> <p>This has been superseded with the validation rule of top frame (0th code section) being non-returning (non-returning sections introduced in a separate EIP), because validating non-returning status of functions is valuable by itself for other reasons. Therefore all considerations of runtime behavior of <code>RETF</code> in the top frame were obsoleted.</p> <h3 id="minimal-function-type">"Minimal" function type</h3> <p>Let's consider a trivial function with single instruction <code>RETF</code>. Such function have the "minimal" type of <code>inputs = 0, outputs = 0</code>. However, any other type like <code>inputs = k, outputs = k</code> is also valid for such function. It has been considered to enforce usage of the "minimal" type for all functions. This requires additional validation rule that checks if any instruction in the function accesses the bottom stack operand. This rule can be obeyed by compilers, but causes quite significant annoyance. On the other hand, it provides close to zero benefits for the EVM implementations. In the end, it has been decided that this is not enforced.</p> <h3 id="code-section-limit-and-instruction-size">Code section limit and instruction size</h3> <p>The number of code sections is limited to 1024. This requires 2-byte immediate for <code>CALLF</code> and leaves room for increasing the limit in the future. The 256 limit (1-byte immediate) was discussed and concerns were raised that it might not be sufficient.</p> <h3 id="nop-instruction"><code>NOP</code> instruction</h3> <p>Instead of deprecating <code>JUMPDEST</code> we repurpose it as <code>NOP</code> instruction, because <code>JUMPDEST</code> effectively was a "no-operation" instruction and was already used as such in various contexts. It can be useful for some off-chain tooling, e.g. benchmarking EVM implementations (performance of <code>NOP</code> instruction is performance of EVM interpreter loop), as a padding to force code alignment, as a placeholder in dynamic code composition.</p> <h3 id="deprecating-jumpdest-analysis">Deprecating <code>JUMPDEST</code> analysis</h3> <p>The purpose of <code>JUMPDEST</code> analysis was to find in code the valid <code>JUMPDEST</code> bytes that do not happen to be inside <code>PUSH</code> immediate data. Only dynamic jump instructions (<code>JUMP</code>, <code>JUMPI</code>) required destination to be <code>JUMPDEST</code> instruction. Relative static jumps (<code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPV</code>) do not have this requirement and are validated once at deploy-time during EOF instructions validation. Therefore, without dynamic jump instructions, <code>JUMPDEST</code> analysis is not required.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).</p> <p>The new execution state and multi-section control flow pose no risk to backwards compatibility, because it is a generalization of executing a single code section. Executing existing contracts (both legacy and EOF1) has no user-observable changes.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The gas cost of introduced instructions reflects the need to manipulate return stack entries and jumping to proper code section offset in memory when interpreting the bytecode.</p> <p>These new instructions need to be carefully considered during implementation of the EOF container validation algorithm.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-12-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Greg Colvinhttps://github.com/gcolvin Greg Colvingreg@colvin.org https://wg-eips.ritovision.com/4573/

Introduces support for EVM Procedures.

<h2 id="abstract">Abstract</h2> <p>Five EVM instructions are introduced to define, call, and return from named EVM <em>procedures</em> and access their <em>call frames</em> in memory - <code>ENTERPROC</code>, <code>LEAVEPROC</code>, <code>CALLPROC</code>, <code>RETURNPROC</code>, and <code>FRAMEADDRESS</code>.</p> <h2 id="motivation">Motivation</h2> <p>Currently, Ethereum bytecode has no syntactic structure, and <em>subroutines</em> have no defined interfaces.</p> <p>We propose to add <em>procedures</em> -- delimited blocks of code that can be entered only by calling into them via defined interfaces.</p> <p>Also, the EVM currently has no automatic management of memory for <em>procedures</em>. So we also propose to automatically reserve call frames on an in-memory stack.</p> <p>Constraints on the use of <em>procedures</em> must be validated at contract initialization time to maintain the safety properties of <a href="https://wg-eips.ritovision.com/3779/">EIP-3779</a>: Valid programs will not halt with an exception unless they run out of gas or recursively overflow stack.</p> <h3 id="prior-art">Prior Art</h3> <p>The terminology is not well-defined, but we will follow Intel in calling the low-level concept <em>subroutines</em> and the higher level concept <em>procedures</em>. The distinction is that <em>subroutines</em> are little more than a jump that knows where it came from, whereas procedures have a defined interface and manage memory as a stack. <a href="https://wg-eips.ritovision.com/2315/">EIP-2315</a> introduces <em>subroutines</em>, and this EIP introduces <em>procedures</em>.</p> <h2 id="specification">Specification</h2> <h3 id="instructions">Instructions</h3> <h4 id="enterproc-0x-dest-section-uint8-dest-offset-uint8-n-inputs-uint16-n-outputs-uint16-n-locals-uint16">ENTERPROC (0x??) dest_section: uint8, dest_offset: uint8, n_inputs: uint16, n_outputs: uint16, n_locals: uint16</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>frame_stack.push(FP)</span></span> <span class="giallo-l"><span>FP -= n_locals * 32</span></span> <span class="giallo-l"><span>PC +- &lt;length of immediates&gt;</span></span></code></pre> <p>Marks the entry point to a procedure</p> <ul> <li>at offset <code>dest_offset</code> from the beginning of the <code>dest_section</code>.</li> <li>taking <code>n_inputs</code> arguments from the data stack,</li> <li>returning <code>n_outputs</code> values on the <code>data stack</code>, and</li> <li>reserving <code>n_locals</code> words of data in memory on the <code>frame stack</code>.</li> </ul> <p>Procedures can only be entered via a <code>CALLPROC</code> to their entry point.</p> <h4 id="leaveproc-0x">LEAVEPROC (0x??)</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> FP = frame_stack.pop()</span></span> <span class="giallo-l"><span> asm RETURNSUB</span></span></code></pre> <blockquote> <p>Pop the <code>frame stack</code> and return to the calling procedure using <code>RETURNSUB</code>.</p> </blockquote> <p>Marks the end of a procedure. Each <code>ENTERPROC</code> requires a closing <code>LEAVEPROC</code>.</p> <p><em>Note: Attempts to jump into a procedure (including its <code>LEAVEPROC</code>) from outside of the procedure or to jump or step to <code>ENTERPROC</code> at all must be prevented at validation time. <code>CALLPROC</code> is the only valid way to enter a procedure.</em></p> <h4 id="callproc-0x-dest-section-uint16-dest-proc-uint16">CALLPROC (0x??) dest_section: uint16, dest_proc: uint16</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> FP -= n_locals</span></span> <span class="giallo-l"><span> asm JUMPSUB &lt;offset of section&gt; + &lt;offset of procedure&gt;</span></span></code></pre> <blockquote> <p>Allocate a <em>stack frame</em> and transfer control and <code>JUMPSUB</code> to the Nth (N=<em>dest_proc</em>) <em>procedure</em> in the Mth(M=<em>dest_section</em>) <em>section</em> of the code. <em>Section 0</em> is the current code section, any other code sections are indexed starting at <em>1</em>.</p> </blockquote> <p><em>Note: That the procedure is defined and the required <code>n_inputs</code> words are available on the <code>data stack</code> must be shown at validation time.</em></p> <h4 id="returnproc-0x">RETURNPROC (0x??)</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> FP += n_locals</span></span> <span class="giallo-l"><span> asm RETURNSUB</span></span></code></pre> <blockquote> <p>Pop the <code>frame stack</code> and return control to the calling procedure using <code>RETURNSUB</code>.</p> </blockquote> <p><em>Note: That the promised <code>n_outputs</code> words are available on the <code>data stack</code> must be shown at validation time.</em></p> <h4 id="frameaddress-0x-offset-int16">FRAMEADDRESS (0x??) offset: int16</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>asm PUSH2 FP + offset</span></span></code></pre> <blockquote> <p>Push the address <code>FP + offset</code> onto the data stack.</p> </blockquote> <p>Call frame data is addressed at an immediate <code>offset</code> relative to <code>FP</code>.</p> <p>Typical usage includes storing data on a call frame</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xdada</span></span> <span class="giallo-l"><span>FRAMEADDRESS 32</span></span> <span class="giallo-l"><span>MSTORE</span></span></code></pre> <p>and loading data from a call frame</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>FRAMEADDRESS 32</span></span> <span class="giallo-l"><span>MLOAD</span></span></code></pre><h3 id="memory-costs">Memory Costs</h3> <p>Presently,<code>MSTORE</code> is defined as</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> memory[stack[0]...stack[0]+31] = stack[1]</span></span> <span class="giallo-l"><span> memory_size = max(memory_size,floor((stack[0]+32)÷32)</span></span></code></pre> <ul> <li>where <code>memory_size</code> is the number of active words of memory above <em>0</em>.</li> </ul> <p>We propose to treat memory addresses as signed, so the formula needs to be</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> memory[stack[0]...stack[0]+31] = stack[1]</span></span> <span class="giallo-l"><span> if (stack[0])+32)÷32) &lt; 0</span></span> <span class="giallo-l"><span> negative_memory_size = max(negative_memory_size,floor((stack[0]+32)÷32))</span></span> <span class="giallo-l"><span> else</span></span> <span class="giallo-l"><span> positive_memory_size = max(positive_memory_size,floor((stack[0]+32)÷32))</span></span> <span class="giallo-l"><span> memory_size = positive_memory_size + negative_memory_size</span></span></code></pre> <ul> <li>where <code>negative_memory_size</code> is the number of active words of memory below <em>0</em> and</li> <li>where <code>positive_memory_size</code> is the number of active words of memory at or above <em>0</em>.</li> </ul> <h3 id="call-frame-stack">Call Frame Stack</h3> <p>These instructions make use of a <code>frame stack</code> to allocate and free frames of local data for <em>procedures</em> in memory. Frame memory begins at address 0 in memory and grows downwards, towards more negative addresses. A frame is allocated for each procedure when it is called, and freed when it returns.</p> <p>Memory can be addressed relative to the frame pointer <code>FP</code> or by absolute address. <code>FP</code> starts at 0, and moves downward towards more negative addresses to point to the frame for each <code>CALLPROC</code> and moving upward towards less negative addresses to point to the previous frame for the corresponding <code>RETURNPROC</code>.</p> <p>Equivalently, in the EVM's twos-complement arithmetic, <code>FP</code> moves from the highest address down, as is common in many calling conventions.</p> <p>For example, after an initial <code>CALLPROC</code> to a procedure needing two words of data the <code>frame stack</code> might look like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 0-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> FP-&gt;</span></span></code></pre> <p>Then, after a further <code>CALLPROC</code> to a procedure needing three words of data the <code>frame stack</code> would like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 0-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> -64-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> FP-&gt;</span></span></code></pre> <p>After a <code>RETURNPROC</code> from that procedure the <code>frame stack</code> would look like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 0-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> FP-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> ........</span></span></code></pre> <p>and after a final <code>RETURNPROC</code>, like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> FP-&gt; ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> ........</span></span> <span class="giallo-l"><span> ........</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>There is actually not much new here. It amounts to <a href="https://wg-eips.ritovision.com/615/">EIP-615</a>, refined and refactored into bite-sized pieces, along lines common to other machines.</p> <p>This proposal uses the <a href="https://wg-eips.ritovision.com/2315/">EIP-2315</a> return stack to manage calls and returns, and steals ideas from <a href="https://wg-eips.ritovision.com/615/">EIP-615</a>, <a href="https://wg-eips.ritovision.com/3336/">EIP-3336</a>, and <a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a>. <code>ENTERPROC</code> corresponds to <code>BEGINSUB</code> from EIP-615. Like EIP-615 it uses a frame stack to track call-frame addresses with <code>FP</code> as <em>procedures</em> are entered and left, but like EIP-3336 and EIP-3337 it moves call frames from the data stack to memory.</p> <p>Aliasing call frames with ordinary memory supports addressing call-frame data with ordinary stores and loads. This is generally useful, especially for languages like C that provide pointers to variables on the stack.</p> <p>The design model here is the <em>subroutines</em> and <em>procedures</em> of the Intel x86 architecture.</p> <ul> <li><code>JUMPSUB</code> and <code>RETURNSUB</code> (from <a href="https://wg-eips.ritovision.com/2315/">EIP-2315</a> -- like <code>CALL</code> and <code>RET</code> -- jump to and return from <em>subroutines</em>.</li> <li><code>ENTERPROC</code> -- like <code>ENTER</code> -- sets up the stack frame for a <em>procedure</em>.</li> <li><code>CALLPROC</code> amounts to a <code>JUMPSUB</code> to an <code>ENTERPROC</code>.</li> <li><code>RETURNPROC</code> amounts to an early <code>LEAVEPROC</code>.</li> <li><code>LEAVEPROC</code> -- like <code>LEAVE</code> -- takes down the stack frame for a <em>procedure</em>. It then executes a <code>RETURNSUB</code>.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal adds new EVM opcodes. It doesn't remove or change the semantics of any existing opcodes, so there should be no backwards compatibility issues.</p> <h2 id="security">Security</h2> <p>Safe use of these constructs must be checked completely at validation time -- per EIP-3779 -- so there should be no security issues at runtime.</p> <p><code>ENTERPROC</code> and <code>LEAVEPROC</code> must follow the same safety rules as for <code>JUMPSUB</code> and <code>RETURNSUB</code> in EIP-2315. In addition, the following constraints must be validated:</p> <ul> <li>Every<code>ENTERPROC</code> must be followed by a <code>LEAVEPROC</code> to delimit the bodies of <em>procedures</em>.</li> <li>There can be no nested <em>procedures</em>.</li> <li>There can be no jump into the body of a procedure (including its <code>LEAVEPROC</code>) from outside of that body.</li> <li>There can be no jump or step to <code>BEGINPROC</code> at all -- only <code>CALLPROC</code>.</li> <li>The specified <code>n_inputs</code> and <code>n_outputs</code> must be on the stack.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-12-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Brayton Goodallhttps://github.com/Spore-Druid-Bray Mihir Faujdarhttps://github.com/uink45 https://wg-eips.ritovision.com/4520/

Reserve `0xEB` and `0xEC` for usage as extended opcode space.

<h2 id="abstract">Abstract</h2> <p>Reserve <code>0xEB</code> and <code>0xEC</code> for usage as extended opcode space.</p> <h2 id="motivation">Motivation</h2> <p>It would be convenient to introduce new opcodes that are likely to be infrequently used, whilst also being able to have greater than 256 opcodes in total. As a single byte opcode is half the size of a double byte opcode, the greatest efficiency in code sizes will be one where frequently used opcodes are single bytes. Two prefix bytes are used to accommodate up to 510 double byte opcodes.</p> <h2 id="specification">Specification</h2> <p>For example, a new arithmetic opcode may be allocated to <code>0xEC 01</code>(<code>ADD</code>), and a novel opcode may be introduced at <code>0xEB F4</code>(<code>DELEGATECALL</code>).</p> <p>Triple byte opcodes may be doubly-prefixed by <code>0xEB EB</code>, <code>0xEC EC</code>, <code>0xEB EC</code> and <code>0xEC EB</code>. It is possible to allocate experimental opcodes to this triple-byte space initially, and if they prove safe and useful, they could later be allocated a location in double-byte or single-byte space.</p> <p>Only <code>0xEB EB</code>, <code>0xEC EC</code>, <code>0xEC EC</code>, and <code>0xEB EC</code> may be interpreted as further extensions of the opcode space. <code>0xEB</code> and <code>0xEC</code> do not themselves affect the stack or memory, however opcodes specified by further bytes may. If a multi-byte opcode is yet to be defined, it is to be treated as <code>INVALID</code> rather than as a <code>NOP</code>, as per usual for undefined opcodes.</p> <h2 id="rationale">Rationale</h2> <p>It was considered that two prefix bytes rather than one would be adequate for reservation as extension addresses. Both <code>0xEB</code> and <code>0xEC</code> were chosen to be part of the E-series of opcodes. For example, the <code>0xEF</code> byte is reserved for contracts conforming to the Ethereum Object Format. By having unassigned opcodes for extending the opcode space, there will be a lower risk of breaking the functionalities of deployed contracts compared to choosing assigned opcodes.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Previous usage of <code>0xEB</code> and <code>0xEC</code> may result in unexpected behaviour and broken code.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security considerations.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-11-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/4488/

Greatly decreases the gas cost of transaction calldata and simultaneously caps total transaction calldata in a block

<h2 id="abstract">Abstract</h2> <p>Decrease transaction calldata gas cost, and add a limit of how much total transaction calldata can be in a block.</p> <h2 id="motivation">Motivation</h2> <p>Rollups are in the short and medium term, and possibly the long term, the only trustless scaling solution for Ethereum. Transaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups. Rollups are significantly reducing fees for many Ethereum users: Optimism and Arbitrum frequently provide fees that are ~3-8x lower than the Ethereum base layer itself, and ZK rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer.</p> <p>However, even these fees are too expensive for many users. The long-term solution to the long-term inadequacy of rollups by themselves has always been <a rel="external" href="https://github.com/ethereum/consensus-specs#sharding">data sharding</a>, which would add ~1-2 MB/sec of dedicated data space for rollups to the chain. However, data sharding will still take a considerable amount of time to finish implementing and deploying. Hence, a short-term solution to further cut costs for rollups, and to incentivize an ecosystem-wide transition to a rollup-centric Ethereum, is desired.</p> <p>This EIP presents a quick-to-implement short-term solution that also mitigates security risks.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>NEW_CALLDATA_GAS_COST</code></td><td><code>3</code></td></tr> <tr><td><code>BASE_MAX_CALLDATA_PER_BLOCK</code></td><td><code>1,048,576</code></td></tr> <tr><td><code>CALLDATA_PER_TX_STIPEND</code></td><td><code>300</code></td></tr> </tbody></table> <p>Reduce the gas cost of transaction calldata to <code>NEW_CALLDATA_GAS_COST</code> per byte, regardless of whether the byte is zero or nonzero.</p> <p>Add a rule that a block is only valid if <code>sum(len(tx.calldata) for tx in block.txs) &lt;= BASE_MAX_CALLDATA_PER_BLOCK + len(block.txs) * CALLDATA_PER_TX_STIPEND</code>.</p> <h2 id="rationale">Rationale</h2> <p>A natural alternative proposal is to decrease <code>NEW_CALLDATA_GAS_COST</code> without adding a limit. However, this presents a security concern: today, the average block size <a rel="external" href="https://etherscan.io/chart/blocksize">is 60-90 kB</a>, but the <em>maximum</em> block size is <code>30M / 16 = 1,875,000</code> bytes (plus about a kilobyte of block and tx overhead). Simply decreasing the calldata gas cost from 16 to 3 would increase the maximum block size to 10M bytes. This would push the Ethereum p2p networking layer to unprecedented levels of strain and risk breaking the network; some previous live tests of ~500 kB blocks a few years ago had already taken down a few bootstrap nodes.</p> <p>The decrease-cost-and-cap proposal achieves most of the benefits of the decrease, as rollups are unlikely to <em>dominate</em> Ethereum block space in the short term future and so 1.5 MB will be sufficient, while preventing most of the security risk.</p> <p>Historically, the Ethereum protocol community has been suspicious of multi-dimensional resource limit rules (in this case, gas and calldata) because such rules greatly increase the complexity of the block packing problem that proposers (today miners, post-merge validators) need to solve. Today, proposers can generate blocks with near-optimal fee revenue by simply choosing transactions in highest-to-lowest order of priority fee. In a multi-dimensional world, proposers would have to deal with multi-dimensional constraints. Multi-dimensional knapsack problems are much more complicated than the single-dimensional equivalent, and well-optimized proprietary implementations built by pools may well outperform default open source implementations.</p> <p>Today, there are two key reasons why this is less of a problem than before:</p> <ol> <li><a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> means that, at least most of the time, the problem that block proposers are solving is <em>not</em> a knapsack problem. Rather, block proposers are simply including all the transactions they can find with sufficient base fee and priority fee. Hence, naive algorithms will also frequently generate close-to-optimal results.</li> <li>The existence of sophisticated proprietary strategies for miner extractable value (MEV) extraction means that decentralized optimal block production is already in the medium and long term a lost cause. Research is instead going into solutions that separate away the specialization-friendly task of block body generation from the role of a validator ("proposer/builder separation"). Instead of being a fundamental change, two-dimensional knapsack problems today would be merely "yet another" MEV opportunity.</li> </ol> <p>Hence, it's worth rethinking the historical opposition to multi-dimensional resource limits and considering them as a pragmatic way to simultaneously achieve moderate scalability gains while retaining security.</p> <p>Additionally, the stipend mechanism makes the two-dimensional optimization problem even less of an issue in practice. 90% of all transactions (<a href="https://wg-eips.ritovision.com/4488/./assets/gas_and_calldata_sample.csv">sample</a> taken from blocks <code>13500000, 13501000 ... 13529000</code>) have &lt;300 bytes of calldata. Hence, if a naive transaction selection algorithm overfills the calldata of a block that the proposer is creating, the proposer will still be able to keep adding transactions from 90% of their mempool.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p> <p>Users will be able to continue operating with no changes.</p> <p>Miners will be able to continue operating with no changes except for a rule to stop adding new transactions into a block when the total calldata size reaches the maximum. However, there are pragmatic heuristics that they could add to achieve closer-to-optimal returns in such cases: for example, if a block fills up to the size limit, they could repeatedly remove the last data-heavy transaction and replace it with as many data-light transactions as possible, until doing so is no longer profitable.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The <em>burst</em> data capacity of the chain does not increase as a result of this proposal (in fact, it slightly decreases). However, the <em>average</em> data capacity will increase. This means that the storage requirements of history-storing will go up. A worst-case scenario would be a theoretical long-run maximum of ~1,262,861 bytes per 12 sec slot, or ~3.0 TB per year.</p> <p>We recommend <a href="https://wg-eips.ritovision.com/4444/">EIP-4444</a> or some similar history expiry proposal be implemented either at the same time or soon after this EIP to mitigate this risk.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-10-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin Danny Ryanhttps://github.com/djrtwo https://wg-eips.ritovision.com/4399/

Expose beacon chain randomness in the EVM by supplanting DIFFICULTY opcode semantics

<h2 id="abstract">Abstract</h2> <p>This EIP supplants the semantics of the return value of existing <code>DIFFICULTY (0x44)</code> opcode and renames the opcode to <code>PREVRANDAO (0x44)</code>.</p> <p>The return value of the <code>DIFFICULTY (0x44)</code> instruction after this change is the output of the randomness beacon provided by the beacon chain.</p> <h2 id="motivation">Motivation</h2> <p>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.</p> <p>At the point of <code>TRANSITION_BLOCK</code> of the Proof-of-Stake (PoS) upgrade described in <a href="https://wg-eips.ritovision.com/3675/">EIP-3675</a>, the <code>difficulty</code> block field <strong>MUST</strong> be <code>0</code> thereafter because there is no longer any Proof-of-Work (PoW) seal on the block. This means that the <code>DIFFICULTY (0x44)</code> instruction no longer has it's previous semantic meaning, nor a clear "correct" value to return.</p> <p>Given prior analysis on the usage of <code>DIFFICULTY</code>, the value returned by the instruction mixed with other values is a common pattern used by smart contracts to obtain randomness. The instruction with the same number as the <code>DIFFICULTY</code> opcode returning outputs of the beacon chain RANDAO implementation makes the upgrade to PoS backwards compatible for existing smart contracts obtaining randomness from the <code>DIFFICULTY</code> instruction.</p> <p>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 <code>DIFFICULTY</code> instruction. A value greater than <code>2**64</code> indicates that the transaction is being executed in the PoS block. Decompilers and other similar tooling may also use this trick to discern the new semantics of the instruction if data of the block including the transaction in question is available.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <ul> <li><strong><code>TRANSITION_BLOCK</code></strong> The definition of this block can be found in the Definitions section of <a href="https://wg-eips.ritovision.com/3675/#definitions">EIP-3675</a>.</li> </ul> <h3 id="block-structure">Block structure</h3> <p>Beginning with <code>TRANSITION_BLOCK</code>, client software <strong>MUST</strong> set the value of the <code>mixHash</code>, i.e. the field with the number <code>13</code> (0-indexed) in a block header, to the latest RANDAO mix of the post beacon state of the previous block.</p> <h3 id="evm">EVM</h3> <p>Beginning with <code>TRANSITION_BLOCK</code>, the <code>DIFFICULTY (0x44)</code> instruction <strong>MUST</strong> return the value of the <code>mixHash</code> field.</p> <p><em>Note</em>: The gas cost of the <code>DIFFICULTY (0x44)</code> opcode remains unchanged.</p> <h3 id="renaming">Renaming</h3> <p>The <code>mixHash</code> field <strong>SHOULD</strong> further be renamed to <code>prevRandao</code>.</p> <p>The <code>DIFFICULTY (0x44)</code> opcode <strong>SHOULD</strong> further be renamed to <code>PREVRANDAO (0x44)</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="including-randao-output-in-the-block-header">Including RANDAO output in the block header</h3> <p>Including a RANDAO 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.</p> <p>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.</p> <p>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.</p> <h3 id="using-mixhash-field-instead-of-difficulty">Using <code>mixHash</code> field instead of <code>difficulty</code></h3> <p>The <code>mixHash</code> header field is used instead of <code>difficulty</code> to avoid a class of hidden forkchoice bugs after the PoS upgrade.</p> <p>Client software implementing pre-EIP-3675 logic heavily depends on the <code>difficulty</code> value as total difficulty computation is the basis of the PoW fork choice rule. Setting the <code>difficulty</code> field to <code>0</code> at the PoS upgrade aims to reduce the surface of bugs related to the total difficulty value growing after the upgrade.</p> <p>Additionally, any latent total difficulty computation after the PoS upgrade would become overflow prone if the randomness output supplanted the value of the <code>difficulty</code> field.</p> <h3 id="reusing-existing-field-instead-of-appending-a-new-one">Reusing existing field instead of appending a new one</h3> <p>The <code>mixHash</code> 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.</p> <h3 id="reusing-the-difficulty-opcode-instead-of-introducing-a-new-one">Reusing the <code>DIFFICULTY</code> opcode instead of introducing a new one</h3> <p>See the <a href="https://wg-eips.ritovision.com/4399/#motivation">Motivation</a>.</p> <h3 id="renaming-the-field-and-the-opcode">Renaming the field and the opcode</h3> <p>The renaming should be done to make the field and the opcode names semantically sound.</p> <h3 id="using-transition-block-rather-than-a-block-or-slot-number">Using <code>TRANSITION_BLOCK</code> rather than a block or slot number</h3> <p>By utilizing <code>TRANSITION_BLOCK</code> 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 <a href="https://wg-eips.ritovision.com/3675/">EIP-3675</a>.</p> <p>By tightly coupling to the PoS upgrade, we ensure that there is no discontinuity for the usecase of this opcode for randomness -- the primary <a href="https://wg-eips.ritovision.com/4399/#motivation">motivation</a> for re-using <code>DIFFICULTY</code> rather than creating a new opcode.</p> <h3 id="using-2-64-threshold-to-determine-pos-blocks">Using <code>2**64</code> threshold to determine PoS blocks</h3> <p>The probability of RANDAO value to fall into the range between <code>0</code> and <code>2**64</code> 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 <code>2**54</code>), 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.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatible changes to the execution and validation of EVM state transitions. As written, this EIP utilizes <code>TRANSITION_BLOCK</code> and is thus tightly coupled with the PoS upgrade introduced in <a href="https://wg-eips.ritovision.com/3675/">EIP-3675</a>. If this EIP is to be adopted, it <strong>MUST</strong> be scheduled at the same time as EIP-3675.</p> <p>Additionally, the changes proposed might be backward incompatible for the following categories of applications:</p> <ul> <li>Applications that use the value returned by the <code>DIFFICULTY</code> opcode as the PoW <code>difficulty</code> parameter</li> <li>Applications with logic that depends on the <code>DIFFICULTY</code> opcode returning a relatively small number with respect to the full 256-bit size of the field.</li> </ul> <p>The first category is already affected by switching the consensus mechanism to PoS and no additional breaking changes are introduced by this specification.</p> <p>The second category is comprised of applications that use the return value of the <code>DIFFICULTY</code> 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.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>In one of ancestors of <code>TRANSITION_BLOCK</code> deploy a contract that stores return value of <code>DIFFICULTY (0x44)</code> to the state</li> <li>Check that value returned by <code>DIFFICULTY (0x44)</code> in transaction executed within the parent of <code>TRANSITION_BLOCK</code> equals <code>difficulty</code> field value</li> <li>Check that value returned by <code>PREVRANDAO (0x44)</code> in transaction executed within <code>TRANSITION_BLOCK</code> equals <code>prevRandao</code> field value</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>The <code>PREVRANDAO (0x44)</code> opcode in PoS Ethereum (based on the beacon chain RANDAO implementation) is a source of randomness with different properties to the randomness supplied by <code>BLOCKHASH (0x40)</code> or <code>DIFFICULTY (0x44)</code> opcodes in the PoW network.</p> <h3 id="biasability">Biasability</h3> <p>The beacon chain RANDAO implementation gives every block proposer 1 bit of influence power per slot. Proposer may deliberately refuse to propose a block on the opportunity cost of proposer and transaction fees to prevent beacon chain randomness (a RANDAO mix) from being updated in a particular slot.</p> <p>An effect of proposer's influence power is limited in time and lasts until the first honest RANDAO reveal is made afterwards. This limitation does also exist in the case when proposers of <code>n</code> consecutive slots are colluding to get <code>n</code> bits of influence power. Simply speaking, one honest block proposal is enough to unbias the RANDAO even if it was biased during several slots in a row.</p> <p>Additionally, semantics of the <code>PREVRANDAO (0x44)</code> instruction gives proposers another way to gain 1 bit of influence power on applications. Biased proposer may censor a rolling the dice transaction to force it to be included into the next block, thus, force it to use a RANDAO mix that the proposer knows in advance. The opportunity cost in this case would be negligible.</p> <h3 id="predictability">Predictability</h3> <p>Obviously, historical randomness provided by any decentralized oracle is 100% predictable. On the contrary, the randomness that is revealed in the future is predictable up to a limited extent.</p> <p>A list of inputs influencing future randomness on the beacon chain consists of but is not limited to the following items:</p> <ul> <li><strong>Accumulated randomness.</strong> A RANDAO mix produced by the beacon chain in the last slot of epoch <code>N</code> is the main input to the function defining block proposers in each slot of epoch <code>N + MIN_SEED_LOOKAHEAD + 1</code>, i.e. it is the main factor defining future RANDAO revealers.</li> <li><strong>Number of active validators.</strong> A number of active validators throughout an epoch is another input to the block proposer function.</li> <li><strong>Effective balance.</strong> All else being equal, the lower the effective balance of a validator the lower the chance this validator has to be designated as a proposer in a slot.</li> <li><strong>Accidentally missed proposals.</strong> Network conditions and other factors that are resulting in accidentally missed proposals is a source of highly qualitative entropy that impacts RANDAO mixes. Usual rate of missed proposals on the Mainnet is about <code>1%</code>.</li> </ul> <p>These inputs may be predictable and malleable on a short range of slots but the longer the attempted lookahead the more entropy is accumulated by the beacon chain.</p> <h3 id="tips-for-application-developers">Tips for application developers</h3> <p>The following tips attempt to reduce predictability and biasability of randomness outputs returned by <code>PREVRANDAO (0x44)</code>:</p> <ol> <li>Make your applications rely on the future randomness with a reasonably high lookahead. For example, an application stops accepting bids at the end of epoch <code>K</code> and uses a RANDAO mix produced in slot <code>K + N + ε</code> to roll the dice, where <code>N</code> is a lookahead in epochs and <code>ε</code> is a few slots into epoch <code>N + 1</code>.</li> <li>At least four epochs of lookahead results in the following outcome:</li> </ol> <ul> <li>A proposer set of epoch <code>N + 1</code> isn't known at the end of epoch <code>K</code> breaking a direct link between bidders and dice rollers</li> <li>A number of active validators is updated at the end of each epoch affecting a set of proposers of next epochs, thus, impacting a RANDAO mix used by the application to roll the dice</li> <li>Due to Mainnet statistics, there is about a <code>100%</code> chance for the network to accidentally miss a proposal during this period of time which reduces predictability of a RANDAO mix used to roll the dice.</li> </ul> <ol start="3"> <li>Setting <code>ε</code> to a small number, e.g. 2 or 4 slots, gives a third party a little time to gain influence power on the future randomness that is being used to roll the dice. This amount of time is defined by <code>MIN_SEED_LOOKAHEAD</code> parameter and is about 6 minutes on the Mainnet.</li> </ol> <p>A reasonably high distance between bidding and rolling the dice attempts to leave low chance for bidders controlling a subset of validators to directly exploit their influence power. Ultimately, this chance depends on the type of the game and on a number of controlled validators. For instance, a chance of a single validator to affect a one-time game is negligible, and becomes bigger for multiple validators in a repeated game scenario.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-10-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ansgar Dietrichshttps://github.com/adietrichs https://wg-eips.ritovision.com/4396/

Accounts for block time in the base fee calculation to target a stable throughput by time instead of by block.

<h2 id="abstract">Abstract</h2> <p>This EIP proposes accounting for time between blocks in the base fee calculation to target a stable throughput by time, instead of by block. Aiming to minimize changes to the calculation, it only introduces a variable block gas target proportional to the block time. The EIP can, in principle, be applied to either a Proof-of-Work or a Proof-of-Stake chain, however the security implications for the Proof-of-Work case remain unexplored.</p> <h2 id="motivation">Motivation</h2> <p>The current base fee calculation chooses the gas usage of a block as the signal to determine whether demand for block space is too low (indicating that the base fee should be lowered) or too high (indicating that the base fee should be increased). While simple, this choice of signal has drawbacks: it does not take the block time into account. Assuming a relatively constant demand, a proposer constructing a block after 20 seconds will have transactions available with twice the gas of a proposer constructing a block after 10 seconds. Using the same gas target for both is accordingly sub-optimal. In practice, there are several undesirable consequences of this flawed signal:</p> <h3 id="base-fee-volatility-under-proof-of-work">Base Fee Volatility Under Proof-of-Work</h3> <p>Under Proof-of-Work (PoW), block times are stochastic, and for that reason there exists large block time variability. This variability contributes to the base fee volatility, where the base fee can be expected to oscillate around the equilibrium value even under perfectly stable demand.</p> <h3 id="missed-slots">Missed Slots</h3> <p>Under Proof-of-Stake (PoS), block times are ideally uniform (always 12s), but missed slots lead to individual blocks with increased block time (24s, 36s, ...). Such missed slots will result in the next block being overfull, and with the current update rule, signal a fake demand spike and thus cause a small unwarranted base fee spike.</p> <p>More importantly, these missed slots directly reduce the overall throughput of the execution chain by the gas target of one block. While the next block can be expected to include the "delayed" transactions of the missed slot, the resulting base fee spike then results in some number of under-full blocks. In the end the block space of the missed slot is lost for the chain.</p> <p>This is particularly problematic because a Denial-of-Service (DoS) attack on block proposers can cause them to miss slots, and compromises the overall chain performance.</p> <h3 id="throughput-degradation-during-consensus-issues">Throughput Degradation During Consensus Issues</h3> <p>A more severe version of individual missed slots can be caused by consensus issues that prevent a significant portion of block proposers from continuing to create blocks. This can be due to block proposers forking off (and creating blocks on their own fork), being unable to keep up with the current chain head for another reason, or simply being unable to create valid blocks.</p> <p>In all these situations, average block times go up significantly, causing chain throughput to fall by the same fraction. While this effect is already present under PoW, the self-healing mechanism of difficulty adjustments is relatively quick to kick in and restore normal block times. On the other hand, under PoS the automatic self-healing mechanism can be extremely slow: potentially several months to return to normal with up to a third of slots missed, or several weeks if more than a third of slots are missed.</p> <p>For all these reasons, it would be desirable to target a stable throughput per time instead of per block, by taking block time into account during the base fee calculation.</p> <p>To maximize the chance of this EIP being included in the merge fork, the adjustments are kept to a minimum, with more involved changes discussed in the rationale section.</p> <h2 id="specification">Specification</h2> <p>Using the pseudocode language of <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a>, the updated base fee calculation becomes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">BASE_FEE_MAX_CHANGE_DENOMINATOR</span><span class="z-keyword"> =</span><span class="z-constant"> 8</span></span> <span class="giallo-l"><span class="z-constant">BLOCK_TIME_TARGET</span><span class="z-keyword"> =</span><span class="z-constant"> 12</span></span> <span class="giallo-l"><span class="z-constant">MAX_GAS_TARGET_PERCENT</span><span class="z-keyword"> =</span><span class="z-constant"> 95</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> World</span><span>(</span><span class="z-constant">ABC</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> parent_gas_limit</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_limit</span></span> <span class="giallo-l"><span> parent_block_time</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>timestamp</span><span class="z-keyword"> -</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span class="z-variable z-language">self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>)</span><span>.</span><span>timestamp</span></span> <span class="giallo-l"><span> parent_base_gas_target</span><span class="z-keyword"> =</span><span> parent_gas_limit</span><span class="z-keyword"> //</span><span class="z-constant"> ELASTICITY_MULTIPLIER</span></span> <span class="giallo-l"><span> parent_adjusted_gas_target</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>parent_base_gas_target</span><span class="z-keyword"> *</span><span> parent_block_time</span><span class="z-keyword"> //</span><span class="z-constant"> BLOCK_TIME_TARGET</span><span>,</span><span> parent_gas_limit</span><span class="z-keyword"> *</span><span class="z-constant"> MAX_GAS_TARGET_PERCENT</span><span class="z-keyword"> //</span><span class="z-constant"> 100</span><span>)</span></span> <span class="giallo-l"><span> parent_base_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>base_fee_per_gas</span></span> <span class="giallo-l"><span> parent_gas_used</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_used</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> parent_gas_used</span><span class="z-keyword"> ==</span><span> parent_adjusted_gas_target</span><span>:</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> parent_gas_used</span><span class="z-keyword"> &gt;</span><span> parent_adjusted_gas_target</span><span>:</span></span> <span class="giallo-l"><span> gas_used_delta</span><span class="z-keyword"> =</span><span> parent_gas_used</span><span class="z-keyword"> -</span><span> parent_adjusted_gas_target</span></span> <span class="giallo-l"><span> base_fee_per_gas_delta</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>parent_base_fee_per_gas</span><span class="z-keyword"> *</span><span> gas_used_delta</span><span class="z-keyword"> //</span><span> parent_base_gas_target</span><span class="z-keyword"> //</span><span class="z-constant"> BASE_FEE_MAX_CHANGE_DENOMINATOR</span><span>,</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> +</span><span> base_fee_per_gas_delta</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> gas_used_delta</span><span class="z-keyword"> =</span><span> parent_adjusted_gas_target</span><span class="z-keyword"> -</span><span> parent_gas_used</span></span> <span class="giallo-l"><span> base_fee_per_gas_delta</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> *</span><span> gas_used_delta</span><span class="z-keyword"> //</span><span> parent_base_gas_target</span><span class="z-keyword"> //</span><span class="z-constant"> BASE_FEE_MAX_CHANGE_DENOMINATOR</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> -</span><span> base_fee_per_gas_delta</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant"> ...</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="mechanism">Mechanism</h3> <p>The proposed new base fee calculation only adjusts the block gas target by scaling it with the block time, capped at a maximum percent of the overall block gas limit:</p> <h4 id="current-base-fee-calculation">Current Base Fee Calculation</h4> <p><img src="https://wg-eips.ritovision.com/4396/./assets/old_formula.png" alt="" /></p> <h4 id="proposed-base-fee-calculation">Proposed Base Fee Calculation</h4> <p><img src="https://wg-eips.ritovision.com/4396/./assets/new_formula.png" alt="" /></p> <p>This new calculation thus targets a stable throughput per time instead of per block.</p> <h3 id="limitations">Limitations</h3> <p>Under PoS, block time increases always come in multiples of full blocks (e.g. a single missed slot = 24s instead of 12s block time). Accounting for this already requires doubling the block gas target, even for a single missed slot. However, with the block elasticity currently set to 2, this target would be equal to the block gas limit. Having the new target equal to the block gas limit is less than ideal, and thus is reduced slightly, according to the <code>MAX_GAS_TARGET_PERCENT</code> parameter. The reason for the existence of this parameter is twofold:</p> <ul> <li>Ensure that the signal remains meaningful: A target equal to or greater than the gas limit could never be reached, so the base fee would always be reduced after a missed slot.</li> <li>Ensure that the base fee can still react to genuine demand increases: During times of many offline block proposers (and thus many missed slots), genuine demand increases still need a way to eventually result in a base fee increase, to avoid a fallback to a first-price priority fee auction.</li> </ul> <p>However, this means that even a single missed slot cannot be fully compensated. Even worse, any second or further sequential missed slot cannot be compensated for at all, as the gas target is already at its max. This effect becomes more pronounced as the share of offline validators increases:</p> <p><img src="https://wg-eips.ritovision.com/4396/./assets/degradation.png" alt="" /></p> <p>As can be observed, while this EIP does indeed increase the robustness of the network throughput in cases of offline validators, it does so imperfectly. Furthermore, there is a tradeoff effected by the <code>MAX_GAS_TARGET_PERCENT</code> parameter, with a higher value resulting in a higher network robustness, but a more impaired base fee adjustment mechanism during times of frequent missed slots.</p> <h3 id="possible-extensions">Possible Extensions</h3> <p>These limitations directly result from the design goal of a minimal change, to maximize chances of being included in the merge. There are natural ways of extending the EIP design to more effectively handle offline validators, at the expense of somewhat more extensive changes:</p> <h4 id="persistent-multi-slot-buffer">Persistent Multi-Slot Buffer</h4> <p>To be able to compensate multiple consecutive missed slots, a gas buffer could be introduced, that would allow the gas beyond the block elasticity to be carried forward to future blocks. To avoid long-run buffer accumulation that would delay a return to normal operations once block proposers are back online, a cap on the buffer would be added. Even for a relatively small buffer cap, the throughput robustness is significantly improved:</p> <p><img src="https://wg-eips.ritovision.com/4396/./assets/degradation_buffers.png" alt="" /></p> <p>With an elasticity still at 2, there is no way of avoiding the eventual breakdown for more than 50% offline block proposers.</p> <p>The main implementation complexity for this approach comes from the introduction of the buffer as a new persistent field. To retain the ability for calculating base fees only based on headers, it would have to be added to the block header.</p> <h4 id="increased-block-elasticity">Increased Block Elasticity</h4> <p>In addition to the introduction of a buffer, increasing the block elasticity is another tool for increasing throughput robustness. The following diagram shows the effect of different elasticity levels, both in the presence and absence of a persistent buffer:</p> <p><img src="https://wg-eips.ritovision.com/4396/./assets/degradation_elasticity.png" alt="" /></p> <p>Again, a clear positive effect can be observed.</p> <p>The main additional complexity here would come from the increased peak load (networking, compute &amp; disk access) of multiple sequential overfull blocks. Note though that PoS with its minimum block time of 12s significantly reduces worst case peak stress as compared to PoW.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The EIP has minimal impact on backwards compatibility, only requiring updates to existing base fee calculation tooling.</p> <h2 id="test-cases">Test Cases</h2> <p>tbd</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>tbd</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="timestamp-manipulation">Timestamp Manipulation</h3> <p>Under PoW, miners are in control over the timestamp field of their blocks. While there are some enforced limits to valid timestamps, implications regarding potential timestamp manipulation are nontrivial and remain unexplored for this EIP.</p> <p>Under PoS, each slot has a <a rel="external" href="https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/merge/beacon-chain.md#process_execution_payload">fixed assigned timestamp</a>, rendering any timestamp manipulation by block proposers impossible.</p> <h3 id="suppressing-base-fee-increases">Suppressing Base Fee Increases</h3> <p>As discussed in the rationale, a high value for <code>MAX_GAS_TARGET_PERCENT</code> during times of many offline block proposers results in a small remaining signal space for genuine demand increases that should result in base fee increases. This in turn decreases the cost for block proposers for suppresing these base fee increases, instead forcing the fallback to a first-price priority fee auction.</p> <p>While the arguments of incentive incompatibility for base fee suppression of the base EIP-1559 case still apply here, with a decreasing cost of this individually irrational behavior the risk for overriding psychological factors becomes more significant.</p> <p>Even in such a case the system degradation would however be graceful, as it would only temporarily suspend the base fee burn. As soon as the missing block proposers would come back online, the system would return to its ordinary EIP-1559 equilibrium.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-10-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Tim Beikohttps://github.com/timbeiko James Hancockhttps://github.com/MadeOfTin Thomas Jay Rushhttps://github.com/tjayrush https://wg-eips.ritovision.com/4345/

Delays the difficulty bomb to be noticeable in June 2022.

<h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLOCK_NUMBER</code> the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 10,700,000 blocks later than the actual block number.</p> <h2 id="motivation">Motivation</h2> <p>Targeting for The Merge to occur before June 2022. If it is not ready by then, the bomb can be delayed further.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span> fake_block_number</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">0</span><span>,</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> 10_700_000</span><span>)</span><span class="z-keyword"> if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_BLOCK_NUMBER</span><span class="z-keyword"> else</span><span> block</span><span>.</span><span>number</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The following script predicts a ~0.1 second delay to block time by June 2022 and a ~0.5 second delay by July 2022. This gives reason to address because the effect will be seen, but not so much urgency we don't have space to work around if needed.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> predict_diff_bomb_effect</span><span>(</span><span class="z-variable z-parameter z-function">current_blknum</span><span>,</span><span class="z-variable z-parameter z-function"> current_difficulty</span><span>,</span><span class="z-variable z-parameter z-function"> block_adjustment</span><span>,</span><span class="z-variable z-parameter z-function"> months</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span class="z-string"> Predicts the effect on block time (as a ratio) in a specified amount of months in the future.</span></span> <span class="giallo-l"><span class="z-string"> Vars used for predictions:</span></span> <span class="giallo-l"><span class="z-string"> current_blknum = 13423376 # Oct 15, 2021</span></span> <span class="giallo-l"><span class="z-string"> current_difficulty = 9545154427582720</span></span> <span class="giallo-l"><span class="z-string"> block adjustment = 10700000</span></span> <span class="giallo-l"><span class="z-string"> months = 7.5 # June 2022</span></span> <span class="giallo-l"><span class="z-string"> months = 8.5 # July 2022</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span> blocks_per_month</span><span class="z-keyword"> =</span><span> (</span><span class="z-constant">86400</span><span class="z-keyword"> *</span><span class="z-constant"> 30</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 13.3</span></span> <span class="giallo-l"><span> future_blknum</span><span class="z-keyword"> =</span><span> current_blknum</span><span class="z-keyword"> +</span><span> blocks_per_month</span><span class="z-keyword"> *</span><span> months</span></span> <span class="giallo-l"><span> diff_adjustment</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span><span class="z-keyword"> **</span><span> (</span><span>(</span><span>future_blknum</span><span class="z-keyword"> -</span><span> block_adjustment</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 100000</span><span class="z-keyword"> -</span><span class="z-constant"> 2</span><span>)</span></span> <span class="giallo-l"><span> diff_adjust_coeff</span><span class="z-keyword"> =</span><span> diff_adjustment</span><span class="z-keyword"> /</span><span> current_difficulty</span><span class="z-keyword"> *</span><span class="z-constant"> 2048</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> diff_adjust_coeff</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span>diff_adjust_coeff</span><span class="z-keyword"> =</span><span> predict_diff_bomb_effect</span><span>(</span><span class="z-constant">13423376</span><span>,</span><span class="z-constant">9545154427582720</span><span>,</span><span class="z-constant">10700000</span><span>,</span><span class="z-constant">7.5</span><span>)</span></span> <span class="giallo-l"><span>diff_adjust_coeff</span><span class="z-keyword"> =</span><span> predict_diff_bomb_effect</span><span>(</span><span class="z-constant">13423376</span><span>,</span><span class="z-constant">9545154427582720</span><span>,</span><span class="z-constant">10700000</span><span>,</span><span class="z-constant">8.5</span><span>)</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known backward compatibility issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Misjudging the effects of the difficulty can mean longer blocktimes than anticipated until a hardfork is released. Wild shifts in difficulty can affect this number severely. Also, gradual changes in blocktimes due to longer-term adjustments in difficulty can affect the timing of difficulty bomb epochs. This affects the usability of the network but unlikely to have security ramifications.</p> <p>In this specific instance, it is possible that the network hashrate drops considerably before The Merge, which could accelerate the timeline by which the bomb is felt in block times. The offset value chosen aimed to take this into account.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-09-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anton Bukovhttps://github.com/k06a Mikhail Melnikhttps://github.com/ZumZoom https://wg-eips.ritovision.com/3978/

Reprice reverted SSTORE/CREATE/SELFDESTRUCT/LOGX operations gas via gas refund mechanism

<h2 id="abstract">Abstract</h2> <p>For reverted state modification operations, keep access cost, but refund modification cost.</p> <h2 id="motivation">Motivation</h2> <p>Reverting a transaction, or any of its sub-calls, drops any state modifications that happened inside. But now, users are being charged for the dropped modifications as if they persisted.</p> <p>Since <a href="https://wg-eips.ritovision.com/3298/">EIP-3298</a>, the gas refund mechanism works for storage restores only inside the same transaction. But on revert, the gas refund is not increased; it is completely erased. It can even be cheaper to transfer tokens back at the end of a transaction instead of reverting, to keep the existing gas refund. This should be changed.</p> <ul> <li>Reverted SSTORE deserves to be repriced to SLOAD gas (100 gas)</li> <li>Reverted LOG0, LOG1, LOG2, LOG3 and LOG4 deserve to be repriced to 100 gas</li> <li>Reverted CALL with value (<code>positive_value_cost</code> = 9,000 gas) deserves to be repriced to 100 gas</li> <li>Reverted CALL with value and account creation (<code>value_to_empty_account_cost</code> = 25,000 gas) deserves to be repriced to 100 gas</li> <li>Reverted CREATE and CREATE2 (32,000 gas) deserve to be repriced to 100 gas</li> <li>Reverted SELFDESTRUCT (5,000 or 25,000 gas) deserves to be repriced to 100 gas</li> </ul> <p>Moreover, it seems fair to charge CREATE and CREATE2 operations 32,000 fix price conditionally only if returned bytecode is not empty.</p> <h2 id="specification">Specification</h2> <p>For each callframe, track <code>revert_gas_refund</code>, initially 0.</p> <p>The set of operations that modify <code>revert_gas_refund</code> are:</p> <ul> <li>SSTORE</li> <li>LOG0, LOG1, LOG2, LOG3, LOG4</li> <li>CALL</li> <li>CREATE, CREATE2</li> <li>SELFDESTRUCT</li> </ul> <p>They increase <code>revert_gas_refund</code> as follows:</p> <pre class="giallo z-code"><code data-lang="javascript"><span class="giallo-l"><span class="z-variable z-other">call</span><span>.</span><span class="z-variable z-other">revert_gas_refund</span><span class="z-keyword"> +=</span><span class="z-variable z-other"> operation</span><span>.</span><span class="z-variable z-other">gas</span><span class="z-keyword"> -</span><span class="z-variable z-other z-constant"> WARM_STORAGE_READ_COST</span></span></code></pre> <p>And in case of revert let's use this value instead of just erasing <code>gas_refund</code>:</p> <pre class="giallo z-code"><code data-lang="javascript"><span class="giallo-l"><span class="z-keyword">if</span><span> (</span><span class="z-variable z-other">call</span><span>.</span><span class="z-variable z-other">reverted</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> existing behavior</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span>.</span><span class="z-variable z-other">gas_refund</span><span class="z-keyword"> -=</span><span class="z-variable z-other"> call</span><span>.</span><span class="z-variable z-other">gas_refund</span><span>;</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> New behavior added to existing according to the EIP-3978</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span>.</span><span class="z-variable z-other">gas_refund</span><span class="z-keyword"> +=</span><span class="z-variable z-other"> call</span><span>.</span><span class="z-variable z-other">revert_gas_refund</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>Gas should reflect the cost of use. The revert cost reflects the cost of access during execution, but not the cost of modification.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known backward incompatibilities.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-09-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gregory Markouhttps://github.com/GregTheGreek https://wg-eips.ritovision.com/3788/

Reject transactions that do not explicitly have the same chainId as the node's configuration.

<h2 id="abstract">Abstract</h2> <p>Reject transactions that do not explicitly have the same chainId as the node's configuration.</p> <h2 id="motivation">Motivation</h2> <p>Per <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> a transaction with a <code>chainId = 0</code> is considered to be a valid transaction. This was a feature to offer developers the ability to submit replayable transactions across different chains. With the rise of evm compatible chains, many of which use forks, or packages from popular Ethereum clients, we are putting user funds at risk. This is because most wallet interfaces do not expose the chainId to the user, meaning they typically do not have insight into what chainId they are signing. Should a malicious actor (or accidental) choose to, they can easily have users submit transactions with a <code>chainId = 0</code> on a non-mainnet network, allowing the malicious actor to replay the transaction on ethereum mainnet (or other networks for that matter) as a grief or sophisticated attack.</p> <h2 id="specification">Specification</h2> <p>As of the fork block <code>N</code>, consider transactions with a <code>chaindId = 0</code> to be invalid. Such that transactions are verified based on the nodes configuration. Eg:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>if (node.cfg.chainId != tx.chainId) {</span></span> <span class="giallo-l"><span> // Reject transaction</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The configuration set by the node is the main source of truth, and thus should be explicitly used when deciding how to filter out a transaction. This check should exist in two places, as a filter on the JSON-RPC (eg: <code>eth_sendTransaction</code>), and strictly enforced on the EVM during transaction validation.</p> <p>This ensures that users will not have transactions pending that will be guaranteed to fail, and prevents the transaction from being included in a block.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This breaks all applications or tooling that submit transactions with a <code>chainId == 0</code> after block number <code>N</code>.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>It should be noted this will not prevent a malicious actor from deploying a network with <code>chainId = 1</code>, or copying any other networks chainId.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-08-30T00:00:00+00:00 2026-02-11T14:49:28+00:00 Greg Colvinhttps://github.com/gcolvin Greg Colvingreg@colvin.org Brooklyn Zelenkahttps://github.com/expede https://wg-eips.ritovision.com/3779/

Ensure an essential level of safety for EVM code.

<h2 id="abstract">Abstract</h2> <p>We define a safe EVM contract as one that cannot encounter an exceptional halting state. In general, we cannot prove safety for Turing-complete programs. But we can prove a useful subset.</p> <p>This EIP specifies validity rules to ensure that:</p> <blockquote> <p>Valid contracts will not halt with an exception unless they either</p> <ul> <li>throw <code>out of gas</code> or</li> <li>recursively overflow stack.</li> </ul> </blockquote> <p>This EIP does not introduce any new opcodes. Rather, it restricts the use of existing and proposed control-flow instructions. The restrictions must be validated at contract initialization time – not at runtime – by the provided algorithm or its equivalent. This algorithm must take time and space near-linear in the size of the contract, so as not to be a denial of service vulnerability.</p> <p>This specification is entirely semantic. It imposes no further syntax on bytecode, as none is required to ensure the specified level of safety. Ethereum Virtual Machine bytecode is just that -- a sequence of bytes that when executed causes a sequence of changes to the machine state. The safety we seek here is simply to not, as it were, jam up the gears.</p> <h2 id="motivation">Motivation</h2> <h3 id="safety">Safety</h3> <p>For our purposes we define a safe EVM contract as one that cannot encounter an exceptional halting state. From the standpoint of security it would be best if unsafe contracts were never placed on the blockchain. Unsafe code can attempt to overflow stack, underflow stack, execute invalid instructions, and jump to invalid locations.</p> <p>Unsafe contracts are exploits waiting to happen.</p> <p>Validating contract safety requires traversing the contract code. So in order to prevent denial of service attacks all jumps, including the existing <code>JUMP</code> and <code>JUMPI</code>, and also the other proposed jumps -- <code>RJUMP</code>, <code>RJUMPI</code>, <code>RJUMPSUB</code> and <code>RETURNSUB</code> -- must be validated at initialization time, and in time and space linear in the size of the code.</p> <h4 id="static-jumps-and-subroutines">Static Jumps and Subroutines</h4> <p>The relative jumps of <a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a> and the simple subroutines of <a href="https://wg-eips.ritovision.com/2315/">EIP-2315</a> provide a complete set of static control flow instructions:</p> <blockquote> <p><code>RJUMP</code> <em>offset</em></p> </blockquote> <ul> <li>Jumps to <em>IP+offset</em>.</li> </ul> <blockquote> <p><code>RJUMPI</code> <em>offset</em></p> </blockquote> <ul> <li>Jumps if the top of stack is non-zero.</li> </ul> <blockquote> <p><code>RJUMPSUB</code> offset</p> </blockquote> <ul> <li>Pushes <em>IP+1</em> on the return stack and jumps to <em>IP+offset</em>.</li> </ul> <blockquote> <p><code>RETURNSUB</code></p> </blockquote> <ul> <li>Jumps to the address popped off the return stack.</li> </ul> <p>Note that each jump creates at most two paths of control through the code, such that the complexity of traversing the entire control-flow graph is linear in the size of the code.</p> <h4 id="dynamic-jumps"><em>Dynamic Jumps</em></h4> <p>Dynamic jumps, where the destination of a <code>JUMP</code> or <code>JUMPI</code> is not known until runtime, are an obstacle to proving validity in linear time -- any jump can be to any destination in the code, potentially requiring time quadratic in the size of code. For this reason we have two real choices.</p> <ol> <li>Deprecate dynamic jumps. This is easily done:</li> </ol> <blockquote> <p>Define <code>JUMP</code> and <code>JUMPI</code> as <code>INVALID</code> for the purposes of EOF Code Validation</p> </blockquote> <ol start="2"> <li>Constrain dynamic jumps. This requires static analysis.</li> </ol> <p>Consider the simplest and most common case.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH address</span></span> <span class="giallo-l"><span>JUMP</span></span></code></pre> <p>This is effectively a static jump.</p> <p>Another important use of <code>JUMP</code> is to implement the return jump from a subroutine. So consider this example of calling and returning from a minimal subroutine:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TEST_SQUARE:</span></span> <span class="giallo-l"><span> jumpdest</span></span> <span class="giallo-l"><span> push RTN_SQUARE </span></span> <span class="giallo-l"><span> 0x02</span></span> <span class="giallo-l"><span> push SQUARE</span></span> <span class="giallo-l"><span> jump</span></span> <span class="giallo-l"><span>RTN_SQUARE</span></span> <span class="giallo-l"><span> jumpdest</span></span> <span class="giallo-l"><span> swap1</span></span> <span class="giallo-l"><span> jump</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>SQUARE:</span></span> <span class="giallo-l"><span> jumpdest</span></span> <span class="giallo-l"><span> dup1</span></span> <span class="giallo-l"><span> mul</span></span> <span class="giallo-l"><span> swap1</span></span> <span class="giallo-l"><span> jump</span></span></code></pre> <p>The return address -<code>RTN_SQUARE</code> - and the destination address - <code>SQUARE</code> - are pushed on the stack as constants and remain unchanged as they move on the stack, such that only those constants are passed to each <code>JUMP</code>. They are effectively static. We can track the motion of constants on the <code>data stack</code> at validation time, so <em>we do not need unconstrained dynamic jumps to implement subroutines.</em></p> <p><em>The above is the simplest analysis that suffices. A more powerful analysis that takes in more use cases is possible -- slower, but still linear-time.</em></p> <h4 id="validation">Validation</h4> <p>We can validate the safety of contracts with a static analysis that takes time and space linear in the size of the <em>code</em>, as shown below. And since we can, we should.</p> <h3 id="performance">Performance</h3> <p>Validating safe control flow at initialization time has potential performance advantages.</p> <ul> <li>Static jumps do not need to be checked at runtime.</li> <li>Stack underflow does not need to be checked for at runtime.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="validity">Validity</h3> <blockquote> <p>In theory, theory and practice are the same. In practice, they're not. -- Albert Einstein</p> </blockquote> <p>We define a <em>safe</em> EVM contract as one that cannot encounter an exceptional halting state. We validate <em>safety</em> at initialization time to the extent practical.</p> <h4 id="exceptional-halting-states"><em>Exceptional Halting States</em></h4> <p>The <em>execution</em> of each instruction is defined in the Yellow Paper as a change to the EVM state that preserves the invariants of EVM state. At runtime, if the execution of an instruction would violate an invariant the EVM is in an exceptional halting state. The Yellow Paper defined five such states.</p> <ol> <li>Insufficient gas</li> <li>More than 1024 stack items</li> <li>Insufficient stack items</li> <li>Invalid jump destination</li> <li>Invalid instruction</li> </ol> <p><em>A program is safe iff no execution can lead to an exceptional halting state.</em></p> <p><em>We would like to consider EVM programs valid iff they are safe.</em></p> <p><em>In practice</em>, we must be able to validate <em>code</em> in linear time to avoid denial of service attacks. And we must support dynamically-priced instructions, loops, and recursion, which can use arbitrary amounts of gas and stack.</p> <p>Thus our validation cannot consider concrete computations -- it only performs a limited symbolic execution of the <em>code</em>. This means we will reject programs if we detect any invalid execution paths, even if those paths are not reachable at runtime. And we will count as valid programs that may not always produce correct results.</p> <p>We can detect only <em>non-recursive</em> stack overflows at <em>validation time</em>, so we must check for the first two states at <em>runtime</em>:</p> <ul> <li><code>out of gas</code> and</li> <li>stack overflow.</li> </ul> <p>The remaining three states we can check at <em>validation time</em>:</p> <ul> <li>stack underflow,</li> <li>invalid jump, and</li> <li>invalid instruction.</li> </ul> <p>That is to say:</p> <blockquote> <p>Valid contracts will not halt with an exception unless they either</p> <ul> <li>throw <code>out of gas</code> or</li> <li>recursively overflow stack.</li> </ul> </blockquote> <h4 id="constraints-on-valid-code"><em>Constraints on Valid Code</em></h4> <ul> <li>Every instruction is valid.</li> <li>Every jump is valid: <ul> <li>Every<code>JUMP</code> and <code>JUMPI</code> is <em>static</em>.</li> <li>No <code>JUMP</code>, <code>JUMPI</code>, <code>RJUMP</code>, <code>RJUMPI</code>, or <code>RJUMPSUB</code> addresses immediate data.</li> </ul> </li> <li>The stacks are always valid: <ul> <li>The <em>number</em> of items on the <code>data stack</code> is always positive, and at most 1024.</li> <li>The <em>number</em> of items on the <code>return stack</code> is always positive, and at most 1024.</li> </ul> </li> <li>The data stack is consistently aligned: <ul> <li>The <em>number</em> of items on the <code>data stack</code> between the current <code>stack pointer</code> and the <code>stack pointer</code> on entry to the most recent basic block is the same for each <em>execution</em> of a <em>byte_code</em>.</li> </ul> </li> </ul> <p>We define a <code>JUMP</code> or <code>JUMPI</code> instruction to be <em>static</em> if its <code>jumpsrc</code> argument was first placed on the stack via a <code>PUSH…</code> and that value has not changed since, though it may have been copied via a <code>DUP…</code> or <code>SWAP…</code>.</p> <p>The <code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPSUB</code>instructions take their destination as an immediate argument, so they are <em>static</em>.</p> <p>Taken together, these rules allow for code to be validated by traversing the control-flow graph, in time and space linear in the size of the code, following each edge only once.</p> <p><em>Note: The definition of 'static' for <code>JUMP</code> and <code>JUMPI</code> is the bare minimum needed to implement subroutines. Deeper analyses could be proposed that would validate a larger and probably more useful set of jumps, at the cost of more expensive (but still linear) validation.</em></p> <h2 id="rationale">Rationale</h2> <p>Demanding <em>static</em> destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime.</p> <p>Bounding the stack pointers catches all <code>data stack</code> and non-recursive<code>return stack</code> overflows.</p> <p>Requiring a consistently aligned<code>data stack</code> prevents stack underflow. It can also catch such errors as misaligned stacks due to irreducible control flows and calls to subroutines with the wrong number of arguments.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These changes affect the semantics of EVM code – the use of <code>JUMP</code>, <code>JUMPI</code>, and the stack are restricted, such that some <em>code</em> that would otherwise run correctly will nonetheless be invalid EVM <em>code</em>.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>The following is a pseudo-Go implementation of an algorithm for predicating code validity. An equivalent algorithm must be run at initialization time.</p> <p>This algorithm performs a symbolic execution of the program that recursively traverses the <em>code</em>, emulating its control flow and stack use and checking for violations of the rules above.</p> <p>It runs in time equal to <code>O(vertices + edges)</code> in the program's control-flow graph, where edges represent control flow and the vertices represent <em>basic blocks</em> -- thus the algorithm takes time proportional to the size of the <em>code</em>.</p> <p><em>Note: All valid code has a control-flow graph that can be traversed in time and space linear in the length of the code. That means that some other static analyses and code transformations that might otherwise require quadratic time can also be written to run in near-linear time, including one-pass and streaming compilers.</em></p> <h3 id="validation-function">Validation Function</h3> <p><em><strong>Note:</strong> This function is a work in progress, and the version below is known to be incorrect.</em></p> <p>For simplicity's sake we assume that <em>jumpdest analysis</em> has been done and that we have some helper functions.</p> <ul> <li><code>isValidInstruction(pc)</code> returns true if <code>pc</code> points at a valid instruction</li> <li><code>isValidJumpdest(dest)</code> returns true if <code>dest</code> is a valid jumpdest</li> <li><code>immediateData(pc)</code> returns the immediate data for the instruction at <code>pc</code>.</li> <li><code>advancePC(pc)</code> returns next <code>pc</code>, skipping any immediate data.</li> <li><code>removed_items(pc)</code> returns the number of items removed from the <code>dataStack</code> by the instruction at <code>pc</code>.</li> <li><code>added_items(pc)</code> returns the number of items added to the <code>dataStack</code> by the instruction at <code>pc</code>.</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>var bytecode [codeLen]byte</span></span> <span class="giallo-l"><span>var subMin [codeLen]int</span></span> <span class="giallo-l"><span>var subMax [codeLen]int</span></span> <span class="giallo-l"><span>var subDelta [codeLen]int</span></span> <span class="giallo-l"><span>var visited [codeLen]bool</span></span> <span class="giallo-l"><span>var dataStack [1024]int</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>// validate a path through the control flow of the bytecode at pc</span></span> <span class="giallo-l"><span>// and return the maximum number of stack items used down that path</span></span> <span class="giallo-l"><span>// or else the PC and an error</span></span> <span class="giallo-l"><span>//</span></span> <span class="giallo-l"><span>// by starting at pc:=0 the entire program is recursively evaluated</span></span> <span class="giallo-l"><span>//</span></span> <span class="giallo-l"><span>func validate(pc := 0, sp := 0, rp := 0) int, error {</span></span> <span class="giallo-l"><span> minStack := 0 </span></span> <span class="giallo-l"><span> maxStack := 0 </span></span> <span class="giallo-l"><span> deltaStack := 0 </span></span> <span class="giallo-l"><span> for pc &lt; codeLen {</span></span> <span class="giallo-l"><span> if !isValidInstruction(pc) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_instruction</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // if we have jumped here before return to break cycle</span></span> <span class="giallo-l"><span> if visited[pc] {</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // stack is not aligned if deltas not the same</span></span> <span class="giallo-l"><span> if ??? {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_stack</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> visited[pc] = true</span></span> <span class="giallo-l"><span> switch bytecode[pc] {</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // successful termination</span></span> <span class="giallo-l"><span> case STOP:</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span> case RETURN:</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> case SELFDESTRUCT:</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span> case REVERT:</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span> case INVALID:</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_instruction</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> case RJUMP:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check for valid jump destination</span></span> <span class="giallo-l"><span> if !isValidJumpdest(jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // reset pc to destination of jump</span></span> <span class="giallo-l"><span> pc += immediateData(pc)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> case RJUMPI:</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // recurse to validate true side of conditional</span></span> <span class="giallo-l"><span> jumpdest = pc + immediateData(pc)</span></span> <span class="giallo-l"><span> if !isValidJumpdest(pc + jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> minRight, maxLeft, deltaRight, err =</span></span> <span class="giallo-l"><span> validate(jumpdest, sp, rp)</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> err {</span></span> <span class="giallo-l"><span> return 0,0,0,err</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // recurse to validate false side of conditional</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"><span> minRight, maxRight, deltaRight, err =</span></span> <span class="giallo-l"><span> validate(pc, sp, rp)</span></span> <span class="giallo-l"><span> if err {</span></span> <span class="giallo-l"><span> return 0,0,0,err</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // both paths valid, so return max</span></span> <span class="giallo-l"><span> minStack = min(minStack, min(minLeft, minRight))</span></span> <span class="giallo-l"><span> maxStack += max(maxLeft, maxRight)</span></span> <span class="giallo-l"><span> deltaStack += max(deltaLeft, deltaRight)</span></span> <span class="giallo-l"><span> return minStack, maxStack, deltaStack</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> case RJUMPSUB:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check for valid jump destination</span></span> <span class="giallo-l"><span> jumpdest = immediateData(pc)</span></span> <span class="giallo-l"><span> if !isValidJumpdest(pc + jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> pc += jumpdest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // recurse to validate subroutine call</span></span> <span class="giallo-l"><span> minSub, maxSub, deltaSub, err = validate(jumpdest, sp, rp)</span></span> <span class="giallo-l"><span> if err {</span></span> <span class="giallo-l"><span> return 0,0,0,err</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> subMin[pc] = minSub</span></span> <span class="giallo-l"><span> subMax[pc] = maxSub</span></span> <span class="giallo-l"><span> subDelta[pc] = deltaSub</span></span> <span class="giallo-l"><span> minStack = min(minStack, sp)</span></span> <span class="giallo-l"><span> maxStack = max(maxStack, sp)</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> case RETURNSUB:</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> maxStack = max(maxStack, sp)</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp, nil</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> /////////////////////////////////////////////////////</span></span> <span class="giallo-l"><span> //</span></span> <span class="giallo-l"><span> // The following are to be included only if we take</span></span> <span class="giallo-l"><span> //</span></span> <span class="giallo-l"><span> // Option 2</span></span> <span class="giallo-l"><span> //</span></span> <span class="giallo-l"><span> // and do not deprecate JUMP and JUMPI</span></span> <span class="giallo-l"><span> //</span></span> <span class="giallo-l"><span> case JUMP:</span></span> <span class="giallo-l"><span> // pop jump destination</span></span> <span class="giallo-l"><span> jumpdest = dataStack[--sp]</span></span> <span class="giallo-l"><span> if !valid_jumpdest(jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> pc = jumpdest</span></span> <span class="giallo-l"><span> case JUMPI:</span></span> <span class="giallo-l"><span> // pop jump destination and conditional</span></span> <span class="giallo-l"><span> jumpdest = dataStack[--sp]</span></span> <span class="giallo-l"><span> jumpif = dataStack[--sp]</span></span> <span class="giallo-l"><span> if sp &lt; 0 {}</span></span> <span class="giallo-l"><span> return 0,0,0,stack_underflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> if !valid_jumpdest(jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // recurse to validate true side of conditional</span></span> <span class="giallo-l"><span> if !isValidJumpdest(jumpdest) {</span></span> <span class="giallo-l"><span> return 0,0,0,invalid_destination</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> maxLeft, err = validate(jumpdest, sp, rp)</span></span> <span class="giallo-l"><span> if err {</span></span> <span class="giallo-l"><span> return 0,0,0,err</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // recurse to validate false side of conditional</span></span> <span class="giallo-l"><span> pc = advance_pc(pc)</span></span> <span class="giallo-l"><span> maxRight, err = validate(pc, sp, rp)</span></span> <span class="giallo-l"><span> if err {</span></span> <span class="giallo-l"><span> return 0,0,0,err</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // both sides valid, return max</span></span> <span class="giallo-l"><span> maxStack += max(maxLeft, maxRight)</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span> case PUSH1 &lt;= bytecode[pc] &amp;&amp; bytecode[pc] &lt;= PUSH32 {</span></span> <span class="giallo-l"><span> sp++</span></span> <span class="giallo-l"><span> if (sp &gt; 1023) {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_overflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> maxStack = max(maxStack, sp)</span></span> <span class="giallo-l"><span> dataStack[sp] = immediateData(pc)</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"><span> case DUP1 &lt;= bytecode[pc] &amp;&amp; bytecode[pc] &lt;= DUP32 {</span></span> <span class="giallo-l"><span> dup = sp - (bytecode[pc] - DUP1)</span></span> <span class="giallo-l"><span> if dup &lt; 0 {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_underflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> sp++</span></span> <span class="giallo-l"><span> if (sp &gt; 1023) {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_overflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> maxStack = max(maxStack, sp)</span></span> <span class="giallo-l"><span> dataStack[sp] = dataStack[dup]</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"><span> case SWAP1 &lt;= bytecode[pc] &amp;&amp; bytecode[pc] &lt;= SWAP32 {</span></span> <span class="giallo-l"><span> swap = sp - (bytecode[pc] - SWAP1)</span></span> <span class="giallo-l"><span> if swap &lt; 0 {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_underflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> temp := dataStack[swap]</span></span> <span class="giallo-l"><span> dataStack[swap] = dataStack[0]</span></span> <span class="giallo-l"><span> dataStack[0] = temp</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"><span> //</span></span> <span class="giallo-l"><span> /////////////////////////////////////////////////////</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> default:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // apply other instructions to stack pointer</span></span> <span class="giallo-l"><span> sp -= removed_items(pc)</span></span> <span class="giallo-l"><span> if (sp &lt; 0) {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_underflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> minStack = min(minStack, sp)</span></span> <span class="giallo-l"><span> sp += added_items(pc)</span></span> <span class="giallo-l"><span> if (sp &gt; 1023) {</span></span> <span class="giallo-l"><span> return 0,0,0,stack_overflow</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> maxStack = max(maxStack, sp)</span></span> <span class="giallo-l"><span> pc = advancePC(pc)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // successful termination</span></span> <span class="giallo-l"><span> return minStack, maxStack, sp</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>This EIP is intended to ensure an essential level of safety for EVM code deployed on the blockchain.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-08-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 lightclienthttps://github.com/lightclient https://wg-eips.ritovision.com/3756/

Set an in-protocol cap for the gas limit

<h2 id="abstract">Abstract</h2> <p>Set an in-protocol cap for the gas limit of 30,000,000.</p> <h2 id="motivation">Motivation</h2> <p>A high gas limit increases pressure on the network. In the benign case, it increases the size of the state and history faster than we can sustain. In the malicious case, it amplifies the devastation of certain denial-of-service attacks.</p> <h2 id="specification">Specification</h2> <p>As of the fork block <code>N</code>, consider blocks with a <code>gas_limit</code> greater than <code>30,000,000</code> invalid.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-cap-the-gas-limit">Why Cap the Gas Limit</h3> <p>The gas limit is currently under the control of block proposers. They have the ability to increase the gas limit to whatever value they desire. This allows them to bypass the EIP and All Core Devs processes in protocol decisions that may negatively affect the security and/or decentralization of the network.</p> <h3 id="no-fixed-gas-limit">No Fixed Gas Limit</h3> <p>A valuable property of proposers choosing the gas limit is they can scale it down quickly if the network becomes unstable or is undergoing certain types of attacks. For this reason, we maintain their ability to lower the gas limit <em>below</em> 30,000,000.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backwards compatibility issues.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>No security considerations.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-07-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Mikhail Kalininhttps://github.com/mkalinin Danny Ryanhttps://github.com/djrtwo Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/3675/

Specification of the consensus mechanism upgrade on Ethereum Mainnet that introduces Proof-of-Stake

<h2 id="abstract">Abstract</h2> <p>This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in <a href="https://wg-eips.ritovision.com/2982/">EIP-2982</a>. Full specification of the beacon chain can be found in the <code>ethereum/consensus-specs</code> repository.</p> <p>This document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade.</p> <h2 id="motivation">Motivation</h2> <p>The beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. This long period of running without failure demonstrates the sustainability of the beacon chain system and its readiness to become a security provider for the Ethereum Mainnet.</p> <p>To understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of <a href="https://wg-eips.ritovision.com/2982/#motivation">EIP-2982</a>.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <ul> <li><strong>PoW block</strong>: Block that is built and verified by the existing proof-of-work mechanism. In other words, a block of the Ethereum network before the consensus upgrade.</li> <li><strong>PoS block</strong>: Block that is built and verified by the new proof-of-stake mechanism.</li> <li><strong>Terminal PoW block</strong>: A PoW block that satisfies the following conditions -- <code>pow_block.total_difficulty &gt;= TERMINAL_TOTAL_DIFFICULTY</code> <em>and</em> <code>pow_block.parent_block.total_difficulty &lt; TERMINAL_TOTAL_DIFFICULTY</code>. There can be more than one terminal PoW block in the network, e.g. multiple children of the same pre-terminal block.</li> <li><strong><code>TERMINAL_TOTAL_DIFFICULTY</code></strong> The amount of total difficulty reached by the network that triggers the consensus upgrade. Ethereum Mainnet configuration <strong>MUST</strong> have this parameter set to the value <code>58750000000000000000000</code>.</li> <li><strong><code>TRANSITION_BLOCK</code></strong> The earliest PoS block of the canonical chain, i.e. the PoS block with the lowest block height.</li> <li><strong><code>POS_FORKCHOICE_UPDATED</code></strong> An event occurring when the state of the proof-of-stake fork choice is updated.</li> <li><strong><code>FORK_NEXT_VALUE</code></strong> A block number set to the <code>FORK_NEXT</code> parameter for the upcoming consensus upgrade.</li> <li><strong><code>TERMINAL_BLOCK_HASH</code></strong> Designates the hash of the terminal PoW block if set, i.e. if not stubbed with <code>0x0000000000000000000000000000000000000000000000000000000000000000</code>.</li> <li><strong><code>TERMINAL_BLOCK_NUMBER</code></strong> Designates the number of the terminal PoW block if <code>TERMINAL_BLOCK_HASH</code> is set.</li> </ul> <h4 id="pos-events">PoS events</h4> <p>Events having the <code>POS_</code> prefix in the name (PoS events) are emitted by the new proof-of-stake consensus mechanism. They signify the corresponding assertion that has been made regarding a block specified by the event. The underlying logic of PoS events can be found in the beacon chain specification. On the occurrence of each PoS event the corresponding action that is specified by this EIP <strong>MUST</strong> be taken.</p> <p>The details provided below must be taken into account when reading those parts of the specification that refer to the PoS events:</p> <ul> <li>Reference to a block that is contained by PoS events is provided in a form of a block hash unless another is explicitly specified.</li> <li>A <code>POS_FORKCHOICE_UPDATED</code> event contains references to the head of the canonical chain and to the most recent finalized block. Before the first finalized block occurs in the system the finalized block hash provided by this event is stubbed with <code>0x0000000000000000000000000000000000000000000000000000000000000000</code>.</li> <li><strong><code>FIRST_FINALIZED_BLOCK</code></strong> The first finalized block that is designated by <code>POS_FORKCHOICE_UPDATED</code> event and has the hash that differs from the stub.</li> </ul> <h3 id="client-software-configuration">Client software configuration</h3> <p>The following set of parameters is a part of client software configuration and <strong>MUST</strong> be included into its binary distribution:</p> <ul> <li><code>TERMINAL_TOTAL_DIFFICULTY</code></li> <li><code>FORK_NEXT_VALUE</code></li> <li><code>TERMINAL_BLOCK_HASH</code></li> <li><code>TERMINAL_BLOCK_NUMBER</code></li> </ul> <p><em>Note</em>: If <code>TERMINAL_BLOCK_HASH</code> is stubbed with <code>0x0000000000000000000000000000000000000000000000000000000000000000</code> then <code>TERMINAL_BLOCK_HASH</code> and <code>TERMINAL_BLOCK_NUMBER</code> parameters <strong>MUST NOT</strong> take an effect.</p> <h3 id="pow-block-processing">PoW block processing</h3> <p>PoW blocks that are descendants of any terminal PoW block <strong>MUST NOT</strong> be imported. This implies that a terminal PoW block will be the last PoW block in the canonical chain.</p> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th></tr></thead><tbody> <tr><td><strong><code>MAX_EXTRA_DATA_BYTES</code></strong></td><td><code>32</code></td></tr> </tbody></table> <h3 id="block-structure">Block structure</h3> <p>Beginning with <code>TRANSITION_BLOCK</code>, a number of previously dynamic block fields are deprecated by enforcing these values to instead be constants. Each block field listed in the table below <strong>MUST</strong> be replaced with the corresponding constant value.</p> <table><thead><tr><th>Field</th><th>Constant value</th><th>Comment</th></tr></thead><tbody> <tr><td><strong><code>ommersHash</code></strong></td><td><code>0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347</code></td><td><code>= Keccak256(RLP([]))</code></td></tr> <tr><td><strong><code>difficulty</code></strong></td><td><code>0</code></td><td></td></tr> <tr><td><strong><code>mixHash</code></strong></td><td><code>0x0000000000000000000000000000000000000000000000000000000000000000</code></td><td></td></tr> <tr><td><strong><code>nonce</code></strong></td><td><code>0x0000000000000000</code></td><td></td></tr> <tr><td><strong><code>ommers</code></strong></td><td><code>[]</code></td><td><code>RLP([]) = 0xc0</code></td></tr> </tbody></table> <p>Beginning with <code>TRANSITION_BLOCK</code>, the validation of the block's <strong><code>extraData</code></strong> field changes: The length of the block's <strong><code>extraData</code></strong> <strong>MUST</strong> be less than or equal to <strong><code>MAX_EXTRA_DATA_BYTES</code></strong> bytes.</p> <p><em>Note</em>: Logic and validity conditions of block fields that are <em>not</em> specified here <strong>MUST</strong> remain unchanged. Additionally, the overall block format <strong>MUST</strong> remain unchanged.</p> <p><em>Note</em>: Subsequent EIPs may override the constant values specified above to provide additional functionality. For an example, see <a href="https://wg-eips.ritovision.com/4399/">EIP-4399</a>.</p> <h3 id="block-validity">Block validity</h3> <p>Beginning with <code>TRANSITION_BLOCK</code>, the block validity conditions <strong>MUST</strong> be altered by the following:</p> <ul> <li>Remove verification of the block's <strong><code>difficulty</code></strong> value with respect to the difficulty formula.</li> <li>Remove verification of the block's <strong><code>nonce</code></strong> and <strong><code>mixHash</code></strong> values with respect to the Ethash function.</li> <li>Remove all validation rules that are evaluated over the list of ommers and each member of this list.</li> <li>Add verification of the fields noted in the <a href="https://wg-eips.ritovision.com/3675/#block-structure">block structure</a> section.</li> </ul> <p><em>Note</em>: If one of the new rules fails then the block <strong>MUST</strong> be invalidated.</p> <p><em>Note</em>: Validity rules that are not specified in the list above <strong>MUST</strong> remain unchanged.</p> <h4 id="transition-block-validity">Transition block validity</h4> <p>In addition to satisfying the above conditions, <code>TRANSITION_BLOCK</code> <strong>MUST</strong> be a child of a terminal PoW block. That is, a parent of <code>TRANSITION_BLOCK</code> <strong>MUST</strong> satisfy terminal PoW block conditions.</p> <h3 id="block-and-ommer-rewards">Block and ommer rewards</h3> <p>Beginning with <code>TRANSITION_BLOCK</code>, block and ommer rewards are deprecated. Specifically, the following actions <strong>MUST</strong> be taken:</p> <ul> <li>Remove increasing the balance of the block's <strong><code>beneficiary</code></strong> account by the block reward.</li> <li>Remove increasing the balance of the block's <strong><code>beneficiary</code></strong> account by the ommer inclusion reward per each ommer.</li> <li>Remove increasing the balance of the ommer's <strong><code>beneficiary</code></strong> account by the ommer block reward per each ommer.</li> </ul> <p><em>Note</em>: Transaction fee mechanics affecting the block's <code>beneficiary</code> account <strong>MUST</strong> remain unchanged.</p> <h3 id="fork-choice-rule">Fork choice rule</h3> <p>If set, <code>TERMINAL_BLOCK_HASH</code> parameter affects the PoW heaviest chain rule in the following way:</p> <ul> <li>Canonical blockchain <strong>MUST</strong> contain a block with the hash defined by <code>TERMINAL_BLOCK_HASH</code> parameter at the height defined by <code>TERMINAL_BLOCK_NUMBER</code> parameter.</li> </ul> <p><em>Note</em>: This rule is akin to block hash whitelisting functionality already present in client software implementations.</p> <p>As of the first <code>POS_FORKCHOICE_UPDATED</code> event, the fork choice rule <strong>MUST</strong> be altered in the following way:</p> <ul> <li>Remove the existing PoW heaviest chain rule.</li> <li>Adhere to the new PoS LMD-GHOST rule.</li> </ul> <p>The new PoS LMD-GHOST fork choice rule is specified as follows. On each occurrence of a <code>POS_FORKCHOICE_UPDATED</code> event including the first one, the following actions <strong>MUST</strong> be taken:</p> <ul> <li>Consider the chain starting at genesis and ending with the head block nominated by the event as the canonical blockchain.</li> <li>Set the head of the canonical blockchain to the corresponding block nominated by the event.</li> <li>Beginning with the <code>FIRST_FINALIZED_BLOCK</code>, set the most recent finalized block to the corresponding block nominated by the event.</li> </ul> <p>Changes to the block tree store that are related to the above actions <strong>MUST</strong> be applied atomically.</p> <p><em>Note</em>: This rule <strong>MUST</strong> be strictly enforced. "Optimistic" updates to the head <strong>MUST NOT</strong> be made. That is -- if a new block is processed on top of the current head block, this new block becomes the new head if and only if an accompanying <code>POS_FORKCHOICE_UPDATED</code> event occurs.</p> <h3 id="network">Network</h3> <h4 id="fork-identifier">Fork identifier</h4> <p>For the purposes of the <a href="https://wg-eips.ritovision.com/2124/">EIP-2124</a> fork identifier, nodes implementing this EIP <strong>MUST</strong> set the <code>FORK_NEXT</code> parameter to the <code>FORK_NEXT_VALUE</code>.</p> <h4 id="devp2p">devp2p</h4> <p>The networking stack <strong>SHOULD NOT</strong> send the following messages if they advertise the descendant of any terminal PoW block:</p> <ul> <li><code>NewBlockHashes (0x01)</code></li> <li><code>NewBlock (0x07)</code></li> </ul> <p>Beginning with receiving the <code>FIRST_FINALIZED_BLOCK</code>, the networking stack <strong>MUST</strong> discard the following ingress messages:</p> <ul> <li><code>NewBlockHashes (0x01)</code></li> <li><code>NewBlock (0x07)</code></li> </ul> <p>Beginning with receiving the finalized block next to the <code>FIRST_FINALIZED_BLOCK</code>, the networking stack <strong>MUST</strong> remove the handlers corresponding to the following messages:</p> <ul> <li><code>NewBlockHashes (0x01)</code></li> <li><code>NewBlock (0x07)</code></li> </ul> <p>Peers that keep sending these messages after the handlers have been removed <strong>SHOULD</strong> be disconnected.</p> <p><em>Note:</em> The logic of message handlers that are not affected by this section <strong>MUST</strong> remain unchanged.</p> <h2 id="rationale">Rationale</h2> <p>The changes specified in this EIP target a minimal requisite set of consensus and client software modifications to safely replace the existing proof-of-work consensus algorithm with the new proof-of-stake consensus represented by the already in-production beacon chain.</p> <p>This EIP was designed to minimize the complexity of hot-swapping the live consensus of the Ethereum network. Both the safety of the operation and time to production were taken into consideration. Additionally, a minimal changeset helps ensure that <em>most</em> smart contracts and services will continue to function as intended during and after the transition with little to no required intervention.</p> <h3 id="total-difficulty-triggering-the-upgrade">Total difficulty triggering the upgrade</h3> <p>See <a href="https://wg-eips.ritovision.com/3675/#terminal-total-difficulty-vs-block-number">Security considerations</a>.</p> <h3 id="parameterizing-terminal-block-hash">Parameterizing terminal block hash</h3> <p>See <a href="https://wg-eips.ritovision.com/3675/#terminal-pow-block-overriding">Security considerations</a>.</p> <h3 id="halting-the-import-of-pow-blocks">Halting the import of PoW blocks</h3> <p>See <a href="https://wg-eips.ritovision.com/3675/#halt-the-importing-of-pow-blocks">Security considerations</a>.</p> <h3 id="replacing-block-fields-with-constants">Replacing block fields with constants</h3> <p>Deprecated block fields are replaced with constant values to ensure the block format remains backwards compatible. Preserving the block format aids existing smart contracts and services in providing uninterrupted service during and after this transition.</p> <p>Particularly, this is important for those smart contracts that verify Merkle proofs of transaction/receipt inclusion and state by validating the hash of externally provided block header against the corresponding value returned by the <code>BLOCKHASH</code> operation.</p> <p>This change introduces an additional validity rule that enforces the replacement of deprecated block fields.</p> <h3 id="replacing-difficulty-with-0">Replacing <code>difficulty</code> with <code>0</code></h3> <p>After deprecating the proof-of-work the notion of difficulty no longer exists and replacing the block header <strong><code>difficulty</code></strong> field with <code>0</code> constant is semantically sound.</p> <h3 id="changing-block-validity-rules">Changing block validity rules</h3> <p>The rule set enforcing the PoW seal validity is replaced with the corresponding PoS rules along with the consensus upgrade as the rationale behind this change.</p> <p>An additional rule validating a set of deprecated block fields is required by the block format changes introduced by this specification.</p> <h3 id="removing-block-rewards">Removing block rewards</h3> <p>Existing rewards for producing and sealing blocks are deprecated along with the PoW mechanism. The new PoS consensus becomes both responsible for sealing blocks and for issuing block rewards once this specification enters into effect.</p> <h3 id="supplanting-fork-choice-rule">Supplanting fork choice rule</h3> <p>The fork choice rule of the PoW mechanism becomes completely irrelevant after the upgrade and is replaced with the corresponding rule of the new PoS consensus mechanism.</p> <h3 id="remove-of-pos-consensus-validated">Remove of <code>POS_CONSENSUS_VALIDATED</code></h3> <p>In prior draft versions of this EIP, an additional POS event -- <code>POS_CONSENSUS_VALIDATED</code> -- was required as a validation condition for blocks. This event gave the signal to either fully incorporate or prune the block from the block tree.</p> <p>This event was removed for two reasons:</p> <ol> <li>This event was an unnecessary optimization to allow for pruning of "bad" blocks from the block tree. This optimization was unnecessary because the PoS consensus would never send <code>POS_FORKCHOICE_UPDATED</code> for any such bad blocks or their descendants, and eventually any such blocks would be able to be pruned after a PoS finality event of an alternative branch in the block tree.</li> <li>This event was dangerous in some scenarios because a block could be referenced by two <em>different</em> and conflicting PoS branches. Thus for the same block in some scenarios, both a <code>POS_CONSENSUS_VALIDATED == TRUE</code> and <code>POS_CONSENSUS_VALIDATED == FALSE</code> event could sent, entirely negating the ability to safely perform the optimization in (1).</li> </ol> <h3 id="eip-2124-fork-identifier">EIP-2124 fork identifier</h3> <p>The value of <code>FORK_NEXT</code> in EIP-2124 refers to the block number of the next fork a given node knows about and <code>0</code> otherwise.</p> <p>The number of <code>TRANSITION_BLOCK</code> cannot be known ahead of time given the dynamic nature of the transition trigger condition. As the block will not be known a priori, nodes can't use its number for <code>FORK_NEXT</code> and in light of this fact an explicitly set <code>FORK_NEXT_VALUE</code> is used instead.</p> <h3 id="removing-block-gossip">Removing block gossip</h3> <p>After the upgrade of the consensus mechanism only the beacon chain network will have enough information to validate a block. Thus, block gossip provided by the <code>eth</code> network protocol will become unsafe and is deprecated in favour of the block gossip existing in the beacon chain network.</p> <p>It is recommended for the client software to not propagate descendants of any terminal PoW block to reduce the load on processing the P2P component and stop operating in the environment with unknown security properties.</p> <h3 id="restricting-the-length-of-extradata">Restricting the length of <code>extraData</code></h3> <p>The <code>extraData</code> field is defined as a maximum of <code>32</code> bytes in the yellow paper. Thus mainnet and most PoW testnets cap the value at <code>32</code> bytes. <code>extraData</code> fields of greater length are used by clique testnets and other networks to carry special signature/consensus schemes. This EIP restricts the length of <code>extraData</code> to <code>32</code> bytes because any network that is transitioning from another consensus mechanism to a beacon chain PoS consensus mechanism no longer needs extended or unbounded <code>extraData</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backward incompatibilities in block validity, block rewards and fork choice rule.</p> <p>The design of the consensus upgrade specified by this document does not introduce backward incompatibilities for existing applications and services built on top of Ethereum except for those that are described in the <a href="https://wg-eips.ritovision.com/3675/#evm">EVM</a> section below or heavily depends on the PoW consensus in any other way.</p> <h3 id="evm">EVM</h3> <p>Although this EIP does not introduce any explicit changes to the EVM there are a couple of places where it may affect the logic of existing smart contracts.</p> <h4 id="difficulty">DIFFICULTY</h4> <p><code>DIFFICULTY</code> operation will always return <code>0</code> after this EIP takes effect and deprecates the <strong><code>difficulty</code></strong> field by replacing it with <code>0</code> constant.</p> <p><em>Note:</em> Altering the <code>DIFFICULTY</code> semantics to return randomness accumulated by the beacon chain is under consideration but will be introduced in a separate EIP.</p> <h4 id="blockhash">BLOCKHASH</h4> <p>Pseudo-random numbers obtained as the output of <code>BLOCKHASH</code> operation become more insecure after this EIP takes effect and the PoW mechanism (which decreases the malleability of block hashes) gets supplanted by PoS.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>Block validity <ul> <li>Beginning with <code>TRANSITION_BLOCK</code>, block is invalidated if any of the following is true: <ul> <li><code>ommersHash != Keccak256(RLP([]))</code></li> <li><code>difficulty != 0</code></li> <li><code>nonce != 0x0000000000000000</code></li> <li><code>len(extraData) &gt; MAX_EXTRA_DATA_BYTES</code></li> </ul> </li> <li>Beginning with <code>TRANSITION_BLOCK</code>, block rewards aren't added to <code>beneficiary</code> account</li> </ul> </li> <li>Client software adheres to PoS LMD-GHOST rule <ul> <li>Head and finalized blocks are set according to the recent <code>POS_FORKCHOICE_UPDATED</code> event</li> <li>No fork choice state is updated unless <code>POS_FORKCHOICE_UPDATED</code> event is received</li> </ul> </li> <li>Transition process <ul> <li>Client software doesn't process any PoW block beyond a terminal PoW block</li> <li>Beginning with <code>TRANSITION_BLOCK</code>, client software applies new block validity rules</li> <li>Beginning with the first <code>POS_FORKCHOICE_UPDATED</code>, client software switches its fork choice rule to PoS LMD-GHOST</li> <li><code>TRANSITION_BLOCK</code> must be a child of a terminal PoW block</li> <li><code>NewBlockHashes (0x01)</code> and <code>NewBlock (0x07)</code> network messages are discarded after receiving the <code>FIRST_FINALIZED_BLOCK</code></li> </ul> </li> </ul> <h2 id="security-considerations">Security Considerations</h2> <h3 id="beacon-chain">Beacon chain</h3> <p>See Security Considerations section of <a href="https://wg-eips.ritovision.com/2982/#security-considerations">EIP-2982</a>.</p> <h3 id="transition-process">Transition process</h3> <p>The transition process used to take this specification into effect is a more sophisticated version of a hardfork -- the regular procedure of applying backwards incompatible changes in the Ethereum network. This process has multiple successive steps instead of the normal block-height point condition of simpler hardforks.</p> <p>The complexity of this upgrade process stems from this fork targeting the underlying consensus mechanism rather than the execution layer within the consensus mechanism. Although the design seeks simplicity where possible, safety and liveness considerations during this transition have been prioritized.</p> <h4 id="terminal-total-difficulty-vs-block-number">Terminal total difficulty vs block number</h4> <p>Using a pre-defined block number for the hardfork is unsafe in this context due to the PoS fork choice taking priority during the transition.</p> <p>An attacker may use a minority of hash power to build a malicious chain fork that would satisfy the block height requirement. Then the first PoS block may be maliciously proposed on top of the PoW block from this adversarial fork, becoming the head and subverting the security of the transition.</p> <p>To protect the network from this attack scenario, difficulty accumulated by the chain (total difficulty) is used to trigger the upgrade.</p> <h4 id="ability-to-jump-between-terminal-pow-blocks">Ability to jump between terminal PoW blocks</h4> <p>There could be the case when a terminal PoW block is not observed by the majority of network participants due to (temporal) network partitioning. In such a case, this minority would switch their fork choice to the new rule provided by the PoS rooted on the minority terminal PoW block that they observed.</p> <p>The transition process allows the network to re-org between forks with different terminal PoW blocks as long as (a) these blocks satisfy the terminal PoW block conditions and (b) the <code>FIRST_FINALIZED_BLOCK</code> has not yet been received. This provides resilience against adverse network conditions during the transition process and prevents irreparable forks/partitions.</p> <h4 id="halt-the-importing-of-pow-blocks">Halt the importing of PoW blocks</h4> <p>Suppose the part of the client software that is connected to the beacon chain network goes offline before the Ethereum network reaches the <code>TERMINAL_TOTAL_DIFFICULTY</code> and stays offline while the network meets this threshold. Such an event makes the client software unable to switch to PoS and allows it to keep following the PoW chain if this chain is being built beyond the terminal PoW block. Depending on how long the beacon chain part was offline, it could result in different adverse effects such as:</p> <ul> <li>The client has no post-state for the terminal PoW block (the state has been pruned) which prevents it from doing the re-org to the PoS chain and leaving syncing from scratch as the only option to recover.</li> <li>An application, a user or a service uses the data from the wrong fork (PoW chain that is kept being built) which can cause security issues on their side.</li> </ul> <p>Not importing PoW blocks that are beyond the terminal PoW block prevents these adverse effects on safety/re-orgs in the event of software or configuration failures <em>in favor</em> of a liveness failure.</p> <h4 id="terminal-pow-block-overriding">Terminal PoW block overriding</h4> <p>There is a mechanism allowing for accelerating the consensus upgrade in emergency cases. This EIP considers the following emergency case scenarios for the acceleration to come into effect:</p> <ul> <li>A drop of the network hashing rate which delays the upgrade significantly.</li> <li>Attacks on the PoW network before the upgrade.</li> </ul> <p>The first case can be safely accelerated by updating the following parameters:</p> <ul> <li><code>TERMINAL_TOTAL_DIFFICULTY</code> -- reset to a value that is closer in time than the original one.</li> <li><code>FORK_NEXT_VALUE</code> -- adjust accordingly.</li> </ul> <p>The second, more dire attack scenario requires a more invasive override:</p> <ul> <li><code>TERMINAL_BLOCK_HASH</code> -- set to the hash of a certain block to become the terminal PoW block.</li> <li><code>TERMINAL_BLOCK_NUMBER</code> -- set to the number of a block designated by <code>TERMINAL_BLOCK_HASH</code>.</li> <li><code>TERMINAL_TOTAL_DIFFICULTY</code> -- set to the total difficulty value of a block designated by <code>TERMINAL_BLOCK_HASH</code>.</li> <li><code>FORK_NEXT_VALUE</code> -- adjust accordingly.</li> </ul> <p><em>Note</em>: Acceleration in the second case is considered for the most extreme of scenarios because it will result in a non-trivial liveness failure on Ethereum Mainnet.</p> <h3 id="ancient-blocks-are-no-longer-a-requisite-for-a-network-security">Ancient blocks are no longer a requisite for a network security</h3> <p>Keeping historical blocks starting from genesis is essential in the PoW network. A header of every block that belongs to a particular chain is required to justify the validity of this chain with respect to the PoW seal.</p> <p>Validating the entire history of the chain is not required by the new PoS mechanism. Instead, the sync process in the PoS network relies on weak subjectivity checkpoints, which are historical snapshots shared by peers on the network. This means historical blocks beyond weak subjectivity checkpoint are no longer a requisite for determining the canonical blockchain.</p> <p>Specification of weak subjectivity checkpoints can be found in the <code>ethereum/consensus-specs</code> repository.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-07-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Holst Swendehttps://github.com/holiman Paweł Bylicahttps://github.com/chfast Alex Beregszaszihttps://github.com/axic Andrei Maiborodahttps://github.com/gumb0 https://wg-eips.ritovision.com/3860/

Limit the maximum size of initcode to 49152 and apply extra gas cost of 2 for every 32-byte chunk of initcode

<h2 id="abstract">Abstract</h2> <p>We extend <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> by introducing a maximum size limit for <code>initcode</code> (<code>MAX_INITCODE_SIZE = 2 * MAX_CODE_SIZE = 49152</code>).</p> <p>Furthermore, we introduce a charge of <code>2</code> gas for every 32-byte chunk of <code>initcode</code> to represent the cost of jumpdest-analysis.</p> <p>Lastly, the size limit results in the nice-to-have property that EVM code size, code offset (<code>PC</code>), and jump offset fits a 16-bit value.</p> <h2 id="motivation">Motivation</h2> <p>During contract creation the client has to perform jumpdest-analysis on the <code>initcode</code> prior to execution. The work performed scales linearly with the size of the <code>initcode</code>. This work currently is not metered, nor is there a protocol enforced upper bound for the size.</p> <p>There are three costs charged today:</p> <ol> <li>Cost for calldata aka <code>initcode</code>: 4 gas for a byte with the value of zero, and 16 gas otherwise.</li> <li>Cost for the resulting deployed code: 200 gas per byte.</li> <li>Cost of address calculation (hashing of code) in case of <code>CREATE2</code> only: 6 gas per word.</li> </ol> <p>Only the first cost applies to <code>initcode</code>, but only in the case of contract creation transactions. For the case of <code>CREATE</code>/<code>CREATE2</code> there is no such cost, and it is possible to programmatically generate variations of <code>initcode</code> in a relatively cheap manner. In the past it was possible to craft malicious <code>initcode</code> due to a vulnerability fixed in 2017 by geth 1.6.5.</p> <p>Furthermore, the lack of a limit has caused lengthy discussions for some EVM proposals, influencing the design, or even causing a delay or cancellation of a feature.</p> <p>We are motivated by three reasons:</p> <ol> <li>Ensuring <code>initcode</code> is fairly charged (most importantly cost is proportional to <code>initcode</code>'s length) to minimize the risks for the future.</li> <li>To have a cost system which is extendable in the future.</li> <li>To simplify EVM engines by the explicit limits (code size, code offsets (<code>PC</code>), and jump offsets fit 16-bits).</li> </ol> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>INITCODE_WORD_COST</code></td><td><code>2</code></td></tr> <tr><td><code>MAX_INITCODE_SIZE</code></td><td><code>2 * MAX_CODE_SIZE</code></td></tr> </tbody></table> <p>Where <code>MAX_CODE_SIZE</code> is defined by <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> as <code>24576</code>.</p> <p>We define <code>initcode_cost(initcode)</code> to equal <code>INITCODE_WORD_COST * ceil(len(initcode) / 32)</code>.</p> <h3 id="rules">Rules</h3> <ol> <li>If length of transaction data (<code>initcode</code>) in a create transaction exceeds <code>MAX_INITCODE_SIZE</code>, transaction is invalid. (<em>Note that this is similar to transactions considered invalid for not meeting the intrinsic gas cost requirement.</em>)</li> <li>For a create transaction, extend the transaction data cost formula to include <code>initcode_cost(initcode)</code>. (<em>Note that this is included in transaction intrinsic cost, i.e. transaction with not enough gas to cover initcode cost is invalid.</em>)</li> <li>If length of <code>initcode</code> to <code>CREATE</code> or <code>CREATE2</code> instructions exceeds <code>MAX_INITCODE_SIZE</code>, instruction execution exceptionally aborts (as if it runs out of gas).</li> <li>For the <code>CREATE</code> and <code>CREATE2</code> instructions charge an extra gas cost equaling to <code>initcode_cost(initcode)</code>. This cost is deducted before the calculation of the resulting contract address and the execution of <code>initcode</code>. (<em>Note that this means before or at the same time as the hashing cost is applied in <code>CREATE2</code>.</em>)</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="gas-cost-constant">Gas cost constant</h3> <p>The value of <code>INITCODE_WORD_COST</code> is selected based on performance benchmarks of differing worst-cases per implementation. The baseline for the benchmarks is the performance of <code>KECCAK256</code> hashing in geth 1.10.9, which matches the 70 Mgas/s gas limit target on a 4.0 GHz x86_64 CPU.</p> <table><thead><tr><th>EVM</th><th>version</th><th>MB/s</th><th>B/CPUcycle</th><th>CPUcycle/B</th><th>cost of 1 B</th><th>cost of 32 B</th></tr></thead><tbody> <tr><td>geth/KECCAK256</td><td>1.10.9</td><td>357</td><td>1.8</td><td>0.6</td><td>0.2</td><td>6.0</td></tr> <tr><td>geth</td><td>1.10.9</td><td>1091</td><td>5.5</td><td>0.2</td><td>0.1</td><td>2.0</td></tr> <tr><td>evmone/Baseline</td><td>0.8.2</td><td>727</td><td>3.7</td><td>0.3</td><td>0.1</td><td>2.9</td></tr> <tr><td>evmone/Advanced</td><td>0.8.2</td><td>155</td><td>0.8</td><td>1.3</td><td>0.4</td><td>13.8</td></tr> </tbody></table> <h3 id="gas-cost-per-word-32-byte-chunk">Gas cost per word (32-byte chunk)</h3> <p>We have chosen the cost of 2 gas per word based on Geth's implementation and comparing with <code>KECCAK256</code> performance. This means the per byte cost is <code>0.0625</code>. While fractional gas costs are not permitted in the EVM, we can approximate it by charging per-word.</p> <p>Moreover, calculating gas per word is compatible with the calculation of <code>CREATE2</code>'s <em>hashcost</em> of <a href="https://wg-eips.ritovision.com/1014/">EIP-1014</a>. Therefore, the same implementation may be used for <code>CREATE</code> and <code>CREATE2</code> with different cost constants: before activation <code>0</code> for <code>CREATE</code> and <code>6</code> for <code>CREATE2</code>, after activation <code>2</code> for <code>CREATE</code> and <code>6 + 2</code> for <code>CREATE2</code>.</p> <h3 id="reason-for-size-limit-of-initcode">Reason for size limit of initcode</h3> <p>Estimating and creating worst case scenarios is easier with an upper bound in place, given one parameter for the search is greatly reduced. This allows for selecting a much more optimistic gas per byte.</p> <p>Should there be no upper bound, the cost would need to be higher accounting for unknown unknowns. Given most <em>initcode</em> (<em>TODO: state maximum initcode size resulting in deployment seen on mainnet here</em>) does not exceed the proposed limit, penalising contracts by overly conservative costs seems unnecessary.</p> <h3 id="effect-of-size-limit-of-initcode">Effect of size limit of initcode</h3> <p>In most, if not all cases when a new contract is being created, the resulting runtime code is copied from the initcode itself. For the basic case the <code>2 * MAX_CODE_SIZE</code> limit allows <code>MAX_CODE_SIZE</code> for runtime code and another <code>MAX_CODE_SIZE</code> for contract constructor code. However, the limit may have practical implications for cases where multiple contracts are deployed in a single create transaction.</p> <h3 id="initcode-cost-for-create-transaction">Initcode cost for create transaction</h3> <p>The initcode cost for create transaction data (0.0625 gas per byte) is negligible compared to the transaction data cost (4 or 16 gas per byte). Despite that, we decided to include it in the specification for consistency, and more importantly for forward compatibility.</p> <h3 id="how-to-report-initcode-limit-violation">How to report initcode limit violation?</h3> <p>We specified that initcode size limit violation for <code>CREATE</code>/<code>CREATE2</code> results in exceptional abort of the execution. This places it in the group of early out-of-gas checks, including: stack underflow, memory expansion, static call violation, initcode hashing cost, and initcode cost introduced by this EIP. They precede the later "light" checks: call depth and balance. The choice gives consistency to the order of checks and lowers implementation complexity (out-of-gas checks can be performed in any order).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a "network upgrade", since it modifies consensus rules.</p> <p>Already deployed contracts should not be affected, but certain transactions (with <code>initcode</code> beyond the proposed limit) would still be includable in a block, but result in an exceptional abort.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests should include the following cases:</p> <ul> <li>Creation transaction with gas limit enough to cover initcode cost</li> <li>Creation transaction with gas limit enough to cover intrinsic cost except initcode cost</li> <li><code>CREATE</code>/<code>CREATE2</code>/creation transaction with <code>len(initcode)</code> at <code>MAX_INITCODE_SIZE</code></li> <li><code>CREATE</code>/<code>CREATE2</code>/creation transaction with <code>len(initcode)</code> at <code>MAX_INITCODE_SIZE+1</code></li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>For client implementations, this EIP makes attacks based on jumpdest-analysis less problematic, so should increase the robustness of clients.</p> <p>For layer 2, this EIP introduces failure-modes where there previously were none. There <em>could</em> exist factory-contracts which deploy multi-level contract hierarchies, such that the code for multiple contracts are included in the initcode of the first contract. The author(s) of this EIP are not aware of any such contracts.</p> <p>Currently, on London, with <code>30M</code> gas limit, it would be possible to trigger jumpdest-analysis of a total <code>~1.3GB</code> of initcode. With this EIP, the cost for such an attack would increase by roughly <code>80M</code> gas.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-07-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/4200/

RJUMP, RJUMPI and RJUMPV instructions with a signed immediate encoding the jump destination

<h2 id="abstract">Abstract</h2> <p>Three new EVM jump instructions are introduced (<code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPV</code>) which encode destinations as signed immediate values. These can be useful in the majority of (but not all) use cases and offer a cost reduction.</p> <h2 id="motivation">Motivation</h2> <p>A recurring discussion topic is that EVM only has a mechanism for dynamic jumps. They provide a very flexible architecture with only 2 (!) instructions. This flexibility comes at a cost however: it makes analysis of code more complicated and it also (partially) resulted in the need to have the <code>JUMPDEST</code> marker.</p> <p>In a great many cases control flow is actually static and there is no need for any dynamic behaviour, though not every use case can be solved by static jumps.</p> <p>There are various ways to reduce the need for dynamic jumps, some examples:</p> <ol> <li>With native support for functions / subroutines</li> <li>A "return to caller" instruction</li> <li>A "switch-case" table with dynamic indexing</li> </ol> <p>This change does not attempt to solve these, but instead introduces a minimal feature set to allow compilers to decide which is the most adequate option for a given use case. It is expected that compilers will use <code>RJUMP</code>/<code>RJUMPI</code> almost exclusively, with the exception of returning to the caller continuing to use <code>JUMP</code>.</p> <p>This functionality does not preclude the EVM from introducing other forms of control flow later on. <code>RJUMP</code>/<code>RJUMPI</code> can efficiently co-exists with a higher-level declaration of functions, where static relative jumps should be used for intra-function control flow.</p> <p>The main benefit of these instruction is reduced gas cost (both at deploy and execution time) and better analysis properties.</p> <h2 id="specification">Specification</h2> <p>We introduce three new instructions on the same block number <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is activated on:</p> <ol> <li><code>RJUMP</code> (0xe0) - relative jump</li> <li><code>RJUMPI</code> (0xe1) - conditional relative jump</li> <li><code>RJUMPV</code> (0xe2) - relative jump via jump table</li> </ol> <p>If the code is legacy bytecode, all of these instructions result in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <p>If the code is valid EOF1:</p> <ol> <li><code>RJUMP relative_offset</code> sets the <code>PC</code> to <code>PC_post_instruction + relative_offset</code>.</li> <li><code>RJUMPI relative_offset</code> pops a value (<code>condition</code>) from the stack, and sets the <code>PC</code> to <code>PC_post_instruction + ((condition == 0) ? 0 : relative_offset)</code>.</li> <li><code>RJUMPV max_index relative_offset+</code> pops a value (<code>case</code>) from the stack, and sets the <code>PC</code> to <code>PC_post_instruction + ((case &gt; max_index) ? 0 : relative_offset[case])</code>.</li> </ol> <p>The immediate argument <code>relative_offset</code> is encoded as a 16-bit <strong>signed</strong> (two's-complement) big-endian value. Under <code>PC_post_instruction</code> we mean the <code>PC</code> position after the entire immediate value.</p> <p>The immediate encoding of <code>RJUMPV</code> is more special: the unsigned 8-bit <code>max_index</code> value determines the maximum index in the jump table. The number of <code>relative_offset</code> values following is <code>max_index+1</code>. This allows table sizes up to 256. The encoding of <code>RJUMPV</code> must have at least one <code>relative_offset</code> and thus it will take at minimum 4 bytes. Furthermore, the <code>case &gt; max_index</code> condition falling through means that in many use cases, one would place the <em>default</em> path following the <code>RJUMPV</code> instruction. An interesting feature is that <code>RJUMPV 0 relative_offset</code> is an inverted-<code>RJUMPI</code>, which can be used in many cases instead of <code>ISZERO RJUMPI relative_offset</code>.</p> <p>We also extend the validation algorithm of <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> to verify that each <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> has a <code>relative_offset</code> pointing to an instruction. This means it cannot point to an immediate data of <code>PUSHn</code>/<code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code>. It cannot point outside of code bounds. It is allowed to point to a <code>JUMPDEST</code>, but is not required to.</p> <p>Because the destinations are validated upfront, the cost of these instructions are less than their dynamic counterparts: <code>RJUMP</code> should cost 2, and <code>RJUMPI</code> and <code>RJUMPV</code> should cost 4.</p> <h2 id="rationale">Rationale</h2> <h3 id="relative-addressing">Relative addressing</h3> <p>We chose relative addressing in order to support code which is relocatable. This also means a code snippet can be injected. A technique seen used prior to this EIP to achieve the same goal was to inject code like <code>PUSHn PC ADD JUMPI</code>.</p> <p>We do not see any significant downside to relative addressing and it allows us to also deprecate the <code>PC</code> instruction.</p> <h3 id="immediate-size">Immediate size</h3> <p>The signed 16-bit immediate means that the largest jump distance possible is 32767. In the case the bytecode at <code>PC=0</code> starts with an <code>RJUMP</code>, it will be possible to jump as far as <code>PC=32770</code>.</p> <p>Given <code>MAX_CODE_SIZE = 24576</code> (in <a href="https://wg-eips.ritovision.com/170/">EIP-170</a>) and <code>MAX_INITCODE_SIZE = 49152</code> (in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>), we think the 16-bit immediate is large enough.</p> <p>A version with an 8-bit immediate would only allow moving <code>PC</code> backward by 125 or forward by 127 bytes. While that seems to be a good enough distance for many for-loops, it is likely not good enough for cross-function jumps, and since the 16-bit immediate is the same size as what a dynamic jump would take in such cases (3 bytes: <code>JUMP PUSH1 n</code>), we think having less instructions is better.</p> <p>Should there be a need to have immediate encodings of other size (such as 8-bits, 24-bits or 32-bits), it would be possible to introduce new opcodes, similarly to how multiple <code>PUSH</code> instructions exist.</p> <h3 id="pushn-jump-sequences"><code>PUSHn JUMP</code> sequences</h3> <p>If we chose absolute addressing, then <code>RJUMP</code> could be viewed similar to the sequence <code>PUSHn JUMP</code> (and <code>RJUMPI</code> similar to <code>PUSHn JUMPI</code>). In that case one could argue that instead of introducing a new instruction, such sequences should get a discount, because EVMs could optimise them.</p> <p>We think this is a bad direction to go:</p> <ol> <li>It further complicates the already complex rules of gas calculation.</li> <li>And it either requires a consensus defined internal representation for EVM code, or forces EVM implementations to do optimisations on their own.</li> </ol> <p>Both of these are risky. Furthermore we think that EVM implementations should be free to chose what optimisations they apply, and the savings do not need to be passed down at all cost.</p> <p>Additionally it requires a potentially significant change to the current implementations which depend on a streaming one-by-one execution without a lookahead.</p> <h3 id="relation-to-dynamic-jumps">Relation to dynamic jumps</h3> <p>The goal was not to completely replace the current control flow system of the EVM, but to augment it. There are many cases where dynamic jumps are useful, such as returning to the caller.</p> <p>It is possible to introduce a new mechanism for having a pre-defined table of valid jump destinations, and dynamically supplying the index within this table to accomplish some form of dynamic jumps. This is very useful for efficiently encoding a form of "switch-cases" statements. It could also be used for "return to caller" cases, however it is likely inefficient or awkward.</p> <h3 id="lack-of-jumpdest">Lack of <code>JUMPDEST</code></h3> <p><code>JUMPDEST</code> serves two purposes:</p> <ol> <li>To efficiently partition code -- this can be useful for pre-calculating total gas usage for a given <em>block</em> (i.e. instructions between <code>JUMPDEST</code>s), and for JIT/AOT translation.</li> <li>To explicitly show valid locations (otherwise any non-data location would be valid).</li> </ol> <p>This functionality is not needed for static jumps, as the analysers can easily tell destinations from the static jump immediates during jumpdest-analysis.</p> <p>There are two benefits here:</p> <ol> <li>Not wasting a byte for a <code>JUMPDEST</code> also means a saving of 200 gas during deployment, for each jump destination.</li> <li>Saving an extra 1 gas per jump during execution, given <code>JUMPDEST</code> itself cost 1 gas and is "executed" during jumping.</li> </ol> <h3 id="rjumpv-fallback-case"><code>RJUMPV</code> fallback case</h3> <p>If no match is found (i.e. the <em>default</em> case) in the <code>RJUMPV</code> instruction execution will continue without branching. This allows for gaps in the arguments to be filled with <code>0</code>s, and a choice of implementation by the programmer. Alternate options would include exceptional aborts in case of no match.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).</p> <h2 id="test-cases">Test Cases</h2> <h3 id="validation">Validation</h3> <h4 id="valid-cases">Valid cases</h4> <ul> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with <code>JUMPDEST</code> as target <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with instruction other than <code>JUMPDEST</code> as target <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li><code>RJUMPV</code> with various valid table sizes from 1 to 256</li> <li><code>RJUMP</code> as a final instruction in code section</li> </ul> <h4 id="invalid-cases">Invalid cases</h4> <ul> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> with truncated immediate</li> <li><code>RJUMPI</code>/<code>RJUMPV</code> as a final instruction in code section</li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> target outside of code section bounds</li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> target push data</li> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> target another <code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> immediate argument</li> </ul> <h3 id="execution">Execution</h3> <ul> <li><code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code> in legacy code aborts execution</li> <li><code>RJUMP</code> <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code></li> </ul> </li> <li><code>RJUMPI</code> <ul> <li><code>relative_offset</code> is positive/negative/<code>0</code> <ul> <li><code>condition</code> equals <code>0</code></li> <li><code>condition</code> does not equal <code>0</code></li> </ul> </li> </ul> </li> <li><code>RJUMPV 0 relative_offset</code> <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> </ul> </li> <li><code>RJUMPV</code> with table containing positive, negative, <code>0</code> offsets <ul> <li><code>case</code> equals <code>0</code></li> <li><code>case</code> does not equal <code>0</code></li> <li><code>case</code> outside of table bounds (<code>case &gt; max_index</code>, fallback case)</li> <li><code>case</code> &gt; 255</li> </ul> </li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Adding new instructions with immediate arguments should be carefully considered when implementing the EOF container validation algorithm.</p> <p>Static relative jump execution does not require runtime check of the jump destination. It greatly reduces execution cost. Therefore the gas cost of the new instructions can also be significantly reduced.</p> <p>The <code>RJUMPV</code> instruction relative offset table can have up to 256 one-byte entries, so reading an offset cannot be a potential attack surface.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-07-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/3651/

Starts the `COINBASE` address warm

<h2 id="abstract">Abstract</h2> <p>The <code>COINBASE</code> address shall be warm at the start of transaction execution, in accordance with the actual cost of reading that account.</p> <h2 id="motivation">Motivation</h2> <p>Direct <code>COINBASE</code> payments are becoming increasingly popular because they allow conditional payments, which provide benefits such as implicit cancellation of transactions that would revert. But accessing <code>COINBASE</code> is overpriced; the address is initially cold under the access list framework introduced in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>. This gas cost mismatch can incentivize alternative payments besides ETH, such as <a href="https://wg-eips.ritovision.com/20/">ERC-20</a>, but ETH should be the primary means of paying for transactions on Ethereum.</p> <h2 id="specification">Specification</h2> <p>At the start of transaction execution, <code>accessed_addresses</code> shall be initialized to also include the address returned by <code>COINBASE</code> (<code>0x41</code>).</p> <h2 id="rationale">Rationale</h2> <p>The addresses currently initialized warm are the addresses that should already be loaded at the start of transaction validation. The <code>ORIGIN</code> address is always loaded to check its balance against the gas limit and the gas price. The <code>tx.to</code> address is always loaded to begin execution. The <code>COINBASE</code> address should also be always be loaded because it receives the block reward and the transaction fees.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues presented by this change.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security considerations introduced by this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-06-23T00:00:00+00:00 2026-02-11T14:49:28+00:00 Alex Beregszaszihttps://github.com/axic Andrei Maiborodahttps://github.com/gumb0 Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/3670/

Validate EOF bytecode for correctness at the time of deployment.

<h2 id="abstract">Abstract</h2> <p>Introduce code validation at contract creation time for EOF formatted (<a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>) contracts. Reject contracts which contain truncated <code>PUSH</code>-data or undefined instructions. Legacy bytecode (code which is not EOF formatted) is unaffected by this change.</p> <h2 id="motivation">Motivation</h2> <p>Currently existing contracts require no validation of correctness and EVM implementations can decide how they handle truncated bytecode or undefined instructions. This change aims to bring code validity into consensus, so that it becomes easier to reason about bytecode. Moreover, EVM implementations may require fewer paths to decide which instruction is valid in the current execution context.</p> <p>If there's a desire to introduce new instructions without bumping the EOF version, having undefined instructions already deployed could potentially break such contracts, as some instructions might change their behavior. Rejecting to deploy undefined instructions allows introducing new instructions with or without bumping the EOF version.</p> <h3 id="eof1-forward-compatibility">EOF1 forward compatibility</h3> <p>The EOF1 format provides following forward compatibility properties:</p> <ol> <li>New instructions can be defined for previously unassigned opcodes. These instructions may have immediate values.</li> <li>Mandatory EOF sections may be made optional.</li> <li>New optional EOF sections may be introduced. They can be placed in any order in relation to previously defined sections.</li> </ol> <h2 id="specification">Specification</h2> <p>This feature is introduced on the same block EIP-3540 is enabled, therefore every EOF1-compatible bytecode MUST be validated according to these rules.</p> <ol> <li>Previously deprecated instructions <code>CALLCODE</code> (0xf2) and <code>SELFDESTRUCT</code> (0xff), as well as instructions deprecated in EIP-3540, are invalid and their opcodes are undefined. (<strong>NOTE</strong> there are more instructions deprecated and rejected in EOF, as specced out by separate EIPs)</li> <li>At contract creation time <em>code validation</em> is performed on each code section of the EOF container. The code is invalid if any of the checks below fails. For each instruction: <ol> <li>Check if the opcode is defined. The <code>INVALID</code> (0xfe) is considered defined.</li> <li>Check if all instructions' immediate bytes are present in the code (code does not end in the middle of instruction).</li> </ol> </li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="immediate-data">Immediate data</h3> <p>Allowing implicit zero immediate data for <code>PUSH</code> instructions introduces inefficiencies to EVM implementations without any practical use-case (the value of a <code>PUSH</code> instruction at the code end cannot be observed by EVM). This EIP requires all immediate bytes to be explicitly present in the code.</p> <h3 id="rejection-of-deprecated-instructions">Rejection of deprecated instructions</h3> <p>The deprecated instructions <code>CALLCODE</code> (0xf2) and <code>SELFDESTRUCT</code> (0xff) are removed from the <code>valid_opcodes</code> list to prevent their use in the future.</p> <h3 id="blockhash-instruction">BLOCKHASH instruction</h3> <p>The <code>BLOCKHASH</code> instruction is well replaced by the system contract introduced in <a href="https://wg-eips.ritovision.com/2935/">EIP-2935</a>. However, despite a replacement being introduced this opcode has not been deprecated. This opcode will remain valid in EOF not to differentiate from legacy bytecode.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The validation does not cover legacy bytecode (code which is not EOF formatted).</p> <h2 id="test-cases">Test Cases</h2> <h3 id="contract-creation">Contract creation</h3> <p>Each case should be tested by submitting an EOF container to EOF contract creation (as specced out in a separate EIP). Each case should be tested with code placed in code sections at different indices.</p> <h3 id="valid-codes">Valid codes</h3> <ul> <li>EOF code containing <code>INVALID</code></li> <li>EOF code with data section containing bytes that are undefined instructions</li> </ul> <h3 id="invalid-codes">Invalid codes</h3> <ul> <li>EOF code containing an undefined instruction</li> <li>EOF code ending with incomplete <code>PUSH</code> instruction</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> The ranges below are as specified by Execution Specs for Shanghai.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Note: range(s, e) excludes e, hence the +1</span></span> <span class="giallo-l"><span>shanghai_opcodes</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">00</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">0b</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">10</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">1d</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">20</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">30</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">40</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">48</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">50</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">5b</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">5f</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">60</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">6f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">70</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">7f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">80</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">8f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">90</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">9f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-keyword"> *</span><span class="z-support">range</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">a0</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">a4</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span>,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Note: 0xfe is considered assigned.</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">f0</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f1</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f2</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f3</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f4</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f5</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fa</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fd</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fe</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">ff</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Drop the opcodes deprecated and rejected in here and in EIP-3540</span></span> <span class="giallo-l"><span>rejected_in_eof</span><span class="z-keyword"> =</span><span> [</span></span> <span class="giallo-l"><span class="z-storage z-type"> 0x</span><span class="z-constant">38</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">39</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3b</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3c</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3f</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">5a</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f1</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f2</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">f4</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fa</span><span>,</span><span class="z-storage z-type"> 0x</span><span class="z-constant">ff</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"><span>valid_opcodes</span><span class="z-keyword"> =</span><span> [</span><span>op</span><span class="z-keyword"> for</span><span> op</span><span class="z-keyword"> in</span><span> shanghai_opcodes</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> rejected_in_eof</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>immediate_sizes</span><span class="z-keyword"> =</span><span class="z-constant"> 256</span><span class="z-keyword"> *</span><span> [</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span>immediate_sizes</span><span>[</span><span class="z-storage z-type">0x</span><span class="z-constant">60</span><span>:</span><span class="z-storage z-type">0x</span><span class="z-constant">7f</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>]</span><span class="z-keyword"> =</span><span class="z-support"> range</span><span>(</span><span class="z-constant">1</span><span>,</span><span class="z-constant"> 32</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> PUSH1..PUSH32</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Raises ValidationException on invalid code</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_instructions</span><span>(</span><span class="z-variable z-parameter z-function">code</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Note that EOF1 already asserts this with the code section requirements</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> pos</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure the opcode is valid</span></span> <span class="giallo-l"><span> opcode</span><span class="z-keyword"> =</span><span> code</span><span>[</span><span>pos</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> opcode</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> valid_opcodes</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> ValidationException</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">undefined opcode</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Skip immediate data</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span><span class="z-keyword"> +</span><span> immediate_sizes</span><span>[</span><span>opcode</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure last instruction&#39;s immediate doesn&#39;t go over code end</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> pos</span><span class="z-keyword"> !=</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span> ValidationException</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">truncated immediate</span><span class="z-punctuation z-definition z-string">&quot;</span><span>)</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>See <a href="https://wg-eips.ritovision.com/3540/#security-considerations">Security Considerations of EIP-3540</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-06-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Andrei Maiborodahttps://github.com/gumb0 https://wg-eips.ritovision.com/3690/

A special EOF section for storing the list of JUMPDESTs, which simplifies execution time analysis.

<h2 id="abstract">Abstract</h2> <p>Introduce a section in the EOF format (<a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>) for storing the list of <code>JUMPDEST</code>s, validate the correctness of this list at the time of contract creation, and remove the need for <code>JUMPDEST</code>-analysis at execution time. In EOF contracts, the <code>JUMPDEST</code> instruction is not needed anymore and becomes invalid. Legacy contracts are entirely unaffected by this change.</p> <h2 id="motivation">Motivation</h2> <p>Currently existing contracts require no validation of correctness, but every time they are executed, a list must be built containing all the valid jump-destinations. This is an overhead which can be avoided, albeit the effect of the overhead depends on the client implementation.</p> <p>With the structure provided by EIP-3540 it is easy to store and transmit a table of valid jump-destinations instead of using designated <code>JUMPDEST</code> (0x5b) opcodes in the code.</p> <p>The goal of this change is that we trade less complexity (and processing time) at execution time for more complexity at contract creation time. Through benchmarks we have identified that the mandatory execution preparation time is the same as before for extreme cases (i.e. deliberate edge cases), while it is ~10x faster for the average case.</p> <p>Finally, this change puts an implicit bound on "initcode analysis" which is now limited to jumpdests section loading of max size of 0xffff. The legacy code remains vulnerable.</p> <h2 id="specification">Specification</h2> <p>This feature is introduced on the very same block <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> is enabled, therefore every EOF1-compatible bytecode MUST have a JUMPDEST-table if it uses jumps.</p> <p><em>Remark:</em> We rely on the notation of <em>initcode</em>, <em>code</em> and <em>creation</em> as defined by <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a>, and extend validation rules of <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>.</p> <h3 id="eof-container-changes">EOF container changes</h3> <ol> <li> <p>A new EOF section called <code>jumpdests</code> (<code>section_kind = 3</code>) is introduced. It contains a sequence of <em>n</em> unsigned integers <em>jumploc_i</em>.</p> </li> <li> <p>The <em>jumploc_i</em> values are encoded with <a rel="external" href="https://en.wikipedia.org/wiki/LEB128#Unsigned_LEB128">unsigned LEB128</a>.</p> <table><thead><tr><th>description</th><th>encoding</th></tr></thead><tbody> <tr><td>jumploc₀</td><td>unsigned LEB128</td></tr> <tr><td>jumploc₁</td><td>unsigned LEB128</td></tr> <tr><td>...</td><td></td></tr> <tr><td>jumploc_n</td><td>unsigned LEB128</td></tr> </tbody></table> </li> <li> <p>The jump destinations represent the set of valid code positions as arguments to jump instructions. They are delta-encoded therefore partial sum must be performed to retrieve the absolute offsets.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> jumpdest</span><span>(</span><span class="z-variable z-parameter z-function">n</span><span>:</span><span class="z-support"> int</span><span>,</span><span class="z-variable z-parameter z-function"> jumpdests_table</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> sum</span><span>(</span><span>jumpdests_table</span><span>[</span><span>:</span><span>n</span><span class="z-keyword">+</span><span class="z-constant">1</span><span>]</span><span>)</span></span></code></pre></li> </ol> <h3 id="validation-rules">Validation rules</h3> <blockquote> <p>This section extends contract creation validation rules (as defined in EIP-3540).</p> </blockquote> <ol start="4"> <li>The <code>jumpdests</code> section MUST be present if and only if the <code>code</code> section contains <code>JUMP</code> or <code>JUMPI</code> opcodes.</li> <li>If the <code>jumpdests</code> section is present it MUST directly precede the <code>code</code> section. In this case a valid EOF bytecode will have the form of <code>format, magic, version, [jumpdests_section_header], code_section_header, [data_section_header], 0, [jumpdests_section_contents], code_section_contents, [data_section_contents]</code>.</li> <li>The LEB128 encoding of a <code>jumploc</code> must be valid: the encoding must be complete and not read out of <code>jumpdests</code> section. As an additional constraint, the shortest possible encoding must be used.</li> <li>With an exception of the first entry, the value of <code>jumploc</code> MUST NOT be 0.</li> <li>Every <code>jumploc</code> MUST point to a valid opcode. They MUST NOT point into PUSH-data or outside of the code section.</li> <li>The <code>JUMPDEST</code> (0x5b) instruction becomes undefined (Note: According to rules of EIP-3670, deploying the code will fail if it contains <code>JUMPDEST</code>)</li> </ol> <h3 id="execution">Execution</h3> <ol start="10"> <li>When executing <code>JUMP</code> or <code>JUMPI</code> instructions, the jump destination MUST be in the <code>jumpdests</code> table. Otherwise, the execution aborts with <em>bad jump destination</em>. In case of <code>JUMPI</code>, the check is done only when the jump is to be taken (no change to the previous behaviour).</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="jumpdests-section-is-bounded">Jumpdests section is bounded</h3> <p>The length of the <code>jumpdests</code> section is bounded by the EOF maximum section size value 0xffff. Moreover, for deployed code this is additionally limited by the max bytecode size 0x6000. Then any valid <code>jumpdests</code> section may not be larger than 0x3000.</p> <h3 id="delta-encoding">Delta encoding</h3> <p>Delta-encoding is very efficient for this job. From a quick analysis of a small set of contracts <code>JUMPDEST</code> opcodes are relatively close to each other. In the delta-encoding the values almost never exceed 128. Combined with any form of variable-length quantity (VLQ) where values &lt; 128 occupy one byte, encoding of single jumpdest takes ~1 byte. We also remove <code>JUMPDEST</code> opcodes from the code section therefore the total bytecode length remains the same if extreme examples are ignored.</p> <p>By extreme examples we mean contracts having a distance between two subsequent JUMPDESTs larger than 128. Then the LEB128 encoding of such distance requires more than one byte and the total bytecode size will increase by the additional number of bytes used.</p> <h3 id="leb128-for-offsets">LEB128 for offsets</h3> <p>The LEB128 encoding is the most popular VLQ used in DWARF and WebAssembly.</p> <p>LEB128 allows encoding a fixed value with arbitrary number of bytes by having zero payloads for most significant bits of the value. To ensure there exists only single encoding of a given value, we additionally require the shortest possible LEB128 encoding to be used. This constraint is also required by WebAssembly.</p> <h3 id="size-prefix-for-offsets">Size-prefix for offsets</h3> <p>This is another option for encoding inspired by UTF-8. The benefit is that the number of following bytes is encoded in the first byte (the top two bits), so the expected length is known upfront.</p> <p>A simple decoder is the following:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> decode</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span></span> <span class="giallo-l"><span> size_prefix</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> &gt;&gt;</span><span class="z-constant"> 6</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> size_prefix</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-support"> input</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> &amp;</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3f</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> size_prefix</span><span class="z-keyword"> ==</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span class="z-support">input</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> &amp;</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3f</span><span>)</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 8</span><span class="z-keyword"> |</span><span class="z-support"> input</span><span>[</span><span class="z-constant">1</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> size_prefix</span><span class="z-keyword"> ==</span><span class="z-constant"> 2</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span class="z-support">input</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> &amp;</span><span class="z-storage z-type"> 0x</span><span class="z-constant">3f</span><span>)</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 16</span><span class="z-keyword"> |</span><span> (</span><span class="z-support">input</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 8</span><span>)</span><span class="z-keyword"> |</span><span class="z-support"> input</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Do not support case 3</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span class="z-constant">False</span><span>)</span></span></code></pre><h3 id="empty-table">Empty table</h3> <p>In case code does not use jumps, an empty JUMPDEST table is represented by omitting <code>jumpdests</code> section as opposed to a section that is always present, but allowed to be empty. This is consistent with the requirement of EIP-3540 for section size to be non-zero. Additionally, omitting the section saves 3 bytes of code storage.</p> <h3 id="why-jumpdests-before-code">Why jumpdests before code?</h3> <p>The contents of <code>jumpdests</code> section are always needed to start EVM execution. For chunked and/or merkleized bytecode it is more efficient to have <code>jumpdests</code> just after the EOF header so they can share the same first chunk(s).</p> <h3 id="code-chunking-merkleization">Code chunking / merkleization</h3> <p>In code chunking the contract code is split into (fixed size) chunks. Due to the requirement of jumpdest-analysis, it must be known where the first instruction starts in a given chunk, in case the split happened within a PUSH-data. This is commonly accomplished with reserving the first byte of the chunk as the "first instruction offset" (FIO) field.</p> <p>With this EIP, code chunking does not need to have such a field. However, the jumpdest table must be provided instead (for all the chunks up until the last jump location used during execution).</p> <h3 id="benchmarks-performance-analysis">Benchmarks / performance analysis</h3> <p>We compared the performance of <code>jumpdests</code> section loading to JUMPDEST analysis in evmone/Baseline interpreter. In both cases a bitset of valid jumpdest positions is built.</p> <p>We used the worst case for <code>jumpdests</code> section as the benchmark baseline. This is the case where every position in the code section is valid jumpdest. I.e. the bytecode has as many jumpdests as possible making the jumpdests section as large as possible. The encoded representation is <code>0x00, 0x01, 0x01, 0x01, ...</code>.</p> <p>This also happen to be the worst case for the JUMPDEST analysis.</p> <p>Further, we picked 5 popular contracts from the Ethereum mainnet.</p> <table><thead><tr><th>case</th><th>size</th><th>num JUMPDESTs</th><th>JUMPDEST analysis (cycles/byte)</th><th>jumpdests load (cycles/byte)</th><th>performance change</th></tr></thead><tbody> <tr><td>worst</td><td>65535</td><td>65535</td><td>9.11</td><td>9.36</td><td>2.75%</td></tr> <tr><td>RoninBridge</td><td>1760</td><td>71</td><td>3.57</td><td></td><td>-89.41%</td></tr> <tr><td>UniswapV2ERC20</td><td>2319</td><td>61</td><td>2.10</td><td></td><td>-88.28%</td></tr> <tr><td>DepositContract</td><td>6358</td><td>123</td><td>1.86</td><td></td><td>-90.24%</td></tr> <tr><td>TetherToken</td><td>11075</td><td>236</td><td>1.91</td><td></td><td>-89.58%</td></tr> <tr><td>UniswapV2Router02</td><td>21943</td><td>468</td><td>2.26</td><td></td><td>-91.17%</td></tr> </tbody></table> <p>For the worst case the performance difference between JUMPDEST analysis and jumpdests section loading is very small. The performance very slow compared to memory copy (0.15 cycles/byte).</p> <p>However, the maximum length for the worst cases is different. For JUMPDEST analysis this is 24576 (0x6000) for deployed contracts and only limited by EVM memory cost in case of <em>initcode</em> (can be over 1MB). For jumpdests sections, the limit is 12288 for deployed contracts (the deployed bytecode length limit must be split equally between jumpdests and code sections). For <em>initcode</em> case, the limit is 65535 because this is the maximum section size allowed by EOF.</p> <p>For "popular" contracts the gained efficiency is ~10x because the jumpdests section is relatively small compared to the code section and therefore there is much less bytes to loop over than in JUMPDEST analysis.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>We extend the <code>validate_code()</code> function of <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a>:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> The same table as in EIP-3670</span></span> <span class="giallo-l"><span>valid_opcodes</span><span class="z-keyword"> =</span><span class="z-constant"> ...</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Remove JUMPDEST from the list of valid opcodes</span></span> <span class="giallo-l"><span>valid_opcodes</span><span>.</span><span>remove</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">5b</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This helper decodes a single unsigned LEB128 encoded value</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This will abort on truncated (short) input</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> leb128u_decode</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> (</span><span class="z-support">int</span><span>,</span><span class="z-support"> int</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> ret</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> shift</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> consumed_bytes</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span class="z-constant"> True</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Check for truncated input</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>consumed_bytes</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Only allow up to 4-byte long leb128 encodings</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>consumed_bytes</span><span class="z-keyword"> &lt;=</span><span class="z-constant"> 3</span><span>)</span></span> <span class="giallo-l"><span> input_byte</span><span class="z-keyword"> =</span><span class="z-support"> input</span><span>[</span><span>consumed_bytes</span><span>]</span></span> <span class="giallo-l"><span> consumed_bytes</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> ret</span><span class="z-keyword"> |=</span><span> (</span><span>input_byte</span><span class="z-keyword"> &amp;</span><span class="z-storage z-type"> 0x</span><span class="z-constant">7f</span><span>)</span><span class="z-keyword"> &lt;&lt;</span><span> shift</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>input_byte</span><span class="z-keyword"> &amp;</span><span class="z-storage z-type"> 0x</span><span class="z-constant">80</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Do not allow additional leading zero bits.</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>input_byte</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-invalid z-illegal"> ||</span><span> consumed_bytes</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> break</span></span> <span class="giallo-l"><span> shift</span><span class="z-keyword"> +=</span><span class="z-constant"> 7</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>ret</span><span>,</span><span> consumed_bytes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This helper parses the jumpdest table into a list of relative offsets</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This will abort on truncated (short) input</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> parse_table</span><span>(</span><span class="z-variable z-parameter z-function">input</span><span>:</span><span class="z-support"> bytes</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> jumpdests</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> pos</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span class="z-support">input</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> value</span><span>,</span><span> consumed_bytes</span><span class="z-keyword"> =</span><span> leb128u_decode</span><span>(</span><span class="z-support">input</span><span>[</span><span>pos</span><span>:</span><span>]</span><span>)</span></span> <span class="giallo-l"><span> jumpdests</span><span>.</span><span>append</span><span>(</span><span>value</span><span>)</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span> consumed_bytes</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> jumpdests</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This helper translates the delta offsets into absolute ones</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> This will abort on invalid 0-value entries</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_jumpdests</span><span>(</span><span class="z-variable z-parameter z-function">delta</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>)</span><span> -&gt;</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> jumpdests</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span> partial_sum</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> first</span><span class="z-keyword"> =</span><span class="z-constant"> True</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> d</span><span class="z-keyword"> in</span><span> delta</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> first</span><span>:</span></span> <span class="giallo-l"><span> first</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>d</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> partial_sum</span><span class="z-keyword"> +=</span><span> d</span></span> <span class="giallo-l"><span> jumpdests</span><span>.</span><span>append</span><span>(</span><span>partial_sum</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> jumpdests</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Fails with assertion on invalid code</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Expects list of absolute jumpdest offsets</span></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> validate_code</span><span>(</span><span class="z-variable z-parameter z-function">code</span><span>:</span><span class="z-support"> bytes</span><span>,</span><span class="z-variable z-parameter z-function"> jumpdests</span><span>:</span><span> list</span><span>[</span><span class="z-support">int</span><span>]</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> pos</span><span class="z-keyword"> &lt;</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure the opcode is valid</span></span> <span class="giallo-l"><span> opcode</span><span class="z-keyword"> =</span><span> code</span><span>[</span><span>pos</span><span>]</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>opcode</span><span class="z-keyword"> in</span><span> valid_opcodes</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Remove touched offset</span></span> <span class="giallo-l"><span class="z-keyword"> try</span><span>:</span></span> <span class="giallo-l"><span> jumpdests</span><span>.</span><span>remove</span><span>(</span><span>pos</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> except</span><span class="z-support"> ValueError</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Skip pushdata</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> opcode</span><span class="z-keyword"> &gt;=</span><span class="z-storage z-type"> 0x</span><span class="z-constant">60</span><span class="z-keyword"> and</span><span> opcode</span><span class="z-keyword"> &lt;=</span><span class="z-storage z-type"> 0x</span><span class="z-constant">7f</span><span>:</span></span> <span class="giallo-l"><span> pos</span><span class="z-keyword"> +=</span><span> opcode</span><span class="z-keyword"> -</span><span class="z-storage z-type"> 0x</span><span class="z-constant">60</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Ensure last PUSH doesn&#39;t go over code end</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span>pos</span><span class="z-keyword"> ==</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The table is invalid if there are untouched locations</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span>(</span><span class="z-support">len</span><span>(</span><span>jumpdests</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>)</span></span></code></pre><h2 id="test-cases">Test Cases</h2> <h4 id="valid-bytecodes">Valid bytecodes</h4> <ul> <li>No jumpdests</li> <li>Every byte is a jumpdest</li> <li>Distant jumpdests (0x7f and 0x3f01 bytes apart)</li> <li>Max number of jumpdests <ul> <li>1-byte offset encoding: initcode of max size (64K) with jumpdest at each byte - table contains 65536 1-byte offsets, first one is 0x00, all others equal 0x01</li> <li>2-byte offset encoding: inicode of max size with jumpdests 0x80 (128) bytes apart - table contains 512 offsets, first one is 0x7f (127), all others equal 0x8001</li> <li>3-byte offset encoding: inicode of max size with jumpdests 0x4000 (16384) bytes apart - table contains 4 offsets: 0xFF7F (16383), 0x808001, 0x808001, 0x808001</li> </ul> </li> </ul> <h4 id="invalid-bytecodes">Invalid bytecodes</h4> <ul> <li>Empty jumpdest section</li> <li>Multiple jumpdest sections</li> <li>jumpdest section after the code section</li> <li>jumpdest section after the data section</li> <li>Final jumploc in the table is truncated (not a valid LEB128)</li> <li>LEB128 encoding with extra 0s (non-minimal encoding)</li> <li>Jumpdest location pointing to PUSH data</li> <li>Jumpdest location out of code section bounds <ul> <li>pointing into data section</li> <li>pointing into jumpdest section</li> <li>pointing outside container bounds</li> </ul> </li> <li>Duplicate jumpdest locations (0 deltas in table other than 1st offset)</li> <li>Code containing <code>JUMP</code> but no jumpdest table</li> <li>Code containing <code>JUMPI</code> but no jumpdest table</li> <li>Code containing jumpdest table but not <code>JUMP</code>/<code>JUMPI</code></li> <li>Code containing <code>JUMPDEST</code></li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The requirement of a JUMPDEST table does not cover legacy bytecode.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The authors are not aware of any security or DoS risks posed by this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-06-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dankrad Feisthttps://github.com/dankrad Dmitry Khovratovichhttps://github.com/khovratovich Marius van der Wijdenhttps://github.com/MariusVanDerWijden https://wg-eips.ritovision.com/3607/

Do not allow transactions for which `tx.sender` has any code deployed.

<h2 id="abstract">Abstract</h2> <p>Ethereum addresses are currently only 160 bits long. This means it is possible to create a collision between a contract account and an Externally Owned Account (EOA) using an estimated <code>2**80</code> computing operations, which is feasible now given a large budget (ca. 10 billion USD). The fix in this EIP prevents the worst possible attack, where a safe looking contract (e.g. a token wrapper or an AMM-type contract) is deployed to attract user funds, which can then be spent using the EOA key for the same address. The fix is to never allow to use an address that already has code deployed as an EOA address.</p> <h2 id="motivation">Motivation</h2> <h3 id="generating-address-collisions">Generating address collisions</h3> <p>By creating keys for <code>2**80</code> EOAs and simulating the deployment of <code>2**80</code> contracts from these EOAs (one each), one expects to find about one collision where an EOA has the same address as one contract.</p> <p>This very simple form of the attack requires the storage of <code>2**80</code> addresses, which is a practical barrier: It would require <code>2.4*10**25</code> bytes of memory (24 Yottabyte). However, there are cycle finding algorithms that can perform the collision search without requiring large amounts of storage. An estimate for the complexity has been made <a rel="external" href="https://hackmd.io/Vzhp5YJyTT-LhWm_s0JQpA">here</a>. We estimate that a collision between a contract and an EOA could be found in about one year with an investment of ca. US$10 billion in hardware and electricity.</p> <h3 id="background">Background</h3> <p>There is currently a discussion to move to 256-bit addresses on Ethereum, which would increase collision resistance to a complexity of <code>2**128</code> which is currently thought infeasible for the foreseeable future. However, with 160 bit addresses, the collision problem can be effectively solved now, as demonstrated above.</p> <p>Most attacks that can occur via address collisions are quite impractical: They involve users sending funds to an address before a contract is deployed. This is a very rare application in practice and users can easily circumvent the attack by never sending funds to a contract until it has been safely deployed with enough confirmations.</p> <p>However, the yellow paper does not explicitly specify how a client should handle the case where a transaction is sent from an account that already has contract code deployed; presumably because this was considered infeasible at the time. The assumption is that most client would allow this transaction in their current state.</p> <p>This EIP is to specify this behaviour to always forbid such transactions. This fixes most realistic or serious attacks due to address collisions.</p> <h2 id="specification">Specification</h2> <p>Any transaction where <code>tx.sender</code> has a <code>CODEHASH != EMPTYCODEHASH</code> MUST be rejected as invalid, where <code>EMPTYCODEHASH = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code>. The invalid transaction MUST be rejected by the client and not be included in a block. A block containing such a transaction MUST be considered invalid.</p> <h2 id="rationale">Rationale</h2> <p>We note that it was always expected that a contract account's behaviour is constrained by the code in that contract -- which means that the account's funds should not suddenly be spendable by some private key. It was just implicitly assumed in the past that a 160 bit address length is enough to provide collision resistance, and thus that this case could never occur. In that sense, this EIP should be seen as a clarification of protocol behaviour in a previously undefined case rather than an explicit upgrade of consensus rules.</p> <p>This does not exclude all possible attack vectors, only the most serious one. Further possible attack vectors via address collisions between contracts and EOAs are:</p> <ol> <li>An attacker can convince a user to send funds to an account before it is deployed. Some applications require this behaviour (e.g. state channels).</li> <li>A chain reorg can happen after a contract is deployed. If the reorg removes the contract deployment transaction the funds can still be accessed using the private key.</li> <li>A contract can self destruct, with the stated intention that ERC20s (or other tokens) in the contract would be burned. However, they can now be accessed by a key for that address.</li> </ol> <p>All these scenarios are much harder to exploit for an attacker, and likely have much lower yield making the attacks unlikely to be economically viable.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>It is unlikely that an attack like this has already occurred on the Ethereum mainnet, or we would very likely have heard of it. It is inconceivable that someone would use this as a "feature" to make a contract an EOA at the same time, when they could simply do this by adding some methods to the contract instead of spending billions on building hardware to find hash collisions.</p> <p>Private networks may have deployed contracts which also work as EOAs at genesis and should check that this upgrade does not impact their workflows.</p> <p>Clients might choose to disable this rule for RPC calls like <code>eth_call</code> and <code>eth_estimateGas</code> as some Multi-Sig contracts use these calls to create transactions as if they originated from the multisig contract itself.</p> <h2 id="test-cases">Test Cases</h2> <p>Given a genesis allocation of</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Address: 0x71562b71999873DB5b286dF957af199Ec94617F7</span></span> <span class="giallo-l"><span>Balance: 1000000000000000000 // 1 ether</span></span> <span class="giallo-l"><span>Nonce: 0,</span></span> <span class="giallo-l"><span>Code: 0xB0B0FACE&quot;,</span></span></code></pre> <p>Every transaction sent by the private key corresponding to <code>0x715656...</code> ( <code>b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291</code>) should be rejected. These transaction must be rejected and not included in a block.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>The following check must be added to the state transition checks after checking that the nonce of the sender is correct. The sender is the address recovered from the signature of the transaction.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>// Make sure the sender is an EOA</span></span> <span class="giallo-l"><span>Set ch to the CodeHash of the sender account</span></span> <span class="giallo-l"><span>if ch is not equal to EmptyCodeHash then</span></span> <span class="giallo-l"><span> return ErrSenderNoEOA</span></span> <span class="giallo-l"><span>end if</span></span></code></pre> <p>A diff to implement EIP-3607 in go-ethereum can be found <a href="https://wg-eips.ritovision.com/3607/./assets/geth.diff">here</a></p> <h2 id="security-considerations">Security Considerations</h2> <p>This EIP is a strict security upgrade: It simply makes some transactions that were formerly valid now invalid. There is no legitimate use for such transactions, so there should be no security downsides.</p> <p>This EIP can be implemented as a soft fork because the new validity rules are a strict superset of the previous validity rules.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-05-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gajinder Singhhttps://github.com/g11in Piper Merriamhttps://github.com/pipermerriam https://wg-eips.ritovision.com/3584/ <h2 id="simple-summary">Simple Summary</h2> <p>A proposal to build a block's <code>access_list</code> and include its fingerprint <code>AccessListRoot</code> in the block header.</p> <h2 id="abstract">Abstract</h2> <p><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>/<a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> centers around normalizing the (low) gas costs of data/storage accesses made by a transaction as well as providing for (and encouraging) a new transaction type format:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])</span></span></code></pre> <p>that makes upfront <code>access_list</code> declarations, where <code>access_list</code> is some <code>[[{20 bytes}, [{32 bytes}...]]...]</code> map of <code>AccessedAddress=&gt; AccessedStorageKeys</code>.</p> <p>The first <em>accesses</em> of these upfront <em>declarations</em> are charged at discounted price (roughly ~<code>10%</code>) and first accesses outside this list are charged higher price. Reason is upfront access declaration provides for a way to <em>preload/optimize/batch</em> loading these locations while executing the transaction. This inadvertently leads to generation of transaction <code>access_list</code> that has all (first) accesses (declared or not) made by a transaction. This proposal is to collate these <em>transaction</em> <code>access_list</code>s for all the transactions in a <strong>block</strong> <code>access_list</code> document and include its <em>fingerprint</em> in the block header.</p> <h2 id="motivation">Motivation</h2> <p>Motivation for collating the <em>transaction</em> <code>access_list</code>s for all the transactions in a <strong>block</strong>’s <code>access_list</code> is to have an <em>access index</em> of the block with following benefits:</p> <ol> <li>Block execution/validation optimizations/parallelization/cache warm-up by enabling construction of <em>a partial order</em> for access and hence execution (hint: <em>chains</em> in this <em>poset</em> can be parallelized).</li> <li>Enabling partial inspection and fetching/serving of a block data/state by <em>light sync</em> or <em>fast sync</em> protocols concerned with a subset of addresses.</li> <li>Possible future extension of this list to serve as index for bundling, serving and fetching witness data for <em>stateless</em> protocols.</li> </ol> <h2 id="specification">Specification</h2> <p>A block <code>access_list</code> represents:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Set [ </span></span> <span class="giallo-l"><span> AccessedAddress, </span></span> <span class="giallo-l"><span> List [AccessedStorageKeys] , </span></span> <span class="giallo-l"><span> Set [ AccessedInBlockTransactionNumber, List [ AccessedStorageKeys ]] </span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>A <strong>canonical</strong> construction of such an <code>access_list</code> is specified as below.</p> <h3 id="canonical-block-access-list">Canonical Block Access List</h3> <p>An <code>access_list</code> is defined to be comprised of many <code>access_list_entry</code> elements:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>access_list := [access_list_entry, ...]</span></span></code></pre> <p>An <code>access_list_entry</code> is a 3-tuple of:</p> <ul> <li>address</li> <li>sorted list of storage keys of the address accessed across the entire block</li> <li>sorted list of 2-tuples of: <ul> <li>transaction index in which the address or any of its storage keys were accessed</li> <li>sorted list of storage keys which were accessed</li> </ul> </li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>access_list := [access_list_entry, ...]</span></span> <span class="giallo-l"><span>access_list_entry := [address, storage_keys, accesses_by_txn_index]</span></span> <span class="giallo-l"><span>address := bytes20</span></span> <span class="giallo-l"><span>accesses_by_txn_index := [txn_index_and_keys, ...]</span></span> <span class="giallo-l"><span>txn_index_and_keys := [txn_index, storage_keys]</span></span> <span class="giallo-l"><span>txn_index := uint64 # or uint256 or whatever</span></span> <span class="giallo-l"><span>storage_keys := [storage_key, ...]</span></span> <span class="giallo-l"><span>storage_key := bytes32</span></span></code></pre> <p>Additional sorting rules for the above are that:</p> <ul> <li><code>access_list</code> is sorted by the <code>address</code></li> <li><code>storage_keys</code> is sorted</li> <li><code>accesses_by_txn_index</code> is sorted by <code>txn_index</code></li> </ul> <p>Additional validation rules for the above are that:</p> <ul> <li>Each unique <code>address</code> may only appear at most once in <code>access_list</code></li> <li>Each <code>storage_key</code> may only appear at most once in <code>storage_keys</code></li> <li>Each <code>txn_index</code> may only appear at most once in <code>txn_index_and_keys</code></li> </ul> <p>All sorting is in increasing order.</p> <h3 id="accesslistroot">AccessListRoot</h3> <p>An <code>AccessListRoot</code> is a URN <em>like</em> encoding <code>Hash/Commitment</code> of the canonical <code>access_list</code> as well as the construction type ( <code>sha256</code> ) and serialization type ( <code>json</code> ), i.e.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>AccessListRoot := &quot;urn:sha256:json:0x${ SHA256( access_list.toJSONString(&#39;utf8&#39;) ).toHexString() }&quot;</span></span></code></pre> <p>where <code>0x${ SHA256 (...)...}</code> is the <code>SHA256</code> hashed <code>32</code> bytes hex string as indicated by leading <code>0x</code>.</p> <h3 id="additional-block-validation">Additional Block Validation</h3> <p>Validating a new block requires an additional validation check that the block’s <code>AccessListRoot</code> matches the one generated by executing the block using the construction as defined by the <code>AccessListRoot</code> URN.</p> <h2 id="rationale">Rationale</h2> <h3 id="sorting-of-canonical-access-list">Sorting of canonical <code>access_list</code></h3> <p>It is specified to be sorted in lexicographic ordering or integer sorting wherever applicable and specified. Sorting with respect to access time was considered but didn't seem to provide any additional benefit at the cost of adding implementation complexity and bookkeeping.</p> <h3 id="accesslistroot-1"><code>AccessListRoot</code></h3> <p><code>AccessListRoot</code> is generated to prevent any <em>griefing</em> attacks and hence will need to be included (and validated) in the <em>block header</em>. Even though <code>AccessListRoot</code> is currently specified to be a simple <code>sha256</code> hash of the canonical <code>access_list</code>, it would be beneficial to consider other constructions</p> <ul> <li>a tree structure (<code>merkle</code>/<code>verkle</code>). It will be a bit more expensive but will enable partial downloading, inspection and validation of the <code>access_list</code>.</li> <li>a normal <code>kate</code> commitment can also be generated to enable this partial capability and is recommended as validating partial fetch of access list chunks would be very simple.</li> </ul> <p>Also serialization of the <code>access_list</code> is currently specified as a normal <code>JSON String</code> dump and these parameters could vary from construction to construction, but for the sake of simplicity, it can always be <code>sha256</code> hashed to get a consistent <code>32</code> bytes hex string root.</p> <p>So this AccessListRoot could evolve to <code>urn:merkle:ssz:...</code> or to <code>urn:kate:...</code> or to any other scheme as per requirement. And the idea of having the <code>AccessListRoot</code> as URN <em>like</em> structure is to enable upgradation to these paths without affecting block structure.</p> <h3 id="future-extensions-of-access-list">Future extensions of <code>access_list</code></h3> <p>We can extend the notion of a block’s <code>access_list</code> to include witnesses:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>access_list := Set[ </span></span> <span class="giallo-l"><span> Address,</span></span> <span class="giallo-l"><span> List [ AddressWitnesses ],</span></span> <span class="giallo-l"><span> Set [ AccessedStorageKey, List [ StorageKeyWitnesses] ], </span></span> <span class="giallo-l"><span> Set [ AccessedInBlockTransactionNumber, List [ AccessedStorageKeys ] ]</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>and then get to define the a canonical specification for building the fingerprint. This will allow an incremental path to partial or full statelessness, where it would be easy to bundle/request <strong>witnesses</strong> using this <code>access_list</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The extra block validation will only be mandatory post the block number this EIP comes into effect, but the clients can still provide a way to generate (and possibly store) this access list on request (via the <code>JSON/RPC</code> api). However this is optional and client dependent.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues as a result of this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-05-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Hancockhttps://github.com/madeoftin https://wg-eips.ritovision.com/3554/ <h2 id="simple-summary">Simple Summary</h2> <p>Delays the difficulty bomb to show effect the first week of December 2021.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLOCK_NUMBER</code> the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 9,700,000 blocks later than the actual block number.</p> <h2 id="motivation">Motivation</h2> <p>Targeting for the Shanghai upgrade and/or the Merge to occur before December 2021. Either the bomb can be readjusted at that time, or removed all together.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span> fake_block_number</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">0</span><span>,</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> 9_700_000</span><span>)</span><span class="z-keyword"> if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_BLOCK_NUMBER</span><span class="z-keyword"> else</span><span> block</span><span>.</span><span>number</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The following script predicts a .1 second delay to blocktime the first week of december and a 1 second delay by the end of the month. This gives reason to address because the effect will be seen, but not so much urgency we don't have space to work around if needed.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> predict_diff_bomb_effect</span><span>(</span><span class="z-variable z-parameter z-function">current_blknum</span><span>,</span><span class="z-variable z-parameter z-function"> current_difficulty</span><span>,</span><span class="z-variable z-parameter z-function"> block_adjustment</span><span>,</span><span class="z-variable z-parameter z-function"> months</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span class="z-string"> Predicts the effect on block time (as a ratio) in a specified amount of months in the future.</span></span> <span class="giallo-l"><span class="z-string"> Vars used in last prediction:</span></span> <span class="giallo-l"><span class="z-string"> current_blknum = 12382958</span></span> <span class="giallo-l"><span class="z-string"> current_difficulty = 7393633000000000</span></span> <span class="giallo-l"><span class="z-string"> block adjustment = 9700000</span></span> <span class="giallo-l"><span class="z-string"> months = 6</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string"> &#39;&#39;&#39;</span></span> <span class="giallo-l"><span> blocks_per_month</span><span class="z-keyword"> =</span><span> (</span><span class="z-constant">86400</span><span class="z-keyword"> *</span><span class="z-constant"> 30</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 13.3</span></span> <span class="giallo-l"><span> future_blknum</span><span class="z-keyword"> =</span><span> current_blknum</span><span class="z-keyword"> +</span><span> blocks_per_month</span><span class="z-keyword"> *</span><span> months</span></span> <span class="giallo-l"><span> diff_adjustment</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span><span class="z-keyword"> **</span><span> (</span><span>(</span><span>future_blknum</span><span class="z-keyword"> -</span><span> block_adjustment</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 100000</span><span class="z-keyword"> -</span><span class="z-constant"> 2</span><span>)</span></span> <span class="giallo-l"><span> diff_adjust_coeff</span><span class="z-keyword"> =</span><span> diff_adjustment</span><span class="z-keyword"> /</span><span> current_difficulty</span><span class="z-keyword"> *</span><span class="z-constant"> 2048</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> diff_adjust_coeff</span><span> </span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span>diff_adjust_coeff</span><span class="z-keyword"> =</span><span> predict_diff_bomb_effect</span><span>(</span><span class="z-constant">12382958</span><span>,</span><span class="z-constant">7393633000000000</span><span>,</span><span class="z-constant">9700000</span><span>,</span><span class="z-constant">6</span><span>)</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known backward compatibility issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Misjudging the effects of the difficulty can mean longer blocktimes than anticipated until a hardfork is released. Wild shifts in difficulty can affect this number severely. Also, gradual changes in blocktimes due to longer-term adjustments in difficulty can affect the timing of difficulty bomb epochs. This affects the usability of the network but unlikely to have security ramifications.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/3529/ <h2 id="simple-summary">Simple Summary</h2> <p>Remove gas refunds for <code>SELFDESTRUCT</code>, and reduce gas refunds for <code>SSTORE</code> to a lower level where the refunds are still substantial, but they are no longer high enough for current "exploits" of the refund mechanism to be viable.</p> <h2 id="motivation">Motivation</h2> <p>Gas refunds for <code>SSTORE</code> and <code>SELFDESTRUCT</code> were originally introduced to motivate application developers to write applications that practice "good state hygiene", clearing storage slots and contracts that are no longer needed. However, the benefits of this technique have proven to be far lower than anticipated, and gas refunds have had multiple unexpected harmful consequences:</p> <ul> <li>Refunds give rise to GasToken. GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a "battery" to save up gas) and inefficiently clogging blockchain gas usage</li> <li>Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction's gas used). This is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP-1559 can.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> <tr><td><code>MAX_REFUND_QUOTIENT</code></td><td>5</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <ol> <li>Remove the <code>SELFDESTRUCT</code> refund.</li> <li>Replace <code>SSTORE_CLEARS_SCHEDULE</code> (as defined in <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a>) with <code>SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST</code> (4,800 gas as of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> + <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>)</li> <li>Reduce the max gas refunded after a transaction to <code>gas_used // MAX_REFUND_QUOTIENT</code></li> </ol> <p>Remark: Previously <em>max gas refunded</em> was defined as <code>gas_used // 2</code>. Here we name the constant <code>2</code> as <code>MAX_REFUND_QUOTIENT</code> and change its value to <code>5</code>.</p> <h2 id="rationale">Rationale</h2> <p>In <a href="https://wg-eips.ritovision.com/2200/#specification">EIP-2200</a>, three cases for refunds were introduced:</p> <ol> <li>If the original value is nonzero, and the new value is zero, add <code>SSTORE_CLEARS_SCHEDULE</code> (currently 15,000) gas to the refund counter</li> <li>If the original value is zero, the current value is nonzero, and the new value is zero, add <code>SSTORE_SET_GAS - SLOAD_GAS</code> (currently 19,900) gas to the refund counter</li> <li>If the original value is nonzero, the current value is a different nonzero value, and the new value equals the original value, add <code>SSTORE_RESET_GAS - SLOAD_GAS</code> (currently 4,900) gas to the refund counter</li> </ol> <p>Of these three, only (1) enables gastokens and allows a block to expend more gas on execution than the block gas limit. (2) does not have this property, because for the 19,900 refund to be obtained, <em>the same storage slot</em> must have been changed from zero to nonzero previously, costing 20,000 gas. The inability to obtain gas from clearing one storage slot and use it to edit another storage slot means that it cannot be used for gas tokens. Additionally, obtaining the refund requires <em>reverting</em> the effect of the storage write and expansion, so the refunded gas does not contribute to a client's load in processing a block. (3) behaves similarly: the 4,900 refund can only be obtained when 5,000 gas had previously been spent on the same storage slot.</p> <p>This EIP deals with case (1). We can establish under what conditions a gastoken is nonviable (ie. you cannot get more gas out of a storage slot than you put in) by using a similar "pairing" argument, mapping each refund to a previous expenditure in the same transaction on the same storage slot. lf a storage slot is changed to zero when its original value is nonzero, there are two possibilities:</p> <ol> <li>This could be the first time that the storage slot is set to zero. In this case, we can pair this event with the <code>SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST</code> minimum cost of reading and editing the storage slot for the first time.</li> <li>This could be the second or later time that the storage slot is set to zero. In this case, we can pair this event with the most recent previous time that the value was set <em>away</em> from zero, in which <code>SSTORE_CLEARS_SCHEDULE</code> gas is <em>removed</em> from the refund.</li> </ol> <p>For the second and later event, it does not matter what value <code>SSTORE_CLEARS_SCHEDULE</code> has, because every refund of that size is paired with a refund <em>removal</em> of the same size. This leaves the first event. For the total gas expended on the slot to be guaranteed to be positive, we need <code>SSTORE_CLEARS_SCHEDULE &lt;= SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST</code>. And so this EIP simply decreases <code>SSTORE_CLEARS_SCHEDULE</code> to the sum of those two costs.</p> <p>One alternative intuition for this EIP is that there will not be a net refund for clearing data that has not yet been read (which is often "useless" data), but there will continue to be a net refund for clearing data that has been read (which is likely to be "useful" data).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Refunds are currently only applied <em>after</em> transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.</p> <p>Gas tokens will become valueless. DeFi arbitrage bots, which today frequently use either established gas token schemes or a custom alternative to reduce on-chain costs, would benefit from rewriting their code to remove calls to these no-longer-functional gas storage mechanisms.</p> <p>However, fully preserving refunds in the <code>new = original = 0 != current</code> case, and keeping <em>some</em> refund in the other <code>nonzero -&gt; zero</code> cases, ensures that a few key use cases that receive (and deserve) favorable gas cost treatment continue to do so. For example, <code>zero -&gt; nonzero -&gt; zero</code> storage set patterns continue to cost only ~100 gas. Two important examples of such patterns include:</p> <ul> <li>Anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends)</li> <li>ERC20 approve-and-send (the "approved value" goes from zero to nonzero when the token transfer is approved, and then back to zero when the token transfer processes)</li> </ul> <h3 id="effect-on-storage-clearing-incentives">Effect on storage clearing incentives</h3> <p>A criticism of earlier refund removal EIPs (<a href="https://wg-eips.ritovision.com/3298/">EIP-3298</a> and <a href="https://wg-eips.ritovision.com/3403/">EIP-3403</a>) is that these EIPs fully remove the incentive to set a value to zero, encouraging users to not fully clear a storage slot if they expect even the smallest probability that they will want to use that storage slot again.</p> <p>For example, if you have 1 unit of an ERC20 token and you are giving away or selling your entire balance, you could instead only give away 0.999999 units and leave the remainder behind. If you ever decide to re-acquire more of that token with the same account in the future, you would only have to pay 5000 gas (2100 for the read + 2900 for nonzero-to-nonzero set) for the <code>SSTORE</code> instead of 22100 (20000 for the zero-to-nonzero set). Today, this is counterbalanced by the 15000 refund for clearing, so you only have an incentive to do this if you are more than <code>15000 / 17100 = 87.7%</code> sure that you will use the slot again; with EIP-3298 or EIP-3403 the counterbalancing incentive would not exist, so setting to nonzero is better if your chance of using the slot again is <em>any</em> value greater than 0%.</p> <p>A refund of 4800 gas remains, so there is only be an incentive to keep a storage slot nonzero if you expect a probability of more than <code>4800 / 17100 = 28.1%</code> that you will use that slot again. This is not perfect, but it is likely higher than the average person's expectations of later re-acquiring a token with the same address if they clear their entire balance of it.</p> <p>The capping of refunds to 1/5 of gas expended means that this refund can only be used to increase the amount of storage write operations needed to process a block by at most 25%, limiting the ability to use this mechanic for storage-write-focused denial-of-service attacks.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="eip-2929-gas-costs">EIP-2929 Gas Costs</h3> <p>Note, there is a difference between 'hot' and 'cold' slots. This table shows the values as of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> assuming that all touched storage slots were already 'hot' (the difference being a one-time cost of <code>2100</code> gas).</p> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th><th>Effective gas (after refund)</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>212</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20112</td><td>19900</td><td>0</td><td>1</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60006000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>0</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>0</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>2</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60026000556003600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>2</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60026000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>1</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>212</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40118</td><td>19900</td><td>0</td><td>1</td><td>0</td><td>1</td><td>20218</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>5918</td><td>17800</td><td>1</td><td>0</td><td>1</td><td>0</td><td>-11882</td></tr> </tbody></table> <h3 id="with-reduced-refunds">With reduced refunds</h3> <p>If refunds were to be partially removed, by changing <code>SSTORE_CLEARS_SCHEDULE</code> from 15000 to 4800 (and removing selfdestruct refund) this would be the comparative table.</p> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th><th>Effective gas (after refund)</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>212</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20112</td><td>19900</td><td>0</td><td>1</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60006000556000600055</code></td><td>3012</td><td>4800</td><td>1</td><td>0</td><td>0</td><td></td><td>-1788</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>0</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556000600055</code></td><td>3012</td><td>4800</td><td>1</td><td>2</td><td>0</td><td></td><td>-1788</td></tr> <tr><td><code>0x60026000556003600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>2</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60026000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>3012</td><td>4800</td><td>1</td><td>1</td><td>0</td><td></td><td>-1788</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>212</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40118</td><td>19900</td><td>0</td><td>1</td><td>0</td><td>1</td><td>20218</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>5918</td><td>7600</td><td>1</td><td>0</td><td>1</td><td>0</td><td>-1682</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>Refunds are not visible to transaction execution, so this should not have any impact on transaction execution logic.</p> <p>The maximum amount of gas that can be spent on execution in a block is limited to the gas limit, if we do not count zero-to-nonzero <code>SSTORE</code>s that were later reset back to zero. It is okay to not count those, because if such an <code>SSTORE</code> is reset, storage is not expanded and the client does not need to actually adjust the Merke tree; the gas consumption is refunded, but the effort normally required by the client to process those opcodes is also cancelled. <strong>Clients should make sure to not do a storage write if <code>new_value = original_value</code>; this was a prudent optimization since the beginning of Ethereum but it becomes more important now.</strong></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-20T00:00:00+00:00 2026-02-11T14:49:28+00:00 Isaac Ardishttps://github.com/whilei https://wg-eips.ritovision.com/3534/ <h2 id="simple-summary">Simple Summary</h2> <p>Defines a new transaction type with constraints on ancestor block hash, block author, and/or block timestamp.</p> <h2 id="abstract">Abstract</h2> <p>We introduce a new EIP-2718 transaction type with the format <code>0x4 || rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])</code>.</p> <p>This proposed <code>chainContext</code> element adds a constraint on the validity of a transaction to a chain segment meeting the referenced value(s). Four contexts are defined as subclasses of this type:</p> <ul> <li><code>segmentId</code></li> <li><code>eligibleMinerList</code></li> <li><code>ineligibleMinerList</code></li> <li><code>expiry</code></li> </ul> <p>These contexts can be used in arbitrary combinations. Annotated context value combinations are referenced by a composite integer prefix on the annotation.</p> <h2 id="motivation">Motivation</h2> <p>Establish a protocol-based mechanism with which transactions are able to articulate constraints on eligible chain contexts. Generally, these constraints give the consumer (the transactor) an ability to express requirements about the transaction's relationship to blockchain data and its provenance.</p> <ul> <li>Restrict transaction applicability to a chain context that is currently available and reasoned about under some subjective view. <ul> <li>Introduces a way for transactions to describe a dependency on their current view of a chain.</li> </ul> </li> <li>Restrict transaction applicability to a chain context following some foregoing block (and its transactions). <ul> <li>Introduces a way for transactions to describe ancestral dependencies at a "macro" (block) level. Indirectly, this offers a way for a transaction to depend on the presence of another, so long as the dependent transaction is in a different block.</li> </ul> </li> <li>Restrict transaction applicability to blocks benefitting, or <em>not</em> benefitting, a preferred/spurned miner address or addresses. <ul> <li>Introduces an opportunity/market for miners to compete for consumers' transactions; under the status quo, the current miner-transaction processing service is almost perfectly homogeneous from the consumer perspective.</li> </ul> </li> <li>Restrict transaction applicability time span. <ul> <li>Introduces an alternative (to the status quo) way for consumers/transactors to have transactions invalidated/ejected from the transaction pool.</li> </ul> </li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLOCK_NUMBER</code> <code>TBD</code></li> <li><code>TRANSACTION_TYPE_NUMBER</code> <code>0x4</code>. See EIP-2718.</li> </ul> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new EIP-2718 transaction is introduced with <code>TransactionType</code> <code>TRANSACTION_TYPE_NUMBER</code>.</p> <p>The EIP-2718 <code>TransactionPayload</code> for this transaction is <code>rlp([chainId, chainContext, nonce, gasPrice, gasLimit, to, value, data, access_list, yParity, senderR, senderS])</code>.</p> <p>The EIP-2718 <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulativeGasUsed, logsBloom, logs])</code>.</p> <h3 id="definitions">Definitions</h3> <ul> <li><code>chainContext</code>. The transaction is only valid for blockchain data satisfying ALL OF the annotations.</li> <li><code>ANNOTATION_COMPOSITE_PREFIX</code>. A positive integer between <code>1</code> and <code>0xff</code> that represents the set of subclass annotations in the <code>chainContext</code> (<em>ie.</em> <em>which</em> chain context subclasses should the provided values be applied to). This value should be the sum of the subclass' <code>ANNOTATION_PREFIX</code>s.</li> <li><code>ANNOTATION_PREFIX</code>s are defined for Subclasses as octal-derived positive integers, limited to the set <code>2^0,2^1,2^2,2^3,2^4,2^5,2^6,2^7</code>.</li> </ul> <p>The <code>chainContext</code> value should be of the form <code>ANNOTATION_COMPOSITE_PREFIX || [{subclass value}...]</code>, where</p> <ul> <li><code>...</code> means "zero or more of the things to the left," and</li> <li><code>||</code> denotes the byte/byte-array concatenation operator.</li> </ul> <p>The <code>chainContext</code> value should be encoded as <code>ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]</code>.</p> <h3 id="validation">Validation</h3> <p>The values defined as subclasses below acts as constraints on transaction validity for specific chain contexts. Transactions defining constraints which are not satisfied by their chain context should be rejected as invalid. Blocks containing invalid transactions should be rejected as invalid themselves, per the <em>status quo</em>.</p> <h3 id="subclass-combination">Subclass Combination</h3> <p><code>chainContext</code> values annotating more than one subclass reference should provide those values in the following sequential order:</p> <ol> <li><code>ANCESTOR_ID</code></li> <li><code>ELIGIBLE_MINER_LIST</code></li> <li><code>INELIGIBLE_MINER_LIST</code></li> <li><code>EXPIRY</code></li> </ol> <p>As above, the <code>ANNOTATION_COMPOSITE_PREFIX</code> should be the sum of the designated subclass' <code>ANNOTATION_PREFIX</code>s.</p> <h3 id="subclasses">Subclasses</h3> <ul> <li>An <code>ANNOTATION_PREFIX</code> value is used to represent each of the available context subclasses.</li> </ul> <h4 id="ancestorid"><code>ancestorId</code></h4> <ul> <li><code>ANNOTATION_PREFIX</code> <code>1</code>.</li> <li><code>ANCESTOR_ID</code> <code>bytes</code>. A byte array between 4 and 12 bytes in length.</li> </ul> <p>The <code>ANCESTOR_ID</code> is a reference to a specific block by concatenating the byte representation of a block number and the first 4 bytes of its hash. The block number's should be encoded as a big endian value and should have left-padding 0's removed. The block number value may be omitted in case of reference to the genesis block.</p> <p>The <code>ANCESTOR_ID</code> value should be RLP encoded as a byte array for hashing and transmission.</p> <h4 id="eligibleminerlist"><code>eligibleMinerList</code></h4> <ul> <li><code>ANNOTATION_PREFIX</code> <code>2</code>.</li> <li><code>ELIGIBLE_MINER_LIST</code> <code>[address...]</code>. A list of addresses.</li> <li><code>MAX_ELEMENTS</code> <code>3</code>. The maximum number of addresses that can be provided.</li> </ul> <p>The <code>ELIGIBLE_MINER_LIST</code> value is an array of unique, valid addresses. Any block containing a transaction using this value must have a block beneficiary included in this set.</p> <p>The <code>ELIGIBLE_MINER_LIST</code> value should be of the type <code>[{20 bytes}+]</code>, where <code>+</code> means "one or more of the thing to the left." Non-unique values are not permitted.</p> <p>The <code>ELIGIBLE_MINER_LIST</code> value should be RLP encoded for hashing and transmission.</p> <p>An <code>ELIGIBLE_MINER_LIST</code> value may NOT be provided adjacent to an <code>INELIGIBLE_MINER_LIST</code> value.</p> <h4 id="ineligibleminerlist"><code>ineligibleMinerList</code></h4> <ul> <li><code>ANNOTATION_PREFIX</code> <code>4</code>.</li> <li><code>INELIGIBLE_MINER_LIST</code> <code>[address...]</code>. A list of addresses.</li> <li><code>MAX_ELEMENTS</code> <code>3</code>. The maximum number of addresses that can be provided.</li> </ul> <p>The <code>INELIGIBLE_MINER_LIST</code> value is an array of unique, valid addresses. Any block containing a transaction using this value must not have a block beneficiary included in this set.</p> <p>The <code>INELIGIBLE_MINER_LIST</code> value should be of the type <code>[{20 bytes}+]</code>, where <code>+</code> means "one or more of the thing to the left." Non-unique values are not permitted.</p> <p>The <code>INELIGIBLE_MINER_LIST</code> value should be RLP encoded for hashing and transmission.</p> <p>An <code>INELIGIBLE_MINER_LIST</code> value may NOT be provided adjacent to an <code>ELIGIBLE_MINER_LIST</code> value.</p> <h4 id="expiry"><code>expiry</code></h4> <ul> <li><code>ANNOTATION_PREFIX</code> <code>8</code>.</li> <li><code>EXPIRY</code> <code>integer</code>. A positive, unsigned scalar.</li> </ul> <p>The <code>EXPIRY</code> value is a scalar equal to the maximum valid block <code>timestamp</code> for a block including this transaction.</p> <p>The <code>EXPIRY</code> value should be RLP encoded as an integer for hashing and transmission.</p> <h2 id="rationale">Rationale</h2> <h3 id="subclasses-1">Subclasses</h3> <p>Subclasses are defined with a high level of conceptual independence, and can be modified and/or extended independently from this EIP. Their specification definitions allow arbitrary mutual (<code>AND</code>) combinations.</p> <p>This design is intended to form a proposal which offers a concrete set of specifics while doing so with enough flexibility for extension or modification later.</p> <h4 id="annotation-prefix"><code>ANNOTATION_PREFIX</code></h4> <p><code>ANNOTATION_PREFIX</code> values' use of octal-derived values, ie. <code>1, 2, 4, 8, 16, 32, 64, 128</code>, follows a conventional pattern of representing combinations from a limited set uniquely and succinctly, eg. Unix-style file permissions. This EIP defines four of the eight possible context subclasses; this seems to leave plenty of room for future growth in this direction if required. If this limit is met or exceeded, doing so will require a hard fork <em>de facto</em> (by virtue of making consensus protocol facing changes to transaction validation schemes), so revising this scheme as needed should be only incidental and trivial.</p> <h4 id="ancestorid-1"><code>ancestorId</code></h4> <p>Constrains the validity of a transaction by referencing a prior canonical block by number and hash. The transaction is only valid when included in a block which has the annotated block as an ancestor.</p> <p>Practically, the "designated allowable chain segment" can be understood as the segment of blocks from <code>0..ancestorId</code> inclusive.</p> <h5 id="redundancy-to-chainid">Redundancy to <code>chainId</code></h5> <p>This pattern can be understood as a correlate of <a href="https://wg-eips.ritovision.com/155/">EIP-155</a>'s <code>chainId</code> specification. EIP155 defines the restriction of transactions between chains; limiting the applicability of any EIP-155 transaction to a chain with the annotated ChainID. <code>ancestorId</code> further restricts transaction application to one subsection ("segment") of one chain.</p> <p>From this constraint hierarchy, we note that an implementation of <code>ancestorId</code> can make <code>chainId</code> conceptually redundant.</p> <h5 id="so-why-keep-chainid">So why keep <code>chainId</code>?</h5> <p><code>chainId</code> is maintained as an invariant because:</p> <ul> <li>The use of the transaction type proposed by this EIP is optional, implying the continued necessity of <code>chainId</code> in the protocol infrastructure and tooling for legacy and other transaction types.</li> <li>The presence of <code>ancestorId</code> in the transaction type proposed by this EIP is optional. If the value is not filled by an RCC transaction, the demand for <code>chainId</code> remains.</li> <li>A <code>chainId</code> value is not necessarily redundant to <code>ancestorId</code>, namely in cases where forks result in living chains. For example, an <code>ancestorId</code> reference to block <code>1_919_999</code> would be ambiguous between Ethereum and Ethereum Classic.</li> <li>It would be possible to specify the omission of <code>chainId</code> in case of <code>ancestorId</code>'s use. This would add infrastructural complexity for the sake of removing the few bytes <code>chainId</code> typically requires; we do not consider this trade-off worth making. <ul> <li><code>chainId</code> is used as the <code>v</code> value (of <code>v,r,s</code>) in the transaction signing scheme; removing or modifying this incurs complexity at a level below encoded transaction fields, demanding additional infrastructural complexity for implementation.</li> </ul> </li> <li>The proposed design for <code>ancestorId</code> does not provide perfect precision (at the benefit of byte-size savings). In the small chance that the value is ambiguous, the <code>chainId</code> maintains an infallible guarantee for a transaction's chain specificity.</li> </ul> <h4 id="eligibleminerlist-1"><code>eligibleMinerList</code></h4> <p>The transaction is only valid when included in a block having an <code>etherbase</code> contained in the annotated list of addresses. The use of "whitelist" (<code>eligibleMinerList</code>) in conjunction with a "blacklist" (<code>ineligibleMinerList</code>) is logically inconsistent; their conjunction is not allowed.</p> <p>A <code>MAX_ELEMENTS</code> limit of <code>3</code> is chosen to balance the interests of limiting the potential size of transactions, and to provide a sufficient level of articulation for the user. At the time of writing, the top 3 miners of Ethereum (by block, measured by known public addresses) account for 52% of all blocks produced.</p> <h4 id="ineligibleminerlist-1"><code>ineligibleMinerList</code></h4> <p>The transaction is only valid when included in a block having an <code>etherbase</code> <em>not</em> contained in the annotated list of addresses. The use of "blacklist" (<code>ineligibleMinerList</code>) in conjunction with a "whitelist" (<code>eligibleMinerList</code>) is logically inconsistent; their conjunction is not allowed.</p> <p>A <code>MAX_ELEMENTS</code> limit of <code>3</code> is chosen to balance the interests of limiting the potential size of transactions, and to provide a sufficient level of articulation for the user. At the time of writing, the top 3 miners of Ethereum (by block, measured by known public addresses) account for 52% of all blocks produced.</p> <h4 id="expiry-1"><code>expiry</code></h4> <p>The transaction is only valid when included in a block having a <code>timestamp</code> less than the value annotated. A positive integer is used because that corresponds to the specified type of block <code>timestamp</code> header values.</p> <h3 id="subclass-combination-1">Subclass Combination</h3> <p>Since subclasses use octal-based values for <code>ANNOTATION_PREFIX</code>, they can be distinguishably combined as sums, provided as we assume annotation cardinality (ie ordering). For example:</p> <ul> <li><code>ANNOTATION_PREFIX</code> <code>1</code> signals <code>ancestorId</code> exclusively.</li> <li><code>ANNOTATION_PREFIX</code> <code>2</code> signals <code>eligibleMinerList</code> exclusively.</li> <li><code>ANNOTATION_PREFIX</code> <code>4</code> signals <code>ineligibleMinerList</code> exclusively.</li> <li><code>ANNOTATION_PREFIX</code> <code>8</code> signals <code>expiry</code> exclusively.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+2=3</code> combines <code>ancestorId</code> and <code>eligibleMinerList</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+4=5</code> combines <code>ancestorId</code> and <code>ineligibleMinerList</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+8=9</code> combines <code>ancestorId</code> and <code>expiry</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+2+8=11</code> combines <code>ancestorId</code> and <code>eligibleMinerList</code> and <code>expiry</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+4+8=13</code> combines <code>ancestorId</code> and <code>ineligibleMinerList</code> and <code>expiry</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>2+4=6</code> is NOT PERMITTED. It would combine <code>eligibleMinerList</code> and <code>ineligibleMinerList</code>.</li> <li><code>ANNOTATION_PREFIX</code> <code>1+2+4+8=15</code> is NOT PERMITTED. It would combine <code>eligibleMinerList</code> and <code>ineligibleMinerList</code> (and <code>ancestorId</code> and <code>expiry</code>).</li> </ul> <p>Since ordering is defined and demanded for multiple values, annotated references remain distinguishable. For example:</p> <ul> <li><code>chainContext</code> <code>3[e4e1c0e78b1ec3,[Df7D7e053933b5cC24372f878c90E62dADAD5d42]]</code> - Transaction can only be included in a block having a canonical ancestor block numbered <code>15_000_000</code> and with a hash prefixed with the bytes <code>e78b1ec3</code>, and if the containing block uses <code>Df7D7e053933b5cC24372f878c90E62dADAD5d42</code> as the beneficiary.</li> <li><code>chainContext</code> <code>10[[Df7D7e053933b5cC24372f878c90E62dADAD5d42],1619008030]</code> - Transaction can only be included in a block naming <code>Df7D7e053933b5cC24372f878c90E62dADAD5d42</code> as the <code>etherbase</code> beneficiary, and which has a timestamp greater than <code>1619008030</code> (Wed Apr 21 07:27:10 CDT 2021).</li> </ul> <h3 id="eip-2930-inheritance">EIP-2930 Inheritance</h3> <p>The <a rel="external" href="https://eips.ethereum.org/EIPS/eip-2930">EIP-2930 Optional Access List Type Transaction</a> is used as an assumed "base" transaction type for this proposal. However, this is NOT a conceptual dependency; the included <code>accessList</code> portion of this proposal (the only differential from post-EIP-155 legacy transaction fields) can readily be removed. Standing on the shoulders of EIP-2930 is only intended to support and further the adoption of next-generation transactions.</p> <h3 id="signature-target">Signature target</h3> <p>The signature signs over the transaction type as well as the transaction data. This is done to ensure that the transaction cannot be “re-interpreted” as a transaction of a different type.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues.</p> <h2 id="test-cases">Test Cases</h2> <table><thead><tr><th>Segment ID</th><th>Block Number</th><th>Canonical Block Hash</th></tr></thead><tbody> <tr><td><code>e78b1ec3</code></td><td><code>0</code></td><td><code>0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58</code></td></tr> <tr><td><code>01e78b1ec3</code></td><td><code>1</code></td><td><code>0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58</code></td></tr> <tr><td><code>e4e1c0e78b1ec3</code></td><td><code>15_000_000</code></td><td><code>0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58</code></td></tr> <tr><td><code>e8d4a50fffe78b1ec3</code></td><td><code>999_999_999_999</code></td><td><code>0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58</code></td></tr> <tr><td><code>7fffffffffffffffe78b1ec3</code></td><td><code>9223372036854775807</code></td><td><code>0xe78b1ec31bcb535548ce4b6ef384deccad1e7dc599817b65ab5124eeaaee3e58</code></td></tr> </tbody></table> <p>Further test cases, TODO.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="why-4-bytes-of-a-block-hash-is-safe-enough-for-the-ancestorid">Why 4 bytes of a block hash is "safe enough" for the <code>ancestorId</code></h3> <p><strong>TL;DR</strong>: The chance of an ineffectual <code>ancestorId</code> is about 1 in between ~4 billion and ~40 billion, with the greater chance for intentional duplication scenarios, eg. malicious reorgs.</p> <p><strong>If a collision <em>does</em> happen</strong>, that means the transaction will be valid on both segments (as is the case under the status quo).</p> <p>Four bytes, instead of the whole hash (32 bytes), was chosen only to reduce the amount of information required to cross the wire to implement this value. Using the whole hash would result in a "perfectly safe" implementation, and every additional byte reduces the chance of collision exponentially.</p> <p>The goal of the <code>ancestorId</code> is to disambiguate one chain segment from another, and in doing so, enable a transaction to define with adequate precision which chain it needs to be on. When a transaction's <code>ancestorId</code> references a block, we want to be pretty sure that that reference won't get confused with a different block than the one the author of the transaction had in mind.</p> <p>We assume the trait of collision resistance is uniformly applicable to all possible subsets of the block hash value, so our preference of using the <em>first</em> 4 bytes is arbitrary and functionally equivalent to any other subset of equal length.</p> <p>For the sake of legibility and accessibility, the following arguments will reference the hex representation of 4 bytes, which is 8 characters in length, eg. <code>e78b1ec3</code>.</p> <p>The chance of a colliding <code>ancestorId</code> is <code>1/(16^8=4_294_967_296)</code> times whatever we take the chance of the existence of an equivalently-numbered block (on an alternative chain) to be. Assuming a generous ballpark chance of 10% (<code>1/10</code>) for any given block having a public uncle, this yields <code>(1/(16^8=4_294_967_296) * 1/10</code>. Note that this ballpark assumes "normal" chain and network behavior. In the case of an enduring competing chain segment, this value rises to 100% (<code>1</code>).</p> <h3 id="eligibleminerlist-2"><code>eligibleMinerList</code></h3> <p>Miners who do not find themselves listed in an annotated <code>eligibleMinerList</code> should be expected to immediately remove the transaction from their transaction pool.</p> <p>In a pessimistic outlook, we should also expect that these ineligible nodes would not offer rebroadcasts of these transactions, potentially impacting the distribution (and availability) of the transactions to their intended miners. On the other hand, miners are incentivized to make themselves available for reception of such transactions, and there are many ways this is feasible both on-network and off-.</p> <p>The author of a transaction using the <code>eligibleMinerList</code> must assume that the "general availability" of the blockchain state database for such a transaction will be lower than a nonrestrictive transaction (since only a subset of miners will be able to process the transaction).</p> <p>A final consideration is the economics of a whitelisted miner concerning the processing order of transactions in which they are whitelisted and those without whitelists. Transactions without whitelists would appear at first glean to be more competitive, and thus should be processed with priority. However, miners following such a strategy may find their reputation diminished, and, in the worst case, see the assertive preferences of transaction authors shift to their competitors and beyond their reach.</p> <h3 id="ineligibleminerlist-2"><code>ineligibleMinerList</code></h3> <p>In addition to the concerns and arguments presented by <code>eligibleMinerList</code> above, there is a unique concern for <code>ineligibleMinerList</code>: in order for a miner entity to avoid ineligibility by a blacklist, they only need to use an alternative adhoc address as the block beneficiary. In principle, this is ineluctable.</p> <p>However, there are associated costs to the "dodging" miner that should be considered.</p> <ul> <li>The creation of an account requires time and energy. But indeed, this work can be done at any convenient time and circumstance. Probably marginal, but non-zero.</li> <li>The transfer of funds from multiple accounts requires a commensurate number of transactions. Block rewards are applied after transactions are processed, so the miner is unable to simultaneously shift funds from an adhoc account to a target account in the same block they mine (which would otherwise be a "free" transaction).</li> <li>In using an adhoc address to dodge a blacklist, the miner may also cause their ineligibility from contemporary whitelist transactions.</li> </ul> <h3 id="validation-costs">Validation costs</h3> <p>Miner lists and expiry depend on easily cached and contextually available conditions (ie. the containing block header). The infrastructural overhead costs for enforcing these validations are expected to be nominal.</p> <p>Validation of <code>ancestorId</code> demands the assertion of a positive database hit by block number (thereby cross-referencing a stored block's hash). This necessary lookup can be (and maybe already is) cached, but we must expect less than 100% hits on cached values, since the lookup value is arbitrary. With that in mind, however, the value provided to a transaction using a deep <code>ancestorId</code> is increasingly marginal, so we should expect most transactions using this field to use a relatively small set of common, shallow, cache-friendly values.</p> <h3 id="transaction-size-increase">Transaction size increase</h3> <p>The proposed additional fields potentially increase transaction size. The proposed fields are not associated with any gas costs, establishing no protocol-defined economic mitigation for potential spam. However, transactions which are considered by a miner to be undesirable can be simply dropped from the transaction pool and ignored.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waved via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Papageorgiouhttps://github.com/alex-ppg https://wg-eips.ritovision.com/3508/ <h2 id="simple-summary">Simple Summary</h2> <p>Provide access to original transaction data.</p> <h2 id="abstract">Abstract</h2> <p>This EIP introduces the following three EVM instructions: <code>ORIGINDATALOAD</code>, <code>ORIGINDATASIZE</code>, and <code>ORIGINDATACOPY</code>.</p> <p>These three instructions are meant to provide access to the original transaction's <code>data</code> payload, enabling a gas-efficient way of accessing large data payloads in cross-contract calls.</p> <h2 id="motivation">Motivation</h2> <p>As the Ethereum development scene matures, more ambitious and complex features are introduced into smart contracts more often than not requiring the utilization of complex and at times large data structures. Given the inherent limits of the EVM, however, transporting large data structures in between contracts is a costly task that can at times lead to even futile scenarios whereby the gas consumption of such an operation is impossible to execute within the gas limit bounds as well as without sacrificing a large chunk of ETH to facilitate its gas cost.</p> <p>The purpose of this EIP is to render these features viable by introducing a way via which multi-contract systems are able to access the same in-memory data source without necessarily transmitting the full payload between them.</p> <p>This EIP enables elaborate smart contract features to become part of a larger call-chain by efficiently reading data from the original transaction payload rather than requiring the data to be passed in as call-level data. Its inclusion will mainly benefit advanced trustless schemes to manifest, such as efficient verification of Merkle Patricia trees validating the storage value of a particular Ethereum block or EVM-based layer 2 solutions.</p> <p>A side-effect of this change is that smart contract systems relying entirely on origin data inherently guarantee that the data they receive has not been malformed by an intermediate smart contract call.</p> <h2 id="specification">Specification</h2> <h3 id="origindataload-0x47-origindatasize-0x48-and-origindatacopy-0x49">ORIGINDATALOAD (<code>0x47</code>), ORIGINDATASIZE (<code>0x48</code>) and ORIGINDATACOPY (<code>0x49</code>)</h3> <p>These instructions are meant to operate similarly to their call-prefixed counterparts with the exception that they instead operate on the original <code>data</code> of a transaction instead of the current call's data. In detail:</p> <ul> <li>ORIGINDATALOAD (<code>0x47</code>) performs similarly to CALLDATALOAD (<code>0x35</code>)</li> <li>ORIGINDATASIZE (<code>0x48</code>) performs similarly to CALLDATASIZE (<code>0x36</code>)</li> <li>ORIGINDATACOPY (<code>0x49</code>) performs similarly to CALLDATACOPY (<code>0x37</code>)</li> </ul> <p>As the data is retrieved once again from the execution environment, the costs for the three instructions will be <code>G_verylow</code>, <code>G_base</code> and <code>G_base + G_verylow * (number of words copied, rounded up)</code> respectively.</p> <p>The transaction data the <code>ORIGINDATA*</code> opcodes operate on will be equivalent to the <code>calldata</code> specified in the <code>args*</code> parameter to the nearest <code>AUTHCALL</code> (<code>0xf7</code>) up the stack. If there is no <code>AUTHCALL</code> in the stack then <code>ORIGINDATA*</code> will operate on the transaction's original <code>data</code> field.</p> <p>This interaction ensures full compatibility with <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> and ensures that no form of discrimination is introduced back into the system by this EIP e.g. by contracts entirely relying on <code>ORIGINDATA*</code> and thus allowing only EOAs to supply data to them.</p> <h2 id="rationale">Rationale</h2> <h3 id="authcall-0xf7-interaction">AUTHCALL (<code>0xf7</code>) Interaction</h3> <p>The <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> that will be part of the London fork has introduced a new call instruction called <code>AUTHCALL</code> (<code>0xf7</code>) that will replace a transaction's <code>ORIGIN</code> (<code>0x32</code>) with the context variable <code>authorized</code>. The intention of <code>AUTHCALL</code> is to prevent discrimination between smart contracts and EOAs which <code>ORIGIN</code> initially facilitated and as a result, it is sensible also replace the values retrieved by the <code>ORIGINDATA*</code> opcodes to the ones used in the <code>AUTHCALL</code>.</p> <h3 id="naming-conventions">Naming Conventions</h3> <p>The <code>ORIGIN</code>-prefixed instructions attempted to conform to the existing naming convention of <code>CALL</code>-prefixed instructions given the existence of the <code>ORIGIN</code> (<code>0x32</code>) instruction which is equivalent to the <code>CALLER</code> (<code>0x33</code>) instruction but on the original transaction's context.</p> <h3 id="instruction-address-space">Instruction Address Space</h3> <p>The instruction address space of the <code>0x30-0x3f</code> has been exhausted by calls that already provide information about the execution context of a call so a new range had to be identified that is suitable for the purposes of the EIP.</p> <p>Given that the <a href="https://wg-eips.ritovision.com/1344/">EIP-1344</a> <code>CHAINID</code> opcode was included at <code>0x46</code>, it made sense to include additional transaction-related data beyond it since the Chain ID is also included in transaction payloads apart from the blocks themselves, rendering the <code>0x46-0x4f</code> address space reserved for more transaction-related data that may be necessary in the future, such as the EOA's nonce.</p> <h3 id="gas-costs">Gas Costs</h3> <p>The opcodes ORIGINDATALOAD (<code>0x47</code>), ORIGINDATASIZE (<code>0x48</code>), and ORIGINDATACOPY (<code>0x49</code>) essentially perform the same thing as opcodes CALLDATALOAD (<code>0x35</code>), CALLDATASIZE (<code>0x36</code>), and CALLDATACOPY (<code>0x37</code>) respectively and thus share the exact same gas costs.</p> <h3 id="instruction-space-pollution">Instruction Space Pollution</h3> <p>One can argue that multiple new EVM instructions pollute the EVM instruction address space and could cause issues in assigning sensible instruction codes to future instructions. This particular issue was assessed and a methodology via which the raw RLP encoded transaction may be accessible to the EVM was ideated. This would <em>future-proof</em> the new instruction set as it would be usable for other members of the transaction that may be desired to be accessible on-chain in the future, however, it would also cause a redundancy in the <code>ORIGIN</code> opcode.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The EIP does not alter or adjust existing functionality provided by the EVM and as such, no known issues exist.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="introspective-contracts">Introspective Contracts</h3> <p>Atomically, the <code>ORIGINDATALOAD</code> and <code>ORIGINDATACOPY</code> values should be considered insecure as they can easily be spoofed by creating an entry smart contract with the appropriate function signature and arguments that consequently invokes other contracts within the call chain. In brief, one should always assume that <code>tx.data != calldata</code> and these instructions should not be used as an introspection tool alone.</p> <h3 id="denial-of-service-attack">Denial-of-Service Attack</h3> <p>An initial concern that may arise from this EIP is the additional contextual data that must be provided at the software level of nodes to the EVM in order for it to be able to access the necessary data via the <code>ORIGINDATALOAD</code> and <code>ORIGINDATACOPY</code> instructions.</p> <p>This would lead to an increase in memory consumption, however, this increase should be negligible if at all existent given that the data of a transaction should already exist in memory as part of its execution process; a step in the overall inclusion of a transaction within a block.</p> <h3 id="multi-contract-system-gas-reduction">Multi-Contract System Gas Reduction</h3> <p>Given that most complex smart contract systems deployed on Ethereum today rely on cross-contract interactions whereby values are passed from one contract to another via function calls, the <code>ORIGIN</code>-prefixed instruction set would enable a way for smart contract systems to acquire access to the original transaction data at any given step in the call chain execution which could result in cross-contract calls ultimately consuming less gas if the data passed between them is reduced as a side-effect of this change.</p> <p>The gas reduction, however, would be an implementation-based optimization that would also be solely applicable for rudimentary memory arguments rather than storage-based data, the latter of which is most commonly utilized in these types of calls. As a result, the overall gas reduction observed by this change will be negligible for most implementations.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-16T00:00:00+00:00 2026-02-11T14:49:28+00:00 Alex Papageorgiouhttps://github.com/alex-ppg https://wg-eips.ritovision.com/3520/ <h2 id="simple-summary">Simple Summary</h2> <p>Provide access to the original recipient of a transaction.</p> <h2 id="abstract">Abstract</h2> <p>This EIP introduces the following EVM instruction: <code>ENTRYPOINT</code>.</p> <p>This instruction is meant to provide access to the original recipient of the transaction, the <code>to</code> address, enabling new ways of introspection to be applied in conjunction with <a href="https://wg-eips.ritovision.com/3508/">EIP-3508</a>.</p> <h2 id="motivation">Motivation</h2> <p>It is undeniable that smart contracts are becoming more interconnected than ever. Up until this point, smart contracts have entirely relied on compliant interfaces and introspection to introduce a new step in the call chain of a complex multi-contract interaction. However, this presents a forwards-only approach which limits the types of interactions that can manifest.</p> <p>The purpose of this EIP is to provide a way via which a contract is able to identify the entry-point of a transaction on the blockchain and deduce what was the original intention of the transaction by applying introspection on the original transaction data itself.</p> <p>This EIP enables the development of new types of smart contracts as it can open new pathways for <a href="https://wg-eips.ritovision.com/721/">EIP-721</a> NFTs and <a href="https://wg-eips.ritovision.com/20/">EIP-20</a> tokens to detect which action their transaction is part of, such as detecting a liquidity provision to a decentralized exchange or a loan within a collateralized lending protocol.</p> <h2 id="specification">Specification</h2> <h3 id="entrypoint-0x4a">ENTRYPOINT (<code>0x4a</code>)</h3> <p>The <code>ENTRYPOINT</code> instruction uses 0 stack arguments and pushes the original <code>to</code> member of the transaction onto the stack. The address yielded by the instruction is a 160-bit value padded to 256-bits. The operation costs <code>G_base</code> to execute, similarly to <code>ORIGIN</code> (<code>0x32</code>).</p> <p>The address returned by the <code>ENTRYPOINT</code> opcode will be equivalent to the <code>to</code> address parameter specified in the nearest <code>AUTHCALL</code> up the stack. If there is no <code>AUTHCALL</code> in the stack then <code>ENTRYPOINT</code> will retrieve the original transaction's <code>to</code> field.</p> <h2 id="rationale">Rationale</h2> <h3 id="authcall-0xf7-interaction">AUTHCALL (<code>0xf7</code>) Interaction</h3> <p>The <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> introduced a new call instruction called <code>AUTHCALL</code> (<code>0xf7</code>) that will replace a transaction's <code>ORIGIN</code> (<code>0x32</code>) with the context variable <code>authorized</code>. The intention of <code>AUTHCALL</code> is to prevent discrimination between smart contracts and EOAs which <code>ORIGIN</code> initially facilitated. The <code>ENTRYPOINT</code> opcode by itself re-introduces discrimination into the system as it indirectly allows one to evaluate whether the smart contract code being executed is done so by an EOA by validating that <code>ENTRYPOINT == ADDRESS</code> where <code>ADDRESS</code> (<code>0x30</code>) retrieves the currently executing account address. Therefore, it is sensible also replace the values retrieved by the <code>ENTRYPOINT</code> opcode to the target of an <code>AUTHCALL</code>.</p> <p>This interaction ensures full compatibility with <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> and ensures that no form of discrimination is introduced back into the system by this EIP.</p> <h3 id="naming-conventions">Naming Conventions</h3> <p>The <code>ENTRYPOINT</code> instruction came to be by defining a sensible name that immediately and clearly depicts what it is meant to achieve by signaling the first interaction of a particular call, i.e. the entry-point.</p> <h3 id="instruction-address-space">Instruction Address Space</h3> <p>Equivalent to <a href="https://wg-eips.ritovision.com/3508/">EIP-3508</a>.</p> <h3 id="gas-cost">Gas Cost</h3> <p>The opcode ENTRYPOINT (<code>0x4a</code>) essentially performs the same thing as the opcode ORIGIN (<code>0x32</code>) and thus shares the exact same gas cost.</p> <h3 id="dependency-on-eip-3508">Dependency on EIP-3508</h3> <p>The <code>ENTRYPOINT</code> (<code>0x4a</code>) instruction alone has no perceivable benefit as it can be replaced by the <code>AUTHCALL</code> (<code>0xf7</code>) instruction and as such should solely be introduced to the system in conjunction with the <code>ORIGINDATA*</code> opcodes defined in <a href="https://wg-eips.ritovision.com/3508/">EIP-3508</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The EIP does not alter or adjust existing functionality provided by the EVM and as such, no known issues exist.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="introspective-contracts">Introspective Contracts</h3> <p>The <code>ENTRYPOINT</code> instruction allows the association of the <code>ORIGINDATALOAD</code> and <code>ORIGINDATACOPY</code> values with a particular smart contract address and interface, enabling introspection to be applied based on the function signature invoked and the arguments provided to reliably deduce the call-path via which a particular smart contract was invoked and allowing a more granular level of interaction to be defined in such special cases.</p> <p>However, this type of introspection should solely be applied on pre-approved contracts rather than user-defined ones as the value stemming from this type of introspection entirely relies on a contract's code immutability and proper function, both of which a user supplied contract can easily bypass.</p> <h3 id="caller-discrimination">Caller Discrimination</h3> <p>The instructions of this EIP should not be utilized as a way to discriminate between EOA callers and smart contracts, as this type of differentiation can be broken by an <code>AUTHCALL</code> as defined in the specification chapter.</p> <h3 id="contract-creation-behaviour">Contract Creation Behaviour</h3> <p>The behaviour of the <code>ENTRYPOINT</code> opcode during a contract creation will result in the opcode yielding the zero-address as the first address interacted with in the transaction. This should be taken into account by contract implementations in a similar fashion to how <code>ecrecover</code> invalid signatures are handled to prevent software misbehaviours from arising.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Matt Garnetthttps://github.com/lightclient https://wg-eips.ritovision.com/3521/ <h2 id="simple-summary">Simple Summary</h2> <p>Reduce the cost of declaring <code>tx.to</code> storage keys in access lists.</p> <h2 id="motivation">Motivation</h2> <p>Currently, a transaction must read at least 25 distinct storage slots in <code>tx.to</code> before it's more expensive to forego an access list.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>ACCESS_LIST_ADDRESS_COST + (ACCESS_LIST_STORAGE_KEY_COST + WARM_STORAGE_READ_COST) * x = COLD_SLOAD_COST * x</span></span> <span class="giallo-l"><span>x = 24</span></span></code></pre> <p>EIP-2930 requires the address under which the storage keys reside be declared explicitly, since it must be added to the EIP-2929 <code>accessed_addresses</code> list. However, <code>tx.to</code> is a special case that is added by default, so paying <code>ACCESS_LIST_ADDRESS_COST</code> for <code>tx.to</code> is essentially paying twice for the same address. Avoiding overpayment here will reduce the differential to just 5 unique reads before using an access list is cheaper -- making them a more attractive option.</p> <h2 id="specification">Specification</h2> <p>Treat the first occurrence of <code>tx.to</code> in an access list as <code>calldata</code> for gas accounting purposes. Do not charge <code>ACCESS_LIST_ADDRESS_COST</code> for it. Storage keys underneath the address are unaffected.</p> <p>If <code>tx.to == nil</code>, <code>tx.to</code> is defined be the derived contract address created by the transaction.</p> <h2 id="rationale">Rationale</h2> <h3 id="why-charge-at-all">Why charge at all?</h3> <p>EIP-2930 is specifically written to make access lists simple to reason about and validate. It may be possible to modify the structure of the access list to avoid including <code>tx.to</code> explicitly, but this would renege on the spirit of EIP-2930.</p> <h3 id="why-charge-as-calldata">Why charge as <code>calldata</code>?</h3> <p>The cost of <code>calldata</code> was thoroughly analyzed in EIP-2028 to determine a fair value that is not susceptible to denial-of-service attacks. We consider this the lower bound on how much transaction data should cost. Since there is no computation burden imposed for adding <code>tx.to</code> to the <code>accessed_addresses</code> map (it's added by default by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>), there is no reason to charge more than the absolute minimum for the data.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: []</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>cost = 320</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span> &quot;0x00ffffffffffffffffffffffffffffffffffffff&quot;: []</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>cost = 308</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: []</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: []</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>cost = 2720</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: [</span></span> <span class="giallo-l"><span> &quot;0x00&quot;</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: []</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>cost = 4620</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: [</span></span> <span class="giallo-l"><span> &quot;0x00&quot;</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> &quot;0xffffffffffffffffffffffffffffffffffffffff&quot;: [</span></span> <span class="giallo-l"><span> &quot;0x00&quot;</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>cost = 6520</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-04-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements Baptiste Vautheyhttps://github.com/thabaptiser https://wg-eips.ritovision.com/3455/

A new opcode is introduced to allow calling from an arbitrary sender address.

<h2 id="abstract">Abstract</h2> <p>A new opcode, <code>SUDO</code>, is introduced with the same parameters as <code>CALL</code>, plus another parameter to specify the sender address.</p> <h2 id="motivation">Motivation</h2> <p>There are many use cases for being able to set the sender.</p> <p>Many tokens are stuck irretrievably because nobody has the key for the owner address. In particular, at address zero there is approximately 17 billion USD in tokens and ether, according to etherscan. With <code>SUDO</code>, anyone could free that value, leading to an economic boom that would end poverty and world hunger. Instead it is sitting there idle like the gold in Fort Knox. <code>SUDO</code> fixes this.</p> <p>It is a common mistake to send <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> tokens to the token address instead of the intended recipient. This happens because users paste the token address into the recipient fields. Currently there is no way to recover these tokens. <code>SUDO</code> fixes this.</p> <p>Many scammers have fraudulently received tokens and ETH via trust-trading. Their victims currently have no way to recover their funds. <code>SUDO</code> fixes this.</p> <p>Large amounts of users have accidentally locked up tokens and ether by losing their private keys. This is inefficient and provides a bad user experience. To accommodate new and inexperienced users, there needs to be a way to recover funds after the private key has been lost. <code>SUDO</code> fixes this.</p> <p>Finally, there are many tokens and ether sitting in smart contracts locked due to a bug. We could finally close EIP issue #156. We cannot currently reclaim ether from stuck accounts. <code>SUDO</code> fixes this.</p> <h2 id="specification">Specification</h2> <p>Adds a new opcode (<code>SUDO</code>) at <code>0xf8</code>. <code>SUDO</code> pops 8 parameters from the stack. Besides the sender parameter, the parameters shall match <code>CALL</code>.</p> <ol> <li>Gas: Integer; Maximum gas allowance for message call, safely using current gas counter if the counter is lower</li> <li>Sender: Address, truncated to lower 40 bytes; Sets <code>CALLER</code> inside the call frame</li> <li>To: Address, truncated to lower 40 bytes; sets <code>ADDRESS</code></li> <li>Value: Integer, raises exception amount specified is less than the value in Sender account; transferred with call to recipient balance, sets <code>CALLVALUE</code></li> <li>InStart: Integer; beginning of memory to use for <code>CALLDATA</code></li> <li>InSize: Integer; length of memory to use for <code>CALLDATA</code></li> <li>OutStart: Integer; beginning of memory to replace with <code>RETURNDATA</code></li> <li>OutSize: Integer; maximum <code>RETURNDATA</code> to place in memory</li> </ol> <p>Following execution, <code>SUDO</code> pushes a result value to the stack, indicating success or failure. If the call ended with <code>STOP</code>, <code>RETURN</code>, or <code>SELFDESTRUCT</code>, <code>1</code> is pushed. If the call ended with <code>REVERT</code>, <code>INVALID</code>, or an EVM assertion, <code>0</code> is pushed.</p> <h2 id="rationale">Rationale</h2> <p>The <code>GAS</code> parameter is first so that callers can tediously compute how much of their remaining gas to send at the last possible moment. The remaining parameters inherited from <code>CALL</code> are in the same order, with sender inserted between.</p> <h2 id="security-considerations">Security Considerations</h2> <p>It will be fine.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/3436/ <h2 id="simple-summary">Simple Summary</h2> <p>Add a four step block rule to Clique that should reduce block production deadlocks</p> <h2 id="abstract">Abstract</h2> <p>The current specification of Clique allows for multiple competing blocks from producers but does not provide any strategies to pick blocks aside from the current "highest total difficulty" rule. This EIP proposes a four step choice rule of highest total difficulty, shortest chain, most recently in-turn, and lowest hash. This would prevent deadlocks that have occurred in production systems.</p> <h2 id="motivation">Motivation</h2> <p>There has been more than one deadlock in the Goerli multi-client Clique network. The number of active validators was greater than 1/2 of the available validators so a chain halt should not have occurred. The halt was resolved by an inactive validator coming back on line. The state of the chain was in one of two configurations of 8 validators that can result in a chain halt. Three of the four clients observed a choice sequence of lowest total difficulty followed by first observed block. Geth added one extra rule of preferring the shortest chain before preferring the first observed block. This fork would have resolved itself with Geth's rule, but there is still a configuration where the chain can halt with a shortest chain rule.</p> <h2 id="specification">Specification</h2> <p>When a Clique validator is arbitrating the canonical status between two different chain head blocks, they should choose the canonical block with the following ordered priorities.</p> <ol> <li>Choose the block with the most total difficulty.</li> <li>Then choose the block with the lowest block number.</li> <li>Then choose the block whose validator had the least recent in-turn block assignment.</li> <li>Then choose the block with the lowest hash.</li> </ol> <p>When resolving rule 3 clients should use the following formula, where <code>validator_index</code> is the integer index of the validator that signed the block when sorted as per epoch checkpointing, <code>header_number</code> is the number of the header, and <code>validator_count</code> is the count of the current validators. Clients should choose the block with the <strong>largest</strong> value. Note that an in-turn block is considered to be the most recent in-turn block.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(header_number - validator_index) % validator_count</span></span></code></pre> <p>When resolving rule 4 the hash should be converted into an unsigned 256 bit integer.</p> <h2 id="rationale">Rationale</h2> <p>Two scenarios of a halted chain are known based on the current total difficulty then first observed rule. One of the scenarios is also resistant to the shortest chain rule.</p> <p>For the first scenario where chains of different lengths can halt consider a block with 8 validators, whose addresses sort to the same order as their designation in this example. A fully in-order chain exists and validator number 8 has just produced an in-turn block and then validators 5, 7 and 8 go offline, leaving validators 1 to 6 to produce blocks. Two forks form, one with an in-order block from validator 1 and then an out of order block from validator 3. The second fork forms from validators 2, 4, and 6 in order. Both have a net total difficulty of 3 more than the common ancestor. So in this case if both forks become aware of the other fork then both are considered equally viable and neither set of validators should switch to the newly observed fork. In this case, adding a shortest chain rule would break the deadlock as the even numbered validators would adopt the shorter chain.</p> <p>For the second scenario with the same validator set and in-order chain with validator 7 having just produced an in order block, then validators 7 and 8 go offline. Two forks form, 1,3,5 on one side and 2,4,6 on the other. Both forks become aware of the other fork after producing their third block. In this case both forks have equal total difficulty and equal length. So Geth's rule would not break the tie and only the arrival of one of the missing validators fix the chain. In a worst case scenario the odd and even chains would produce a block for 7 and 8 respectively, and chain halt would result with no validators that have not chosen a fork. Only a manual rollback would fix this.</p> <p>One consideration when formulating the rules is that the block choice should be chosen so that it would encourage the maximum amount of in-order blocks. Selecting a chain based on shortest chain implicitly prefers the chain with more in-order blocks. When selecting between competing out of order chains the validator who is closest to producing an in-order block in the future should have their chain declined so that they are available to produce an in-order block sooner.</p> <p>At least one client has been observed producing multiple blocks at the same height with the same difficulty, so a final catch-all standard of lowest block hash should break any remaining ties.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The current block choice rules are a mix of most total difficulty and most total difficulty plus shortest chain.</p> <p>As long as the majority of the active validators implement the block choice rules then a client who only implements the existing difficulty based rule will eventually align with the chain preferred by these rules. If less than a majority implement these rules then deadlocks can still occur, and depend on the first observation of problematic blocks, which is no worse than the current situation.</p> <p>If clients only partially implement the rule as long as every higher ranked rule is also implemented then the situation will be no worse than today.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Malicious and motivated attackers who are participating in the network can force the chain to halt with well crafted block production. With a fully deterministic choice rule the opportunity to halt is diminished. Attackers still have the same opportunities to flood the network with multiple blocks at the same height. A deterministic rule based on the lowest hash reduces the impact of such a flooding attack. A malicious validator could exploit this deterministic rule to produce a replacement block. Such an attack exists in current implementations but a deterministic hash rule makes such replacements more likely. However the impact of such an attack seems low to trivial at this time.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 HexZorrohttps://github.com/hexzorro Mojtaba Tefaghhttps://github.com/mtefagh https://wg-eips.ritovision.com/3416/ <h2 id="simple-summary">Simple Summary</h2> <p>A transaction pricing mechanism with a fixed-per-block network fee and a median inclusion fee with additive updates.</p> <h2 id="abstract">Abstract</h2> <p>There is a base fee per gas in protocol, which can move up or down by a maximum of 1/8 in each block. The base fee per gas is adjusted by the protocol to target an average gas usage per block instead of an absolute gas usage per block. The base fee is increased when blocks are over the gas limit target and decreases when blocks are under the gas limit target. Transaction senders specify their fees by providing <em>only one value</em>:</p> <ul> <li>The fee cap which represents the maximum total (base fee + gas premium) that the transaction sender would be willing to pay to get their transaction included, resembles the current maximum gas price specified by senders but in this protocol change proposal the final gas price paid, most of the time, will be lower than the proposed by the transaction sender.</li> </ul> <p>Then there is a gas premium that is directly computed as 50% of (fee cap - base fee). This gas premium gets added onto the base fee to calculate the gas price that will be used in the weighted median computation. The gas premium, determined directly by a specified fee cap, can either be set to a fairly low value to compensate miners for uncle rate risk only with the base fee, or to a high value to compete during sudden bursts of activity. Using all transactions that the miner wants to include in the block, a <strong>weighted median gas premium</strong> is computed, not considering in the computation 5% of gas price outliers on the upper-side for extra robustness against miner manipulation.</p> <h2 id="motivation">Motivation</h2> <p>We target the following goals:</p> <ul> <li>Gas prices spikes are mathematically smoothed out. EIP1559 does not seems to really tackle gas premium volatility and UX.</li> <li>Maintain gas price preference, i.e. transaction senders willing to pay extra in fees will be rewarded with early preferential inclusion in the blocks, because the miners want to maximize their profits and include transactions with higher fee caps first to maximize the median.</li> <li>Final gas price paid by the sender is, most of the time, smaller than the maximum gas price specified by sender.</li> <li>Gas pricing is more robust to sender manipulation or miner manipulation.</li> </ul> <p>Ethereum currently prices transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency:</p> <ul> <li><strong>Current extreme volatility of gas prices is hurting user experience</strong>: if you observe online gas price metrics, the current trends in recommended gas prices can change substantially by the minute, making the user experience in the network very awkward. Also, gas volatility makes the mining business more unpredictable and costly, because miners need to spend money hedging the risks.</li> <li><strong>Mismatch between volatility of transaction fee levels and social cost of transactions</strong>: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum bids range between 1 nanoeth (10^9 nanoeth = 1 ETH), but sometimes go over 100 nanoeth and have reached over 200 nanoeth. This clearly creates many inefficiencies, because it's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 200x more when gas prices are 200 nanoeth than when they are 1 nanoeth; in both cases, it's a difference between 8 million gas and 8.02 million gas.</li> <li><strong>Needless delays for users</strong>: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no "slack" mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand.</li> <li><strong>Inefficiencies of first price auctions</strong>: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment. We need a more stable fee metric that is computed inside the protocol.</li> </ul> <p>The proposal in this EIP is to start with a base fee amount which is adjusted up and down by the protocol based on how congested the network is. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. Because these base fee changes are constrained, the maximum difference in base fee from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users the base fee will be estimated by their wallet and a small gas premium related to the urgency and the priority they want to instill into the transaction.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <p>This is a classic fork without a long migration time.</p> <ul> <li><code>FORK_BLOCK_NUMBER</code>: TBD. Block number at or after which EIP-3416 transactions are valid.</li> <li><code>GAS_TARGET_MAX_CHANGE</code>: <code>1 // 1024</code>.</li> <li><code>BLOCK_GAS_USED</code>: total gas consumed by transaction included in the block.</li> <li><code>PARENT_GAS_USED</code>: same as <code>BLOCK_GAS_USED</code> for parent block.</li> <li><code>CURRENT_BLOCK</code>: The current block that is being worked with (either being validated, or being produced).</li> <li><code>BASE_FEE</code>: 16th item in the block header. Represents the amount of attoeth burned for every unit of gas a transaction uses.</li> <li><code>PARENT_BASE_FEE</code>: same as <code>BASE_FEE</code> for parent block.</li> <li><code>BASE_FEE_MAX_CHANGE</code>: <code>1 // 8</code></li> <li><code>INITIAL_BASE_FEE</code> : Median gas price in <code>FORK_BLOCK_NUMBER - 1</code>.</li> </ul> <h3 id="process">Process</h3> <ul> <li>At <code>block.number == FORK_BLOCK_NUMBER</code> we set <code>BASE_FEE = INITIAL_BASE_FEE</code></li> <li><code>BASE_FEE</code> is set, from <code>FORK_BLOCK_NUMBER + 1</code>, as follows <ul> <li>Let <code>GAS_DELTA = (PARENT_GAS_USED - PARENT_GAS_TARGET) // PARENT_GAS_TARGET</code> (possibly negative).</li> <li>Set <code>BASE_FEE = PARENT_BASE_FEE + GAS_DELTA * BASE_FEE_MAX_CHANGE</code></li> </ul> </li> <li>Transactions since <code>FORK_BLOCK_NUMBER</code> are encoded the same as the current ones <code>rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])</code> where <code>v,r,s</code> is a signature of <code>rlp([nonce, gasPrice, gasLimit, to, value, data])</code> and <code>gasPrice</code> is the <code>FEE_CAP</code> specified by the sender according to this proposal.</li> <li>To produce transactions since <code>FORK_BLOCK_NUMBER</code>, the new <code>FEE_CAP</code> field (maintaining legacy name of <code>gasPrice</code> in the transaction) is set as follows (and the <code>GAS_PREMIUM</code> is computed as specified): <ul> <li><code>FEE_CAP</code>: <code>tx.gasPrice</code>, serves as the absolute maximum that the transaction sender is willing to pay.</li> <li><code>GAS_PREMIUM = (FEE_CAP - BASE_FEE) / 2</code> serves as a sender-preferred median premium to the miner, beyond the base fee.</li> <li>If <code>FEE_CAP &lt; BASE_FEE</code> then the transaction is considered invalid and cannot be included in the current block, but might be included in future blocks.</li> </ul> </li> <li>During transaction execution, for EIP3416 transactions we calculate the cost to the <code>tx.origin</code> and the gain to the <code>block.coinbase</code> as follows: <ul> <li>Set <code>GASPRICE = BASE_FEE + median((tx_i.gasPrice - BASE_FEE) / 2)</code> among all transactions <code>tx_i</code> included in the same block, <em>weighted by gas consumed</em> and not including the top 5% of outlier gas price in calculation. By weighted median without 5% of the upper-side outliers, we mean that each gas unit spent is ordered according to the corresponding transaction by <code>BASE_FEE + tx.gasPrice / 2</code> and then the value chosen will be the one separating the lower 95% in two parts.</li> <li>Let <code>GASUSED</code> be the gas used during the transaction execution/state transition.</li> <li>The <code>tx.origin</code> initially pays <code>GASPRICE * tx.gasLimit</code>, and gets refunded <code>GASPRICE * (tx.gasLimit - GASUSED)</code>.</li> </ul> </li> </ul> <p>The miners can still use a <code>greedy</code> strategy to include new transactions in the proposed blocks by adding the transactions ordered by larger <code>FEE_CAP</code> first. This is similar to how current blocks are filled, and is a consequence of <code>FEE_CAP</code> and <code>GAS_PREMIUM</code> being a positive linear function of each other.</p> <h2 id="rationale">Rationale</h2> <p>The rationale behind the premium being 50% of (fee cap - base fee) is that at any given point the average network sender has an average fee cap, and we assume that between base fee and fee cap the sender has no specific preference, as long as the transaction is included in some block. Then, the sender is happy with a median premium among this uniform range. Another justification can be that the user also knows that this new version of the pricing protocol for the complete block uses a median, then is fair for him to apply a median within his preferential range, assuming an uniform sampling there. Simulations (<a rel="external" href="https://hackmd.io/c6kyRNMuTnKf_SlolmevRg#An-improvement-for-the-premium">here</a>) with Ethereum gas data shows indeed that median one of the most robust metric.s</p> <p>The 5% top outliers removal, not considered in the median, or similar number, is to give extra robustness against miner manipulation, because as current network utilization has been around 97% for the last 6 months the miners can include their own transactions on the empty 3% to try to manipulate and increase the median price (even this manipulation effect will be very small on the final price).</p> <p>The rationale for the <code>BASE_FEE</code> update formula is that we are using an additive version (<code>PARENT_BASE_FEE + GAS_DELTA * BASE_FEE_MAX_CHANGE</code>) to avoid an attack of senders sending this fee to zero. This attack was simulated and observed for multiplicative formula proposed in previous version (<code>PARENT_BASE_FEE + PARENT_BASE_FEE * GAS_DELTA * BASE_FEE_MAX_CHANGE</code>). See an article about the attack and the simulation <a rel="external" href="https://mtefagh.github.io/fee/">here</a>.</p> <p>Another rationale for the additive <code>BASE_FEE</code> update formula is that it guarantees (see <a rel="external" href="https://pdfs.semanticscholar.org/3d2d/773983c5201b58586af463f045befae5bbf2.pdf">this</a> article) that the optimal execution strategy (scheduling broadcasts in order to pay less fee) for a batch of nonurgent transactions is to spread the transactions across different blocks which in turn helps to avoid network congestion and lowers volatility. For the multiplicative formula, it is exactly the reverse, that is, spikes (dumping all your transactions at once) are incentivized as described <a rel="external" href="https://ethresear.ch/t/path-dependence-of-eip-1559-and-the-simulation-of-the-resulting-permanent-loss/8964">here</a>.</p> <p>The rationale for the <code>BASE_FEE_MAX_CHANGE</code> being <code>1 // 8</code> is that the <code>BASE_FEE</code> is designed to be very adaptative to block utilization changes.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The backward compatibility is very straightforward because there are no new fields added to the transactions. Pricing of the gas per block on the miner/validator side is still fast to compute but a little more complex. Changes only affect miners/validators. Wallets are no affected by this proposal.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Senders cannot manipulate the minimum fee because the minimum <code>BASE_FEE</code> is controlled by the miners with small increments or decrements on each new block proposed.</li> <li>Above the <code>BASE_FEE</code> the senders have a very limited ability to manipulate and lower the final gas price they pay because they have to move the weighted median close to <code>BASE_FEE</code> and, as we know, this is a very robust statistic.</li> <li>Miners have a very limited ability to manipulate and raise the final gas price paid by senders above <code>BASE_FEE</code> because to influence the final gas price they have to stuff fake transactions beyond the top 5% of the blocks. In average and currently, only the top 3% of the block is empty, so to fill-up 5% of the block they need to start dropping profitable transactions to reach 5%. Only beyond 5% of the top block gas they can start moving the median a little and the median is still a very robust statistic, not liable to being easily manipulated.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/3403/ <h2 id="simple-summary">Simple Summary</h2> <p>Remove gas refunds for SELFDESTRUCT, and restrict gas refunds for SSTORE to one specific case.</p> <h2 id="motivation">Motivation</h2> <p>Gas refunds for SSTORE and SELFDESTRUCT were originally introduced to motivate application developers to write applications that practice "good state hygiene", clearing storage slots and contracts that are no longer needed. However, they are not widely used for this, and poor state hygiene continues to be the norm. It is now widely accepted that the only solution to state growth is some form of statelessness or state expiry, and if such a solution is implemented, then disused storage slots and contracts would start to be ignored automatically.</p> <p>Gas refunds additionally have multiple harmful consequences:</p> <ul> <li>Refunds give rise to GasToken. GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a "battery" to save up gas) and inefficiently clogging blockchain gas usage</li> <li>Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction's gas used). This is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can.</li> </ul> <h3 id="the-mutex-usecase">The mutex usecase</h3> <p>There are two typical ways to implement mutexes: '0-1-0' and '1-2-1. Let's see how they differ</p> <ul> <li>'0-1-0': <ul> <li>Istanbul: 1612</li> <li>Berlin: 212</li> <li>NoRefund: 20112</li> <li>EIP-3403: 1112</li> </ul> </li> <li>'1-2-1': <ul> <li>Istanbul: 1612</li> <li>Berlin: 212</li> <li>NoRefund: 3012</li> <li>EIP-3403: 3012</li> </ul> </li> </ul> <p><strong>Note</strong>: In reality, there are never a negative gas cost, since the refund is capped at 0.5 * gasUsed. However, these tables show the negative values, since a more real-world scenario would likely spend the extra gas on other operations.'</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> <tr><td><code>SSTORE_REFUND_GAS</code></td><td>19000</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <ol> <li>Remove the <code>SELFDESTRUCT</code> refund.</li> <li>Remove the <code>SSTORE</code> refund in all cases except for one specific case: if the <em>new value</em> and <em>original value</em> of the storage slot both equal 0 but the <em>current value</em> does not (those terms being defined as in <a rel="external" href="https://eips.ethereum.org/EIPS/eip-1283">EIP-1283</a>), refund <code>SSTORE_REFUND_GAS</code> gas.</li> </ol> <h2 id="rationale">Rationale</h2> <p>Preserving refunds in the <code>new = original = 0 != current</code> case ensures that a few key use cases that deserve favorable gas cost treatment continue to receive favorable gas cost treatment, particularly:</p> <ul> <li>Anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends)</li> <li>ERC20 approve-and-send (the "approved value" goes from zero to nonzero when the token transfer is approved, and then back to zero when the token transfer processes)</li> </ul> <p>It also preserves two key goals of EIP 3298:</p> <ol> <li>Gas tokens continue to be non-viable, because each 19000 refund is only possible because of 19000 extra gas that was paid for flipping that storage slot from zero to nonzero earlier in the same transaction, so you can't clear some storage slots and use that saved gas to fill others.</li> <li>The total amount of gas <em>spent on execution</em> is capped at the gas limit. Every 19000 refund for flipping a storage slot non from zero -&gt; zero is only possible because of 19000 extra gas paid for flipping that slot from zero -&gt; nonzero earlier in the same transaction; that gas paid for a storage write and expansion that were both reverted and so do not actually need to be applied to the Merkle tree. Hence, this extra gas does not contribute to risk.</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Refunds are currently only applied <em>after</em> transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.</p> <p>Gas tokens in particular will become valueless. DeFi arbitrage bots, which today frequently use either established gas token schemes or a custom alternative to reduce on-chain costs, would benefit from rewriting their code to remove calls to these no-longer-functional gas storage mechanisms.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="2929-gas-costs">2929 Gas Costs</h3> <p>Note, there is a difference between 'hot' and 'cold' slots. This table shows the values as of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> assuming that all touched storage slots were already 'hot' (the difference being a one-time cost of <code>2100</code> gas).</p> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th><th>Effective gas (after refund)</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>212</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20112</td><td>19900</td><td>0</td><td>1</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60006000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>0</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>0</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>2</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60026000556003600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556001600055</code></td><td>3012</td><td>2800</td><td>1</td><td>2</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x60026000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>3012</td><td>15000</td><td>1</td><td>1</td><td>0</td><td></td><td>-11988</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>212</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40118</td><td>19900</td><td>0</td><td>1</td><td>0</td><td>1</td><td>20218</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>5918</td><td>17800</td><td>1</td><td>0</td><td>1</td><td>0</td><td>-11882</td></tr> </tbody></table> <h3 id="with-eip-3403-partial-refunds">With EIP-3403 partial refunds</h3> <p>If refunds were to be partially removed, as specified <a rel="external" href="https://github.com/ethereum/EIPs/pull/3403/">here</a>, this would be the comparative table. <strong>This table also assumes touched storage slots were already 'hot'</strong>.</p> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th><th>Effective gas (after refund)</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>212</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td><td>212</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20112</td><td>19000</td><td>0</td><td>1</td><td>0</td><td></td><td>1112</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td><td>20112</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20112</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td>20112</td></tr> <tr><td><code>0x60006000556000600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>0</td><td></td><td>3012</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>1</td><td></td><td>3012</td></tr> <tr><td><code>0x60006000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556000600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>0</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556003600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556001600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>1</td><td></td><td>3012</td></tr> <tr><td><code>0x60026000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>3012</td><td>0</td><td>1</td><td>1</td><td>0</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>3012</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td><td>3012</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>212</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td><td>212</td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40118</td><td>19000</td><td>0</td><td>1</td><td>0</td><td>1</td><td>21118</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>5918</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td>5918</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>Refunds are not visible to transaction execution, so this should not have any impact on transaction execution logic.</p> <p>The maximum amount of gas that can be spent on execution in a block is limited to the gas limit, if we do not count zero-to-nonzero SSTOREs that were later reset back to zero. It is okay to not count those, because if such an SSTORE is reset, storage is not expanded and the client does not need to actually adjust the Merke tree; the gas consumption is refunded, but the effort normally required by the client to process those opcodes is also cancelled. <strong>Clients should make sure to not do a storage write if <code>new_value = original_value</code>; this was a prudent optimization since the beginning of Ethereum but it becomes more important now.</strong></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Andrei Maiborodahttps://github.com/gumb0 Matt Garnetthttps://github.com/lightclient Piotr Dobaczewskihttps://github.com/pdobacz https://wg-eips.ritovision.com/3540/

EOF is an extensible and versioned container format for EVM bytecode with a once-off validation at deploy time.

<h2 id="abstract">Abstract</h2> <p>We introduce an extensible and versioned container format for the EVM with a once-off validation at deploy time. The version described here brings the tangible benefit of code and data separation, and allows for easy introduction of a variety of changes in the future. This change relies on the reserved byte introduced by <a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>.</p> <p>To summarise, EOF bytecode has the following layout:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>magic, version, (section_kind, section_size_or_sizes)+, 0, &lt;section contents&gt;</span></span></code></pre><h2 id="motivation">Motivation</h2> <p>On-chain deployed EVM bytecode contains no pre-defined structure today. Code is typically validated in clients to the extent of <code>JUMPDEST</code> analysis at runtime, every single time prior to execution. This poses not only an overhead, but also a challenge for introducing new or deprecating existing features.</p> <p>Validating code during the contract creation process allows code versioning without an additional version field in the account. Versioning is a useful tool for introducing or deprecating features, especially for larger changes (such as significant changes to control flow, or features like account abstraction).</p> <p>The format described in this EIP introduces a simple and extensible container with a minimal set of changes required to both clients and languages, and introduces validation.</p> <p>The first tangible feature it provides is separation of code and data. This separation is especially beneficial for on-chain code validators (like those utilised by layer-2 scaling tools, such as Optimism), because they can distinguish code and data (this includes deployment code and constructor arguments too). Currently, they a) require changes prior to contract deployment; b) implement a fragile method; or c) implement an expensive and restrictive jump analysis. Code and data separation can result in ease of use and significant gas savings for such use cases. Additionally, various (static) analysis tools can also benefit, though off-chain tools can already deal with existing code, so the impact is smaller.</p> <p>A non-exhaustive list of proposed changes which could benefit from this format:</p> <ul> <li>Including a <code>JUMPDEST</code>-table (to avoid analysis at execution time) and/or removing <code>JUMPDEST</code>s entirely.</li> <li>Introducing static jumps (with relative addresses) and jump tables, and disallowing dynamic jumps at the same time.</li> <li>Multibyte opcodes without any workarounds.</li> <li>Representing functions as individual code sections instead of subroutines.</li> <li>Introducing special sections for different use cases, notably Account Abstraction.</li> </ul> <h2 id="specification">Specification</h2> <p>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 and RFC 8174.</p> <p>In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. This is achieved by choosing a byte sequence for the <em>magic</em> that doesn't exist in any of the already deployed contracts.</p> <h3 id="remarks">Remarks</h3> <p>If code starts with the <code>MAGIC</code>, it is considered to be EOF formatted, otherwise it is considered to be <em>legacy</em> code. For clarity, the <code>MAGIC</code> together with a version number <em>n</em> is denoted as the <em>EOFn prefix</em>, e.g. <em>EOF1 prefix</em>.</p> <p>EOF-formatted contracts are created using new instructions which are introduced in a separate EIP.</p> <p>The opcode <code>0xEF</code> is currently an undefined instruction, therefore: <em>It pops no stack items and pushes no stack items, and it causes an exceptional abort when executed.</em> This means legacy <em>initcode</em> or already deployed legacy <em>code</em> starting with this instruction will continue to abort execution.</p> <p>Unless otherwise specified, all integers are encoded in big-endian byte order.</p> <h3 id="code-validation">Code validation</h3> <p>We introduce <em>code validation</em> for new contract creation. To achieve this, we define a format called EVM Object Format (EOF), containing a version indicator, and a ruleset of validity tied to a given version.</p> <p>Legacy code is not affected by EOF code validation.</p> <p>Code validation is performed during contract creation, and is elaborated on in separate EIPs. The EOF format itself and its formal validation are described in the following sections.</p> <h3 id="container-specification">Container specification</h3> <p>EOF container is a binary format with the capability of providing the EOF version number and a list of EOF sections.</p> <p>The container starts with the EOF prefix:</p> <table><thead><tr><th>description</th><th>length</th><th>value</th><th></th></tr></thead><tbody> <tr><td>magic</td><td>2-bytes</td><td>0xEF00</td><td></td></tr> <tr><td>version</td><td>1-byte</td><td>0x01–0xFF</td><td>EOF version number</td></tr> </tbody></table> <p>The EOF prefix is followed by at least one section header. Each section header contains two fields, <code>section_kind</code> and either <code>section_size</code> or <code>section_size_list</code>, depending on the kind. <code>section_size_list</code> is a list of size values when multiple sections of this kind are allowed, encoded as a count of items followed by the items.</p> <table><thead><tr><th>description</th><th>length</th><th>value</th><th></th></tr></thead><tbody> <tr><td>section_kind</td><td>1-byte</td><td>0x01–0xFF</td><td><code>uint8</code></td></tr> <tr><td>section_size</td><td>2-bytes</td><td>0x0000–0xFFFF</td><td><code>uint16</code></td></tr> <tr><td>section_size_list</td><td>dynamic</td><td>n/a</td><td><code>uint16, uint16+</code></td></tr> </tbody></table> <p>The list of section headers is terminated with the <em>section headers terminator byte</em> <code>0x00</code>. The body content follows immediately after.</p> <h4 id="container-validation-rules">Container validation rules</h4> <ol> <li><code>version</code> MUST NOT be <code>0</code>.</li> <li><code>section_kind</code> MUST NOT be <code>0</code>. The value <code>0</code> is reserved for <em>section headers terminator byte</em>.</li> <li>There MUST be at least one section (and therefore section header).</li> <li>Stray bytes outside of sections MUST NOT be present. This includes trailing bytes after the last section.</li> </ol> <h3 id="eof-version-1">EOF version 1</h3> <p>EOF version 1 is made up of several EIPs, including this one. Some values in this specification are only discussed briefly. To understand the full scope of EOF, it is necessary to review each EIP in-depth.</p> <h4 id="container">Container</h4> <p>The EOF version 1 container consists of a <code>header</code> and <code>body</code>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>container := header, body</span></span> <span class="giallo-l"><span>header := </span></span> <span class="giallo-l"><span> magic, version, </span></span> <span class="giallo-l"><span> kind_type, type_size, </span></span> <span class="giallo-l"><span> kind_code, num_code_sections, code_size+,</span></span> <span class="giallo-l"><span> [kind_container, num_container_sections, container_size+,]</span></span> <span class="giallo-l"><span> kind_data, data_size,</span></span> <span class="giallo-l"><span> terminator</span></span> <span class="giallo-l"><span>body := types_section, code_section+, container_section*, data_section</span></span> <span class="giallo-l"><span>types_section := (inputs, outputs, max_stack_increase)+</span></span></code></pre> <p><em>note: <code>,</code> is a concatenation operator, <code>+</code> should be interpreted as "one or more" of the preceding item, <code>*</code> should be interpreted as "zero or more" of the preceding item, and <code>[item]</code> should be interpreted as an optional item.</em></p> <h4 id="header">Header</h4> <table><thead><tr><th>name</th><th>length</th><th>value</th><th>description</th></tr></thead><tbody> <tr><td>magic</td><td>2 bytes</td><td>0xEF00</td><td></td></tr> <tr><td>version</td><td>1 byte</td><td>0x01</td><td>EOF version</td></tr> <tr><td>kind_type</td><td>1 byte</td><td>0x01</td><td>kind marker for type section</td></tr> <tr><td>type_size</td><td>2 bytes</td><td>0x0004-0x1000</td><td>16-bit unsigned big-endian integer denoting the length of the type section content, 4 bytes per code section</td></tr> <tr><td>kind_code</td><td>1 byte</td><td>0x02</td><td>kind marker for code size section</td></tr> <tr><td>num_code_sections</td><td>2 bytes</td><td>0x0001-0x0400</td><td>16-bit unsigned big-endian integer denoting the number of the code sections</td></tr> <tr><td>code_size</td><td>2 bytes</td><td>0x0001-0xFFFF</td><td>16-bit unsigned big-endian integer denoting the length of the code section content</td></tr> <tr><td>kind_container</td><td>1 byte</td><td>0x03</td><td>kind marker for container size section</td></tr> <tr><td>num_container_sections</td><td>2 bytes</td><td>0x0001-0x0100</td><td>16-bit unsigned big-endian integer denoting the number of the container sections</td></tr> <tr><td>container_size</td><td>4 bytes</td><td>0x00000001-0xFFFFFFFF</td><td>32-bit unsigned big-endian integer denoting the length of the container section content</td></tr> <tr><td>kind_data</td><td>1 byte</td><td>0xFF</td><td>kind marker for data size section</td></tr> <tr><td>data_size</td><td>2 bytes</td><td>0x0000-0xFFFF</td><td>16-bit unsigned big-endian integer denoting the length of the data section content (*)</td></tr> <tr><td>terminator</td><td>1 byte</td><td>0x00</td><td>marks the end of the header</td></tr> </tbody></table> <p>(*) For not yet deployed containers this can be greater than the actual content length.</p> <h4 id="body">Body</h4> <table><thead><tr><th>name</th><th>length</th><th>value</th><th>description</th></tr></thead><tbody> <tr><td>types_section</td><td>variable</td><td>n/a</td><td>stores code section metadata</td></tr> <tr><td>inputs</td><td>1 byte</td><td>0x00-0x7F</td><td>number of stack elements the code section consumes</td></tr> <tr><td>outputs</td><td>1 byte</td><td>0x00-0x7F</td><td>number of stack elements the code section returns</td></tr> <tr><td>max_stack_increase</td><td>2 bytes</td><td>0x0000-0x03FF</td><td>maximum increase of the operand stack height by the code section</td></tr> <tr><td>code_section</td><td>variable</td><td>n/a</td><td>arbitrary bytecode</td></tr> <tr><td>container_section</td><td>variable</td><td>n/a</td><td>arbitrary EOF-formatted container</td></tr> <tr><td>data_section</td><td>variable</td><td>n/a</td><td>arbitrary sequence of bytes</td></tr> </tbody></table> <p><strong>NOTE</strong>: A special value of <code>outputs</code> being <code>0x80</code> is designated to denote non-returning functions as defined in a separate EIP.</p> <h4 id="eof-version-1-validation-rules">EOF version 1 validation rules</h4> <p>The following validity constraints are placed on the container format:</p> <ul> <li><code>types_size</code> is divisible by <code>4</code></li> <li>the number of code sections must be equal to <code>types_size / 4</code></li> <li>data body length may be shorter than <code>data_size</code> for a not yet deployed container</li> <li>the total size of a container must not exceed <code>MAX_INITCODE_SIZE</code> (as defined in <a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a>)</li> </ul> <h3 id="changes-to-execution-semantics">Changes to execution semantics</h3> <p>For an EOF contract:</p> <ul> <li>Execution starts at the first byte of code section 0</li> <li><code>CODESIZE</code>, <code>CODECOPY</code>, <code>EXTCODESIZE</code>, <code>EXTCODECOPY</code>, <code>EXTCODEHASH</code>, <code>GAS</code> are rejected by validation in EOF contracts, with no replacements</li> <li><code>CALL</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code> are rejected by validation in EOF contracts, replacement instructions to be introduced in a separate EIP.</li> <li><code>DELEGATECALL</code> (or any replacement instruction for EOF) from an EOF contract to a non-EOF contract (legacy contract, EOA, empty account) is disallowed, and it should fail in the same mode as if the call depth check failed. We allow legacy to EOF path for existing proxy contracts to be able to use EOF upgrades.</li> </ul> <p>For a legacy contract:</p> <ul> <li>If the target account of <code>EXTCODECOPY</code> is an EOF contract, then it will copy up to 2 bytes from <code>EF00</code>, as if that would be the code.</li> <li>If the target account of <code>EXTCODEHASH</code> is an EOF contract, then it will return <code>0x9dbf3648db8210552e9c4f75c6a1c3057c0ca432043bd648be15fe7be05646f5</code> (the hash of <code>EF00</code>, as if that would be the code).</li> <li>If the target account of <code>EXTCODESIZE</code> is an EOF contract, then it will return 2.</li> </ul> <p><strong>NOTE</strong> Like for legacy targets, the aforementioned behavior of <code>EXTCODECOPY</code>, <code>EXTCODEHASH</code> and <code>EXTCODESIZE</code> does not apply to EOF contract targets mid-creation, i.e. those report same as accounts without code.</p> <h2 id="rationale">Rationale</h2> <p>EVM and/or account versioning has been discussed numerous times over the past years. This proposal aims to learn from them. See "Ethereum account versioning" on the Fellowship of Ethereum Magicians Forum for a good starting point.</p> <h3 id="execution-vs-creation-time-validation">Execution vs. creation time validation</h3> <p>This specification introduces creation time validation, which means:</p> <ul> <li>All created contracts with <em>EOFn</em> prefix are valid according to version <em>n</em> rules. This is very strong and useful property. The client can trust that the deployed code is well-formed.</li> <li>In the future, this allows to serialize <code>JUMPDEST</code> map in the EOF container and eliminate the need of implicit <code>JUMPDEST</code> analysis required before execution.</li> <li>Or to completely remove the need for <code>JUMPDEST</code> instructions.</li> <li>This helps with deprecating EVM instructions and/or features.</li> <li>The biggest disadvantage is that deploy-time validation of EOF code must be enabled in two hard-forks. However, the first step (<a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>) is already deployed in London.</li> </ul> <p>The alternative is to have execution time validation for EOF. This is performed every single time a contract is executed, however clients may be able to cache validation results. This <em>alternative</em> approach has the following properties:</p> <ul> <li>Because the validation is consensus-level execution step, it means the execution always requires the entire code. This makes <em>code merkleization impractical</em>.</li> <li>Can be enabled via a single hard-fork.</li> <li>Better backwards compatibility: data contracts starting with the <code>0xEF</code> byte or the <em>EOF prefix</em> can be deployed. This is a dubious benefit, however.</li> </ul> <h3 id="the-magic">The MAGIC</h3> <ol> <li> <p>The first byte <code>0xEF</code> was chosen because it is reserved for this purpose by <a href="https://wg-eips.ritovision.com/3541/">EIP-3541</a>.</p> </li> <li> <p>The second byte <code>0x00</code> was chosen to avoid clashes with three contracts which were deployed on <strong>Mainnet</strong>:</p> <ul> <li><code>0xca7bf67ab492b49806e24b6e2e4ec105183caa01</code>: <code>EFF09f918bf09f9fa9</code></li> <li><code>0x897da0f23ccc5e939ec7a53032c5e80fd1a947ec</code>: <code>EF</code></li> <li><code>0x6e51d4d9be52b623a3d3a2fa8d3c5e3e01175cd0</code>: <code>EF</code></li> </ul> </li> <li> <p>No contracts starting with <code>0xEF</code> bytes exist on public testnets: Goerli, Ropsten, Rinkeby, Kovan and Sepolia at their London fork block.</p> </li> </ol> <p><strong>NOTE</strong>: This EIP MUST NOT be enabled on chains which contain bytecodes starting with <code>MAGIC</code> and not being valid EOF.</p> <h3 id="eof-version-range-start-with-1">EOF version range start with 1</h3> <p>The version number 0 will never be used in EOF, so we can call legacy code <em>EOF0</em>. Also, implementations may use APIs where 0 version number denotes legacy code.</p> <h3 id="section-structure">Section structure</h3> <p>We have considered different questions for the sections:</p> <ul> <li>Streaming headers (i.e. <code>section_header, section_data, section_header, section_data, ...</code>) are used in some other formats (such as WebAssembly). They are handy for formats which are subject to editing (adding/removing sections). That is not a useful feature for EVM. One minor benefit applicable to our case is that they do not require a specific "header terminator". On the other hand they seem to play worse with code chunking / merkleization, as it is better to have all section headers in a single chunk.</li> <li>Whether to have a header terminator or to encode <code>number_of_sections</code> or <code>total_size_of_headers</code>. Both raise the question of how large of a value these fields should be able to hold. A terminator byte seems to avoid the problem of choosing a size which is too small without any perceptible downside, so it is the path taken.</li> <li>(EOF1) Whether to encode section sizes as fixed 16-bit (32-bit for container section size) values or some kind of variable length field (e.g. LEB128). We have opted for fixed size. Should this be limiting in the future, a new EOF version could change the format. Besides simplifying client implementations, not using LEB128 also greatly simplifies on-chain parsing.</li> <li>Whether or not to have more structure to the container header for all EOF versions to follow. In order to allow future formats optimized for chunking and merkleization (verkleization) it was decided to keep it generic and specify the structure only for a specific EOF version.</li> </ul> <h3 id="data-only-contracts">Data-only contracts</h3> <p>See section <a href="https://wg-eips.ritovision.com/7480/#lack-of-extdatacopy">Lack of <code>EXTDATACOPY</code> in EIP-7480</a>.</p> <h3 id="eof1-contracts-can-only-delegatecall-eof1-contracts">EOF1 contracts can only <code>DELEGATECALL</code> EOF1 contracts</h3> <p>Currently contracts can selfdestruct in three different ways (directly through <code>SELFDESTRUCT</code>, indirectly through <code>CALLCODE</code> and indirectly through <code>DELEGATECALL</code>). <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> disables the first two possibilities, however the third possibility remains. Allowing EOF1 contracts to only <code>DELEGATECALL</code> other EOF1 contracts allows the following strong statement: EOF1 contract can never be destructed. Attacks based on <code>SELFDESTRUCT</code> completely disappear for EOF1 contracts. These include destructed library contracts (e.g. Parity Multisig).</p> <h3 id="eof1-containers-have-a-size-limit">EOF1 containers have a size limit</h3> <p>Imposing an EOF-validation time limit for the size of EOF containers provides a reference limit of how large the containers should EVM implementations be able to handle when validating and processing containers. <code>MAX_INITCODE_SIZE</code> was chosen for EOF1, as it is what contract creation currently allows for.</p> <p>Given one of the main reasons for the limit is to avoid attack vectors on <code>JUMPDEST</code>-analysis, and EOF removes the need for <code>JUMPDEST</code>-analysis and introduces a cost structure for deploy-time analysis, in the future this limit could be increased or even lifted for EOF.</p> <h3 id="kind-data-could-be-0x04-not-0xff"><code>kind_data</code> could be <code>0x04</code> not <code>0xff</code></h3> <p>Putting the data section last as <code>0xff</code> has the advantage of aligning with the fact that it always comes last. We're avoiding a situation that a new section kind would need to go before the data section and break the section kind ordering. At the same time, data section being last is advantageous because it is the section which gets data appended to during contract deployment.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a breaking change given that any code starting with <code>0xEF</code> was not deployable before (and resulted in exceptional abort if executed), but now some subset of such codes can be deployed and executed successfully.</p> <p>The choice of <code>MAGIC</code> guarantees that none of the contracts existing on the chain are affected by the new rules.</p> <h2 id="security-considerations">Security Considerations</h2> <p>With the anticipated EOF extensions, the validation is expected to have linear computational and space complexity. We think that the validation cost is sufficiently covered by:</p> <ul> <li><a href="https://wg-eips.ritovision.com/3860/">EIP-3860</a> for <em>initcode</em>,</li> <li>high per-byte cost of deploying <em>code</em>.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast Andrei Maiborodahttps://github.com/gumb0 Alexey Akhunovhttps://github.com/AlexeyAkhunov Christian Reitwiessnerhttps://github.com/chriseth Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/3541/ <h2 id="abstract">Abstract</h2> <p>Disallow new code starting with the <code>0xEF</code> byte to be deployed. Code already existing in the account trie starting with <code>0xEF</code> byte is not affected semantically by this change.</p> <h2 id="motivation">Motivation</h2> <p>Contracts conforming to the EVM Object Format (EOF) are going to be validated at deploy time. In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. This will be achieved by choosing a byte sequence for the <em>magic</em> that doesn't exist in any of the already deployed contracts. To prevent the growth of the search space and to limit the analysis to the contracts existing before this fork, we disallow the starting byte of the format (the first byte of the magic).</p> <p>Should the EVM Object Format proposal not be deployed in the future, the <em>magic</em> can be used by other features depending on versioning. In the case versioning becomes obsolete, it is simple to roll this back by allowing contracts starting with the <code>0xEF</code> byte to be deployed again.</p> <h2 id="specification">Specification</h2> <p>After <code>block.number == HF_BLOCK</code> new contract creation (via create transaction, <code>CREATE</code> or <code>CREATE2</code> instructions) results in an exceptional abort if the <em>code</em>'s first byte is <code>0xEF</code>.</p> <h3 id="remarks">Remarks</h3> <p>The <em>initcode</em> is the code executed in the context of the <em>create</em> transaction, <code>CREATE</code>, or <code>CREATE2</code> instructions. The <em>initcode</em> returns <em>code</em> (via the <code>RETURN</code> instruction), which is inserted into the account. See section 7 ("Contract Creation") in the Yellow Paper for more information.</p> <p>The opcode <code>0xEF</code> is currently an undefined instruction, therefore: <em>It pops no stack items and pushes no stack items, and it causes an exceptional abort when executed.</em> This means <em>initcode</em> or already deployed <em>code</em> starting with this instruction will continue to abort execution.</p> <p>The exceptional abort due to <em>code</em> starting with <code>0xEF</code> behaves exactly the same as any other exceptional abort that can occur during <em>initcode</em> execution, i.e. in case of abort all gas provided to a <code>CREATE*</code> or create transaction is consumed.</p> <h2 id="rationale">Rationale</h2> <p>The <code>0xEF</code> byte was chosen because it resembles <strong>E</strong>xecutable <strong>F</strong>ormat.</p> <p>Contracts using unassigned opcodes are generally understood to be at risk of changing semantics. Hence using the unassigned <code>0xEF</code> should have lesser effects, than choosing an assigned opcode, such as <code>0xFD</code> (<code>REVERT</code>), <code>0xFE</code> (<code>INVALID)</code>, or <code>0xFF</code> (<code>SELFDESTRUCT</code>). Arguably while such contracts may not be very useful, they are still using valid opcodes.</p> <p>Analysis in May 2021, on <code>18084433</code> contracts in state, showed that there are 0 existing contracts starting with the <code>0xEF</code> byte, as opposed to 1, 4, and 12 starting with <code>0xFD</code>, <code>0xFE</code>, and <code>0xFF</code>, respectively.</p> <h2 id="test-cases">Test Cases</h2> <p>Each test case below may be executed in 3 different contexts:</p> <ul> <li>create transaction (no account code)</li> <li><code>CREATE</code>, with account code: <code>0x6000356000523660006000f0151560165760006000fd5b</code> (Yul code: <code>mstore(0, calldataload(0)) if iszero(create(0, 0, calldatasize())) { revert(0, 0) }</code>),</li> <li><code>CREATE2</code>, with account code: <code>0x60003560005260003660006000f5151560185760006000fd5b</code> (Yul code: <code>mstore(0, calldataload(0)) if iszero(create2(0, 0, calldatasize(), 0)) { revert(0, 0) }</code>)</li> </ul> <table><thead><tr><th>Case</th><th>Calldata</th><th>Expected result</th></tr></thead><tbody> <tr><td>deploy one byte <code>ef</code></td><td><code>0x60ef60005360016000f3</code></td><td>new contract not deployed, transaction fails</td></tr> <tr><td>deploy two bytes <code>ef00</code></td><td><code>0x60ef60005360026000f3</code></td><td>new contract not deployed, transaction fails</td></tr> <tr><td>deploy three bytes <code>ef0000</code></td><td><code>0x60ef60005360036000f3</code></td><td>new contract not deployed, transaction fails</td></tr> <tr><td>deploy 32 bytes <code>ef00...00</code></td><td><code>0x60ef60005360206000f3</code></td><td>new contract not deployed, transaction fails</td></tr> <tr><td>deploy one byte <code>fe</code></td><td><code>0x60fe60005360016000f3</code></td><td>new contract deployed, transaction succeeds</td></tr> </tbody></table> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a breaking change given new code starting with the <code>0xEF</code> byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with <code>0xEF</code> as the first byte is not executable anyway.</p> <p>While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the <code>0xEF</code> byte.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The authors are not aware of any security or DoS risks posed by this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 mineruniter969https://github.com/mineruniter969 mineruniter969mineruniter969@tutanota.com https://wg-eips.ritovision.com/3372/ <h2 id="simple-summary">Simple Summary</h2> <p>Introduce 5 new FNV primes into the ethash algorithm.</p> <h2 id="abstract">Abstract</h2> <p>This EIP is to kick current ASIC implementations out of the network to keep the Ethereum network secure and healthy by changing the <code>fnv</code> constants.</p> <h2 id="motivation">Motivation</h2> <p>ASICs provide a severe centralization risk for the Ethereum network. If we do not get rid of them, small GPU miners will be forced to exit the Ethereum mining because EIP-1559 will make them mining at a loss. Furthermore, ASIC production will be concentrated only at one or two parties, which will make the Ethereum hashrate centralized. Also, it is worth noting that Ethash ASIC machines cost 10k+ USD, while GPUs are priced less than 1000 USD.</p> <p>With GPUs, miners can switch to other mining algorithms, but with ASICs, it is impossible. Leaving everything as-is will almost certainly a very tough (from the side of miners) integration of the Ethereum 2.0.</p> <p>In short, this EIP is required to keep the Ethereum network stable and decentralized by keeping the ASIC business away.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= ETHASH11_BLKNUM</code>, activate the <code>ethash1.1</code> algorithm version.</p> <h3 id="ethash1-1">ethash1.1</h3> <p>Prior to this change, <code>fnv</code> hash function is used throughout the <code>hashimoto</code> function. <code>fnv</code> is identical for all steps, <code>ethash1.1</code> will introduce additional <code>fnvA</code>, <code>fnvB</code>, <code>fnvC</code>, <code>fnvD</code>, and <code>fnvE</code> functions. All those functions will have different FNV constants.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>// Previously used FNV prime</span></span> <span class="giallo-l"><span>#define FNV_PRIME_0 0x1000193</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>// New FNV primes</span></span> <span class="giallo-l"><span>#define FNV_PRIME_A 0x10001a7</span></span> <span class="giallo-l"><span>#define FNV_PRIME_B 0x10001ab</span></span> <span class="giallo-l"><span>#define FNV_PRIME_C 0x10001cf</span></span> <span class="giallo-l"><span>#define FNV_PRIME_D 0x10001e3</span></span> <span class="giallo-l"><span>#define FNV_PRIME_E 0x10001f9</span></span></code></pre> <p>Prior to this EIP, all parts of Ethash are using the <code>fnv</code> (hereinafter referenced as <code>fnv0</code>) function. As of the introduction of this EIP:</p> <ul> <li><code>fnvA</code> replaces <code>fnv0</code> in the DAG item selection step</li> <li><code>fnvB</code> replaces <code>fnv0</code> in the DAG item mix step</li> <li><code>fnvC(fnvD(fnvE</code> replaces <code>fnv0(fnv0(fnv0(</code> in the compress mix step</li> <li><code>fnv0</code> in the DAG generation step should remain unchanged.</li> </ul> <h2 id="rationale">Rationale</h2> <p>ASIC Miners have become a threat to the future of Ethereum and a hard fork is required to remove them from the network before additional damage is caused. EIP-3372 proposes the minimum necessary to do so and will not affect ETH stakeholders or the network like Ethash 2.0 would. The threat ASICs pose is legal, social, moral, technical, monetary, and environmental. As we continue to come closer to the merge ASICs will attack the network and the developers personally as they have done in the past because miners will always pursue profits.</p> <p>Legally and socially ASIC's have previously been a threat and a nuisance. As Hudson describes Linzhi attacked the EF and developers personally seeking to spread lies and misinformation while sending legal threats during discussions around EIP-1057. His account is <a rel="external" href="https://github.com/Souptacular/linzhi">here</a> and in his own words</p> <blockquote> <p>ASIC manufacturer Linzhi has both pressured me and told lies</p> </blockquote> <p>With their attacks and harassment on staff demonstrated in the below image: <img src="upload://n8TJsS8hEEH4DXYJ2WDzblm5qJo.jpeg" alt="" /></p> <p>Socially and morally the Ethereum community must adopt a no-tolerance policy towards personal attacks on its developers. It is only because of the core developers that Ethereum has value, the community cannot allow large companies free reign to attack them personally and must seek to protect each developer as they are a resource that keeps Ethereum viable. Multiple developers were "burned" during this event. As we accelerate the merge, it is likely that ASIC companies will repeat their actions and again attack the developers personally while pursuing legal options. This is seen not only by their actions during EIP-1057 but recent discussion around EIP-969 where legal threats from them caused the champion of that EIP to dropout and forcing me to submit this EIP anonymously. Ethereum cannot allow its actors to be threatened without consequence and this is a fight that must happen now while they are weak rather than pre-merge where they are stronger which will result in a delayed merge and hurt the value of Ethereum.</p> <p>ASICs have the greatest incentives and resources to commit bad acts because they are centralized in farms this is why Vitalik designed ETH to be ASIC-resistant because ASICs had ruined BTC's principles of decentralization. Each day their power and control over the network grows. ASICs are against the founding principles of Ethereum which promotes a decentralized system run by common people, not a single owner of large warehouses. F2Pool which consists largely of ASIC farms has become the #3 largest pool controlling around 10% of hashrate. Their farms can be viewed on their webpage. In November 2020 they were 23TH/s yet today they are 45.6 TH/s. That's a doubling in 4 months and their growth is accelerating as additional ASICs come online. ASICs are becoming a threat that will soon dominate the network and action must be taken now to head them off.</p> <p>ASICs on F2Pool have long been known to be "bad actors" on the BTC network. They are known for market manipulation and dumping BTC to manipulate prices (I could not post the source link as this is a new account). What will these ASICs do once they find out that they are about to lose millions prior to the merge? Ethereum is not just a network it is a community and they will use their financial resources and pour millions into delaying the merge as they launch legal case after legal case. They will attack the developers and the community as they seek to squeeze every last dollar.</p> <p>The reason Ethereum was founded on the principle of being anti-ASIC is because Vitalik had seen the damage ASICs had caused to the BTC network as they pursued profits rather than the betterment of the network. GPU miners are decentralized and disorganized which makes them a much lower threat than warehouses under one central corporation that is outside the legal system and thus cannot be held to account for bad acts.</p> <p>EIP-3372 also works to protect the environment. Post merge, gpus will go into the secondary market or move to other coins. However, ASICs will become junk. As more ASICs are produced, Ethereum increases its environmental footprint. These ASICs are being mass produced in greater numbers despite it being public that the merge is being accelerated. It is clear that these ASIC manufacturers and buyers must either be ignorant of the accelerated merge or plan to delay it. Because they dump their ETH they have no stake in the network except the money they can squeeze from it and if by making trouble they can give themselves another day than they will do it.</p> <p>Finally, Ethereum has always sought to pursue "minimum issuance". By reducing the amount of miners that can pose a threat to the network, Ethereum also decreases how much it needs to pay for protection. Some EIP's are being prepared to increase miner incomes post EIP-1559 should a threat appear. EIP-3372 eliminates the need to pay more for security and allows miners to be paid less without compromising the network's security. As we go forward closer to the merge, the community must reduce attack vectors so as to reduce the cost of the merge itself and maximize the security of the network. The community already pays too much for protection and by reducing threats we can reduce this cost. ASIC warehouse farms are dumping all the ETH they make which is suppressing the price of ETH. Although rare, several individual GPU miners are taking part in staking or have gone on to join the community in development or our financial endeavors. They thus are more valuable to the community than a warehouse of future junk. There is no need for the Ethereum community to continue to pay for soon-to-be obsolete hardware that will end up in landfills.</p> <h3 id="technical-overview">Technical Overview</h3> <p>Ethash 1.1 will replace the only FNV prime with five new primes at the stage of the hash computation. The prime used for the DAG generation is remained unchanged, while all others are be changed. This will not prevent ASIC companies from creating new ASICs that adapt but so close to the merge it is unlikely they will do so, and even if they do they are unlikely to be able to produce enough to again be a threat. The choice of FNV constants are based on the formal specification that is available on <a rel="external" href="https://ietf">https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1</a></p> <p>We apologize for the delay in submitting the justification for this EIP. As the community may or may not be aware, the original champion was forced to stop working on this EIP due to legal attacks from ASIC companies. It has taken us this long to review his work and find a new champion. To protect ourselves we are submitting this anonymously and would request the community's aid in our endeavor to maintain our anonymity and some lenience given the circumstances and threats we face pursuing this EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Mining hardware that is optimized for ethash may no longer work if the <code>fnv</code> constants are baked into the hardware and cannot be changed.</p> <h2 id="test-vectors">Test Vectors</h2> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">first</span><span class="z-support">&quot;</span><span>:</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">4242424242424242</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">mixHash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">aa6a928db9b548ebf20fc9a74e9200321426f1c2db1571636cdd3a33eb162b36</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">header</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">f901f3a00000000000000000000000000000000000000000000000000000000000000000a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347940000000000000000000000000000000000000000a09178d0f23c965d81f0834a4c72c6253ce6830f4022b1359aaebfc1ecba442d4ea056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421b90100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008302000080830f4240808080a058f759ede17a706c93f13030328bcea40c1d1341fb26f2facd21ceb0dae57017884242424242424242</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">seed</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0000000000000000000000000000000000000000000000000000000000000000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">result</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">3972318778d2af9d3c5c3dfc463bc2a5ebeebd1a7a04392708ff94d29aa18c5f</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">cache_size</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> 16776896</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">full_size</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> 1073739904</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">header_hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2a8de2adf89af77358250bf908bf04ba94a6e8c3ba87775564a41d269a05e4ce</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">cache_hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">35ded12eecf2ce2e8da2e15c06d463aae9b84cb2530a00b932e4bbc484cde353</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">second</span><span class="z-support">&quot;</span><span>:</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">307692cf71b12f6d</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">mixHash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">4a2ef8287dc21f5def0d4e9694208c56e574b1692d7b254822a3f4704d8ad1ba</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">header</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">f901f7a01bef91439a3e070a6586851c11e6fd79bbbea074b2b836727b8e75c7d4a6b698a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d4934794ea3cb5f94fa2ddd52ec6dd6eb75cf824f4058ca1a00c6e51346be0670ce63ac5f05324e27d20b180146269c5aab844d09a2b108c64a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421b90100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008302004002832fefd880845511ed2a80a0e55d02c555a7969361cf74a9ec6211d8c14e4517930a00442f171bdb1698d17588307692cf71b12f6d</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">seed</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0000000000000000000000000000000000000000000000000000000000000000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">result</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">5ab98957ba5520d4e367080f442e37a047cfd9d2857b6e00dd12d82900d108a6</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">cache_size</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> 16776896</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">full_size</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> 1073739904</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">header_hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">100cbec5e5ef82991290d0d93d758f19082e71f234cf479192a8b94df6da6bfe</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">cache_hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">35ded12eecf2ce2e8da2e15c06d463aae9b84cb2530a00b932e4bbc484cde353</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues with this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Query0xhttps://github.com/Query0x https://wg-eips.ritovision.com/3374/ <h2 id="simple-summary">Simple Summary</h2> <p>Sets block reward to 3 and reduces it to 1 linearly over the course of about 1 year.</p> <h2 id="abstract">Abstract</h2> <p>Sets the block reward to 3 ETH and then incrementally decreases it every block for 2,362,000 blocks (approximately 1 year) until it reaches 1 ETH.</p> <h2 id="motivation">Motivation</h2> <p>Unnecessarily abrupt changes to the Ethereum ecosystem cause disruption and disharmony resulting in the disenfranchisement of community members while undermining stability and confidence. While moves from Proof-of-Work to Proof-of-Stake will undoubtedly cause friction between those community members vested in either, all benefit from a measured, predictable transition.</p> <p>This proposal:</p> <ol> <li>Is issuance neutral over 1 year, and reduces issuance beyond that.</li> <li>Sets an initial block reward of 3;</li> <li>Introduces an ongoing, predictable reduction in future mining rewards down to 1, effectively "sunsetting" POW and codifying the move to POS;</li> <li>Reduces economic incentives for continued development of ASICs;</li> <li>Allows the impacts of decreasing miner rewards to be measured and monitored rather than relying on conjecture and game theory, so adjustments can be made if necessary.</li> </ol> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <ul> <li><code>TRANSITION_START_BLOCK_NUMBER: TBD</code></li> <li><code>TRANSITION_DURATION: 2_362_000</code> // (about one year)</li> <li><code>TRANSITION_END_BLOCK_NUMBER: FORK_BLOCK_NUMBER + TRANSITION_DURATION</code></li> <li><code>STARTING_REWARD: 3_000_000_000_000_000_000</code></li> <li><code>ENDING_REWARD: 1_000_000_000_000_000_000</code></li> <li><code>REWARD_DELTA: STARTING_REWARD - ENDING_REWARD</code></li> </ul> <h3 id="block-reward">Block Reward</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> TRANSITION_END_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> ENDING_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> ==</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> STARTING_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> STARTING_REWARD</span><span class="z-keyword"> -</span><span class="z-constant"> REWARD_DELTA</span><span class="z-keyword"> *</span><span class="z-constant"> TRANSITION_DURATION</span><span class="z-keyword"> /</span><span> (</span><span>block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>Picking starting and ending block reward values that are equidistant from the current block reward rate of 2 ensures the impact of this EIP will be issuance neutral over the one year time frame. Temporarily raising the block reward to 3 blunts the initial impact of a sudden miner revenue decrease and the continual reductions thereafter codify Ethereum's move to POS by increasingly disincentivizing POW. Importantly, this approach moderates the rate of change so impacts and threats can be measured and monitored.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues with the introduction of this EIP.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues with the introduction of this EIP.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0.</p> 2021-03-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Philippe Castonguayhttps://github.com/PhABC https://wg-eips.ritovision.com/3382/ <h2 id="simple-summary">Simple Summary</h2> <p>Hardcode the block gas limit to <code>12,500,000</code> gas per block.</p> <h2 id="abstract">Abstract</h2> <p>Updates the block validation rules such that a block is invalid if the <code>gas_limit</code> header field is not equal to <code>12,500,000</code>.</p> <h2 id="motivation">Motivation</h2> <p>Both Ethereum's Proof of Work and Proof of Stake designs assume that block producers are financially rational, but does not assume block producers to be benevolent. There is one exception however, and it is when block producers choose the gas limit of a block where it is assumed that block producers care about the long term health and decentralisation of the chain. Indeed, the block gas limit is one of the only parameters in Ethereum that is not dictated by node consensus, but instead is chosen by block producers. This decision was initially made to allow urgent changes in the block gas limit if necessary. Both drastically increasing or decreasing this parameter could have serious consequences that may not be desired. It is therefore a critical parameter that should require node consensus to avoid any sudden harmful change imposed by a small number of actors on the rest of the network.</p> <h2 id="specification">Specification</h2> <p>Refer to <code>gasLimit</code> as <code>gasTarget</code> post EIP-1559.</p> <h3 id="added-consensus-constraint">Added Consensus Constraint</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, the <code>header.gasLimit</code> <strong>MUST</strong> be equal to <code>BLOCK_GAS_LIMIT</code>, where <code>BLOCK_GAS_LIMIT</code> is a hardcoded constant set to <code>12,500,000</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="keeping-gaslimit-in-block-headers">Keeping gasLimit in Block Headers</h3> <p>While it would be possible to remove the <code>gasLimit</code> field from block headers, it would change the data structure to be hashed, which could lead to unintended consequences. It is therefore easier to leave the gasLimit as part of block headers.</p> <h3 id="chosen-gas-limit">Chosen Gas Limit</h3> <p>The <code>12,500,000</code> value is being proposed as it's the current block gas limit as of time of writing this EIP. The actual amount could be altered with a subsequent EIP to avoid deviating from the core intent of this EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is backward compatible.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Rapid changes to the gas limit will likely be more difficult to execute, which could be problematic if an urgent situation arise that required changing the gas limit.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Michael D. Carterhttps://github.com/BitsBeTrippin https://wg-eips.ritovision.com/3368/ <h2 id="simple-summary">Simple Summary</h2> <p>Changes the block reward paid to proof-of-work (POW) miners to 3 ETH from existing 2 ETH and starts a decay schedule for next two years to 1 ETH Block Reward.</p> <h2 id="abstract">Abstract</h2> <p>Set the block reward to 3 ETH and then decrease it slightly every block for 4,724,000 blocks (approximately 2 years) until it reaches 1 ETH.</p> <h2 id="motivation">Motivation</h2> <p>A sudden drop in PoW mining rewards could result in a sudden precipitous decrease in mining profitability that may drive miners to auction off their hashrate to the highest bidder while they figure out what to do with their now "worthless" hardware. If enough hashrate is auctioned off in this way at the same time, an attacker will be able to rent a large amount of hashing power for a short period of time at relatively low cost vs. reward and potentially attack the network. By setting the block reward to X (where X is enough to offset the sudden profitability decrease) and then decreasing it over time to Y (where Y is a number below the sudden profitability decrease), we both avoid introducing long term inflation while at the same time spreading out the rate that individual miners cross into a transitional range. This approach offers a higher level of confidence and published schedule of yield, while allowing mining participants time to gracefully repurpose/sell their hardware. This greatly increases ethereums PoW security by keeping incentives aligned to ethereum and not being force projected to short term brokerage for the highest bidder. Additionally the decay promotes a known schedule of a deflationary curve, aligning to the overall Minimal Viable Issuance directive aligned to a 2 year transition schedule for Proof of Stake, consensus replacement of Proof of Work. Security is paramount in cryptocurrency blockchains and the risk to a 51% non-resistant chain is real. The scope of Ethereum's current hashrate has expanded to hundreds of thousands of new participants and over 2.5x original ATH hashrate/difficulty. While the largest by hashrate crypto is bitcoin, ethereum is not far behind the total network size in security aspects. This proposal is focused to keep that superiority in security one of the key aspects.</p> <h2 id="specification">Specification</h2> <p>Adjust block, uncle, and nephew rewards</p> <h3 id="constants">Constants</h3> <ul> <li><code>TRANSITION_START_BLOCK_NUMBER: TBD</code></li> <li><code>TRANSITION_DURATION: 4_724_000</code> (about two years)</li> <li><code>TRANSITION_END_BLOCK_NUMBER: FORK_BLOCK_NUMBER + TRANSITION_DURATION</code></li> <li><code>STARTING_REWARD: 3_000_000_000_000_000_000</code></li> <li><code>ENDING_REWARD: 1_000_000_000_000_000_000</code></li> <li><code>REWARD_DELTA: STARTING_REWARD - ENDING_REWARD</code></li> </ul> <h3 id="block-reward">Block Reward</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> TRANSITION_END_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> ENDING_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> =</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> STARTING_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &gt;</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> STARTING_REWARD</span><span class="z-keyword"> -</span><span class="z-constant"> REWARD_DELTA</span><span class="z-keyword"> *</span><span class="z-constant"> TRANSITION_DURATION</span><span class="z-keyword"> /</span><span> (</span><span>block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> TRANSITION_START_BLOCK_NUMBER</span><span>)</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>2 years was chosen because it gives miners sufficient time to find alternative uses for their hardware and/or get their hardware back out onto the open market (e.g., in the form of gaming GPUs) without flooding the market suddenly. This proposal should ONLY be considered as a last resort as something we have in our pocket should the "network need to attract hashing power quickly and then bleed it off over time" rather than "something that is scheduled to be included in X hard fork" ; Recommendation to have in a fast track state, but NOT deployed to mainnet unless needed.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues with the introduction of this EIP.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues with the introduction of this EIP.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0.</p> 2021-03-07T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/3338/ <h2 id="abstract">Abstract</h2> <p>Limit account nonce to be between <code>0</code> and <code>2^52</code>.</p> <h2 id="motivation">Motivation</h2> <p>Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized way.</p> <p>Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals.</p> <p>Lastly, this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= FORK_BLOCK</code> introduce two new restrictions:</p> <ol> <li>Consider any transaction invalid, where the nonce exceeds <code>2^52</code>.</li> <li>The <code>CREATE</code> instruction to abort with an exceptional halt, where the account nonce is <code>2^52</code>.</li> </ol> <h2 id="rationale">Rationale</h2> <ol> <li> <p>It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least <code>21000 * (2^64-1) = 387_381_625_547_900_583_915_000</code> gas.</p> </li> <li> <p>It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of <code>2^20</code> in order to differentiate transactions from mainnet transactions. This mode of replay protection is out of fashion since <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> introduced a more elegant way using chain identifiers.</p> </li> <li> <p>Most clients already consider the nonce field to be 64-bit, such as go-ethereum.</p> </li> <li> <p>All integer values &lt;= 2^52 can be encoded in a 64-bit floating point without any loss of precision, making this value easy to work with in languages that only have floating point number support.</p> </li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>While this is a breaking change, no actual effect should be visible:</p> <ol> <li>There is no account in the state currently which would have a nonce exceeding that value. As of November 2020, the account <code>0xea674fdde714fd979de3edf0f56aa9716b898ec8</code> is responsible for the highest account nonce at approximately 29 million.</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonhttps://github.com/arachnid https://wg-eips.ritovision.com/3336/ <h2 id="simple-summary">Simple Summary</h2> <p>Changes the memory model for the EVM to use pagination.</p> <h2 id="abstract">Abstract</h2> <p>Presently, the EVM charges for memory as a linear array starting at address 0 and extending to the highest address that has been read from or written to. This suffices for simple uses, but means that compilers have to generate programs that use memory compactly, which leads to wasted gas with reallocation of memory elements, and makes some memory models such as separate heap and stack areas impractical. This EIP proposes changing to a page-based billing model, which adds minimal complexity to implementations, while providing for much more versatility in EVM programs.</p> <h2 id="motivation">Motivation</h2> <p>Most modern computers implement "virtual memory" for userspace programs, where programs have access to a large address space, with pages of RAM that are allocated as needed by the OS. This allows them to distribute data throughout memory in ways that minimises the amount of reallocation and copying that needs to go on, and permits flexible use of memory for data with different lifetimes. Implementing a simple version of paged memory inside the EVM will provide the same flexibility to compilers targeting the EVM.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> <tr><td><code>PAGE_BITS</code></td><td>10</td></tr> <tr><td><code>PAGE_BASE_COST</code></td><td>96</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <h3 id="changes-to-memory-allocation-in-evm-implementations">Changes to memory allocation in EVM implementations</h3> <p>Memory is now allocated in pages of <code>2**PAGE_BITS</code> bytes each. The most significant <code>256 - PAGE_BITS</code> bits of each memory address denote the page number, while the least significant <code>PAGE_BITS</code> bits of the memory address denote the location in the page. Pages are initialized to contain all zero bytes and allocated when the first byte from a page is read or written.</p> <p>EVM implementations are encouraged to store the pagetable as an associative array (eg, hashtable or dict) mapping from page number to an array of bytes for the page.</p> <h3 id="changes-to-memory-expansion-gas-cost">Changes to memory expansion gas cost</h3> <p>Presently, the total cost to extend the memory to <code>a</code> words long is <code>Cmem(a) = 3 * a + floor(a ** 2 / 512)</code>. If the memory is already <code>b</code> words long, the incremental cost is <code>Cmem(a) - Cmem(b)</code>. <code>a</code> is the number of words required to cover the range from memory address 0 to the last word that has been read or written by the EVM.</p> <p>Under this EIP, we define a new memory cost function, based on the number of allocated pages. This function is <code>Cmem'(p) = max(PAGE_BASE_COST * (p - 1) + floor(2 * (p - 1) ** 2), 0)</code>. As above, if the memory already contains <code>q</code> pages, the incremental cost is <code>Cmem'(p) - Cmem'(q)</code>.</p> <h3 id="changes-to-mload-and-mstore">Changes to <code>MLOAD</code> and <code>MSTORE</code></h3> <p>Loading a word from memory or storing a word to memory requires instantiating any pages that it touches that do not already exist, with the resulting gas cost as described above. If the word being loaded or stored resides in a single page, the gas cost remains unchanged at 3 gas. If the word being loaded spans two pages, the cost is 6 gas.</p> <h3 id="changes-to-other-memory-touching-opcodes">Changes to other memory-touching opcodes</h3> <p><code>CALLDATACOPY</code>, <code>CODECOPY</code>, <code>EXTCODECOPY</code>, <code>CALL</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>, <code>STATICCALL</code>, <code>CREATE</code>, <code>MSTORE8</code> and any other opcodes that read or write memory are modified as follows:</p> <ul> <li>Any page they touch for reading or writing is instantiated if it is not already.</li> <li>Memory expansion gas is charged as described above.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="memory-expansion-gas-cost">Memory expansion gas cost</h3> <p>The new gas cost follows the same curve as the previous one, while ensuring that the new gas cost is always less than or equal to the previous cost. This prevents existing programs that make assumptions about memory allocation gas costs from resulting in errors, without unduly discounting memory below what it costs today. Intuitively, a program that uses up to a page boundary pays for one page less than they would under the old model, while a program that uses one word more than a page boundary pays for one word less than they would under the old model.</p> <p>We believe that this incremental reduction will not have a significant impact on the effective gas limit, as it gets proportionally smaller as programs use more RAM.</p> <h3 id="additional-cost-for-mloads-and-mstores-spanning-two-pages">Additional cost for MLOADs and MSTOREs spanning two pages</h3> <p>Loading or storing data spanning two memory pages requires more work from the EVM implementation, which must split the word at the page boundary and update the two (possibly disjoint) pages. Since we cannot guarantee loads and stores in existing EVM programs are page-aligned, we cannot prohibit this behaviour for efficiency. Instead, we propose treating each as two loads or stores for gas accounting purposes. This discourages the use of this functionality, and accounts for the additional execution cost, without prohibiting it outright.</p> <p>This will result in additional gas costs for any programs that perform these operations. We believe this to be minimal, and hope to do future analysis to confirm this.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The new function for memory expansion gas cost is designed specifically to avoid backwards compatibility issues by always charging less than or equal to the amount the current EVM would charge. Under some circumstances existing programs will be charged more for MLOADs and MSTOREs that span page boundaries as described above; we believe these changes will affect a minimum of programs and have only a small impact on their gas consumption.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>Potential CPU DoS issues arising from additional work done under the new model are alleviated by charging more for non-page-aligned reads and writes. Charges for memory expansion asymptotically approach those currently in force, so this change will not permit programs to allocate substantially more memory than they can today.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonhttps://github.com/arachnid https://wg-eips.ritovision.com/3337/ <h2 id="simple-summary">Simple Summary</h2> <p>Introduces four new opcodes for loading data from and storing data to memory offset by a frame pointer.</p> <h2 id="abstract">Abstract</h2> <p>This EIP introduces four new opcodes, <code>MLOADFP</code>, <code>MSTOREFP</code>, <code>GETFP</code> and <code>SETFP</code> that allow for more efficient memory access offset by a user-controlled quantity called the "frame pointer". This permits compilers to more efficiently offload ephemeral data such as local variables to memory instead of the EVM's evaluation stack, which has a number of benefits, including the effective elimination of restrictions on the number of local variables in a function.</p> <h2 id="motivation">Motivation</h2> <p>In most commonly used VMs, ephemeral data such as local variables, function arguments, and return addresses is stored in a region of memory called the stack. In contrast to the EVM's evaluation stack, this area of memory is randomly accessible, and thus can store an arbitrary amount of data, which can be referenced from anywhere they remain in scope. Although this model is possible in the current EVM design, it is made difficult by the linear model of memory (addressed in <a href="https://wg-eips.ritovision.com/3336/">EIP-3336</a>) and by the lack of opcodes for relative memory access commonly found in other architectures. This EIP proposes new opcodes that permit this form of memory use, without imposing undue burden on EVM implementers or on runtime efficiency.</p> <p>In the current EVM model, a compiler wishing to use this pattern would have to store the frame pointer - which points to the start or end of the current memory stack frame - in memory, and load it each time they wish to reference it. For example, loading a value from memory offset by the frame pointer would require the following sequence of operations:</p> <table><thead><tr><th>Opcode</th><th>Gas used</th></tr></thead><tbody> <tr><td><code>PUSHn x</code></td><td>3</td></tr> <tr><td><code>PUSH1 0</code></td><td>3</td></tr> <tr><td><code>MLOAD</code></td><td>3</td></tr> <tr><td><code>ADD</code></td><td>3</td></tr> <tr><td><code>MLOAD</code></td><td>3</td></tr> </tbody></table> <p>This consumes a total of 15 gas, and takes up at least 7 bytes of bytecode each time it is referenced. In contrast, after this EIP, the equivalent sequence of operations is:</p> <table><thead><tr><th>Opcode</th><th>Gas used</th></tr></thead><tbody> <tr><td><code>PUSH1 x</code></td><td>3</td></tr> <tr><td><code>MLOADFP</code></td><td>3</td></tr> </tbody></table> <p>This consumes only 6 gas, and takes at least 3 bytes of bytecode. The effort required from the EVM implementation is equivalent, costing only one extra addition operation over a regular <code>MLOAD</code>. The alternative of storing values on the stack, which requires 3 gas and 1 byte of bytecode for a <code>DUPn</code> operation, but it is now at most twice as efficient rather than 5 times as efficient, making storing values in memory a viable alternative.</p> <p>Likewise, before this EIP a frame-pointer relative store requires the following sequence of operations:</p> <table><thead><tr><th>Opcode</th><th>Gas used</th></tr></thead><tbody> <tr><td><code>PUSHn x</code></td><td>3</td></tr> <tr><td><code>PUSH1 0</code></td><td>3</td></tr> <tr><td><code>MLOAD</code></td><td>3</td></tr> <tr><td><code>ADD</code></td><td>3</td></tr> <tr><td><code>MSTORE</code></td><td>3</td></tr> </tbody></table> <p>This consumes 15 gas and at least 7 bytes of bytecode. After this EIP, the equivalent sequence of operations is:</p> <table><thead><tr><th>Opcode</th><th>Gas used</th></tr></thead><tbody> <tr><td><code>PUSHn x</code></td><td>3</td></tr> <tr><td><code>MSTOREFP</code></td><td>3</td></tr> </tbody></table> <p>Consuming only 6 gas and at least 3 bytes of bytecode, while once again only requiring EVM implementations to do one extra addition operation. The alternative of storing values on the stack requires 6 gas and 2 bytes of bytecode for the sequence <code>SWAPn POP</code>, making it no more efficient than memory storage.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <h3 id="frame-pointer">Frame pointer</h3> <p>A new EVM internal state variable called the "frame pointer" is introduced. This is a signed integer that starts at 0.</p> <h3 id="setfp-opcode"><code>SETFP</code> opcode</h3> <p>A new opcode, <code>SETFP</code> is introduced with value <code>0x5c</code>. This opcode costs <code>G_low</code> (3 gas) and takes one argument from the stack. The argument is stored as the new value of the frame pointer.</p> <h3 id="getfp-opcode"><code>GETFP</code> opcode</h3> <p>A new opcode, <code>GETFP</code> is introduced with value <code>0x5d</code>. This opcode costs <code>G_low</code> (3 gas) and takes no arguments. It takes the current value of the frame pointer and pushes it to the stack.</p> <h3 id="mloadfp-opcode"><code>MLOADFP</code> opcode</h3> <p>A new opcode <code>MLOADFP</code> is introduced with value <code>0x5e</code>. This opcode acts in all ways identical to <code>MLOAD</code>, except that the value of the frame pointer is added to the address before loading data from memory. An attempt to load data from a negative address should be treated identically to an invalid opcode, consuming all gas and reverting the current execution context.</p> <h3 id="mstorefp-opcode"><code>MSTOREFP</code> opcode</h3> <p>A new opcode <code>MSTOREFP</code> is introduced with value <code>0x5f</code>. This opcode acts in all ways identical to <code>MSTORE</code>, except that the value of the frame pointer is added to the address before storing data to memory. An attempt to store data to a negative address should be treated identically to an invalid opcode, consuming all gas and reverting the current execution context.</p> <h2 id="rationale">Rationale</h2> <h3 id="cost-of-new-opcodes">Cost of new opcodes</h3> <p>The cost of the new opcodes <code>MLOADFP</code> and <code>MSTOREFP</code> reflects the cost of <code>MLOAD</code> and <code>MSTORE</code>. They are generally equivalent in cost with the exception of an extra addition operation, which imposes negligible cost.</p> <p>The cost of the new opcodes <code>SETFP</code> and <code>GETFP</code> is based on other common low-cost opcodes such as <code>PUSH</code> and <code>POP</code>.</p> <h3 id="absence-of-mstore8fp">Absence of <code>MSTORE8FP</code></h3> <p><code>MSTORE8FP</code> opcode was not included because it is expected that it would be used infrequently, and there is a desire to minimise the size of the instruction set and to conserve opcodes for future use.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP exclusively introduces new opcodes, and as a result should not impact any existing programs unless they operate under the assumption that these opcodes are undefined, which we believe will not be the case.</p> <h2 id="security-considerations">Security Considerations</h2> <p>DoS risks are mitigated by correct pricing of opcodes to reflect current execution costs. No other security considerations pertain to this EIP.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-03-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Justice Hudsonhttps://github.com/jchancehud https://wg-eips.ritovision.com/3332/ <h2 id="simple-summary">Simple Summary</h2> <p>An opcode for getting the median gas price of the parent block.</p> <h2 id="abstract">Abstract</h2> <p>Adds <code>MEDGASPRICE (0x46)</code> opcode that returns the median gas price for the parent block.</p> <h2 id="motivation">Motivation</h2> <p>With the emergence of rollups as core mechanisms in scaling Ethereum there are a number of common transactions that can be front-run. Optimistic rollups rely on the submission of fraud proofs to maintain the integrity of their systems. As a result actors submitting fraud proofs typically receive a financial reward for doing so. This opens a trivial front-running strategy of watching the mempool for fraud proof submissions and copying such transactions with a much higher gas price to reap the reward. Such front-runners do not perform validation independently and de-incentivize others from performing validation. Adding a mechanism enforcing an upper bound on gas prices for a transaction could be an effective defense against such front-running attacks.</p> <p>Consider a smart contract that wants to implement a first come first serve mechanism. Such a mechanism must defeat the inherently pay-to-win nature of the gas price market. Enforcing a maximum gas price for a transaction relies on the fact that transactions of the same gas price are generally processed in a first in first out way by Ethereum miners. A contract currently has few options for setting a max gas price:</p> <ul> <li>Set a constant value at a reasonable rate given the current gas prices</li> <li>Allow an individual or group of individuals to adjust a max gas price over time</li> </ul> <p>More elaborate schemes could likely be constructed but all would involve storing gas price information on chain increasing the number of transactions and costing Ether.</p> <p>Given a median gas price opcode a contract can set a maximum gas price as a function of the last blocks gas price. This can easily be implemented using a strategy such as the following:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>// Assume that block.medgasprice is bound to MEDGASPRICE (0x46)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function submitFraudProof(bytes calldata proof) public {</span></span> <span class="giallo-l"><span> require(tx.gasprice &lt;= maxGasPrice());</span></span> <span class="giallo-l"><span> // process the fraud proof and provide a reward (if valid)</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function maxGasPrice() public view returns (uint) {</span></span> <span class="giallo-l"><span> return 3 * block.medgasprice;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Given the contract implementation above a client would simply call <code>maxGasPrice</code> to determine the gas price to use when submitting a fraud proof. This particular implementation allows up to 3x the median gas price of the last block to be used.</p> <h3 id="forwards-compatibility">Forwards Compatibility</h3> <p><a rel="external" href="https://eips.ethereum.org/EIPS/eip-1559">EIP-1559</a> plans to change the fee market in a number of ways. Most notably is the creation of a base fee that is burned. In this context an "inclusion fee" still exists as a part of the total fee. Consider the following two cases:</p> <h4 id="block-sizes-are-increasing-all-available-gas-is-being-consumed">Block sizes are increasing (all available gas is being consumed)</h4> <p>In this case there will be bidding contention in the inclusion fee to incentivize miners to include transactions. A median gas price operator would still be helpful as an attacker could supply a high inclusion fee to bump honest transactions.</p> <h4 id="block-sizes-are-decreasing-excess-gas-is-available">Block sizes are decreasing (excess gas is available)</h4> <p>In this case an attacker could specify a high inclusion fee to incentivize miners to include their transaction early in the block. Miners are incentivized to do so as including expensive transactions first reduces the risk of a revert (and partial refund) occurring.</p> <p>Given these two cases this EIP seems relevant in the context of EIP-1559.</p> <p>Post EIP-1559 <code>MEDGASPRICE (0x46)</code> should return the median <code>effective_gas_price</code> of the previous block.</p> <p><a rel="external" href="https://eips.ethereum.org/EIPS/eip-3198">EIP-3198</a> is required for the above strategies to be implemented. With the inclusion of <code>BASEFEE (0x48)</code> a contract can subtract the <code>base_fee_per_gas</code> from the <code>effective_gas_price</code> to determine the inclusion fee per gas being paid for the transaction and thus implement an upper bound.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= TBD</code>, add a new opcode <code>MEDGASPRICE (0x46)</code>:</p> <p>Pushes the median gas price of the parent block onto the stack.</p> <p>| Op | Input | Output | Cost | |:----: |:-----: |:------: |:----: | | 0x46 | 0 | 1 | 8 |</p> <h2 id="rationale">Rationale</h2> <p>Having access to the current gas price economy allows contracts to implement more robust and automated logic surrounding acceptable transaction gas prices.</p> <h3 id="naming-note">Naming note</h3> <p>The name <code>MEDGASPRICE</code> was chosen because the median gas price of the network can only be calculated from the latest complete block. Thus transactions being executed should expect the median gas price to be calculated from the previous block.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backwards incompabitility issues.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The strategy described for preventing front-running by setting an upper bound on the gas price of transactions has a few caveats:</p> <ol> <li>It relies on miners being impartial. Reordering transactions with the same gas price is a trivial means of defeating this strategy.</li> <li>The value returned by <code>MEDGASPRICE (0x46)</code> may fluctuate rapidly between blocks. If a transaction is not included immediately it may either fail (if the gas price drops) or become vulnerable to front-running (if the gas price increases).</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-02-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/3298/ <h2 id="simple-summary">Simple Summary</h2> <p>Remove gas refunds for SSTORE and SELFDESTRUCT.</p> <h2 id="motivation">Motivation</h2> <p>Gas refunds for SSTORE and SELFDESTRUCT were originally introduced to motivate application developers to write applications that practice "good state hygiene", clearing storage slots and contracts that are no longer needed. However, they are not widely used for this, and poor state hygiene continues to be the norm. It is now widely accepted that the only solution to state growth is some form of <a rel="external" href="https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/state_size_management">statelessness or state expiry</a>, and if such a solution is implemented, then disused storage slots and contracts would start to be ignored automatically.</p> <p>Gas refunds additionally have multiple harmful consequences:</p> <ul> <li>Refunds give rise to <a rel="external" href="https://gastoken.io/">GasToken</a>. GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a "battery" to save up gas) and inefficiently clogging blockchain gas usage</li> <li>Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction's gas used). This is <a rel="external" href="https://notes.ethereum.org/@vbuterin/eip_1559_spikes">not fatal</a>, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>TBD</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <p>Do not apply the <code>refund</code>.</p> <p>The description above is sufficient to describe the change, but for the sake of clarity we enumerate all places where gas refunds are currently used and which should/could be removed within a node implementation.</p> <ol> <li> <p>Remove all use of the "refund counter" in SSTORE gas accounting, as defined in <a rel="external" href="https://eips.ethereum.org/EIPS/eip-2200">EIP 2200</a>. Particularly:</p> <ul> <li>If a storage slot is changed and the <em>current value</em> equals the <em>original value</em>, but does not equal the <em>new value</em>, <code>SSTORE_RESET_GAS</code> is deducted (plus <code>COLD_SLOAD_COST</code> if <a rel="external" href="https://eips.ethereum.org/EIPS/eip-2929#sstore-changes">prescribed by EIP 2929 rules</a>), but no modifications to the refund counter are made.</li> <li>If a storage slot is changed and the <em>current value</em> equals neither the <em>new value</em> nor the <em>original value</em> (regardless of whether or not the latter two are equal), <code>SLOAD_GAS</code> is deducted (plus <code>COLD_SLOAD_COST</code> if <a rel="external" href="https://eips.ethereum.org/EIPS/eip-2929#sstore-changes">prescribed by EIP 2929 rules</a>), but no modifications to the refund counter are made.</li> </ul> </li> <li> <p>Remove the <code>SELFDESTRUCT</code> refund.</p> </li> </ol> <h2 id="rationale">Rationale</h2> <p>A full removal of refunds is the simplest way to solve the issues with refunds; any gains from partial retention of the refund mechanism are not worth the complexity that that would leave remaining in the Ethereum protocol.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Refunds are currently only applied <em>after</em> transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.</p> <p><a rel="external" href="https://gastoken.io/">GasToken</a> in particular will become valueless. DeFi arbitrage bots, which today frequently use either established GasToken schemes or a custom alternative to reduce on-chain costs, would benefit from rewriting their code to remove calls to these no-longer-functional gas storage mechanisms.</p> <h2 id="implementation">Implementation</h2> <p>An implementation can be found here: https://gist.github.com/holiman/460f952716a74eeb9ab358bb1836d821#gistcomment-3642048</p> <h2 id="test-case-changes">Test case changes</h2> <ul> <li>The "original", "1st", "2nd", "3rd" columns refer to the value of storage slot 0 before the execution and after each SSTORE.</li> <li>The "Berlin (cold)" column gives the post-Berlin (EIP 2929) gas cost assuming the storage slot had not yet been accessed.</li> <li>The "Berlin (hot)" column gives the post-Berlin gas cost assuming the storage slot has already been accessed.</li> <li>The "Berlin (hot) + norefund" column gives the post-Berlin gas cost assuming the storage slot has already been accessed, <strong>and assuming this EIP has been implemented</strong>.</li> </ul> <p>Gas costs are provided with refunds subtracted; if the number is negative this means that refunds exceed gas costs. The 50% refund limit is not applied (due to the implied assumption that this code is only a small fragment of a much larger execution).</p> <p>If refunds were to be removed, this would be the comparative table</p> <table><thead><tr><th>Code</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th><th>Istanbul</th><th>Berlin (cold)</th><th>Berlin (hot)</th><th>Berlin (hot)+norefund</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>0</td><td>0</td><td>0</td><td></td><td>1612</td><td>2312</td><td>212</td><td>212</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>0</td><td>0</td><td>1</td><td></td><td>20812</td><td>22212</td><td>20112</td><td>20112</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>0</td><td>1</td><td>0</td><td></td><td>1612</td><td>2312</td><td>212</td><td>20112</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>0</td><td>1</td><td>2</td><td></td><td>20812</td><td>22212</td><td>20112</td><td>20112</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>0</td><td>1</td><td>1</td><td></td><td>20812</td><td>22212</td><td>20112</td><td>20112</td></tr> <tr><td><code>0x60006000556000600055</code></td><td>1</td><td>0</td><td>0</td><td></td><td>-9188</td><td>-9888</td><td>-11988</td><td>3012</td></tr> <tr><td><code>0x60006000556001600055</code></td><td>1</td><td>0</td><td>1</td><td></td><td>1612</td><td>2312</td><td>212</td><td>3012</td></tr> <tr><td><code>0x60006000556002600055</code></td><td>1</td><td>0</td><td>2</td><td></td><td>5812</td><td>5112</td><td>3012</td><td>3012</td></tr> <tr><td><code>0x60026000556000600055</code></td><td>1</td><td>2</td><td>0</td><td></td><td>-9188</td><td>-9888</td><td>-11988</td><td>3012</td></tr> <tr><td><code>0x60026000556003600055</code></td><td>1</td><td>2</td><td>3</td><td></td><td>5812</td><td>5112</td><td>3012</td><td>3012</td></tr> <tr><td><code>0x60026000556001600055</code></td><td>1</td><td>2</td><td>1</td><td></td><td>1612</td><td>2312</td><td>212</td><td>3012</td></tr> <tr><td><code>0x60026000556002600055</code></td><td>1</td><td>2</td><td>2</td><td></td><td>5812</td><td>5112</td><td>3012</td><td>3012</td></tr> <tr><td><code>0x60016000556000600055</code></td><td>1</td><td>1</td><td>0</td><td></td><td>-9188</td><td>-9888</td><td>-11988</td><td>3012</td></tr> <tr><td><code>0x60016000556002600055</code></td><td>1</td><td>1</td><td>2</td><td></td><td>5812</td><td>5112</td><td>3012</td><td>3012</td></tr> <tr><td><code>0x60016000556001600055</code></td><td>1</td><td>1</td><td>1</td><td></td><td>1612</td><td>2312</td><td>212</td><td>212</td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>0</td><td>1</td><td>0</td><td>1</td><td>21618</td><td>22318</td><td>20218</td><td>40118</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>1</td><td>0</td><td>1</td><td>0</td><td>-8382</td><td>-9782</td><td>-11882</td><td>5918</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-02-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Hugo De la cruzhttps://github.com/hugo-dc Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/3855/

Introduce a new instruction which pushes the constant value 0 onto the stack

<h2 id="abstract">Abstract</h2> <p>Introduce the <code>PUSH0</code> (<code>0x5f</code>) instruction, which pushes the constant value 0 onto the stack.</p> <h2 id="motivation">Motivation</h2> <p>Many instructions expect offsets as inputs, which in a number of cases are zero. A good example is the return data parameters of <code>CALLs</code>, which are set to zeroes in case the contract prefers using <code>RETURNDATA*</code>. This is only one example, but there are many other reasons why a contract would need to push a zero value. They can achieve that today by <code>PUSH1 0</code>, which costs 3 gas at runtime, and is encoded as two bytes which means <code>2 * 200</code> gas deployment cost.</p> <p>Because of the overall cost many try to use various other instructions to achieve the same effect. Common examples include <code>PC</code>, <code>MSIZE</code>, <code>CALLDATASIZE</code>, <code>RETURNDATASIZE</code>, <code>CODESIZE</code>, <code>CALLVALUE</code>, and <code>SELFBALANCE</code>. Some of these cost only 2 gas and are a single byte long, but their value can depend on the context.</p> <p>We have conducted an analysis on Mainnet (block ranges 8,567,259…8,582,058 and 12,205,970…12,817,405), and ~11.5% of all the <code>PUSH*</code> instructions executed push a value of zero.</p> <p>The main motivations for this change include:</p> <ol> <li>Reducing contract code size.</li> <li>Reducing the risk of contracts (mis)using various instructions as an optimisation measure. Repricing/changing those instructions can be more risky.</li> <li>Reduce the need to use <code>DUP</code> instructions for duplicating zeroes.</li> </ol> <p>To put the "waste" into perspective, across existing accounts 340,557,331 bytes are wasted on <code>PUSH1 00</code> instructions, which means 68,111,466,200 gas was spent to deploy them. In practice a lot of these accounts share identical bytecode with others, so their total stored size in clients is lower, however the deploy time cost must have been paid nevertheless.</p> <p>An example for 2) is changing the behaviour of <code>RETURNDATASIZE</code> such that it may not be guaranteed to be zero at the beginning of the call frame.</p> <h2 id="specification">Specification</h2> <p>The instruction <code>PUSH0</code> is introduced at <code>0x5f</code>. It has no immediate data, pops no items from the stack, and places a single item with the value 0 onto the stack. The cost of this instruction is 2 gas (aka <code>base</code>).</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-cost">Gas cost</h3> <p>The <code>base</code> gas cost is used for instructions which place constant values onto the stack, such as <code>ADDRESS</code>, <code>ORIGIN</code>, and so forth.</p> <h3 id="opcode">Opcode</h3> <p><code>0x5f</code> means it is in a "contiguous" space with the rest of the <code>PUSH</code> implementations and potentially could share the implementation.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new opcode which did not exist previously. Already deployed contracts using this opcode could change their behaviour after this EIP.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li><code>5F</code> -- successful execution, stack consist of a single item, set to zero</li> <li><code>5F5F..5F</code> (1024 times) -- successful execution, stack consists of 1024 items, all set to zero</li> <li><code>5F5F..5F</code> (1025 times) -- execution aborts due to out of stack</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>The authors are not aware of any impact on security. Note that jumpdest-analysis is unaffected, as <code>PUSH0</code> has no immediate data bytes.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-02-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Victor Portonhttps://github.com/vporton Victor Portonporton@narod.ru https://wg-eips.ritovision.com/3267/ <h2 id="simple-summary">Simple Summary</h2> <p>Transfer a part of Ethereum transfer/mining fees to Future Salaries contract</p> <h2 id="abstract">Abstract</h2> <p>Transfer a part (exact fractions - TBD) of mining/transfer fees + (probably: TBD) some minted ETH to the <code>DonateETH</code> contract configured to transfer to <code>SalaryWithDAO</code> contract.</p> <h2 id="motivation">Motivation</h2> <p>This proposal solves two problems at once:</p> <ol> <li> <p>It provides a big amount of "money" to common good producers. That obviously personally benefits common good producers, allowing them to live better human lives, it increases peoples' and organizations' both abilities and incentives to produce common goods. That benefits the humanity as a whole and the Ethereum ecosystem in particular. See more in the discussion why it's crucial.</p> </li> <li> <p>This would effectively decrease circulating ETH supply. The necessity to decrease the (circulating) ETH supply (by locking ETH in Future Salaries system for a long time) is a well-known important thing to be done.</p> </li> </ol> <p>Paradoxically, it will directly benefit miners/validators, see the discussion.</p> <h2 id="specification">Specification</h2> <p>(TBD)</p> <p><code>SalaryWithDAO</code> = <code>TBD</code> (<code>address</code>)</p> <p><code>DefaultDAOInterface</code> = <code>TBD</code> (<code>address</code>)</p> <p><code>MintPerPeriod</code> = <code>TBD</code> (<code>uint256</code>)</p> <p><code>TransferFraction</code> = <code>TBD</code> (0..1)</p> <p><code>MineFraction</code> = <code>TBD</code> (0..1)</p> <p><a href="https://wg-eips.ritovision.com/3267/assets/contracts/README/">The contract's source</a></p> <p>Prior to <code>FORK_BLOCK_NUMBER</code>, <code>SalaryWithDAO</code> and <code>DefaultDAOInterface</code> contracts will be deployed to the network and exist at the above specified addresses.</p> <p>Change the Ethereum clients to transfer at every ETH transfer and every ETH mine a fixed fraction <code>TransferFraction</code> of the transferred ETH and <code>MineFraction</code> of the mined ETH to a fixed account (decide the account number, it can be for example <code>0x00000000000000000000000000000000000000001</code> or even <code>0x00000000000000000000000000000000000000000</code> or a random account).</p> <p>Change the Ethereum clients to mint <code>MintPerPeriod</code> ETH to the contract <code>DonateETH</code> every some time (e.g. the first transaction of the first block every UTC day - TBD how often).</p> <p>Change the Ethereum clients to every some time (e.g. the second transaction of the first block every UTC day - TBD how often) transfer the entire ETH from this account to the contract <code>DonateETH</code>.</p> <p>Because this EIP solves a similar problem, cancel any other EIPs that burn ETH (except gas fees) during transfers or mining. (TBD: We should transfer more ETH in this EIP than we burned accordingly older accepted EIPs, because this EIP has the additional advantages of: 1. funding common goods; 2. better aligning values of ETH and values of tokens).</p> <h2 id="rationale">Rationale</h2> <p>The Future Salaries is the <em>only</em> known system of distributing significant funds to common good producers. (Quadratic funding aimed to do a similar thing, but in practice as we see on GitCoin it favors a few developers, ignores project of highly advanced scientific research that is hard to explain to an average developer, and encourages colluding, and it just highly random due to small number of donors. Also quadratic funding simply does not gather enough funds to cover common good needs). So this EIP is the only known way to recover the economy.</p> <p>The economical model of Future Salaries is described in <a href="https://wg-eips.ritovision.com/3267/./assets/science-salaries.pdf">this research article preprint</a>.</p> <p>Funding multiple oracles with different finish time would alleviate the future trouble that the circulating ETH (or other tokens) supply would suddenly increase when the oracle finishes. It would effectively exclude some ETH from the circulation forever.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Because transferring to the aforementioned account is neither mining nor a transaction, we get a new kinds of ETH transfers, so there may be some (expected moderate impact) troubles with applications that have made assumptions about ETH transfers all occurring either as miner payments or transactions.</p> <h2 id="security-considerations">Security Considerations</h2> <p>The security considerations are:</p> <ul> <li>The DAO that controls account restoration may switch to a non-effective or biased way of voting (for example to being controlled by one human) thus distributing funds unfairly. This problem could be solved by a future fork of Ethereum that would "confiscate" control from the DAO.</li> </ul> <p>See more in the discussion.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-02-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paul Dworzanskihttps://github.com/poemm Jared Wasingerhttps://github.com/jwasinger Casey Detriohttps://github.com/cdetrio Pawel Bylicahttps://github.com/chfast Charles Cooperhttps://github.com/charles-cooper https://wg-eips.ritovision.com/5656/

An efficient EVM instruction for copying memory areas

<h2 id="abstract">Abstract</h2> <p>Provide an efficient EVM instruction for copying memory areas.</p> <h2 id="motivation">Motivation</h2> <p>Memory copying is a basic operation, yet implementing it on the EVM comes with overhead.</p> <p>This was recognised and alleviated early on with the introduction of the "identity" precompile, which accomplishes memory copying by the use of <code>CALL</code>'s input and output memory offsets. Its cost is <code>15 + 3 * (length / 32)</code> gas, plus the call overhead. The identity precompile was rendered ineffective by the raise of the cost of <code>CALL</code> to 700, but subsequently the reduction by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> made it slightly more economical.</p> <p>Copying exact words can be accomplished with <code>&lt;offset&gt; MLOAD &lt;offset&gt; MSTORE</code> or <code>&lt;offset&gt; DUP1 MLOAD DUP2 MSTORE</code>, at a cost of at least 12 gas per word. This is fairly efficient if the offsets are known upfront and the copying can be unrolled. In case copying is implemented at runtime with arbitrary starting offsets, besides the control flow overhead, the offset will need to be incremented using <code>32 ADD</code>, adding at least 6 gas per word.</p> <p>Copying non-exact words is more tricky, as for the last partial word, both the source and destination needs to be loaded, masked, or'd, and stored again. This overhead is significant. One edge case is if the last "partial word" is a single byte, it can be efficiently stored using <code>MSTORE8</code>.</p> <p>As example use case, copying 256 bytes costs:</p> <ul> <li>at least 757 gas pre-EIP-2929 using the identity precompile</li> <li>at least 157 gas post-EIP-2929 using the identity precompile</li> <li>at least 96 gas using unrolled <code>MLOAD</code>/<code>MSTORE</code> instructions</li> <li>27 gas using this EIP</li> </ul> <p>According to an analysis of blocks 10537502 to 10538702, roughly 10.5% of memory copies would have had improved performance with the availability of an <code>MCOPY</code> instruction.</p> <p>Memory copying is used by languages like Solidity and Vyper, where we expect this improvement to provide efficient means of building data structures, including efficient sliced access and copies of memory objects. Having a dedicated <code>MCOPY</code> instruction would also add forward protection against future gas cost changes to <code>CALL</code> instructions in general.</p> <p>Having a special <code>MCOPY</code> instruction makes the job of static analyzers and optimizers easier, since the effects of a <code>CALL</code> in general have to be fenced, whereas an <code>MCOPY</code> instruction would be known to only have memory effects. Even if special cases are added for precompiles, a future hard fork could change <code>CALL</code> effects, and so any analysis of code using the identity precompile would only be valid for a certain range of blocks.</p> <p>Finally, we expect memory copying to be immensely useful for various computationally heavy operations, such as EVM384, where it is identified as a significant overhead.</p> <h2 id="specification">Specification</h2> <p>The instruction <code>MCOPY</code> is introduced at <code>0x5E</code>.</p> <h3 id="input-stack">Input stack</h3> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td>top - 0</td><td><code>dst</code></td></tr> <tr><td>top - 1</td><td><code>src</code></td></tr> <tr><td>top - 2</td><td><code>length</code></td></tr> </tbody></table> <p>This ordering matches the other copying instructions, i.e. <code>CALLDATACOPY</code>, <code>RETURNDATACOPY</code>.</p> <h3 id="gas-costs">Gas costs</h3> <p>Per yellow paper terminology, it should be considered part of the <code>W_copy</code> group of opcodes, and follow the gas calculation for <code>W_copy</code> in the yellow paper. While the calculation in the yellow paper should be considered the final word, for reference, as of time of this writing, that currently means its gas cost is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>words_copied = (length + 31) // 32</span></span> <span class="giallo-l"><span>g_verylow = 3</span></span> <span class="giallo-l"><span>g_copy = 3 * words_copied + memory_expansion_cost</span></span> <span class="giallo-l"><span>gas_cost = g_verylow + g_copy</span></span></code></pre><h3 id="output-stack">Output stack</h3> <p>This instruction returns no stack items.</p> <h3 id="semantics">Semantics</h3> <p>It copies <code>length</code> bytes from the offset pointed at <code>src</code> to the offset pointed at <code>dst</code> in memory. Copying takes place as if an intermediate buffer was used, allowing the destination and source to overlap.</p> <p>If <code>length &gt; 0</code> and (<code>src + length</code> or <code>dst + length</code>) is beyond the current memory length, the memory is extended with respective gas cost applied.</p> <p>The gas cost of this instruction mirrors that of other <code>Wcopy</code> instructions and is <code>Gverylow + Gcopy * ceil(length / 32)</code>.</p> <h2 id="rationale">Rationale</h2> <p>Production implementation of exact-word memory copying and partial-word memory copying can be found in the Solidity, Vyper and Fe compilers.</p> <p>With <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> the call overhead using the identity precompile was reduced from 700 to 100 gas. This is still prohibitive for making the precompile a reasonable alternative again.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new instruction which did not exist previously. Already deployed contracts using this instruction could change their behaviour after this EIP.</p> <h2 id="test-cases">Test Cases</h2> <p><code>MCOPY 0 32 32</code> - copy 32 bytes from offset 32 to offset 0.</p> <p>pre (spaces included for readability):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000000 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f</span></span></code></pre> <p>post:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f</span></span></code></pre> <p>gas used: 6</p> <p><code>MCOPY 0 0 32</code> - copy 32 bytes from offset 0 to offset 0.</p> <p>pre:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0101010101010101010101010101010101010101010101010101010101010101</span></span></code></pre> <p>post:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0101010101010101010101010101010101010101010101010101010101010101</span></span></code></pre> <p>gas used: 6</p> <p><code>MCOPY 0 1 8</code> - copy 8 bytes from offset 1 to offset 0 (overlapping).</p> <p>pre (space at byte 8):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0001020304050607 080000000000000000000000000000000000000000000000</span></span></code></pre> <p>post:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0102030405060708 080000000000000000000000000000000000000000000000</span></span></code></pre> <p>gas used: 6</p> <p><code>MCOPY 1 0 8</code> - copy 8 bytes from offset 0 to offset 1 (overlapping).</p> <p>pre (space at byte 8):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0001020304050607 080000000000000000000000000000000000000000000000</span></span></code></pre> <p>post:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000010203040506 070000000000000000000000000000000000000000000000</span></span></code></pre> <p>gas used: 6</p> <h3 id="full-test-suite">Full test suite</h3> <p>A full suite of tests can be found in the execution spec tests: <a rel="external" href="https://github.com/ethereum/execution-spec-tests/tree/c0065176a79f89d93f4c326186fc257ec5b8d5f1/tests/cancun/eip5656_mcopy">MCOPY suite</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Clients should take care that their implementation does not use an intermediate buffer (see for instance that the C stdlib <code>memmove</code> function does not use an intermediate buffer), as this is a potential Denial of Service (DoS) vector. Most language builtins / standard library functions for moving bytes have the correct performance characteristics here.</p> <p>This aside, the analysis for Denial of Service (DoS) and memory exhaustion attacks is identical to other opcodes which touch memory, as the memory expansion follows the same pricing rules.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-01-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Afri Schoedonhttps://github.com/q9f https://wg-eips.ritovision.com/3238/ <h2 id="simple-summary">Simple Summary</h2> <p>Delays the difficulty bomb so 30 second blocks won't happen until around Q2/2022.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLOCK_NUMBER</code> the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting eleven million blocks later than the actual block number.</p> <h2 id="motivation">Motivation</h2> <p>Even after the Ethereum 2.0 mainnet launch, Ethash proof-of-work mining on the legacy chain should be feasible. It should allow miners sealing new blocks every 13~15 seconds on average for another ten months and allow both Ethereum 1.x and Ethereum 2.0 developers to conclude the merge.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fake_block_number = max(0, block.number - 11_000_000) if block.number &gt;= FORK_BLOCK_NUMBER else block.number</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>This will delay the ice age by another ~26 million seconds (approximately ~9.89 months), so the chain would be back at ~30 second block times in Q2/2022. Hopefully, by then the Eth1-to-Eth2 merge will be concluded and the ice age fulfilled its task.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to consider this EIP either with or shortly after the Berlin hard-fork but not later than July 2021.</p> <p>Alternatively, in order to maintain stability of the system, a it can be considered to activate this EIP along with EIP-1559 fee market changes in a bundle. With the delay of the ice age, there is a desire to no further increase inflation and rather incentivize users to participate in proof-of-stake consensus instead.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues with this proposal.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2021-01-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Abdelhamid Bakhtahttps://github.com/abdelhamidbakhta Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/3198/ <h2 id="simple-summary">Simple Summary</h2> <p>Adds an opcode that gives the EVM access to the block's base fee.</p> <h2 id="abstract">Abstract</h2> <p>Add a <code>BASEFEE (0x48)</code> that returns the value of the base fee of the current block it is executing in.</p> <h2 id="motivation">Motivation</h2> <p>The intended use case would be for contracts to get the value of the base fee. This feature would enable or improve existing use cases, such as:</p> <ul> <li>Contracts that need to set bounties for anyone to "poke" them with a transaction could set the bounty to be <code>BASEFEE + x</code>, or <code>BASEFEE * (1 + x)</code>. This makes the mechanism more reliable, because they will always pay "enough" regardless of market conditions.</li> <li>Gas futures can be implemented based on it. This would be more precise than gastokens.</li> <li>Improve the security for state channels, plasma, optirolls and other fraud proof driven solutions. Having the <code>BASEFEE</code> as an input allows you to lengthen the challenge period automatically if you see that the <code>BASEFEE</code> is high.</li> </ul> <h2 id="specification">Specification</h2> <p>Add a <code>BASEFEE</code> opcode at <code>(0x48)</code>, with gas cost <code>G_base</code>.</p> <p>| Op | Input | Output | Cost | |:----: |:-----: |:------: |:----: | | 0x48 | 0 | 1 | 2 |</p> <h2 id="rationale">Rationale</h2> <h3 id="gas-cost">Gas cost</h3> <p>The value of the base fee is needed to process transactions. That means it's value is already available before running the EVM code. The opcode does not add extra complexity and additional read/write operations, hence the choice of <code>G_base</code> gas cost.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues with this opcode.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="nominal-case">Nominal case</h3> <p>Assuming current block base fee is <code>7 wei</code>. This should push the value <code>7</code> (left padded byte32) to the stack.</p> <p>Bytecode: <code>0x4800</code> (<code>BASEFEE, STOP</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>BASEFEE</td><td>2</td><td>[]</td><td>[]</td></tr> <tr><td>1</td><td>STOP</td><td>0</td><td>[7]</td><td>[]</td></tr> </tbody></table> <p>Output: 0x Consumed gas: <code>2</code></p> <h2 id="security-considerations">Security Considerations</h2> <p>The value of the base fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this opcode.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-12-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Tinnerhttps://github.com/Terra854 https://wg-eips.ritovision.com/3143/ <h2 id="simple-summary">Simple Summary</h2> <p>Changes the block reward paid to proof-of-work (POW) miners to 5 ETH.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLKNUM</code> block rewards will be increased to a base of 5 ETH, uncle and nephew rewards will be adjusted accordingly.</p> <h2 id="motivation">Motivation</h2> <p>Currently, the transaction fees (tx fees) portion of the mining rewards makes up a significant portion of the total rewards per block, at times almost exceeded the block reward of 2 ETH. This have resulted in situations where at times of low tx fees, POW miners decide to point their rigs away from ETH as they will always prefer to mine coins that are the most profitable at any point in time, reducing the security of the ETH network till transaction activity picks up again. By increasing the block rewards back to the original 5 ETH when the network first started, the voliatility will be reduced in terms of the percentage of tx fees that make up the mining rewards per block while increasing the total rewards per block, making it more financially attractive to POW miners to mine ETH barring any gigantic ETH price drops. The increase in block rewards will also allow smaller POW miners ample opporturnity to build up their stores of ETH so that when the time comes to fully transition to ETH 2.0, they may be more willing to become validators as they already have earned the requite amount of ETH needed to do so as opposed to having to spend tens of thousands of dollars to purchase the required ETH directly, increasing the number of validators in the network and therefore strengthening network security.</p> <p>Therefore, the ultimate end goal for this EIP is to give POW miners more incentive to switch to POS once ETH 2.0 is fully implemented since the transition will take a few years to complete and during that time, they will be incentivised to hold on to the tokens instead of selling it straight away in order to prepare to be a validator for ETH 2.0, reducing the selling pressure on ETH and increasing it's value in the long run. A side effect of miners staying on Ethereum is that network security will be assured during the transition period.</p> <h2 id="specification">Specification</h2> <h4 id="adjust-block-uncle-and-nephew-rewards">Adjust Block, Uncle, and Nephew rewards</h4> <p>Adjust the block reward to <code>new_block_reward</code>, where</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_block_reward = 5_000_000_000_000_000_000 if block.number &gt;= FORK_BLKNUM else block.reward</span></span></code></pre> <p>(5E18 wei, or 5,000,000,000,000,000,000 wei, or 5 ETH).</p> <p>Analogue, if an uncle is included in a block for <code>block.number &gt;= FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (8 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing formula for uncle rewards, simply adjusted with <code>new_block_reward</code>.</p> <p>The nephew reward for <code>block.number &gt;= FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = new_block_reward / 32</span></span></code></pre> <p>This is the existing formula for nephew rewards, simply adjusted with <code>new_block_reward</code>.</p> <h2 id="rationale">Rationale</h2> <p>A 5 ETH base reward was chosen as a middle ground between wanting to prevent too high of an inflation rate (10.4% per annum for the first year at 5 ETH per block) and converting as many POW miners as possible into POS validators by making it easier to amass the required ETH needed through POW mining.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no known backward compatibility issues with the introduction of this EIP.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are no known security issues presented by this change.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-10-23T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dr. Christopher Gormanhttps://github.com/chgormanMH https://wg-eips.ritovision.com/3068/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP defines a hash-to-curve precompile for use in BN256 and would allow for cheaper BLS signature verification.</p> <h2 id="abstract">Abstract</h2> <p>There is currently no inexpensive way to perform BLS signature verification for arbitrary messages. This stems from the fact that there is no precompiled contract in the EVM for a hash-to-curve algorithm for the BN256 elliptic curve. The gas cost of calling a deterministic hash-to-curve algorithm written in Solidity is approximately that of one pairing check, although the latter requires an order of magnitude more computation. This EIP remedies this by implementing a hash-to-curve algorithm for the BN256 G1 curve, which would reduce the cost of signature verification to essentially that of the pairing check precompiled contract. We also include a hash-to-curve algorithm for the BN256 G2 group.</p> <h2 id="motivation">Motivation</h2> <p>The precompiled contracts in <a href="https://wg-eips.ritovision.com/198/">EIP-198</a> and <a href="https://wg-eips.ritovision.com/1108/">EIP-1108</a> increased usage of cryptographic operations in the EVM by reducing the gas costs. In particular, the cost reduction from <a href="https://wg-eips.ritovision.com/1108/">EIP-1108</a> helps increase the use of SNARKs in Ethereum via an elliptic curve pairing check; however, a hash-to-curve algorithm enabling arbitrary BLS signature verification on BN256 in the EVM was noticeably missing. There is interest in having a precompiled contract which would allow for signature verification, as noted <a rel="external" href="https://ethereum-magicians.org/t/pre-compile-for-bls/3973">here</a>.</p> <p>At this time, we are able to perform addition, scalar multiplication, and pairing checks in BN256. Reducing these costs in <a href="https://wg-eips.ritovision.com/1108/">EIP-1108</a> made <a rel="external" href="https://github.com/PhilippSchindler/ethdkg">ETHDKG</a>, a distributed key generation protocol in Ethereum, less expensive. ETHDKG by itself is useful; however, what it is lacking is the ability to verify arbitrary BLS signatures. Creating group signatures by aggregating partial signatures is one goal of a DKG protocol. The DKG enables the computation of partial signatures to be combined into a group signature offline, but there is no easy way to verify partial signatures or group signatures in the EVM.</p> <p>In order to perform BLS signature validation, a hash-to-curve algorithm is required. While the MapToGroup method initially discussed in the original BLS <a href="https://wg-eips.ritovision.com/3068/./assets/weilsigs.pdf">paper</a> works in practice, the nondeterministic nature of the algorithm leaves something to be desired as we would like to bound the overall computational cost in the EVM. A deterministic method for mapping to BN curves is given <a href="https://wg-eips.ritovision.com/3068/./assets/latincrypt12.pdf">here</a>; in the paper, Fouque and Tibouchi proved their mapping was indifferentiable from a random oracle. This gives us the desired algorithm.</p> <h2 id="specification">Specification</h2> <p>Here is the pseudocode for the <code>HashToG1</code> function:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function HashToG1(msg)</span></span> <span class="giallo-l"><span> fieldElement0 = HashToBase(msg, 0x00, 0x01)</span></span> <span class="giallo-l"><span> fieldElement1 = HashToBase(msg, 0x02, 0x03)</span></span> <span class="giallo-l"><span> curveElement0 = BaseToG1(fieldElement0)</span></span> <span class="giallo-l"><span> curveElement1 = BaseToG1(fieldElement1)</span></span> <span class="giallo-l"><span> g1Element = ECAdd(curveElement0, curveElement1)</span></span> <span class="giallo-l"><span> return g1Element</span></span> <span class="giallo-l"><span>end function</span></span></code></pre> <p>Here is the pseudocode for <code>HashToBase</code>; <code>msg</code> is the byte slice to be hashed while <code>dsp1</code> and <code>dsp2</code> are domain separation parameters. <code>fieldPrime</code> is the prime of the underlying field.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function HashToBase(msg, dsp1, dsp2)</span></span> <span class="giallo-l"><span> hashResult0 = uint256(Keccak256(dsp1||msg))</span></span> <span class="giallo-l"><span> hashResult1 = uint256(Keccak256(dsp2||msg))</span></span> <span class="giallo-l"><span> constant = 2^256 mod fieldPrime</span></span> <span class="giallo-l"><span> fieldElement0 = hashResult0*constant mod fieldPrime</span></span> <span class="giallo-l"><span> fieldElement1 = hashResult1 mod fieldPrime</span></span> <span class="giallo-l"><span> fieldElement = fieldElement0 + fieldElement1 mod fieldPrime</span></span> <span class="giallo-l"><span> return fieldElement</span></span> <span class="giallo-l"><span>end function</span></span></code></pre> <p>Here is the pseudocode for <code>BaseToG1</code>. All of these operations are performed in the finite field. <code>inverse</code> computes the multiplicative inverse in the underlying finite field; we have the convention <code>inverse(0) == 0</code>. <code>is_square(a)</code> computes the Legendre symbol of the element, returning 1 if <code>a</code> is a square, -1 if <code>a</code> is not a square, and 0 if <code>a</code> is 0. <code>sqrt</code> computes the square root of the element in the finite field; a square root is assumed to exist. <code>sign0</code> returns the sign of the finite field element.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function BaseToG1(t)</span></span> <span class="giallo-l"><span> # All operations are done in the finite field GF(fieldPrime)</span></span> <span class="giallo-l"><span> # Here, the elliptic curve satisfies the equation</span></span> <span class="giallo-l"><span> # y^2 == g(x) == x^3 + curveB</span></span> <span class="giallo-l"><span> constant1 = (-1 + sqrt(-3))/2</span></span> <span class="giallo-l"><span> constant2 = -3</span></span> <span class="giallo-l"><span> constant3 = 1/3</span></span> <span class="giallo-l"><span> constant4 = g(1)</span></span> <span class="giallo-l"><span> s = (constant4 + t^2)^3</span></span> <span class="giallo-l"><span> alpha = inverse(t^2*(constant4 + t^2))</span></span> <span class="giallo-l"><span> x1 = constant1 - constant2*t^4*alpha</span></span> <span class="giallo-l"><span> x2 = -1 - x1</span></span> <span class="giallo-l"><span> x3 = 1 - constant3*s*alpha</span></span> <span class="giallo-l"><span> a1 = x1^3 + curveB</span></span> <span class="giallo-l"><span> a2 = x2^3 + curveB</span></span> <span class="giallo-l"><span> residue1 = is_square(a1)</span></span> <span class="giallo-l"><span> residue2 = is_square(a2)</span></span> <span class="giallo-l"><span> index = (residue1 - 1)*(residue2 - 3)/4 + 1</span></span> <span class="giallo-l"><span> coef1 = ConstantTimeEquality(1, index)</span></span> <span class="giallo-l"><span> coef2 = ConstantTimeEquality(2, index)</span></span> <span class="giallo-l"><span> coef3 = ConstantTimeEquality(3, index)</span></span> <span class="giallo-l"><span> x = coef1*x1 + coef2*x2 + coef3*x3</span></span> <span class="giallo-l"><span> y = sign0(t)*sqrt(x^3 + curveB)</span></span> <span class="giallo-l"><span> return (x, y)</span></span> <span class="giallo-l"><span>end function</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function sign0(t)</span></span> <span class="giallo-l"><span> if t &lt;= (fieldPrime-1)/2</span></span> <span class="giallo-l"><span> return 1</span></span> <span class="giallo-l"><span> else</span></span> <span class="giallo-l"><span> return fieldPrime-1</span></span> <span class="giallo-l"><span> end if</span></span> <span class="giallo-l"><span>end function</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function ConstantTimeEquality(a, b)</span></span> <span class="giallo-l"><span> # This function operates in constant time</span></span> <span class="giallo-l"><span> if a == b</span></span> <span class="giallo-l"><span> return 1</span></span> <span class="giallo-l"><span> else</span></span> <span class="giallo-l"><span> return 0</span></span> <span class="giallo-l"><span> end if</span></span> <span class="giallo-l"><span>end function</span></span></code></pre> <p>In <code>HashToG2</code>, we first map to the underlying twist curve and then clear the cofactor to map to G2. Here is the pseudocode for <code>HashToG2</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function HashToG2(msg)</span></span> <span class="giallo-l"><span> fieldElement00 = HashToBase(msg, 0x04, 0x05)</span></span> <span class="giallo-l"><span> fieldElement01 = HashToBase(msg, 0x06, 0x07)</span></span> <span class="giallo-l"><span> fieldElement10 = HashToBase(msg, 0x08, 0x09)</span></span> <span class="giallo-l"><span> fieldElement11 = HashToBase(msg, 0x0a, 0x0b)</span></span> <span class="giallo-l"><span> fieldElement0 = (fieldElement00, fieldElement01)</span></span> <span class="giallo-l"><span> fieldElement1 = (fieldElement10, fieldElement11)</span></span> <span class="giallo-l"><span> twistElement0 = BaseToTwist(fieldElement0)</span></span> <span class="giallo-l"><span> twistElement1 = BaseToTwist(fieldElement1)</span></span> <span class="giallo-l"><span> twistElement = ECAdd(twistElement0, twistElement1)</span></span> <span class="giallo-l"><span> g2Element = ClearCofactor(twistElement)</span></span> <span class="giallo-l"><span> return g2Element</span></span> <span class="giallo-l"><span>end function</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>function ClearCofactor(twistElement)</span></span> <span class="giallo-l"><span> return ECMul(twistElement, cofactor)</span></span> <span class="giallo-l"><span>end function</span></span></code></pre> <p>Here is the pseudocode for <code>BaseToTwist</code>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function BaseToTwist(t)</span></span> <span class="giallo-l"><span> # All operations are done in the finite field GF(fieldPrime^2)</span></span> <span class="giallo-l"><span> # Here, the twist curve satisfies the equation</span></span> <span class="giallo-l"><span> # y^2 == g&#39;(x) == x^3 + curveBPrime</span></span> <span class="giallo-l"><span> constant1 = (-1 + sqrt(-3))/2</span></span> <span class="giallo-l"><span> constant2 = -3</span></span> <span class="giallo-l"><span> constant3 = 1/3</span></span> <span class="giallo-l"><span> constant4 = g&#39;(1)</span></span> <span class="giallo-l"><span> s = (constant4 + t^2)^3</span></span> <span class="giallo-l"><span> alpha = inverse(t^2*(constant4 + t^2))</span></span> <span class="giallo-l"><span> x1 = constant1 - constant2*t^4*alpha</span></span> <span class="giallo-l"><span> x2 = -1 - x1</span></span> <span class="giallo-l"><span> x3 = 1 - constant3*s*alpha</span></span> <span class="giallo-l"><span> a1 = x1^3 + curveBPrime</span></span> <span class="giallo-l"><span> a2 = x2^3 + curveBPrime</span></span> <span class="giallo-l"><span> residue1 = is_square(a1)</span></span> <span class="giallo-l"><span> residue2 = is_square(a2)</span></span> <span class="giallo-l"><span> index = (residue1 - 1)*(residue2 - 3)/4 + 1</span></span> <span class="giallo-l"><span> coef1 = ConstantTimeEquality(1, index)</span></span> <span class="giallo-l"><span> coef2 = ConstantTimeEquality(2, index)</span></span> <span class="giallo-l"><span> coef3 = ConstantTimeEquality(3, index)</span></span> <span class="giallo-l"><span> x = coef1*x1 + coef2*x2 + coef3*x3</span></span> <span class="giallo-l"><span> y = sign0(t)*sqrt(x^3 + curveBPrime)</span></span> <span class="giallo-l"><span> return (x, y)</span></span> <span class="giallo-l"><span>end function</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>The BaseToG1 algorithm is based on the original Fouque and Tibouchi <a href="https://wg-eips.ritovision.com/3068/./assets/latincrypt12.pdf">paper</a> with modifications based on Wahby and Boneh's <a href="https://wg-eips.ritovision.com/3068/./assets/2019-403_BLS12_H2C.pdf">paper</a>. There is freedom in choosing the HashToBase function and this could easily be changed. Within HashToBase, the particular hashing algorithm (Keccak256 in our case) could also be modified. It may be desired to change the call to <code>sign0</code> at the end of BaseToG1 and BaseToTwist with <code>is_square</code>, as this would result in the same deterministic map to curve from the Fouque and Tibouchi <a href="https://wg-eips.ritovision.com/3068/./assets/latincrypt12.pdf">paper</a> and ensure HashToG1 is indifferentiable from a random oracle; they proved this result in their paper. It may be possible to show that switching the <code>is_square</code> call with <code>sign0</code> does not affect indifferentiability, although this has not been proven.</p> <p>The HashToG2 algorithm follows from the Wahby and Boneh <a href="https://wg-eips.ritovision.com/3068/./assets/2019-403_BLS12_H2C.pdf">paper</a>. Algorithms for computing <code>inverse</code>, <code>is_square</code>, and <code>sqrt</code> in finite field GF(fieldPrime^2) can be found <a href="https://wg-eips.ritovision.com/3068/./assets/2012-685_Square_Root_Even_Ext.pdf">here</a>.</p> <p>We now discuss the potential gas cost for the HashToG1 and HashToG2 operations. On a local machine, ECMul was clocked at 68 microseconds per operation. The same machine clocked HashToG1 at 94 microseconds per operation when hashing 32 bytes into G1 and 105 microseconds per operation when hashing 1024 bytes into G1. Given that it currently costs 6000 gas for ECMul, this gives us an estimated gas cost for HashToG1 at <code>8500 + len(bytes)</code>. Similarly, HashToG2 was clocked at 886 microseconds per operation when hashing 32 bytes into G2 and 912 microseconds per operation when hashing 1024 bytes into G2. This allows us to estimate the gas cost at <code>80000 + 3*len(bytes)</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backward compatibility concerns.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>Due to recent <a href="https://wg-eips.ritovision.com/3068/./assets/2015-1027_exTNFS.pdf">work</a>, the 128-bit security promised by the BN256 elliptic curve no longer applies; this was mentioned in the Cloudflare BN256 <a rel="external" href="https://github.com/cloudflare/bn256">library</a>. There has been some discussion on the exact security decrease from this advancement; see these <a href="https://wg-eips.ritovision.com/3068/./assets/2016-1102_Assessing_NFS_Advances.pdf">two</a> <a href="https://wg-eips.ritovision.com/3068/./assets/2017-334.pdf">papers</a> for different estimates. The more conservative estimate puts the security of BN256 at 100-bits. While this is likely still out of reach for many adversaries, it should give us pause. This reduced security was noted in the recent MadNet <a href="https://wg-eips.ritovision.com/3068/./assets/madnet.pdf">whitepaper</a>, and this security concern was partially mitigated by requiring Secp256k1 signatures of the partial group signatures in order for those partial signatures to be valid. Full disclosure: the author of this EIP works for MadHive, assisted in the development of MadNet, and helped write the MadNet whitepaper.</p> <p>The security concerns of the BN256 elliptic curve affect any operation using pairing check because it is related to the elliptic curve pairing; they are independent of this EIP.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-10-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Weijia Zhanghttps://github.com/weijia31415 Peter Robinsonhttps://github.com/drinkcoffee https://wg-eips.ritovision.com/3220/ <h2 id="simple-summary">Simple Summary</h2> <p>A self-verifying unique blockchain identifier that deals with forks.</p> <h2 id="abstract">Abstract</h2> <p>The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain. We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.</p> <h2 id="motivation">Motivation</h2> <p>With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace. There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network. The growth of public and private blockchains imposes challenges for inter-chain interoperability, particularly when these chains are heterogeneous and incompatible. Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.</p> <p><a href="https://wg-eips.ritovision.com/155/">EIP-155</a> provides a unique identifier to a blockchain to provide simple relay attack protection. This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.</p> <p>The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid. Also, it does not address the issue for two forked blockchains having the same chainid.</p> <p>Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved. A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:</p> <ul> <li>should provide identification, description, and discovery of blockchains.</li> <li>should provide unique identification of each blockchain in the crosschain service ecosystem.</li> <li>should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.</li> <li>should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.</li> <li>should provide a mechanism for a joining blockchain to register to the ecosystem.</li> <li>should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.</li> <li>should provide a mechanism to get some critical information of the blockchain</li> <li>should provide a mechanism to differentiate an original blockchain and a forked blockchain</li> <li>should provide a mechanism to verify a chainid without external registration service</li> </ul> <h2 id="specification">Specification</h2> <h3 id="definition-of-a-32-byte-crosschain-id">Definition of a 32 byte crosschain id</h3> <table><thead><tr><th>Name</th><th>Size(bytes)</th><th>Description</th></tr></thead><tbody> <tr><td>Truncated Block Hash</td><td>16</td><td>This is the block hash of the genesis block or the block hash of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order.</td></tr> <tr><td>Native Chain ID</td><td>8</td><td>This is the <strong>Chain Id</strong> value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of <strong>Chain Id</strong>, this value is zero.</td></tr> <tr><td>Chain Type</td><td>2</td><td>Reserve 0x00 as undefined chaintype. 0x01 as mainnet type. 0x1[0-A]: testnet, 0x2[0-A]: private development network</td></tr> <tr><td>Governance Identifier</td><td>2</td><td>For new blockchains, a governance_identifier can be specified to identify an original <strong>owner</strong> of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an <strong>owner</strong>, this field is zero.</td></tr> <tr><td>Reserved</td><td>3</td><td>Reserved for future use. Use 000000 for now.</td></tr> <tr><td>Checksum</td><td>1</td><td>Used to verify the integrity of the identifier. This integrity check is targeted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier.</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <p>We have considered various alternative specifications such as using a random unique hex string to represent a blockchain. The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block. A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations. The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Crosschainid can be backward compatible with EIP-155. The crosschain id contains an 8 byte segment to record the <code>Native Chain ID</code>. For Ethereum chains, that can be used for a value intended to be used with EIP-155.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Collision of crosschain id: Two blockchains can contain the same crosschain id and hence making the mistakenly transfer assets to a wrong blockchain.<br /> This security concern is addressed by comparing the hash of the crosschain id with the hash of the genesis block. If it matches, then the crosschain id is verified. If not, the crosschain id can be compared with the forked blockhash. If none of the blockhash match the crosschain id hash, then the crosschain id cannot be verified.</p> <p>Preventing relay attack: Although crosschain id by itself is different from chainid and it is not signed into blockchain transaction, the crosschain id can still be used for presenting relay attack. An application that handles crosschain transaction can verified the crosschain id with its blockhash and decide whether the transaction is valid or not. Any transaction with a non-verifiable crosschain id should be rejected.</p> <p>The crosschain-id are not required to be signed into blockchaid tx. For blockchains that do not cryptographically sign crosschain id into the blocks, the crosschain id cannot be verified with the blocks itself and have to be verified with external smart contract address and offchain utilities implemented based on the crosschain id specification.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-10-15T00:00:00+00:00 2026-02-11T14:49:28+00:00 Sam Wilsonhttps://github.com/SamWilsn Ansgar Dietrichshttps://github.com/adietrichs Matt Garnetthttps://github.com/lightclient Micah Zoltuhttps://github.com/micahzoltu https://wg-eips.ritovision.com/3074/

Allow externally owned accounts to delegate control to a contract.

<h2 id="abstract">Abstract</h2> <p>This EIP introduces two EVM instructions <code>AUTH</code> and <code>AUTHCALL</code>. The first sets a context variable <code>authorized</code> based on an ECDSA signature. The second sends a call as the <code>authorized</code> account. This essentially delegates control of the externally owned account (EOA) to a smart contract.</p> <h2 id="motivation">Motivation</h2> <p>Adding more functionality to EOAs has been a long-standing feature request. The requests have spanned from implementing batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. These changes often mean increased complexity and rigidity of the protocol. In some cases, it also means increased attack surfaces.</p> <p>This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it allows users to <em>delegate</em> control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs. A motivating use case of this EIP is that it allows any EOA to act like a smart contract wallet <em>without</em> deploying a contract.</p> <p>Although this EIP provides great benefit to individual users, the leading motivation for this EIP is "sponsored transactions". This is where the fee for a transaction is provided by a different account than the one that originates the call.</p> <p>With the extraordinary growth of tokens on Ethereum, it has become common for EOAs to hold valuable assets without holding any ether at all. Today, these assets must be converted to ether before they can be used to pay gas fees. However, without ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency.</p> <h2 id="specification">Specification</h2> <h3 id="conventions">Conventions</h3> <ul> <li><strong><code>top - N</code></strong> - the <code>N</code>th most recently pushed value on the EVM stack, where <code>top - 0</code> is the most recent.</li> <li><strong><code>||</code></strong> - byte concatenation operator.</li> <li><strong>invalid execution</strong> - execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump).</li> </ul> <h3 id="constants">Constants</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>MAGIC</code></td><td><code>0x04</code></td></tr> </tbody></table> <p><code>MAGIC</code> is used for <a href="https://wg-eips.ritovision.com/3074/">EIP-3074</a> signatures to prevent signature collisions with other signing formats.</p> <h3 id="context-variables">Context Variables</h3> <table><thead><tr><th>Variable</th><th>Type</th><th style="text-align: left">Initial Value</th></tr></thead><tbody> <tr><td><code>authorized</code></td><td><code>address</code></td><td style="text-align: left">unset</td></tr> </tbody></table> <p>The context variable <code>authorized</code> shall indicate the active account for <code>AUTHCALL</code> instructions in the current frame of execution. If set, <code>authorized</code> shall only contain an account which has given the contract authorization to act on its behalf. An unset value shall indicate that no such account is set and that there is not yet an active account for <code>AUTHCALL</code> instructions in the current frame of execution.</p> <p>The variable has the same scope as the program counter -- <code>authorized</code> persists throughout a single frame of execution of the contract, but is not passed through any calls (including <code>DELEGATECALL</code>). If the same contract is being executed in separate execution frames (ex. a <code>CALL</code> to self), both frames shall have independent values for <code>authorized</code>. Initially in each frame of execution, <code>authorized</code> is always unset, even if a previous execution frame for the same contract has a value.</p> <h3 id="auth-0xf6"><code>AUTH</code> (<code>0xf6</code>)</h3> <p>A new opcode <code>AUTH</code> shall be created at <code>0xf6</code>. It shall take three stack element inputs (the last two describing a memory range), and it shall return one stack element.</p> <h4 id="input">Input</h4> <h5 id="stack">Stack</h5> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>authority</code></td></tr> <tr><td><code>top - 1</code></td><td><code>offset</code></td></tr> <tr><td><code>top - 2</code></td><td><code>length</code></td></tr> </tbody></table> <h5 id="memory">Memory</h5> <p>The final two stack arguments (<code>offset</code> and <code>length</code>) describe a range of memory. The format of the contents of that range is:</p> <ul> <li><code>memory[offset : offset+1 ]</code> - <code>yParity</code></li> <li><code>memory[offset+1 : offset+33]</code> - <code>r</code></li> <li><code>memory[offset+33 : offset+65]</code> - <code>s</code></li> <li><code>memory[offset+65 : offset+97]</code> - <code>commit</code></li> </ul> <h4 id="output">Output</h4> <h5 id="stack-1">Stack</h5> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>success</code></td></tr> </tbody></table> <h5 id="memory-1">Memory</h5> <p>Memory is not modified by this instruction.</p> <h4 id="behavior">Behavior</h4> <p>If <code>length</code> is greater than 97, the extra bytes are ignored for signature verification (they still incur a gas cost as defined later). Bytes outside the range (in the event <code>length</code> is less than 97) are treated as if they had been zeroes.</p> <p><code>authority</code> is the address of the account which generated the signature. If <code>EXTCODESIZE</code> of <code>authority</code> is not zero, consider the operation unsuccessful and unset <code>authorized</code>.</p> <p>The arguments (<code>yParity</code>, <code>r</code>, <code>s</code>) are interpreted as an ECDSA signature on the secp256k1 curve over the message <code>keccak256(MAGIC || chainId || nonce || invokerAddress || commit)</code>, where:</p> <ul> <li><code>chainId</code> is the current chain's <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> unique identifier padded to 32 bytes.</li> <li><code>nonce</code> is the signer's current nonce, left-padded to 32 bytes.</li> <li><code>invokerAddress</code> is the address of the contract executing <code>AUTH</code> (or the active state address in the context of <code>CALLCODE</code> or <code>DELEGATECALL</code>), left-padded with zeroes to a total of 32 bytes (ex. <code>0x000000000000000000000000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</code>).</li> <li><code>commit</code>, one of the arguments passed into <code>AUTH</code>, is a 32-byte value that can be used to commit to specific additional validity conditions in the invoker's pre-processing logic.</li> </ul> <p>Signature validity and signer recovery are handled analogously to transaction signatures, including the stricter <code>s</code> range for preventing ECDSA malleability. Note that <code>yParity</code> is expected to be <code>0</code> or <code>1</code>.</p> <p>If the signature is valid and the signer address is equal to <code>authority</code>, the context variable <code>authorized</code> is set to the <code>authority</code>. In particular, this is also true if <code>authority == tx.origin</code>, which used to be handled separately in earlier versions of this EIP (see Security Considerations). If the signature is instead invalid or the signer address does not equal <code>authority</code>, <code>authorized</code> is reset to an unset value.</p> <p><code>AUTH</code> returns <code>1</code> if <code>authorized</code> is set, or <code>0</code> otherwise.</p> <h4 id="gas-cost">Gas Cost</h4> <p>The gas cost for <code>AUTH</code> is equal to the sum of:</p> <ul> <li>fixed fee <code>3100</code>.</li> <li>memory expansion gas cost (<code>auth_memory_expansion_fee</code>).</li> <li><code>100</code> if <code>authority</code> is warm, <code>2600</code> if it is cold (per <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>).</li> </ul> <p>The fixed fee is equal to the cost for the <code>ecrecover</code> precompile, plus a bit extra to cover a keccak256 hash and some additional logic.</p> <p>The memory expansion gas cost (<code>auth_memory_expansion_fee</code>) shall be calculated in the same way as <code>RETURN</code>, where memory is expanded if the specified range is outside the current allocation.</p> <h3 id="authcall-0xf7"><code>AUTHCALL</code> (<code>0xf7</code>)</h3> <p>A new opcode <code>AUTHCALL</code> shall be created at <code>0xf7</code>. It shall take seven stack elements and return one stack element. It matches the behavior of the existing <code>CALL</code> (<code>0xF1</code>) instruction, except where noted below.</p> <h4 id="input-1">Input</h4> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>gas</code></td></tr> <tr><td><code>top - 1</code></td><td><code>addr</code></td></tr> <tr><td><code>top - 2</code></td><td><code>value</code></td></tr> <tr><td><code>top - 3</code></td><td><code>argsOffset</code></td></tr> <tr><td><code>top - 4</code></td><td><code>argsLength</code></td></tr> <tr><td><code>top - 5</code></td><td><code>retOffset</code></td></tr> <tr><td><code>top - 6</code></td><td><code>retLength</code></td></tr> </tbody></table> <h4 id="output-1">Output</h4> <table><thead><tr><th>Stack</th><th>Value</th></tr></thead><tbody> <tr><td><code>top - 0</code></td><td><code>success</code></td></tr> </tbody></table> <h4 id="behavior-1">Behavior</h4> <p><code>AUTHCALL</code> is interpreted the same as <code>CALL</code>, except for (note: this list is also the order of precedence for the logical checks):</p> <ul> <li>If <code>authorized</code> is unset, execution is invalid (as defined above). Otherwise, the caller address for the call is set to <code>authorized</code>.</li> <li>The gas cost, including how much gas is available for the subcall, is specified in the Gas Cost section.</li> <li>If the <code>gas</code> operand is equal to <code>0</code>, the instruction will send all available gas as per <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>.</li> <li>If the gas available for the subcall would be less than <code>gas</code>, execution is invalid.</li> <li>There is no gas stipend, even for non-zero <code>value</code>.</li> <li><code>value</code> is deducted from the balance of <code>authorized</code>. If <code>value</code> is higher than the balance of <code>authorized</code>, execution is invalid.</li> </ul> <p><code>AUTHCALL</code> must increase the call depth by one. <code>AUTHCALL</code> must not increase the call depth by two as it would if it first called into the authorized account and then into the target.</p> <p>The return data area accessed with <code>RETURNDATASIZE</code> (<code>0x3d</code>) and <code>RETURNDATACOPY</code> (<code>0x3e</code>) must be set in the same way as the <code>CALL</code> instruction.</p> <p>Importantly, <code>AUTHCALL</code> does not reset <code>authorized</code>, but leaves it unchanged.</p> <h4 id="gas-cost-1">Gas Cost</h4> <p>The gas cost for <code>AUTHCALL</code> shall be the <strong>sum</strong> of:</p> <ul> <li>static gas cost (<code>warm_storage_read</code>)</li> <li>memory expansion gas cost (<code>memory_expansion_fee</code>)</li> <li>dynamic gas cost (<code>dynamic_gas</code>)</li> <li>gas available for execution in the subcall (<code>subcall_gas</code>)</li> </ul> <p>The memory expansion gas cost (<code>memory_expansion_fee</code>) shall be calculated in the same way as <code>CALL</code>.</p> <p>The dynamic gas portion (<code>dynamic_gas</code>), and the gas available for execution in the subcall (<code>subcall_gas</code>) shall be calculated as:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>dynamic_gas = 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if addr not in accessed_addresses:</span></span> <span class="giallo-l"><span> dynamic_gas += 2500 # cold_account_access - warm_storage_read</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if value &gt; 0:</span></span> <span class="giallo-l"><span> dynamic_gas += 6700 # NB: Not 9000, like in `CALL`</span></span> <span class="giallo-l"><span> if is_empty(addr):</span></span> <span class="giallo-l"><span> dynamic_gas += 25000</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>remaining_gas = available_gas - dynamic_gas</span></span> <span class="giallo-l"><span>all_but_one_64th = remaining_gas - (remaining_gas // 64)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>if gas == 0:</span></span> <span class="giallo-l"><span> subcall_gas = all_but_one_64th</span></span> <span class="giallo-l"><span>elif all_but_one_64th &lt; gas:</span></span> <span class="giallo-l"><span> raise # Execution is invalid.</span></span> <span class="giallo-l"><span>else:</span></span> <span class="giallo-l"><span> subcall_gas = gas</span></span></code></pre> <p>As with <code>CALL</code>, the full gas cost is charged immediately, independently of actually executing the call.</p> <h2 id="rationale">Rationale</h2> <h3 id="signature-in-memory">Signature in Memory</h3> <p>The signature format (<code>yParity</code>, <code>r</code>, and <code>s</code>) is fixed, so it might seem curious that <code>auth</code> accepts a dynamic memory range. The signature is placed in memory so that <code>auth</code> can be upgraded in the future to work with contract accounts (which might use non-ECDSA signatures) and not just EOAs.</p> <h3 id="signing-address-auth-argument">Signing Address <code>auth</code> Argument</h3> <p>Including <code>authority</code> (the signing address) as an argument to <code>auth</code> allows future upgrades to the instruction to work with contract accounts, and not just EOAs.</p> <p>If <code>authority</code> were not included and multiple signature schemes allowed, it would not be possible to compute the authorizing account's address from just the signature alone.</p> <h3 id="reserving-one-sixty-fourth-of-available-gas">Reserving One Sixty-Fourth of Available Gas</h3> <p><code>AUTHCALL</code> will not pass more than 63/64th of the available gas for the reasons enumerated in <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>.</p> <h3 id="throwing-for-unset-authorized-during-authcall">Throwing for Unset <code>authorized</code> During <code>AUTHCALL</code></h3> <p>A well-behaved contract should never reach an <code>AUTHCALL</code> without having successfully set <code>authorized</code> beforehand. The safest behavior, therefore, is to exit the current frame of execution immediately. This is especially important in the context of transaction sponsoring / relaying, which is expected to be one of the main use cases for this EIP. In a sponsored transaction, the inability to distinguish between a sponsee-attributable fault (like a failing sub-call) and a sponsor-attributable fault (like a failing <code>AUTH</code>) is especially dangerous and should be prevented because it charges unfair fees to the sponsee.</p> <h3 id="another-sponsored-transaction-eip">Another Sponsored Transaction EIP</h3> <p>There are two general approaches to separating the "fee payer" from the "action originator".</p> <p>The first is introducing a new transaction type. This requires significant changes to clients to support and is generally less upgradeable than other solutions (e.g. this EIP). This approach is also not immediately compatible with account abstraction (AA). These proposals require a <em>signed</em> transaction from the sponsor's account, which is not possible from an AA contract, because it has no private key to sign with. The main advantage of new transaction types is that the validity requirements are enforced by the protocol, therefore invalid transactions do not pollute block space.</p> <p>The other main approach is to introduce a new mechanism in the EVM to masquerade as other accounts. This EIP introduces <code>AUTH</code> and <code>AUTHCALL</code> to make calls as EOAs. There are many different permutations of this mechanism. An alternative mechanism would be to add an opcode that can make arbitrary calls based on a similar address creation scheme as <code>CREATE2</code>. Although this mechanism would not benefit users today, it would immediately allow for those accounts to send and receive ether -- making it feel like a more first-class primitive.</p> <p>Besides better compatibility with AA, introducing a new mechanism into the EVM is a much less intrusive change than a new transaction type. This approach requires no changes in existing wallets, and little change in other tooling.</p> <p><code>AUTHCALL</code>'s single deviation from <code>CALL</code> is to set <code>CALLER</code>. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes <code>AUTHCALL</code> significantly more composable with existing Ethereum features.</p> <p>More logic can be implemented around the <code>AUTHCALL</code> instruction, giving more control to invokers and sponsors without sacrificing security or user experience for sponsees.</p> <h3 id="what-to-sign">What to Sign?</h3> <p>As originally written, this proposal specified a precompile with storage to track nonces. Since a precompile with storage is unprecedented, a revision moved replay protection into the invoker contract, necessitating a certain level of user trust in the invoker. Expanding on this idea of trusted invokers, the other signed fields were eventually eliminated, one by one, until only <code>invoker</code> and <code>commit</code> remained. To appease concerns about cross-chain replay attacks and irrevocable signatures, the <code>chainId</code> and <code>nonce</code> fields returned to the signed message.</p> <p>The <code>invoker</code> binds a particular signed message to a single invoker. If invoker was not part of the message, any invoker could reuse the signature to completely compromise the EOA. This allows users to trust that their message will be validated as they expect, particularly the values committed to in <code>commit</code>.</p> <h3 id="understanding-commit">Understanding <code>commit</code></h3> <p>Earlier iterations of this EIP included mechanisms for replay protection, and also signed over value, gas, and other arguments to <code>AUTHCALL</code>. After further investigation, we revised this EIP to its current state: explicitly delegate these responsibilities to the invoker contract.</p> <p>A user will specifically interact with an invoker they trust. Because they trust this contract to execute faithfully, they will "commit" to certain properties of a call they would like to make by computing a hash of the call values. They can be certain that the invoker will only allow the call to proceed if it is able to verify the values committed to (e.g. a nonce to protect against replay attacks). This certainty arises from the <code>commit</code> value that is signed over by the user. This is the hash of values which the invoker will validate. A safe invoker should accept the values from the user and compute the commit hash itself. This ensures that invoker operated on the same input that user authorized.</p> <p><img src="https://wg-eips.ritovision.com/3074/./assets/auth-msg.png" alt="auth message format" /></p> <p>Using <code>commit</code> as a hash of values allows for invokers to implement arbitrary constraints. For example, they could allow accounts to have <code>N</code> parallel nonces. Or, they could allow a user to commit to multiple calls with a single signature. This would allow multi-tx flows, such as <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> <code>approve</code>-<code>transfer</code> actions, to be condensed into a single transaction with a single signature verification. A commitment to multiple calls would look something like the diagram below.</p> <p><img src="https://wg-eips.ritovision.com/3074/./assets/auth-msg-multi-call.png" alt="multi-call auth message" /></p> <p>Another interesting use is to delegate control of the EOA to other key(s). This would mean the EOA signs a <code>commit</code> message with the address of the key(s) and an access policy, if applicable. When the delegate wants to make a call as the EOA it will construct a signature over the invoker-specified call format and relay it (with the actual call data) onto chain with the signature and commit that granted it access to the account. The invoker will then be able to determine that the EOA has allowed this alternative key to make calls on its behalf.</p> <p><img src="https://wg-eips.ritovision.com/3074/./assets/auth-msg-delegate.png" alt="delegate auth message" /></p> <h3 id="invoker-contracts">Invoker Contracts</h3> <p>The invoker contract is a trustless intermediary between the sponsor and sponsee. A sponsee signs over <code>invoker</code> to require the transaction to be processed only by a contract they trust. This allows them to interact with sponsors without needing to trust them.</p> <p>Choosing an invoker is similar to choosing a smart contract wallet implementation. It's important to choose one that has been thoroughly reviewed, tested, and accepted by the community as secure. We expect a few invoker designs to be utilized by most major transaction relay providers, with a few outliers that offer more novel mechanisms.</p> <p>An important note is that invoker contracts <strong>MUST NOT</strong> be upgradeable. If an invoker can be redeployed to the same address with different code, it would be possible to redeploy the invoker with code that does not properly verify <code>commit</code> and any account that signed a message over that invoker would be compromised. Although this sounds scary, it is no different than using a smart contract wallet via <code>DELEGATECALL</code>. If the wallet is redeployed with different logic, all wallets using its code could be compromised.</p> <h3 id="on-call-depth">On Call Depth</h3> <p>The EVM limits the maximum number of nested calls, and naively allowing a sponsor to manipulate the call depth before reaching the invoker would introduce a griefing attack against the sponsee. That said, with the 63/64th gas rule, and the cost of <code>AUTHCALL</code>, the stack is effectively limited to a much smaller depth than the hard maximum by the <code>gas</code> parameter.</p> <p>It is, therefore, sufficient for the invoker to guarantee a minimum amount of gas, because there is no way to reach the hard maximum call depth with any reasonable (i.e. less than billions) amount of gas.</p> <h3 id="source-of-value">Source of <code>value</code></h3> <p>In previous iterations of this EIP, it was thought that deducting value from an EOA mid-execution was problematic. This was due to an invariant of pending transactions which allows tx pools to statically determine the validity of a given transaction.</p> <p>However, after further investigation we found that breaking the invariant is safe. This is mostly due to the fact that the worst case is similar in both instances.</p> <p>Currently an attacker can queue many transactions in the tx pool, across many accounts, and invalidate them all at once with a block where each of the queued accounts send a tx moving their entire balance. This attack will become easier and cheaper after this EIP, because it will no longer require direct access to the block builder and will not cost a full 21000 gas to originate each tx. However, the attack does not have a substantial impact on the network, so reducing the difficulty and cost is not of concern.</p> <h3 id="allowing-tx-origin-as-signer">Allowing <code>tx.origin</code> as Signer</h3> <p>Allowing <code>authorized</code> to equal <code>tx.origin</code> enables simple transaction batching, where the sender of the outer transaction would be the signing account. The ERC-20 approve-then-transfer pattern, which currently requires two separate transactions, could be completed in a single transaction with this proposal.</p> <p><code>AUTH</code> allows for signatures to be signed by <code>tx.origin</code>. For any such signatures, subsequent <code>AUTHCALL</code>s have <code>msg.sender == tx.origin</code> in their first layer of execution. Without EIP-3074, this situation can only ever arise in the topmost execution layer of a transaction. This EIP breaks that invariant and so affects smart contracts containing <code>require(msg.sender == tx.origin)</code> checks. This check can be used for at least three purposes:</p> <ol> <li>Ensuring that <code>msg.sender</code> is an EOA (given that <code>tx.origin</code> always has to be an EOA). This invariant does not depend on the execution layer depth and, therefore, is not affected.</li> <li>Protecting against atomic sandwich attacks like flash loans, that rely on the ability to modify state before and after the execution of the target contract as part of the same atomic transaction. This protection would be broken by this EIP. However, relying on <code>tx.origin</code> in this way is considered bad practice, and can already be circumvented by miners conditionally including transactions in a block.</li> <li>Preventing reentrancy.</li> </ol> <p>Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal.) On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive.</p> <p>This distribution of occurrences—many (1), some (2), and no (3)—is exactly what the authors of this EIP expect, because:</p> <ul> <li>Determining if <code>msg.sender</code> is an EOA without <code>tx.origin</code> is difficult (if not impossible.)</li> <li>The only execution context which is safe from atomic sandwich attacks is the topmost context, and <code>tx.origin == msg.sender</code> is the only way to detect that context.</li> <li>In contrast, there are many direct and flexible ways of preventing reentrancy (ex. using a storage variable.) Since <code>msg.sender == tx.origin</code> is only true in the topmost context, it would make an obscure tool for preventing reentrancy, rather than other more common approaches.</li> </ul> <p>There are other approaches to mitigate this restriction which do not break the invariant:</p> <ul> <li>Set <code>tx.origin</code> to a constant <code>ENTRY_POINT</code> address for <code>AUTHCALL</code>s.</li> <li>Set <code>tx.origin</code> to the invoker address for <code>AUTHCALL</code>s.</li> <li>Set <code>tx.origin</code> to a special address derived from any of the sender, invoker, and/or signer addresses.</li> <li>Disallow <code>authorized == tx.origin</code>. This would make the simple batching use cases impossible, but could be relaxed in the future.</li> </ul> <h3 id="authcall-cheaper-than-call-when-sending-value"><code>AUTHCALL</code> cheaper than <code>CALL</code> when sending value</h3> <p>Sending non-zero value with <code>CALL</code> increases its cost by 9,000. Of that, 6,700 covers the increased overhead of the balance transfer and 2,300 is used as a stipend into the subcall to seed its gas counter. <code>AUTHCALL</code> does not provide a stipend and thus only charges the base 6,700.</p> <h3 id="in-protocol-revocation">In-Protocol Revocation</h3> <p>This EIP has gone <a href="https://wg-eips.ritovision.com/3074/#what-to-sign">back and forth</a> on how to deal with <code>AUTH</code> message revocation. Without revocation, this EIP is a supremely powerful and flexible primitive for developers. However, it does have risk for users who use insecure and/or actively malicious invokers.</p> <p>Much of the risk is due to the new ability for users to batch many operations in a single transaction. It becomes easier for an account to be drained. This is a risk that will continue to grow, regardless of the adoption of this EIP, due to overwhelming desire for the feature and attempts to support it at the protocol level and at the app level.</p> <p>A new class of risk is introduced for insecure and buggy invokers. If an invoker has implemented replay protection, as per the authors' recommendation, this should substantially contain the blast radius. However, if the bug allows an adversary to circumvent the replay protection mechanism, it may give them full access to any EOA which has interacted with the vulnerable invoker.</p> <p>Although this is a truly catastrophic event which is not expected to be possible via reputable wallets, it is a serious consideration. Without in-protocol revocation, users have no way to remove their account from the vulnerable invoker.</p> <p>For this reason, <code>AUTH</code> requires the <code>nonce</code> in the message to be equal to the signer's current nonce. This way, a single tx from the EOA will cause the nonce to increase, invalidating all outstanding authorizations.</p> <h3 id="failing-on-extcodesize-check">Failing on <code>EXTCODESIZE</code> check</h3> <p>In <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a>, it was determined that the protocol should reject any transaction which originates from an account with code. Although this EIP focused on transaction origination, the authors of EIP-3074 feel the intention is clear: an account that has both code and a known private key should not be allowed to make arbitrary calls on behalf of said account. Therefore, the property is upheld in this EIP. For full rationale, please refer to <a href="https://wg-eips.ritovision.com/3607/">EIP-3607</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Although this EIP poses no issues for backwards compatibility, there are concerns that it limits future changes to accounts by further enshrining ECDSA signatures. For example, it might be desirable to eradicate the concept of EOAs altogether, and replace them with smart contract wallets that emulate the same behavior. This is fully compatible with the EIP as written, however, it gets tricky if users can then elect to "upgrade" their smart contract wallets to use other methods of authentication -- e.g. convert into a multi-sig. Without any changes, <code>AUTH</code> would not respect this new logic and continue allowing the old private key to perform actions on behalf of the account.</p> <p>A solution to this would be at the same time that EOAs are removed, to modify the logic of <code>AUTH</code> to actually call into the account with some standard message and allow the account to determine if the signature / witness is valid. Further research should be done to understand how invokers would need to change in this situation and how best to write them in a future-compatible manner.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="secure-invokers">Secure Invokers</h3> <p>The following is a non-exhaustive list of checks/pitfalls/conditions that invokers <em>should</em> be wary of:</p> <ul> <li>Replay protection (ex. a nonce) should be implemented by the invoker, and included in <code>commit</code>. Without it, a malicious actor can reuse a signature, repeating its effects.</li> <li><code>value</code> should be included in <code>commit</code>. Without it, a malicious sponsor could cause unexpected effects in the callee.</li> <li><code>gas</code> should be included in <code>commit</code>. Without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.</li> <li><code>addr</code> and <code>calldata</code> should be included in <code>commit</code>. Without them, a malicious actor may call arbitrary functions in arbitrary contracts.</li> </ul> <p>A poorly implemented invoker can <em>allow a malicious actor to take near complete control over a signer's EOA</em>.</p> <h3 id="allowing-tx-origin-as-signer-1">Allowing <code>tx.origin</code> as Signer</h3> <p>Allowing <code>authorized</code> to equal <code>tx.origin</code> has the possibility to:</p> <ul> <li>Break atomic sandwich protections which rely on <code>tx.origin</code>;</li> <li>Break reentrancy guards of the style <code>require(tx.origin == msg.sender)</code>.</li> </ul> <p>The authors of this EIP believe the risks of allowing <code>authorized</code> to equal <code>tx.origin</code> are acceptable for the reasons outlined in the Rationale section.</p> <h3 id="sponsored-transaction-relayers">Sponsored Transaction Relayers</h3> <p>It is possible for the <code>authorized</code> account to cause sponsored transaction relayers to spend gas without being reimbursed by either invalidating the authorization (i.e. increasing the account's nonce) or by sweeping the relevant assets out of the account. Relayers should be designed with these cases in mind, possibly by requiring a bond to be deposited or by implementing a reputation system.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-10-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Youssef El Housnihttps://github.com/yelhousni Michael Connorhttps://github.com/iAmMichaelConnor Aurore Guillevicaurore.guillevic@inria.fr hujw77https://github.com/hujw77 https://wg-eips.ritovision.com/3026/

Precompiles for BW6-761 curve operations

<h2 id="abstract">Abstract</h2> <p>This precompile adds operations for the BW6-761 curve (from the EY/Inria <strong>Optimized and secure pairing-friendly elliptic curves suitable for one layer proof composition</strong> research paper) as a precompile in a set necessary to <em>efficiently</em> perform verification of one-layer composed zkSNARKs proofs. If <code>block.number &gt;= X</code> we introduce <em>seven</em> separate precompiles to perform the following operations (addresses to be determined):</p> <ul> <li>BW6_G1_ADD - to perform point addition on a curve defined over a prime field</li> <li>BW6_G1_MUL - to perform point multiplication on a curve defined over a prime field</li> <li>BW6_G1_MULTIEXP - to perform multiexponentiation on a curve defined over a prime field</li> <li>BW6_G2_ADD - to perform point addition on a curve twist defined the base a prime field</li> <li>BW6_G2_MUL - to perform point multiplication on a curve twist defined over a prime field</li> <li>BW6_G2_MULTIEXP - to perform multiexponentiation on a curve twist defined over a prime field</li> <li>BW6_PAIRING - to perform a pairing operations between a set of <em>pairs</em> of (G1, G2) points</li> </ul> <p>The multiexponentiation operations are a generalization of point multiplication, but separate precompiles are prosposed because running a single MUL through MULTIEXP seems to be 20% more expensive.</p> <h2 id="motivation">Motivation</h2> <p>This EIP is based on and tends to replace matter-labs' proposal for significant performance reasons. In most applications, BW6-761 is used as an outer curve to BLS12-377 considered in <a href="https://wg-eips.ritovision.com/2539/">EIP-2539</a>. The motivation of this precompile is to allow efficient one-layer composition of SNARK proofs. Currently this is done by Zexe using the BLS12-377/CP6-782 pair of curves. This precompile proposes a replacement of CP6-782 by BW6-761, which allows much faster operations. For example, it was shown that verifying a Groth16 proof with BW6-761 is 30 times faster than with CP6-782.</p> <h3 id="proposed-addresses-table">Proposed addresses table</h3> <table><thead><tr><th>Precompile</th><th>Address</th></tr></thead><tbody> <tr><td>BW6_G1_ADD</td><td>0x1e</td></tr> <tr><td>BW6_G1_MUL</td><td>0x1f</td></tr> <tr><td>BW6_G1_MULTIEXP</td><td>0x20</td></tr> <tr><td>BW6_G2_ADD</td><td>0x21</td></tr> <tr><td>BW6_G2_MUL</td><td>0x22</td></tr> <tr><td>BW6_G2_MULTIEXP</td><td>0x23</td></tr> <tr><td>BW6_PAIRING</td><td>0x24</td></tr> </tbody></table> <h2 id="specification">Specification</h2> <p>Curve parameters:</p> <p>The BW6-761 <code>y^2=x^3-1</code> curve is fully defined by the following set of parameters:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Base field modulus = 0x122e824fb83ce0ad187c94004faff3eb926186a81d14688528275ef8087be41707ba638e584e91903cebaff25b423048689c8ed12f9fd9071dcd3dc73ebff2e98a116c25667a8f8160cf8aeeaf0a437e6913e6870000082f49d00000000008b</span></span> <span class="giallo-l"><span>A coefficient = 0x0</span></span> <span class="giallo-l"><span>B coefficient = 0x122e824fb83ce0ad187c94004faff3eb926186a81d14688528275ef8087be41707ba638e584e91903cebaff25b423048689c8ed12f9fd9071dcd3dc73ebff2e98a116c25667a8f8160cf8aeeaf0a437e6913e6870000082f49d00000000008a</span></span> <span class="giallo-l"><span>Main subgroup order = 0x1ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508c00000000001</span></span> <span class="giallo-l"><span>Extension tower:</span></span> <span class="giallo-l"><span>Fp3 construction: (Fp3 = Fp[u]/u^3+4)</span></span> <span class="giallo-l"><span>Fp cubic non-residue = 0x122e824fb83ce0ad187c94004faff3eb926186a81d14688528275ef8087be41707ba638e584e91903cebaff25b423048689c8ed12f9fd9071dcd3dc73ebff2e98a116c25667a8f8160cf8aeeaf0a437e6913e6870000082f49d000000000087</span></span> <span class="giallo-l"><span>Twist parameters:</span></span> <span class="giallo-l"><span>Twist type: M</span></span> <span class="giallo-l"><span>twist curve A coefficient c0 = 0x0</span></span> <span class="giallo-l"><span> c1 = 0x0</span></span> <span class="giallo-l"><span>twist curve B coefficient c0 = 0x4</span></span> <span class="giallo-l"><span> c1 = 0x0</span></span> <span class="giallo-l"><span>Generators:</span></span> <span class="giallo-l"><span>G1:</span></span> <span class="giallo-l"><span>X = 0x1075b020ea190c8b277ce98a477beaee6a0cfb7551b27f0ee05c54b85f56fc779017ffac15520ac11dbfcd294c2e746a17a54ce47729b905bd71fa0c9ea097103758f9a280ca27f6750dd0356133e82055928aca6af603f4088f3af66e5b43d</span></span> <span class="giallo-l"><span>Y = 0x58b84e0a6fc574e6fd637b45cc2a420f952589884c9ec61a7348d2a2e573a3265909f1af7e0dbac5b8fa1771b5b806cc685d31717a4c55be3fb90b6fc2cdd49f9df141b3053253b2b08119cad0fb93ad1cb2be0b20d2a1bafc8f2db4e95363</span></span> <span class="giallo-l"><span>G2:</span></span> <span class="giallo-l"><span>X = 0x110133241d9b816c852a82e69d660f9d61053aac5a7115f4c06201013890f6d26b41c5dab3da268734ec3f1f09feb58c5bbcae9ac70e7c7963317a300e1b6bace6948cb3cd208d700e96efbc2ad54b06410cf4fe1bf995ba830c194cd025f1c</span></span> <span class="giallo-l"><span>Y = 0x17c3357761369f8179eb10e4b6d2dc26b7cf9acec2181c81a78e2753ffe3160a1d86c80b95a59c94c97eb733293fef64f293dbd2c712b88906c170ffa823003ea96fcd504affc758aa2d3a3c5a02a591ec0594f9eac689eb70a16728c73b61</span></span> <span class="giallo-l"><span>Pairing parameters:</span></span> <span class="giallo-l"><span>e(P,Q)=(ML1(P,Q)*ML2(P,Q)^q)^FE</span></span> <span class="giallo-l"><span>|loop_count_1| (first miller loop ML1 count) = 0x8508c00000000002</span></span> <span class="giallo-l"><span>|loop_count_2| (second miller loop ML2 count) = 0x23ed1347970dec008a442f991fffffffffffffffffffffff</span></span> <span class="giallo-l"><span>loop_count_1 is negative = false</span></span> <span class="giallo-l"><span>loop_count_2 is negative = false</span></span></code></pre><h3 id="encoding">Encoding</h3> <h4 id="field-elements-encoding">Field elements encoding:</h4> <p>To encode points involved in the operation one has to encode elements of only the base field.</p> <p>The base field element (Fp) is encoded as <code>96</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer <strong>MUST</strong> be less than the base field modulus.</p> <p>If encodings do not follow this spec anywhere during parsing in the precompile, the precompile <strong>MUST</strong> revert with "endoding error".</p> <h4 id="encoding-of-uncompressed-points">Encoding of uncompressed points:</h4> <p>Points in both G1 and G2 can be expressed as <code>(x, y)</code> affine coordinates, where <code>x</code> and <code>y</code> are elements of the base field. Therefore, points in both G1 and G2 are encoded as the byte concatenation of the field element encodings of the <code>x</code> and <code>y</code> affine coordinates. The total encoding length for a G1/G2 point is thus <code>192</code> bytes.</p> <h4 id="point-at-infinity-encoding">Point at infinity encoding:</h4> <p>Also referred as the "zero point". For BW6-761 (<code>y^2=x^3-1</code>) and its M-twisted curves (<code>y^3=x^3+4</code>), the point with coordinates <code>(0, 0)</code> (formal zeros in Fp) is <em>not</em> on the curve, and so the encoding of <code>(0, 0)</code> is used as a convention to encode the point at infinity.</p> <h4 id="encoding-of-scalars-for-multiplication-and-multiexponentiation-operations">Encoding of scalars for multiplication and multiexponentiation operations:</h4> <p>For multiplication and multiexponentiation operations, a scalar is encoded as <code>64</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer.</p> <p>Note that the main subgroup order for BW6-761 is actually only <code>377</code> bits (<code>48</code> bytes), but an encoding of <code>64</code> bytes has been chosen to have a <code>32</code>-byte-aligned ABI (representable as e.g. <code>bytes32[2]</code> or <code>uint256[2]</code>).</p> <p>The corresponding integer <strong>MAY</strong> be greater than the main subgroup order.</p> <h3 id="abi-for-operations">ABI for operations</h3> <h4 id="abi-for-g1-addition">ABI for G1 addition</h4> <p>G1 addition call expects <code>384</code> bytes as an input that is interpreted as the byte concatenation of two G1 points (point-encoded as <code>192</code> bytes each). Output is a point-encoding of the addition operation result.</p> <p>Error cases:</p> <ul> <li>Either of the points being not on the curve</li> <li>Input has invalid length</li> <li>Field element encoding rules apply (obviously)</li> </ul> <h4 id="abi-for-g1-multiplication">ABI for G1 multiplication</h4> <p>G1 multiplication call expects <code>256</code> bytes as an input that is interpreted as the byte concatenation of the point-encoding of a G1 point (<code>192</code> bytes) and the encoding of a scalar value (<code>64</code> bytes). Output is a point-encoding of the multiplication operation result.</p> <p>Error cases:</p> <ul> <li>Point being not on the curve</li> <li>Input has invalid length</li> <li>Field element encoding rules apply (obviously)</li> <li>Scalar encoding rules apply (obviously)</li> </ul> <h4 id="abi-for-g1-multiexponentiation">ABI for G1 multiexponentiation</h4> <p>G1 multiplication call expects <code>256*k</code> bytes as an input that is interpreted as the byte concatenation of <code>k</code> slices, each of them being a byte concatenation of the point-encoding of a G1 point (<code>192</code> bytes) and the encoding of a scalar value (<code>64</code> bytes). Output is an encoding of the multiexponentiation operation result.</p> <p>Error cases:</p> <ul> <li>Any of the G1 points being not on the curve</li> <li>Input has invalid length</li> <li>Field element encoding rules apply (obviously)</li> <li>Scalar encoding rules apply (obviously)</li> </ul> <h4 id="abi-for-g2-addition">ABI for G2 addition</h4> <p>G2 addition call expects <code>384</code> bytes as an input that is interpreted as the byte concatenation of two G2 points (point-encoded as <code>192</code> bytes each). Output is a point-encoding of the addition operation result.</p> <p>Error cases:</p> <ul> <li>Either of points being not on the curve</li> <li>Input has invalid length</li> <li>Field elements encoding rules apply (obviously)</li> </ul> <h4 id="abi-for-g2-multiplication">ABI for G2 multiplication</h4> <p>G2 multiplication call expects <code>256</code> bytes as an input that is interpreted as the byte concatenation of the point-encoding of a G2 point (<code>192</code> bytes) and the encoding of a scalar value (<code>64</code> bytes). Output is an encoding of multiplication operation result.</p> <p>Error cases:</p> <ul> <li>Point being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g2-multiexponentiation">ABI for G2 multiexponentiation</h4> <p>G2 multiplication call expects <code>240*k</code> bytes as an input that is interpreted as byte concatenation of <code>k</code> slices each of them being a byte concatenation of encoding of G2 point (<code>192</code> bytes) and encoding of a scalar value (<code>48</code> bytes). Output is an encoding of multiexponentiation operation result.</p> <p>Error cases:</p> <ul> <li>Any of G2 points being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-pairing">ABI for pairing</h4> <p>Pairing call expects <code>384*k</code> bytes as an input, that is interpreted as the byte concatenation of <code>k</code> slices. Each slice has the following structure:</p> <ul> <li><code>192</code> bytes G1 point encoding</li> <li><code>192</code> bytes G2 point encoding</li> </ul> <p>Output is <code>32</code> bytes representing a boolean:</p> <ul> <li><code>0x0000000000000000000000000000000000000000000000000000000000000001</code> if the pairing result is equal the to multiplicative identity in the pairing target field; and</li> <li><code>0x0000000000000000000000000000000000000000000000000000000000000000</code> otherwise.</li> </ul> <p>Error cases:</p> <ul> <li>Any of the G1 or G2 points being not on the curve</li> <li>Any of the G1 or G2 points being not in the correct subgroup</li> <li>Input has invalid length</li> <li>Field elements encoding rules apply (obviously)</li> </ul> <h3 id="prevention-of-ddos-on-error-handling">Prevention of DDoS on error handling</h3> <p>This precompile performs extensive computations and in case of any errors during execution it <strong>MUST</strong> consume all gas from the gas schedule for the corresponding operation.</p> <h3 id="gas-schedule">Gas schedule</h3> <h4 id="g1-addition">G1 addition</h4> <p><code>180</code> gas</p> <h4 id="g1-multiplication">G1 multiplication</h4> <p><code>64000</code> gas</p> <h4 id="g2-addition">G2 addition</h4> <p><code>180</code> gas</p> <h4 id="g2-multiplication">G2 multiplication</h4> <p><code>64000</code> gas</p> <h4 id="g1-g2-multiexponentiation">G1/G2 Multiexponentiation</h4> <p>Discounts table as a vector of pairs <code>[k, discount]</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[[1, 1266], [2, 733], [3, 561], [4, 474], [5, 422], [6, 387], [7, 362], [8, 344], [9, 329], [10, 318], [11, 308], [12, 300], [13, 296], [14, 289], [15, 283], [16, 279], [17, 275], [18, 272], [19, 269], [20, 266], [21, 265], [22, 260], [23, 259], [24, 256], [25, 255], [26, 254], [27, 252], [28, 251], [29, 250], [30, 249], [31, 249], [32, 220], [33, 228], [34, 225], [35, 223], [36, 219], [37, 216], [38, 214], [39, 212], [40, 209], [41, 209], [42, 205], [43, 203], [44, 202], [45, 200], [46, 198], [47, 196], [48, 199], [49, 195], [50, 192], [51, 192], [52, 191], [53, 190], [54, 187], [55, 186], [56, 185], [57, 184], [58, 184], [59, 181], [60, 181], [61, 181], [62, 180], [63, 178], [64, 179], [65, 176], [66, 177], [67, 176], [68, 175], [69, 174], [70, 173], [71, 171], [72, 171], [73, 170], [74, 170], [75, 169], [76, 168], [77, 168], [78, 167], [79, 167], [80, 166], [81, 165], [82, 167], [83, 166], [84, 166], [85, 165], [86, 165], [87, 164], [88, 164], [89, 163], [90, 163], [91, 162], [92, 162], [93, 160], [94, 163], [95, 159], [96, 162], [97, 159], [98, 160], [99, 159], [100, 159], [101, 158], [102, 158], [103, 158], [104, 158], [105, 157], [106, 157], [107, 156], [108, 155], [109, 155], [110, 156], [111, 155], [112, 155], [113, 154], [114, 155], [115, 154], [116, 153], [117, 153], [118, 153], [119, 152], [120, 152], [121, 152], [122, 152], [123, 151], [124, 151], [125, 151], [126, 151], [127, 151], [128, 150]]</span></span></code></pre> <p><code>max_discount = 150</code></p> <h4 id="pairing-operation">Pairing operation</h4> <p>Base cost of the pairing operation is <code>120000*k + 320000</code> where <code>k</code> is a number of pairs.</p> <h2 id="rationale">Rationale</h2> <p>Gas costs are based on <a href="https://wg-eips.ritovision.com/1962/">EIP-1962</a> estimation strategy (but do not fully include yet parsing of ABI, decoding and encoding of the result as a byte array).</p> <h3 id="gas-estimation-strategy">Gas estimation strategy</h3> <p>Gas cost is derived by taking the average timing of the same operations over different implementations and assuming a constant <code>30 MGas/second</code>. Since the execution time is machine-specific, this constant is determined based on execution times of <em>ECRECOVER</em> and <em>BNPAIR</em> precompiles on my machine and their proposed gas price (<code>43.5 MGas/s</code> for ECRECOVER and <code>16.5 MGas/s</code> for BNPAIR). Following are the proposed methods to time the precompile operations:</p> <ul> <li>G1 addition: Average timing of 1000 random samples.</li> <li>G1 multiplication: Average timing of 1000 samples of random worst-case of double-and-add algorithm (scalar of max bit length and max hamming weight and random base points in G1)</li> <li>G2 addition: Average timing of 1000 random samples</li> <li>G2 multiplication: Average timing of 1000 samples of random worst-case of double-and-add algorithm (scalar of max bit length and max hamming weight and random base points in G2)</li> <li>G1 and G2 multiexponentiations: Expected to be performed by the Peppinger algorithm, with a table prepared for discount in case of <code>k &lt;= 128</code> points in the multiexponentiation with a discount cup <code>max_discount</code> for <code>k &gt; 128</code>. To avoid non-integer arithmetic call cost is calculated as <code>k * multiplication_cost * discount / multiplier</code> where <code>multiplier = 1000</code>, <code>k</code> is a number of (scalar, point) pairs for the call, <code>multiplication_cost</code> is a corresponding single multiplication call cost for G1/G2.</li> <li>Pairing: Average timing of 1000 random samples (random points in G1 and G2) for different number of pairs with linear lifting.</li> </ul> <h3 id="multiexponentiation-as-a-separate-call">Multiexponentiation as a separate call</h3> <p>Explicit separate multiexponentiation operation that allows one to save execution time (so gas) by both the algorithm used (namely Peppinger algorithm) and (usually forgotten) by the fact that <code>CALL</code> operation in Ethereum is expensive (at the time of writing), so one would have to pay non-negigible overhead if e.g. for multiexponentiation of <code>100</code> points would have to call the multiplication precompile <code>100</code> times and addition for <code>99</code> times (roughly <code>138600</code> would be saved).</p> <h3 id="explicit-subgroup-checks">Explicit subgroup checks</h3> <p>G2 subgroup check has the same cost as G1 subgroup check. Endomorphisms can be leverages to optimize this operation.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backward compatibility questions.</p> <h2 id="test-cases">Test Cases</h2> <p>Due to the large test parameters space we first provide properties that various operations must satisfy. We use additive notation for point operations, capital letters (<code>P</code>, <code>Q</code>) for points, small letters (<code>a</code>, <code>b</code>) for scalars. Generator for G1 is labeled as <code>G</code>, generator for G2 is labeled as <code>H</code>, otherwise we assume random point on a curve in a correct subgroup. <code>0</code> means either scalar zero or point of infinity. <code>1</code> means either scalar one or multiplicative identity. <code>group_order</code> is a main subgroup order. <code>e(P, Q)</code> means pairing operation where <code>P</code> is in G1, <code>Q</code> is in G2.</p> <p>Requeired properties for basic ops (add/multiply):</p> <ul> <li>Commutativity: <code>P + Q = Q + P</code></li> <li>Additive negation: <code>P + (-P) = 0</code></li> <li>Doubling <code>P + P = 2*P</code></li> <li>Subgroup check: <code>group_order * P = 0</code></li> <li>Trivial multiplication check: <code>1 * P = P</code></li> <li>Multiplication by zero: <code>0 * P = 0</code></li> <li>Multiplication by the unnormalized scalar <code>(scalar + group_order) * P = scalar * P</code></li> </ul> <p>Required properties for pairing operation:</p> <ul> <li>Degeneracy <code>e(P, 0*Q) = e(0*P, Q) = 1</code></li> <li>Bilinearity <code>e(a*P, b*Q) = e(a*b*P, Q) = e(P, a*b*Q)</code> (internal test, not visible through ABI)</li> </ul> <h2 id="reference-implementation">Reference Implementation</h2> <p>There is a various choice of existing implementations:</p> <p><strong>Libraries:</strong></p> <ul> <li>Rust implementation (EY/Zexe): github.com/yelhousni/zexe/tree/youssef/BW6-761-Fq-ABLR-2ML-M</li> <li>C++ implementation (EY/libff): github.com/EYBlockchain/zk-swap-libff</li> <li>Golang implementation (Consensys/gurvy): github.com/ConsenSys/gurvy</li> </ul> <p><strong>Stand-alone implementation:</strong></p> <ul> <li>Golang implementation with Intel assembly (Onur Kilic): github.com/kilic/bw6</li> </ul> <p><strong>Precompiles:</strong></p> <ul> <li>OpenEthereum (EY/Parity): github.com/EYBlockchain/solidity-elliptic-curves</li> <li>Frontier (Parity): github.com/paritytech/frontier/pull/1049/files</li> </ul> <p><strong>Scripts:</strong></p> <ul> <li>SageMath and Magma scripts: gitlab.inria.fr/zk-curves/bw6-761/</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Strictly following the spec will eliminate security implications or consensus implications in a contrast to the previous BN254 precompile.</p> <p>Important topic is a "constant time" property for performed operations. We explicitly state that this precompile <strong>IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Sergio Demian Lernerhttps://github.com/SergioDemianLerner https://wg-eips.ritovision.com/2997/ <h2 id="abstract">Abstract</h2> <p>Add a new opcode, <code>IMPERSONATECALL</code> at <code>0xf6</code>, which is similar in idea to <code>CALL (0xF1)</code>, except that it impersonates a sender, i.e. the callee sees a sender different from the real caller. The impersonated sender address is derived from the real caller address and a salt.</p> <h2 id="motivation">Motivation</h2> <p>This proposal enables native multi-user wallets (wallets that serve multiple users) that can be commanded by EIP-712 based messages and therefore enable meta-transactions. Multi-user wallets also enable the aggregation of transfer operations in batches similar to rollups, but maintaining the same address space as normal onchain transactions, so the sender's wallet does not need to be upgraded to support sinding ether or tokens to a user of a multi-user wallet. Additionally, many times a sponsor company wants to deploy non-custodial smart wallets for all its users. The sponsor does not want to pay the deployment cost of each user contract in advance. Counterfactual contract creation enables this, yet it forces the sponsor to create the smart wallet (or a proxy contract to it) when the user wants to transfer ether or tokens out of his/her account for the first time. This proposal avoids this extra cost, which is at least 42000 gas per user.</p> <h2 id="specification">Specification</h2> <p><code>IMPERSONATECALL</code>: <code>0xf6</code>, takes 7 operands:</p> <ul> <li><code>gas</code>: the amount of gas the code may use in order to execute;</li> <li><code>to</code>: the destination address whose code is to be executed;</li> <li><code>in_offset</code>: the offset into memory of the input;</li> <li><code>in_size</code>: the size of the input in bytes;</li> <li><code>ret_offset</code>: the offset into memory of the output;</li> <li><code>ret_size</code>: the size of the scratch pad for the output.</li> <li><code>salt</code> is a <code>32</code> bytes value (a stack item).</li> </ul> <h3 id="computation-of-impersonated-sender">Computation of impersonated sender</h3> <p>The impersonated sender address is computed as <code>keccak256( 0xff ++ address ++ salt ++ zeros32)[12:]</code>.</p> <ul> <li> <p><code>0xff</code> is a single byte,</p> </li> <li> <p><code>address</code> is always <code>20</code> bytes, and represents the address of the real caller contract.</p> </li> <li> <p><code>salt</code> is always <code>32</code> bytes.</p> </li> <li> <p>The field zeros32 corresponds to 32 zero bytes.</p> </li> </ul> <p>This scheme emulates <code>CREATE2</code> address derivation, but it cannot practically collude with the <code>CREATE2</code> address space.</p> <h3 id="notes">Notes</h3> <ul> <li>The opcode behaves exactly as <code>CALL</code> in terms of gas consumption.</li> <li>In the called context <code>CALLER (0x33)</code> returns the impersonated address.</li> <li>If value transfer is non-zero in the call, the value is transferred from the impersonated account, and not from the real caller. This can be used to transfer ether out of an impersonated account.</li> </ul> <h2 id="rationale">Rationale</h2> <p>Even if <code>IMPERSONATECALL</code> requires hashing 3 words, implying an additional cost of 180 gas, we think the benefit of accounting for hashing doesn't not compensate increasing the complexity of the implementation.</p> <p>We use the zeros32 field to base address derivation in a pre-image of similar size than CREATE2 and reuse the existing address derivation functions. We also avoid worrying about address collisions between EOA derivation (65 bytes pre-image), CREATE derivation (from 23 to 27 bytes pre-image, for a 32bit nonce) and CREATE2 derivation (85 bytes pre-image).</p> <p>An option is to omit the zeros32 field: the resulting length of the Keccak pre-image for IMPERSONATECALL address is 53 bytes , which does not generate address collision.</p> <p>While the same functionality could be provided in a pre-compiled contract, we believe using a new opcode is a cleaner solution.</p> <h2 id="clarifications">Clarifications</h2> <ul> <li> <p>This EIP makes address collisions possible, yet practically impossible.</p> </li> <li> <p>If a contract already exists with an impersonated address, the <code>IMPERSONATECALL</code> is executed in the same way, and the existing code will not be executed. It should be noted that <code>SELFDESTRUCT</code> (<code>0xff</code>) cannot be executed directly with <code>IMPERSONATECALL</code> as no opcode is executed in the context of the impersonated account.</p> </li> </ul> <h2 id="backward-compatibility">Backward Compatibility</h2> <p>The opcode number <code>0xf6</code> is currently unused and results in an out-of-gas (OOG) exception. Solidity uses the <code>INVALID (0xfe)</code> opcode (called <code>ABORT</code> by EIP-1803) to raise OOG exceptions, so the <code>0xf6</code> opcode does not appear in normal Solidity programs. Programmers are already advised not to include this opcode in contracts written in EVM assembly. Therefore is does not pose any backward compatibility risk.</p> <h2 id="test-cases">Test Cases</h2> <p>We present 4 examples of impersonated address derivation:</p> <p>Example 0</p> <ul> <li>address <code>0x0000000000000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>result: <code>0xFFC4F52F884A02BCD5716744CD622127366F2EDF</code></li> </ul> <p>Example 1</p> <ul> <li>address <code>0xdeadbeef00000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>result: <code>0x85F15E045E1244AC03289B48448249DC0A34AA30</code></li> </ul> <p>Example 2</p> <ul> <li>address <code>0xdeadbeef00000000000000000000000000000000</code></li> <li>salt <code>0x000000000000000000000000feed000000000000000000000000000000000000</code></li> <li>result: <code>0x2DB27D1D6BE32C9ABFA484BA3D591101881D4B9F</code></li> </ul> <p>Example 3</p> <ul> <li>address <code>0x00000000000000000000000000000000deadbeef</code></li> <li>salt <code>0x00000000000000000000000000000000000000000000000000000000cafebabe</code></li> <li>result: <code>0x5004E448F43EFE3C7BF32F94B83B843D03901457</code></li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>The address derivation scheme prevents address collision with another deployed contract or an externally owned account, as the impersonated sender address is derived from the real caller address and a salt.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/2970/ <h2 id="simple-summary">Simple Summary</h2> <p>Add a <code>IS_STATIC (0x4A)</code> opcode that pushes <code>1</code> if the current context is static (ie. the execution is in a <code>STATICCALL</code> or a descendant thereof, so state-changing operations are not possible), and <code>0</code> if it is not.</p> <h2 id="abstract">Abstract</h2> <h2 id="motivation">Motivation</h2> <p>The main intended use case is to allow account abstraction (EIP 2938) to be extended so that accounts can allow static calls from the outside (which are harmless to AA's security model) but not state-changing calls.</p> <h2 id="specification">Specification</h2> <p>Add a <code>IS_STATIC (0x4A)</code> opcode that pushes <code>1</code> if the current context is static (ie. the execution is in a <code>STATICCALL</code> or a descendant thereof, so state-changing operations are not possible), and <code>0</code> if it is not.</p> <h2 id="rationale">Rationale</h2> <p>Determining staticness is already possibly using the following hacky technique: make a <code>CALL</code> with limited gas, and inside that <code>CALL</code> issue one <code>LOG</code> and exit. If the context is static, the <code>CALL</code> would fail and leave a 0 on the stack; if the context is non-static, the <code>CALL</code> would succeed. However, this technique is fragile against changes to gas costs, and is needlessly wasteful. Hence, the status quo neither allows a reasonably effective way of determining whether or not the context is static, nor provides any kind of invariant that executions that do not fail outright will execute the same way in a static and non-static context. This EIP provides a cleaner way of determining staticness.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-12T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/2972/ <h2 id="simple-summary">Simple Summary</h2> <p>Two new transaction types for wrapping legacy transactions with and without a chain ID.</p> <h2 id="abstract">Abstract</h2> <p>Introduces two new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transactions that are signature compatible with legacy transactions and can be automatically upgraded by any client.</p> <ul> <li><code>0x00 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data]))</code></li> <li><code>0x01 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0]))</code></li> </ul> <h2 id="motivation">Motivation</h2> <p>We would like to eventually deprecate legacy transactions so we no longer have to retain code in the networking and signer layer that deals with them. However, we also want to ensure that signatures for transactions that were generated prior to that deprecation are still valid and funds don't end up stuck because of an inability to sign a new style transaction. This EIP provides a mechanism for transmitting/including transactions in a way that is <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> compatible while still being signature compatible with legacy transactions.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <ul> <li><code>||</code> is the byte/byte-array concatenation operator.</li> <li><code>yParity</code> is the parity (0 for even, 1 for odd) of the <code>y</code> value of the curve point for which <code>r</code> is the <code>x</code> value in the secp256k1 signing process.</li> </ul> <h3 id="transactions">Transactions</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>0x00 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data]))</code> will be a valid transaction where:</p> <ul> <li>the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding</li> <li>TODO: Hashing or Merkleizing for block transaction root</li> </ul> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>0x01 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0]))</code> will be a valid transaction where:</p> <ul> <li>the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding</li> <li>TODO: Hashing or Merkleizing for block transaction root</li> </ul> <p>The SSZ schema for both transaction types is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Transaction[</span></span> <span class="giallo-l"><span> yParity: boolean,</span></span> <span class="giallo-l"><span> r: bytes32,</span></span> <span class="giallo-l"><span> s: bytes32,</span></span> <span class="giallo-l"><span> signedData: bytes,</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>Note: <code>sszencode(yParity, r, s, rlp(...))</code> is the same as <code>yParity || r || s || 0x45000000 || rlp(...)</code></p> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>rlp(nonce, gasPrice, gasLimit, to, value, data, v, r, s)</code> will no longer be a valid transaction in a block.</p> <h3 id="receipts">Receipts</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>0 || ssz.serialize(status, cumulativeGasUsed, logsBloom, logs)</code> will be a valid receipt where:</p> <ul> <li>the <code>ReceiptPayload</code> will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding</li> <li>TODO: Hashing or Merkleizing for block receipt root</li> </ul> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>1 || ssz.serialize(status, cumulativeGasUsed, logsBloom, logs)</code> will be a valid receipt where:</p> <ul> <li>the <code>ReceiptPayload</code> will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding</li> <li>TODO: Hashing or Merkleizing for block receipt root</li> </ul> <p>The SSZ schema for both receipt types is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Log[</span></span> <span class="giallo-l"><span> address: bytes20,</span></span> <span class="giallo-l"><span> topics: List[bytes32, 4],</span></span> <span class="giallo-l"><span> data: List[uint8, 0xffffff],</span></span> <span class="giallo-l"><span>]</span></span> <span class="giallo-l"><span>Receipt[</span></span> <span class="giallo-l"><span> status: uint8,</span></span> <span class="giallo-l"><span> cumulativeGasUsed: uint64,</span></span> <span class="giallo-l"><span> logsBloom: BitVector[2048],</span></span> <span class="giallo-l"><span> logs: List[Log, 0xffffff],</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>As of <code>FORK_BLOCK_NUMBER</code>, <code>rlp(status, cumulativeGasUsed, logsBloom, logs)</code> will no longer be a valid receipt in a block.</p> <h2 id="rationale">Rationale</h2> <h3 id="signature-doesn-t-include-transaction-type-as-first-signature-byte">Signature doesn't include transaction type as first signature byte</h3> <p>These transaction types are explicitly designed to be signature compatible with legacy transactions, which means we cannot change the data being signed. See Security Considerations section for more details.</p> <h3 id="two-transaction-types-instead-of-one">Two transaction types instead of one</h3> <p>With the introduction of typed transactions, we no longer need to do bit packing to avoid changing the shape of the signature. Legacy transactions introduced chain ID in <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> and wanted to avoid changing the transaction array length, so it bitpacked the chainID into the signature's <code>v</code> value. Since we no longer need to guarantee consistent payload lengths between transaction types, we have opted to have two transaction types with clear fields.</p> <h3 id="signature-separate-from-signed-data">Signature separate from signed data</h3> <p>When validating a signature, one must first separate out the signed data from the signature and then validate the signature against the signed data. In the case of legacy transactions, this was a bit of a burden since you had to first RLP decode the transaction, then extract out the signature, then RLP encode a subset of the transaction. EIP-155 made this process even worse by requiring the validator to further decode the <code>v</code> signature value to extract the chain ID (if present) and include that in the signed data payload. By having the signed data encoded exactly as it is signed, we make it so one can verify the transaction's signature without having to do any decoding before hand. By having the signature SSZ encoded up front, we can easily extract the signature without even having to use a decoder.</p> <h3 id="ssz-for-serialization">SSZ for serialization</h3> <p>There is a weak consensus that RLP is not a particularly good encoding scheme for hashed data partially due to its inability to be streamed. SSZ is almost certainly going to be included in Ethereum at some point in the future, so clients likely have access to an SSZ decoder. For this particular case, manual decoding without a full SSZ decoder isn't too complicated, though it does require doing a bit of "pointer math" since <code>logs</code> is an array of variable length items.</p> <h3 id="deprecating-legacy-transactions">Deprecating legacy transactions</h3> <p>By deprecating legacy transactions, we make it easier for clients as they can always deal with typed transactions in blocks.</p> <h3 id="max-length-of-logs-and-logs-data">Max length of logs and logs data</h3> <p><a href="https://wg-eips.ritovision.com/706/">EIP-706</a> limits devp2p messages to 24 bit length, which gives us a pragmatic cap at that for any single transaction at the moment. This number seems to far exceed what is reasonable anytime in the near future, so feels like as reasonable of a cap as any.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The new transactions are signature compatible with legacy transactions. Legacy transactions can be decoded and then encoded as type 0 or type 1 transactions. This EIP does not introduce any deprecation process for legacy encoded transactions, though the authors do encourage client developers to upgrade legacy encoded transactions to typed transactions as soon as it is reasonable.</p> <p>The signature compatibility means that a client may see the same transaction encoded both ways. In such a case the client can choose which to retain, but it is encouraged to retain the typed transaction rather than the legacy encoded transaction. Since the two transactions would share a nonce, only one will ever be valid in a chain at a time.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>While <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> strongly recommends including the transaction type as the first byte of the signed data, we cannot accomplish that in this case because we need to remain signature compatible with legacy transactions. Luckily, <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> also excludes transaction types <code>0xc0</code> to <code>0xfe</code> from valid transaction types, and the first byte of the signature in this case is in that range so we can be sure this will not conflict with any future transaction types.</p> <p>A signature for these transaction types <strong>does</strong> collide with legacy transactions, but the transactions will be processed the same so it doesn't matter if the transaction ends up included as a legacy transaction or a typed transaction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/2937/ <h2 id="simple-summary">Simple Summary</h2> <p>Add a <code>SET_INDESTRUCTIBLE (0xA8)</code> opcode that prevents the contract from calling <code>SELFDESTRUCT (0xFF)</code>.</p> <h2 id="abstract">Abstract</h2> <h2 id="motivation">Motivation</h2> <p>The intended use case would be for contracts to make their first byte of code be the <code>SET_INDESTRUCTIBLE</code> opcode if they wish to serve as libraries that guarantee to users that their code will exist unmodified forever. This is useful in account abstraction as well as other contexts.</p> <p>Unlike EIPs that disable the <code>SELFDESTRUCT</code> opcode entirely, this EIP does not modify behavior of any existing contracts.</p> <h2 id="specification">Specification</h2> <p>Add a transaction-wide global variable <code>globals.indestructible: Set[Address]</code> (i.e. a variable that operates the same way as the selfdestructs set), initialized to the empty set.</p> <p>Add a <code>SET_INDESTRUCTIBLE</code> opcode at <code>0xA8</code>, with gas cost <code>G_base</code>, that adds the current <code>callee</code> to the <code>globals.indestructible</code> set. If in the current execution context the <code>callee</code> is in <code>globals.indestructible</code>, the <code>SELFDESTRUCT</code> opcode throws an exception.</p> <h2 id="rationale">Rationale</h2> <p>Alternative proposals to this include:</p> <ul> <li>Simply banning <code>SELFDESTRUCT</code> outright. This would be ideal, but has larger backwards compatibility issues.</li> <li>Using a local variable instead of a global variable. This is problematic because it would be broken by <code>DELEGATECALL</code>.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>This breaks forward compatibility with <em>some</em> forms of state rent, which would simply delete contracts that get too old without paying some maintenance fee. However, this is not the case with all state size control schemes; for example this is not an issue if we use <a rel="external" href="https://ledgerwatch.github.io/regenesis_plan.html">ReGenesis</a>.</p> <p>If <code>SELFDESTRUCT</code> is ever removed in the future, this EIP would simply become a no-op.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Ansgar Dietrichshttps://github.com/adietrichs Matt Garnetthttps://github.com/lightclient Will Villanuevahttps://github.com/villanuevawill Sam Wilsonhttps://github.com/SamWilsn https://wg-eips.ritovision.com/2938/ <h2 id="simple-summary">Simple Summary</h2> <p>Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.</p> <h2 id="abstract">Abstract</h2> <p><strong>See also: <a rel="external" href="https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020">https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020</a> and the links therein for historical work and motivation.</strong></p> <p>Transaction validity, as of Muir Glacier, is defined rigidly by the protocol: ECDSA signature, a simple nonce, and account balance. Account abstraction extends the validity conditions of transactions with the execution of arbitrary EVM bytecode (with some limits on what state may be accessed.) To signal validity, we propose a new EVM opcode <code>PAYGAS</code>, which also sets the gas price and gas limit the contract is willing to pay.</p> <p>We split account abstraction into two tiers: <strong>single-tenant AA</strong>, which is intended to support wallets or other use cases with few participants, and <strong>multi-tenant AA</strong>, which is intended to support applications with many participants (eg. tornado.cash, Uniswap).</p> <h2 id="motivation">Motivation</h2> <p>The existing limitations preclude innovation in a number of important areas, particularly:</p> <ol> <li>Smart contract wallets that use signature verification other than ECDSA (eg. Schnorr, BLS, post-quantum...)</li> <li>Smart contract wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen</li> <li>Privacy-preserving systems like <a rel="external" href="http://tornado.cash">tornado.cash</a></li> <li>Attempts to improve gas efficiency of DeFi protocols by preventing transactions that don't satisfy high-level conditions (eg. existence of a matching order) from being included on chain</li> <li>Users being able to pay for transaction fees in a token other than ETH (eg. by converting that token into the ETH needed for fees inside the transaction in real-time)</li> </ol> <p>Most of the above use cases are currently possible using intermediaries, most notably the <a rel="external" href="https://www.opengsn.org/">Gas Station Network</a> and application-specific alternatives. These implementations are (i) technically inefficient, due to the extra 21000 gas to pay for the relayer, (ii) economically inefficient, as relayers need to make a profit on top of the gas fees that they pay. Additionally, use of intermediary protocols means that these applications cannot simply rely on base Ethereum infrastructure and need to rely on extra protocols that have smaller userbases and higher risk of no longer being available at some future date.</p> <p>Out of the five use cases above, single-tenant AA approximately supports (1) and (2), and multi-tenant AA approximately supports (3) and (4). We discuss the differences between the two tiers in the specification and rationale sections below.</p> <h2 id="specification">Specification</h2> <h3 id="single-tenant">Single Tenant</h3> <p>After <code>FORK_BLOCK</code>, the following changes will be recognized by the protocol.</p> <h4 id="constants">Constants</h4> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><strong><code>AA_ENTRY_POINT</code></strong></td><td><code>0xffffffffffffffffffffffffffffffffffffffff</code></td></tr> <tr><td><strong><code>AA_TX_TYPE</code></strong></td><td><code>2</code></td></tr> <tr><td><strong><code>FORK_BLOCK</code></strong></td><td>TBD</td></tr> <tr><td><strong><code>AA_BASE_GAS_COST</code></strong></td><td>15000</td></tr> </tbody></table> <h4 id="new-transaction-type">New Transaction Type</h4> <p>A new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction with type <code>AA_TX_TYPE</code> is introduced. Transactions of this type are referred to as "AA transactions". Their payload should be interpreted as <code>rlp([nonce, target, data])</code>.</p> <p>The base gas cost of this transaction is set to <code>AA_BASE_GAS_COST</code> instead of 21000 to reflect the lack of "intrinsic" ECDSA and signature.</p> <p>Nonces are processed analogously to existing transactions (check <code>tx.nonce == tx.target.nonce</code>, transaction is invalid if this fails, otherwise proceed and immediately set <code>tx.nonce += 1</code>).</p> <p>Note that this transaction type has no intrinsic gas limit; when beginning execution, the gas limit is simply set to the remaining gas in the block (ie. <code>block.gas_limit</code> minus gas spent on previous transactions), and the <code>PAYGAS</code> opcode (see below) can adjust the gas limit downwards.</p> <h4 id="transaction-wide-global-variables">Transaction-wide global variables</h4> <p>Introduce some new transaction-wide global variables. These variables work similarly (in particular, have similar reversion logic) to the SSTORE refunds counter.</p> <table><thead><tr><th>Variable</th><th>Type</th><th>Initial value</th></tr></thead><tbody> <tr><td><code>globals.transaction_fee_paid</code></td><td><code>bool</code></td><td><code>False if type(tx) == AA_TX_TYPE else True</code></td></tr> <tr><td><code>globals.gas_price</code></td><td><code>int</code></td><td><code>0 if type(tx) == AA_TX_TYPE else tx.gas_price</code></td></tr> <tr><td><code>globals.gas_limit</code></td><td><code>int</code></td><td><code>0 if type(tx) == AA_TX_TYPE else tx.gas_limit</code></td></tr> </tbody></table> <h4 id="nonce-0x48-opcode"><code>NONCE (0x48)</code> Opcode</h4> <p>A new opcode <code>NONCE (0x48)</code> is introduced, with gas cost <code>G_base</code>, which pushes the <code>nonce</code> of the callee onto the stack.</p> <h4 id="paygas-0x49-opcode"><code>PAYGAS (0x49)</code> Opcode</h4> <p>A new opcode <code>PAYGAS (0x49)</code> is introduced, with gas cost <code>G_base</code>. It takes two arguments off the stack: (top) <code>version_number</code>, (second from top) <code>memory_start</code>. In the initial implementation, it will <code>assert version_number == 0</code> and read:</p> <ul> <li><code>gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])</code></li> <li><code>gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])</code></li> </ul> <p>Both reads use similar mechanics to MLOAD and CALL, so memory expands if needed.</p> <p>Future hard forks may add support for different version numbers, in which case the opcode may take different-sized memory slices and interpret them differently. Two particular potential use cases are <a rel="external" href="https://notes.ethereum.org/@vbuterin/BkSQmQTS8">EIP 1559</a> and <a rel="external" href="https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399">the escalator mechanism</a>.</p> <p>The opcode works as follows. If all three of the following conditions (in addition to the version number check above) are satisfied:</p> <ol> <li>The account's balance is <code>&gt;= gas_price * gas_limit</code></li> <li><code>globals.transaction_fee_paid == False</code></li> <li>We are in a top-level AA execution frame (ie. if the currently running EVM execution exits or reverts, the EVM execution of the entire transaction is finished)</li> </ol> <p>Then do the following:</p> <ul> <li>Subtract <code>gas_price * gas_limit</code> from the contract's balance</li> <li>Set <code>globals.transaction_fee_paid</code> to <code>True</code></li> <li>Set <code>globals.gas_price</code> to <code>gas_price</code>, and <code>globals.gas_limit</code> to <code>gas_limit</code></li> <li>Set the remaining gas in the current execution context to equal <code>gas_limit</code> minus the gas that was already consumed</li> </ul> <p>If any of the above three conditions are not satisfied, throw an exception.</p> <p>At the end of execution of an AA transaction, it is mandatory that <code>globals.transaction_fee_paid == True</code>; if it is not, then the transaction is invalid. At the end of execution, the contract is refunded <code>globals.gas_price * remaining_gas</code> for any remaining gas, and <code>(globals.gas_limit - remaining_gas) * globals.gas_price</code> is transferred to the miner.</p> <p><code>PAYGAS</code> also serves as an EVM execution <em>checkpoint</em>: if the top-level execution frame reverts after <code>PAYGAS</code> has been called, then the execution only reverts up to the point right after <code>PAYGAS</code> was called, and exits there. In that case, the contract receives no refund, and <code>globals.gas_limit * globals.gas_price</code> is transferred to the miner.</p> <h4 id="replay-protection">Replay Protection</h4> <p>One of the two following approaches must be implemented to safeguard against replay attacks.</p> <h5 id="require-set-indestructible">Require <code>SET_INDESTRUCTIBLE</code></h5> <p>Require that contracts targeted by AA transactions begin with <a href="https://wg-eips.ritovision.com/2937/">EIP-2937</a>'s <code>SET_INDESTRUCTIBLE</code> opcode. AA transactions targeting contracts that do not begin with <code>SET_INDESTRUCTIBLE</code> are invalid, and cannot be included in blocks.</p> <p><code>AA_PREFIX</code> would need to be modified to include this opcode.</p> <h5 id="preserve-nonce-on-selfdestruct">Preserve Nonce on <code>SELFDESTRUCT</code></h5> <p>The other option is to preserve contract nonces across <code>SELFDESTRUCT</code> invocations, instead of setting the nonce to zero.</p> <h4 id="miscellaneous">Miscellaneous</h4> <ul> <li>If <code>CALLER (0x33)</code> is invoked in the first frame of execution of a call initiated by an AA transaction, then it must return <code>AA_ENTRY_POINT</code>.</li> <li>If <code>ORIGIN (0x32)</code> is invoked in any frame of execution of an AA transaction it must return <code>AA_ENTRY_POINT</code>.</li> <li>The <code>GASPRICE (0x3A)</code> opcode now pushes the value <code>globals.gas_price</code></li> </ul> <p>Note that the new definition of <code>GASPRICE</code> does not lead to any changes in behavior in non-AA transactions, because <code>globals.gas_price</code> is initialized to <code>tx.gas_price</code> and cannot be changed as <code>PAYGAS</code> cannot be called.</p> <h4 id="mining-and-rebroadcasting-strategies">Mining and Rebroadcasting Strategies</h4> <p>Much of the complexity in account abstraction originates from the strategies used by miners and validating nodes to determine whether or not to accept and rebroadcast transactions. Miners need to determine if a transaction will actually pay the fee if they include it after only a small amount of processing to avoid <a rel="external" href="https://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/">DoS attacks</a>. Validating nodes need to perform an essentially identical verification to determine whether or not to rebroadcast the transaction.</p> <p>By keeping the consensus changes minimal, this EIP allows for gradual introduction of AA mempool support by miners and validating nodes. Initial support would be focused on enabling simple, single-tenant use cases, while later steps would additionally allow for more complex, multi-tenant use cases. Earlier stages are deliberately more fully fleshed-out than later stages, as there is still more time before later stages need to be implemented.</p> <h5 id="transactions-with-fixed-nonces">Transactions with Fixed Nonces</h5> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>VERIFICATION_GAS_MULTIPLIER</code></td><td><code>6</code></td></tr> <tr><td><code>VERIFICATION_GAS_CAP</code></td><td><code>= VERIFICATION_GAS_MULTIPLIER * AA_BASE_GAS_COST = 90000</code></td></tr> <tr><td><code>AA_PREFIX</code></td><td><code>if(msg.sender != shr(-1, 12)) { LOG1(msg.sender, msg.value); return }</code>; compilation to EVM TBD</td></tr> </tbody></table> <p>When a node receives an AA transaction, they process it (i.e. attempt to execute it against the current chain head's post-state) to determine its validity, continuing to execute until one of several events happens:</p> <ul> <li>If the code of the <code>target</code> is NOT prefixed with <code>AA_PREFIX</code>, exit with failure</li> <li>If the execution hits any of the following, exit with failure: <ul> <li>An environment opcode (<code>BLOCKHASH</code>, <code>COINBASE</code>, <code>TIMESTAMP</code>, <code>NUMBER</code>, <code>DIFFICULTY</code>, <code>GASLIMIT</code>)</li> <li><code>BALANCE</code> (of any account, including the <code>target</code> itself)</li> <li>An external call/create that changes the <code>callee</code> to anything but the <code>target</code> or a precompile (<code>CALL</code>, <code>CALLCODE</code>, <code>STATICCALL</code>, <code>CREATE</code>, <code>CREATE2</code>).</li> <li>An external state access that reads code (<code>EXTCODESIZE</code>, <code>EXTCODEHASH</code>, <code>EXTCODECOPY</code>, but also <code>CALLCODE</code> and <code>DELEGATECALL</code>), unless the address of the code that is read is the <code>target</code>.</li> </ul> </li> <li>If the execution consumes more gas than <code>VERIFICATION_GAS_CAP</code> (specified above), or more gas than is available in the block, exit with failure</li> <li>If the execution reaches <code>PAYGAS</code>, then exit with success or failure depending on whether or not the balance is sufficient (e.g. <code>balance &gt;= gas_price * gas_limit</code>).</li> </ul> <p>Nodes do not keep transactions with nonces higher than the current valid nonce in the mempool. If the mempool already contains a transaction with a currently valid nonce, another incoming transaction to the same contract and with the same nonce either replaces the existing one (if its gas price is sufficiently higher) or is dropped. Thus, the mempool keeps only at most one pending transaction per account.</p> <p>While processing a new block, take note of which accounts were the <code>target</code> of an AA transaction (each block currently has <code>12500000</code> gas and an AA transaction costs <code>&gt;= 15000</code> so there would be at most <code>12500000 // 15000 = 833</code> targeted accounts). Drop all pending transactions targeting those accounts. All other transactions remain in the mempool.</p> <h3 id="single-tenant-1">Single Tenant+</h3> <p>If the <a rel="external" href="http://github.com/ethereum/EIPs/pull/2937">indestructible contracts EIP</a> is added, Single Tenant AA can be adapted to allow for <code>DELEGATECALL</code> during transaction verification: during execution of a new AA transaction, external state access that reads code (<code>EXTCODESIZE</code>, <code>EXTCODEHASH</code>, <code>EXTCODECOPY</code>, <code>CALLCODE</code>, <code>DELEGATECALL</code>) of any contract whose first byte is the <code>SET_INDESTRUCTIBLE</code> opcode is no longer banned. However, calls to anything but the <code>target</code> or a precompile that change the <code>callee</code> (i.e., calls other than <code>CALLCODE</code> and <code>DELEGATECALL</code>) are still not permitted.</p> <p>If the <a rel="external" href="http://github.com/ethereum/EIPs/pull/2975">IS_STATIC EIP</a> is added, the list of allowed prefixes can be extended to allow a prefix that enables incoming static calls but not state-changing calls.</p> <p>The list of allowed prefixes can also be extended to enable other benign use cases (eg. logging incoming payments).</p> <p>External calls <em>into</em> AA accounts can be allowed as follows. We can add an opcode <code>RESERVE_GAS</code>, which takes as argument a value <code>N</code> and has simple behavior: immediately burn <code>N</code> gas and add <code>N</code> gas to the refund. We then add an allowed <code>AA_PREFIX</code> that reserves <code>&gt;= AA_BASE_GAS_COST * 2</code> gas. This ensures that at least <code>AA_BASE_GAS_COST</code> gas must be spent (as refunds can refund max 50% of total consumption) in order to call into an account and invalidate transactions targeting that account in the mempool, preserving that invariant.</p> <p>Note that accounts may also opt to set a higher <code>RESERVE_GAS</code> value in order to safely have a higher <code>VERIFICATION_GAS_CAP</code>; the goal would be to preserve a <code>VERIFICATION_GAS_MULTIPLIER</code>-to-1 ratio between the minimum gas cost to edit an account (ie. half its <code>RESERVE_GAS</code>) and the <code>VERIFICATION_GAS_CAP</code> that is permitted that account. This would also preserve invariants around maximum reverification gas consumption that are implied by the previous section.</p> <h3 id="multi-tenant-beyond">Multi-Tenant &amp; Beyond</h3> <p>In a later stage, we can add support for multiple pending transactions per account in the mempool. The main challenge here is that a single transaction can potentially cause state changes that invalidate all other transactions to that same account. Additionally, if we naively prioritize transactions by gasprice, there is an attack vector where the user willing to pay the highest gasprice publishes many (mutually exclusive) versions of their transaction with small alterations, thereby pushing everyone else's transactions out of the mempool.</p> <p>Here is a sketch of a strategy for mitigating this problem. We would require incoming transactions to contain an <a rel="external" href="https://github.com/ethereum/EIPs/blob/master/EIPS/./02930.md">EIP-2930</a>-style access list detailing the storage slots that the transaction reads or modifies, and make it binding; that is, accesses outside the access list would be invalid. A transaction would only be included in the mempool if its access list is disjoint from the access lists of other transactions in the mempool (or if its gasprice is higher). An alternative way to think about this is to have per-storage-slot mempools instead of just per-account mempools, except a transaction could be part of multiple per-storage-slot mempools (if desired it could be capped to eg. 5 storage slots).</p> <p>Note also that multi-tenant AA will almost certainly require allowing miners to edit the nonces of incoming transactions to put them into sequence, with the result that the final hash of a transaction is unpredictable at publication time. Clients will need to explicitly work around this.</p> <p>More research is required to refine these ideas, and this is left for later work.</p> <h2 id="rationale">Rationale</h2> <p>The core problem in an account abstraction setup is always that miners and network nodes need to be able to verify that a transaction that they attempt to include, or rebroadcast, will actually pay a fee. Currently, this is fairly simple, because a transaction is guaranteed to be includable and pay a fee as long as the signature and nonce are valid and the balance and gasprice are sufficient. These checks can be done quickly.</p> <p>In an account abstraction setup, the goal is to allow accounts to specify EVM code that can establish more flexible conditions for a transaction's validity, but with the requirement that this EVM code can be quickly verified, with the same safety properties as the existing setup.</p> <p>In a normal transaction, the top-level call goes from the <code>tx.sender</code> to <code>tx.to</code> and carries with it <code>tx.value</code>. In an AA transaction, the top-level call goes from the <em>entry point address</em> (<code>0xFFFF...FF</code>) to the <code>tx.target</code>.</p> <p>The top-level code execution is expected to be split into two phases: the shorter <strong>verification phase</strong> (before <code>PAYGAS</code>) and the longer <strong>execution phase</strong> (after <code>PAYGAS</code>). If execution throws an exception during the verification phase, the transaction is invalid, much like a transaction with an invalid signature in the current system. If execution throws an exception after the verification phase, the transaction pays fees, and so the miner can still include it.</p> <p>The transition between different stages of AA is entirely done through changes in miner strategy. The first stage supports <strong>single-tenant AA</strong>, where the only use cases that can be easily implemented are where the <code>tx.target</code> is a contract representing a user account (that is, a smart contract wallet, eg. multisig). Later stages improve support for eg. logs and libraries, and also move toward supporting <strong>multi-tenant AA</strong>, where the goal is to try to support cases where the <code>tx.target</code> represents an <em>application</em> that processes incoming activity from multiple users.</p> <h3 id="nonces-still-enshrined-in-single-tenant-aa">Nonces still enshrined in single-tenant AA</h3> <p>Nonces are still enforced in single-tenant AA to ensure that single-target AA does not break the invariant that each transaction (and hence each transaction hash) can only be included in the chain once. While there is some limited value in allowing arbitrary-order transaction inclusion in single-tenant AA, there is not enough value to justify breaking that invariant.</p> <p>Note that nonces in AA accounts do end up having a dual-purpose: they are both there for replay protection and for contract address generation when using the <code>CREATE</code> opcode. This does mean that a single transaction could increment the nonce by more than 1. This is deemed acceptable, as the other mechanics introduced by AA already break the ability to easily verify that a chain longer than one transaction can be processed. However, we strongly recommend that AA contracts use <code>CREATE2</code> instead of <code>CREATE</code>.</p> <p>In multi-tenant AA, as mentioned above, nonces are expected to become malleable and applications that use multi-tenant AA systems would need to manage this.</p> <h3 id="nonces-are-exposed-to-the-evm">Nonces are exposed to the EVM</h3> <p>This is done to allow signature checking done in validation code to validate the nonce.</p> <h3 id="replay-protection-1">Replay Protection</h3> <p>One of the above two approaches (requiring <code>SET_INDESTRUCTIBLE</code> or modifying <code>SELFDESTRUCT</code> behavior) must be implemented so that nonces cannot be reused. It must be a consensus change, and not simply part of <code>AA_PREFIX</code>, so that transaction hash uniqueness is maintained.</p> <h3 id="miners-refuse-transactions-that-access-external-data-or-the-target-s-own-balance-before-paygas">Miners refuse transactions that access external data or the target's own balance, before PAYGAS</h3> <p>An important property of traditional transactions is that activity happening as part of transactions that originate outside of some given account X cannot make transactions whose sender is X invalid. The only state change that an outside transaction can impose on X is increasing its balance, which cannot invalidate a transaction.</p> <p>Allowing AA contracts to access external data (both other accounts and environment variables such as GASPRICE, DIFFICULTY, etc.) before they call <code>PAYGAS</code> (ie. during the verification phase) breaks this invariant. For example, imagine someone sends many thousands of AA transactions that perform an external call <code>if FOO.get_number() != 5: throw()</code>. <code>FOO.number</code> might be set to <code>5</code> when those transactions are all sent, but a single transaction to <code>FOO</code> could set the <code>number</code> to something else, invalidating <em>all of the thousands of AA transactions</em> that depend on it. This would be a serious DoS vector.</p> <p>The one allowed exception is contracts that are indestructible (that is, whose first byte is the <code>SET_INDESTRUCTIBLE</code> opcode defined in <a rel="external" href="https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/SyNT3Cdmw">this EIP</a>). This is a safe exception, because the data that is being read cannot be changed.</p> <p>Disallowing reading <code>BALANCE</code> blocks a milder attack vector: an attacker could force a transaction to be reprocessed at a mere cost of 6700 gas (not 15000 or 21000), in the worst case more than doubling the number of transactions that would need to be reprocessed.</p> <p>In the long term, AA could be expanded to allow reading external data, though protections such as mandatory access lists would be required.</p> <h3 id="aa-transactions-must-call-contracts-with-prefix">AA transactions must call contracts with prefix</h3> <p>The prelude is used to ensure that <em>only</em> AA transactions can call the contract. This is another measure taken to ensure the invariant described above. If this check did not occur, it would be possible for a transaction originating outside some AA account X to call into X and make a storage change, forcing transactions targeting that account to be reprocessed at the cost of a mere 5000 gas.</p> <h3 id="multi-tenant-aa">Multi-tenant AA</h3> <p>Multi-tenant AA extends single-tenant AA by <strong>better handling cases where distinct and uncoordinated users attempt to send transactions for/to the same account and those transactions may interfere with each other</strong>.</p> <p>We can understand the value of multi-tenant AA by examining two example use cases: (i) <a rel="external" href="http://tornado.cash">tornado.cash</a> and (ii) <a rel="external" href="http://uniswap.exchange">Uniswap</a>. In both of these cases, there is a single central contract that represents the application, and not any specific user. Nevertheless, there is important value in using abstraction to do application-specific validation of transactions.</p> <h4 id="tornado-cash">Tornado Cash</h4> <p>The tornado.cash workflow is as follows:</p> <ol> <li>A user sends a transaction to the TC contract, depositing some standard quantity of coins (eg. 1 ETH). A record of their deposit, containing the hash of a secret known by the user, is added to a Merkle tree whose root is stored in the TC contract.</li> <li>When that user later wants to withdraw, they generate and send a ZK-SNARK proving that they know a secret whose hash is in a leaf somewhere in the deposit tree (without revealing where). The TC contract verifies the ZK-SNARK, and also verifies that a nullifier value (also derivable from the secret) has not yet been spent. The contract sends 1 ETH to the user's desired address, and saves a record that the user's nullifier has been spent.</li> </ol> <p>The privacy provided by TC arises because when a user makes a withdrawal, they can prove that it came from <em>some</em> unique deposit, but no one other than the user knows which deposit it came from. However, implementing TC naively has a fatal flaw: the user usually does not yet have ETH in their withdrawal address, and if the user uses their deposit address to pay for gas, that creates an on-chain link between their deposit address and their withdrawal address.</p> <p>Currently, this is solved via relayers; a third-party relayer verifies the ZK-SNARK and unspent status of the nullifier, publishes the transaction using their own ETH to pay for gas, and collects the fee back from the user from the TC contract.</p> <p>AA allows this without relayers: the user could simply send an AA transaction targeting the TC contract, the ZK-SNARK verification and the nullifier checking can be done in the verification step, and PAYGAS can be called directly after that. This allows the withdrawer to pay for gas directly out of the coins going to their withdrawal address, avoiding the need for relayers or for an on-chain link to their deposit address.</p> <p>Note that fully implementing this functionality requires AA to be structured in a way that supports multiple users sending withdrawals at the same time (requiring nonces would make this difficult), and that allows a single account to support both AA transactions (the withdrawals) and externally-initiated calls (the deposits).</p> <h4 id="uniswap">Uniswap</h4> <p>A new version of Uniswap could be built that allows transactions to be sent that directly target the Uniswap contract. Users could deposit tokens into Uniswap ahead of time, and Uniswap would store their balances as well as a public key that transactions spending those balances could be verified against. An AA-initiated Uniswap trade would only be able to spend these internal balances.</p> <p>This would be useless for normal traders, as normal traders have their coins outside the Uniswap contract, but it would be a powerful boon to arbitrageurs. Arbitrageurs would deposit their coins into Uniswap, and they would be able to send transactions that perform arbitrage every time external market conditions change, and logic such as price limits could be enforced during the verification step. Hence, transactions that do not get in (eg. because some other arbitrageur made the trade first) would not be included on-chain, allowing arbitrageurs to not pay gas, and reducing the number of "junk" transactions that get included on-chain. This could significantly increase both de-facto blockchain scalability as well as market efficiency, as arbitrageurs would be able to much more finely correct for cross-exchange discrepancies between prices.</p> <p>Note that here also, Uniswap would need to support both AA transactions and externally-initiated calls.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This AA implementation preserves the existing transaction type. The use of <code>assert origin == caller</code> to verify that an account is an EOA remains sound, but is not extensible to AA accounts; AA transactions will always have <code>origin == AA_ENTRY_POINT</code>.</p> <p>Badly-designed single-tenant AA contracts will break the transaction non-malleability invariant. That is, it is possible to take an AA transaction in-flight, modify it, and have the modified version still be valid; AA account contracts can be designed in such a way as to make that not possible, but it is their responsibility. Multi-tenant AA will break the transaction non-malleability invariant much more thoroughly, making the transaction hash unpredictable even for legitimate applications that use the multi-tenant AA features (though the invariant will not further break for applications that existed before then).</p> <p>AA contracts may not have replay protection unless they build it in explicitly; this can be done with the <code>CHAINID (0x46)</code> opcode introduced in <a href="https://wg-eips.ritovision.com/1344/">EIP 1344</a>.</p> <h2 id="test-cases">Test Cases</h2> <p>See: <a rel="external" href="https://github.com/quilt/tests/tree/account-abstraction">https://github.com/quilt/tests/tree/account-abstraction</a></p> <h2 id="implementation">Implementation</h2> <p>See: <a rel="external" href="https://github.com/quilt/go-ethereum/tree/account-abstraction">https://github.com/quilt/go-ethereum/tree/account-abstraction</a></p> <h2 id="security-considerations">Security Considerations</h2> <p>See <a rel="external" href="https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937">https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937</a> for an analysis of DoS issues.</p> <h3 id="re-validation">Re-validation</h3> <p>When a transaction enters the mempool, the client is able to quickly ascertain whether the transaction is valid. Once it determines this, it can be confident that the transaction will continue to be valid unless a transaction from the same account invalidates it.</p> <p>There are, however, cases where an attacker can publish a transaction that invalidates existing transactions and requires the network to perform more recomputation than the computation in the transaction itself. The EIP maintains the invariant that recomputation is bounded to a theoretical maximum of six times the block gas limit in a single block; this is somewhat more expensive than before, but not that much more expensive.</p> <h4 id="peer-denial-of-service">Peer denial-of-service</h4> <p>Denial-of-Service attacks are difficult to defend against, due to the difficulty in identifying sybils within a peer list. At any moment, one may decide (or be bribed) to initiate an attack. This is not a problem that Account Abstraction introduces. It can be accomplished against existing clients today by inundating a target with transactions whose signatures are invalid. However, due to the increased allotment of validation work allowed by AA, it's important to bound the amount of computation an adversary can force a client to expend with invalid transactions. For this reason, it's best for the miner to follow the recommended mining strategies.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Tomasz Stanczakhttps://github.com/tkstanczak Guillaume Ballethttps://github.com/gballet Gajinder Singhhttps://github.com/g11tech Tanishq Jasoriahttps://github.com/tanishqjasoria Ignacio Hagopianhttps://github.com/jsign Jochem Brouwerhttps://github.com/jochem-brouwer Sina Mahmoodihttps://github.com/s1na https://wg-eips.ritovision.com/2935/

Store and serve last 8191 block hashes as storage slots of a system contract to allow for stateless execution

<h2 id="abstract">Abstract</h2> <p>Store last <code>HISTORY_SERVE_WINDOW</code> historical block hashes in the storage of a system contract as part of the block processing logic. Furthermore this EIP has no impact on <code>BLOCKHASH</code> resolution mechanism (and hence its range/costs etc).</p> <h2 id="motivation">Motivation</h2> <p>EVM implicitly assumes the client has the recent block (hashes) at hand. This assumption is not future-proof given the prospect of stateless clients. Including the block hashes in the state will allow bundling these hashes in the witness provided to a stateless client. This is already possible in the MPT and will become more efficient post-Verkle.</p> <p>Extending the range of blocks which <code>BLOCKHASH</code> can serve (<code>BLOCKHASH_SERVE_WINDOW</code>) would have been a semantics change. Using extending that via this contract storage would allow a soft-transition. Rollups can benefit from the longer history window through directly querying this contract.</p> <p>A side benefit of this approach could be that it allows building/validating proofs related to last <code>HISTORY_SERVE_WINDOW</code> ancestors directly against the current state.</p> <h2 id="specification">Specification</h2> <table><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody> <tr><td><code>BLOCKHASH_SERVE_WINDOW</code></td><td><code>256</code></td></tr> <tr><td><code>HISTORY_SERVE_WINDOW</code></td><td><code>8191</code></td></tr> <tr><td><code>SYSTEM_ADDRESS</code></td><td><code>0xfffffffffffffffffffffffffffffffffffffffe</code></td></tr> <tr><td><code>HISTORY_STORAGE_ADDRESS</code></td><td><code>0x0000F90827F1C53a10cb7A02335B175320002935</code></td></tr> </tbody></table> <p>This EIP specifies for storing last <code>HISTORY_SERVE_WINDOW</code> block hashes in a ring buffer storage of <code>HISTORY_SERVE_WINDOW</code> length. Note that <code>HISTORY_SERVE_WINDOW</code> &gt; <code>BLOCKHASH_SERVE_WINDOW</code> (which remains unchanged).</p> <h3 id="block-processing">Block processing</h3> <p>At the start of processing any block where this EIP is active (ie. before processing any transactions), call to <code>HISTORY_STORAGE_ADDRESS</code> as <code>SYSTEM_ADDRESS</code> with the 32-byte input of <code>block.parent.hash</code>, a gas limit of <code>30_000_000</code>, and <code>0</code> value. This will trigger the <code>set()</code> routine of the history contract. This is a system operation following the same convention as <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> and therefore:</p> <ul> <li>the call must execute to completion</li> <li>the call does not count against the block's gas limit</li> <li>the call does not follow the <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> burn semantics - no value should be transferred as part of the call</li> <li>if no code exists at <code>HISTORY_STORAGE_ADDRESS</code>, the call must fail silently</li> </ul> <p>Note: Alternatively clients can choose to directly write to the storage of the contract but EVM calling the contract remains preferred. Refer to the rationale for more info.</p> <p>Note that, it will take <code>HISTORY_SERVE_WINDOW</code> blocks after the EIP's activation to completely fill up the ring buffer. The contract will only contain the parent hash of the fork block and no hashes prior to that.</p> <h3 id="evm-changes">EVM Changes</h3> <p>The <code>BLOCKHASH</code> opcode semantics remains the same as before.</p> <h3 id="block-hash-history-contract">Block hash history contract</h3> <p>The history contract has two operations: <code>get</code> and <code>set</code>. The <code>set</code> operation is invoked only when the <code>caller</code> is equal to the <code>SYSTEM_ADDRESS</code> as per <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a>. Otherwise the <code>get</code> operation is performed.</p> <h4 id="get"><code>get</code></h4> <p>It is used from the EVM for looking up block hashes.</p> <ul> <li>Callers provide the block number they are querying in a big-endian encoding.</li> <li>If calldata is not 32 bytes, revert.</li> <li>For any request outside the range of [block.number-<code>HISTORY_SERVE_WINDOW</code>, block.number-1], revert.</li> </ul> <h4 id="set"><code>set</code></h4> <ul> <li>Caller provides <code>block.parent.hash</code> as calldata to the contract.</li> <li>Set the storage value at <code>block.number-1 % HISTORY_SERVE_WINDOW</code> to be <code>calldata[0:32]</code>.</li> </ul> <h4 id="bytecode">Bytecode</h4> <p>Exact evm assembly that can be used for the history contract:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>// https://github.com/lightclient/sys-asm/blob/f1c13e285b6aeef2b19793995e00861bf0f32c9a/src/execution_hash/main.eas</span></span> <span class="giallo-l"><span>caller</span></span> <span class="giallo-l"><span>push20 0xfffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>eq</span></span> <span class="giallo-l"><span>push1 0x46</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"><span>push1 0x20</span></span> <span class="giallo-l"><span>calldatasize</span></span> <span class="giallo-l"><span>sub</span></span> <span class="giallo-l"><span>push1 0x42</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>push1 0x01</span></span> <span class="giallo-l"><span>number</span></span> <span class="giallo-l"><span>sub</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>push1 0x42</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"><span>push2 0x1fff</span></span> <span class="giallo-l"><span>dup2</span></span> <span class="giallo-l"><span>number</span></span> <span class="giallo-l"><span>sub</span></span> <span class="giallo-l"><span>gt</span></span> <span class="giallo-l"><span>push1 0x42</span></span> <span class="giallo-l"><span>jumpi</span></span> <span class="giallo-l"><span>push2 0x1fff</span></span> <span class="giallo-l"><span>swap1</span></span> <span class="giallo-l"><span>mod</span></span> <span class="giallo-l"><span>sload</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>mstore</span></span> <span class="giallo-l"><span>push1 0x20</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>return</span></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>revert</span></span> <span class="giallo-l"><span>jumpdest</span></span> <span class="giallo-l"><span>push0</span></span> <span class="giallo-l"><span>calldataload</span></span> <span class="giallo-l"><span>push2 0x1fff</span></span> <span class="giallo-l"><span>push1 0x01</span></span> <span class="giallo-l"><span>number</span></span> <span class="giallo-l"><span>sub</span></span> <span class="giallo-l"><span>mod</span></span> <span class="giallo-l"><span>sstore</span></span> <span class="giallo-l"><span>stop</span></span></code></pre><h4 id="deployment">Deployment</h4> <p>A special synthetic address is generated by working backwards from the desired deployment transaction:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">nonce</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">to</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gas</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x3d090</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">gasPrice</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xe8d4a51000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxPriorityFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">maxFeePerGas</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> null</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">value</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">input</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x60538060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">v</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x1b</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">r</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x539</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">s</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0xaa12693182426612186309f02cfe8a80a0000</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">hash</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">0x67139a552b0d3fffc30c0fa7d0c20d42144138c8fe07fc5691f09c1cce632e15</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Note, the input in the transaction has a simple constructor prefixing the desired runtime code.</p> <p>The sender of the transaction can be calculated as <code>0x3462413Af4609098e1E27A490f554f260213D685</code>. The address of the first contract deployed from the account is <code>rlp([sender, 0])</code> which equals <code>0x0000F90827F1C53a10cb7A02335B175320002935</code>. This is how <code>HISTORY_STORAGE_ADDRESS</code> is determined. Although this style of contract creation is not tied to any specific initcode like create2 is, the synthetic address is cryptographically bound to the input data of the transaction (e.g. the initcode).</p> <p>Some activation scenarios:</p> <ul> <li>For the fork to be activated at genesis, no history is written to the genesis state, and at the start of block <code>1</code>, genesis hash will be written as a normal operation to slot <code>0</code>.</li> <li>for activation at block <code>1</code>, only genesis hash will be written at slot <code>0</code>.</li> <li>for activation at block <code>32</code>, block <code>31</code>'s hash will be written to slot <code>31</code>. Every other slot will be <code>0</code>.</li> </ul> <h3 id="eip-161-handling"><a href="https://wg-eips.ritovision.com/161/">EIP-161</a> handling</h3> <p>The bytecode above will be deployed à la <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a>. As such the account at <code>HISTORY_STORAGE_ADDRESS</code> will have code and a nonce of 1, and will be exempt from EIP-161 cleanup.</p> <h3 id="gas-costs">Gas costs</h3> <p>The system update at the beginning of the block, i.e. <code>process_block_hash_history</code> (or via system call to the contract with <code>SYSTEM_ADDRESS</code> caller), will not warm the <code>HISTORY_STORAGE_ADDRESS</code> account or its storage slots as per <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> rules. As such the first call to the contract will pay for warming up the account and storage slots it accesses.To clarify further any contract call to the <code>HISTORY_STORAGE_ADDRESS</code> will follow normal EVM execution semantics.</p> <p>Since <code>BLOCKHASH</code> semantics doesn't change, this EIP has no impact on <code>BLOCKHASH</code> mechanism and costs.</p> <h2 id="rationale">Rationale</h2> <p>Very similar ideas were proposed before. This EIP is a simplification, removing two sources of needless complexity:</p> <ol> <li>Having a tree-like structure with multiple layers as opposed to a single list</li> <li>Writing the EIP in EVM code</li> <li>Serial unbounded storage of hashes for a deep access to the history</li> </ol> <p>However after weighing pros and cons, we decided to go with just a limited ring buffer to only serve the requisite <code>HISTORY_SERVE_WINDOW</code> as <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> and beacon state accumulators allow (albeit a bit more complex) proof against any ancestor since merge.</p> <p>Second concern was how to best transition the BLOCKHASH resolution logic post fork by:</p> <ol> <li>Either waiting for <code>HISTORY_SERVE_WINDOW</code> blocks for the entire relevant history to persist</li> <li>Storing of all last <code>HISTORY_SERVE_WINDOW</code> block hashes on the fork block.</li> </ol> <p>We choose to go with the former. It simplifies the logic greatly. It will take roughly a day to bootstrap the contract. Given that this is a new way of accessing history and no contract depends on it, it is deemed a favorable tradeoff.</p> <h3 id="inserting-the-parent-block-hash">Inserting the parent block hash</h3> <p>Clients have generally two options for inserting the parent block hash into state:</p> <ol> <li>Performing a system call to <code>HISTORY_STORAGE_ADDRESS</code> and letting that handle the storing in state.</li> <li>Avoid EVM processing and directly write to the state trie.</li> </ol> <p>The latter option is as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_block_hash_history</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>:</span><span> Block</span><span>,</span><span class="z-variable z-parameter z-function"> state</span><span>:</span><span> State</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> block</span><span>.</span><span>timestamp</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> FORK_TIMESTAMP</span><span>:</span><span class="z-keyword"> //</span><span class="z-constant"> FORK_TIMESTAMP</span><span> should</span><span> be</span><span> defined</span><span> outside</span><span> of</span><span> the</span><span class="z-constant"> EIP</span></span> <span class="giallo-l"><span> state</span><span>.</span><span>insert_slot</span><span>(</span><span class="z-constant">HISTORY_STORAGE_ADDRESS</span><span>,</span><span> (</span><span>block</span><span>.</span><span>number</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> HISTORY_SERVE_WINDOW</span><span> ,</span><span> block</span><span>.</span><span>parent</span><span>.</span><span>hash</span><span>)</span></span></code></pre> <p>The first option is recommended until the Verkle fork, to stay consistent with <a href="https://wg-eips.ritovision.com/4788/">EIP-4788</a> and to issues for misconfigured networks where this EIP is activated but history contract hasn't been deployed. The recommendation may be reconsidered at the Verkle fork if filtering the system contract code chunks is deemed too complex.</p> <h3 id="size-of-ring-buffers">Size of ring buffers</h3> <p>The ring buffer data structure is sized to hold 8191 hashes. In other system contracts a prime ring buffer size is chosen in because using a prime as the modulus ensures that no value is overwritten until the entire ring buffer has been saturated and thereafter, each value will be updated once per iteration, regardless of if some slot are missing or the slot time changes. However, in this EIP the block number is the value in the modulo operation and it only ever increases by 1 each iteration. Which means we can be confident that the ring buffer will always remain saturated.</p> <p>For consistency with other system contracts, we have decided to retain the buffer size of 8191. Given the current mainnet values, 8191 roots provides about a day of coverage. This also gives users plenty of time to make a transaction with a verification against a specific hash and get the transaction included on-chain.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces backwards incompatible changes to the block validation rule set. But neither of these changes break anything related to current user activity and experience.</p> <h2 id="test-cases">Test Cases</h2> <p><a rel="external" href="https://github.com/ethereum/execution-spec-tests/tree/3810d22f84f206866f66f4f6bf856187c2893ab1/tests/prague/eip2935_historical_block_hashes_from_state">EIP-2935 Execution Spec Tests</a></p> <h2 id="security-considerations">Security Considerations</h2> <p>Having contracts (system or otherwise) with hot update paths (branches) poses a risk of "branch" poisoning attacks where attacker could sprinkle trivial amounts of eth around these hot paths (branches). But it has been deemed that cost of attack would escalate significantly to cause any meaningful slow down of state root updates.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/2936/ <h2 id="simple-summary">Simple Summary</h2> <p>Enable new opcode to clear storage for <code>SELFDESTRUCTED</code>ed contracts.</p> <h2 id="abstract">Abstract</h2> <p>Changes <code>SELFDESTRUCT</code> (<code>0xff</code>) to not clear any storage and adds a new <code>EXTCLEAR</code> (<code>0x5c</code>) opcode that will clear a specific storage slot for a contract that has previously been self destructed.</p> <h2 id="motivation">Motivation</h2> <p><code>SELFDESTRUCT</code> (<code>0xFF</code>) is unnecessarily complex because it clears an unbounded amount of contract storage. It is computationally expensive for nodes to track all of the storage used in every contract in case the contract <code>SELFDESTRUCT</code>s. Further, contracts can be re-initialized using <code>CREATE2</code> (<code>0xF5</code>), and then <code>SLOAD</code> (<code>0x54</code>) prior storage. Therefore, several ethereum clients do not clear storage at all, and just check if the contract was initiated since <code>SSTORE</code> (<code>0x55</code>) during <code>SLOAD</code>. <code>CREATE2</code> was not intended to complicate <code>SLOAD</code>, and this change reverts that complexity. Also, bugs in this implementation could split the network.</p> <p>Instead this defers the time of storage cleanup, and leaves the storage in-place, which reduces the complexity of <code>SLOAD</code> and <code>SELFDESTRUCT</code>.</p> <p>This empowers the <code>CREATE2</code> reincarnation proxy pattern by retaining storage during upgrade, which would otherwise have to be reset again. An atomic reincarnation upgrade could clear a subset of storage during the upgrade, while the contract is destroyed, before reinstating it.</p> <h2 id="specification">Specification</h2> <p>After <code>FORK_BLOCK_NUM</code>, a new opcode, <code>EXTCLEAR</code>, is enabled at <code>0x5C</code> to clear storage for <code>SELFDESTRUCT</code>ed contracts. <code>EXTCLEAR</code>:</p> <ul> <li>does not push any words onto the stack</li> <li>pops two words off the stack: the destroyed contract address and a storage address</li> <li>if the contract exists, charge the same gas cost as <code>EXTCODEHASH</code> (<code>0x3F</code>)</li> <li>otherwise, if the storage is zero, charge the same gas as <code>EXTCODEHASH</code> plus <code>SLOAD</code></li> <li>otherwise, the destroyed contract's slot is reset to 0, charging the same gas as <code>EXTCODEHASH</code> and <code>SSTORE</code> when resetting storage, while also refunding the amount specified in <code>SSTORE</code>.</li> </ul> <p><code>SELFDESTRUCT</code> is modified to not clear contract storage. This change also works retroactively: all prior destroyed contracts can be cleaned up.</p> <h2 id="rationale">Rationale</h2> <p><code>0x5C</code> is available in the same range as <code>SSTORE</code> and <code>SLOAD</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>A reincarnation upgrade mechanism that expects all internal storage to be cleared might break, but such an upgrade mechanism would allow adaptation to this new behavior.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="implementation">Implementation</h2> <p>Implementation is required on all major clients to add the opcode.</p> <h2 id="security-considerations">Security Considerations</h2> <p>A reincarnated contract that does not expect its state to be cleared by malicious actors SHOULD reinitialize itself to avoid antagonistic <code>EXTCLEAR</code>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/2929/ <h2 id="simple-summary">Simple Summary</h2> <p>Increases gas cost for <code>SLOAD</code>, <code>*CALL</code>, <code>BALANCE</code>, <code>EXT*</code> and <code>SELFDESTRUCT</code> when used for the first time in a transaction.</p> <h2 id="abstract">Abstract</h2> <p>Increase the gas cost of <code>SLOAD</code> (<code>0x54</code>) to 2100, and the <code>*CALL</code> opcode family (<code>0xf1</code>, <code>f2</code>, <code>f4</code>, <code>fA</code>), <code>BALANCE</code> <code>0x31</code> and the <code>EXT*</code> opcode family (<code>0x3b</code>, <code>0x3c</code>, <code>0x3f</code>) to 2600. Exempts (i) precompiles, and (ii) addresses and storage slots that have already been accessed in the same transaction, which get a decreased gas cost. Additionally reforms <code>SSTORE</code> metering and <code>SELFDESTRUCT</code> to ensure "de-facto storage loads" inherent in those opcodes are priced correctly.</p> <h2 id="motivation">Motivation</h2> <p>Generally, the main function of gas costs of opcodes is to be an estimate of the time needed to process that opcode, the goal being for the gas limit to correspond to a limit on the time needed to process a block. However, storage-accessing opcodes (<code>SLOAD</code>, as well as the <code>*CALL</code>, <code>BALANCE</code> and <code>EXT*</code> opcodes) have historically been underpriced. In the 2016 Shanghai DoS attacks, once the most serious client bugs were fixed, one of the more durably successful strategies used by the attacker was to simply send transactions that access or call a large number of accounts.</p> <p>Gas costs were increased to mitigate this, but recent numbers suggest they were not increased enough. Quoting <a rel="external" href="https://arxiv.org/pdf/1909.07220.pdf">https://arxiv.org/pdf/1909.07220.pdf</a>:</p> <blockquote> <p>Although by itself, this issue might seem benign, <code>EXTCODESIZE</code> forces the client to search the contract ondisk, resulting in IO heavy transactions. While replaying the Ethereum history on our hardware, the malicious transactions took around 20 to 80 seconds to execute, compared to a few milliseconds for the average transactions</p> </blockquote> <p>This proposed EIP increases the costs of these opcodes by a factor of ~3, reducing the worst-case processing time to ~7-27 seconds. Improvements in database layout that involve redesigning the client to read storage directly instead of hopping through the Merkle tree would decrease this further, though these technologies may take a long time to fully roll out, and even with such technologies the IO overhead of accessing storage would remain substantial.</p> <p>A secondary benefit of this EIP is that it also performs most of the work needed to make <a rel="external" href="https://ethereum-magicians.org/t/protocol-changes-to-bound-witness-size/3885">stateless witness sizes</a> in Ethereum acceptable. Assuming <a rel="external" href="https://ethresear.ch/t/binary-trie-format/7621">a switch to binary tries</a>, the theoretical maximum witness size not including code size (hence "most of the work" and not "all") would decrease from <code>(12500000 gas limit) / (700 gas per BALANCE) * (800 witness bytes per BALANCE) ~= 14.3M bytes</code> to <code>12500000 / 2600 * 800 ~= 3.85M bytes</code>. Pricing for code access could be changed when code merklization is implemented.</p> <p>In the further future, there are similar benefits in the case of SNARK/STARK witnesses. Recent numbers from Starkware suggest that they are able to prove 10000 Rescue hashes per second on a consumer desktop; assuming 25 hashes per Merkle branch, and a block full of state accesses, at present this would imply a witness would take <code>12500000 / 700 * 25 / 10000 ~= 44.64</code> seconds to generate, but after this EIP that would reduce to <code>12500000 / 2500 * 25 / 10000 ~= 12.5</code> seconds, meaning that a single desktop computer would be able to generate witnesses on time under any conditions. Future gains in STARK proving could be spent on either (i) using a more expensive but robust hash function or (ii) reducing proving times further, reducing the delay and hence improving user experience of stateless clients that rely on such witnesses.</p> <h2 id="specification">Specification</h2> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>12244000</td></tr> <tr><td><code>COLD_SLOAD_COST</code></td><td>2100</td></tr> <tr><td><code>COLD_ACCOUNT_ACCESS_COST</code></td><td>2600</td></tr> <tr><td><code>WARM_STORAGE_READ_COST</code></td><td>100</td></tr> </tbody></table> <p>For blocks where <code>block.number &gt;= FORK_BLOCK</code>, the following changes apply.</p> <p>When executing a transaction, maintain a set <code>accessed_addresses: Set[Address]</code> and <code>accessed_storage_keys: Set[Tuple[Address, Bytes32]]</code> .</p> <p>The sets are transaction-context-wide, implemented identically to other transaction-scoped constructs such as the self-destruct-list and global <code>refund</code> counter. In particular, if a scope reverts, the access lists should be in the state they were in before that scope was entered.</p> <p>When a transaction execution begins,</p> <ul> <li><code>accessed_storage_keys</code> is initialized to empty, and</li> <li><code>accessed_addresses</code> is initialized to include <ul> <li>the <code>tx.sender</code>, <code>tx.to</code> (or the address being created if it is a contract creation transaction)</li> <li>and the set of all precompiles.</li> </ul> </li> </ul> <h3 id="storage-read-changes">Storage read changes</h3> <p>When an address is either the target of a (<code>EXTCODESIZE</code> (<code>0x3B</code>), <code>EXTCODECOPY</code> (<code>0x3C</code>), <code>EXTCODEHASH</code> (<code>0x3F</code>) or <code>BALANCE</code> (<code>0x31</code>)) opcode or the target of a (<code>CALL</code> (<code>0xF1</code>), <code>CALLCODE</code> (<code>0xF2</code>), <code>DELEGATECALL</code> (<code>0xF4</code>), <code>STATICCALL</code> (<code>0xFA</code>)) opcode, the gas costs are computed as follows:</p> <ul> <li>If the target is not in <code>accessed_addresses</code>, charge <code>COLD_ACCOUNT_ACCESS_COST</code> gas, and add the address to <code>accessed_addresses</code>.</li> <li>Otherwise, charge <code>WARM_STORAGE_READ_COST</code> gas.</li> </ul> <p>In all cases, the gas cost is charged and the map is updated at the time that the opcode is being called. When a <code>CREATE</code> or <code>CREATE2</code> opcode is called, immediately (ie. before checks are done to determine whether or not the address is unclaimed) add the address being created to <code>accessed_addresses</code>, but gas costs of <code>CREATE</code> and <code>CREATE2</code> are unchanged. Clarification: If a <code>CREATE</code>/<code>CREATE2</code> operation fails later on, e.g during the execution of <code>initcode</code> or has insufficient gas to store the code in the state, the <code>address</code> of the contract itself remains in <code>access_addresses</code> (but any additions made within the inner scope are reverted).</p> <p>For <code>SLOAD</code>, if the <code>(address, storage_key)</code> pair (where <code>address</code> is the address of the contract whose storage is being read) is not yet in <code>accessed_storage_keys</code>, charge <code>COLD_SLOAD_COST</code> gas and add the pair to <code>accessed_storage_keys</code>. If the pair is already in <code>accessed_storage_keys</code>, charge <code>WARM_STORAGE_READ_COST</code> gas.</p> <p>Note: For call-variants, the <code>100</code>/<code>2600</code> cost is applied immediately (exactly like how <code>700</code> was charged before this EIP), i.e: before calculating the <code>63/64ths</code> available for entering the call.</p> <p>Note 2: There is currently no way to perform a 'cold sload read/write' on a 'cold account', simply because in order to read/write a <code>slot</code>, the execution must already be inside the <code>account</code>. Therefore, the behaviour of cold storage reads/writes on cold accounts is undefined as of this EIP. Any future EIP which proposes to add 'remote read/write' would need to define the pricing behaviour of that change.</p> <h3 id="sstore-changes">SSTORE changes</h3> <p>When calling <code>SSTORE</code>, check if the <code>(address, storage_key)</code> pair is in <code>accessed_storage_keys</code>. If it is not, charge an additional <code>COLD_SLOAD_COST</code> gas, and add the pair to <code>accessed_storage_keys</code>. Additionally, modify the parameters defined in <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a> as follows:</p> <table><thead><tr><th>Parameter</th><th>Old value</th><th>New value</th></tr></thead><tbody> <tr><td><code>SLOAD_GAS</code></td><td>800</td><td><code>= WARM_STORAGE_READ_COST</code></td></tr> <tr><td><code>SSTORE_RESET_GAS</code></td><td>5000</td><td><code>5000 - COLD_SLOAD_COST</code></td></tr> </tbody></table> <p>The other parameters defined in EIP 2200 are unchanged. Note: The constant <code>SLOAD_GAS</code> is used in several places in EIP 2200, e.g <code>SSTORE_SET_GAS - SLOAD_GAS</code>. Implementations that are using composite definitions have to ensure to update those definitions too.</p> <h3 id="selfdestruct-changes">SELFDESTRUCT changes</h3> <p>If the ETH recipient of a <code>SELFDESTRUCT</code> is not in <code>accessed_addresses</code> (regardless of whether or not the amount sent is nonzero), charge an additional <code>COLD_ACCOUNT_ACCESS_COST</code> on top of the existing gas costs, and add the ETH recipient to the set.</p> <p>Note: <code>SELFDESTRUCT</code> does not charge a <code>WARM_STORAGE_READ_COST</code> in case the recipient is already warm, which differs from how the other call-variants work. The reasoning behind this is to keep the changes small, a <code>SELFDESTRUCT</code> already costs <code>5K</code> and is a no-op if invoked more than once.</p> <h2 id="rationale">Rationale</h2> <h3 id="opcode-costs-vs-charging-per-byte-of-witness-data">Opcode costs vs charging per byte of witness data</h3> <p>The natural alternative path to changing gas costs to reflect witness sizes is to charge per byte of witness data. However, that would take a longer time to implement, hampering the goal of providing short-term security relief. Furthermore, following that path faithfully would lead to extremely high gas costs to transactions that touch contract code, as one would need to charge for all 24576 contract code bytes; this would be an unacceptably high burden on developers. It is better to wait for <a rel="external" href="https://medium.com/ewasm/evm-bytecode-merklization-2a8366ab0c90">code merklization</a> to start trying to properly account for gas costs of accessing individual chunks of code; from a short-term DoS prevention standpoint, accessing 24 kB from disk is not much more expensive than accessing 32 bytes from disk, so worrying about code size is not necessary.</p> <h3 id="adding-the-accessed-addresses-accessed-storage-keys-sets">Adding the accessed_addresses / accessed_storage_keys sets</h3> <p>The sets of already-accessed accounts and storage slots are added to avoid needlessly charging for things that can be cached (and in all performant implementations already are cached). Additionally, it removes the current undesirable status quo where it is needlessly unaffordable to do self-calls or call precompiles, and enables contract breakage mitigations that involve pre-fetching some storage key allowing a future execution to still take the expected amount of gas.</p> <h3 id="sstore-gas-cost-change">SSTORE gas cost change</h3> <p>The change to SSTORE is needed to avoid the possibility of a DoS attack that "pokes" a randomly chosen zero storage slot, changing it from 0 to 0 at a cost of 800 gas but requiring a de-facto storage load. The <code>SSTORE_RESET_GAS</code> reduction ensures that the total cost of SSTORE (which now requires paying the <code>COLD_SLOAD_COST</code>) remains unchanged. Additionally, note that applications that do <code>SLOAD</code> followed by <code>SSTORE</code> (eg. <code>storage_variable += x</code>) <em>would actually get cheaper</em>!</p> <h3 id="change-sstore-accounting-only-minimally">Change SSTORE accounting only minimally</h3> <p>The SSTORE gas costs continue to use Wei Tang's original/current/new approach, instead of being redesigned to use a dirty map, because Wei Tang's approach correctly accounts for the actual costs of changing storage, which only care about current vs final value and not intermediate values.</p> <h3 id="how-would-gas-consumption-of-average-applications-increase-under-this-proposal">How would gas consumption of average applications increase under this proposal?</h3> <h4 id="rough-analysis-from-witness-sizes">Rough analysis from witness sizes</h4> <p>We can look at <a rel="external" href="https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc">Alexey Akhunov's earlier work</a> for data on average-case blocks. In summary, average blocks have witness sizes of ~1000 kB, of which ~750 kB is Merkle proofs and not code. Assuming a conservative 2000 bytes per Merkle branch this implies ~375 accesses per block (SLOADs have a similar gas-increase-to-bytes ratio so there's no need to analyze them separately).</p> <p>Data on <a rel="external" href="https://etherscan.io/chart/tx">txs per day</a> and <a rel="external" href="https://etherscan.io/chart/blocks">blocks per day</a> from Etherscan gives ~160 transactions per block (reference date: Jul 1), implying a large portion of those accesses are just the <code>tx.sender</code> and <code>tx.to</code> which are excluded from gas cost increases, though likely less than 320 due to duplicate addresses.</p> <p>Hence, this implies ~50-375 chargeable accesses per block, and each access suffers a gas cost increase of 1900; <code>50 * 1900 = 95000</code> and <code>375 * 1900 = 712500</code>, implying the gas limit would need to be raised by ~1-6% to compensate. However, this analysis may be complicated further in either direction by (i) accounts / storage keys being accessed in multiple transactions, which would appear once in the witness but twice in gas cost increases, and (ii) accounts / storage keys being accessed multiple times in the same transaction, which lead to gas cost <em>decreases</em>.</p> <h4 id="goerli-analysis">Goerli analysis</h4> <p>A more precise analysis can be found by scanning Goerli transactions, as done by Martin Swende here: https://github.com/holiman/gasreprice</p> <p>The conclusion is that on average gas costs increase by ~2.36%. One major contributing factor to reducing gas costs is that a large number of contracts inefficiently read the same storage slot multiple times, which leads to this EIP giving a few transactions gas cost <em>savings</em> of over 10%.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These gas cost increases may potentially break contracts that depend on fixed gas costs; see the security considerations section for details and arguments for why we expect the total risks to be low and how if desired they can be reduced further.</p> <h2 id="test-cases">Test Cases</h2> <p>Some test cases can be found here: https://gist.github.com/holiman/174548cad102096858583c6fbbb0649a</p> <p>Ideally we would test the following:</p> <ul> <li>SLOAD the same storage slot {1, 2, 3} times</li> <li>CALL the same address {1, 2, 3} times</li> <li>(SLOAD | CALL) in a sub-call, then revert, then (SLOAD | CALL) the same (storage slot | address) again</li> <li>Sub-call, SLOAD, sub-call again, revert the inner sub-call, SLOAD the same storage slot</li> <li>SSTORE the same storage slot {1, 2, 3} times, using all combinations of zero/nonzero for original value and the value being set</li> <li>SSTORE then SLOAD the same storage slot</li> <li><code>OP_1</code> then <code>OP_2</code> to the same address where <code>OP_1</code> and <code>OP_2</code> are all combinations of (<code>*CALL</code>, <code>EXT*</code>, <code>SELFDESTRUCT</code>)</li> <li>Try to <code>CALL</code> an address but with all possible failure modes (not enough gas, not enough ETH...), then (<code>CALL</code> | <code>EXT*</code>) that address again successfully</li> </ul> <h2 id="implementation">Implementation</h2> <p>A WIP early-draft implementation for Geth can be found here: https://github.com/holiman/go-ethereum/tree/access_lists</p> <h2 id="security-considerations">Security Considerations</h2> <p>As with any gas cost increasing EIP, there are three possible cases where it could cause applications to break:</p> <ol> <li>Fixed gas limits to sub-calls in contracts</li> <li>Applications relying on contract calls that consume close to the full gas limit</li> <li>The 2300 base limit given to the callee by ETH-transferring calls</li> </ol> <p>These risks have been studied before in the context of an earlier gas cost increase, EIP-1884. See <a rel="external" href="https://github.com/holiman/eip-1884-security">Martin Swende's earlier report</a> and <a rel="external" href="https://gist.github.com/ritzdorf/1c6bd72955391e831f8a397d3152b4e0/">Hubert Ritzdorf's analysis</a> focusing on (1) and (3). (2) has received less analysis, though one can argue that it is very unlikely both because applications tend to very rarely use close to the entire gas limit in a transaction, and because gas limits were very recently raised from 10 million to 12.5 million. EIP-1884 in practice <a rel="external" href="https://www.coindesk.com/ethereums-istanbul-upgrade-will-break-680-smart-contracts-on-aragon">did lead to a small number of contracts breaking</a> for this reason.</p> <p>There are two ways to look at these risks. First, we can note that as of today developers have had years of warning; gas cost increases on storage-accessing opcodes have been <a rel="external" href="https://ethereum-magicians.org/t/protocol-changes-to-bound-witness-size/3885">discussed for a long time</a>, with multiple statements made including to major dapp developers around the likelihood of such changes. EIP-1884 itself provided an important wake-up call. Hence, we can argue that risks this time will be significantly lower than EIP-1884.</p> <h3 id="contract-breakage-mitigations">Contract breakage mitigations</h3> <p>A second way to look at the risks is to explore mitigations. First of all, the existence of an <code>accessed_addresses</code> and <code>accessed_storage_keys</code> map (present in this EIP, absent in EIP-1884) already makes some cases recoverable: in any case where a contract A needs to send funds to some address B, where that address accepts funds from any source but leaves a storage-dependent log, one can recover by first sending a separate call to B to pull it into the cache, and then call A, knowing that the execution of B triggered by A will only charge 100 gas per SLOAD. This fact does not fix all situations, but it does reduce risks significantly.</p> <p>But there are ways to further expand the usability of this pattern. One possibility is to add a <code>POKE</code> precompile, which would take an address and a storage key as input and allow transactions that attempt to "rescue" stuck contracts by pre-poking all of the storage slots that they will access. This works even if the address only accepts transactions from the contract, and works in many other contexts with present gas limits. The only case where this will not work would be the case where a transaction call <em>must</em> go from an EOA straight into a specific contract that then sub-calls another contract.</p> <p>Another option is <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, which would have a similar effect to <code>POKE</code> but is more general: it also works for the EOA -&gt; contract -&gt; contract case, and generally should work for all known cases of breakage due to gas cost increases. This option is more complex, though it is arguably a stepping stone toward access lists being used for other use cases (regenesis, account abstraction, SSA all demand access lists).</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-09-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/3102/ <h2 id="simple-summary">Simple Summary</h2> <p>Change the storage structure from hexary to binary, merge the account and storage tries, and use blake2b.</p> <h2 id="abstract">Abstract</h2> <p>This proposal presents a binary structure and merkelization rule for the account and storage tries, which are merged into a single “state” trie. RLP and most of the MPT’s optimizations are dropped to simplify the design. Keccak256 is replaced with blake2b.</p> <h2 id="motivation">Motivation</h2> <p>The current design of the Merkle Patricia Trie (MPT) uses an hexary trie. Hexary Merkle trees are more shallow than their binary counterparts, which means less hashing. Over the course of the 5 years of Ethereum’s existence, it has become apparent that disk accesses are a greater bottleneck than hashing. Clients are therefore moving away from a storage model in which all internal nodes are stored, in favor of a flat (key, value) storage model first used by turbo-geth, in which the intermediate nodes are recalculated only when needed.</p> <p>There is a push for making Ethereum easier to use in a stateless fashion. Binary tries make for smaller (~4x) proofs than hexary tries, making it the design of choice for a stateless-friendly Ethereum.</p> <p>For that same reason, the account and storage tries are merged in order to have a single proof for all changes.</p> <p>The MPT design is also rife with uncanny optimizations for size, that have a limited effect - at the cost of prohibitive complexity. For example, nesting for children whose RLP is less than 32 bytes saves an estimated 1MB of disk space. A paltry compared to the 300GB required by a fast sync at the time of this writing. These optimizations are a significant source of errors, and therefore a consensus-breaking risk. The reliance on RLP has also been criticized for its complexity, while the overhead of a general-purpose encoding scheme isn’t warranted for the rigid structure of a Merkle trie.</p> <p>The desire to switch the storage model from an hexary trie to a binary trie provides an opportunity to adopt a simpler trie architecture that pushes optimizations from the protocol level down to that of the client implementors.</p> <h2 id="specification">Specification</h2> <h3 id="conventions">Conventions</h3> <table><thead><tr><th style="text-align: center">Code</th><th>Description</th></tr></thead><tbody> <tr><td style="text-align: center"><code>u256(x)</code></td><td>Big endian, 32-byte representation of number <em>x</em></td></tr> <tr><td style="text-align: center">`</td><td></td></tr> <tr><td style="text-align: center"><code>++</code></td><td>Bit-wise concatenation operator</td></tr> <tr><td style="text-align: center"><code>0b0101</code></td><td>The binary string <code>0101</code></td></tr> <tr><td style="text-align: center"><code>hash()</code></td><td>The usual hashing function</td></tr> <tr><td style="text-align: center"><code>empty_hash</code></td><td>The empty hash: <code>hash("")</code></td></tr> <tr><td style="text-align: center"><code>length(x)</code></td><td>The byte length of object <code>x</code></td></tr> <tr><td style="text-align: center"><code>d[a..b]</code></td><td>The big-endian bit sequence taken from byte sequence <code>d</code>, starting at bit index <code>a</code>, up to and including the bit at index <code>b</code>.</td></tr> </tbody></table> <h3 id="notable-changes-from-the-hexary-structure">Notable changes from the hexary structure</h3> <ul> <li>Account and storage tries are merged, with key length between 32 and 64 bytes;</li> <li>RLP is no longer used;</li> <li>The "leaf marker" bit used in the hex prefix is also dropped. Leaves are identified as nodes with no children;</li> <li>Serialized nodes are hashed, no matter how small the byte length of the serialized nodes.</li> </ul> <h3 id="the-trie">The trie</h3> <h4 id="structure">Structure</h4> <p>The trie structure is made up of <em>nodes</em>. A node <code>N ≡ (N_l,N_r,N_p,N_v)</code> has the following 4 components:</p> <ul> <li><code>N_l</code> is the hash to the node's <em>left child</em>. If the node does not have a left child, then <code>N_l</code> is the empty hash <code>empty_hash</code>;</li> <li><code>N_r</code> is the hash to the node's <em>right child</em>. If the node does not have a right child, then <code>N_r</code> is the empty hash <code>empty_hash</code>;</li> <li>the optional <code>N_p</code> is the node's <em>prefix</em> : every key into the subtrie rooted at <code>N</code> is prefixed by this bit string;</li> <li><code>N_v</code> is the <em>value</em> stored at this node. The value is <strong>only present in leaf nodes</strong>.</li> </ul> <p>Nodes with <code>empty_hash</code> as both children are called <em>leaf nodes</em>, and the remaining nodes are known as <em>internal nodes</em>.</p> <h4 id="accessing-account-s-balance-nonce-code-storage-root-and-storage-slots">Accessing account's balance, nonce, code, storage root and storage slots</h4> <p>Assuming an account <code>A ≡ (A_b, A_n, A_c, A_s)</code> at address <code>A_a</code>, the following elements can be found at the following addresses:</p> <ul> <li>The account balance <code>A_b</code> can be found at key <code>hash(A_a)[0..253] ++ 0b00</code> and is of type <code>uint256</code>;</li> <li>The account nonce <code>A_n</code> can be found at key <code>hash(A_a)[0..253] ++ 0b01</code> and is of type <code>uint64</code>;</li> <li>The code <code>A_c</code> is an arbitrary-length byte sequence that can be found at key <code>hash(A_a)[0..253] ++ 0b10</code>;</li> <li>The root of the storage trie <code>A_s</code> can be found at key <code>hash(A_a)[0..253] ++ 0b11</code> <ul> <li>The storage slot number <code>k</code> can be found at key <code>hash(A_a)[0..253] ++ 0b11 ++ hash(k)</code>.</li> </ul> </li> </ul> <p>After <a href="https://wg-eips.ritovision.com/2926/">EIP-2926</a> has been rolled out, <code>A_c</code> will represent the root of the code merkelization tree. The key accessing code chunk number <code>c</code> is <code>hash(A_a)[0..253] ++ 0b10 ++ u256(c)</code>.</p> <p>In the unlikely future case that extra items are to be added to the trie at account level, a third bit can be reserved for future use.</p> <h3 id="node-merkelization-rule">Node merkelization rule</h3> <p>Leaves and nodes that have no prefix are hashed according to the rule below:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>internal_hash = hash(left_child_hash || right_child_hash)</span></span> <span class="giallo-l"><span>leaf_hash = hash(hash(key) || hash(leaf_value))</span></span></code></pre> <p>If a prefix is present, the length of the path from the root to the prefixed node is further concatenated with the output of the prefix-less rule, and hashed again:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>internal_hash_with_prefix = hash(u256(path_length_u256 - 1) || internal_hash)</span></span> <span class="giallo-l"><span>leaf_hash_with_prefix = hash(u256(path_length_u256 - 1) || leaf_hash)</span></span></code></pre><h2 id="rationale">Rationale</h2> <h3 id="blake2b">blake2b</h3> <p>BLAKE2 offers better performance, which is key to compensate for the loss of performance associated to a ~4x increase in the number of nodes.</p> <p>BLAKE3 offers even better performance. No official golang release exists at the time of the writing of this document. This presents a security risk, and therefore BLAKE2 is considered instead.</p> <h3 id="merging-of-the-account-and-storage-tries">Merging of the account and storage tries</h3> <p>The trend in clients is to store the keys and values in a "flat" database. Having the key of any storage slot prefixed with the address key of the account it belongs to helps grouping all of an account's data on disk, as well as simplifying the witness structure.</p> <h3 id="prefixes-and-extension-nodes">Prefixes and extension nodes</h3> <p>An alternative proposal has been made, which provides optimal witnesses. The trade-off is that extension nodes must be removed.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>node_hash = hash(left_child_hash || right_child_hash)</span></span> <span class="giallo-l"><span>leaf_hash = hash(0 || leaf_value)</span></span></code></pre> <p>The removal of extension nodes induces 40x higher hashing costs (on the order of 25ms for a trie with only 1k leaves) and as a result they have been kept.</p> <p>An attempt to keep extension nodes for witness and not the merkelization rule can be found <a rel="external" href="https://notes.ethereum.org/m5VMkX8FRvi0Q_OOR7TF4A">here</a>.</p> <p>Getting rid of complex methods like RLP, the hex prefix and children nesting is already offering great simplification.</p> <h3 id="2x32-byte-inputs">2x32-byte inputs</h3> <p>It has been requested to keep each node hash calculation as a function that takes two 256-bit integer as an input and outputs one 256-bit integer. This property is expected to play nice with circuit constructions and is therefore expected to greatly help with future zero-knowledge applications.</p> <h3 id="binary-tries">Binary tries</h3> <p>Binary tries have been chosen primarily because they reduce the witness size. In general, in an <code>N</code>-element tree with each element having <code>k</code> children, the average length of a branch is roughly <code>32 * (k-1) * log(N) / log(k)</code> plus a few percent for overhead. 32 is the length of a hash; the <code>k-1</code> refers to the fact that a Merkle proof needs to provide all <code>k-1</code> sister nodes at each level, and <code>log(N) / log(k)</code> is an approximation of the number of levels in the tree (eg. a tree where each node has 5 children, with 625 nodes total, would have depth 4, as <code>625 = 5**4</code> and so <code>log(625) / log(5) = 4</code>).</p> <p>For any <code>N</code>, the expression is minimized at <code>k = 2</code>. Here's a table of branch lengths for different <code>k</code> values assuming <code>N = 2**24</code>:</p> <table><thead><tr><th><code>k</code> (children per node)</th><th>Branch length (chunks)</th><th>Branch length (bytes)</th></tr></thead><tbody> <tr><td>2</td><td>1 * 24 = 24</td><td>768</td></tr> <tr><td>4</td><td>3 * 12 = 36</td><td>1152</td></tr> <tr><td>8</td><td>7 * 8 = 56</td><td>1792</td></tr> <tr><td>16</td><td>15 * 6 = 90</td><td>2880</td></tr> </tbody></table> <p>Actual branch lengths will be slightly larger than this due to uneven distribution and overhead, but the pattern of <code>k=2</code> being by far the best remains.</p> <p>The ethereum tree was originally hexary because this would reduce the number of database reads (eg. 6 instead of 24 in the above example). It is now understood that this reasoning was flawed, because nodes can still "pretend" that a binary tree is a hexary (or even 256-ary) tree at the database layer (eg. see https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751), and thereby get the best-of-both-worlds of having the low proof sizes of the tree being binary from a hash-structure perspective and at the same time a much more efficient representation in the database.</p> <p>Additionally, binary trees are expected to be widely used in Eth2, so this path improves forward-compatibility and reduces long-run total complexity for the protocol.</p> <h3 id="path-length-instead-of-bit-prefix">Path length instead of bit prefix</h3> <p>In order to remove the complexity associated with byte manipulation, only the bit-length of the extension is used to merkelize a node with a prefix.</p> <p>Storing the length of the path from the root node instead of that from the parent node has the nice property that siblings need not be hashed when deleting a leaf.</p> <p><img src="https://wg-eips.ritovision.com/3102/./assets/sibling.svg" alt="Sibling deletion diagram" /></p> <p><em>On the left, a trie with the prefix length, and on the right, a trie with the full path length. Each both have values <code>10000100</code> and <code>10000000</code>. After deleting <code>10000100</code>,the sibling node has to be updated in the left tree, while it need not be in the case on the right.</em></p> <h3 id="value-hashing">Value hashing</h3> <p>Except for the code, all values in the trie are less than 32 bytes. EIP-2926 introduces code chunks, with <code>CHUNK_SIZE = 32 bytes</code>. The hashing of the leaf's value could therefore be saved. The authors of the EIP are however considering a future increase of <code>CHUNK_SIZE</code>, making <code>hash(value)</code> the future-proof choice.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>A hard fork is required in order for blocks to have a trie root using a different structure.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <ul> <li>As of <a rel="external" href="https://github.com/gballet/multiproof-rs/commit/6d22b1aef9548581826b3c04b3e00d6cc709388c">commit 0db87e187dc0bfb96046a47e3d6768c93a2e3331</a>, <a rel="external" href="https://github.com/gballet/multiproof-rs">multiproof-rs</a> implements this merkelization rule in the <code>hash_m5()</code> function, found in file <code>src/binary_tree.rs</code>.</li> <li>An implementation of this structure for go-ethereum is available <a rel="external" href="https://github.com/gballet/go-ethereum/tree/rebased-binary-trie-m5-full-path">in this branch</a>.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Issues could arise when performing the transition. In particular, a heavy conversion process could incentivize clients to wait the transition out. This could lead to a lowered network security at the time of the transition. A transition process has been proposed with <a href="https://wg-eips.ritovision.com/2584/">EIP-2584</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-08-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Martin Swendehttps://github.com/holiman https://wg-eips.ritovision.com/2930/ <h2 id="simple-summary">Simple Summary</h2> <p>Adds a transaction type which contains an access list, a list of addresses and storage keys that the transaction plans to access. Accesses outside the list are possible, but become more expensive.</p> <h2 id="abstract">Abstract</h2> <p>We introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type, with the format <code>0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])</code>.</p> <p>The <code>accessList</code> specifies a list of addresses and storage keys; these addresses and storage keys are added into the <code>accessed_addresses</code> and <code>accessed_storage_keys</code> global sets (introduced in <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>). A gas cost is charged, though at a discount relative to the cost of accessing outside the list.</p> <h2 id="motivation">Motivation</h2> <p>This EIP serves two functions:</p> <ol> <li>Mitigates contract breakage risks introduced by <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>, as transactions could pre-specify and pre-pay for the accounts and storage slots that the transaction plans to access; as a result, in the actual execution, the SLOAD and EXT* opcodes would only cost 100 gas: low enough that it would not only prevent breakage due to that EIP but also "unstuck" any contracts that became stuck due to EIP 1884.</li> <li>Introduces the access list format and the logic for handling the format. This logic can later be repurposed for many other purposes, including block-wide witnesses, use in ReGenesis, moving toward static state access over time, and more.</li> </ol> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <p><strong><code>TransactionType</code></strong> <code>1</code>. See <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a></p> <p><strong><code>ChainId</code></strong> The transaction only valid on networks with this <code>chainID</code>.</p> <p><strong><code>YParity</code></strong> The parity (0 for even, 1 for odd) of the y-value of a secp256k1 signature.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Constant</th><th>Value</th></tr></thead><tbody> <tr><td><code>FORK_BLOCK</code></td><td>12244000</td></tr> <tr><td><code>ACCESS_LIST_STORAGE_KEY_COST</code></td><td>1900</td></tr> <tr><td><code>ACCESS_LIST_ADDRESS_COST</code></td><td>2400</td></tr> </tbody></table> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> <code>1</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is <code>rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])</code>.</p> <p>The <code>signatureYParity, signatureR, signatureS</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList]))</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulativeGasUsed, logsBloom, logs])</code>.</p> <p>For the transaction to be valid, <code>accessList</code> must be of type <code>[[{20 bytes}, [{32 bytes}...]]...]</code>, where <code>...</code> means "zero or more of the thing to the left". For example, the following is a valid access list (all hex strings would in reality be in byte representation):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[</span></span> <span class="giallo-l"><span> [</span></span> <span class="giallo-l"><span> &quot;0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae&quot;,</span></span> <span class="giallo-l"><span> [</span></span> <span class="giallo-l"><span> &quot;0x0000000000000000000000000000000000000000000000000000000000000003&quot;,</span></span> <span class="giallo-l"><span> &quot;0x0000000000000000000000000000000000000000000000000000000000000007&quot;</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span> ],</span></span> <span class="giallo-l"><span> [</span></span> <span class="giallo-l"><span> &quot;0xbb9bc244d798123fde783fcc1c72d3bb8c189413&quot;,</span></span> <span class="giallo-l"><span> []</span></span> <span class="giallo-l"><span> ]</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>At the beginning of execution (ie. at the same time as the <code>21000 + 4 * zeroes + 16 * nonzeroes</code> start gas is charged according to <a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a> rules), we charge additional gas for the access list: <code>ACCESS_LIST_ADDRESS_COST</code> gas per address and <code>ACCESS_LIST_STORAGE_KEY_COST</code> gas per storage key. For example, the above example would be charged <code>ACCESS_LIST_ADDRESS_COST * 2 + ACCESS_LIST_STORAGE_KEY_COST * 2</code> gas.</p> <p>Note that non-unique addresses and storage keys are not disallowed, though they will be charged for multiple times, and aside from the higher gas cost there is no other difference in execution flow or outcome from multiple-inclusion of a value as opposed to the recommended single-inclusion.</p> <p>The address and storage keys would be immediately loaded into the <code>accessed_addresses</code> and <code>accessed_storage_keys</code> global sets; this can be done using the following logic (which doubles as a specification-in-code of validation of the RLP-decoded access list)</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> process_access_list</span><span>(</span><span class="z-variable z-parameter z-function">access_list</span><span>)</span><span> -&gt;</span><span> Tuple</span><span>[</span><span>List</span><span>[</span><span>Set</span><span>[</span><span>Address</span><span>]</span><span>,</span><span> Set</span><span>[</span><span>Pair</span><span>[</span><span>Address</span><span>,</span><span> Bytes32</span><span>]</span><span>]</span><span>]</span><span>,</span><span class="z-support"> int</span><span>]</span><span>:</span></span> <span class="giallo-l"><span> accessed_addresses</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> accessed_storage_keys</span><span class="z-keyword"> =</span><span class="z-support"> set</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>access_list</span><span>,</span><span class="z-support"> list</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> item</span><span class="z-keyword"> in</span><span> access_list</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>item</span><span>,</span><span class="z-support"> list</span><span>)</span><span class="z-keyword"> and</span><span class="z-support"> len</span><span>(</span><span>item</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate and add the address</span></span> <span class="giallo-l"><span> address</span><span class="z-keyword"> =</span><span> item</span><span>[</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>address</span><span>,</span><span class="z-support"> bytes</span><span>)</span><span class="z-keyword"> and</span><span class="z-support"> len</span><span>(</span><span>address</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 20</span></span> <span class="giallo-l"><span> accessed_addresses</span><span>.</span><span>add</span><span>(</span><span>address</span><span>)</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> ACCESS_LIST_ADDRESS_COST</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Validate and add the storage keys</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>item</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span class="z-support"> list</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> key</span><span class="z-keyword"> in</span><span> item</span><span>[</span><span class="z-constant">1</span><span>]</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span class="z-support"> isinstance</span><span>(</span><span>key</span><span>,</span><span class="z-support"> bytes</span><span>)</span><span class="z-keyword"> and</span><span class="z-support"> len</span><span>(</span><span>key</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 32</span></span> <span class="giallo-l"><span> accessed_storage_keys</span><span>.</span><span>add</span><span>(</span><span>(</span><span>address</span><span>,</span><span> key</span><span>)</span><span>)</span></span> <span class="giallo-l"><span> gas_cost</span><span class="z-keyword"> +=</span><span class="z-constant"> ACCESS_LIST_STORAGE_KEY_COST</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span></span> <span class="giallo-l"><span> accessed_addresses</span><span>,</span></span> <span class="giallo-l"><span> accessed_storage_keys</span><span>,</span></span> <span class="giallo-l"><span> gas_cost</span></span> <span class="giallo-l"><span> )</span></span></code></pre> <p>The access list is NOT charged per-byte fees like tx data is; the per-item costs described above are meant to cover the bandwidth costs of the access list data in addition to the costs of accessing those accounts and storage keys when evaluating the transaction.</p> <h2 id="rationale">Rationale</h2> <h3 id="charging-less-for-accesses-in-the-access-list">Charging less for accesses in the access list</h3> <p>This is done to encourage transactions to use the access list as much as possible, and because processing transactions is easier when their storage reads are predictable (because clients can pre-load the data from databases and/or ask for witnesses at the time the transaction is received, or at least load the data in parallel).</p> <h3 id="allowing-duplicates">Allowing duplicates</h3> <p>This is done because it maximizes simplicity, avoiding questions of what to prevent duplication against: just between two addresses/keys in the access list, between the access list and the tx sender/recipient/newly created contract, other restrictions? Because gas is charged per item, there is no gain and only cost in including a value in the access list twice, so this should not lead to extra chain bloat in practice.</p> <h3 id="signature-signs-over-the-transaction-type-as-well-as-the-transaction-data">Signature signs over the transaction type as well as the transaction data</h3> <p>This is done to ensure that the transaction cannot be "re-interpreted" as a transaction of a different type.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP does make it more gas-expensive to perform "unexpected" SLOADs and account accesses. Because gas is prepaid and so does not affect fixed-gas local calls, it does not break contracts in the way that previous gas cost increases would risk. However, it does make applications that heavily rely on storage access much less economically viable.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="access-list-generation">Access list generation</h3> <p>Access lists are difficult to construct in real-time in many situations, and this is exacerbated in environments where there is a high time lag between transaction generation and signing or simplicity of the transaction generator is highly valued (eg. either or both may apply in hardware wallets).</p> <p>However, this EIP proposes only a 10% initial discount to access lists, so there is almost no cost to not bothering with access list generation and only making a simple transaction. The cost of accessing state outside the access list is expected to be ramped up in future hard forks over time as tools are developed and access list generation becomes more mature.</p> <h3 id="transaction-size-bloating">Transaction size bloating</h3> <p>Average block size will increase as a result of access lists being used. However, the per-byte cost of access lists is <code>1900 / 32 = 59.375</code> for storage keys and <code>2400 / 20 = 120</code> for addresses, making it much more expensive than calldata; hence, worst-case block size will not increase. Additionally, increases in average block size will be partially compensated for by the ability to pre-fetch storage at time of receiving a transaction and/or load storage in parallel upon receiving a block.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-08-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Sina Mahmoodihttps://github.com/s1na Alex Beregszaszihttps://github.com/axic Guillaume Ballethttps://github.com/gballet Jochem Brouwerhttps://github.com/jochem-brouwer Ignacio Hagopianhttps://github.com/jsign https://wg-eips.ritovision.com/2926/

Introduce code-chunking in an MPT context.

<h2 id="abstract">Abstract</h2> <p>Code merkleization, along with binarification of the trie and gas cost bump of state-accessing opcodes, are considered as the main levers for decreasing block witness sizes in stateless or partial-stateless Eth1x roadmaps. Here we specify a fixed-sized chunk approach to code merkleization and outline how the transition of existing contracts to this model would look like.</p> <h2 id="motivation">Motivation</h2> <p>Bytecode is currently the second contributor to block witness size, after the proof hashes. Transitioning the trie from hexary to binary reduces the hash section of the witness by 3x, thereby making code the first contributor. By breaking contract code into chunks and committing to those chunks in a merkle tree, stateless clients would only need the chunks that were touched during a given transaction to execute it.</p> <h2 id="specification">Specification</h2> <p>What follows is structured to have two sections:</p> <ol> <li>How a given contract code is split into chunks and then merkleized</li> <li>How to merkleize all existing contract codes during a hardfork</li> </ol> <h3 id="constants-and-definitions">Constants and Definitions</h3> <h4 id="constants">Constants</h4> <ul> <li><code>CHUNK_SIZE</code>: 31 (bytes)</li> <li><code>VERSION_KEY</code>: <code>max(u256)</code></li> <li><code>VERSION</code>: 0</li> <li><code>EMPTY_CODE_ROOT</code>: <code>0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code> (==<code>keccak256('')</code>)</li> <li><code>HF_TIMESTAMP</code>: to be defined</li> <li><code>ITERATOR_STRIDE</code>: <code>TBC</code> but based on verkle numbers, first devnets should use <code>50_000</code></li> </ul> <h4 id="definitions">Definitions</h4> <ul> <li><code>BE(x, N)</code>: casts <code>x</code> to an unsigned integer of <code>N</code> bytes and returns its big-endian representation</li> </ul> <h3 id="code-merkleization">Code merkleization</h3> <p>For an account record <code>A</code> with code <code>C</code>, two extra optional fields are added: <code>A.codeSize</code> and <code>A.codeRoot</code>. <code>A.codeHash</code> is retained to serve <code>EXTCODEHASH</code>.</p> <p>If <code>C</code> is empty, i.e. in the case of an EoA, <code>A.codeRoot</code> and <code>A.codeSize</code> are omitted from the account's RLP. This is intended to limit the size overhead of this change.</p> <p>If <code>C</code> is not empty:</p> <ul> <li><code>A.codeSize = len(code)</code></li> <li><code>A.codeRoot</code> contains the root of <code>codeTrie</code>, a trie with the following leaves: <ul> <li>Key: <code>VERSION_KEY</code>, value: <code>BE(VERSION, 1)</code></li> <li>A list of code <code>chunks = [(FIO_0, code_0), ..., (FIO_n, code_n)]</code> which are derived from <code>C</code> as follows: <ul> <li><code>code_0 || ... || code_n == C</code>.</li> <li><code>length(code_i) == CHUNK_SIZE</code> where <code>0 &lt;= i &lt; n</code>.</li> <li><code>length(code_n) &lt;= CHUNK_SIZE</code>.</li> <li><code>FIO_i</code> is the offset of the first instruction within the chunk. It should only be greater than zero if the last instruction in <code>code_i-1</code> is a multi-byte instruction (like <code>PUSHN</code>) crossing the chunk boundary. It is set to <code>CHUNK_SIZE</code> in the case where all bytes of a chunk are data.</li> </ul> </li> </ul> </li> </ul> <p>The <code>i</code>th element of <code>chunks</code> is stored in <code>codeTrie</code> with:</p> <ul> <li>Key: <code>BE(i, 4)</code></li> <li>Value: <code>BE(FIO_i, 1) || code_i</code>, where <code>||</code> stands for byte-wise concatenation</li> </ul> <h4 id="contract-creation-gas-cost">Contract creation gas cost</h4> <p>As of now there is a charge of 200 gas per byte of the code stored in state by contract creation operations, be it initiated via <code>CREATE</code>, <code>CREATE2</code>, or an external transaction. This per byte cost is to be increased from <code>200</code> to <code>500</code> to account for the chunking and merkleization costs. This number is inherited from <a href="https://wg-eips.ritovision.com/4762/">EIP-4762</a> and is picked for forward-compatibility.</p> <h3 id="updating-existing-code-transition-process">Updating existing code (transition process)</h3> <p>The transition process involves reading all contracts in the state and applying the above procedure to them. A process similar to <a href="https://wg-eips.ritovision.com/7612/">EIP-7612</a> is to be used, as the total code size at the time of this EIP edit is &gt;10GB and can not be processed in a single block.</p> <p>Note that:</p> <ul> <li>Because multiple accounts can share the same code hash, the whole account tree needs to be iterated over to convert each account. Only iterating over the bytecodes isn't enough.</li> <li>Nonetheless, the conversion process should take a few hours, instead of days for a full tree change.</li> </ul> <p>At <code>HF_TIMESTAMP</code> the EIP gets activated:</p> <ul> <li>any contract creation and 7702 delegation updates must use the new format. <ul> <li>for 7702 accounts, the code size is set to <code>23</code>, and <code>CODESIZE</code>/<code>CODECOPY</code> are forwarded to the delegated account. <code>EXTCODESIZE</code>/<code>EXTCODEHASH</code>/<code>EXTCODECOPY</code> behave the same as they did before the activation of this EIP.</li> <li>accounts are NOT converted in case of a balance or nonce update: accounts are converted by the iterator sweep or automatically at creation time.</li> </ul> </li> <li>at the end of block processing, and after all transactions have been executed but before recomputing the tree root hash, the client iterates over <code>ITERATOR_STRIDE</code> accounts in the tree, and for each account: <ul> <li>if the account has empty code, or is a contract using the new format, leave that account untouched,</li> <li>if the account is a "legacy" contract, convert it and write it back to the tree</li> </ul> </li> </ul> <p>The value for <code>ITERATOR_STRIDE</code> has been chosen to be safe while ensuring the transition process does not last too long. At the current state size and block time, this represents about 10000 blocks, which is about one and a half day.</p> <p>Following the transition process described in <a href="https://wg-eips.ritovision.com/8032/">EIP-8032</a>, the transition process uses a system contract to store its progress pointers. The transition process has been designed in such a way that if both EIPs are activated at the same time, their transition process can be merged. Refer to that EIP for more details.</p> <p>Note that for a bytecode used by multiple contracts, the chunking need happen only once. Such contract only need to update their code size and code root, which MAY be cached during the transition process.</p> <h2 id="rationale">Rationale</h2> <h3 id="hexary-vs-binary-trie">Hexary vs binary trie</h3> <p>The trie format is chosen to be the same as that of the account trie. If a tree conversion happens at a later stage, the chunk tree will have to be converted as well, e.g. the way it is in <a href="https://wg-eips.ritovision.com/6800/">EIP-6800</a> or <a href="https://wg-eips.ritovision.com/7864/">EIP-7864</a>.</p> <h3 id="chunk-size">Chunk size</h3> <p>The current recommended chunk size of 31 bytes has been selected based on a few observations. Smaller chunks are more efficient (i.e. have higher chunk utilization), but incur a larger hash overhead (i.e. number of hashes as part of the proof) due to a higher trie depth. Larger chunks are less efficient, but incur less hash overhead. We plan to run a larger experiment comparing various chunk sizes to arrive at a final recommendation.</p> <h3 id="first-instruction-offset">First instruction offset</h3> <p>The <code>firstInstructionOffset</code> field allows safe jumpdest analysis when a client doesn't have all the chunks, e.g. a stateless clients receiving block witnesses.</p> <p>Note: there could be an edge case when computing FIO for the chunks where the data bytes at the end of a bytecode (last chunk) resemble a multi-byte instruction. This case can be safely ignored.</p> <h3 id="gas-cost-of-code-accessing-opcodes">Gas cost of code-accessing opcodes</h3> <p>Details of how the code is stored, is left to the client implementers. However, to reflect the removal of the max code limit and the fact that larger codes will be more expensive to load, reading a non-accessed chunk will incur a 200 warming cost, and chunks written beyond the 24kb limit will cost 500 gas instead of 200.</p> <h3 id="different-chunking-logic">Different chunking logic</h3> <p>We have considered an alternative option to package chunks, where each chunk is prepended with its <code>chunkLength</code> and would only contain complete opcodes (i.e. any multi-byte opcode not fitting the <code>CHUNK_SIZE</code> would be deferred to the next chunk).</p> <p>This approach has downsides compared to the one specified:</p> <ol> <li>Requires a larger <code>CHUNK_SIZE</code> -- at least 33 bytes to accommodate the <code>PUSH32</code> instruction.</li> <li>It is more wasteful. For example, <code>DUP1 PUSH32 &lt;32-byte payload&gt;</code> would be encoded as two chunks, the first chunk contains only <code>DUP1</code>, and the second contains only the <code>PUSH32</code> instruction with its payload.</li> <li>Calculating the number of chunks is not trivial and would have to be stored explicitly in the metadata.</li> </ol> <p>Additionally we have reviewed many other options (basic block based, Solidity subroutines (requires determining the control flow), EIP-2315 subroutines). This EIP however only focuses on the chunk-based option.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>From the perspective of contracts, the design aims to be transparent, with the exception of changes in gas costs.</p> <p>Outside of the interface presented for contracts, this proposal introduces major changes to the way contract code is stored, and needs a substantial modification of the Ethereum state. Therefore it can only be introduced via a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <p>Show the <code>codeRoot</code> for the following cases:</p> <ol> <li><code>code=''</code></li> <li><code>code='PUSH1(0) DUP1 REVERT'</code></li> <li><code>code='PUSH32(-1)'</code> (data passing through a chunk boundary)</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-07-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/2803/

Support 'rich transactions' by allowing transactions from externally owned accounts to execute bytecode directly.

<h2 id="abstract">Abstract</h2> <p>If a transaction has a <code>to</code> of address <code>x</code>, then the <code>data</code> of the transaction will be treated as EVM bytecode and it will be executed from the context of the <code>CALLER</code> of the transaction (aka: the transaction signer).</p> <h2 id="motivation">Motivation</h2> <p>Many Ethereum DApps presently require users to approve multiple transactions in order to produce one effect - for example, the common pattern of first approving a contract to spend a token, then calling that contract. This results in a poor user-experience, and complicates the experience of interacting with DApps.</p> <p>Making it possible for externally owned accounts to execute EVM bytecode directly allows a single transaction to execute multiple contract calls, allowing DApps to provide a streamlined experience, where every interaction results in at most one transaction.</p> <p>While this is in principle possible today using contract wallets, other UX issues, such as the need to fund a sending account with gas money, lack of support for contract wallets in browser integrations, and lack of a consistent API for contract wallets has led to poor adoption of these.This EIP is a way of enhancing the utility of existing EOAs, in the spirit of "don't let the perfect be the enemy of the good".</p> <h2 id="specification">Specification</h2> <p>A new reserved address is specified at <code>x</code>, in the range used for precompiles. When a transaction is sent to this address from an externally owned account, the payload of the transaction is treated as EVM bytecode, and executed with the signer of the transaction as the current account. For clarity:</p> <ul> <li>The <code>ADDRESS</code> opcode returns the address of the EOA that signed the transaction.</li> <li>The <code>BALANCE</code> opcode returns the balance of the EOA that signed the transaction.</li> <li>Any <code>CALL</code> operations that send value take their value from the EOA that signed the transaction.</li> <li><code>CALL</code> will set the <code>CALLER</code> to the EOA (not <code>x</code>).</li> <li><code>DELEGATECALL</code> preserves the EOA as the owning account.</li> <li>The <code>CALLER</code> and <code>ORIGIN</code> opcodes both return the address of the EOA that signed the transaction.</li> <li>There is no code associated with the precompile address. <code>CODE*</code> and <code>EXTCODE*</code> opcodes behave the same as they do for any empty address.</li> <li><code>CALLDATA*</code> opcodes operate on the transaction payload as expected.</li> <li><code>SLOAD</code> and <code>SSTORE</code> operate on the storage of the EOA. As a result, an EOA can have data in storage, that persists between transactions.</li> <li>The <code>SELFDESTRUCT</code> opcode does nothing.</li> <li>All other opcodes behave as expected for a call to a contract address.</li> <li>The transaction is invalid if there is any value attached.</li> <li>A call to the precompile address from a contract has no special effect and is equivalent to a call to a nonexistent precompile or an empty address.</li> </ul> <h2 id="rationale">Rationale</h2> <p>The intent of this EIP is for the new precompile to act in all ways possible like a <code>DELEGATECALL</code> from an externally owned account. Some changes are required to reflect the fact that the code being executed is not stored on chain, and for special cases such as <code>SELFDESTRUCT</code>, to prevent introducing new edge-cases such as the ability to zero-out an EOA's nonce.</p> <p>A precompile was used rather than a new EIP-2718 transaction type because a precompile allows us to have a rich transaction with any type of EIP-2718 transaction.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces a new feature that will need to be implemented in a future hard fork. No backwards compatibility issues with existing code are expected.</p> <p>Contracts or DApps that assume that an EOA cannot atomically perform multiple operations may be affected by this change, as this now makes it possible for EOAs to execute multiple atomic operations together. The authors do not believe this is a significant use-case, as this 'protection' is already trivially defeated by miners.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-07-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Matt Garnetthttps://github.com/lightclient Uri Klarmanhttps://github.com/uriklarman Ben Adamshttps://github.com/benaadams Maria Inês Silvahttps://github.com/misilva73 Anders Elowssonhttps://github.com/anderselowsson Anthony Sassanohttps://github.com/sassal https://wg-eips.ritovision.com/2780/

Reduce intrinsic transaction gas and charge 25k when a value transfer creates a new account

<h2 id="abstract">Abstract</h2> <p>Reduce the intrinsic cost <code>TX_BASE_COST</code> from <code>21,000</code> to <code>4,500</code> and define a consistent gas accounting model based on actual state operations. This more granular approach makes a simple ETH transfer <code>6,000</code> from additional costs related to the <code>to</code> account.</p> <p>If a non-create transaction has <code>value &gt; 0</code> and targets a non-existent account, charge <code>GAS_NEW_ACCOUNT = 25,000</code> to align with <code>CALL</code> account creation and price in state growth. When this surcharge applies, the recipient pays exactly one cold non-code touch; no code-load cost applies.</p> <p>This EIP does not change calldata or access-list metering. It also refines related gas schedule items used in derivation and execution accounting:</p> <ul> <li>Split cold-account touches into <code>COLD_ACCOUNT_COST_CODE = 2,600</code> and <code>COLD_ACCOUNT_COST_NOCODE = 500</code>.</li> <li>Introduce <code>STATE_UPDATE = 1,000</code> as the price of a single account-leaf write.</li> <li>Reprice value-moving calls as account-leaf writes, replacing <code>CALL_VALUE_COST = 9,000</code> with <code>CALL_VALUE_COST = 2 * STATE_UPDATE = 2,000</code>.</li> <li>Specify that a <code>PAY</code>-style value-move primitive, if present, does not warm its recipient and never loads code (charged at <code>COLD_ACCOUNT_COST_NOCODE</code> if not already warmed).</li> </ul> <p>Capacity impact (illustrative):</p> <table><thead><tr><th>Metric</th><th style="text-align: right">Result</th><th style="text-align: right">Change</th><th>Description</th></tr></thead><tbody> <tr><td>Max (minimal txs)</td><td style="text-align: right">13,333 tx / block</td><td style="text-align: right">+367%</td><td>4,500-gas minimal transactions per 60 M block</td></tr> <tr><td>Max (ETH transfers)</td><td style="text-align: right">10,000 tx / block</td><td style="text-align: right">+250%</td><td>6,000-gas ETH transfers per 60 M block</td></tr> <tr><td>Thoughput (minimal txs)</td><td style="text-align: right">~1,111 TPS</td><td style="text-align: right">+367%</td><td>4,500-gas minimal transactions per 60 M block per 12sec</td></tr> <tr><td>Thoughput (ETH transfers)</td><td style="text-align: right">~833 TPS</td><td style="text-align: right">+250%</td><td>6,000-gas ETH transfers per 60 M block per 12sec</td></tr> <tr><td>Equivalent gas-limit uplift</td><td style="text-align: right">≈ +20.8%</td><td style="text-align: right">-</td><td>Effective throughput gain for ave tx usage (e.g., 60 M =&gt; ~72.5 M)</td></tr> </tbody></table> <h2 id="motivation">Motivation</h2> <p><strong>Monetary Context</strong></p> <p>Money has three basic functions: a unit of account, a medium of exchange, and a store of value. ETH already meets the last two by design. It carries value without an issuer and settles with finality. Where it falls short is in everyday exchange - the friction of use rather than the nature of the asset.</p> <p>ETH underpins most onchain liquidity. Pairs are denominated in it, and gas is paid in it - a de-facto tax base that anchors value. Bitcoin's monetary role now runs mainly through exchange pairs, hence its drift in focus to store-of-value rather than medium-of-exchange. ETH still clears real activity onchain, yet outside NFTs few people think in ETH terms. In that niche ETH already functions as both unit and medium, but only for high-value items.</p> <p>For ETH to operate fully as money, it must also handle small transactions. That was impractical when gas sat at 300 gwei, or even 90 gwei on quiet weekends. Post-4844, blobs absorb L2's "pay at any price" data and higher gaslimits ease congestion; cost, not capacity, is the bottleneck.</p> <p>EIP-2780 lowers that fixed cost. By aligning the base gas with the real work of a transaction and by correcting <code>CALL</code> value pricing, it removes the legacy penalty on simple payments. Small transfers become viable again without subsidising calldata or storage. The same logic charges properly for new-account creation, so state growth remains priced in.</p> <ul> <li> <p><strong>Unit of account:</strong> When transfers are cheap and regular, people price in ETH because they use it directly. This proposal turns that habit into equilibrium rather than idealism.</p> </li> <li> <p><strong>Medium of exchange:</strong> Reducing <code>TX_BASE_COST</code> eliminates the old friction that slowed native circulation. Settlement becomes frequent, not occasional.</p> </li> <li> <p><strong>Store of value:</strong> Honest pricing reinforces confidence that ETH's cost structure is grounded in real computation, not arbitrary constants.</p> </li> <li> <p><strong>Velocity:</strong> Lower friction raises the rate of final settlement; more frequent, smaller clears in native ETH, without altering calldata or storage economics.</p> </li> <li> <p><strong>Monetary competition:</strong> Stablecoins and LSTs are welcome, but they compete for onchain "moneyness". Making native ETH easy to spend keeps it central; not just the fuel, but the money of the system.</p> </li> </ul> <p><strong>Note:</strong> This proposal doesn't target ETH specifically, the lower base cost applies to every transaction type. However since <code>TX_BASE_COST</code> makes up nearly all of an ETH transfer's gas, while it's only a small fraction of contract calls, ETH loses the most friction and gains the most velocity.</p> <p><strong>Specifics</strong></p> <p>The legacy <code>21,000</code> base no longer matches the universal work path under warm/cold accounting. Decomposed into signature recovery, one account-leaf write for the sender (nonce + balance coalesced), and one cold non-code touch (sender), the universal path totals <code>4,500</code> gas.</p> <p>State growth is underpriced for top-level value transfers that create accounts, while <code>CALL</code> pays explicit creation. Charging <code>25,000</code> when a transfer creates an account aligns entry points and internalizes state growth.</p> <p>A lower base removes the distortion that over-incentivized batching solely to dodge <code>TX_BASE_COST</code>, without subsidizing calldata or storage. The refinement of value-transfer costs and cold-account pricing makes execution charges proportional to actual state work: account touches and leaf writes.</p> <p>We intentionally do <strong>not</strong> charge per-byte gas for the transaction envelope (<code>nonce</code>, <code>gas*</code>, <code>to</code>, <code>value</code>, <code>v</code>, <code>r</code>, <code>s</code>). Calldata pricing applies only to <code>tx.data</code>. A plain ETH payment has empty <code>tx.data</code>, so it pays zero calldata gas. Lowering <code>TX_BASE_COST</code> to the universal work path makes ETH payments cheaper without subsidizing arbitrary calldata.</p> <h3 id="throughput-payload-and-basefee-dynamics">Throughput, payload, and basefee dynamics</h3> <p>This EIP affects three independent levers:</p> <ol> <li> <p><strong>Gas-limit equivalence:</strong> Reducing the base cost from <code>21,000</code> to <code>4,500</code> increases transaction capacity at a fixed block gaslimit by approximately +20.8%.</p> </li> <li> <p><strong>Payload-size bounds:</strong> Per <a href="https://wg-eips.ritovision.com/7934/">EIP-7934</a> the execution payload cap is <code>MAX_RLP_BLOCK_SIZE = 10,485,760 - 2,097,152 = 8,388,608</code> bytes. Payload size, not gas, may become the dominant block-size constraint at high gaslimits.</p> </li> <li> <p><strong>Basefee market dynamics:</strong> Lower intrinsic gas reduces the average gas per tx, temporarily increasing utilisation and causing short-term downward adjustment in basefee. Over time, equilibrium restores as inclusion policies adapt.</p> </li> </ol> <p>These levers are independent; this proposal changes only intrinsic gas, not calldata metering or access-list pricing.</p> <h3 id="monetary-effects">Monetary Effects</h3> <p>Reducing ETH transfer cost from <code>21,000</code> =&gt; <code>6,000</code> gas increases both transaction frequency and viable payment granularity. At a fixed basefee, smaller payments become economical, raising the <strong>velocity of money</strong> - how often ETH changes hands on L1.</p> <p>Let $g$ be gas per transaction, $b$ the basefee (in gwei), and $r$ the user's tolerated fee share of payment value.</p> <p>$v_{\text{min}} = \frac{g \times b \times 10^{-9}}{r}$</p> <p>Since $g$ drops from $21,000$ to $6,000$:</p> <p>$\frac{v_{\text{min,new}}}{v_{\text{min,old}}} = \frac{6{,}000}{21{,}000} \approx 0.29$</p> <p>The minimum economical L1 payment falls by about <strong>71 %</strong>, allowing more, smaller transfers to clear directly in ETH.</p> <p>From the quantity relation $M V = P Q$, with $M$ and $P$ roughly constant over short periods:</p> <p>$V_{\text{new}} / V_{\text{old}} \approx Q_{\text{new}} / Q_{\text{old}}$</p> <p>Pure ETH-transfer capacity rises roughly <strong>3.5x</strong> (+250 %), and the lower $v_{\text{min}}$ further increases $Q$ as more small-value payments become viable.</p> <p>Together these effects lift $V$, more frequent, smaller, native settlements without changing monetary supply.</p> <p>ETH thus gains moneyness:</p> <ul> <li><strong>Medium of exchange:</strong> direct use becomes routine, not exceptional.</li> <li><strong>Unit of account:</strong> frequent native settlement encourages ETH-denominated pricing.</li> <li><strong>Store of value:</strong> workload-based fees reinforce trust in cost realism.</li> </ul> <p>Price volatility may still lead users to prefer stablecoins for predictability, but this change removes unnecessary friction, restoring ETH’s competitiveness wherever volatility is tolerable.</p> <p>The <code>25,000</code> surcharge for new-account creation continues to price state growth honestly while everyday transfers become cheaper and faster.</p> <h3 id="equivalent-gas-limit-increase">Equivalent gas-limit increase</h3> <p>Lowering <code>TX_BASE_COST</code> from <code>21,000</code> to <code>4,500</code> removes up to <code>16,500</code> gas per transaction. Using recent totals of 163 Ggas/day and 1.7 M tx/day:</p> <table><thead><tr><th>Metric</th><th style="text-align: right">Calculation</th><th style="text-align: right">Result</th><th style="text-align: right">Change</th></tr></thead><tbody> <tr><td>Avg gas per tx</td><td style="text-align: right">163Bn / 1.7M</td><td style="text-align: right">≈ 95,882 gas</td><td style="text-align: right">-</td></tr> <tr><td>New avg gas per tx</td><td style="text-align: right">95,882 − 16,500</td><td style="text-align: right">≈ 79,382 gas</td><td style="text-align: right">-</td></tr> <tr><td>Throughput at fixed gaslimit</td><td style="text-align: right">95,882 / 79,382</td><td style="text-align: right">≈ x1.208</td><td style="text-align: right">+20.08%</td></tr> <tr><td>Daily tx at same gas usage</td><td style="text-align: right">1.7M × 1.208</td><td style="text-align: right">≈ 2.053M tx/day</td><td style="text-align: right">+340k/day</td></tr> </tbody></table> <p>Perfnet measurements show EL clients handle &gt;300 MGas/s for pure ETH transfers. Expressed under a 4.5k base this corresponds to <code>300 * (4.5/21) ~ 64.3 MGas/s</code>, i.e. <code>~771 MGas</code> per 12 s slot. This indicates sufficient headroom and that the current base is significantly overcharged, so no extra engineering is required to improve performance to support this change.</p> <p>Net effect equals raising a 45 M gas limit to ~54.4 M at unchanged calldata and access-list metering. This directly advances Scaling L1.</p> <h2 id="specification">Specification</h2> <p>After <code>FORK_BLOCK</code>, set the following parameters and rules:</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>Name</th><th style="text-align: right">Value</th><th>Description</th></tr></thead><tbody> <tr><td><code>TX_BASE_COST</code></td><td style="text-align: right">4,500</td><td>Base cost of any transaction</td></tr> <tr><td><code>GAS_NEW_ACCOUNT</code></td><td style="text-align: right">25,000</td><td>Surcharge when a value-transferring transaction creates a new account</td></tr> <tr><td><code>STATE_UPDATE</code></td><td style="text-align: right">1,000</td><td>One account-leaf write in the account trie (nonce and balance coalesce)</td></tr> <tr><td><code>COLD_ACCOUNT_COST_CODE</code></td><td style="text-align: right">2,600</td><td>Cold touch of an account with code</td></tr> <tr><td><code>COLD_ACCOUNT_COST_NOCODE</code></td><td style="text-align: right">500</td><td>Cold touch of an account known to have no code</td></tr> <tr><td><code>WARM_STATE_READ</code></td><td style="text-align: right">100</td><td>Touch of an already-warm account (same as <code>WARM_STORAGE_READ_COST</code>)</td></tr> </tbody></table> <p>The intrinsic gas accounting defined here overrides <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a>'s blanket "all tx addresses are warm" rule.</p> <p>A transaction’s intrinsic base is decomposed into explicit primitives, so warmth must be priced explicitly.</p> <ul> <li> <p><code>tx.sender</code> is charged as a cold non-code account (<code>COLD_ACCOUNT_COST_NOCODE = 500</code>), representing the first access and coalesced account-leaf update.</p> </li> <li> <p><code>tx.to</code> is charged based on its type:</p> <ul> <li> <p>if a contract create, charge under those rules.</p> </li> <li> <p>if an EOA or an empty account, use <code>COLD_ACCOUNT_COST_NOCODE = 500</code>.</p> </li> <li> <p>if a contract, use <code>COLD_ACCOUNT_COST_CODE = 2,600</code>.</p> </li> <li> <p>if a precompile, it is warm at tx start and charged zero.</p> </li> </ul> </li> <li> <p>Warmth discovered through an access list still applies and overrides the cold cost.</p> </li> </ul> <p>This decomposition replaces the implicit warmth assumptions of <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> and makes the per-account cost explicit in the base or the execution phase as appropriate.</p> <p>Notes:</p> <ul> <li><code>STATE_UPDATE</code> counts writes at the account-leaf granularity. If a single account's nonce and balance both change in one transition, charge one <code>STATE_UPDATE</code>.</li> <li><code>COLD_ACCOUNT_COST_NOCODE</code> reflects that non-code accounts do not load code or a storage trie, so have a lower warming cost.</li> <li>A regular ETH transfer additionally includes a cold touch of at least <code>COLD_ACCOUNT_COST_NOCODE</code> and a <code>STATE_UPDATE</code> of the <code>to</code> address, so the effective minimal productive tx cost is <code>6,000</code>.</li> <li>Not including the <code>to</code> cold warming and <code>STATE_UPDATE</code> in <code>TX_BASE_COST</code> means a contract-interaction transaction that does not transfer value does not unnecessarily pay these additional costs.</li> </ul> <h3 id="derivation-non-normative">Derivation (non-normative)</h3> <p>Decomposition of the base cost into universal primitives:</p> <table><thead><tr><th>Component</th><th style="text-align: right">Cost</th><th>Notes</th></tr></thead><tbody> <tr><td>ECRECOVER</td><td style="text-align: right">3,000</td><td>Elliptic curve signature recovery</td></tr> <tr><td>STATE_UPDATE</td><td style="text-align: right">1,000</td><td>One account-leaf write (nonce + balance coalesced)</td></tr> <tr><td>COLD_ACCOUNT_COST_NOCODE</td><td style="text-align: right">500</td><td>Sender is cold and has no code</td></tr> <tr><td><strong>TX_BASE_COST</strong></td><td style="text-align: right"><strong>4,500</strong></td><td>Sum of above (3,000 + 1,000 + 500)</td></tr> </tbody></table> <h3 id="new-account-surcharge">New-account surcharge</h3> <p>Apply <code>GAS_NEW_ACCOUNT</code> when <strong>all</strong> are true:</p> <ol> <li>The transaction is not a <code>CREATE</code> transaction.</li> <li><code>value &gt; 0</code>.</li> <li><code>to</code> is not a precompile.</li> <li><code>to</code> is non-existent per <a href="https://wg-eips.ritovision.com/161/">EIP-161</a> emptiness at the start of transaction execution.</li> </ol> <p>The <code>GAS_NEW_ACCOUNT = 25,000</code>charge covers state growth (new leaf creation and one <code>STATE_UPDATE</code>). An additional <code>COLD_ACCOUNT_COST_NOCODE = 500</code> applies for the initial lookup to determine that the account does not exist.</p> <p>Thus, the <strong>total</strong> intrinsic gas for a value-transferring transaction to a new account is <code>30,000</code> (<code>4,500 base + 500 lookup + 25,000 new-account surcharge</code>).</p> <p>For reference, the <strong>total</strong> charges for such transfers change from 21,000 to 30,000.</p> <table><thead><tr><th>Component</th><th style="text-align: right">Cost</th><th>Notes</th></tr></thead><tbody> <tr><td>TX_BASE_COST</td><td style="text-align: right">4,500</td><td>Base transaction cost</td></tr> <tr><td>COLD_ACCOUNT_COST_NOCODE</td><td style="text-align: right">500</td><td>Recipient cold lookup (execution charge)</td></tr> <tr><td>GAS_NEW_ACCOUNT</td><td style="text-align: right">25,000</td><td>Account creation, includes leaf write</td></tr> <tr><td><strong>Total</strong></td><td style="text-align: right"><strong>30,000</strong></td><td>Sum of above (4,500 + 500 + 25,000)</td></tr> </tbody></table> <p>Notes:</p> <ul> <li>If <code>value = 0</code> and <code>to</code> is empty per <a href="https://wg-eips.ritovision.com/161/">EIP-161</a>, no account is created and no surcharge applies.</li> <li><code>CREATE</code> transactions are unchanged; their cost already includes account creation.</li> </ul> <h3 id="intrinsic-gas-computation">Intrinsic gas computation</h3> <p>Clients compute intrinsic gas as today for each typed transaction <strong>except</strong>:</p> <ul> <li>Replace any hardcoded <code>21,000</code> with <code>TX_BASE_COST = 4,500</code>.</li> <li>Add <code>GAS_NEW_ACCOUNT</code> when the <em>New-account surcharge</em> conditions hold.</li> </ul> <h3 id="pseudocode-normative">Pseudocode (normative):</h3> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> CalculateIntrinsicGas</span><span>(</span><span class="z-variable z-parameter z-function">tx</span><span>,</span><span class="z-variable z-parameter z-function"> state_at_start</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> gasCost</span><span class="z-keyword"> =</span><span class="z-constant"> TX_BASE_COST</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Existing rules for calldata and access lists remain unchanged by this EIP.</span></span> <span class="giallo-l"><span> gasCost</span><span class="z-keyword"> +=</span><span> GasForCalldata</span><span>(</span><span>tx</span><span>.</span><span>data</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> per active calldata pricing EIPs</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>has_access_list</span><span>(</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> gasCost</span><span class="z-keyword"> +=</span><span> GasForAccessList</span><span>(</span><span>tx</span><span>.</span><span>access_list</span><span>)</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> per EIP-2930</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> tx</span><span>.</span><span>is_create</span><span>(</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> tx</span><span>.</span><span>value</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> is_precompile</span><span>(</span><span>tx</span><span>.</span><span>to</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span class="z-keyword"> and</span><span> is_nonexistent_per_eip161</span><span>(</span><span>state_at_start</span><span>,</span><span> tx</span><span>.</span><span>to</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> gasCost</span><span class="z-keyword"> +=</span><span class="z-constant"> GAS_NEW_ACCOUNT</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> gasCost</span></span></code></pre><h3 id="evm-gas-schedule-adjustments">EVM gas schedule adjustments</h3> <p>These changes refine execution-layer accounting to align with the primitives above.</p> <ul> <li> <p><strong>Value-moving calls.</strong> Replace the legacy <code>CALL_VALUE_COST = 9,000</code> with:</p> <ul> <li>If recipient exists: <code>CALL_VALUE_COST = 2 * STATE_UPDATE = 2,000</code>.</li> <li>If recipient is EIP-161-empty: <code>CALL_VALUE_COST = STATE_UPDATE + GAS_NEW_ACCOUNT = 26,000</code>.</li> <li>This charge is in addition to warm/cold account-touch costs per EIP-2929 and the existing <code>CALL</code> base cost. This EIP does not modify the <code>CALL</code> base cost. The <code>CALL_VALUE_COST = 2,000</code> applies for all value-carrying calls, regardless of whether the callee's account has already been updated earlier in the same transaction. This ensures the 2300-gas stipend mechanism remains safe and consistent for simple value forwarding and does not retroactively depend on account-update history.</li> </ul> </li> <li> <p><strong>Cold-account touches.</strong></p> <ul> <li>Use <code>COLD_ACCOUNT_COST_CODE = 2,600</code> when touching an account with code.</li> <li>Use <code>COLD_ACCOUNT_COST_NOCODE = 500</code> when touching an account known to have no code.</li> </ul> </li> <li> <p><strong>Warmth policy.</strong></p> <ul> <li>Access-list entries (charged via <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>) and precompiles are warm at tx start.</li> <li><code>CALL</code> warms its <code>to</code> after charging the appropriate cold cost if cold.</li> <li>A <code>PAY</code>-style pure value-move primitive, if present, does not warm its recipient and never loads code. It pays <code>WARM_STATE_READ = 100</code> if warm for unrelated reasons, else <code>COLD_ACCOUNT_COST_NOCODE = 500</code>, plus the value-write cost above.</li> </ul> </li> <li> <p><strong>Self-transfers.</strong> If <code>from == to</code>, only one <code>STATE_UPDATE</code> occurs. The sender's nonce and balance update are coalesced into the same leaf write. No recipient lookup or separate write is charged. (Is a NOP tx other than charging gas and incrementing nonce).</p> </li> </ul> <h3 id="transaction-reference-cases">Transaction reference cases</h3> <table><thead><tr><th>Case</th><th>Formula</th><th style="text-align: right">Total Cost</th></tr></thead><tbody> <tr><td>(NOP) No-transfer to EOA</td><td><code>TX_BASE_COST</code></td><td style="text-align: right">4,500</td></tr> <tr><td>(NOP) No-transfer to empty account</td><td><code>TX_BASE_COST</code></td><td style="text-align: right">4,500</td></tr> <tr><td>(NOP) ETH transfer to self</td><td><code>TX_BASE_COST</code></td><td style="text-align: right">4,500</td></tr> <tr><td>ETH Transfer to existing EOA</td><td><code>TX_BASE_COST</code> + <code>COLD_ACCOUNT_COST_NOCODE</code> + <code>STATE_UPDATE</code></td><td style="text-align: right">6,000</td></tr> <tr><td>No-transfer to contract</td><td><code>TX_BASE_COST</code> + <code>COLD_ACCOUNT_COST_CODE</code> + <strong>execution</strong></td><td style="text-align: right">7,100 + <strong>execution</strong></td></tr> <tr><td>ETH Transfer to contract</td><td><code>TX_BASE_COST</code> + <code>COLD_ACCOUNT_COST_CODE</code> + <code>STATE_UPDATE</code> + <strong>execution</strong></td><td style="text-align: right">8,100 + <strong>execution</strong></td></tr> <tr><td>ETH Transfer creating new account</td><td><code>TX_BASE_COST</code> + <code>COLD_ACCOUNT_COST_NOCODE</code> + <code>GAS_NEW_ACCOUNT</code></td><td style="text-align: right">30,000</td></tr> </tbody></table> <p>This aligns costs with actual state work rather than legacy flat surcharges.</p> <h3 id="edits-and-interactions-with-other-eips">Edits and interactions with other EIPs</h3> <ul> <li><strong><a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a> (Access List).</strong> Intrinsic gas is <code>TX_BASE_COST</code> after <code>FORK_BLOCK</code>. Access lists keep their existing per-entry charges and warming semantics.</li> <li><strong><a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> (Gas cost increases for state access).</strong> Refined by this EIP to price non-code cold touches at <code>500</code> and code-account cold touches at <code>2,600</code>.</li> <li><strong><a href="https://wg-eips.ritovision.com/7702/">EIP-7702</a> (Set EOA Code).</strong> <code>TX_BASE_COST</code> remains <code>4,500</code> even if the sender temporarily assumes code for the transaction. Clients must not perform any disk code-load to determine sender type, since 7702 provides code inline. If the transaction executes code that reads or executes its own code, normal <code>COLD_ACCOUNT_COST_CODE</code> or <code>WARM_STATE_READ</code> costs apply at execution time as per the standard cold/warm model.</li> <li><strong>Calldata-pricing EIPs (e.g. <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a>).</strong> Unchanged. This EIP does not alter calldata pricing.</li> </ul> <h2 id="rationale">Rationale</h2> <p>Price only what every transaction always does: ECDSA recovery, warming <code>sender</code> and <code>to</code>, and one account-leaf write for the sender (nonce + balance change). That sums to <code>4,500</code> gas. Anything not universal should be metered separately.</p> <p>Calldata remains metered per byte. No calldata allowance is folded into the base. This reinforces ETH as money and payments: a plain ETH transfer carries no calldata, executes no bytecode, and touches no contract storage slots. It adds exactly one recipient touch (when not a smart contract) and one recipient leaf write, so its total is <code>6,000</code>.</p> <p><code>CREATE</code> is unchanged because its cost already includes account creation. Access-list pricing is unchanged.</p> <p>Legacy pricing undercharged top-level ETH transfers that created new accounts relative to internal <code>CALL</code>-based creations. This EIP corrects that by charging <code>GAS_NEW_ACCOUNT = 25,000</code>, identical to the <code>CALL</code> account-creation surcharge, ensuring consistent pricing for state growth regardless of entry path.</p> <p>This removes cross-subsidies, aligns charges with resources, and keeps costs equal across paths that perform the same state growth.</p> <p>Do not fold any calldata allowance into the base. The envelope RLP (<code>nonce</code>, <code>gas*</code>, <code>to</code>, <code>value</code>, <code>v</code>, <code>r</code>, <code>s</code>) is not charged as calldata and remains unmetered per byte. Only <code>tx.data</code> bytes are metered at the existing calldata schedule, and access lists keep their per-entry costs. A vanilla ETH transfer executes no bytecode and touches no contract storage slots; it performs signature recovery, warms the sender, and updates sender and recipient accounts. It therefore receives the base discount and pays only the additional recipient costs.</p> <p>Bundling multiple transfers into a single contract call avoids repeated <code>TX_BASE_COST</code>, but those transfers then execute serially inside one EVM context. That blocks parallel execution. With a lower per-tx base cost, users have less incentive to bundle, so more transfers remain independent transactions. Independent transactions can be scheduled across threads, which improves parallelism at the client and execution-layer level.</p> <p>Thus, reducing <code>TX_BASE_COST</code> not only corrects mispricing but also increases the share of transactions that are naturally parallelizable.</p> <p>This EIP composes cleanly with calldata-pricing proposals such as <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> and <a href="https://wg-eips.ritovision.com/7976/">EIP-7976</a>. Those EIPs affect <code>tx.data</code> metering, while this EIP adjusts only transaction-level intrinsic accounting. There is no overlapping scope.</p> <h3 id="why-not-charge-full-tx-data-as-calldata">Why not charge full tx data as calldata?</h3> <ul> <li> <p><strong>Intrinsic coupling to signed fields.</strong> Pricing full-transaction bytes would make intrinsic gas depend on <code>gas_limit</code> and variable-length signature elements, creating fixed-point estimation issues and incentives for signature-length selection as well as iteration unstablity as <code>gas_limit</code> depends on signiture which contains <code>gas_limit</code>.</p> </li> <li> <p><strong>Serialization neutrality.</strong> A fee rule keyed to RLP size couples costs to one encoding and weakens <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> type neutrality and future formats such as SSZ. Calldata is treated as opaque bytes so it avoids this coupling.</p> </li> <li> <p><strong>Policy targeting and market floor.</strong> Calldata floors (for example <a href="https://wg-eips.ritovision.com/7623/">EIP-7623</a> or <a href="https://wg-eips.ritovision.com/7976/">EIP-7976</a>) price bytes in <code>tx.data</code> to bound EL payload and steer data to blobs; envelope bytes are control-plane. The <code>TX_BASE_COST</code> is the smallest tx size, and having a low encoding-agnostic intrinsic base keeps the minimum inclusion price coupled to the basefee market, without opening a DoS vector.</p> </li> <li> <p><strong>Native settlement and unit-of-account.</strong> Even though all transactions receive the same absolute gas reduction, it proportionally improves pristine ETH transfers more. With an ETH transfer at ~6,000 gas vs a permissioned ERC-20/LST/stablecoin transfer at ~48,000 gas, you get ~8x higher payment throughput per unit gas, which reinforces ETH as the settlement asset and reduces reliance on contract-based money (which carries smart contract risk, operator risk, governance risk and censorship risks via smart contract operator).</p> </li> </ul> <p><img src="https://wg-eips.ritovision.com/2780/./assets/1.png" alt="Figure 1" /></p> <h3 id="effects-on-transactions-per-block">Effects on transactions per block</h3> <p>For execution-payload size, use <a href="https://wg-eips.ritovision.com/7934/">EIP-7934</a>’s 8 MiB uncompressed cap: <code>8,388,608 bytes</code>. A typical EIP-1559 ETH transfer encodes at roughly <code>~110 bytes</code>, yielding a size cap of <code>floor(8,388,608 / 110) = 76,260 tx</code> per block when size, not gas, is the binding constraint.</p> <p>There are two useful ceilings to consider:</p> <ul> <li>Minimal transaction with no value and no execution: <code>TX_BASE_COST = 4,500</code> gas.</li> <li>Minimal ETH payment to an existing EOA: <code>6,000</code> gas (<code>TX_BASE_COST + COLD_ACCOUNT_COST_NOCODE + STATE_UPDATE</code>).</li> </ul> <p>Counts below are <code>floor(gaslimit / per-tx-gas)</code>, then capped by <code>76,260</code> when the 8 MiB size limit binds. TPS figures round to the nearest integer.</p> <h4 id="scenario-a-minimal-txs-at-4-500-gas">Scenario A: minimal txs at 4,500 gas</h4> <p>Binding point for size-cap dominance: <code>76,260 * 4,500 = 343,170,000</code> gas. At gaslimits above ~343.17 M, block size, not gas, limits the tx count for 4,500-gas transactions.</p> <table><thead><tr><th style="text-align: right">Block gaslimit</th><th style="text-align: right">Old tx/bk (21k)</th><th style="text-align: right">New tx/bk (4.5k)</th><th style="text-align: right">TPS @ 12s</th><th style="text-align: right">TPS @ 6s</th><th style="text-align: right">TPS @ 3s</th><th style="text-align: right">TPS @ 1.5s</th></tr></thead><tbody> <tr><td style="text-align: right">45 M</td><td style="text-align: right">2,142</td><td style="text-align: right">10,000</td><td style="text-align: right">833</td><td style="text-align: right">1,667</td><td style="text-align: right">3,333</td><td style="text-align: right">6,667</td></tr> <tr><td style="text-align: right">60 M</td><td style="text-align: right">2,857</td><td style="text-align: right">13,333</td><td style="text-align: right">1,111</td><td style="text-align: right">2,222</td><td style="text-align: right">4,444</td><td style="text-align: right">8,889</td></tr> <tr><td style="text-align: right">100 M</td><td style="text-align: right">4,761</td><td style="text-align: right">22,222</td><td style="text-align: right">1,852</td><td style="text-align: right">3,704</td><td style="text-align: right">7,407</td><td style="text-align: right">14,815</td></tr> <tr><td style="text-align: right">200 M</td><td style="text-align: right">9,523</td><td style="text-align: right">44,444</td><td style="text-align: right">3,704</td><td style="text-align: right">7,407</td><td style="text-align: right">14,815</td><td style="text-align: right">29,629</td></tr> <tr><td style="text-align: right">450 M</td><td style="text-align: right">21,428</td><td style="text-align: right">†76,260</td><td style="text-align: right">6,355</td><td style="text-align: right">12,710</td><td style="text-align: right">25,420</td><td style="text-align: right">50,840</td></tr> </tbody></table> <p>† Size cap binds at 450 M because 450 M &gt; 343.17 M.</p> <h4 id="scenario-b-eth-transfers-at-6-000-gas">Scenario B: ETH transfers at 6,000 gas</h4> <p>Binding point for size-cap dominance: <code>76,260 * 6,000 = 457,560,000</code> gas. At gaslimits below ~457.56 M, gas limits tx count; above it, the 8 MiB size cap dominates.</p> <table><thead><tr><th style="text-align: right">Block gaslimit</th><th style="text-align: right">Old tx/bk (21k)</th><th style="text-align: right">New tx/bk (6k)</th><th style="text-align: right">TPS @ 12s</th><th style="text-align: right">TPS @ 6s</th><th style="text-align: right">TPS @ 3s</th><th style="text-align: right">TPS @ 1.5s</th></tr></thead><tbody> <tr><td style="text-align: right">45 M</td><td style="text-align: right">2,142</td><td style="text-align: right">7,500</td><td style="text-align: right">625</td><td style="text-align: right">1,250</td><td style="text-align: right">2,500</td><td style="text-align: right">5,000</td></tr> <tr><td style="text-align: right">60 M</td><td style="text-align: right">2,857</td><td style="text-align: right">10,000</td><td style="text-align: right">833</td><td style="text-align: right">1,667</td><td style="text-align: right">3,333</td><td style="text-align: right">6,667</td></tr> <tr><td style="text-align: right">100 M</td><td style="text-align: right">4,761</td><td style="text-align: right">16,666</td><td style="text-align: right">1,389</td><td style="text-align: right">2,778</td><td style="text-align: right">5,555</td><td style="text-align: right">11,111</td></tr> <tr><td style="text-align: right">200 M</td><td style="text-align: right">9,523</td><td style="text-align: right">33,333</td><td style="text-align: right">2,778</td><td style="text-align: right">5,556</td><td style="text-align: right">11,111</td><td style="text-align: right">22,222</td></tr> <tr><td style="text-align: right">450 M</td><td style="text-align: right">21,428</td><td style="text-align: right">75,000</td><td style="text-align: right">6,250</td><td style="text-align: right">12,500</td><td style="text-align: right">25,000</td><td style="text-align: right">50,000</td></tr> </tbody></table> <h4 id="changes-for-common-types-of-txs">Changes for common types of txs</h4> <table><thead><tr><th>Transaction Type</th><th style="text-align: right">Old Cost</th><th style="text-align: right">New Cost</th><th style="text-align: right">Change</th></tr></thead><tbody> <tr><td>Simple ETH transfer (existing EOA)</td><td style="text-align: right">21,000</td><td style="text-align: right">6,000</td><td style="text-align: right">−71 %</td></tr> <tr><td>ETH transfer creating new EOA</td><td style="text-align: right">21,000</td><td style="text-align: right">30,000</td><td style="text-align: right">+43 %</td></tr> <tr><td>ERC-20 transfer (typical)</td><td style="text-align: right">63,200</td><td style="text-align: right">48,200</td><td style="text-align: right">−24 %</td></tr> <tr><td>ERC-20 transfer (Solady)</td><td style="text-align: right">33,400</td><td style="text-align: right">18,400</td><td style="text-align: right">−45 %</td></tr> <tr><td>Uniswap v3 swap</td><td style="text-align: right">184,500</td><td style="text-align: right">169,500</td><td style="text-align: right">−8 %</td></tr> <tr><td>Uniswap v3 add-liquidity</td><td style="text-align: right">216,900</td><td style="text-align: right">201,900</td><td style="text-align: right">−7 %</td></tr> </tbody></table> <h4 id="reference-mgas-s-for-gaslimit-vs-slot-time">Reference MGas/s for gaslimit vs slot time</h4> <table><thead><tr><th style="text-align: right">Block gaslimit</th><th style="text-align: right">MGas/s @ 12s</th><th style="text-align: right">MGas/s @ 6s</th><th style="text-align: right">MGas/s @ 3s</th><th style="text-align: right">MGas/s @ 1.5s</th></tr></thead><tbody> <tr><td style="text-align: right">45 M</td><td style="text-align: right">3.75</td><td style="text-align: right">7.50</td><td style="text-align: right">15.00</td><td style="text-align: right">30.00</td></tr> <tr><td style="text-align: right">60 M</td><td style="text-align: right">5.00</td><td style="text-align: right">10.00</td><td style="text-align: right">20.00</td><td style="text-align: right">40.00</td></tr> <tr><td style="text-align: right">100 M</td><td style="text-align: right">8.33</td><td style="text-align: right">16.67</td><td style="text-align: right">33.33</td><td style="text-align: right">66.67</td></tr> <tr><td style="text-align: right">200 M</td><td style="text-align: right">16.67</td><td style="text-align: right">33.33</td><td style="text-align: right">66.67</td><td style="text-align: right">133.33</td></tr> <tr><td style="text-align: right">450 M</td><td style="text-align: right">37.50</td><td style="text-align: right">75.00</td><td style="text-align: right">150.00</td><td style="text-align: right">300.00</td></tr> </tbody></table> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is <strong>not</strong> backward compatible. It is a consensus gas repricing that must be activated at <code>FORK_BLOCK</code>.</p> <p>Wallets, RPCs, gas estimators, and any logic that assumes a <code>21,000</code> base must update.</p> <h2 id="test-cases">Test Cases</h2> <p>While the benefits of reducing transactions' intrinsic cost are apparent, such a change should be applied if it imposes no negative externalities, or if such effects are negligible.</p> <p>Tests should be created with blocks of just ETH transfers and tested on Perfnet across all EL clients to ensure the pricing is correct.</p> <p>Add explicit test vectors (intrinsic gas only):</p> <ol> <li><code>value &gt; 0</code> to an empty EOA (non-existent per EIP-161): intrinsic <code>30,000</code> (4,500 base + 500 + 25,000 surcharge).</li> <li><code>value &gt; 0</code> to a precompile: intrinsic <code>4,500</code> (no surcharge; precompiles are warm at tx start).</li> <li><code>value = 0</code> to an empty address: intrinsic <code>4,500</code> (no creation, no surcharge).</li> <li><code>CREATE</code> transaction: unchanged from prior rules.</li> <li>EIP-7702 transaction with and without access list: intrinsic uses <code>TX_BASE_COST</code> plus unchanged access-list costs.</li> <li>Block of txs calling minimal gas contract execution with maximal contract size addresses (so VM is activated for every tx).</li> <li>Warmth and access list interplay <ul> <li>ETH transfer to existing EOA without access list: charge <code>COLD_ACCOUNT_COST_NOCODE = 500</code> for recipient lookup.</li> <li>Same transaction with recipient in access list: charge <code>WARM_STATE_READ = 100</code>.</li> </ul> </li> <li>7702 interactions <ul> <li>7702 tx where sender assumes code and calls nothing: intrinsic = 4,500, no extra cold-code cost.</li> <li>7702 tx where sender assumes code and executes self-code: charge <code>COLD_ACCOUNT_COST_CODE</code> when first loaded.</li> </ul> </li> <li>Precompile transfers <ul> <li><code>value &gt; 0</code> to <code>0x01</code>–<code>0x09</code>: intrinsic = 4,500, no surcharge.</li> </ul> </li> <li>Self-transfer <code>from == to</code>: total = 4,500.</li> <li>Internal CALL repricing <ul> <li>Internal <code>CALL</code> to existing EOA with value: <code>CALL_VALUE_COST = 2,000</code> plus cold/warm costs.</li> <li>Internal <code>CALL</code> to EIP-161-empty: <code>CALL_VALUE_COST = 26,000</code>.</li> </ul> </li> <li>Zero-value edge cases <code>value = 0</code> to empty address: intrinsic = <code>4,500</code>.</li> <li>Perfnet stress <ul> <li>Fill block with minimal 4,500-gas tx and 6,000-gas ETH transfers; confirm gas vs byte-size binding per <a href="https://wg-eips.ritovision.com/7934/">EIP-7934</a>.</li> </ul> </li> <li>SELFDESTRUCT test: Create-and-destroy in one tx; confirm normal value-transfer costs apply, no deletion repricing.</li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>As this significantly increases the max tx per block this carries risk.</p> <p>However this pricing should be the same as performing the component changes inside the transaction; and it factors in the additional costs from state growth which were not originally in the transaction base price.</p> <p>Current gaslimit testing mostly uses a block with a single transaction; so this should not cause unexpected load compared to what is already being tested.</p> <p>The semantics of <code>SELFDESTRUCT</code> remain unchanged. Following <a href="https://wg-eips.ritovision.com/6780/">EIP-6780</a>, only contracts created within the same transaction may be fully deleted. This EIP does not reprice or modify any <code>SELFDESTRUCT</code> side-effects.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-06-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Matt Garnetthttps://github.com/lightclient https://wg-eips.ritovision.com/2733/ <h2 id="simple-summary">Simple Summary</h2> <p>Creates a new transaction type which executes a package of one or more transactions, while passing status information to subsequent transactions.</p> <h2 id="abstract">Abstract</h2> <p>Introduce a new transaction type which includes a list of transactions that must be executed serially by clients. Execution information (e.g. success, gas_used, etc.) will be propagated forward to the next transaction.</p> <h2 id="motivation">Motivation</h2> <p>Onboarding new users to Ethereum has been notoriously difficult due to the need for new users to acquire enough ether to pay for their transactions. This hurdle has seen a significant allocation of resources over the years to solve. Today, that solution is meta-transactions. This is, unfortunately, a brittle solution that requires signatures to be recovered within a smart contract to authenticate the message. This EIP aims to provide a flexible framework for relayers to "sponsor" many transactions at once, trustlessly.</p> <p>Meta-transactions often use relay contracts to maintain nonces and allow users to pay for gas using alternative assets. They have historically been designed to catch reversions in their inner transactions by only passing a portion of the available gas to the subcall. This allows them to be certain the outer call will have enough gas to complete any required account, like processing a gas payment. This type of subcall has been considered bad practice for a long time, but in the case of where you don't trust the subcalls, it is the only available solution.</p> <p>Transaction packages are an alternative that allow multiple transactions to be bundled into one package and executed atomically, similarly to how relay contracts operate. Transactions are able to pass their result to subsequent transactions. This allows for conditional workflows based on the outcome of previous transactions. Although this functionality is already possible as described above, workflows using transaction packages are more robust, because they are protected from future changes to the gas schedule.</p> <p>An important byproduct of this EIP is that it also facilitates bundling transactions for single users.</p> <h2 id="specification">Specification</h2> <p>Introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type where <code>id = 2</code>.</p> <h4 id="structure">Structure</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>struct TransactionPackage {</span></span> <span class="giallo-l"><span> chain_id: u256,</span></span> <span class="giallo-l"><span> children: [ChildPackage],</span></span> <span class="giallo-l"><span> nonce: u64,</span></span> <span class="giallo-l"><span> gas_price: u256,</span></span> <span class="giallo-l"><span> v: u256,</span></span> <span class="giallo-l"><span> r: u256,</span></span> <span class="giallo-l"><span> s: u256</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h5 id="hash">Hash</h5> <p><code>keccak256(rlp([2, chain_id, children, nonce, gas_price, v, r, s])</code></p> <h5 id="signature-hash">Signature Hash</h5> <p><code>keccak256(rlp([2, chain_id, children, nonce, gas_price])</code></p> <h5 id="receipt">Receipt</h5> <p>Each <code>ChildTransaction</code> transaction will generate a <code>ChildReceipt</code> after execution. Each of these receipts will be aggregated into a <code>Receipt</code>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>type Receipt = [ChildReceipt]</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>struct ChildReceipt {</span></span> <span class="giallo-l"><span> status: u256,</span></span> <span class="giallo-l"><span> cumulative_gas_used: u256,</span></span> <span class="giallo-l"><span> logs_bloom: [u8; 256],</span></span> <span class="giallo-l"><span> logs: [u8]</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h4 id="child-transaction">Child Transaction</h4> <p>Let <code>ChildPackage</code> be interpreted as follows.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>struct ChildPackage {</span></span> <span class="giallo-l"><span> type: u8,</span></span> <span class="giallo-l"><span> nonce: u64,</span></span> <span class="giallo-l"><span> transactions: [ChildTransaction],</span></span> <span class="giallo-l"><span> max_gas_price: u256,</span></span> <span class="giallo-l"><span> v: u256,</span></span> <span class="giallo-l"><span> r: u256,</span></span> <span class="giallo-l"><span> s: u256</span></span> <span class="giallo-l"><span>}</span></span></code></pre><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>struct ChildTransaction {</span></span> <span class="giallo-l"><span> flags: u8,</span></span> <span class="giallo-l"><span> to: Address,</span></span> <span class="giallo-l"><span> value: u256,</span></span> <span class="giallo-l"><span> data: [u8],</span></span> <span class="giallo-l"><span> extra: [u8],</span></span> <span class="giallo-l"><span> gas_limit: u256</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h5 id="types">Types</h5> <p>The <code>type</code> field is used to denote whether the <code>Child</code> signer wishes to delegate the <code>max_gas_price</code> and <code>gas_limit</code> choice to the <code>TransactionPackage</code> signer.</p> <table><thead><tr><th>type</th><th>signature hash</th></tr></thead><tbody> <tr><td><code>0x00</code></td><td><code>keccak256(rlp([0, nonce, transactions, max_gas_price])</code></td></tr> <tr><td><code>0x01</code></td><td><code>keccak256(rlp([1, nonce, transactions_without_gas_limit])</code></td></tr> </tbody></table> <h3 id="validity">Validity</h3> <p>A <code>TransactionPackage</code> can be deemed valid or invalid as follows.</p> <pre class="giallo z-code"><code data-lang="rust"><span class="giallo-l"><span class="z-keyword">fn</span><span class="z-entity z-name"> is_valid</span><span>(</span><span class="z-variable z-other">config</span><span class="z-keyword">:</span><span class="z-keyword"> &amp;</span><span class="z-entity z-name">Config</span><span>,</span><span class="z-variable z-other"> state</span><span class="z-keyword">:</span><span class="z-keyword"> &amp;</span><span class="z-entity z-name">State</span><span>,</span><span class="z-variable z-other"> tx</span><span class="z-keyword">:</span><span class="z-entity z-name"> TransactionPackage</span><span>)</span><span class="z-entity z-name"> bool</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span class="z-variable z-other"> config</span><span class="z-keyword">.</span><span class="z-entity z-name">chain_id</span><span>(</span><span>)</span><span class="z-keyword"> !=</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>chain_id </span><span class="z-keyword">|</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>children</span><span class="z-keyword">.</span><span class="z-entity z-name">len</span><span>(</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span class="z-keyword"> |</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span class="z-keyword">.</span><span class="z-entity z-name">nonce</span><span>(</span><span class="z-variable z-other">tx</span><span class="z-keyword">.</span><span class="z-entity z-name">from</span><span>(</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span class="z-keyword"> !=</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>nonce</span></span> <span class="giallo-l"><span> )</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> false</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> let</span><span class="z-variable z-other"> cum_limit</span><span class="z-keyword"> =</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>children</span><span class="z-keyword">.</span><span class="z-entity z-name">map</span><span>(</span><span class="z-keyword">|</span><span class="z-variable z-other">x</span><span class="z-keyword">|</span><span class="z-variable z-other"> x</span><span class="z-keyword">.</span><span>gas_limit</span><span>)</span><span class="z-keyword">.</span><span class="z-entity z-name">sum</span><span>(</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-variable z-other"> state</span><span class="z-keyword">.</span><span class="z-entity z-name">balance</span><span>(</span><span class="z-variable z-other">tx</span><span class="z-keyword">.</span><span class="z-entity z-name">from</span><span>(</span><span>)</span><span>)</span><span> &lt;</span><span class="z-variable z-other"> cum_limit</span><span class="z-keyword"> *</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>gas_price </span><span class="z-keyword">+</span><span class="z-entity z-name"> intrinsic_gas</span><span>(</span><span class="z-variable z-other">tx</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> false</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span class="z-variable z-other"> child</span><span class="z-keyword"> in</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>children </span><span>{</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span class="z-variable z-other"> child</span><span class="z-keyword">.</span><span>nonce </span><span class="z-keyword">!=</span><span class="z-variable z-other"> state</span><span class="z-keyword">.</span><span class="z-entity z-name">nonce</span><span>(</span><span class="z-variable z-other">child</span><span class="z-keyword">.</span><span class="z-entity z-name">from</span><span>(</span><span>)</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span class="z-keyword"> |</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> child</span><span class="z-keyword">.</span><span>value</span><span class="z-keyword"> &gt;</span><span class="z-variable z-other"> state</span><span class="z-keyword">.</span><span class="z-entity z-name">balance</span><span>(</span><span class="z-variable z-other">child</span><span class="z-keyword">.</span><span class="z-entity z-name">from</span><span>(</span><span>)</span><span>)</span><span class="z-keyword"> |</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> child</span><span class="z-keyword">.</span><span>max_gas_price</span><span class="z-keyword"> &lt;</span><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>gas_price</span></span> <span class="giallo-l"><span> )</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> false</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span class="z-variable z-other"> tx</span><span class="z-keyword"> in</span><span class="z-variable z-other"> child</span><span class="z-keyword">.</span><span>txs </span><span>{</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>flags </span><span class="z-keyword">!=</span><span class="z-constant"> 0</span><span class="z-keyword"> |</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>extra</span><span class="z-keyword">.</span><span class="z-entity z-name">len</span><span>(</span><span>)</span><span class="z-keyword"> !=</span><span class="z-constant"> 0</span><span class="z-keyword"> |</span><span class="z-keyword">|</span></span> <span class="giallo-l"><span class="z-variable z-other"> tx</span><span class="z-keyword">.</span><span>gas_limit</span><span class="z-keyword"> &lt;</span><span class="z-entity z-name"> intrinsic_gas</span><span>(</span><span class="z-variable z-other">tx</span><span>)</span></span> <span class="giallo-l"><span> )</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> false</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span class="z-constant"> true</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="results">Results</h3> <p>Subsequent <code>ChildTransaction</code>s will be able to receive the result of the previous <code>ChildTransaction</code> via <code>RETURNDATACOPY (0x3E)</code> in first frame of execution, before making any subcalls. Each element, except the last, will be <code>0</code>-padded left to 32 bytes.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>struct Result {</span></span> <span class="giallo-l"><span> // Status of the previous transaction</span></span> <span class="giallo-l"><span> success: bool,</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // Total gas used by the previous transaction</span></span> <span class="giallo-l"><span> gas_used: u256,</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // Cumulative gas used by previous transactions</span></span> <span class="giallo-l"><span> cum_gas_used: u256,</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // The size of the return value</span></span> <span class="giallo-l"><span> return_size: u256,</span></span> <span class="giallo-l"><span> </span></span> <span class="giallo-l"><span> // The return value of the previous transaction</span></span> <span class="giallo-l"><span> return_value: [u8]</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="intrinsic-cost">Intrinsic Cost</h3> <p>Let the intrinsic cost of the transaction package be defined as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fn intrinsic_gas(tx: TransactionPackage) u256 {</span></span> <span class="giallo-l"><span> let data_gas = tx.children.map(|c| c.txs.map(|t| data_cost(&amp;c.data)).sum()).sum();</span></span> <span class="giallo-l"><span> 17000 + 8000 * tx.children.len() + data_gas</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="execution">Execution</h3> <p>Transaction packages should be executed as follows:</p> <ol> <li>Deduct the cumulative cost from the outer signer's balance.</li> <li>Load the first child package, and execute the first child transaction.</li> <li>Record all state changes, logs, the receipt, and refund any unused gas.</li> <li>If there are no more child transactions, goto <code>8</code>.</li> <li>Compute <code>Result</code> for the previously executed transaction.</li> <li>Prepare <code>Result</code> to be available via return opcodes in the next transaction's first frame.</li> <li>Execute the next transaction, then goto <code>3</code>.</li> <li>Load the next child package, then goto <code>7</code>.</li> </ol> <h2 id="rationale">Rationale</h2> <h3 id="each-child-has-its-own-signature">Each <code>Child</code> has its own signature</h3> <p>For simplicity, the author has chosen to require each child package to specify its own signature, even if the signer is the same as the package signer. This choice is made to allow for maximum flexibility, with minimal client changes. This transaction can still be used by a single user at the cost of only one additional signature recovery.</p> <h3 id="childpackage-specifies-max-gas-price-instead-of-gas-price"><code>ChildPackage</code> specifies <code>max_gas_price</code> instead of <code>gas_price</code></h3> <p>Allowing child packages to specify a range of acceptable gas prices is strictly more versatile than a static price. It gives relayers more flexibility in terms of building transaction bundles, and it makes it possible for relayers to try and achieve the best price for the transaction sender. With a fixed price, the relayer may require the user to sign multiple different transactions, with varying prices. This can be avoided by specifying a max price, and communicating out-of-band how the urgency of the transaction (e.g. the relayer should package it with the max price immediately vs. slowly increasing the gas price). A future transaction type can be specified with only a single signature, if such an optimization is desired.</p> <h3 id="childpackage-is-also-typed"><code>ChildPackage</code> is also typed</h3> <p>The type element serves a modest role in the transaction type, denoting whether the transaction signer wishes to delegate control of the gas price and gas limit to the outer signer. This is a useful UX improvement when interacting with a trusted relayer, as once the user decides to make a transaction the relayer can ensure it is included on chain by choosing the best gas price and limit.</p> <h3 id="the-flags-and-extra-fields-aren-t-used">The <code>flags</code> and <code>extra</code> fields aren't used</h3> <p>These fields are included to better support future changes to the transaction type. This would likely be used in conjunction with the <code>flags</code> and <code>type</code> fields. A benefit of explicitly defining them is that specialized serialization of RLP can be avoided, simplifying clients and downstream infrastructure. The author believe the cost of 2 bytes per transaction is acceptable for smoother integration of future features.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Contracts which rely on <code>ORIGIN (0x32) == CALLER (0x33) &amp;&amp; RETURNDATASIZE (0x3D) == 0x00</code> will now always fail in transaction packages, unless they are the first executed transaction. It’s unknown if any contracts conduct this check.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="managing-packages-efficiently-in-the-mempool">Managing packages efficiently in the mempool</h3> <p>The introduction of a new transaction type brings along new concerns regarding the mempool. Done naively, it could turn into a DDoS vector for clients. This EIP has been written to reduce as much validation complexity as possible.</p> <p>An existing invariant in the mempool that is desirable for new transactions to maintain, is that transactions can be validated in constant time. This is also possible for packaged transactions. There is an inherent 10Mb limit for RLPx frames, so that would be the upper bound on transactions that could be included in a package. On the other hand, clients can also just configure their own bound locally (e.g. packages must be less than 1Mb). Validity can then be determined by using the function above.</p> <p>Once a package has been validated, it must continuously be monitored for nonce invalidations within its package. One potential way to achieve this efficiently is to modify the mempool to operate on thin pointers to the underlying transaction. This will allow packages to ingest as many "single" transactions, simplifying the facilities for monitoring changes. These "parts" of the package can maintain a pointer to a structure with pointers to all the parts of the package. This way, as soon as one part becomes invalid, it can request the parent to invalidate all outstanding parts of the package.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-06-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/2718/

Defines a new transaction type that is an envelope for future transaction types.

<h2 id="abstract">Abstract</h2> <p><code>TransactionType || TransactionPayload</code> is a valid transaction and <code>TransactionType || ReceiptPayload</code> is a valid transaction receipt where <code>TransactionType</code> identifies the format of the transaction and <code>*Payload</code> is the transaction/receipt contents, which are defined in future EIPs.</p> <h2 id="motivation">Motivation</h2> <p>In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types. This was seen in <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> where the new value was bit-packed into one of the encoded fields. There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides <code>msg.sender</code> to pay for gas, and proposals related to layer 1 multi-sig transactions. These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.</p> <p>By introducing an envelope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between <code>TransactionType</code>s.</p> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <ul> <li><code>||</code> is the byte/byte-array concatenation operator.</li> </ul> <h3 id="transactions">Transactions</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, the transaction root in the block header <strong>MUST</strong> be the root hash of <code>patriciaTrie(rlp(Index) =&gt; Transaction)</code> where:</p> <ul> <li><code>Index</code> is the index in the block of this transaction</li> <li><code>Transaction</code> is either <code>TransactionType || TransactionPayload</code> or <code>LegacyTransaction</code></li> <li><code>TransactionType</code> is a positive unsigned 8-bit number between <code>0</code> and <code>0x7f</code> that represents the type of the transaction</li> <li><code>TransactionPayload</code> is an opaque byte array whose interpretation is dependent on the <code>TransactionType</code> and defined in future EIPs</li> <li><code>LegacyTransaction</code> is <code>rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])</code></li> </ul> <p>All signatures for future transaction types <strong>SHOULD</strong> include the <code>TransactionType</code> as the first byte of the signed data. This makes it so we do not have to worry about signatures for one transaction type being used as signatures for a different transaction type.</p> <h3 id="receipts">Receipts</h3> <p>As of <code>FORK_BLOCK_NUMBER</code>, the receipt root in the block header <strong>MUST</strong> be the root hash of <code>patriciaTrie(rlp(Index) =&gt; Receipt)</code> where:</p> <ul> <li><code>Index</code> is the index in the block of the transaction this receipt is for</li> <li><code>Receipt</code> is either <code>TransactionType || ReceiptPayload</code> or <code>LegacyReceipt</code></li> <li><code>TransactionType</code> is a positive unsigned 8-bit number between <code>0</code> and <code>0x7f</code> that represents the type of the transaction</li> <li><code>ReceiptPayload</code> is an opaque byte array whose interpretation is dependent on the <code>TransactionType</code> and defined in future EIPs</li> <li><code>LegacyReceipt</code> is <code>rlp([status, cumulativeGasUsed, logsBloom, logs])</code></li> </ul> <p>The <code>TransactionType</code> of the receipt <strong>MUST</strong> match the <code>TransactionType</code> of the transaction with a matching <code>Index</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="transactiontype-only-goes-up-to-0x7f">TransactionType only goes up to 0x7f</h3> <p>For the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit. This also prevents us from colliding with legacy transaction types, which always start with a byte <code>&gt;= 0xc0</code>.</p> <h3 id="should-instead-of-must-for-the-transactiontype-being-first-byte-of-signed-data"><strong>SHOULD</strong> instead of <strong>MUST</strong> for the TransactionType being first byte of signed data</h3> <p>While it is strongly recommended that all future transactions sign the first byte to ensure that there is no problem with signature reuse, the authors acknowledge that this may not always make sense or be possible. One example where this isn't possible is wrapped legacy transactions that are signature compatible with the legacy signing scheme. Another potential situation is one where transactions don't have a signature in the traditional sense and instead have some other mechanism for determining validity.</p> <h3 id="transactiontype-selection-algorithm">TransactionType selection algorithm</h3> <p>There was discussion about defining the <code>TransactionType</code> identifier assignment/selection algorithm in this standard. While it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope. A future EIP may introduce a standard for TransactionType identifier assignment if it is deemed necessary.</p> <h3 id="opaque-byte-array-rather-than-an-rlp-array">Opaque byte array rather than an RLP array</h3> <p>By having the second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the transaction payload in the future such as SSZ, LEB128, or a fixed width format.</p> <h3 id="origin-and-caller">ORIGIN and CALLER</h3> <p>There was discussion about having ORIGIN and CALLER opcodes become dependent on the transaction type, so that each transaction type could define what those opcodes returned. However, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different types of transactions differently. There also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes. Going forward, we will assume that all transaction types will have an address that reasonably represents a <code>CALLER</code> of the first EVM frame and <code>ORIGIN</code> will be the same address in all cases. If a transaction type needs to supply additional information to contracts, they will need a new opcode.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Clients can differentiate between the legacy transactions and typed transactions by looking at the first byte. If it starts with a value in the range <code>[0, 0x7f]</code> then it is a new transaction type, if it starts with a value in the range <code>[0xc0, 0xfe]</code> then it is a legacy transaction type. <code>0xff</code> is not realistic for an RLP encoded transaction, so it is reserved for future use as an extension sentinel value.</p> <h2 id="security-considerations">Security Considerations</h2> <p>When designing a new 2718 transaction type, it is <strong>STRONGLY</strong> recommended to include the transaction type as the first byte of the signed payload. If you fail to do this, it is possible that your transaction may be signature compatible with transactions of another type which can introduce security vulnerabilities for users.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-06-11T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/2711/ <h2 id="simple-summary">Simple Summary</h2> <p>Creates a new transaction type that supports sponsored transactions (separate gas payer from sender), batch transactions (multiple transactions executed in sequence), and expiring transactions (transactions which are not valid after a certain timestamp).</p> <h2 id="abstract">Abstract</h2> <p>An EIP-2718 transaction with the type number <code>2</code> is a new type of transaction that includes support for:</p> <ol> <li><strong>Sponsored Transactions</strong>: an optional additional signature from which the account that will pay for gas (<code>GAS_PAYER</code>) can be recovered</li> <li><strong>Batch Transactions</strong>: multiple transactions from the same sender that will be executed in sequence</li> <li><strong>Expiring Transactions</strong>: an optional <code>validUntil</code> field that makes the transaction invalid after a certain point in time</li> </ol> <h2 id="motivation">Motivation</h2> <h3 id="sponsored-transactions">Sponsored Transactions</h3> <p>With the advent of tokens and especially stable coins, it has become common for users to not hold ETH in an account while they may have other assets of value in that account. Some users don't want to be exposed to the perceived volatility of ETH and instead would prefer to transact using other assets. Unfortunately, since gas <strong>MUST</strong> be paid for with ETH, this prevents the user from transacting with their assets without first acquiring some ETH using some other means, and then using that ETH to pay fees.</p> <p>This EIP proposes a mechanism by which we can allow people to transact without ever having to own any ETH by allowing someone else to cover gas costs. The arrangements that enable the covering of gas costs is out of scope for this EIP but it could be an extra-protocol monthly subscription, payment could occur as part of the transaction being submitted, the recipient may be willing to cover gas costs, or it could be a free service offered as a value-add by a company that you are working with.</p> <p>While it is possible to implement these sort of mechanisms at the individual contract layer, such solutions require integration by just about every contract and those solutions also end up depending on gas costs being stable with time in order to appropriately bake them into contracts without putting either party at risk of malicious participants in the system. For this reason, it is believed that separating out <code>GAS_PAYER</code> from <code>msg.sender</code> at the protocol layer is valuable.</p> <h3 id="batch-transactions">Batch Transactions</h3> <p>Often times an EOA may want to execute a series of transactions with a strong guarantee that they happen in order with nothing occurring between them. For example, one may want to send some tokens to a contract and then follow that up with another transaction that makes a contract call on the destination address that causes those tokens to be registered to them. By supporting transaction batching at layer 1, we can ensure that the user can get strong guarantees at signing time of cross-transaction atomicity.</p> <h3 id="expiring-transactions">Expiring Transactions</h3> <ul> <li>If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user.</li> <li>In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues.</li> <li>Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="definitions">Definitions</h3> <p><strong><code>TransactionType</code></strong> 2. See <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a></p> <p><strong><code>TransactionSubtype</code></strong> is either 1, 2, 3, or 4.</p> <p><strong><code>ChainId</code></strong> The transaction is valid if this value is <code>0</code> or it is included in a block on a chain whose ID is equal to this value.</p> <p><strong><code>ValidUntil</code></strong> The transaction is valid if this value is <code>0</code> or it is included in a block whose <code>timestamp</code> is less than or equal to this value.</p> <p><strong><code>YParity</code></strong> The parity (0 for even, 1 for odd) of the y-value of a secp256k1 signature.</p> <p><strong><code>ChildTransaction</code></strong> A nested transaction consisting of <code>[to, value, data]</code>.</p> <p><strong><code>SenderPayload</code></strong> Defined based on the <code>TransactionSubtype</code> as follows:</p> <ol> <li><code>[1, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit, gasPrice]</code></li> <li><code>[2, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit, gasPrice]</code></li> <li><code>[3, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit]</code></li> <li><code>[4, ChildTransaction[], nonce, ChainId, ValidUntil]</code></li> </ol> <p><strong><code>SenderSignature</code></strong> <code>[YParity, r, s]</code> of <code>secp256k1(keccak256(rlp([TransactionType, SenderPayload])))</code></p> <p><strong><code>GasPayerPayload</code></strong> Defined based on the <code>TransactionSubtype</code> as follows:</p> <ol> <li><code>[]</code></li> <li><code>[]</code></li> <li><code>[gasPrice]</code></li> <li><code>[gasLimit, gasPrice]</code></li> </ol> <p><strong><code>GasPayerSignature</code></strong> is <code>[]</code> for <code>TransactionSubType</code> <code>1</code> or <code>[YParity, r, s]</code> of <code>secp256k1(keccak256(rlp([SenderPayload, SenderSignature, GasPayerPayload])))</code> for others.</p> <h3 id="new-transaction-type">New Transaction Type</h3> <p>As of <code>FORK_BLOCK_NUMBER</code> an <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction with a <code>TransactionType</code> of <code>2</code> will have its <code>Payload</code> interpreted as an RLP encoded tuple of:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature]</span></span></code></pre> <p>The address recovered from <code>SenderSignature</code> is the address...</p> <ol> <li>...returned by the <code>CALLER</code> opcode (0x33, aka <code>msg.sender</code>) during the first call frame of the transaction</li> <li>...returned by the <code>ORIGIN</code> opcode (0x32, aka <code>tx.origin</code>)</li> <li>...whose <code>nonce</code> is used</li> <li>...whose ETH balance is deducted if any value is attached to the transaction</li> <li>...whose ETH balance is deducted to pay for gas if <code>GasPayerSignature</code> is not present</li> </ol> <p>If <code>GasPayerSignature</code> is present, then the address recovered from it is the address...</p> <ol> <li>...whose ETH balance is deducted to pay for gas</li> </ol> <p>The base gas cost of transactions of this type will be <code>TRANSACTION_TYPE_2_BASE_GAS_PRICE</code> + <code>TRANSACTION_TYPE_2_CHILD_GAS_PRICE</code> * <code>n</code>, rather than the cost associated with transactions of type <code>0</code> and legacy transactions.</p> <h3 id="new-transaction-receipt">New Transaction Receipt</h3> <p>As of <code>FORK_BLOCK_NUMBER</code> an <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction receipt with a <code>TransactionType</code> of <code>2</code> will have its <code>Payload</code> interpreted as a <code>rlp([status, cumulativeGasUsed, logsBloom, logs][])</code> where each item of the array corresponds to the child-transaction at matching offset in the transaction type 2 <code>Payload</code>.</p> <h2 id="rationale">Rationale</h2> <h3 id="one-monolithic-eip">One Monolithic EIP</h3> <p>This EIP could be split up into multiple EIPs, one for each of the subtypes and one for the meta-type. Alternatively, each of the subtypes could be a unique TransactionType. The reason we chose to go with a single EIP with subtypes is because these 4 transactions all have a <em>lot</em> in common and each separate EIP would be almost identical to the previous. We felt that in this case, splitting into multiple EIPs wasn't worth the duplication of EIP content.</p> <h3 id="chainid-not-encoded-with-v">ChainID not encoded with <code>v</code></h3> <p>While we could save one byte in the common case by bundling the y-parity bit of the signature with the Chain ID like in EIP-155, this adds complexity to signing tools that the authors deem not worth it given the size of the transaction overall.</p> <h3 id="optionality-of-chainid">Optionality of ChainID</h3> <p>Sometimes it is useful to have a transaction that <em>can</em> be replayed on multiple chains. An example of this is when you construct a vanity signature for a transaction and have the <code>from</code> be whatever address that signature recovers to. With the ability to have someone else be a gas payer (setting both the gas limit and the gas price), one can have transactions that deploy contracts which live at the same address on every chain. While this can be accomplished with CREATE2 using legacy transactions, we have the opportunity here to simplify the process and enable potentially other future uses of deterministic transactions by making ChainID optional.</p> <h3 id="optionality-of-validuntil">Optionality of ValidUntil</h3> <p>A user can set <code>ValidUntil</code> to a very large number which effectively makes it non-expiring. By making <code>ValidUntil</code> optional, we can save some bytes on the wire by allowing such transactions to simply have a <code>0</code> (1 byte in RLP) value for this field.</p> <h3 id="sender-sets-gaslimit-and-gasprice"><code>SENDER</code> sets <code>gasLimit</code> and <code>gasPrice</code></h3> <p>This type of transaction is useful when the transaction may execute differently depending on what these values are set to. By having the <code>SENDER</code> set both, we ensure that the <code>SENDER</code> has full control over the transaction details.</p> <h3 id="sender-sets-gaslimit-gas-payer-sets-gasprice"><code>SENDER</code> sets <code>gasLimit</code>, <code>GAS_PAYER</code> sets <code>gasPrice</code></h3> <p>This type of transaction is useful when the transaction may execute differently depending on how much gas it is allowed (e.g., number of loops) but where the <code>SENDER</code> would like to give the <code>GAS_PAYER</code> the ability to price the transaction to maximize chances of inclusion.</p> <h3 id="gas-payer-sets-gaslimit-and-gasprice"><code>GAS_PAYER</code> sets <code>gasLimit</code> and <code>gasPrice</code></h3> <p>This type of transaction allows the <code>SENDER</code> to define what they want to do, and leaves all worry about gas to the <code>GAS_PAYER</code>. This is useful for transactions where the sender doesn't care how much gas is used or the price that is paid and also either trusts the <code>GAS_PAYER</code> to be non-malicious or doesn't care if the <code>SENDER</code>'s nonce is increased. Such situations are useful when you have extra-protocol trust between the <code>SENDER</code> and <code>GAS_PAYER</code> and you want to separate concerns (what to do vs how to get included) for security or complexity reasons.</p> <h3 id="nonces">Nonces</h3> <p>The inner transaction needs a nonce to protect themselves from replay attacks. Since the inner transaction has a nonce, we get replay protection on the outer transaction as well, so it is not critical for security to have multiple parties provide a nonce.</p> <p>We could have the <code>GAS_PAYER</code> provide a second nonce, but this would increase the payload size and require <code>GAS_PAYER</code> to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price. It would also create the possibility of a deadlock if the <code>SENDER</code> nonces aren't ordered the same as the <code>GAS_PAYER</code> nonces, and if the <code>SENDER</code> nonce isn't the lowest valid nonce for the <code>SENDER</code> then the <code>GAS_PAYER</code> can't sign and submit yet. Finally, client complexity increases slightly if a transaction has two nonces because you have to protect yourself from deadlocks and do more work to determine validity.</p> <h3 id="validuntil">ValidUntil</h3> <p>For the dust-account clearing usecase,</p> <ul> <li>This change is much less invasive in the consensus engine. <ul> <li>No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block.</li> <li>Only touches the transaction validation part of the consensus engine</li> <li>Other schemas which uses the <code>nonce</code> can have unintended side-effects, <ul> <li>such as inability to create contracts at certain addresses.</li> <li>more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine.</li> <li>More intricate schemes like <code>highest-nonce</code> are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field.</li> </ul> </li> </ul> </li> </ul> <h3 id="validuntil-as-timestamp-instead-of-block-number">ValidUntil as timestamp instead of block number</h3> <ul> <li>The unix time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties.</li> <li>The correlation between time and block number is not fixed; even though a 13s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression.</li> <li>The block number is even more unreliable as a timestamp for testnets and private networks.</li> <li>unix time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitable number of valid blocks.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No known issues.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="implementation">Implementation</h2> <h2 id="security-considerations">Security Considerations</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-05-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Vlasovhttps://github.com/shamatar https://wg-eips.ritovision.com/2666/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP tries to set prices of certain precompiles and built-in EVM function to be in line with their performance, consumed resources and newer changes in EVM itself.</p> <p>New price formulas are proposed for:</p> <ul> <li>SHA256 precompile (<code>0x02</code>)</li> <li>RIPEMD precompile (<code>0x03</code>)</li> <li>KECCAK256 opcode (<code>0x20</code>)</li> </ul> <h2 id="abstract">Abstract</h2> <p>Costs of many precompiles and built-in functions are invalid at the current state of the clients. This EIP contains a list of changes to the pricing formulas to better reflect underlying computations' structure.</p> <h2 id="motivation">Motivation</h2> <p>Historical pricing for these functions in EVM does not reflect inner structure of the underlying computations (inner structure of the hash functions).</p> <ul> <li>EIP-2046 changes a <code>STATICCALL (0xfa)</code> cost to precompile and it may be necessary to adjust costs of some precompiles that <em>may</em> have taken old large cost (<code>700</code> gas) into account and tried to compensate for it</li> <li>Some precompiles are overpriced and their pricing formulas do not reflect the structure of underlying functions</li> <li>Keccak256 built-in function (opcode) in EVM has pricing that does not reflect underlying hash function structure</li> </ul> <h2 id="specification">Specification</h2> <p>If <code>block_number &gt;= X</code> set the gas cost of the following precompiles and Keccak256 opcode:</p> <ul> <li>SHA256 (precompile <code>0x02</code>): <code>10 + ((len(input) + 8)/64 + 1) * 9</code></li> <li>RIPEMD (precompile <code>0x03</code>): <code>6 + ((len(input) + 8)/64 + 1) * 12</code></li> <li>KECCAK256 (<code>0x20</code>): <code>13 + (len(input)/136 + 1)*15</code></li> </ul> <p>This EIP <em>ideally</em> requires that <code>MODEXP</code> repricing is <a href="https://wg-eips.ritovision.com/2565/">implemented</a> to also accurately reflect that there is no implicit compensation for an old <code>STATICCALL (0xfa)</code> cost (pre-2046).</p> <h2 id="rationale">Rationale</h2> <p>Cost of functions being executed must accurately reflect real CPU time spent on computations, so benchmarking was performed for current precompiles and Keccak256 function to measure running time versus input parameters.</p> <h3 id="detailed-summary-of-repricing-approach">Detailed summary of repricing approach</h3> <p>This EIP relies on two facts:</p> <ul> <li>apriori knowledge of the inner strucute of the hash functions</li> <li>benchmarks provided by the client teams for some reasonable range of input lengths for random inputs (random byte strings of a given length)</li> </ul> <h3 id="benchmarks-on-the-most-popular-clients">Benchmarks on the most popular clients</h3> <p>Necessary benchmarks for EIP-2666 were provided by the clients and raw form is assembled in <a rel="external" href="https://docs.google.com/spreadsheets/d/1aCQnk7prrp3Mbcf011BE5zZnkbc3Iw7QAixn6mLbKS0/edit?usp=sharing">here</a></p> <ul> <li>SHA256 precompile</li> </ul> <p>Currently it's <code>60</code> gas + <code>12</code> gas per <code>32</code> byte word (number of words is <code>ceil(len(input)/word_len)</code> here and in similar places. If there is no <code>floor</code> or <code>ceil</code> specifier all divisions below are integer divisions (floor divisions)). Proposed formula is <code>A * ((len(input) + 8) / 64 + 1) + B</code>, with coefficients below</p> <table><thead><tr><th></th><th></th><th>A</th><th>B</th></tr></thead><tbody> <tr><td>Geth</td><td></td><td>5</td><td>3</td></tr> <tr><td>OE</td><td></td><td>9</td><td>4</td></tr> <tr><td>Besu</td><td></td><td>5</td><td>10</td></tr> <tr><td>Nethermind</td><td></td><td>10</td><td>5</td></tr> </tbody></table> <p>EIP-2666 proposes <code>A = 9</code>, <code>B = 10</code>. There are no large one-off costs in this precompile, so it's EIP-2046 - safe.</p> <ul> <li>RIPEMD precompile</li> </ul> <p>Currently it's <code>600</code> gas + <code>120</code> gas per <code>32</code> byte word. Proposed formula is <code>A * ((len(input) + 8) / 64 + 1) + B</code>, with coefficients below</p> <table><thead><tr><th></th><th></th><th>A</th><th>B</th></tr></thead><tbody> <tr><td>Geth</td><td></td><td>12</td><td>6</td></tr> <tr><td>OE</td><td></td><td>8</td><td>2</td></tr> <tr><td>Besu</td><td></td><td>29</td><td>16</td></tr> <tr><td>Nethermind</td><td></td><td>10</td><td>6</td></tr> </tbody></table> <p>EIP-2666 proposes <code>A = 12</code>, <code>B = 6</code>. There are no large one-off costs in this precompile, so it's EIP-2046 - safe. Besu expects to have performance improvements by the end of the year.</p> <ul> <li>Keccak256 performance</li> </ul> <p>Currently it's <code>30</code> gas + <code>6</code> gas per <code>32</code> byte word. Proposed formula is <code>A * (len(input) / 136 + 1) + B</code>, with coefficients below</p> <table><thead><tr><th></th><th></th><th>A</th><th>B</th></tr></thead><tbody> <tr><td>Geth</td><td></td><td>13</td><td>13</td></tr> <tr><td>OE</td><td></td><td>15</td><td>2</td></tr> <tr><td>Besu</td><td></td><td>19</td><td>28</td></tr> <tr><td>Nethermind</td><td></td><td>16</td><td>3</td></tr> </tbody></table> <p>EIP-2666 proposes <code>A = 15</code>, <code>B = 13</code>. There are no large one-off costs in this precompile, so it's EIP-2046 - safe. Besu expects to have performance improvements by the end of the year.</p> <h3 id="tooling-and-data">Tooling and data</h3> <p>Reference material (from benchmarks of different clients) with raw data can be found <a rel="external" href="https://docs.google.com/spreadsheets/d/1aCQnk7prrp3Mbcf011BE5zZnkbc3Iw7QAixn6mLbKS0/edit?usp=sharing">here</a>.</p> <p>There is a repository available with inputs for benchmarking and precompiles testing <a rel="external" href="https://github.com/shamatar/bench_precompiles">here</a> that can be used by client teams to perform all the necessary measurements.</p> <p>Raw Besu <a rel="external" href="https://gist.github.com/shemnon/0ddba91be501fa23291bdec9107fe99a">benchmarks</a>.</p> <h3 id="note-on-formulas-structure">Note on formulas structure</h3> <p>There are terms in formulas that look like <code>A * 1</code> and those are explicitly not combined to the <code>B</code> coefficient to reflect that hash of an empty byte array requires to perform a round of hashing anyway.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Precompile repricings has happened in a past and can be considered standard procedure. Gas costs of many contracts is expected to reduce that may break re-entrancy protection measures based on fixed gas costs. In any case, such protection should have never been considered good and final.</p> <h2 id="test-cases">Test Cases</h2> <p>Let's consider a simple example of Keccak256 hash of <code>0</code>, <code>64</code> and <code>160</code> bytes that can is a simple sanity check for implementation.</p> <ul> <li>Hash <code>0</code> bytes: <ul> <li>Old price: <code>30 + 6 * ceil(0 / 32) = 30</code> gas</li> <li>New price: <code>15 * (0/136 + 1) + 13 = 28</code> gas</li> </ul> </li> <li>Hash <code>64</code> bytes <ul> <li>Old price: <code>30 + 6 * ceil(64 / 32) = 42</code> gas</li> <li>New price: <code>15 * (64/136 + 1) + 13 = 28</code> gas</li> </ul> </li> <li>Hash <code>160</code> bytes <ul> <li>Old price: <code>30 + 6 * ceil(160 / 32) = 60</code> gas</li> <li>New price: <code>15 * (160/136 + 1) + 13 = 43</code> gas</li> </ul> </li> </ul> <h2 id="implementation">Implementation</h2> <p>There is no reference implementation at the time of writing as it requires just a simple change of constants in major clients.</p> <h2 id="security-considerations">Security Considerations</h2> <p>As described in backward compatibility section in some cases reduction of cost may allow e.g. re-entrancy that was not expected before, but we think that re-entrancy protection based on fixed gas costs is anyway flawed design decision.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-05-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Holst Swendehttps://github.com/holiman Paweł Bylicahttps://github.com/chfast Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2677/ <h2 id="simple-summary">Simple Summary</h2> <p>Enforce a maximum size limit (<code>max_initcode_size</code>) of <code>49152</code> (<code>0xc000</code>) for <code>initcode</code>.</p> <h2 id="abstract">Abstract</h2> <p>Enforce a maximum size limit (<code>max_initcode_size</code>) for <code>initcode</code>. If the size of <code>initcode</code> exceeds <code>max_initcode_size</code>, then contract creation fails with an out of gas error.</p> <p>Since <a href="https://wg-eips.ritovision.com/170/">EIP-170</a> was implemented, there has been a size limit of <code>24576</code> (<code>0x6000</code>) on contract code. We propose to also limit the size of executable code to <code>2x</code> the above limit, i.e. <code>49152</code> (<code>0xc000</code>).</p> <p>This also leads to two nice properties:</p> <ul> <li>instruction offset in code fits 16-bit value,</li> <li>code size fits 16-bit value.</li> </ul> <h2 id="motivation">Motivation</h2> <p>When a client executes <code>initcode</code>, the client has to perform a jumpdest analysis. In some cases, the client also performs a <code>hash</code> of the code:</p> <ul> <li>To use as a key in a mapping containing the result of a jumpdest analysis</li> <li>To use for address calculation within <code>CREATE2</code>.</li> </ul> <p>The work performed during a jumpdest analysis scales linearly with the size of the code. Currently, a transaction can expand the memory once, and reuse the same memory segment (with minor modifications) to force the client to perform a lot of analysis/hashing, leading to slow block processing.</p> <p>Historically, this was exploited in June 2017, precipitating the 1.6.5-patch release of <a rel="external" href="https://github.com/ethereum/go-ethereum/releases/tag/v1.6.5">geth</a></p> <p>The work performed during address calculation within <code>CREATE2</code> is charged in proportion with size of the code.</p> <h2 id="specification">Specification</h2> <p>There are three situations where this is applicable:</p> <ul> <li><code>CREATE</code>,</li> <li><code>CREATE2</code>,</li> <li>creation using a transaction with empty receiver.</li> </ul> <p>In all these (and future) cases, the EVM should fail with Out Of Gas error if the code has a length more than <code>max_initcode_size</code>.</p> <h2 id="rationale">Rationale</h2> <p>TBA</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a "network upgrade", since it modifies consensus-rules.</p> <h2 id="security-considerations">Security Considerations</h2> <p>For client implementations, this EIP makes attacks based on jumpdest-analysis or hashing of code less problematic, so should increase the robustness of clients.</p> <p>For layer 2, this EIP introduces failure-modes where there previously were none. There <em>could</em> exist factory-contracts which deploy multi-level contract hierarchies, such that the code for multiple contracts are included in the initcode of the first contract. The author(s) of this EIP are not aware of any such contracts.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases should include the following cases,</p> <ul> <li><code>CREATE</code>/<code>CREATE2</code>/<code>tx create</code> with <code>initcode_size</code> at <code>max_initcode_size</code></li> <li><code>CREATE</code>/<code>CREATE2</code>/<code>tx create</code> with <code>initcode_size</code> at <code>max_initcode_size+1</code></li> </ul> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-04-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2681/ <h2 id="abstract">Abstract</h2> <p>Limit account nonce to be between <code>0</code> and <code>2^64-1</code>.</p> <h2 id="motivation">Motivation</h2> <p>Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized way.</p> <p>Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals.</p> <p>Lastly, this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number.</p> <h2 id="specification">Specification</h2> <p>Introduce two new restrictions retroactively from genesis:</p> <ol> <li>Consider any transaction invalid, where the nonce exceeds or equals to <code>2^64-1</code>.</li> <li>The <code>CREATE</code> and <code>CREATE2</code> instructions' execution ends with the result <code>0</code> pushed on stack, where the account nonce is <code>2^64-1</code>. Gas for initcode execution is not deducted in this case.</li> </ol> <h2 id="rationale">Rationale</h2> <ol> <li> <p>It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least <code>21000 * (2^64-1) = 387_381_625_547_900_583_915_000</code> gas.</p> </li> <li> <p>It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of <code>2^20</code> in order to differentiate transactions from mainnet transactions. This mode of replay protection is out of fashion since <a href="https://wg-eips.ritovision.com/155/">EIP-155</a> introduced a more elegant way using chain identifiers.</p> </li> <li> <p>Most clients already consider the nonce field to be 64-bit, such as go-ethereum.</p> </li> <li> <p>The reason a transaction with nonce <code>2^64-1</code> is invalid, because otherwise after inclusion the sender account's nonce would exceed <code>2^64-1</code>.</p> </li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>While this is a breaking change, no actual effect should be visible:</p> <ol> <li> <p>There is no account in the state currently which would have a nonce exceeding that value. As of November 2020, the account <code>0xea674fdde714fd979de3edf0f56aa9716b898ec8</code> is responsible for the highest account nonce at approximately 29 million.</p> </li> <li> <p>go-ethereum already has this restriction partially in place (<code>state.Account.Nonce</code> and <code>types.txdata.AccountNonce</code> it as a 64-bit number).</p> </li> </ol> <h2 id="security-considerations">Security Considerations</h2> <p>None.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-04-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Guillaume Ballethttps://github.com/gballet https://wg-eips.ritovision.com/2584/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP proposes a method to convert the state trie format from hexary to binary: new values are directly stored in a binary trie “laid over” the hexary trie. Meanwhile, the hexary trie is converted to a binary trie in the background. When the process is finished, both layers are merged.</p> <h2 id="abstract">Abstract</h2> <p>This EIP describes a four phase process to complete the conversion.</p> <ul> <li>In the first phase, all new state writes are made to an overlay binary trie, while the hexary trie is being converted to binary. The block format is changed to have two storage roots: the root of the hexary trie (hereafter called the "base" trie) and the root of the overlay binary trie.</li> <li>After enough time has been given to miners to perform the conversion, the second phase begins. The overlay tree is progressively merged back into the newly converted binary base trie. A constant number of entries are deleted from the overlay and inserted into the base trie.</li> <li>The third and final phase begins when the overlay trie is empty. The field holding its root is removed from the block header.</li> </ul> <h2 id="motivation">Motivation</h2> <p>There is a long running interest in switching the state trie from a hexary format to a binary format, for reasons pertaining to proof and storage sizes. The conversion process poses a catch-up issue, caused by the sheer size of the full state: it can not be translated in a reasonable time (i.e. on the same order of magnitude as the block time).</p> <h2 id="specification">Specification</h2> <p>This specification follows the notation introduced by the <a rel="external" href="https://ethereum.github.io/yellowpaper">Yellow Paper</a>. Prior to reading it is advisable to be familiar with the Yellow Paper.</p> <h3 id="binary-tries">Binary tries</h3> <p>This EIP assumes that a binary trie is defined like the MPT, except that:</p> <ul> <li>The series of bytes in I₀ is seen as a series of <em>bits</em> and so ∀i≤256, I₀[i] is the ith bit in key I₀</li> <li>The first item of an <strong>extension</strong> or a <strong>leaf</strong> is replacing nibbles with bits;</li> <li>A <strong>branch</strong> is a 2 item structure in which both items correspond to each of the two possible bit values for the keys at this point in their traversal;</li> <li>c(𝕴,i) ≡ RLP((u(0), u(1)) at a branch, where u(j) = n({I : I ∈ 𝕴 ⋀ I₀[i] = j}, i+1)</li> </ul> <p>Let ß be the function that, given a hexary trie, computes the equivalent representation of that trie in the aforementioned binary trie format.</p> <h3 id="phase-1">Phase 1</h3> <p>Let <em>h₁</em> be the previously agreed-upon block height at which phase 1 starts, and <em>h₂</em> the block at which phase 2 starts. For each block of height h₁ ≤ <em>h</em> &lt; h₂:</p> <ol start="0"> <li>A conversion process is started in the background, to turn the hexary trie into its binary equivalent. The end goal of this process is the calculation of the <em>root hash of the converted binary trie</em>, denoted Hᵣ². The root of the hexary trie is hereafter called Hᵣ¹⁶. Formally, this process is written as Hᵣ² ≡ ß(Hᵣ¹⁶).</li> <li>Block headers contain a new Hₒ field, which is the <em>root of the overlay binary trie</em>;</li> <li>Hᵣ ≡ P(H)ᵣ¹⁶, i.e. as long as the conversion from hexary to binary is not complete, the hexary trie root is the same as that of its parent block.</li> </ol> <p>The following is changed in the execution environment:</p> <ul> <li>Upon executing a <em>state read</em>, ϒ first searches for the address in the overlay trie. If the key can not be found there, ϒ then searches the base trie as it did at block heights h' &lt; h₁;</li> <li>Upon executing a <em>state write</em>, ϒ inserts or updates the value into the overlay tree. The base tree is left untouched;</li> <li>If an account is deleted, ϒ inserts the empty hash H(∅) at the address of that account in order to mark its deletion; reads from such an address behave the same as a missing account, regardless of what is present in the base trie.</li> </ul> <p>Phase 1 ends at block height h₂, which is set far enough from h₁ to offer miners enough time to perform the conversion.</p> <h3 id="phase-2">Phase 2</h3> <p>This phase differs from the previous one on the following points:</p> <ul> <li>At block height h₂, before the execution of ϒ, Hᵣ ≡ Hᵣ², i.e. the value before the execution of the transition function is set to the root of the converted <em>binary base trie</em>;</li> <li>Hₒ is still present in the block tree, however the overlay trie content can only be <em>read from or deleted</em>;</li> <li>At block height h ≥ h₂, before the execution of ϒ, N accounts are being deleted from the binary overlay trie and inserted into the binary base trie;</li> <li>Upon executing a <em>state write</em>, ϒ will insert or update the value into the <em>base</em> trie. If the search key exists in the overlay trie, it is deleted.</li> </ul> <p>Account deletion is performed according to the following rules:</p> <ul> <li>The first N accounts (in lexicographic order) remaining in the overlay tree are selected; For each of these accounts:</li> <li>If the value is the empty hash, remove the account at the same address from the binary base trie;</li> <li>Otherwise, insert/update the account at the corresponding address in the base trie with its overlay trie value.</li> </ul> <p>When the overlay trie is empty, phase 2 ends and phase 3 begins.</p> <h3 id="phase-3">Phase 3</h3> <p>Phase 3 is the same as phase 2, except for the following change:</p> <ul> <li>Hₒ is dropped from the block header</li> </ul> <h2 id="rationale">Rationale</h2> <p>Methods that have been discussed until now include a "stop the world" approach, in which the chain is stopped for the significant amount of time that is required by the conversion, and a "copy on write" approach, in which branches are converted upon being accessed. The approach suggested here has the advantage that the chain continues to operate normally during the conversion process, and that the tree is fully converted to a binary format, in a predictable time.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This requires a fork and will break backwards compatibility, as the hashes and block formats will necessarily be different. This will cause a fork in clients that don't implement the overlay tree, and those that do not accept the new binary root. No mitigation is proposed, as this is a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>For testing phase 1, it suffices to check that every key in the hexary trie is also available in the binary trie. A looser but faster test picks 1% of keys in the hexary trie at random, and checks that they are present in the binary trie;</li> <li>TBD for phase 2 &amp; 3</li> </ul> <h2 id="implementation">Implementation</h2> <p>A prototype version of the conversion process (phase 1) is available for <code>geth</code> in <a rel="external" href="https://github.com/holiman/go-ethereum/pull/12">this PR</a>.</p> <h2 id="security-considerations">Security Considerations</h2> <p>There are three attack vectors that I can foresee:</p> <ul> <li>A targeted attack that would cause the overlay trie to be unreasonably large. Since gas costs will likely increase during the transition process, lengthening phase 2 will make Ethereum more expensive during an extended period of time. This could be solved by increasing the cost of <code>SSTORE</code> during phase 1.</li> <li>Conversely, if h₂ comes too soon, a majority of miners might not be able to produce the correct value for Hᵣ² in time.</li> <li>If a group of miners representing more than 51% of the network are reporting an invalid value, they could be stealing funds without anyone having a say.</li> </ul> <h2 id="community-feedback">Community feedback</h2> <ul> <li>Preliminary tests indicate that a fast machine can perform the conversion in roughly 30 minutes.</li> <li>The initial version of this EIP expected miners to vote on the value of the binary base root. This has been removed because of the complexity of this process, and because this functionality is already guaranteed by the "longest chain" rule.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-03-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Kelly Olsonhttps://github.com/ineffectualproperty Sean Gulleyhttps://github.com/sean-sn Simon Peffershttps://github.com/simonatsn Justin Drakehttps://github.com/justindrake Dankrad Feisthttps://github.com/dankrad https://wg-eips.ritovision.com/2565/ <h2 id="simple-summary">Simple Summary</h2> <p>Defines the gas cost of the <code>ModExp</code> (<code>0x00..05</code>) precompile.</p> <h2 id="abstract">Abstract</h2> <p>To accurately reflect the real world operational cost of the <code>ModExp</code> precompile, this EIP specifies an algorithm for calculating the gas cost. This algorithm approximates the multiplication complexity cost and multiplies that by an approximation of the iterations required to execute the exponentiation.</p> <h2 id="motivation">Motivation</h2> <p>Modular exponentiation is a foundational arithmetic operation for many cryptographic functions including signatures, VDFs, SNARKs, accumulators, and more. Unfortunately, the ModExp precompile is currently over-priced, making these operations inefficient and expensive. By reducing the cost of this precompile, these cryptographic functions become more practical, enabling improved security, stronger randomness (VDFs), and more.</p> <h2 id="specification">Specification</h2> <p>As of <code>FORK_BLOCK_NUMBER</code>, the gas cost of calling the precompile at address <code>0x0000000000000000000000000000000000000005</code> will be calculated as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def calculate_multiplication_complexity(base_length, modulus_length):</span></span> <span class="giallo-l"><span> max_length = max(base_length, modulus_length)</span></span> <span class="giallo-l"><span> words = math.ceil(max_length / 8)</span></span> <span class="giallo-l"><span> return words**2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def calculate_iteration_count(exponent_length, exponent):</span></span> <span class="giallo-l"><span> iteration_count = 0</span></span> <span class="giallo-l"><span> if exponent_length &lt;= 32 and exponent == 0: iteration_count = 0</span></span> <span class="giallo-l"><span> elif exponent_length &lt;= 32: iteration_count = exponent.bit_length() - 1</span></span> <span class="giallo-l"><span> elif exponent_length &gt; 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent &amp; (2**256 - 1)).bit_length() - 1)</span></span> <span class="giallo-l"><span> return max(iteration_count, 1)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>def calculate_gas_cost(base_length, modulus_length, exponent_length, exponent):</span></span> <span class="giallo-l"><span> multiplication_complexity = calculate_multiplication_complexity(base_length, modulus_length)</span></span> <span class="giallo-l"><span> iteration_count = calculate_iteration_count(exponent_length, exponent)</span></span> <span class="giallo-l"><span> return max(200, math.floor(multiplication_complexity * iteration_count / 3))</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>After benchmarking the ModExp precompile, we discovered that it is ‘overpriced’ relative to other precompiles. We also discovered that the current gas pricing formula could be improved to better estimate the computational complexity of various ModExp input variables. The following changes improve the accuracy of the <code>ModExp</code> pricing:</p> <h3 id="1-modify-computational-complexity-formula-to-better-reflect-the-computational-complexity">1. Modify ‘computational complexity’ formula to better reflect the computational complexity</h3> <p>The complexity function defined in <a href="https://wg-eips.ritovision.com/198/">EIP-198</a> is as follow:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def mult_complexity(x):</span></span> <span class="giallo-l"><span> if x &lt;= 64: return x ** 2</span></span> <span class="giallo-l"><span> elif x &lt;= 1024: return x ** 2 // 4 + 96 * x - 3072</span></span> <span class="giallo-l"><span> else: return x ** 2 // 16 + 480 * x - 199680</span></span></code></pre> <p>where is <code>x</code> is <code>max(length_of_MODULUS, length_of_BASE)</code></p> <p>The complexity formula in <a href="https://wg-eips.ritovision.com/198/">EIP-198</a> was meant to approximate the difficulty of Karatsuba multiplication. However, we found a better approximation for modelling modular exponentiation. In the complexity formula defined in this EIP, <code>x</code> is divided by 8 to account for the number of limbs in multiprecision arithmetic. A comparison of the current ‘complexity’ function and the proposed function against the execution time can be seen below:</p> <p><img src="https://wg-eips.ritovision.com/2565/./assets/Complexity_Regression.png" alt="Option 1 Graph" /></p> <p>The complexity function defined here has a better fit vs. the execution time when compared to the <a href="https://wg-eips.ritovision.com/198/">EIP-198</a> complexity function. This better fit is because this complexity formula accounts for the use of binary exponentiation algorithms that are used by ‘bigint’ libraries for large exponents. You may also notice the regression line of the proposed complexity function bisects the test vector data points. This is because the run time varies depending on if the modulus is even or odd.</p> <h3 id="2-change-the-value-of-gquaddivisor">2. Change the value of GQUADDIVISOR</h3> <p>After changing the 'computational complexity' formula in <a href="https://wg-eips.ritovision.com/198/">EIP-198</a> to the one defined here it is necessary to change <code>QGUADDIVSOR</code> to bring the gas costs inline with their runtime. By setting the <code>QGUADDIVISOR</code> to <code>3</code> the cost of the ModExp precompile will have a higher cost (gas/second) than other precompiles such as ECRecover.</p> <p><img src="https://wg-eips.ritovision.com/2565/./assets/GQuad_Change.png" alt="Option 2 Graph" /></p> <h3 id="3-set-a-minimum-gas-cost-to-prevent-abuse">3. Set a minimum gas cost to prevent abuse</h3> <p>This prevents the precompile from underpricing small input values.</p> <h2 id="test-cases">Test Cases</h2> <p>There are no changes to the underlying interface or arithmetic algorithms, so the existing test vectors can be reused. Below is a table with the updated test vectors:</p> <table><thead><tr><th>Test Case</th><th>EIP-198 Pricing</th><th>EIP-2565 Pricing</th></tr></thead><tbody> <tr><td>modexp_nagydani_1_square</td><td>204</td><td>200</td></tr> <tr><td>modexp_nagydani_1_qube</td><td>204</td><td>200</td></tr> <tr><td>modexp_nagydani_1_pow0x10001</td><td>3276</td><td>341</td></tr> <tr><td>modexp_nagydani_2_square</td><td>665</td><td>200</td></tr> <tr><td>modexp_nagydani_2_qube</td><td>665</td><td>200</td></tr> <tr><td>modexp_nagydani_2_pow0x10001</td><td>10649</td><td>1365</td></tr> <tr><td>modexp_nagydani_3_square</td><td>1894</td><td>341</td></tr> <tr><td>modexp_nagydani_3_qube</td><td>1894</td><td>341</td></tr> <tr><td>modexp_nagydani_3_pow0x10001</td><td>30310</td><td>5461</td></tr> <tr><td>modexp_nagydani_4_square</td><td>5580</td><td>1365</td></tr> <tr><td>modexp_nagydani_4_qube</td><td>5580</td><td>1365</td></tr> <tr><td>modexp_nagydani_4_pow0x10001</td><td>89292</td><td>21845</td></tr> <tr><td>modexp_nagydani_5_square</td><td>17868</td><td>5461</td></tr> <tr><td>modexp_nagydani_5_qube</td><td>17868</td><td>5461</td></tr> <tr><td>modexp_nagydani_5_pow0x10001</td><td>285900</td><td>87381</td></tr> </tbody></table> <h2 id="implementations">Implementations</h2> <p><a rel="external" href="https://github.com/ethereum/go-ethereum/pull/21607">Geth</a></p> <p><a rel="external" href="https://gist.github.com/ineffectualproperty/60e34f15c31850c5b60c8cf3a28cd423">Python</a></p> <h2 id="security-considerations">Security Considerations</h2> <p>The biggest security consideration for this EIP is creating a potential DoS vector by making ModExp operations too inexpensive relative to their computation time.</p> <h2 id="references">References</h2> <p><a href="https://wg-eips.ritovision.com/198/">EIP-198</a></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-03-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Dan Finlaydan@danfinlay.com https://wg-eips.ritovision.com/2593/ <h2 id="simple-summary">Simple Summary</h2> <p>The current "first price auction" fee model in Ethereum is inefficient and needlessly costly to users. This EIP proposes a way to replace this with a mechanism that allows dynamically priced transaction fees and efficient transaction price discovery.</p> <h2 id="abstract">Abstract</h2> <p>Based on <a rel="external" href="https://agoric.com/papers/incentive-engineering-for-computational-resource-management/full-text/">The Agoric Papers</a>.</p> <p>Each transaction would have the option of providing parameters that specify an "escalating" bid, creating a time-based auction for validators to include that transaction.</p> <p>This creates highly efficient price discovery, where the price will always immediately fall to the highest bid price, which is not necessarily that user's highest price they would pay.</p> <p><img src="https://ethresear.ch/uploads/default/original/2X/0/042795efa4c2680d644bc66386cd2984a70293f8.gif" alt="escalator algorithm price chart" /></p> <h2 id="motivation">Motivation</h2> <p>Ethereum currently prices transaction fees using a simple first-price auction, which leads to well documented inefficiencies (some of which are documented in <a rel="external" href="https://github.com/ethereum/EIPs/blob/master/EIPS/./01559.md">EIP-1559</a>) when users are trying to estimate what price will get a transaction included in a block, especially during times of price volatility and full blocks.</p> <p>EIP 1559 is currently being championed as an improvement for the Ethereum protocol, and while I agree that the gas market is very inefficient, since a change like this will affect all client and wallet implementations, the Ethereum community should make sure to make a selection based on solid reasoning and justifications, which I believe 1559 is currently lacking.</p> <p>To facilitate a more productive and concrete discussion about the gas fee market, I felt it was important to present an alternative that is clearly superior to the status quo, so that any claimed properties of EIP-1559 can be compared to a plausible alternative improvement.</p> <p>I suggest the three gas payment algorithms be compared under all combinations of these conditions:</p> <ul> <li>Blocks that are regularly half full, Blocks that are regularly less than half full, and blocks that repeatedly full in a surprising ("black swan") series.</li> <li>Users that are willing to wait for a price that may be below the market rate, vs users who value inclusion urgently and are willing to pay above market rate.</li> </ul> <p>We should then ask:</p> <ul> <li>Is the user willing to pay the most in a given scenario also likely to have their transaction processed in a time period they find acceptable?</li> <li>Are users who want a good price likely to get included in a reasonable period of time? (Ideally within one block)</li> </ul> <p>I believe that under this analysis we will find that the escalator algorithm outperforms EIP-1559 in both normal and volatile conditions, for both high-stakes transactions and more casual users looking for a good price.</p> <p>While I think a deeper simulation/analysis should be completed, I will share my expected results under these conditions.</p> <p>Furthermore, by introducing tx fee payment related to the current time, we create an incentive for miners to more honestly report the current time.</p> <h3 id="user-strategies-under-various-conditions-and-algorithms">User Strategies Under Various Conditions and Algorithms</h3> <p>First I will suggest a likely optimal strategy for different players under the conditions of the different algorithms being considered.</p> <table><thead><tr><th>Gas Strategy</th><th>Current Single-Price</th><th>EIP 1559</th><th>Escalator</th></tr></thead><tbody> <tr><td>Blocks regularly half full, user wants urgent inclusion.</td><td>User bids within the range of prices that have been recently accepted, likely over-pays slightly.</td><td>User bids one price tier over the current rate, and is likely included.</td><td>User bids a range from the low end of recently included to the high end, and is likely included at the lowest rate possible.</td></tr> <tr><td>Blocks regularly half full, user willing to wait for a good price.</td><td>User bids below or near the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price.</td><td>User bids under or at the current price tier, and may wait for the price to fall. If waiting too long, user may need to re-submit with a higher price.</td><td>User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price.</td></tr> <tr><td>Blocks regularly full, user wants urgent inclusion.</td><td>User bids over the price of all recently accepted transactions, almost definitely over-paying significantly.</td><td>User bids over the current price tier, and needs to increase their <code>tip</code> parameter to be competitive on the next block, recreating the single-price auction price problem.</td><td>User bids over a price that has been accepted consistently, with an escalating price in case that price is not high enough.</td></tr> <tr><td>Blocks regularly full, user willing to wait for a good price.</td><td>User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price.</td><td>User bids under or at the current price tier, and may wait for the price to fall. If waiting too long, user may need to re-submit with a higher price.</td><td>User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price.</td></tr> <tr><td>Blocks regularly under-full, user wants urgent inclusion.</td><td>User bids within or over the range of prices that have been recently accepted, likely over-pays slightly, and is likely included in the next block.</td><td>User bids at or over the current price tier, and is likely included in the next block.</td><td>User submits bid starting within recently accepted prices, is likely accepted in the next block.</td></tr> <tr><td>Blocks regularly under-full, user willing to wait for a good price.</td><td>User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price.</td><td>User bids at or under the current price tier, and is likely included in the next block. If bidding under and waiting too long, user may need to re-submit with a higher price.</td><td>User bids as low as they'd like, but set an upper bound on how long they're willing to wait before increasing price, is likely included in the next few blocks at the lowest possible price.</td></tr> </tbody></table> <h3 id="user-results-under-various-conditions-and-algorithms">User Results Under Various Conditions and Algorithms</h3> <p>Now I will consider the ultimate results of the strategies listed above. Are users happy under these conditions? Did we save users money? Were users who wanted urgent inclusion able to secure it?</p> <table><thead><tr><th>Gas Strategy</th><th>Current Single-Price</th><th>EIP 1559</th><th>Escalator</th></tr></thead><tbody> <tr><td>Blocks regularly half full, user wants urgent inclusion.</td><td>User pays an expected amount, and gets transaction mined reliably.</td><td>User pays an expected amount, and gets transaction mined reliably.</td><td>User pays an expected amount, and gets transaction mined reliably.</td></tr> <tr><td>Blocks regularly half full, user willing to wait for a good price.</td><td>User can wait for a better price, but may need to resubmit re-signed transactions.</td><td>User can wait for a better price, but may need to resubmit re-signed transactions.</td><td>User can discover the lowest price within their time preference with a single signature.</td></tr> <tr><td>Blocks regularly full, user wants urgent inclusion.</td><td>User over-pays, but reliably gets transaction included.</td><td>Due to <code>tip</code> parameter "breaking tie" within a block, user over-pays for reliable inclusion.</td><td>User is able to balance the amount of overpayment they risk with the urgency they require.</td></tr> <tr><td>Blocks regularly full, user willing to wait for a good price.</td><td>User chooses their price, and waits for it, or manually re-submits.</td><td>User chooses their price, and waits for it, or manually re-submits.</td><td>User chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed.</td></tr> <tr><td>Blocks regularly under-full, user wants urgent inclusion.</td><td>User over-pays, but reliably gets transaction included.</td><td>User bids at or over current price tier, gets transaction mined reliably.</td><td>User pays an expected amount, and gets transaction mined reliably.</td></tr> <tr><td>Blocks regularly under-full, user willing to wait for a good price.</td><td>User bids below the low end of the recently accepted prices, may need to wait for a while. If waiting too long, user may need to re-submit with a higher price.</td><td>User chooses their price, and waits for it, or manually re-submits.</td><td>User chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed.</td></tr> </tbody></table> <p>In all cases, the escalator algorithm as I have described is able to perform optimally.</p> <p>The current gas auction model works well under half-full and less conditions, but for users with urgent needs, has the downside of overpayment. For users seeking a low price, the current model has the downside of requiring re-submission, but has the benefit of always giving users a path towards reliable block inclusion.</p> <p>EIP-1559 also performs well under normal conditions, but under conditions where blocks are regularly full, the price discovery mechanism breaks, and miners will fall back to the <code>TIP</code> parameter to choose the transactions to include, meaning that under network congestion, EIP-1559 forces users to <em>either</em> choose efficient prices or certainty of next-block inclusion.</p> <p>EIP-1559 also has all the re-submission issues of the current model in situations where a user would like to pay under the current market rate, but has certain time constraints limiting their patience. The Escalator algorithm is the only strategy listed here that allows users to discover the lowest possible price given the network conditions and their time constraints.</p> <h2 id="specification">Specification</h2> <p><strong>Client-Wide Parameters</strong></p> <ul> <li><code>INITIAL_FORK_BLKNUM</code>: TBD</li> </ul> <p><strong>Transaction Parameters</strong> The transaction <code>gasPrice</code> parameter is now optional, and if excluded can be replaced by these parameters instead:</p> <ul> <li><code>START_PRICE</code>: The lowest price that the user would like to pay for the transaction.</li> <li><code>START_TIME</code>: The first time that this transaction is valid at.</li> <li><code>MAX_PRICE</code>: The maximum price the sender would be willing to pay to have this transaction processed.</li> <li><code>MAX_TIME</code>: The time at which point the user's <code>MAX_PRICE</code> is achieved. The transaction remains valid after this time at that price.</li> </ul> <p><strong>Proposal</strong></p> <p>For all blocks where <code>block.number &gt;= INITIAL_FORK_BLKNUM</code>:</p> <p>When processing a transaction with the new pricing parameters, miners now receive a fee based off of the following linear function, where <code>BLOCK</code> is the current block number:</p> <ul> <li>IF <code>BLOCK &gt; MAX_TIME</code> then <code>TX_FEE = MAX_PRICE</code>.</li> <li><code>TX_FEE = START_PRICE + ((MAX_PRICE - START_PRICE) / (MAX_TIME - START_TIME) * (BLOCK - START_TIME))</code></li> </ul> <p>As a JavaScript function:</p> <pre class="giallo z-code"><code data-lang="javascript"><span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> txFee</span><span> (</span><span class="z-variable">startTime</span><span>,</span><span class="z-variable"> startPrice</span><span>,</span><span class="z-variable"> maxTime</span><span>,</span><span class="z-variable"> maxPrice</span><span>,</span><span class="z-variable"> currentTime</span><span>)</span><span> {</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-other">currentTime</span><span class="z-keyword"> &gt;=</span><span class="z-variable z-other"> maxTime</span><span>)</span><span class="z-keyword"> return</span><span class="z-variable z-other"> maxPrice</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> priceRange</span><span class="z-keyword"> =</span><span class="z-variable z-other"> maxPrice</span><span class="z-keyword"> -</span><span class="z-variable z-other"> startPrice</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> blockRange</span><span class="z-keyword"> =</span><span class="z-variable z-other"> maxTime</span><span class="z-keyword"> -</span><span class="z-variable z-other"> startTime</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> slope</span><span class="z-keyword"> =</span><span class="z-variable z-other"> priceRange</span><span class="z-keyword"> /</span><span class="z-variable z-other"> blockRange</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-other"> startPrice</span><span class="z-keyword"> +</span><span> (</span><span class="z-variable z-other">slope</span><span class="z-keyword"> *</span><span> (</span><span class="z-variable z-other">currentTime</span><span class="z-keyword"> -</span><span class="z-variable z-other"> startTime</span><span>)</span><span>)</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Since a current <code>gasPrice</code> transaction is effectively a flat-escalated transaction bid, it is entirely compatible with this model, and so there is no concrete requirement to deprecate current transaction processing logic, allowing cold wallets and hardware wallets to continue working for the foreseeable future.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>The security considerations for this EIP are:</p> <ul> <li>None currently known.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-03-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/3322/ <h2 id="simple-summary">Simple Summary</h2> <p>Allows contract accounts to store gas that can be transferred to the refund counter.</p> <h2 id="abstract">Abstract</h2> <p>Contracts can persist gas for later transfer to the refund counter. Three opcodes are introduced to read, add to, and use this gas counter.</p> <h2 id="motivation">Motivation</h2> <p>The refund mechanism is currently being used by gas tokens to arbitrage gas price. This brings gas supply elasticity and price stability by moving gas from blocks with less demand to blocks with more demand. Unfortunately this rewards unnecessary state growth. By introducing a superior gas storage mechanism, the gas market will require less storage and computation.</p> <h2 id="specification">Specification</h2> <p>Contract accounts gain an unsigned gas refund counter, initially zero.</p> <p>Three new opcodes are introduced to manage this state.</p> <ul> <li><code>SELFGAS</code> (<code>0x49</code>): Pushes the current account's gas refund counter onto the stack. Shares gas pricing with <code>SELFBALANCE</code>.</li> <li><code>USEGAS</code> (<code>0x4a</code>): Pops <code>amount</code> from the stack. The minimum of <code>amount</code> and the current account's gas refund counter is transferred to the execution context's refund counter. Costs <code>5000</code> gas.</li> <li><code>STOREGAS</code> (<code>0x4b</code>): Pops <code>amount</code> from the stack. Costs <code>5000 + amount</code> gas. Increases the current account's gas refund counter by <code>amount</code>.</li> </ul> <h2 id="rationale">Rationale</h2> <p>By reusing the execution context's refund counter we can reuse its 50% DoS protection, which limits its block elasticity contribution to 2x.</p> <p>The gas costs are based on similar opcodes <code>SELFBALANCE</code> and <code>SSTORE</code>.</p> <p>Most accounts will store no gas, so the per-account storage overhead should be minimal or even zero in the normal case.</p> <p>The opcode numbers chosen are in the same <code>0x4X</code> range as <code>SELFBALANCE</code> and <code>GASLIMIT</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Because the gas is added to the refund counter, no compatibility issues are anticipated.</p> <h2 id="test-cases">Test Cases</h2> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>Final</th></tr></thead><tbody> <tr><td>0x60004900</td><td>5003</td><td>0</td><td>0</td><td>0</td></tr> <tr><td>0x60034900</td><td>5003</td><td>2</td><td>2</td><td>0</td></tr> <tr><td>0x60034900</td><td>5003</td><td>3</td><td>3</td><td>0</td></tr> <tr><td>0x60034900</td><td>5003</td><td>3</td><td>4</td><td>1</td></tr> <tr><td>0x60034960034900</td><td>10006</td><td>4</td><td>4</td><td>0</td></tr> <tr><td>0x60034960034900</td><td>10006</td><td>6</td><td>6</td><td>0</td></tr> <tr><td>0x484900</td><td>5010</td><td>100000</td><td>100000</td><td>0</td></tr> <tr><td>0x61ffff4a00</td><td>70538</td><td>0</td><td>0</td><td>65535</td></tr> </tbody></table> <h2 id="security-considerations">Security Considerations</h2> <p>DoS is already limited by the 50% refund limit.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Forshtatforshtat1@gmail.com https://wg-eips.ritovision.com/2542/ <h2 id="simple-summary">Simple Summary</h2> <p>A mechanism to allow smart contracts to access information on gas limits for the current transaction and execution frame.</p> <h2 id="abstract">Abstract</h2> <p>Currently, there is an existing opcode <code>0x45 GASLIMIT</code> that provides access to the block gas limit. While this information may be useful in some cases, it is probably not a value that smart contract developers may be concerned about. The opcode <code>0x5a GAS</code> provides the remaining gas, not the initial one. Also, it is worth noting how existing <code>0x32 ORIGIN</code>, <code>0x33 CALLER</code>, <code>0x34 CALLVALUE</code> and <code>0x3a GASPRICE</code> opcodes set a pattern of having access to both the transaction and current execution frame state. TBD: as 0x30 opcode range is exhausted, the proposed opcodes can be added to 0x50 range, or a new range can be added.</p> <h2 id="motivation">Motivation</h2> <p>As concepts of relaying, meta-transactions, gas fees, and account abstraction gain popularity, it becomes critical for some contracts to be able to track gas expenditure with absolute precision. Without access to this data on an EVM level, such contracts resort to approximation, mimicking EVM logic on-chain, and some use-cases even become infeasible.</p> <h2 id="specification">Specification</h2> <p>If block.number &gt;= TBD, add three new opcodes:</p> <p>TXGASLIMIT: 0x5c</p> <p>Pushes the gas limit of the entire transaction onto the stack. This is a value of the 'startgas' parameter signed by the externally owned account.<br /> Gas costs: 2 (same as <code>GASLIMIT</code>)</p> <p>CALLGASLIMIT: 0x5d</p> <p>Pushes the gas limit of the current execution frame onto the stack. This is the 'callGas' value that was obtained after the application of the EIP-150 “all but one 64th” rule.<br /> Gas costs: 2 (same as <code>GASLIMIT</code>)</p> <p>Also, consider renaming <code>0x45 GASLIMIT</code> to <code>BLOCKGASLIMIT</code> to avoid confusion.</p> <h2 id="rationale">Rationale</h2> <p>Consider a solidity smart contract that wants to know how much gas the entire transaction or a part of it had consumed. It is not entirely possible with the current EVM. With proposed changes, using a pseudo-Solidity syntax, this information would be easily available:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function keepTrackOfGas(string memory message, uint256 number) public {</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> uint gasUsed = msg.gasLimit - gasleft();</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>This is an extremely common use case, and multiple implementations suffer from not taking the non-accessible expenses into consideration. The state-of-the-art solution for the <code>gasUsed</code> problem is to access 'gasleft()' as the first line of your smart contract.<br /> Note how variable transaction input size means the gas used by the transaction depends on the number of zero and non-zero bytes of input, as well <code>GTXDATANONZERO</code>. Another issue is that Solidity handles <code>public</code> methods by loading the entire input from <code>calldata</code> to <code>memory</code>, spending an unpredictable amount of gas.</p> <p>Another application is for a method to have a requirement for a gas limit given to it. This situation arises quite commonly in the context of meta-transactions, where the msg.sender's account holder may not be too interested in the inner transaction's success. Exaggerated pseudocode:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>function verifyGasLimit(uint256 desiredGasLimit, bytes memory signature, address signer, bytes memory someOtherData) public {</span></span> <span class="giallo-l"><span> require(ecrecover(abi.encodePacked(desiredGasLimit, someOtherData), signature) == signer, &quot;Signature does not match&quot;);</span></span> <span class="giallo-l"><span> require(tx.gasLimit == desiredGasLimit, &quot;Transaction limit does not match the signed value. The signer did not authorize that.&quot;);</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>In this situation it is not possible to rely on 'gasleft()' value, because it is dynamic, depends on opcode and calldata pricing, and cannot be signed.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal introduces two new opcodes and renames an existing one, but stays fully backwards compatible apart from that.</p> <h2 id="forwards-compatibility">Forwards Compatibility</h2> <p>A major consideration for this proposal is its alignment with one or many possible future modifications to the EVM:</p> <ol> <li> <p>EIP-2489 Deprecate the GAS opcode (a.k.a. 39-UNGAS proposal)<br /> There is a sentiment that the ability of smart contracts to perform "gas introspection" leads to the contracts being dependent on current opcode pricing.<br /> While criticizing said misconception is beyond the scope of this EIP, in case there is a need to make a breaking change to the behavior of the existing <code>0x5a GAS</code> opcode, the same considerations will apply to the proposed opcodes. This means this EIP does not add any new restraints on EMV evolution.</p> </li> <li> <p>Stateless Ethereum<br /> The UNGAS proposal is said to be related to the ongoing project of Stateless Ethereum. It’s not strictly necessary for stateless Ethereum, but it is an idea for how to make future breaking changes to gas schedules easier.<br /> As long as the concept of 'gas limit' is part of the EVM, the author sees no reason proposed opcodes would conflict with Stateless Ethereum. Gas schedules are not exposed by this proposal.</p> </li> <li> <p>Comparison with other controversial opcodes<br /> There are opcodes that are not proposed for deprecation but face criticism. Examples include <code>0x32 ORIGIN</code> being misused by smart contract developers, or <code>0x46 CHAINID</code> making some smart-contracts 'unforkable'.<br /> This EIP neither encourages nor enables any bad security practices, and does not introduce any concepts that are new for EVM either.</p> </li> </ol> <h2 id="security-considerations">Security considerations</h2> <p>Existing smart contracts are not affected by this change.<br /> Smart contracts that will use proposed opcodes must not use them for the core of any security features, but only as a source of information about their execution environment.</p> <h2 id="implementation">Implementation</h2> <p>The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Vlasovhttps://github.com/shamatar hujw77https://github.com/hujw77 https://wg-eips.ritovision.com/2539/

Precompiles for BLS12-377 curve operations

<h2 id="abstract">Abstract</h2> <p>This precompile adds operation on BLS12-377 curve (from Zexe paper) as a precompile in a set necessary to <em>efficiently</em> perform operations such as BLS signature verification and perform SNARKs verifications. Unique properties of BLS12-377 also later allow to have SNARKs that check BLS12-377 pairing in an efficient way and allow e.g. constant-size BLS signature aggregation.</p> <p>If <code>block.number &gt;= X</code> we introduce <em>nine</em> separate precompiles to perform the following operations:</p> <ul> <li>BLS12_377_G1ADD - to perform point addition on a curve defined over prime field</li> <li>BLS12_377_G1MUL - to perform point multiplication on a curve defined over prime field</li> <li>BLS12_377_G1MULTIEXP - to perform multiexponentiation on a curve defined over prime field</li> <li>BLS12_377_G2ADD - to perform point addition on a curve twist defined over quadratic extension of the base field</li> <li>BLS12_377_G2MUL - to perform point multiplication on a curve twist defined over quadratic extension of the base field</li> <li>BLS12_377_G2MULTIEXP - to perform multiexponentiation on a curve twist defined over quadratic extension of the base field</li> <li>BLS12_377_PAIRING - to perform a pairing operations between a set of <em>pairs</em> of (G1, G2) points</li> <li>BLS12_377_MAP_FP_TO_G1 - maps base field element into the G1 point</li> <li>BLS12_377_MAP_FP2_TO_G2 - maps extension field element into the G2 point</li> </ul> <p>Multiexponentiation operation is included to efficiently aggregate public keys or individual signer's signatures during BLS signature verification.</p> <h3 id="proposed-addresses-table">Proposed addresses table</h3> <table><thead><tr><th>Precompile</th><th>Address</th></tr></thead><tbody> <tr><td>BLS12_377_G1ADD</td><td>0x15</td></tr> <tr><td>BLS12_377_G1MUL</td><td>0x16</td></tr> <tr><td>BLS12_377_G1MULTIEXP</td><td>0x17</td></tr> <tr><td>BLS12_377_G2ADD</td><td>0x18</td></tr> <tr><td>BLS12_377_G2MUL</td><td>0x19</td></tr> <tr><td>BLS12_377_G2MULTIEXP</td><td>0x1a</td></tr> <tr><td>BLS12_377_PAIRING</td><td>0x1b</td></tr> <tr><td>BLS12_377_MAP_FP_TO_G1</td><td>0x1c</td></tr> <tr><td>BLS12_377_MAP_FP2_TO_G2</td><td>0x1d</td></tr> </tbody></table> <h2 id="motivation">Motivation</h2> <p>Motivation of this precompile is to add a cryptographic primitive that allows to get 120+ bits of security for operations over pairing friendly curve compared to the existing BN254 precompile that only provides 80 bits of security. In addition it allows efficient one-time recursive proof aggregations, e.g. proofs about existence of BLS12-377 based signature.</p> <h2 id="specification">Specification</h2> <p>Curve parameters:</p> <p>BLS12-377 curve is fully defined by the following set of parameters (coefficient <code>A=0</code> for all BLS12 curves):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Base field modulus = 0x01ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508c00000000001</span></span> <span class="giallo-l"><span>B coefficient = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>Main subgroup order = 0x12ab655e9a2ca55660b44d1e5c37b00159aa76fed00000010a11800000000001</span></span> <span class="giallo-l"><span>Extension tower:</span></span> <span class="giallo-l"><span>Fp2 construction:</span></span> <span class="giallo-l"><span>Fp quadratic non-residue = 0x01ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508bffffffffffc</span></span> <span class="giallo-l"><span>Fp6/Fp12 construction:</span></span> <span class="giallo-l"><span>Fp2 cubic non-residue c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>Fp2 cubic non-residue c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>Twist parameters:</span></span> <span class="giallo-l"><span>Twist type: D</span></span> <span class="giallo-l"><span>B coefficient for twist c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>B coefficient for twist c1 = 0x010222f6db0fd6f343bd03737460c589dc7b4f91cd5fd889129207b63c6bf8000dd39e5c1ccccccd1c9ed9999999999a</span></span> <span class="giallo-l"><span>Generators:</span></span> <span class="giallo-l"><span>G1:</span></span> <span class="giallo-l"><span>X = 0x008848defe740a67c8fc6225bf87ff5485951e2caa9d41bb188282c8bd37cb5cd5481512ffcd394eeab9b16eb21be9ef</span></span> <span class="giallo-l"><span>Y = 0x01914a69c5102eff1f674f5d30afeec4bd7fb348ca3e52d96d182ad44fb82305c2fe3d3634a9591afd82de55559c8ea6</span></span> <span class="giallo-l"><span>G2:</span></span> <span class="giallo-l"><span>X c0 = 0x018480be71c785fec89630a2a3841d01c565f071203e50317ea501f557db6b9b71889f52bb53540274e3e48f7c005196</span></span> <span class="giallo-l"><span>X c1 = 0x00ea6040e700403170dc5a51b1b140d5532777ee6651cecbe7223ece0799c9de5cf89984bff76fe6b26bfefa6ea16afe</span></span> <span class="giallo-l"><span>Y c0 = 0x00690d665d446f7bd960736bcbb2efb4de03ed7274b49a58e458c282f832d204f2cf88886d8c7c2ef094094409fd4ddf</span></span> <span class="giallo-l"><span>Y c1 = 0x00f8169fd28355189e549da3151a70aa61ef11ac3d591bf12463b01acee304c24279b83f5e52270bd9a1cdd185eb8f93</span></span> <span class="giallo-l"><span>Pairing parameters:</span></span> <span class="giallo-l"><span>|x| (miller loop scalar) = 0x8508c00000000001</span></span> <span class="giallo-l"><span>x is negative = false</span></span></code></pre><h3 id="fine-points-and-encoding-of-base-elements">Fine points and encoding of base elements</h3> <h4 id="field-elements-encoding">Field elements encoding:</h4> <p>To encode points involved in the operation one has to encode elements of the base field and the extension field.</p> <p>Base field element (Fp) is encoded as <code>64</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer (top <code>16</code> bytes are always zeroes). <code>64</code> bytes are chosen to have <code>32</code> byte aligned ABI (representable as e.g. <code>bytes32[2]</code> or <code>uint256[2]</code>). Corresponding integer <strong>must</strong> be less than field modulus.</p> <p>For elements of the quadratic extension field (Fp2) encoding is byte concatenation of individual encoding of the coefficients totaling in <code>128</code> bytes for a total encoding. For an Fp2 element in a form <code>el = c0 + c1 * v</code> where <code>v</code> is formal quadratic non-residue and <code>c0</code> and <code>c1</code> are Fp elements the corresponding byte encoding will be <code>encode(c0) || encode(c1)</code> where <code>||</code> means byte concatenation (or one can use <code>bytes32[4]</code> or <code>uint256[4]</code> in terms of Solidity types).</p> <p>If encodings do not follow this spec anywhere during parsing in the precompile the precompile <em>must</em> return an error.</p> <h4 id="encoding-of-points-in-g1-g2">Encoding of points in G1/G2:</h4> <p>Points in either G1 (in base field) or in G2 (in extension field) are encoded as byte concatenation of encodings of the <code>x</code> and <code>y</code> affine coordinates. Total encoding length for G1 point is thus <code>128</code> bytes and for G2 point is <code>256</code> bytes.</p> <h4 id="point-of-infinity-encoding">Point of infinity encoding:</h4> <p>Also referred as "zero point". For BLS12 curves point with coordinates <code>(0, 0)</code> (formal zeroes in Fp or Fp2) is <em>not</em> on the curve, so encoding of such point <code>(0, 0)</code> is used as a convention to encode point of infinity.</p> <h4 id="encoding-of-scalars-for-multiplication-operation">Encoding of scalars for multiplication operation:</h4> <p>Scalar for multiplication operation is encoded as <code>32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. Corresponding integer is <strong>not</strong> required to be less than or equal than main subgroup size.</p> <h3 id="abi-for-operations">ABI for operations</h3> <h4 id="abi-for-g1-addition">ABI for G1 addition</h4> <p>G1 addition call expects <code>256</code> bytes as an input that is interpreted as byte concatenation of two G1 points (<code>128</code> bytes each). Output is an encoding of addition operation result - single G1 point (<code>128</code> bytes).</p> <p>Error cases:</p> <ul> <li>Either of points being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g1-multiplication">ABI for G1 multiplication</h4> <p>G1 multiplication call expects <code>160</code> bytes as an input that is interpreted as byte concatenation of encoding of G1 point (<code>128</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of multiplication operation result - single G1 point (<code>128</code> bytes).</p> <p>Error cases:</p> <ul> <li>Point being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g1-multiexponentiation">ABI for G1 multiexponentiation</h4> <p>G1 multiexponentiation call expects <code>160*k</code> bytes as an input that is interpreted as byte concatenation of <code>k</code> slices each of them being a byte concatenation of encoding of G1 point (<code>128</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of multiexponentiation operation result - single G1 point (<code>128</code> bytes).</p> <p>Error cases:</p> <ul> <li>Any of G1 points being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g2-addition">ABI for G2 addition</h4> <p>G2 addition call expects <code>512</code> bytes as an input that is interpreted as byte concatenation of two G2 points (<code>256</code> bytes each). Output is an encoding of addition operation result - single G2 point (<code>256</code> bytes).</p> <p>Error cases:</p> <ul> <li>Either of points being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g2-multiplication">ABI for G2 multiplication</h4> <p>G2 multiplication call expects <code>288</code> bytes as an input that is interpreted as byte concatenation of encoding of G2 point (<code>256</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of multiplication operation result - single G2 point (<code>256</code> bytes).</p> <p>Error cases:</p> <ul> <li>Point being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g2-multiexponentiation">ABI for G2 multiexponentiation</h4> <p>G2 multiexponentiation call expects <code>288*k</code> bytes as an input that is interpreted as byte concatenation of <code>k</code> slices each of them being a byte concatenation of encoding of G2 point (<code>256</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of multiexponentiation operation result - single G2 point (<code>256</code> bytes).</p> <p>Error cases:</p> <ul> <li>Any of G2 points being not on the curve must result in error</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-pairing">ABI for pairing</h4> <p>Pairing call expects <code>384*k</code> bytes as an inputs that is interpreted as byte concatenation of <code>k</code> slices. Each slice has the following structure:</p> <ul> <li><code>128</code> bytes of G1 point encoding</li> <li><code>256</code> bytes of G2 point encoding</li> </ul> <p>Output is a <code>32</code> bytes where first <code>31</code> bytes are equal to <code>0x00</code> and the last byte is <code>0x01</code> if pairing result is equal to multiplicative identity in a pairing target field and <code>0x00</code> otherwise.</p> <p>Error cases:</p> <ul> <li>Invalid encoding of any boolean variable must result in error</li> <li>Any of G1 or G2 points being not on the curve must result in error</li> <li>Any of G1 or G2 points are not in the correct subgroup</li> <li>Field elements encoding rules apply (obviously)</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-mapping-fp-element-to-g1-point">ABI for mapping Fp element to G1 point</h4> <p>Field-to-curve call expects <code>64</code> bytes as input that is interpreted as an element of the base field. Output of this call is <code>128</code> bytes and is G1 point following respective encoding rules.</p> <p>Error cases:</p> <ul> <li>Input has invalid length</li> <li>Input is not a valid field element</li> </ul> <h4 id="abi-for-mapping-fp2-element-to-g2-point">ABI for mapping Fp2 element to G2 point</h4> <p>Field-to-curve call expects <code>128</code> bytes as input that is interpreted as an element of the quadratic extension field. Output of this call is <code>256</code> bytes and is G2 point following respective encoding rules.</p> <p>Error cases:</p> <ul> <li>Input has invalid length</li> <li>Input is not a valid field element</li> </ul> <h3 id="prevention-of-ddos-on-error-handling">Prevention of DDoS on error handling</h3> <p>This precompile performs extensive computations and in case of any errors during execution it MUST consume all gas from the gas schedule for the corresponding operation.</p> <h3 id="gas-schedule">Gas schedule</h3> <p>Assuming a constant <code>30 MGas/second</code> following prices are suggested.</p> <h4 id="g1-addition">G1 addition</h4> <p><code>600</code> gas</p> <h4 id="g1-multiplication">G1 multiplication</h4> <p><code>12000</code> gas</p> <h4 id="g2-addition">G2 addition</h4> <p><code>4500</code> gas</p> <h4 id="g2-multiplication">G2 multiplication</h4> <p><code>55000</code> gas</p> <h4 id="g1-g2-multiexponentiation">G1/G2 Multiexponentiation</h4> <p>Multiexponentiations are expected to be performed by the Peppinger algorithm (we can also say that it <strong>must</strong> be performed by Peppinger algorithm to have a speedup that results in a discount over naive implementation by multiplying each pair separately and adding the results). For this case there was a table prepared for discount in case of <code>k &lt;= 128</code> points in the multiexponentiation with a discount cap <code>max_discount</code> for <code>k &gt; 128</code>.</p> <p>To avoid non-integer arithmetic call cost is calculated as <code>k * multiplication_cost * discount / multiplier</code> where <code>multiplier = 1000</code>, <code>k</code> is a number of (scalar, point) pairs for the call, <code>multiplication_cost</code> is a corresponding single multiplication call cost for G1/G2.</p> <p>Discounts table as a vector of pairs <code>[k, discount]</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[[1, 1200], [2, 888], [3, 764], [4, 641], [5, 594], [6, 547], [7, 500], [8, 453], [9, 438], [10, 423], [11, 408], [12, 394], [13, 379], [14, 364], [15, 349], [16, 334], [17, 330], [18, 326], [19, 322], [20, 318], [21, 314], [22, 310], [23, 306], [24, 302], [25, 298], [26, 294], [27, 289], [28, 285], [29, 281], [30, 277], [31, 273], [32, 269], [33, 268], [34, 266], [35, 265], [36, 263], [37, 262], [38, 260], [39, 259], [40, 257], [41, 256], [42, 254], [43, 253], [44, 251], [45, 250], [46, 248], [47, 247], [48, 245], [49, 244], [50, 242], [51, 241], [52, 239], [53, 238], [54, 236], [55, 235], [56, 233], [57, 232], [58, 231], [59, 229], [60, 228], [61, 226], [62, 225], [63, 223], [64, 222], [65, 221], [66, 220], [67, 219], [68, 219], [69, 218], [70, 217], [71, 216], [72, 216], [73, 215], [74, 214], [75, 213], [76, 213], [77, 212], [78, 211], [79, 211], [80, 210], [81, 209], [82, 208], [83, 208], [84, 207], [85, 206], [86, 205], [87, 205], [88, 204], [89, 203], [90, 202], [91, 202], [92, 201], [93, 200], [94, 199], [95, 199], [96, 198], [97, 197], [98, 196], [99, 196], [100, 195], [101, 194], [102, 193], [103, 193], [104, 192], [105, 191], [106, 191], [107, 190], [108, 189], [109, 188], [110, 188], [111, 187], [112, 186], [113, 185], [114, 185], [115, 184], [116, 183], [117, 182], [118, 182], [119, 181], [120, 180], [121, 179], [122, 179], [123, 178], [124, 177], [125, 176], [126, 176], [127, 175], [128, 174]]</span></span></code></pre> <p><code>max_discount = 174</code></p> <h4 id="pairing-operation">Pairing operation</h4> <p>Cost of the pairing operation is <code>55000*k + 65000</code> where <code>k</code> is a number of pairs.</p> <h4 id="fp-to-g1-mapping-operation">Fp-to-G1 mapping operation</h4> <p>Fp -&gt; G1 mapping is <code>5500</code> gas.</p> <h4 id="fp2-to-g2-mapping-operation">Fp2-to-G2 mapping operation</h4> <p>Fp2 -&gt; G2 mapping is <code>75000</code> gas</p> <h2 id="rationale">Rationale</h2> <p>Motivation section covers a total motivation to have operations over BLS12-377 curve available. We also extend a rationale for move specific fine points.</p> <h3 id="multiexponentiation-as-a-separate-call">Multiexponentiation as a separate call</h3> <p>Explicit separate multiexponentiation operation that allows one to save execution time (so gas) by both the algorithm used (namely Peppinger algorithm) and (usually forgotten) by the fact that <code>CALL</code> operation in Ethereum is expensive (at the time of writing), so one would have to pay non-negigible overhead if e.g. for multiexponentiation of <code>100</code> points would have to call the multipication precompile <code>100</code> times and addition for <code>99</code> times (roughly <code>138600</code> would be saved).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backward compatibility questions.</p> <h3 id="important-notes">Important notes</h3> <h4 id="subgroup-checks">Subgroup checks</h4> <p>Subgroup check <strong>is mandatory</strong> during the pairing call. Implementations <em>should</em> use fast subgroup checks: at the time of writing multiplication gas cost is based on <code>double-and-add</code> multiplication method that has a clear "worst case" (all bits are equal to one). For pairing operation it's expected that implementation uses faster subgroup check, e.g. by using wNAF multiplication method for elliptic curves that is ~ <code>40%</code> cheaper with windows size equal to 4. (Tested empirically. Savings are due to lower hamming weight of the group order and even lower hamming weight for wNAF. Concretely, subgroup check for both G1 and G2 points in a pair are around <code>35000</code> combined).</p> <h2 id="test-cases">Test Cases</h2> <p>Due to the large test parameters space we first provide properties that various operations must satisfy. We use additive notation for point operations, capital letters (<code>P</code>, <code>Q</code>) for points, small letters (<code>a</code>, <code>b</code>) for scalars. Generator for G1 is labeled as <code>G</code>, generator for G2 is labeled as <code>H</code>, otherwise we assume random point on a curve in a correct subgroup. <code>0</code> means either scalar zero or point of infinity. <code>1</code> means either scalar one or multiplicative identity. <code>group_order</code> is a main subgroup order. <code>e(P, Q)</code> means pairing operation where <code>P</code> is in G1, <code>Q</code> is in G2.</p> <p>Requeired properties for basic ops (add/multiply):</p> <ul> <li>Commutativity: <code>P + Q = Q + P</code></li> <li>Additive negation: <code>P + (-P) = 0</code></li> <li>Doubling <code>P + P = 2*P</code></li> <li>Subgroup check: <code>group_order * P = 0</code></li> <li>Trivial multiplication check: <code>1 * P = P</code></li> <li>Multiplication by zero: <code>0 * P = 0</code></li> <li>Multiplication by the unnormalized scalar <code>(scalar + group_order) * P = scalar * P</code></li> </ul> <p>Required properties for pairing operation:</p> <ul> <li>Degeneracy <code>e(P, 0*Q) = e(0*P, Q) = 1</code></li> <li>Bilinearity <code>e(a*P, b*Q) = e(a*b*P, Q) = e(P, a*b*Q)</code> (internal test, not visible through ABI)</li> </ul> <p>Test vector for all operations are expanded in this <code>csv</code> files in matter-labs' 1962 proposol.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>There is a various choice of existing implementations of the curve operations. It may require extra work to add an ABI:</p> <ul> <li>Code bases with fixed parameters</li> <li>Rust: matter-labs</li> <li>C++: matter-labs</li> <li>Original implementation linked in Zexe paper in Rust: github.com/scipr-lab/zexe</li> <li>Standalone in Go: github.com/kilic/bls12-377</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Strictly following the spec will eliminate security implications or consensus implications in a contrast to the previous BN254 precompile.</p> <p>Important topic is a "constant time" property for performed operations. We explicitly state that this precompile <strong>IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 William Morrisshttps://github.com/wjmelements https://wg-eips.ritovision.com/3300/ <h2 id="simple-summary">Simple Summary</h2> <p>Phases out the <code>SSTORE</code> and <code>SELFDESTRUCT</code> gas refunds.</p> <h2 id="abstract">Abstract</h2> <p>This EIP would define a block when the <code>SSTORE</code> and <code>SELFDESTRUCT</code> refunds would begin to diminish. The refund would step linearly downward, eroding the implicit value of such refunds at an accelerating pace.</p> <h2 id="motivation">Motivation</h2> <p>Refunds increase block elasticity, so the block gas target can exceed the number established by miners by up to 2x. This can cause hesitancy for miners to increase the block gas target.</p> <p>Refunds, tokenized or not, are valuable to their holders, especially during congestion. If refunds must be removed, a gradual change in their value would be less-disruptive to the gas market than sudden abolition. Refund consumption would proceed, especially during periods of congestion, and the refunds would be cleaned up from the state. Refund creation, driven by demand, would naturally diminish as the efficiency of the refunds fall. As the refund value approaches the activation cost, the implicit value of the refunds will approach zero, but in periods of congestion they will be cleaned up.</p> <p>This change is less work for the protocol developers than compensation and cleanup, while likely still achieving cleanup.</p> <h2 id="specification">Specification</h2> <p>Parameters:</p> <ul> <li><code>FORK_BLOCK_NUM</code>: EIP-3300 activation block</li> <li><code>REFUND_DECAY_STEP</code>: 1 gas</li> <li><code>REFUND_DECAY_FREQUENCY</code>: 100 blocks</li> </ul> <p>Computed:</p> <ul> <li><code>REFUND_DECAY</code>: <code>REFUND_DECAY_STEP * ceil((block.number + 1 - FORK_BLOCK_NUM) / REFUND_DECAY_FREQUENCY)</code></li> </ul> <p>On the block this EIP activates, and again every <code>REFUND_DECAY_FREQUENCY</code> blocks, all gas refunds, including <code>SELFDESTRUCT</code> and <code>SSTORE</code> would diminish by <code>REFUND_DECAY_STEP</code>, until 0. The current difference is called the <code>REFUND_DECAY</code>, which shall be subtracted from each gas refund.</p> <p>For gas-cost regimes with refund removals that cancel prior refunds, the invariant that the refund counter cannot go negative will be preserved by diminishing the magnitude of those removals by <code>REFUND_DECAY</code>, until 0.</p> <h3 id="eip-2929">EIP-2929</h3> <p>The refunds as of EIP-2929 are as follows:</p> <ul> <li>24000 for SELFDESTRUCT</li> <li><code>SSTORE_RESET_GAS - SLOAD_GAS</code> (5000 - 100)</li> <li><code>SSTORE_SET_GAS - SLOAD_GAS</code> (20000 - 100)</li> <li><code>SSTORE_SET_GAS - SLOAD_GAS</code> (20000 - 100)</li> <li><code>SSTORE_CLEARS_SCHEDULE</code> (15000)</li> </ul> <p>Each of these refunds would be decreased by the current <code>REFUND_DECAY</code>.</p> <p>There is also a case where <code>SSTORE_CLEARS_SCHEDULE</code> is removed from the refund counter. That removal will also diminish by <code>REFUND_DECAY_STEP</code> until 0, maintaining the non-negative refund counter invariant.</p> <h2 id="rationale">Rationale</h2> <p>Persisted refunds would become worthless before they fall below their activation cost. Once the refunds are worthless, they can be removed by another hard fork without waiting for 0. The rate of diminishing specified would currently require (24000-5000) * 100 = 1,900,000 blocks for <code>SELFDESTRUCT</code> and (15000-5000) * 100 = 1,000,000 blocks for <code>SSTORE</code>. This timeframe is currently about a year, which should be enough flexibility for the remaining refunds to be consumed.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal breaks gas refunds, which contribute to block elasticity. The effect of this will be increased gas price volatility: higher highs and lower lows.</p> <p>Because the refund counter is separate from the gas counter, the block-to-block gas changes will not break <code>eth_estimateGas</code>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Vlasovhttps://github.com/shamatar Kelly Olsonhttps://github.com/ineffectualproperty Alex Stokeshttps://github.com/ralexstokes Antonio Sansohttps://github.com/asanso https://wg-eips.ritovision.com/2537/

Adds operation on BLS12-381 curve as a precompile in a set necessary to efficiently perform operations such as BLS signature verification.

<h2 id="abstract">Abstract</h2> <p>Add functionality to efficiently perform operations over the BLS12-381 curve, including those for BLS signature verification.</p> <p>Along with the curve arithmetic, multi-scalar-multiplication operations are included to efficiently aggregate public keys or individual signer's signatures during BLS signature verification.</p> <h2 id="motivation">Motivation</h2> <p>The motivation of this precompile is to add a cryptographic primitive that allows to get 120+ bits of security for operations over pairing friendly curve compared to the existing BN254 precompile that only provides 80 bits of security.</p> <h2 id="specification">Specification</h2> <h3 id="constants">Constants</h3> <table><thead><tr><th>Name</th><th>Value</th><th>Comment</th></tr></thead><tbody> <tr><td>BLS12_G1ADD</td><td>0x0b</td><td>precompile address</td></tr> <tr><td>BLS12_G1MSM</td><td>0x0c</td><td>precompile address</td></tr> <tr><td>BLS12_G2ADD</td><td>0x0d</td><td>precompile address</td></tr> <tr><td>BLS12_G2MSM</td><td>0x0e</td><td>precompile address</td></tr> <tr><td>BLS12_PAIRING_CHECK</td><td>0x0f</td><td>precompile address</td></tr> <tr><td>BLS12_MAP_FP_TO_G1</td><td>0x10</td><td>precompile address</td></tr> <tr><td>BLS12_MAP_FP2_TO_G2</td><td>0x11</td><td>precompile address</td></tr> </tbody></table> <p>We introduce <em>seven</em> separate precompiles to perform the following operations:</p> <ul> <li>BLS12_G1ADD - to perform point addition in G1 (curve over base prime field) with a gas cost of <code>375</code> gas</li> <li>BLS12_G1MSM - to perform multi-scalar-multiplication (MSM) in G1 (curve over base prime field) with a gas cost formula defined in the corresponding section</li> <li>BLS12_G2ADD - to perform point addition in G2 (curve over quadratic extension of the base prime field) with a gas cost of <code>600</code> gas</li> <li>BLS12_G2MSM - to perform multi-scalar-multiplication (MSM) in G2 (curve over quadratic extension of the base prime field) with a gas cost formula defined in the corresponding section</li> <li>BLS12_PAIRING_CHECK - to perform a pairing operations between a set of <em>pairs</em> of (G1, G2) points a gas cost formula defined in the corresponding section</li> <li>BLS12_MAP_FP_TO_G1 - maps base field element into the G1 point with a gas cost of <code>5500</code> gas</li> <li>BLS12_MAP_FP2_TO_G2 - maps extension field element into the G2 point with a gas cost of <code>23800</code> gas</li> </ul> <p>A mapping functions specification is included as a separate <a href="https://wg-eips.ritovision.com/2537/assets/field_to_curve/">document</a>. This mapping function does NOT perform mapping of the byte string into a field element (as it can be implemented in many different ways and can be efficiently performed in EVM), but only does field arithmetic to map a field element into a curve point. Such functionality is required for signature schemes.</p> <h3 id="curve-parameters">Curve parameters</h3> <p>The BLS12 curve is fully defined by the following set of parameters (coefficient <code>A=0</code> for all BLS12 curves):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Base field modulus = p = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab</span></span> <span class="giallo-l"><span>Fp - finite field of size p</span></span> <span class="giallo-l"><span>Curve Fp equation: Y^2 = X^3+B (mod p)</span></span> <span class="giallo-l"><span>B coefficient = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004</span></span> <span class="giallo-l"><span>Main subgroup order = q = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001</span></span> <span class="giallo-l"><span>Extension tower</span></span> <span class="giallo-l"><span>Fp2 construction:</span></span> <span class="giallo-l"><span>Fp quadratic non-residue = nr2 = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaaa</span></span> <span class="giallo-l"><span>Fp2 is Fp[X]/(X^2-nr2)</span></span> <span class="giallo-l"><span>Curve Fp2 equation: Y^2 = X^3 + B*(v+1) where v is the square root of nr2</span></span> <span class="giallo-l"><span>Fp6/Fp12 construction:</span></span> <span class="giallo-l"><span>Fp2 cubic non-residue c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>Fp2 cubic non-residue c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>Twist parameters:</span></span> <span class="giallo-l"><span>Twist type: M</span></span> <span class="giallo-l"><span>B coefficient for twist c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004</span></span> <span class="giallo-l"><span>B coefficient for twist c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004</span></span> <span class="giallo-l"><span>Generators:</span></span> <span class="giallo-l"><span>H1:</span></span> <span class="giallo-l"><span>X = 0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb</span></span> <span class="giallo-l"><span>Y = 0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1</span></span> <span class="giallo-l"><span>H2:</span></span> <span class="giallo-l"><span>X c0 = 0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8</span></span> <span class="giallo-l"><span>X c1 = 0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e</span></span> <span class="giallo-l"><span>Y c0 = 0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801</span></span> <span class="giallo-l"><span>Y c1 = 0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be</span></span> <span class="giallo-l"><span>Pairing parameters:</span></span> <span class="giallo-l"><span>|x| (miller loop scalar) = 0xd201000000010000</span></span> <span class="giallo-l"><span>x is negative = true</span></span></code></pre> <p>One should note that base field modulus <code>p</code> is equal to <code>3 mod 4</code> that allows an efficient square root extraction, although as described below gas cost of decompression is larger than gas cost of supplying decompressed point data in <code>calldata</code>.</p> <h3 id="fields-and-groups">Fields and Groups</h3> <p>Field Fp is defined as the finite field of size <code>p</code> with elements represented as integers between 0 and p-1 (both inclusive).</p> <p>Field Fp2 is defined as <code>Fp[X]/(X^2-nr2)</code> with elements <code>el = c0 + c1 * v</code>, where <code>v</code> is the formal square root of <code>nr2</code> represented as integer pairs <code>(c0,c1)</code>.</p> <p>Group G1 is defined as a set of Fp pairs (points) <code>(x,y)</code> such that either <code>(x,y)</code> is <code>(0,0)</code> or <code>x,y</code> satisfy the curve Fp equation.</p> <p>Group G2 is defined as a set of Fp2 pairs (points) <code>(x',y')</code> such that either <code>(x,y)</code> is <code>(0,0)</code> or <code>(x',y')</code> satisfy the curve Fp2 equation.</p> <h3 id="fine-points-and-encoding-of-base-elements">Fine points and encoding of base elements</h3> <h4 id="field-elements-encoding">Field elements encoding:</h4> <p>In order to produce inputs to an operation, one encodes elements of the base field and the extension field.</p> <p>A base field element (Fp) is encoded as <code>64</code> bytes by performing the BigEndian encoding of the corresponding (unsigned) integer. Due to the size of <code>p</code>, the top <code>16</code> bytes are always zeroes. <code>64</code> bytes are chosen to have <code>32</code> byte aligned ABI (representable as e.g. <code>bytes32[2]</code> or <code>uint256[2]</code> with the latter assuming the BigEndian encoding). The corresponding integer <strong>must</strong> be less than field modulus.</p> <p>For elements of the quadratic extension field (Fp2), encoding is byte concatenation of individual encoding of the coefficients totaling in <code>128</code> bytes for a total encoding. For an Fp2 element in a form <code>el = c0 + c1 * v</code> where <code>v</code> is the formal square root of a quadratic non-residue and <code>c0</code> and <code>c1</code> are Fp elements the corresponding byte encoding will be <code>encode(c0) || encode(c1)</code> where <code>||</code> means byte concatenation (or one can use <code>bytes32[4]</code> or <code>uint256[4]</code> in terms of Solidity types).</p> <p><em>Note on the top <code>16</code> bytes being zero</em>: it is required that an encoded element is "in a field", which means strictly <code>&lt; modulus</code>. In BigEndian encoding it automatically means that for a modulus that is just <code>381</code> bit long the top <code>16</code> bytes in <code>64</code> bytes encoding are zeroes and this <strong>must</strong> be checked even if only a subslice of input data is used for actual decoding.</p> <p>On inputs that can not be a valid encodings of field elements the precompile <em>must</em> return an error.</p> <h4 id="encoding-of-points-in-g1-g2">Encoding of points in G1/G2:</h4> <p>Points of G1 and G2 are encoded as byte concatenation of the respective encodings of the <code>x</code> and <code>y</code> coordinates. Total encoding length for a G1 point is thus <code>128</code> bytes and for a G2 point is <code>256</code> bytes.</p> <h4 id="point-of-infinity-encoding">Point of infinity encoding:</h4> <p>Also referred to as the "zero point". For BLS12 curves, the point with coordinates <code>(0, 0)</code> (zeroes in Fp or Fp2) is <em>not</em> on the curve, so a sequence of <code>128</code> resp. <code>256</code> zero bytes, which naively would decode as <code>(0, 0)</code> is instead used by convention to encode the point of infinity of G1 resp. G2.</p> <h4 id="encoding-of-scalars-for-multiplication-operation">Encoding of scalars for multiplication operation:</h4> <p>A scalar for the multiplication operation is encoded as <code>32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer is <strong>not</strong> required to be less than or equal to main subgroup order <code>q</code>.</p> <h4 id="behavior-on-empty-inputs">Behavior on empty inputs:</h4> <p>Certain operations have variable length input, such as MSMs (takes a list of pairs <code>(point, scalar)</code>), or pairing (takes a list of <code>(G1, G2)</code> points). While their behavior is well-defined (from an arithmetic perspective) on empty inputs, this EIP discourages such use cases and variable input length operations must return an error if the input is empty.</p> <h3 id="abi-for-operations">ABI for operations</h3> <h4 id="abi-for-g1-addition">ABI for G1 addition</h4> <p>G1 addition call expects <code>256</code> bytes as an input that is interpreted as byte concatenation of two G1 points (<code>128</code> bytes each). Output is an encoding of addition operation result - single G1 point (<code>128</code> bytes).</p> <p>Error cases:</p> <ul> <li>Invalid coordinate encoding</li> <li>An input is neither a point on the G1 elliptic curve nor the infinity point</li> <li>Input has invalid length</li> </ul> <p>Note:</p> <p>There is no subgroup check for the G1 addition precompile.</p> <h4 id="abi-for-g1-msm">ABI for G1 MSM</h4> <p>G1 MSM call expects <code>160*k</code> (<code>k</code> being a <strong>positive</strong> integer) bytes as an input that is interpreted as byte concatenation of <code>k</code> slices each of them being a byte concatenation of encoding of a G1 point (<code>128</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of MSM operation result - a single G1 point (<code>128</code> bytes).</p> <p>Error cases:</p> <ul> <li>Invalid coordinate encoding</li> <li>An input is neither a point on the G1 elliptic curve nor the infinity point</li> <li>An input is on the G1 elliptic curve but not in the correct subgroup</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-g2-addition">ABI for G2 addition</h4> <p>G2 addition call expects <code>512</code> bytes as an input that is interpreted as byte concatenation of two G2 points (<code>256</code> bytes each). Output is an encoding of addition operation result - a single G2 point (<code>256</code> bytes).</p> <p>Error cases:</p> <ul> <li>Invalid coordinate encoding</li> <li>An input is neither a point on the G2 elliptic curve nor the infinity point</li> <li>Input has invalid length</li> </ul> <p>Note:</p> <p>There is no subgroup check for the G2 addition precompile.</p> <h4 id="abi-for-g2-msm">ABI for G2 MSM</h4> <p>G2 MSM call expects <code>288*k</code> (<code>k</code> being a <strong>positive</strong> integer) bytes as an input that is interpreted as byte concatenation of <code>k</code> slices each of them being a byte concatenation of encoding of G2 point (<code>256</code> bytes) and encoding of a scalar value (<code>32</code> bytes). Output is an encoding of MSM operation result - a single G2 point (<code>256</code> bytes).</p> <p>Error cases:</p> <ul> <li>Invalid coordinate encoding</li> <li>An input is neither a point on the G2 elliptic curve nor the infinity point</li> <li>An input is on the G2 elliptic curve but not in the correct subgroup</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-pairing-check">ABI for pairing check</h4> <p>Pairing check call expects <code>384*k</code> (<code>k</code> being a <strong>positive</strong> integer) bytes as an inputs that is interpreted as byte concatenation of <code>k</code> slices. Each slice has the following structure:</p> <ul> <li><code>128</code> bytes of G1 point encoding</li> <li><code>256</code> bytes of G2 point encoding</li> </ul> <p>Each point is expected to be in the subgroup of order <code>q</code>.</p> <p>It checks the equation <code>e(P1, Q1) * e(P2, Q2) * ... * e(Pk, Qk) == 1</code> in the pairing target field where <code>e</code> is the pairing operation. Output is <code>32</code> bytes where first <code>31</code> bytes are equal to <code>0x00</code> and the last byte is either <code>0x00</code> (false) or <code>0x01</code> (true).</p> <p>Error cases:</p> <ul> <li>Invalid coordinate encoding</li> <li>An input is neither a point on its respective elliptic curve nor the infinity point</li> <li>An input is on its respective elliptic curve but not in the correct subgroup</li> <li>Input has invalid length</li> </ul> <h4 id="abi-for-mapping-fp-element-to-g1-point">ABI for mapping Fp element to G1 point</h4> <p>Field-to-curve call expects <code>64</code> bytes as an input that is interpreted as an element of Fp. Output of this call is <code>128</code> bytes and is an encoded G1 point.</p> <p>Error cases:</p> <ul> <li>Input has invalid length</li> <li>Input is not correctly encoded</li> </ul> <h4 id="abi-for-mapping-fp2-element-to-g2-point">ABI for mapping Fp2 element to G2 point</h4> <p>Field-to-curve call expects <code>128</code> bytes as an input that is interpreted as an element of Fp2. Output of this call is <code>256</code> bytes and is an encoded G2 point.</p> <p>Error cases:</p> <ul> <li>Input has invalid length</li> <li>Input is not correctly encoded</li> </ul> <h3 id="gas-burning-on-error">Gas burning on error</h3> <p>Following the current state of all other precompiles, if a call to one of the precompiles in this EIP results in an error then all the gas supplied along with a <code>CALL</code> or <code>STATICCALL</code> is burned.</p> <h3 id="ddos-protection">DDoS protection</h3> <p>A sane implementation of this EIP <em>should not</em> contain potential infinite loops (it is possible and not even hard to implement all the functionality without <code>while</code> loops) and the gas schedule accurately reflects the time spent on computations of the corresponding function (precompiles pricing reflects an amount of gas consumed in the worst case where such a case exists).</p> <h3 id="gas-schedule">Gas schedule</h3> <p>Assuming <code>EcRecover</code> precompile as a baseline.</p> <h4 id="g1-addition">G1 addition</h4> <p><code>375</code> gas</p> <h4 id="g1-multiplication">G1 multiplication</h4> <p><code>12000</code> gas</p> <h4 id="g2-addition">G2 addition</h4> <p><code>600</code> gas</p> <h4 id="g2-multiplication">G2 multiplication</h4> <p><code>22500</code> gas</p> <h4 id="g1-g2-msm">G1/G2 MSM</h4> <p>MSMs are expected to be performed by Pippenger's algorithm (we can also say that it <strong>must</strong> be performed by Pippenger's algorithm to have a speedup that results in a discount over naive implementation by multiplying each pair separately and adding the results). For this case there was a table prepared for discount in case of <code>k &lt;= 128</code> points in the MSM with a discount cap <code>max_discount</code> for <code>k &gt; 128</code>.</p> <p>The call cost is calculated as <code>(k * multiplication_cost * discount) // multiplier</code> where <code>multiplier = 1000</code>, <code>k</code> is a number of (scalar, point) pairs for the call, <code>multiplication_cost</code> is a corresponding G1/G2 multiplication cost presented above and <code>//</code> is an integer division.</p> <p>G1 and G2 are priced separately, each having their own discount table and <code>max_discount</code>.</p> <h5 id="g1-discounts">G1 discounts</h5> <p>Discounts table for G1 MSM as a vector of pairs <code>[k, discount]</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[[1, 1000], [2, 949], [3, 848], [4, 797], [5, 764], [6, 750], [7, 738], [8, 728], [9, 719], [10, 712], [11, 705], [12, 698], [13, 692], [14, 687], [15, 682], [16, 677], [17, 673], [18, 669], [19, 665], [20, 661], [21, 658], [22, 654], [23, 651], [24, 648], [25, 645], [26, 642], [27, 640], [28, 637], [29, 635], [30, 632], [31, 630], [32, 627], [33, 625], [34, 623], [35, 621], [36, 619], [37, 617], [38, 615], [39, 613], [40, 611], [41, 609], [42, 608], [43, 606], [44, 604], [45, 603], [46, 601], [47, 599], [48, 598], [49, 596], [50, 595], [51, 593], [52, 592], [53, 591], [54, 589], [55, 588], [56, 586], [57, 585], [58, 584], [59, 582], [60, 581], [61, 580], [62, 579], [63, 577], [64, 576], [65, 575], [66, 574], [67, 573], [68, 572], [69, 570], [70, 569], [71, 568], [72, 567], [73, 566], [74, 565], [75, 564], [76, 563], [77, 562], [78, 561], [79, 560], [80, 559], [81, 558], [82, 557], [83, 556], [84, 555], [85, 554], [86, 553], [87, 552], [88, 551], [89, 550], [90, 549], [91, 548], [92, 547], [93, 547], [94, 546], [95, 545], [96, 544], [97, 543], [98, 542], [99, 541], [100, 540], [101, 540], [102, 539], [103, 538], [104, 537], [105, 536], [106, 536], [107, 535], [108, 534], [109, 533], [110, 532], [111, 532], [112, 531], [113, 530], [114, 529], [115, 528], [116, 528], [117, 527], [118, 526], [119, 525], [120, 525], [121, 524], [122, 523], [123, 522], [124, 522], [125, 521], [126, 520], [127, 520], [128, 519]]</span></span></code></pre> <p><code>max_discount = 519</code></p> <h5 id="g2-discounts">G2 discounts</h5> <p>Discounts table for G2 MSM as a vector of pairs <code>[k, discount]</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[[1, 1000], [2, 1000], [3, 923], [4, 884], [5, 855], [6, 832], [7, 812], [8, 796], [9, 782], [10, 770], [11, 759], [12, 749], [13, 740], [14, 732], [15, 724], [16, 717], [17, 711], [18, 704], [19, 699], [20, 693], [21, 688], [22, 683], [23, 679], [24, 674], [25, 670], [26, 666], [27, 663], [28, 659], [29, 655], [30, 652], [31, 649], [32, 646], [33, 643], [34, 640], [35, 637], [36, 634], [37, 632], [38, 629], [39, 627], [40, 624], [41, 622], [42, 620], [43, 618], [44, 615], [45, 613], [46, 611], [47, 609], [48, 607], [49, 606], [50, 604], [51, 602], [52, 600], [53, 598], [54, 597], [55, 595], [56, 593], [57, 592], [58, 590], [59, 589], [60, 587], [61, 586], [62, 584], [63, 583], [64, 582], [65, 580], [66, 579], [67, 578], [68, 576], [69, 575], [70, 574], [71, 573], [72, 571], [73, 570], [74, 569], [75, 568], [76, 567], [77, 566], [78, 565], [79, 563], [80, 562], [81, 561], [82, 560], [83, 559], [84, 558], [85, 557], [86, 556], [87, 555], [88, 554], [89, 553], [90, 552], [91, 552], [92, 551], [93, 550], [94, 549], [95, 548], [96, 547], [97, 546], [98, 545], [99, 545], [100, 544], [101, 543], [102, 542], [103, 541], [104, 541], [105, 540], [106, 539], [107, 538], [108, 537], [109, 537], [110, 536], [111, 535], [112, 535], [113, 534], [114, 533], [115, 532], [116, 532], [117, 531], [118, 530], [119, 530], [120, 529], [121, 528], [122, 528], [123, 527], [124, 526], [125, 526], [126, 525], [127, 524], [128, 524]]</span></span></code></pre> <p><code>max_discount = 524</code></p> <h4 id="pairing-check-operation">Pairing check operation</h4> <p>The cost of the pairing check operation is <code>32600*k + 37700</code> where <code>k</code> is a number of pairs.</p> <h4 id="fp-to-g1-mapping-operation">Fp-to-G1 mapping operation</h4> <p>Fp -&gt; G1 mapping is <code>5500</code> gas.</p> <h4 id="fp2-to-g2-mapping-operation">Fp2-to-G2 mapping operation</h4> <p>Fp2 -&gt; G2 mapping is <code>23800</code> gas</p> <h4 id="gas-schedule-clarifications-for-the-variable-length-input">Gas schedule clarifications for the variable-length input</h4> <p>For MSM and pairing functions, the gas cost depends on the input length. The current state of how the gas schedule is implemented in major clients (at the time of writing) is that the gas cost function does <em>not</em> perform any validation of the length of the input and never returns an error. So we present a list of rules how the gas cost functions <strong>must</strong> be implemented to ensure consistency between clients and safety.</p> <h5 id="gas-schedule-clarifications-for-g1-g2-msm">Gas schedule clarifications for G1/G2 MSM</h5> <p>Define a constant <code>LEN_PER_PAIR</code> that is equal to <code>160</code> for G1 operation and to <code>288</code> for G2 operation. Define a function <code>discount(k)</code> following the rules in the corresponding section, where <code>k</code> is number of pairs.</p> <p>The following pseudofunction reflects how gas should be calculated:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>k = floor(len(input) / LEN_PER_PAIR);</span></span> <span class="giallo-l"><span>if k == 0 {</span></span> <span class="giallo-l"><span> return 0;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"><span>gas_cost = k * multiplication_cost * discount(k) // multiplier;</span></span> <span class="giallo-l"><span>return gas_cost;</span></span></code></pre> <p>We use floor division to get the number of pairs. If the length of the input is not divisible by <code>LEN_PER_PAIR</code> we still produce <em>some</em> result, but later on the precompile will return an error. Also, the case when <code>k = 0</code> is safe: <code>CALL</code> or <code>STATICCALL</code> cost is non-zero, and the case with formal zero gas cost is already used in <code>Blake2f</code> precompile. In any case, the main precompile routine <strong>must</strong> produce an error on such an input because it violated encoding rules.</p> <h5 id="gas-schedule-clarifications-for-pairing">Gas schedule clarifications for pairing</h5> <p>Define a constant <code>LEN_PER_PAIR = 384</code>;</p> <p>The following pseudofunction reflects how gas should be calculated:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>k = floor(len(input) / LEN_PER_PAIR);</span></span> <span class="giallo-l"><span>gas_cost = 32600*k + 37700;</span></span> <span class="giallo-l"><span>return gas_cost;</span></span></code></pre> <p>We use floor division to get the number of pairs. If the length of the input is not divisible by <code>LEN_PER_PAIR</code> we still produce <em>some</em> result, but later on the precompile will return an error (the precompile routine <strong>must</strong> produce an error on such an input because it violated encoding rules).</p> <h2 id="rationale">Rationale</h2> <p>The motivation section covers a total motivation to have operations over the BLS12-381 curves available. We also extend a rationale for more specific fine points.</p> <h3 id="msm-as-a-separate-call">MSM as a separate call</h3> <p>Explicit separate MSM operation that allows one to save execution time (so gas) by both the algorithm used (namely Pippenger's algorithm) and (usually forgotten) by the fact that <code>CALL</code> operation in Ethereum is expensive (at the time of writing), so one would have to pay non-negligible overhead if e.g. for MSM of <code>100</code> points would have to call the multiplication precompile <code>100</code> times and addition for <code>99</code> times (roughly <code>138600</code> would be saved).</p> <h3 id="no-dedicated-mul-call">No dedicated MUL call</h3> <p>Dedicated MUL precompiles which perform single G1/G2 point by scalar multiplication have exactly the same ABI as MSM with <code>k == 1</code>. MSM has to inspect the input length to reject inputs of invalid lengths. Therefore, it should recognize the case of <code>k == 1</code> and invoke the underlying implementation of single point multiplication to avoid the overhead of more complex multi-scalar multiplication algorithm.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backward compatibility questions.</p> <h3 id="subgroup-checks">Subgroup checks</h3> <p>MSMs and pairings MUST perform a subgroup check. Implementations SHOULD use the optimized subgroup check method detailed in a dedicated <a href="https://wg-eips.ritovision.com/2537/assets/fast_subgroup_checks/">document</a>. On any input that fails the subgroup check, the precompile MUST return an error. As endomorphism acceleration requires input on the correct subgroup, implementers MAY use endomorphism acceleration.</p> <h3 id="field-to-curve-mapping">Field to curve mapping</h3> <p>The algorithms and set of parameters for SWU mapping method are provided by a separate <a href="https://wg-eips.ritovision.com/2537/assets/field_to_curve/">document</a></p> <h2 id="test-cases">Test Cases</h2> <p>Due to the large test parameters space, we first provide properties that various operations must satisfy. We use additive notation for point operations, capital letters (<code>P</code>, <code>Q</code>) for points, small letters (<code>a</code>, <code>b</code>) for scalars. The generator for G1 is labeled as <code>G</code>, the generator for G2 is labeled as <code>H</code>, otherwise we assume random points on a curve in a correct subgroup. <code>0</code> means either scalar zero or point at infinity. <code>1</code> means either scalar one or multiplicative identity. <code>group_order</code> is the main subgroup order. <code>e(P, Q)</code> means pairing operation where <code>P</code> is in G1, <code>Q</code> is in G2.</p> <p>Required properties for basic ops (add/multiply):</p> <ul> <li>Commutativity: <code>P + Q = Q + P</code></li> <li>Identity element: <code>P + 0 = P</code></li> <li>Additive negation: <code>P + (-P) = 0</code></li> <li>Doubling <code>P + P = 2*P</code></li> <li>Subgroup check: <code>group_order * P = 0</code></li> <li>Trivial multiplication check: <code>1 * P = P</code></li> <li>Multiplication by zero: <code>0 * P = 0</code></li> <li>Multiplication by the unnormalized scalar <code>(scalar + group_order) * P = scalar * P</code></li> </ul> <p>Required properties for pairing operation:</p> <ul> <li>Bilinearity <code>e(a*P, b*Q) = e(a*b*P, Q) = e(P, a*b*Q)</code></li> <li>Non-degeneracy <code>e(P, Q) != 1</code></li> <li><code>e(P, 0*Q) = e(0*P, Q) = 1</code></li> <li><code>e(P, -Q) = e(-P, Q)</code></li> </ul> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/2537/assets/test-vectors/">in the test vectors files</a>.</p> <h3 id="benchmarking-test-cases">Benchmarking test cases</h3> <p>A set of test vectors for quick benchmarking on new implementations is located in a separate <a href="https://wg-eips.ritovision.com/2537/assets/bench_vectors/">file</a></p> <h2 id="reference-implementation">Reference Implementation</h2> <p>There are two fully spec compatible implementations on the day of writing:</p> <ul> <li>One in Rust language that is based on the <a href="https://wg-eips.ritovision.com/196/">EIP-196</a> code and integrated with OpenEthereum for this library</li> <li>One implemented specifically for Geth as a part of the current codebase</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>Strictly following the spec will eliminate security implications or consensus implications in a contrast to the previous BN254 precompile.</p> <p>Important topic is a "constant time" property for performed operations. We explicitly state that this precompile <strong>IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Holst Swendehttps://github.com/holiman https://wg-eips.ritovision.com/2583/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP introduces a gas penalty for opcodes which access the account for trie non-existent accounts.</p> <h2 id="abstract">Abstract</h2> <p>This EIP adds a gas penalty for accesses to the account trie, where the address being looked up does not exist. Non-existing accounts can be used in DoS attacks, since they bypass cache mechanisms, thus creating a large discrepancy between 'normal' mode of execution and 'worst-case' execution of an opcode.</p> <h2 id="motivation">Motivation</h2> <p>As the ethereum trie becomes more and more saturated, the number of disk lookups that a node is required to do in order to access a piece of state increases too. This means that checking e.g. <code>EXTCODEHASH</code> of an account at block <code>5</code> was <em>inherently</em> a cheaper operation that it is at, say <code>8.5M</code>.</p> <p>From an implementation perspective, a node can (and does) use various caching mechanisms to cope with the problem, but there's an inherent problem with caches: when they yield a 'hit', they're great, but when they 'miss', they're useless.</p> <p>This is attackable. By forcing a node to lookup non-existent keys, an attacker can maximize the number of disk lookups. Sidenote: even if the 'non-existence' is cached, it's trivial to use a new non-existent key the next time, and never hit the same non-existent key again. Thus, caching 'non-existence' might be dangerous, since it will evict 'good' entries.</p> <p>So far, the attempts to handle this problem has been in raising the gas cost, e.g. <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>, <a href="https://wg-eips.ritovision.com/1884/">EIP-1884</a>.</p> <p>However, when determining gas-costs, a secondary problem that arises due to the large discrepancy between 'happy-path' and 'notorious path' -- how do we determine the pricing?</p> <ul> <li>The 'happy-path', assuming all items are cached? <ul> <li>Doing so would that would underprice all trie-accesses, and could be DoS-attacked.</li> </ul> </li> <li>The 'normal' usage, based on benchmarks of actual usage? <ul> <li>This is basically what we do now, but that means that intentionally notorious executions are underpriced -- which constitutes a DoS vulnerability.</li> </ul> </li> <li>The 'paranoid' case: price everything as if caching did not exist? <ul> <li>This would severely harm basically every contract due to the gas-cost increase. Also, if the gas limits were raised in order to allow the same amount of computation as before, the notorious case could again be used for DoS attacks.</li> </ul> </li> </ul> <p>From an engineering point of view, a node implementor is left with few options:</p> <ul> <li>Implement bloom filters for existence. This is difficult, not least because of the problems of reorgs, and the fact that it's difficult to undo bloom filter modifications.</li> <li>Implement flattened account databases. This is also difficult, both because of reorgs and also because it needs to be an <em>additional</em> data structure aside from the <code>trie</code> -- we need the <code>trie</code> for consensus. So it's an extra data structure of around <code>15G</code> that needs to be kept in check. This is currently being pursued by the Geth-team.</li> </ul> <p>This EIP proposes a mechanism to alleviate the situation.</p> <h2 id="specification">Specification</h2> <p>We define the constant <code>penalty</code> as <code>TBD</code> (suggested <code>2000</code> gas).</p> <p>For opcodes which access the account trie, whenever the operation is invoked targeting an <code>address</code> which does not exist in the trie, then <code>penalty</code> gas is deducted from the available <code>gas</code>.</p> <h3 id="detailed-specification">Detailed specification</h3> <p>These are the opcodes which triggers lookup into the main account trie:</p> <table><thead><tr><th>Opcode</th><th>Affected</th><th>Comment</th></tr></thead><tbody> <tr><td>BALANCE</td><td>Yes</td><td><code>balance(nonexistent_addr)</code> would incur <code>penalty</code></td></tr> <tr><td>EXTCODEHASH</td><td>Yes</td><td><code>extcodehash(nonexistent_addr)</code> would incur <code>penalty</code></td></tr> <tr><td>EXTCODECOPY</td><td>Yes</td><td><code>extcodecopy(nonexistent_addr)</code> would incur <code>penalty</code></td></tr> <tr><td>EXTCODESIZE</td><td>Yes</td><td><code>extcodesize(nonexistent_addr)</code> would incur <code>penalty</code></td></tr> <tr><td>CALL</td><td>Yes</td><td>See details below about call variants</td></tr> <tr><td>CALLCODE</td><td>Yes</td><td>See details below about call variants</td></tr> <tr><td>DELEGATECALL</td><td>Yes</td><td>See details below about call variants</td></tr> <tr><td>STATICCALL</td><td>Yes</td><td>See details below about call variants</td></tr> <tr><td>SELFDESTRUCT</td><td>No</td><td>See details below.</td></tr> <tr><td>CREATE</td><td>No</td><td>Create destination not explicitly settable, and assumed to be nonexistent already.</td></tr> <tr><td>CREATE2</td><td>No</td><td>Create destination not explicitly settable, and assumed to be nonexistent already.</td></tr> </tbody></table> <h3 id="notes-on-call-derivatives">Notes on Call-derivatives</h3> <p>A <code>CALL</code> triggers a lookup of the <code>CALL</code> destination address. The base cost for <code>CALL</code> is at <code>700</code> gas. A few other characteristics determine the actual gas cost of a call:</p> <ol> <li>If the <code>CALL</code> (or <code>CALLCODE</code>) transfers value, an additional <code>9K</code> is added as cost. 1.1 If the <code>CALL</code> destination did not previously exist, an additional <code>25K</code> gas is added to the cost.</li> </ol> <p>This EIP adds a second rule in the following way:</p> <ol start="2"> <li>If the call does <em>not</em> transfer value and the callee does <em>not</em> exist, then <code>penalty</code> gas is added to the cost.</li> </ol> <p>In the table below,</p> <ul> <li><code>value</code> means non-zero value transfer,</li> <li><code>!value</code> means zero value transfer,</li> <li><code>dest</code> means destination already exists, or is a <code>precompile</code></li> <li><code>!dest</code> means destination does not exist and is not a <code>precompile</code></li> </ul> <table><thead><tr><th>Op</th><th>value,dest</th><th>value, !dest</th><th>!value, dest</th><th>!value, !dest</th></tr></thead><tbody> <tr><td>CALL</td><td>no change</td><td>no change</td><td>no change</td><td><code>penalty</code></td></tr> <tr><td>CALLCODE</td><td>no change</td><td>no change</td><td>no change</td><td><code>penalty</code></td></tr> <tr><td>DELEGATECALL</td><td>N/A</td><td>N/A</td><td>no change</td><td><code>penalty</code></td></tr> <tr><td>STATICCALL</td><td>N/A</td><td>N/A</td><td>no change</td><td><code>penalty</code></td></tr> </tbody></table> <p>Whether the rules of this EIP is to be applied for regular ether-sends in <code>transactions</code> is TBD. See the 'Backwards Compatibility'-section for some more discussion on that topic.</p> <h3 id="note-on-selfdestruct">Note on <code>SELFDESTRUCT</code></h3> <p>The <code>SELFDESTRUCT</code> opcode also triggers an account trie lookup of the <code>beneficiary</code>. However, due to the following reasons, it has been omitted from having a <code>penalty</code> since it already costs <code>5K</code> gas.</p> <h3 id="clarifications">Clarifications:</h3> <ul> <li>The <code>base</code> costs of any opcodes are not modified by the EIP.</li> <li>The opcode <code>SELFBALANCE</code> is not modified by this EIP, regardless of whether the <code>self</code> address exists or not.</li> </ul> <h2 id="rationale">Rationale</h2> <p>With this scheme, we could continue to price these operations based on the 'normal' usage, but gain protection from attacks that try to maximize disk lookups/cache misses. This EIP does not modify anything regarding storage trie accesses, which might be relevant for a future EIP. However, there are a few crucial differences.</p> <ol> <li>Storage tries are typically small, and there's a high cost to populate a storage trie with sufficient density for it to be in the same league as the account trie.</li> <li>If an attacker wants to use an existing large storage trie, e.g. some popular token, he would typically have to make a <code>CALL</code> to cause a lookup in that token -- something like <code>token.balanceOf(&lt;nonexistent-address&gt;)</code>. That adds quite a lot of extra gas-impediments, as each <code>CALL</code> is another <code>700</code> gas, plus gas for arguments to the <code>CALL</code>.</li> </ol> <h3 id="determining-the-penalty">Determining the <code>penalty</code></h3> <p>A transaction with <code>10M</code> gas can today cause ~<code>14K</code> trie lookups.</p> <ul> <li>A <code>penalty</code> of <code>1000</code>would lower the number to ~<code>5800</code> lookups, <code>41%</code> of the original.</li> <li>A <code>penalty</code> of <code>2000</code>would lower the number to ~<code>3700</code> lookups, <code>26%</code> of the original.</li> <li>A <code>penalty</code> of <code>3000</code>would lower the number to ~<code>2700</code> lookups, <code>20%</code> of the original.</li> <li>A <code>penalty</code> of <code>4000</code>would lower the number to ~<code>2100</code> lookups, <code>15%</code> of the original.</li> </ul> <p>There exists a roofing function for the <code>penalty</code>. Since the <code>penalty</code> is deducted from <code>gas</code>, that means that a malicious contract can always invoke a malicious relay to perform the trie lookup. Let's refer to this as the 'shielded relay' attack.</p> <p>In such a scenario, the <code>malicious</code> would spend <code>~750</code> gas each call to <code>relay</code>, and would need to provide the <code>relay</code> with at least <code>700</code> gas to do a trie access.</p> <p>Thus, the effective <code>cost</code> would be on the order of <code>1500</code>. It can thus be argued that <code>penalty</code> above <code>~800</code> would not achieve better protection against trie-miss attacks.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard-fork.</p> <h3 id="ether-transfers">Ether transfers</h3> <p>A regular <code>transaction</code> from one EOA to another, with value, is not affected.</p> <p>A <code>transaction</code> with <code>0</code> value, to a destination which does not exist, would be. This scenario is highly unlikely to matter, since such a <code>transaction</code> is useless -- even during success, all it would accomplish would be to spend some <code>gas</code>. With this EIP, it would potentially spend some more gas.</p> <h3 id="layer-2">Layer 2</h3> <p>Regarding layer-2 backward compatibility, this EIP is a lot less disruptive than EIPs which modify the <code>base</code> cost of an opcode. For state accesses, there are seldom legitimate scenarios where</p> <ol> <li>A contract checks <code>BALANCE</code>/<code>EXTCODEHASH</code>/<code>EXTCODECOPY</code>/<code>EXTCODESIZE</code> of another contract <code>b</code>, <em>and</em>,</li> <li>If such <code>b</code> does not exist, continues the execution</li> </ol> <h4 id="solidity-remote-calls">Solidity remote calls</h4> <p>Example: When a remote call is made in Solidity:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> recipient.invokeMethod(1)</span></span></code></pre> <ul> <li>Solidity does a pre-flight <code>EXTCODESIZE</code> on <code>recipient</code>.</li> <li>If the pre-flight check returns <code>0</code>, then <code>revert(0,0)</code> is executed, to stop the execution.</li> <li>If the pre-flight check returns non-zero, then the execution continues and the <code>CALL</code> is made.</li> </ul> <p>With this EIP in place, the 'happy-path' would work as previously, and the 'notorious'-path where <code>recipient</code> does not exist would cost an extra <code>penalty</code> gas, but the actual execution-flow would be unchanged.</p> <h4 id="erc223">ERC223</h4> <p><a rel="external" href="https://github.com/ethereum/EIPs/issues/223">ERC223 Token Standard</a> is, at the time of writing, marked as 'Draft', but is deployed and in use on mainnet today.</p> <p>The ERC specifies that when a token <code>transfer(_to,...)</code> method is invoked, then:</p> <blockquote> <p>This function must transfer tokens and invoke the function <code>tokenFallback (address, uint256, bytes)</code> in <code>_to</code>, if <code>_to</code> is a contract. ... NOTE: The recommended way to check whether the <code>_to</code> is a contract or an address is to assemble the code of <code>_to</code>. If there is no code in <code>_to</code>, then this is an externally owned address, otherwise it's a contract.</p> </blockquote> <p>The reference implementations from <a rel="external" href="https://github.com/Dexaran/ERC223-token-standard/tree/development/token/ERC223">Dexaran</a> and <a rel="external" href="https://github.com/OpenZeppelin/openzeppelin-contracts/blob/1bc923b6a222e79a90f20305a459b0ee779eb918/contracts/token/ERC721/ERC721.sol#L499">OpenZeppelin</a> both implement the <code>isContract</code> check using an <code>EXTCODESIZE</code> invocation.</p> <p>This scenario <em>could</em> be affected, but in practice should not be. Let's consider the possibilities:</p> <ol> <li>The <code>_to</code> is a contract: Then <code>ERC223</code> specifies that the function <code>tokenFallback(...)</code> is invoked. <ul> <li>The gas expenditure for that call is at least<code>700</code> gas.</li> <li>In order for the <code>callee</code> to be able to perform any action, best practice it to ensure that it has at least <code>2300</code> gas along with the call.</li> <li>In summary: this path requires there to be least <code>3000</code> extra gas available (which is not due to any <code>penalty</code>)</li> </ul> </li> <li>The <code>_to</code> exists, but is no contract. The flow exits here, and is not affected by this EIP</li> <li>The <code>_to</code> does not exist: A <code>penalty</code> is deducted.</li> </ol> <p>In summary, it would seem that <code>ERC223</code> should not be affected, as long as the <code>penalty</code> does not go above around <code>3000</code> gas.</p> <h3 id="other">Other</h3> <p>The contract <a rel="external" href="https://etherscan.io/address/0x08d32b0da63e2c3bcf8019c9c5d849d7a9d791e6#code"><code>Dentacoin</code></a> would be affected.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> function transfer(address _to, uint256 _value) returns (bool success) {</span></span> <span class="giallo-l"><span> ... // omitted for brevity</span></span> <span class="giallo-l"><span> if (balances[msg.sender] &gt;= _value &amp;&amp; balances[_to] + _value &gt; balances[_to]) { // Check if sender has enough and for overflows</span></span> <span class="giallo-l"><span> balances[msg.sender] = safeSub(balances[msg.sender], _value); // Subtract DCN from the sender</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if (msg.sender.balance &gt;= minBalanceForAccounts &amp;&amp; _to.balance &gt;= minBalanceForAccounts) { // Check if sender can pay gas and if recipient could</span></span> <span class="giallo-l"><span> balances[_to] = safeAdd(balances[_to], _value); // Add the same amount of DCN to the recipient</span></span> <span class="giallo-l"><span> Transfer(msg.sender, _to, _value); // Notify anyone listening that this transfer took place</span></span> <span class="giallo-l"><span> return true;</span></span> <span class="giallo-l"><span> } else {</span></span> <span class="giallo-l"><span> balances[this] = safeAdd(balances[this], DCNForGas); // Pay DCNForGas to the contract</span></span> <span class="giallo-l"><span> balances[_to] = safeAdd(balances[_to], safeSub(_value, DCNForGas)); // Recipient balance -DCNForGas</span></span> <span class="giallo-l"><span> Transfer(msg.sender, _to, safeSub(_value, DCNForGas)); // Notify anyone listening that this transfer took place</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if(msg.sender.balance &lt; minBalanceForAccounts) {</span></span> <span class="giallo-l"><span> if(!msg.sender.send(gasForDCN)) throw; // Send eth to sender</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> if(_to.balance &lt; minBalanceForAccounts) {</span></span> <span class="giallo-l"><span> if(!_to.send(gasForDCN)) throw; // Send eth to recipient</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> } else { throw; }</span></span> <span class="giallo-l"><span> }</span></span></code></pre> <p>The contract checks <code>_to.balance &gt;= minBalanceForAccounts</code>, and if the <code>balance</code> is too low, some <code>DCN</code> is converted to <code>ether</code> and sent to the <code>_to</code>. This is a mechanism to ease on-boarding, whereby a new user who has received some <code>DCN</code> can immediately create a transaction.</p> <p>Before this EIP:</p> <ul> <li>When sending <code>DCN</code> to a non-existing address, the additional <code>gas</code> expenditure would be: <ul> <li><code>9000</code> for an ether-transfer</li> <li><code>25000</code> for a new account-creation</li> <li>(<code>2300</code> would be refunded to the caller later)</li> <li>A total runtime <code>gas</code>-cost of <code>34K</code> gas would be required to handle this case.</li> </ul> </li> </ul> <p>After this EIP:</p> <ul> <li>In addition to the <code>34K</code> an additional <code>penalty</code> would be added. <ul> <li>Possibly two, since the reference implementation does the balance-check twice, but it's unclear whether the compiled code would indeed perform the check twice.</li> </ul> </li> <li>A total runtime <code>gas</code>-cost of <code>34K+penalty</code> (or <code>34K + 2 * penalty</code>) would be required to handle this case.</li> </ul> <p>It can be argued that the extra penalty of <code>2-3K</code> gas can be considered marginal in relation to the other <code>34K</code> gas already required to handle this.</p> <h2 id="test-cases">Test Cases</h2> <p>The following cases need to be considered and tested:</p> <ul> <li>That during creation of a brand new contract, within the constructor, the <code>penalty</code> should not be applied for calls concerning the self-address.</li> <li>TBD: How the <code>penalty</code> is applied in the case of a contract which has performed a <code>selfdestruct</code> <ul> <li>a) previously in the same call-context,</li> <li>b) previously in the same transaction,</li> <li>c) previously in the same block, For any variant of <code>EXTCODEHASH(destructed)</code>, <code>CALL(destructed)</code>, <code>CALLCODE(destructed)</code> etc.</li> </ul> </li> <li>The effects on a <code>transaction</code> with <code>0</code> value going to a non-existent account.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>See 'Backwards Compatibility'</p> <h2 id="implementation">Implementation</h2> <p>Not yet available.</p> <h2 id="alternative-variants">Alternative variants</h2> <h3 id="alt-1-insta-refunds">Alt 1: Insta-refunds</h3> <p>Bump all trie accesses with <code>penalty</code>. <code>EXTCODEHASH</code> becomes <code>2700</code> instead of <code>700</code>.</p> <ul> <li>If a trie access hit an existing item, immediately refund penalty (<code>2K</code> )</li> </ul> <p>Upside:</p> <ul> <li>This eliminates the 'shielded relay' attack</li> </ul> <p>Downside:</p> <ul> <li>This increases the up-front cost of many ops (CALL/EXTCODEHASH/EXTCODESIZE/STATICCALL/EXTCODESIZE etc) <ul> <li>Which may break many contracts.</li> </ul> </li> </ul> <h3 id="alt-2-parent-bail">Alt 2: Parent bail</h3> <p>Use <code>penalty</code> as described, but if a child context goes OOG on the <code>penalty</code>, then the remainder is subtracted from the parent context (recursively).</p> <p>Upside:</p> <ul> <li>This eliminates the 'shielded relay' attack</li> </ul> <p>Downside:</p> <ul> <li>This breaks the current invariant that a child context is limited by whatever <code>gas</code> was allocated for it. <ul> <li>However, the invariant is not <em>totally</em> thrown out, the new invariant becomes that it is limited to <code>gas + penalty</code>.</li> </ul> </li> <li>This can be seen as 'messy' -- since only <em>some</em> types of OOG (penalties) becomes passed up the call chain, but not others, e.g. OOG due to trying to allocate too much memory. There is a distinction, however: <ul> <li>Gas-costs which arise due to not-yet-consumed resources do not get passed to parent. For example: a huge allocation is not actually performed if there is insufficient gas.</li> <li>Whereas gas-costs which arise due to already-consumed resources <em>do</em> get passed to parent; in this case the penalty is paid post-facto for a trie iteration.</li> </ul> </li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-02-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Hancockhttps://github.com/madeoftin https://wg-eips.ritovision.com/2515/ <h2 id="simple-summary">Simple Summary</h2> <p>The difficulty Freeze is an alternative to the Difficulty Bomb that is implemented within the protocols difficulty adjustment algorithm. The Difficulty Freeze begins at a certain block height, determined in advance, freezes the difficulty and increases by 1% after that block forever. This does not stop the chain, but it incentivizes devs to upgrade at a regular cadence and requires any chain split to address the difficulty freeze.</p> <h2 id="abstract">Abstract</h2> <p>The difficulty Freeze is a mechanism that is easy to predict and model, and the pressures of missing it are more readily felt by the core developers and client maintainers. The client maintainers are also positioned as the group that is most able to respond to an incoming Difficulty Freeze. This combined with the predictability is more likely to lead to the timely diffusual of the bomb.</p> <h2 id="motivation">Motivation</h2> <p>The current difficulty bombs' effect on the Block Time Targeting mechanism is rather complex to model, and it has both appeared when it was not expected (Muir Glacier) and negatively affected miners when they are not the target (in the case of delaying forks due to technical difficulties). Miners are affected by a reduction in block rewards due to the increase in block time. Users are affected as a function of the usability of the chain is affected by increased block times. Both of these groups are unable on their own to address the difficulty bomb. In the case of the Difficulty Freeze, the consequences of missing it are more directly felt by the client maintainers and it is more predictiable and so knowing when to make the change is readily apparent.</p> <h2 id="specification">Specification</h2> <p>Add variable <code>DIFFICULTY_FREEZE_HEIGHT</code></p> <p>The logic of the Difficulty Freeze is defined as follows:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>if (BLOCK_HEIGHT &lt;= DIFFICULTY_FREEZE_HEIGHT):</span></span> <span class="giallo-l"><span> block_diff = parent_diff + parent_diff // 2048 * max(</span></span> <span class="giallo-l"><span> 1 - (block_timestamp - parent_timestamp) // 10, -99)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>else:</span></span> <span class="giallo-l"><span> block_diff = parent_diff + parent_diff * 0.01</span></span></code></pre> <p><strong>Optional Implementation</strong></p> <p>Add the variable <code>DIFFICULTY_FREEZE_DIFFERENCE</code> and use the <code>LAST_FORK_HEIGHT</code> to calculate when the Difficulty Freeze would occur.</p> <p>For example we can set the <code>DFD = 1,800,000 blocks</code> or approximately 9 months. The Difficulty Calculation would then be.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>if (BLOCK_HEIGHT &lt;= LAST_FORK_HEIGHT + DIFFICULTY_FREEZE_DIFFERENCE) :</span></span> <span class="giallo-l"><span> block_diff = parent_diff + parent_diff // 2048 * max(</span></span> <span class="giallo-l"><span> 1 - (block_timestamp - parent_timestamp) // 10, -99)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>else:</span></span> <span class="giallo-l"><span> block_diff = parent_diff + parent_diff * 0.01</span></span></code></pre> <p>This approach would have the added benefit that updating the Difficulty Freeze is easier as it happens automatically at the time of every upgrade. The trade-off is that the logic for checking is more complex and would require further analysis and test cases to ensure no consensus bugs arise.</p> <h2 id="rationale">Rationale</h2> <p>Block height is very easy to predict and evaluate within the system. This removes the effect of the Difficulty Bomb on block time, simplifying the block time targeting mechanism. The addition of an increase in the difficulty was added after feedback that the game theory of the mechanism did not reliably result in .</p> <p>https://twitter.com/quentinc137/status/1227110578235330562</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No backward incompatibilities</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>The effect of missing the Difficulty Freeze has a different impact than missing the Difficulty Bomb. At the point of a Difficulty freeze, the protocol is no longer able to adapt to changes in hash power on the network. This can lead to one of three scenarios.</p> <ul> <li>The Hash rate Increases: Block Times would increase on the network for short time until the increase in difficulty is too high for the network to add any more miners.</li> <li>The Hash rate decreases: Block times would increase.</li> <li>The Hash rate stays the same: A consistent increase in blocktimes.</li> </ul> <p>Clients are motivated to have their client sync fully to the network and so are very motivated to keep this situation from occurring. Simultaneously delaying the Difficulty Freeze is most easily implemented by client teams. Therefore the group that is most negatively affected is also the group that can most efficiently address it.</p> <h2 id="economic-considerations">Economic Considerations</h2> <p>Under the current Difficult, Bomb issuance of ETH is reduced as the Ice Age takes affect. Under the Difficulty Freeze, it is more likely that issuance would increase for a short time; however, clients are motivated to prevent this and keep clients syncing effectively. This means it is much less likely to occur. The increase to the difficulty over time will eventually reduce blocktimes and also issuance.</p> <p>It is also easy to predict when this change would happen, and stakeholders who are affected (Eth Holders) can keep client developers accountable by observing when the Difficulty Freeze is approaching and yell at them on twitter.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2020-01-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ricardo Guilherme Schmidthttps://github.com/3esmit https://wg-eips.ritovision.com/2474/ <h2 id="simple-summary">Simple Summary</h2> <p>Allow contracts to be called directly by <code>block.coinbase</code> (block validator), without a transaction.</p> <h2 id="abstract">Abstract</h2> <p><em>In proof-of-work blockchains, validators are known as miners.</em></p> <p>The validator might want to execute functions directly, without having to sign a transaction. Some examples might be presenting a proof in a contract for a change which also benefits the validator.</p> <p>A notable example would be when a validator want to act as an <a href="https://wg-eips.ritovision.com/1077/">EIP-1077</a> Gas Relayer, incentivized to pick up fees from meta transactions. Without this change, they can do so by signing from any address a <code>gasPrice = 0</code> transaction with the gas relayed call. However this brings an overhead of a signed transaction by validator that does nothing, as <code>msg.sender</code> is never used, and there is no gas cost to EVM charge.</p> <p>This proposal makes possible to remove this unused ecrecover.</p> <h2 id="motivation">Motivation</h2> <p>In order to reduce the overhead of calls that don't use <code>msg.sender</code> and are being called by validator with <code>tx.gasPrice = 0</code>.</p> <h2 id="specification">Specification</h2> <p>The calls to be executed by <code>block.coinbase</code> would be included first at block, and would consume normally the gas of block, however they won't pay/cost gas, instead the call logic would pay the validator in other form.</p> <p>Would be valid to execute any calls without a transaction by the block coinbase, except when the validator call tries to read <code>msg.sender</code>, which would throw an invalid jump.</p> <p>Calls included by the validator would have <code>tx.origin = block.coinbase</code> and <code>gas.price = 0</code> for the rest of call stack, the rest follows as normal calls.</p> <h2 id="rationale">Rationale</h2> <p>TBD</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p><code>tx.origin = block.coinbase</code> could cause some issues on bad designed contracts, such as using <code>tx.origin</code> to validate a signature, an analysis on how contracts use tx.origin might be useful to decide if this is a good choice.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-12-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2488/ <h2 id="abstract">Abstract</h2> <p>Deprecate <code>CALLCODE</code> in a <em>somewhat</em> backwards compatible way, by making it always return failure.</p> <h2 id="motivation">Motivation</h2> <p><code>CALLCODE</code> was part of the Frontier release of Ethereum. In the first few weeks/months it became clear that it cannot accomplish its intended design goal. This was rectified with introducing <code>DELEGATECALL</code> (<a href="https://wg-eips.ritovision.com/7/">EIP-7</a>) in the Homestead update (early 2016).</p> <p><code>CALLCODE</code> became never utilized, but it still puts a burden on EVM implementations.</p> <p>Disabling it will not improve the situation for any client whose goal is to sync from genesis, but would help light clients or clients planning to sync from a later point in time.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= FORK_BLOCK</code>, the <code>CALLCODE</code> (<code>0xf2</code>) instruction always returns <code>0</code>, which signals failure.</p> <h2 id="rationale">Rationale</h2> <p>It would be possible just to remove the opcode and exceptionally abort if it is encountered. However, by returning failure, the contract has a chance to act on it and potentially recover.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This is a breaking change and has a potential to break contracts. The author expects no contracts of any value should be affected.</p> <p>TODO: validate this claim.</p> <h2 id="security-considerations">Security Considerations</h2> <p>TBA</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-11-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Eric Connerhttps://github.com/econoar https://wg-eips.ritovision.com/2384/ <h2 id="simple-summary">Simple Summary</h2> <p>The average block times are increasing due to the difficulty bomb (also known as the "<em>ice age</em>") and slowly accelerating. This EIP proposes to delay the difficulty bomb for another 4,000,000 blocks (~611 days).</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>MUIR_GLACIER_FORK_BLKNUM</code> the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 9 million blocks later than the Homestead fork, which is also 7 million blocks later than the Byzantium fork and 4 million blocks later than the Constantinople fork.</p> <h2 id="motivation">Motivation</h2> <p>The difficulty bomb started to become noticeable again on October 5th 2019 at block 8,600,000. Block times have been around 13.1s on average and now as of block 8,900,000 are around 14.3s. This will start to accelerate exponentially every 100,000 blocks. Estimating the added impact from the difficulty bomb on block times shows that we will see 20s block times near the end of December 2019 and 30s+ block times starting February 2020. This will start making the chain bloated and more costly to use. It's best to delay the difficulty bomb again to around the time of expected launch of the Eth2 finality gadget.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fake_block_number = max(0, block.number - 9_000_000) if block.number &gt;= MUIR_GLACIER_FORK_BLKNUM else block.number</span></span></code></pre><h2 id="rationale">Rationale</h2> <p>This will delay the ice age by 52 million seconds (approximately 611 days), so the chain would be back at 20 second block times around July 2021. It's important to note this pushes the ice age 4,000,000 blocks from ~block 8,800,000 NOT from when this EIP is activated in a fork.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP shortly after the Istanbul fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="implementation">Implementation</h2> <p>The implementation in it's logic does not differ from <a href="https://wg-eips.ritovision.com/649/">EIP-649</a> or <a href="https://wg-eips.ritovision.com/1234/">EIP-1234</a>; an implementation for Parity-Ethereum is available in <a rel="external" href="https://github.com/paritytech/parity-ethereum/pull/9187">parity-ethereum#9187</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-10-29T00:00:00+00:00 2026-02-11T14:49:28+00:00 Dominic Letzhttps://github.com/dominicletz Santiago Palladinohttps://github.com/spalladino https://wg-eips.ritovision.com/2330/

A new EVM opcode to read external contract storage data.

<h2 id="abstract">Abstract</h2> <p>This proposal adds a new opcode <code>EXTSLOAD</code> at <code>0x5c</code> which pops two items from the stack: <code>&lt;account address&gt; &lt;storage key&gt;</code> and pushes one item: <code>&lt;storage value&gt;</code>. The gas cost is sum of account access cost and storage read based on <a href="https://wg-eips.ritovision.com/2929/">EIP-2929</a> Access Lists.</p> <h2 id="motivation">Motivation</h2> <p>While any off-chain application can read all contract storage data of all contracts, this is not possible for deployed smart contracts themselves. These are bound to use contract calls for any interaction including reading data from other contracts. This EIP adds an EVM opcode to directly read external contract storage.</p> <p>The gas cost when reading from registry style contract such as <a href="https://wg-eips.ritovision.com/20/">EIP-20s</a>, ENS and other data contracts is very high, because they incur cross contract call cost, cost for ABI encoding, decoding and dispatching and finally loading the data. In many cases the underlying storage that is being queried is though just a simple mapping. On top of that, the view function may SLOAD many other slots which caller may not be interested in, which further adds to the gas costs. In these cases a new <code>EXTSLOAD</code> call directly accessing the mapping in storage could not only <strong>reduce the gas cost</strong> of the interaction more than 10x, but also it would make the gas cost <strong>predictable</strong> for the reading contract.</p> <h2 id="specification">Specification</h2> <p>A new EVM instruction <code>EXTSLOAD (0x5c)</code> that works like <code>SLOAD (0x54)</code> but an additional parameter representing the contract that is to be read from.</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name">EXTSLOAD</span><span> (0x5c</span><span>)</span></span></code></pre> <p>The <code>EXTSLOAD</code> instruction pops 2 values from the stack, first <code>contract</code> a contract address and then second <code>slot</code> a storage address within <code>contract</code>. As result <code>EXTSLOAD</code> pushes on the stack the value from the contract storage of <code>contract</code> at the storage <code>slot</code> address or <code>0</code> in case the account <code>contract</code> does not exist.</p> <h3 id="gas-cost-pre-verkle">Gas cost pre-verkle</h3> <p>Gas to be charged before Verkle Tree change is specified as <code>ACCOUNT_ACCESS_COST + STORAGE_READ_COST</code> where:</p> <ul> <li><code>ACCOUNT_ACCESS_COST</code> is <code>0</code> if the account address is already in <code>accessed_addresses</code> set, otherwise <code>COLD_ACCOUNT_ACCESS_COST</code>.</li> <li><code>STORAGE_READ_COST</code> is <code>WARM_STORAGE_READ_COST</code> if storage key is already in <code>accessed_storage_keys</code> set, otherwise <code>COLD_STORAGE_READ_COST</code>.</li> </ul> <h3 id="gas-cost-post-verkle">Gas cost post-verkle</h3> <p>It is important to consider that post Verkle tree change, <code>ACCOUNT_ACCESS_COST</code> will not be needed since a single account's storage would be spread across the entire global trie. Hence gas to be charged post Verkle Tree change is just <code>STORAGE_READ_COST</code>, which is as specified in <a href="https://wg-eips.ritovision.com/2330/#gas-cost-pre-verkle">Gas cost pre-verkle</a>.</p> <h2 id="rationale">Rationale</h2> <ul> <li>Without this EIP, a contract can still opt-in to make their entire state public, by having a method that simply SLOADs and returns the values (<a href="https://wg-eips.ritovision.com/2330/./assets/Extsload.sol">example</a>). The complexity of the gas cost can be seen as <code>1</code>x CALL cost + <code>N</code>x SLOAD cost. Hence, the gas cost specified for using EXTSLOAD opcode on an account for <code>N</code> times, the charge of <code>1</code>x <code>COLD_ACCOUNT_ACCESS_COST</code> and <code>N</code>x <code>STORAGE_READ_COST</code> is hereby justified.</li> <li>Without this EIP, a contract can still use internal state of other contracts. An external party can supply a value and proof to a contract, which the contract can verify using <code>BLOCKHASH</code>. This is only possible for the previous blocks and not the latest state (since current blockhash cannot be determined before execution).</li> <li>This opcode can be seen as breaking object-oriented (OO) model because it allows to read storage of other contracts. In usual systems using OO is net positive, because there is no limit on machine code and it hardly adds any cost to add more methods or use single method to get a ton of data while the caller needs to just a small portion of data. However on EVM, there are visible costs, i.e. about $0.2 per SLOAD (20 gwei and ETHUSD 2000). Also, OO has caused misleading assumptions for developers where variables marked as "private" in smart contracts are encrypted in some way/impossible to read which has resulted bad designs. Hence, this EIP can be beneficial in terms of making smart contract systems more efficient as well as preventing misconceptions as well.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is fully backwards compatible since it adds a new instruction.</p> <h2 id="security-considerations">Security Considerations</h2> <ul> <li>Since the opcode is similar to SLOAD, it should be easy to implement in various clients.</li> <li>This opcode allows the callee <code>A</code> to re-enter a caller contract <code>B</code> and read state of <code>B</code> and <code>B</code> cannot stop <code>A</code> from doing that. Since this does not change any state, it should not be a security issue. Contracts generally use re-entrancy guards, but that is only added to write methods. So even currently without EXTSLOAD, <code>A</code> can re-enter <code>B</code> and read their state exposed by any view methods and it has not been an issue.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-10-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Lundfallhttps://github.com/MrChico https://wg-eips.ritovision.com/2327/ <h2 id="simple-summary">Simple Summary</h2> <p>Introduces a new opcode <code>BEGINDATA</code>, which indicates that the remaining bytes of the contract should be regarded as data rather than contract code and cannot be executed.</p> <h2 id="abstract">Abstract</h2> <p>It is common for smart contracts to efficiently store data directly in the contract bytecode. Examples include constructor arguments, constant variables, compiler metadata and the contract runtime during the init phase. Currently, such data is not distinguished from normal bytecode and is still being analysed for <code>JUMPDEST</code>s by EVM interpreters. This EIP introduces a new opcode <code>BEGINDATA</code> at byte <code>0xb6</code>, which marks the remainding bytecode as data, indicating to EVM interpreters, static analysis tools and chain explorers that the remaining bytes do not represent opcodes.</p> <h2 id="motivation">Motivation</h2> <p>The <code>BEGINDATA</code> opcode has been suggested before as part of the EIP <code>Subroutines and Static Jumps for the EVM</code> <a href="https://wg-eips.ritovision.com/615/">EIP-615</a> as a way to determine the position of jumptables in contract bytecode. It is here introduced in its own right in order to exclude data from the <code>JUMPDEST</code> analysis of contracts, making it impossible to jump to data. This makes it easier for static analysis tools to analyse contracts, allows disassemblers, chain explorers and debuggers to not display data as a mess of INVALID opcodes and may even provide a marginal improvement in performance. It also helps scalability because it improves on-chain evaluation of transactions from other chains in that the validation that the code conforms to a certain pattern does not need to do a full jumpdest analysis to see that data is not executed and thus does not have to conform to the pattern (used by the optimism project). Additionally, it paves the way for suggestions such as <a rel="external" href="https://github.com/ethereum/EIPs/pull/1712">EIP-1712</a> to disallow unused opcodes, jumptables <a href="https://wg-eips.ritovision.com/615/">EIP-615</a> and speculative proposals to disallow for deployment of contracts with stack usage violations.</p> <h2 id="specification">Specification</h2> <p>While computing the valid <code>JUMPDEST</code>s of a contract, halt analysis once the first <code>BEGINDATA</code> is encountered. In other words: A jump to any codelocation equal to or greater than the location of the first <code>BEGINDATA</code> causes a <code>BAD_JUMP_DESTINATION</code> error. If <code>BEGINDATA</code> is encountered during contract execution, it has the same semantics as <code>STOP</code>. It uses 0 gas.</p> <p>Bytes past <code>BEGINDATA</code> remain accessible via <code>CODECOPY</code> and <code>EXTCODECOPY</code>. <code>BEGINDATA</code> does not influence <code>CODESIZE</code> or <code>EXTCODESIZE</code>.</p> <h2 id="rationale">Rationale</h2> <p>The byte <code>0xb6</code> was chosen to align with <a href="https://wg-eips.ritovision.com/615/">EIP-615</a>. The choice to <code>STOP</code> if <code>BEGINDATA</code> is encountered is somewhat arbitrary. An alternative would be to be to abort the execution with an out-of-gas error.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The proposal will not change any existing contracts unless their current behaviour relies upon the usage of unused opcodes.</p> <p>Since contracts have been using data from the very start, in a sense all of them use unused opcodes, but they would have to use data in a way that it is skipped during execution and jumped over. The Solidity compiler never generated such code. It has to be evaluated whether contracts created by other means could have such a code structure.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases should include:</p> <ol> <li>A contract which jumps to a destination <code>X</code>, where <code>X</code> has a pc value higher than the <code>BEGINDATA</code> opcode, and the byte at <code>X</code> is <code>0x5b</code>. This should fail with a <code>BAD_JUMP_DESTINATION</code> error.</li> <li>A contract which encounters the <code>BEGINDATA</code> opcode (should stop executing the current call frame)</li> </ol> <h2 id="implementation">Implementation</h2> <p>Not yet.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-10-17T00:00:00+00:00 2026-02-11T14:49:28+00:00 Greg Colvinhttps://github.com/gcolvin Martin Holst Swendehttps://github.com/holiman Brooklyn Zelenkahttps://github.com/expede John Max Skallerskaller@internode.on.net https://wg-eips.ritovision.com/2315/

Two opcodes for efficient, safe, and static subroutines.

<h2 id="abstract">Abstract</h2> <p>This proposal provides a <em>complete</em>, <em>efficient</em>, <em>safe</em> and <em>static</em> control-flow facility.</p> <p>It introduces two new opcodes to support calling and returning from subroutines:</p> <ul> <li><code>RJUMPSUB relative_offset</code> -- relative jump to subroutine</li> <li><code>RETURNSUB</code> -- return to <code>PC</code> after most recent <code>RJUMPSUB</code>.</li> </ul> <p>It depends on the two new opcodes proposed by <a href="https://wg-eips.ritovision.com/4200/">EIP-4200</a> to support static jumps:</p> <ul> <li><code>RJUMP relative_offset</code> — relative jump to <code>PC + relative_offset</code></li> <li><code>RJUMPI relative_offset</code> — conditional relative jump</li> </ul> <p>It deprecates <code>JUMP</code> and <code>JUMPI</code>, allowing valid code to support streaming, one-pass, and other near-linear compilers.</p> <p>In concert with <a href="https://wg-eips.ritovision.com/3540/">EIP-3540</a> and <a href="https://wg-eips.ritovision.com/3670/">EIP-3670</a> it ensures, at initialization time, that valid code will not execute invalid instructions or jump to invalid locations, will not underflow stack, will maintain consistent numbers of inputs and outputs for subroutines, and will have bounded stack height in the absence of recursion.</p> <p>This is among the simplest possible proposals that meets these requirements.</p> <h2 id="motivation">Motivation</h2> <h3 id="a-complete-control-flow-facility">A complete control-flow facility.</h3> <p>Jumps, conditional jumps and subroutines were proposed by Alan Turing in 1945 as a means of organizing the logic of the code and the design of the memory crystals for his Automatic Computing Engine:</p> <blockquote> <p>We wish to be able to arrange that sequences of orders can divide at various points, continuing in different ways according to the outcome of the calculations to date... We also wish to be able to arrange for the splitting up of operations into subsidiary operations... To start on a subsidiary operation we need only make a note of where we left off the major operation and then apply the first instruction of the subsidiary. When the subsidiary is over we look up the note and continue with the major operation.</p> <p>— Alan Turing — in B.E. Carpenter, R.W. Doran, "The other Turing machine." The Computer Journal, Volume 20, Issue 3, January 1977.</p> </blockquote> <p>In more contemporary terms, we have sequences of instructions, jumps and conditional jumps that divide sequences into blocks, subroutine calls, and a stack of addresses to return to. The details vary, but similar facilities have proven their value across a long line of important machines over the last 75 years, including most all of the machines we have programmed or implemented -- physical machines including the Burroughs 5000, CDC 7600, IBM 360, DEC PDP-11 and VAX, Motorola 68000, Sun SPARC, and Intel x86s, as well as virtual machines for Scheme, Forth, Pascal, Java, Wasm, and others.</p> <p>Unlike these machines, the Ethereum Virtual Machine <em>does not</em> provide subroutine operations. Instead, they must be synthesized using the dynamic <code>JUMP</code> instruction, which takes its destination on the stack. Further, the EVM provides <em>only</em> dynamic jumps, impeding the static analysis we need.</p> <h3 id="efficient-control-flow">Efficient control-flow.</h3> <p>Efficient to write by hand, compile from high level labguages, validate at deploy time, interpret by VMs, and compile to machine code.</p> <p>Static jumps, conditional jumps, and subroutines are sufficient and efficient in space and time, as shown by historical experience and as we will show for the EVM below.</p> <h3 id="safe-control-flow">Safe control-flow.</h3> <p>The EVM has unusually high requirements for safety. Not only do many smart contracts control inordinately large amounts of valuable Ether, but once placed on the blockchain any defects are visible to attackers and cannot be repaired. We propose to statically validate important safety constraints on code at initialization time.</p> <h3 id="static-control-flow">Static control-flow.</h3> <p>The EVM's dynamic jumps cause two major problems. First, the need to synthesize static jumps and subroutines with dynamic jumps wastes space and gas with needlessly complex code, as we will show below.</p> <p>Worse, jumps that can dynamically branch to any destination in the code can cause quadratic "path explosions" when traversing the flow of control. For Ethereum, this is a denial-of-service vulnerability that prevents us, at initialization time, from validating the safe use of EVM code and from compiling EVM code to machine code.</p> <p>We <em>need</em> static control-flow to validate program safety and to compile EVM bytecode to machine code -- in time and space linear in the size of the code.</p> <h2 id="specification">Specification</h2> <h3 id="opcodes">Opcodes</h3> <h4 id="rjumpsub-0x5f-relative-offset"><code>RJUMPSUB (0x5f) relative_offset</code></h4> <p>Transfers control to a subroutine.</p> <ol> <li>Decode the <code>relative_offset</code> from the immediate data at <code>PC</code>.</li> <li>Push the current <code>PC + 3</code> to the <code>return stack</code>.</li> <li>Set <code>PC</code> to <code>PC + relative_offset</code>.</li> </ol> <p>The <code>relative_offset</code> is relative to the current <code>PC</code>. The offset is encoded as a two-byte, twos-complement signed integer, stored MSB-first.</p> <p>The gas cost is <em>low</em>.</p> <h4 id="returnsub-0x5e"><code>RETURNSUB (0x5e)</code></h4> <p>Returns control to the caller of a subroutine.</p> <ol> <li>Pop the <code>return stack</code> to <code>PC</code>.</li> </ol> <p>The gas cost is <em>verylow</em>.</p> <p><em>Notes:</em></p> <ul> <li><em>Values popped off the <code>return stack</code> do not need to be validated, since they are alterable only by <code>RJUMPSUB</code> and <code>RETURNSUB</code>.</em></li> <li><em>The description above lays out the semantics of these instructions in terms of a <code>return stack</code>. But the actual state of the <code>return stack</code> is not observable by EVM code or consensus-critical to the protocol. (For example, a node implementer may code <code>RJUMPSUB</code> to unobservably push <code>PC</code> on the <code>return stack</code> rather than <code>PC + 1</code>, which is allowed so long as <code>RETURNSUB</code> observably returns control to the <code>PC + 3</code> location.)</em></li> </ul> <h3 id="validity">Validity</h3> <p><em>Execution</em> is defined in the Yellow Paper as a sequence of changes in the EVM state. The conditions on valid code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines six such states.</p> <ol> <li>Insufficient gas</li> <li>More than 1024 stack items</li> <li>State modification during a static call</li> <li>Insufficient stack items</li> <li>Invalid jump destination</li> <li>Invalid instruction</li> </ol> <p>We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state. In practice, we must test at runtime for the first three conditions. We don’t know how much gas there will be, we don’t know how deep a recursion may go, analysis of stack depth even for non-recursive programs is nontrivial, and we don't know whether a call will be static. All of the remaining conditions MUST be validated statically, in time and space quasi-linear in the size of the code.</p> <h4 id="static-constraints-on-valid-code">Static Constraints on Valid Code</h4> <ul> <li>Every instruction MUST be valid: <ul> <li>The <code>JUMP</code> and <code>JUMPI</code> instructions ARE NOT valid.</li> </ul> </li> <li>Every jump MUST be valid: <ul> <li>The <code>RJUMP</code>, <code>RJUMPI</code>, or <code>RJUMPSUB</code> instructions MUST NOT address immediate data or addresses outside of their code section.</li> </ul> </li> <li>The stacks MUST be valid: <ul> <li>The number of items on the <code>data stack</code> MUST always be positive.</li> <li>The number of items on the <code>return stack </code>MUST always be positive.</li> </ul> </li> <li>The data stack MUST be consistently aligned: <ul> <li>The data stack height is <ul> <li>the absolute difference between the current <code>stack pointer</code> and the <code>stack pointer</code> on entry to the current subroutine.</li> </ul> </li> <li>It MUST be the same for every reachable path through a given <code>PC</code> and</li> <li>MUST NOT exceed 1024.</li> </ul> </li> </ul> <h2 id="rationale">Rationale</h2> <p>This is a purely semantic specification, placing no constraints on the syntax of code sections beyond being a sequence of opcodes and immediate data – a subroutine is not a contiguous sequence of bytecode, it is a subgraph of the bytecode's control-flow graph. The EVM is a simple state machine. We only promise that valid code will not, as it were, jam up the gears of the machine.</p> <p>By avoiding syntactic constraints we allow for optimizations like tail call elimination, multiple-entry subroutines, moving "cold" code out of line, and other ways of reducing redundancy and keeping "hot" code in cache. Since we wish to support one-pass compilation of EVM code to machine code it is crucial that the EVM code be as well optimized as possible up front.</p> <h3 id="validation">Validation</h3> <p>Rather than enforce constraints via syntax, we enforce them via validation.</p> <p>The constraints on valid code cover all of the exceptional halting states that we can validate and allow code to be validated and compiled in time and space quasi-linear in the size of the code.</p> <p>The <code>RJUMP</code>, <code>RJUMPI</code> and <code>RJUMPSUB</code> instructions take their <em>relative_offset</em> as immediate arguments, which cannot change at runtime. Having constant destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime. Dynamic jumps can branch to any destination in the code, so exploitable quadratic "path explosions" are possible when traversing the control flow graph. Deprecating <code>JUMP</code> and <code>JUMPI</code> prevents this.</p> <p>Requiring a consistently aligned <code>data stack</code></p> <ul> <li>prevents stack underflow</li> <li>ensures that all calls to a subroutine have the same number of inputs and the same number of outputs and</li> <li>ensures that stack height is bounded in the absence of recursion.</li> </ul> <p>Requiring a consistently aligned <code>data stack</code> also allows some algorithms that traverse the control-flow graph -- including code validation and compilation -- to break cycles at joins, again preventing quadratic path explosion. When a traversal gets to a <code>PC</code> it has visited before it is either at the beginning of a loop or the entry to a function. Since the stack height at that <code>PC</code> is constant we know that loops will not grow stack, and that the number of arguments to a subroutine will always be the same -- there may be no need to traverse that path again.</p> <p><em>Note: The JVM and Wasm enforce similar constraints for similar reasons.</em></p> <h3 id="alternative-designs">Alternative Designs</h3> <p>There are a few major designs for a subroutine facility, two of which are considered here. The others are mostly not appropriate for the EVM, such as the Wheeler Jump -- self-modifying code that writes return addresses into called subroutines.</p> <p><em>1. Keep return addresses on a dedicated return stack.</em> Turing's design is often used by stack machines, including those for Forth, Java, Wasm, and others. The data stack is used for computation, with a dedicated stack for return addresses. A single instruction suffices to call, and another to return from a routine.</p> <p><em>2. Keep return addresses on the data stack.</em> This design is often used by register machines, including those from CDC, IBM, DEC, Intel, and ARM. The registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables. On the EVM there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we see below. Pascal p-code does use this design, but as part of a complex calling convention with dedicated registers.</p> <h4 id="we-prefer-the-dedicated-return-stack">We prefer the dedicated return stack.</h4> <ul> <li>It maintains a clear separation between calculation and flow of control: <ul> <li>the data stack is free of vulnerable return addresses and</li> <li>it's impossible to overwrite the return stack.</li> </ul> </li> <li>It improves efficiency: <ul> <li>it uses native arithmetic rather than 256-bit EVM instructions for the return address,</li> <li>doesn't use up a <code>data stack</code> slot for the return address and</li> <li>needs less motion of 256-bit data on the stack.</li> </ul> </li> </ul> <h3 id="efficiency">Efficiency</h3> <p>We illustrate here how subroutine instructions can be used to reduce the complexity and gas costs of both ordinary and optimized subroutine calls compared to using <code>JUMP</code>.</p> <h4 id="simple-subroutine-call"><strong>Simple Subroutine Call</strong></h4> <p>Consider these examples of a fairly minimal subroutine, including the code to call it.</p> <p>Subroutine call, using <code>RJUMPSUB</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SQUARE:</span></span> <span class="giallo-l"><span> dup1 ; 3 gas</span></span> <span class="giallo-l"><span> mul ; 5 gas</span></span> <span class="giallo-l"><span> returnsub ; 3 gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>CALL_SQUARE:</span></span> <span class="giallo-l"><span> push 0x02 ; 3 gas</span></span> <span class="giallo-l"><span> rjumpsub SQUARE ; 5 gas</span></span></code></pre> <p><em>Total gas: 19</em></p> <p>Subroutine call, using <code>JUMP</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas</span></span> <span class="giallo-l"><span> swap1 ; 3 gas</span></span> <span class="giallo-l"><span> dup1 ; 3 gas</span></span> <span class="giallo-l"><span> mul ; 5 gas</span></span> <span class="giallo-l"><span> swap1 ; 3 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>CALL_SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas</span></span> <span class="giallo-l"><span> push 0x02 ; 3 gas</span></span> <span class="giallo-l"><span> push RTN_CALL: ; 3 gas</span></span> <span class="giallo-l"><span> push SQUARE ; 3 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas</span></span> <span class="giallo-l"><span>RTN_CALL:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas</span></span></code></pre> <p><em>Total: 41 gas</em>.</p> <p>Using <code>RJUMPSUB</code> versus <code>JUMP</code> saves <em>41 - 19 = 22 gas</em> — a <em>54%</em> improvement.</p> <h4 id="tail-call-optimization"><strong>Tail Call Optimization</strong></h4> <p>Of course in cases like this one we can optimize the tail call, so that the return from <code>SQUARE</code> actually returns from <code>TEST_SQUARE</code>.</p> <p>Tail call optimization, using <code>RJUMPSUB</code> and <code>RETURNSUB</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SQUARE:</span></span> <span class="giallo-l"><span> dup1 ; 3 gas</span></span> <span class="giallo-l"><span> mul ; 5 gas</span></span> <span class="giallo-l"><span> returnsub ; 3 gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>CALL_SQUARE:</span></span> <span class="giallo-l"><span> push 0x02 ; 3 gas</span></span> <span class="giallo-l"><span> rjump SQUARE ; 3 gas</span></span></code></pre> <p><em>Total: 17 gas</em></p> <p>Tail call optimization, using <code>JUMP</code>:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas</span></span> <span class="giallo-l"><span> swap1 ; 3 gas</span></span> <span class="giallo-l"><span> dup1 ; 3 gas</span></span> <span class="giallo-l"><span> mul ; 5 gas</span></span> <span class="giallo-l"><span> swap2 ; 3 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>CALL_SQUARE:</span></span> <span class="giallo-l"><span> jumpdest ; 1 gas</span></span> <span class="giallo-l"><span> push 0x02 ; 3 gas</span></span> <span class="giallo-l"><span> push SQUARE ; 3 gas</span></span> <span class="giallo-l"><span> jump ; 8 gas</span></span></code></pre> <p><em>Total: 38 gas</em></p> <p>Using <code>RJUMPSUB</code> versus <code>JUMP</code> saves <em>38 - 17 = 21 gas</em> — a <em>55%</em> improvement.</p> <h4 id="efficiency-caveats">Efficiency Caveats</h4> <p>We can see that these instructions provide a simpler and more gas-efficient subroutine mechanism than using <code>JUMP</code> — in our examples they cut gas use by about half.</p> <p>Clearly, the benefits of this efficiency are greater for programs that have been factored into smaller subroutines. How small? Wrapping code in a subroutine costs only <em>8 gas</em> using <code>RJUMPSUB</code> and <code>RETURNSUB</code> versus <em>30 gas</em> using <code>JUMP</code>, <code>PUSH</code> and <code>SWAP</code> as above.</p> <h3 id="costs">Costs</h3> <p>The <em>low</em> cost of <code>RJUMPSUB</code> versus the <em>mid</em> cost of <code>JUMP</code> is justified by needing only to decode the immediate two byte destination to the <code>PC</code> and push the return address on the <code>return stack</code>, all using native arithmetic, versus using the data stack with emulated 256-bit instructions.</p> <p>The <em>verylow</em> cost of <code>RETURNSUB</code> is justified by needing only to pop the <code>return stack</code> into the <code>PC</code>. Benchmarking will be needed to tell if the costs are well-balanced.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These changes affect the semantics of existing EVM code: bytes that would have been interpreted as valid jump destinations may now be interpreted as immediate data. Since this proposal depends on the Ethereum Object Format to signal the change this is not a practical issue.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="simple-routine">Simple routine</h3> <p>This should jump into a subroutine, back out and stop.</p> <p>Bytecode: <code>0x5f0003005e</code> (<code>RJUMPSUB 3, RETURNSUB, STOP</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RJUMPSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>2</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> <tr><td>3</td><td>RETURNSUB</td><td>3</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Output: 0x Consumed gas: <code>10</code></p> <h3 id="two-levels-of-subroutines">Two levels of subroutines</h3> <p>This should execute fine, going into one two depths of subroutines</p> <p>Bytecode: <code>0x5f00045F00025200</code> (<code>RJUMPSUB 4, RJUMPSUB 2, RETURNSUB, RETURNSUB, STOP</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RJUMPSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>3</td><td>RJUMPSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>4</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>5</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>6</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Consumed gas: <code>20</code></p> <h3 id="failure-1-invalid-jump">Failure 1: invalid jump</h3> <p>This should fail, since the given location is outside of the code-range.</p> <p>Bytecode: <code>0X5fff</code>(<code>RJUMPSUB -1</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RJUMPSUB</td><td>10</td><td>[]</td><td>[]</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Error: at pc=0, op=RJUMPSUB: invalid jump destination</span></span></code></pre><h3 id="failure-2-shallow-return-stack">Failure 2: shallow <code>return stack</code></h3> <p>This should fail at first opcode, due to shallow <code>return_stack</code></p> <p>Bytecode: <code>0x5e</code> (<code>RETURNSUB</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[]</td></tr> </tbody></table> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Error: at pc=0, op=RETURNSUB: invalid retsub</span></span></code></pre><h3 id="subroutine-at-end-of-code">Subroutine at end of code</h3> <p>In this example the RJUMPSUB is on the last byte of code. When the subroutine returns, it should hit the 'virtual stop' <em>after</em> the bytecode, and not exit with error</p> <p>Bytecode: <code>0x5c00045e5fffff</code> (<code>RJUMP 4, RETURNSUB, RJUMPSUB -1</code>)</p> <table><thead><tr><th>Pc</th><th>Op</th><th>Cost</th><th>Stack</th><th>RStack</th></tr></thead><tbody> <tr><td>0</td><td>RJUMP</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>3</td><td>RETURNSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>4</td><td>RJUMPSUB</td><td>5</td><td>[]</td><td>[]</td></tr> <tr><td>7</td><td>STOP</td><td>0</td><td>[]</td><td>[]</td></tr> </tbody></table> <p>Consumed gas: <code>15</code></p> <h2 id="reference-implementation">Reference Implementation</h2> <p>The following is a pseudo-Python implementation of an algorithm for predicating code validity. An equivalent algorithm must be run at initialization time.</p> <p>This algorithm performs a symbolic execution of the program that recursively traverses the <em>code</em>, emulating its control flow and stack use and checking for violations of the rules above.</p> <p>It runs in time equal to <code>O(vertices + edges)</code> in the program's control-flow graph, where edges represent control flow and the vertices represent <em>basic blocks</em> — thus the algorithm takes time proportional to the size of the <em>code</em>. It maintains a stack of continuations for conditional jumps, the size of which is at most proportional to the size of the <em>code</em>.</p> <h3 id="validation-function">Validation Function</h3> <p>** Note: this function is known to be incomplete and incorrect. **</p> <p>For simplicity's sake we assume that all jumpdest analysis and prior validation has been done, including EIP-3540, EIP-3670, and EIP-4200, so EOF headers and sections are well-formed, and there are no invalid instructions or jumps. In practice, all passes of validation can be folded into a single loop no recursion.</p> <p>We also assume some helper functions.</p> <ul> <li><code>is_valid(opcode)</code> returns true iff opcode is valid.</li> <li><code>is_terminator(opcode)</code> returns true iff opcode is terminator.</li> <li><code>is_valid_jumpdest(pc)</code> returns true iff <code>pc</code> is a valid jump destination.</li> <li><code>immediate_data(pc)</code> returns the immediate data for the instruction at <code>pc</code>.</li> <li><code>immediate_size(opcode)</code> returns the size of the immediate data for an opcode.</li> <li><code>removed_items(opcode)</code> returns the number of items removed from the <code>data_stack</code> by the <code>opcode</code>.</li> <li><code>added_items(opcode)</code> returns the number of items added to the <code>data_stack</code> by the <code>opcode</code>.</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span># returns true iff code is valid</span></span> <span class="giallo-l"><span>def validate_code(code: bytes, pc: int, sp: int, bp: int) -&gt; boolean:</span></span> <span class="giallo-l"><span> continuations = []</span></span> <span class="giallo-l"><span> do</span></span> <span class="giallo-l"><span> while pc &lt; len(code):</span></span> <span class="giallo-l"><span> opcode = code[pc]</span></span> <span class="giallo-l"><span> if !is_valid(opcode):</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> if is_terminator(opcode):</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # check stack height and return if we have been here before</span></span> <span class="giallo-l"><span> stack_height = sp - bp</span></span> <span class="giallo-l"><span> if stack_height &gt; 1024</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> if pos in stack_heights:</span></span> <span class="giallo-l"><span> if stack_height != stack_heights[pos]:</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"><span> else:</span></span> <span class="giallo-l"><span> stack_heights[pos] = stack_height</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if opcode == RJUMP:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # reset pc to destination of jump</span></span> <span class="giallo-l"><span> jumpdest = immediate_data(pc)</span></span> <span class="giallo-l"><span> pc += jumpdest</span></span> <span class="giallo-l"><span> if !is_valid_jumpdest(pc)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == RJUMPI:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> jumpdest = pc + immediate_data(pc)</span></span> <span class="giallo-l"><span> if !is_valid_jumpdest(pc)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # continue true side of conditional later</span></span> <span class="giallo-l"><span> continations.push((jumpdest, sp, bp))</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # continue false side of conditional now</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == RJUMPSUB:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # will enter subroutine at destination</span></span> <span class="giallo-l"><span> bp = sp</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # push return address and reset pc to destination</span></span> <span class="giallo-l"><span> jumpdest = pc + immediate_data(pc)</span></span> <span class="giallo-l"><span> if !is_valid_jumpdest(pc)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> push(return_stack, pc + 3)</span></span> <span class="giallo-l"><span> pc = jumpdest</span></span> <span class="giallo-l"><span> continue</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> elif opcode == RETURNSUB:</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # will return to subroutine at destination</span></span> <span class="giallo-l"><span> bp = sp</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # pop return address and check for preceding call</span></span> <span class="giallo-l"><span> pc = pop(return_stack)</span></span> <span class="giallo-l"><span> if code[pc - 3] != RJUMPSUB:</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # apply instructions to stack</span></span> <span class="giallo-l"><span> sp -= removed_items(opcode)</span></span> <span class="giallo-l"><span> if sp &lt; 0</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> sp += added_items(opcode)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> # Skip opcode and immediate data</span></span> <span class="giallo-l"><span> pc += 1 + immediate_size(opcode)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> while (pc, sp, bp) = continuations.pop()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> return true</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>These changes introduce new flow control instructions. They do not introduce any new security considerations. This EIP is intended to improve security by validating a higher level of safety for EVM code deployed on the blockchain. The validation algorithm must be quasi-linear in time and space to not be a denial of service vulnerability. The algorithm here makes one linear-time pass of the bytecode, and uses a stack of continuations that cannot exceed the number of <code>RJUMPI</code> instructions in the code.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-08-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 John Adlerhttps://github.com/adlerjohn https://wg-eips.ritovision.com/2242/ <h2 id="simple-summary">Simple Summary</h2> <p>An additional, optional transaction field is added for "postdata," data that is posted on-chain but that cannot be read from the EVM.</p> <h2 id="abstract">Abstract</h2> <p>A paradigm shift in how blockchains are used has been seen recently in Eth 2.0, with the rise of <a rel="external" href="https://notes.ethereum.org/w1Pn2iMmSTqCmVUTGV4T5A?view"><em>Execution Environments</em></a> (EEs), and <a rel="external" href="https://ethresear.ch/t/the-stateless-client-concept/172"><em>stateless clients</em></a>. This shift involves blockchains serving as a secure data availability and arbitration layer, <em>i.e.</em>, they provide a globally-accepted source of available data, and process fraud/validity and data availability proofs. This same paradigm can be applied on Eth 1.x, replacing EEs with <a rel="external" href="https://ethresear.ch/t/building-scalable-decentralized-payment-systems-request-for-feedback/5312">trust-minimized side chains</a>.</p> <h2 id="motivation">Motivation</h2> <p>While <a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a> provides a reduction in gas cost of calldata, and is a step in the right direction of encouraging use of history rather than state, the EVM does not actually need to see all data that is posted on-chain. Following the principle of "don't pay for what you don't use," a distinct way of posting data on-chain, but without actually being usable within the EVM, is needed.</p> <p>For <a rel="external" href="https://ethresear.ch/t/minimal-viable-merged-consensus/5617">trust-minimized side chains with fraud proofs</a>, we simply need to ensure that the side chain block proposer has attested that <em>some</em> data is available. Authentication can be performed as part of a fraud proof should that data end up invalid. Note that <a rel="external" href="https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477">trust-minimized side chains with validity proofs</a> can't make use of the changes proposed in this EIP, as they required immediate authentication of the posted data. This will be <a rel="external" href="https://ethresear.ch/t/multi-threaded-data-availability-on-eth-1/5899">the topic of a future EIP</a>.</p> <h2 id="specification">Specification</h2> <p>We propose a consensus modification, beginning at <code>FORK_BLKNUM</code>:</p> <p>An additional optional field, <code>postdata</code>, is added to transactions. Serialized transactions now have the format:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>&quot;from&quot;: bytes20,</span></span> <span class="giallo-l"><span>&quot;to&quot;: bytes20,</span></span> <span class="giallo-l"><span>&quot;startGas&quot;: uint256,</span></span> <span class="giallo-l"><span>&quot;gasPrice&quot;: uint256,</span></span> <span class="giallo-l"><span>&quot;value&quot;: uint256,</span></span> <span class="giallo-l"><span>&quot;data&quot;: bytes,</span></span> <span class="giallo-l"><span>&quot;nonce&quot;: uint256,</span></span> <span class="giallo-l"><span>[&quot;postdata&quot;: bytes],</span></span></code></pre> <p>with witnesses signing over the <a rel="external" href="https://github.com/ethereum/wiki/wiki/RLP">RLP encoding</a> of the above. <code>postdata</code> is data that is posted on-chain, for later historical retrieval by layer-2 systems.</p> <p><code>postdata</code> is an RLP-encoded twople <code>(version: uint64, data: bytes)</code>.</p> <ol> <li><code>version</code> is <code>0</code>.</li> <li><code>data</code> is an RLP-encoded list of binary data. This EIP does not interpret the data in any way, simply considering it as a binary blob, though future EIPs may introduce different interpretation schemes for different values of <code>version</code>.</li> </ol> <p>The gas cost of the posted data is <code>1 gas per byte</code>. This cost is deducted from the <code>startGas</code>; if the remaining gas is non-positive the transaction immediately reverts with an out of gas exception.</p> <h2 id="rationale">Rationale</h2> <p>The changes proposed are as minimal and non-disruptive to the existing EVM and transaction format as possible while also supporting possible <a rel="external" href="https://ethresear.ch/t/multi-threaded-data-availability-on-eth-1/5899">future extensions</a> through a version code.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The new transaction format is backwards compatible, as the new <code>postdata</code> field is optionally appended to existing transactions.</p> <p>The proposed changes are not forwards-compatible, and will require a hard fork.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="implementation">Implementation</h2> <p>TODO</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-07-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/2200/ <h2 id="simple-summary">Simple Summary</h2> <p>This is an EIP that implements net gas metering. It's a combined version of <a href="https://wg-eips.ritovision.com/1283/">EIP-1283</a> and <a href="https://wg-eips.ritovision.com/1706/">EIP-1706</a>, with a structured definition so as to make it interoperable with other gas changes such as <a href="https://wg-eips.ritovision.com/1884/">EIP-1884</a>.</p> <h2 id="abstract">Abstract</h2> <p>This EIP provides a structured definition of net gas metering changes for <code>SSTORE</code> opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn’t match how most implementation works.</p> <p>This is a combination of <a href="https://wg-eips.ritovision.com/1283/">EIP-1283</a> and <a href="https://wg-eips.ritovision.com/1706/">EIP-1706</a>.</p> <h2 id="motivation">Motivation</h2> <p>This EIP proposes a way for gas metering on <code>SSTORE</code>, using information that is more universally available to most implementations, and require as little change in implementation structures as possible.</p> <ul> <li>Storage slot’s original value.</li> <li>Storage slot’s current value.</li> <li>Refund counter.</li> </ul> <p>Usages that benefits from this EIP’s gas reduction scheme includes:</p> <ul> <li>Subsequent storage write operations within the same call frame. This includes reentry locks, same-contract multi-send, etc.</li> <li>Exchange storage information between sub call frame and parent call frame, where this information does not need to be persistent outside of a transaction. This includes sub-frame error codes and message passing, etc.</li> </ul> <p>The original definition of EIP-1283 created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a "stipend" of 2300 gas to simple transfer calls. This danger is easily mitigated if <code>SSTORE</code> is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of EIP-1283.</p> <p>This EIP also replaces the original EIP-1283 value definitions of gas by parameters, so that it's more structured, and easier to define changes in the future.</p> <h2 id="specification">Specification</h2> <p>Define variables <code>SLOAD_GAS</code>, <code>SSTORE_SET_GAS</code>, <code>SSTORE_RESET_GAS</code> and <code>SSTORE_CLEARS_SCHEDULE</code>. The old and new values for those variables are:</p> <ul> <li><code>SLOAD_GAS</code>: changed from <code>200</code> to <code>800</code>.</li> <li><code>SSTORE_SET_GAS</code>: <code>20000</code>, not changed.</li> <li><code>SSTORE_RESET_GAS</code>: <code>5000</code>, not changed.</li> <li><code>SSTORE_CLEARS_SCHEDULE</code>: <code>15000</code>, not changed.</li> </ul> <p>Change the definition of EIP-1283 using those variables. The new specification, combining EIP-1283 and EIP-1706, will look like below. The terms <em>original value</em>, <em>current value</em> and <em>new value</em> are defined in EIP-1283.</p> <p>Replace <code>SSTORE</code> opcode gas cost calculation (including refunds) with the following logic:</p> <ul> <li>If <em>gasleft</em> is less than or equal to gas stipend, fail the current call frame with 'out of gas' exception.</li> <li>If <em>current value</em> equals <em>new value</em> (this is a no-op), <code>SLOAD_GAS</code> is deducted.</li> <li>If <em>current value</em> does not equal <em>new value</em> <ul> <li>If <em>original value</em> equals <em>current value</em> (this storage slot has not been changed by the current execution context) <ul> <li>If <em>original value</em> is 0, <code>SSTORE_SET_GAS</code> is deducted.</li> <li>Otherwise, <code>SSTORE_RESET_GAS</code> gas is deducted. If <em>new value</em> is 0, add <code>SSTORE_CLEARS_SCHEDULE</code> gas to refund counter.</li> </ul> </li> <li>If <em>original value</em> does not equal <em>current value</em> (this storage slot is dirty), <code>SLOAD_GAS</code> gas is deducted. Apply both of the following clauses. <ul> <li>If <em>original value</em> is not 0 <ul> <li>If <em>current value</em> is 0 (also means that <em>new value</em> is not 0), remove <code>SSTORE_CLEARS_SCHEDULE</code> gas from refund counter.</li> <li>If <em>new value</em> is 0 (also means that <em>current value</em> is not 0), add <code>SSTORE_CLEARS_SCHEDULE</code> gas to refund counter.</li> </ul> </li> <li>If <em>original value</em> equals <em>new value</em> (this storage slot is reset) <ul> <li>If <em>original value</em> is 0, add <code>SSTORE_SET_GAS - SLOAD_GAS</code> to refund counter.</li> <li>Otherwise, add <code>SSTORE_RESET_GAS - SLOAD_GAS</code> gas to refund counter.</li> </ul> </li> </ul> </li> </ul> </li> </ul> <p>An implementation should also note that with the above definition, if the implementation uses call-frame refund counter, the counter can go negative. If the implementation uses transaction-wise refund counter, the counter always stays positive.</p> <h2 id="rationale">Rationale</h2> <p>This EIP mostly achieves what a transient storage tries to do (<a href="https://wg-eips.ritovision.com/1087/">EIP-1087</a> and <a href="https://wg-eips.ritovision.com/1153/">EIP-1153</a>), but without the complexity of introducing the concept of "dirty maps", or an extra storage struct.</p> <ul> <li>We don't suffer from the optimization limitation of EIP-1087. EIP-1087 requires keeping a dirty map for storage changes, and implicitly makes the assumption that a transaction's storage changes are committed to the storage trie at the end of a transaction. This works well for some implementations, but not for others. After <a href="https://wg-eips.ritovision.com/658/">EIP-658</a>, an efficient storage cache implementation would probably use an in-memory trie (without RLP encoding/decoding) or other immutable data structures to keep track of storage changes, and only commit changes at the end of a block. For them, it is possible to know a storage's original value and current value, but it is not possible to iterate over all storage changes without incurring additional memory or processing costs.</li> <li>It never costs more gas compared with the current scheme.</li> <li>It covers all usages for a transient storage. Clients that are easy to implement EIP-1087 will also be easy to implement this specification. Some other clients might require a little bit extra refactoring on this. Nonetheless, no extra memory or processing cost is needed on runtime.</li> </ul> <p>Regarding <code>SSTORE</code> gas cost and refunds, see Appendix for proofs of properties that this EIP satisfies.</p> <ul> <li>For <em>absolute gas used</em> (that is, actual <em>gas used</em> minus <em>refund</em>), this EIP is equivalent to EIP-1087 for all cases.</li> <li>For one particular case, where a storage slot is changed, reset to its original value, and then changed again, EIP-1283 would move more gases to refund counter compared with EIP-1087.</li> </ul> <p>Examine examples provided in EIP-1087's Motivation (with <code>SLOAD_GAS</code> being <code>200</code>):</p> <ul> <li>If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged <code>20000 + 200 - 19800 = 400</code> gas.</li> <li>A contract with empty storage that increments slot 0 5 times will be charged <code>20000 + 5 * 200 = 21000</code> gas.</li> <li>A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, it will cost <code>5000 * 3 + 200 - 4800 = 10400</code> gas.</li> </ul> <p>In order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower than the gas stipend given to "transfer"/"send" in Solidity. These are other proposed remediations and objections to implementing them:</p> <ul> <li>Drop EIP-1283 and abstain from modifying <code>SSTORE</code> cost <ul> <li>EIP-1283 is an important update</li> <li>It was accepted and implemented on test networks and in clients.</li> </ul> </li> <li>Add a new call context that permits LOG opcodes but not changes to state. <ul> <li>Adds another call type beyond existing regular/staticcall</li> </ul> </li> <li>Raise the cost of <code>SSTORE</code> to dirty slots to &gt;=2300 gas <ul> <li>Makes net gas metering much less useful.</li> </ul> </li> <li>Reduce the gas stipend <ul> <li>Makes the stipend almost useless.</li> </ul> </li> <li>Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter <ul> <li>Still doesn’t make the invariant explicit.</li> <li>Requires callers to supply more gas, just to have it refunded</li> </ul> </li> <li>Add contract metadata specifying per-contract EVM version, and only apply <code>SSTORE</code> changes to contracts deployed with the new version.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork to implement. No gas cost increase is anticipated, and many contracts will see gas reduction.</p> <p>Performing <code>SSTORE</code> has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum Mainnet. Gas estimation should account for this requirement.</p> <h2 id="test-cases">Test Cases</h2> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>1612</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20812</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20812</td><td>19200</td><td>0</td><td>1</td><td>0</td><td></td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20812</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20812</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td></tr> <tr><td><code>0x60006000556000600055</code></td><td>5812</td><td>15000</td><td>1</td><td>0</td><td>0</td><td></td></tr> <tr><td><code>0x60006000556001600055</code></td><td>5812</td><td>4200</td><td>1</td><td>0</td><td>1</td><td></td></tr> <tr><td><code>0x60006000556002600055</code></td><td>5812</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td></tr> <tr><td><code>0x60026000556000600055</code></td><td>5812</td><td>15000</td><td>1</td><td>2</td><td>0</td><td></td></tr> <tr><td><code>0x60026000556003600055</code></td><td>5812</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td></tr> <tr><td><code>0x60026000556001600055</code></td><td>5812</td><td>4200</td><td>1</td><td>2</td><td>1</td><td></td></tr> <tr><td><code>0x60026000556002600055</code></td><td>5812</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556000600055</code></td><td>5812</td><td>15000</td><td>1</td><td>1</td><td>0</td><td></td></tr> <tr><td><code>0x60016000556002600055</code></td><td>5812</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556001600055</code></td><td>1612</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40818</td><td>19200</td><td>0</td><td>1</td><td>0</td><td>1</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>10818</td><td>19200</td><td>1</td><td>0</td><td>1</td><td>0</td></tr> </tbody></table> <h2 id="implementation">Implementation</h2> <p>To be added.</p> <h2 id="appendix-proof">Appendix: Proof</h2> <p>Because the <em>storage slot's original value</em> is defined as the value when a reversion happens on the <em>current transaction</em>, it's easy to see that call frames won't interfere <code>SSTORE</code> gas calculation. So although the below proof is discussed without call frames, it applies to all situations with call frames. We will discuss the case separately for <em>original value</em> being zero and not zero, and use <em>induction</em> to prove some properties of <code>SSTORE</code> gas cost.</p> <p><em>Final value</em> is the value of a particular storage slot at the end of a transaction. <em>Absolute gas used</em> is the absolute value of <em>gas used</em> minus <em>refund</em>. We use <code>N</code> to represent the total number of <code>SSTORE</code> operations on a storage slot. For states discussed below, refer to <em>State Transition</em> in <em>Explanation</em> section.</p> <p>Below we do the proof under the assumption that all parameters are unchanged, meaning <code>SLOAD_GAS</code> is <code>200</code>. However, note that the proof still applies no matter how <code>SLOAD_GAS</code> is changed.</p> <h3 id="original-value-being-zero">Original Value Being Zero</h3> <p>When <em>original value</em> is 0, we want to prove that:</p> <ul> <li><strong>Case I</strong>: If the <em>final value</em> ends up still being 0, we want to charge <code>200 * N</code> gases, because no disk write is needed.</li> <li><strong>Case II</strong>: If the <em>final value</em> ends up being a non-zero value, we want to charge <code>20000 + 200 * (N-1)</code> gas, because it requires writing this slot to disk.</li> </ul> <h4 id="base-case">Base Case</h4> <p>We always start at state A. The first <code>SSTORE</code> can:</p> <ul> <li>Go to state A: 200 gas is deducted. We satisfy <em>Case I</em> because <code>200 * N == 200 * 1</code>.</li> <li>Go to state B: 20000 gas is deducted. We satisfy <em>Case II</em> because <code>20000 + 200 * (N-1) == 20000 + 200 * 0</code>.</li> </ul> <h4 id="inductive-step">Inductive Step</h4> <ul> <li>From A to A. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>200 + 200 * (N-1)</code>. It satisfy <em>Case I</em>.</li> <li>From A to B. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>20000 + 200 * (N-1)</code>. It satisfy <em>Case II</em>.</li> <li>From B to B. The previous gas cost is <code>20000 + 200 * (N-2)</code>. The current gas cost is <code>200 + 20000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> <li>From B to A. The previous gas cost is <code>20000 + 200 * (N-2)</code>. The current gas cost is <code>200 - 19800 + 20000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> </ul> <h3 id="original-value-not-being-zero">Original Value Not Being Zero</h3> <p>When <em>original value</em> is not 0, we want to prove that:</p> <ul> <li><strong>Case I</strong>: If the <em>final value</em> ends up unchanged, we want to charge <code>200 * N</code> gases, because no disk write is needed.</li> <li><strong>Case II</strong>: If the <em>final value</em> ends up being zero, we want to charge <code>5000 - 15000 + 200 * (N-1)</code> gas. Note that <code>15000</code> is the refund in actual definition.</li> <li><strong>Case III</strong>: If the <em>final value</em> ends up being a changed non-zero value, we want to charge <code>5000 + 200 * (N-1)</code> gas.</li> </ul> <h4 id="base-case-1">Base Case</h4> <p>We always start at state X. The first <code>SSTORE</code> can:</p> <ul> <li>Go to state X: 200 gas is deducted. We satisfy <em>Case I</em> because <code>200 * N == 200 * 1</code>.</li> <li>Go to state Y: 5000 gas is deducted. We satisfy <em>Case III</em> because <code>5000 + 200 * (N-1) == 5000 + 200 * 0</code>.</li> <li>Go to state Z: The absolute gas used is <code>5000 - 15000</code> where 15000 is the refund. We satisfy <em>Case II</em> because <code>5000 - 15000 + 200 * (N-1) == 5000 - 15000 + 200 * 0</code>.</li> </ul> <h4 id="inductive-step-1">Inductive Step</h4> <ul> <li>From X to X. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>200 + 200 * (N-1)</code>. It satisfy <em>Case I</em>.</li> <li>From X to Y. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>5000 + 200 * (N-1)</code>. It satisfy <em>Case III</em>.</li> <li>From X to Z. The previous gas cost is <code>200 * (N-1)</code>. The current absolute gas cost is <code>5000 - 15000 + 200 * (N-1)</code>. It satisfy <em>Case II</em>.</li> <li>From Y to X. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The absolute current gas cost is <code>200 - 4800 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> <li>From Y to Y. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The current gas cost is <code>200 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case III</em>.</li> <li>From Y to Z. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 - 15000 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> <li>From Z to X. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 10200 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> <li>From Z to Y. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 15000 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case III</em>.</li> <li>From Z to Z. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Casey Detriohttps://github.com/cdetrio Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2045/ <h2 id="abstract">Abstract</h2> <p>According to recent benchmarks, EVM opcodes for computation (<code>ADD</code>, <code>SUB</code>, <code>MUL</code>, etc.) are generally overpriced relative to opcodes for storage I/O (<code>SLOAD</code>, <code>SSTORE</code>, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum.</p> <h2 id="motivation">Motivation</h2> <p>The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (<code>SSTORE</code>, <code>CREATE</code>, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in <a href="https://wg-eips.ritovision.com/2035/">EIP-2035</a>^{<a href="https://wg-eips.ritovision.com/2045/#eip2035">1</a>}, more research is needed on the potential effects of increasing the cost of storage opcodes).</p> <p>Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic).</p> <p>Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks^{<a href="https://wg-eips.ritovision.com/2045/#evmbenchmarks">2</a>} indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle", which is a fraction (or subdivision) of 1 gas, would enable large cost reductions.</p> <h2 id="specification">Specification</h2> <p>A new gas counter <code>particlesUsed</code> is added to the EVM, in addition to the existing gas counter <code>gasUsed</code>. The unit 1 gas is equal to 10000 particles (<code>PARTICLES_PER_GAS</code>). The <code>particlesUsed</code> counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing <code>particlesUsed</code> results in an excess of 1 gas, then 1 gas is added to <code>gasUsed</code> (and deducted from <code>particlesUsed</code>).</p> <p>Where the current gas logic looks like this:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> vm_execute</span><span>(</span><span class="z-variable z-parameter z-function">ext</span><span>,</span><span class="z-variable z-parameter z-function"> msg</span><span>,</span><span class="z-variable z-parameter z-function"> code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initialize stack, memory, program counter, etc</span></span> <span class="giallo-l"><span> compustate</span><span class="z-keyword"> =</span><span> Compustate</span><span>(</span><span class="z-variable">gas</span><span class="z-keyword">=</span><span>msg</span><span>.</span><span>gas</span><span>)</span></span> <span class="giallo-l"><span> codelen</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> compustate</span><span>.</span><span>pc</span><span class="z-keyword"> &lt;</span><span> codelen</span><span>:</span></span> <span class="giallo-l"><span> opcode</span><span class="z-keyword"> =</span><span> code</span><span>[</span><span>compustate</span><span>.</span><span>pc</span><span>]</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>pc</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>gasUsed</span><span class="z-keyword"> +=</span><span> opcode</span><span>.</span><span>gas_fee</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> out of gas error</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> compustate</span><span>.</span><span>gasUsed</span><span class="z-keyword"> &gt;</span><span> compustate</span><span>.</span><span>gasLimit</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> vm_exception</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">OUT OF GAS</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">STOP</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> peaceful_exit</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">ADD</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> +</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">SUB</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">MUL</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> *</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">...</span><span>.</span><span>.</span></span></code></pre> <p>The new gas logic using particles might look like this:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">PARTICLES_PER_GAS</span><span class="z-keyword"> =</span><span class="z-constant"> 10000</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> vm_execute</span><span>(</span><span class="z-variable z-parameter z-function">ext</span><span>,</span><span class="z-variable z-parameter z-function"> msg</span><span>,</span><span class="z-variable z-parameter z-function"> code</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Initialize stack, memory, program counter, etc</span></span> <span class="giallo-l"><span> compustate</span><span class="z-keyword"> =</span><span> Compustate</span><span>(</span><span class="z-variable">gas</span><span class="z-keyword">=</span><span>msg</span><span>.</span><span>gas</span><span>)</span></span> <span class="giallo-l"><span> codelen</span><span class="z-keyword"> =</span><span class="z-support"> len</span><span>(</span><span>code</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> compustate</span><span>.</span><span>pc</span><span class="z-keyword"> &lt;</span><span> codelen</span><span>:</span></span> <span class="giallo-l"><span> opcode</span><span class="z-keyword"> =</span><span> code</span><span>[</span><span>compustate</span><span>.</span><span>pc</span><span>]</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>pc</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> opcode</span><span>.</span><span>gas_fee</span><span>:</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>gasUsed</span><span class="z-keyword"> +=</span><span> opcode</span><span>.</span><span>gas_fee</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> opcode</span><span>.</span><span>particle_fee</span><span>:</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>particlesUsed</span><span class="z-keyword"> +=</span><span> opcode</span><span>.</span><span>particle_fee</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> compustate</span><span>.</span><span>particlesUsed</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> PARTICLES_PER_GAS</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> particlesUsed will be between 1 and 2 gas (over 10000 but under 20000)</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>gasUsed</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> remainder stays in particle counter</span></span> <span class="giallo-l"><span> compustate</span><span>.</span><span>particlesUsed</span><span class="z-keyword"> =</span><span> compustate</span><span>.</span><span>particlesUsed</span><span class="z-keyword"> %</span><span class="z-constant"> PARTICLES_PER_GAS</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> out of gas error</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> compustate</span><span>.</span><span>gasUsed</span><span class="z-keyword"> &gt;</span><span> compustate</span><span>.</span><span>gasLimit</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> vm_exception</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">OUT OF GAS</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">STOP</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> peaceful_exit</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">ADD</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> +</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">SUB</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> op</span><span class="z-keyword"> ==</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">MUL</span><span class="z-punctuation z-definition z-string">&#39;</span><span>:</span></span> <span class="giallo-l"><span> stk</span><span>.</span><span>append</span><span>(</span><span>stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span class="z-keyword"> *</span><span> stk</span><span>.</span><span>pop</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">...</span><span>.</span><span>.</span></span></code></pre> <p>The above pseudocode is written for clarity. A more performant implementation might instead keep a single <code>particlesUsed</code> counter by multiplying opcode gas costs by 10000 and the <code>gasLimit</code> by 10000, and convert particles back to gas with <code>ceil(particlesUsed / PARTICLES_PER_GAS)</code> at the end of execution. It may also be more performant to use a <code>PARTICLES_PER_GAS</code> ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected.</p> <h4 id="opcode-cost-changes">Opcode cost changes</h4> <p>Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of <code>DUP</code> and <code>SWAP</code> are reduced from 3 gas to 3000 particles (i.e. 0.3 gas). The cost of <code>ADD</code> and <code>SUB</code> are reduced from 3 gas to 6000 particles. The cost of <code>MUL</code> is reduced from 5 gas to 5000 particles (i.e. 0.5 gas).</p> <h2 id="rationale">Rationale</h2> <p>Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of <code>particles</code> need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected.</p> <h3 id="ewasm">Ewasm</h3> <p>The term "particles" was first introduced for Ewasm^{<a href="https://wg-eips.ritovision.com/2045/#particle">3</a>} to enable gas accounting for low cost wasm instructions, while remaining compatible with EVM gas costs. This EIP proposes introducing particles as a new minimum gas unit for EVM opcodes, and is not related to Ewasm.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires a hard fork to be activated.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="implementation">Implementation</h2> <p>TODO</p> <h2 id="references">References</h2> <p><a name="eip2035">1</a>. <a href="https://wg-eips.ritovision.com/2035/">EIP-2035</a>: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs</p> <p><a name="evmbenchmarks">2</a>. https://github.com/ewasm/benchmarking</p> <p><a name="particle">3</a>. The term "particle" was inspired by a proposal for <a rel="external" href="https://github.com/ewasm/design/blob/e77d8e3de42784f40a803a23f58ef06881142d9f/determining_wasm_gas_costs.md">Ewasm gas costs</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2046/ <h2 id="simple-summary">Simple Summary</h2> <p>This change reduces the gas cost of using precompiled contracts.</p> <h2 id="abstract">Abstract</h2> <p>Reduce the base gas cost of calling precompiles using <code>STATICCALL</code> from 700 to 40. This should allow more efficient use of precompiles as well as precompiles with a total cost below 700.</p> <h2 id="motivation">Motivation</h2> <p>The Spurious Dragon hard fork increased the cost of calls significantly to account for loading contract code from the state without making an exception for precompiles, whose "code" is always loaded.</p> <p>This made use of certain precompiles impractical.</p> <p>FIXME: extend this with recent reasoning about ECC repricings.</p> <h2 id="specification">Specification</h2> <p>After block <code>HF</code> the <code>STATICCALL</code> (<code>0xfa</code>) instruction charges different basic gas cost (G_call in <a rel="external" href="https://github.com/ethereum/yellowpaper">Yellow Paper</a>'s notation) depending on the destination address provided:</p> <ul> <li>for precompiles (address range as per <a href="https://wg-eips.ritovision.com/1352/">EIP-1352</a>) the cost is <code>40</code></li> <li>for every other address the cost remains unchanged (<code>700</code>)</li> </ul> <h2 id="rationale">Rationale</h2> <p>Only the <code>STATICCALL</code> instruction was changed to reduce the impact of the change. This should not be a limiting factor, given precompiles (currently) do not have a state and cannot change the state. However, contracts created and deployed before Byzantium likely will not use <code>STATICCALL</code> and as a result this change will not reduce their costs.</p> <p>Contrary to EIP-1109 gas reduction to <code>0</code> is not proposed. The cost <code>40</code> is kept as a cost representing the context switching needed.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP should be backwards compatible. The only effect is that the cost is reduced. Since the cost is not reduced to zero, it should not be possible for a malicious proxy contract, when deployed before the <code>HF</code>, to do any state changing operation.</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="references">References</h2> <p>This has been previously suggested as part of <a href="https://wg-eips.ritovision.com/1109/">EIP-1109</a> and <a rel="external" href="https://github.com/ethereum/EIPs/pull/1231">EIP-1231</a>. However EIP-1109 was later changed to a very different approach. The author <a rel="external" href="https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447/7">has suggested to change EIP-1109</a>.</p> <h2 id="acknowledgements">Acknowledgements</h2> <p>Jordi Baylina (@jbaylina) and Matthew Di Ferrante (@mattdf) who have proposed this before.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov https://wg-eips.ritovision.com/2035/ <h2 id="simple-summary">Simple Summary</h2> <p>The gas cost of EVM opcodes <code>SLOAD</code> and <code>SSTORE</code> increases in order to accommodate extra bandwidth required to propagate block proof together with the block headers and block bodies, as explained <a rel="external" href="https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc">here</a>.</p> <h2 id="abstract">Abstract</h2> <p>It is part of the State Rent roadmap. This particular change prepares Ethereum for introduction of the block proofs (current understanding is that they can be introuced without a hard fork). The introduction of the block proofs allows any Ethereum node that wishes to receive them, to process transactions in the blocks without needing to access the Ethereum state. All necessary information for the execution (and the proof of validity) is continued in the block proofs. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however, there will be more work to do to construct and transmit the block proofs. Therefore, the extra charge (payable to the miners) is introduced. In the first phase, only contract storage will be covered by the block proofs. It means that the Ethereum nodes will still need access to the accounts in the state, but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only <code>SSTORE</code> and <code>SLOAD</code> opcodes are affected.</p> <h2 id="motivation">Motivation</h2> <p>There is <a rel="external" href="https://github.com/holiman/vmstats/blob/master/README.md">empirical analysis</a> showing that <code>SLOAD</code> opcode is currently underpriced in terms of execution latency it adds to the block processing. The hypothesis is that it is due to the latency of the database accesses. In the same analysis, <code>SSTORE</code> is not considered, because its effect on the database accesses can be (and are in many implementations) delayed until the end of the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required. Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached <code>SSTORE</code> or <code>SLOAD</code> adds at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both operations by 69k gas. However, in light of proposal in <a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a>, the increase can be made much smaller.</p> <h2 id="specification">Specification</h2> <p>Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations <code>SLOAD</code> and <code>SSTORE</code> increases by <code>X</code> gas when the storage slots accessed (read by <code>SLOAD</code> or written by <code>SSTORE</code>) were not previously accessed (by another <code>SLOAD</code> or <code>SSTORE</code>) during the same transaction.</p> <p>Future variant (will be possible after the implementation of the <em>Gross contract size acccounting</em>) is researched, where the increase is varied depending on the size of the contract storage, i.e. <code>SLOAD</code> and <code>SSTORE</code> for smaller contracts will be cheaper.</p> <h2 id="rationale">Rationale</h2> <p><a href="https://wg-eips.ritovision.com/1884/">EIP-1884</a> seeks to increase the gas cost of <code>SLOAD</code> but using a different justification (latency of the execution as described in the Motivation). This EIP is likely to increase the cost of <code>SLOAD</code> by a larger amount, therefore partially (because EIP-1884 also proposed other increases) supersedes EIP-1884.</p> <p><a href="https://wg-eips.ritovision.com/2028/">EIP-2028</a> describes the model that can be used for deciding the gas cost of data transmission. It is relevant because in the stateless client regime <code>SSTORE</code> and <code>SLOAD</code> operations add more data to be transmitted (as well as computation to verify the proofs).</p> <p>The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing vulnerability problem, and so far the solution seems to be in redesigning and rewriting smart contracts in a way, which makes them not vulnerable. However, this approach is likely to be very expensive on the non-technical (ecosystem) level.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires hard fork to be activated. There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and <a href="https://wg-eips.ritovision.com/2026/">EIP-2026</a> (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of <code>SLOAD</code> and <code>SSTORE</code> and hard-code them in their internal gas computations. For others, the cost of interacting with the contract storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully analyse the potentially impacted contracts.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests cases will be generated out of a reference implementation.</p> <h2 id="implementation">Implementation</h2> <p>There will be proof of concept implementation to refine and clarify the specification.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov https://wg-eips.ritovision.com/2029/ <h2 id="simple-summary">Simple Summary</h2> <p>A smart contract is deployed on all Ethereum networks, at a pre-determined address, with the code that simply reads the slot in its storage specified by the only parameter. Later, this contract becomes "special" in that Ethereum start writing state counters (number of total transactions, number of accounts, etc.) into that contract.</p> <h2 id="abstract">Abstract</h2> <p>This is part of the State Rent roadmap. This particular change introduces a place in the Ethereum state where various state counters can be stored. At this point, the most important counter is the total number of transactions happened, and this counter will be used to populate the nonces of newly created non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum currently does not have a special place in the state for tracking state counters such as number of transactions or number of accounts.</p> <h2 id="specification">Specification</h2> <p>Prior to the block A, a contract is deployed with the following code: <code>0x60 0x20 0x60 0x00 0x80 0x80 0x35 0x54 0x90 0x52 0xF3</code>, which corresponds to this assembly: <code>PUSH1 32 PUSH1 0 DUP1 DUP1 CALLDATALOAD SLOAD SWAP1 MSTORE RETURN</code> Call to this contract accepts one 32-byte argument, <code>x</code>, and returns the value of the storage item [<code>x</code>].</p> <p>This contract is deployed using <code>CREATE2</code> opcode in such a way that it has the same address on any network.</p> <h2 id="rationale">Rationale</h2> <p>Two alternative solutions were considered so far:</p> <ol> <li>Extending the structure of the Ethereum state to introduce more fields, and hence change the way the state root is constructed. The main downside of this approach is the impact on the software what is currently coupled with the particular way the state root is constructed. Particularly it affects the software that deals with merkle proofs derived from the state root.</li> <li>Extended State Oracle (<a href="https://wg-eips.ritovision.com/2014/">EIP-2014</a>). Under such proposal, there will be a precompile contract with standardised interface, capable of returning current values of the counters. However, the actual data being returned by such oracle is not explicitly in the state, and is not Merkelised. It means that all the counters need to be added to the snapshots when the snapshot sync is perform, so they still present in the state, but implicitly.</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is backwards compatible and does not require hard fork to be activated.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests cases will be created to ensure that the state counter contract returns its storage items correctly.</p> <h2 id="implementation">Implementation</h2> <p>Implementation is envisaged as a transaction that can be posted from any Ethereum address and will cause the deployment of the state counter contract.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov https://wg-eips.ritovision.com/2031/ <h2 id="simple-summary">Simple Summary</h2> <p>Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore it is called <em>Net</em> transaction count). It is done by incrementing a storage slot in the special contract, called <em>State counter contract</em> (<a href="https://wg-eips.ritovision.com/2029/">EIP-2029</a>).</p> <h2 id="abstract">Abstract</h2> <p>It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot in the <em>State counter contract</em>. This counter will be used to populate the nonces of newly created non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum currently does not have a special place in the state for tracking number of transactions.</p> <h2 id="specification">Specification</h2> <p>A new field, with the location 0 (that means it resides in the storage slot 0 in the state counter contract, and can be read by calling that contract with argument being 32 zero bytes), is added to the state counter contract. It will eventually contain <code>txCount</code>, the total number of transactions processed up until that point. On an after block B, or after the deployment of the state counter contract (which comes first), the field <code>txCount</code> is incremented after each transaction. Updating <code>txCount</code> means updating the storage of state counter contract at the location 0. These changes are never reverted.</p> <h2 id="rationale">Rationale</h2> <p>Two main alternatives were proposed for the replay protection of the accounts that were evicted by subsequently brought back by sending ether to them:</p> <ol> <li>Temporal replay protection. The nonce of the new accounts (and those brought back) is still zero, but a new <code>valid-until</code> field is introduced, making transactions invalid for inclusion after the time specified in this field. This, however, has unwanted side effected related to the fact that account nonces are not only used for replay protection, but also for computing the addresses of the deployed contracts (except those created by <code>CREATE2</code>).</li> <li>Setting nonce of new accounts (and those brought back) to something depending on the current block number. This approach requires coming up with an arbitrary parameter, which is the maximum number of transaction in the block, so that the new nonces never clash with the existing nonces. This is mostly a concern for private networks at the moment, because they will potentially have significantly more transactions in a block.</li> </ol> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires hard fork to be activated.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests cases will be generated out of a reference implementation.</p> <h2 id="implementation">Implementation</h2> <p>There will be proof of concept implementation to refine and clarify the specification.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov https://wg-eips.ritovision.com/2026/ <h2 id="simple-summary">Simple Summary</h2> <p>Creation of new accounts (both contracts and non-contracts) requires a fixed one-off rent prepayment. Pre-existed accounts require the same prepayment upon the first modification. The act of rent prepayment causes the addition of an extra field to accounts, called <code>rentbalance</code>. This field becomes part of state.</p> <h2 id="abstract">Abstract</h2> <p>This is part of the State Rent roadmap. This particular change introduces a fixed charge for state expansion that comes from adding new accounts to the state. Theoretically, it puts a bound on the number of accounts that can be ever created, because that fixed charge cannot be recycled via mining.</p> <h2 id="motivation">Motivation</h2> <p>The penalty is levied to the transaction sender. Rather than raising the gas cost of account creation (that would direct levy towards the miner), this change directs prepayment into the account's special field, <code>rentbalance</code>. It addresses several shortcomings of the simple raising of the gas cost:</p> <ol> <li>Prepayments cannot be recycled via mining, which puts a theoretical bound on number of accounts in the state (though it is unlikely to ever be reached).</li> <li>It is not possible for miners to circumvent the penalty or to extend such circumventions onto other users (via private fee rebates, for example).</li> <li>This prepayment will be used to cover state rent in the future, and it will allow newly created contracts with 0 endowment not to be evicted in the same block.</li> <li>It makes is possible to refund <code>rentbalance</code> upon self-destruction - when contract is self-destructed, both <code>balance</code> and <code>rentbalance</code> are returned.</li> <li>Prepayments on pre-existing accounts are necessary to prevent hoarding of accounts ahead of this change.</li> </ol> <h2 id="specification">Specification</h2> <p>On and after block <code>H</code>, every newly created account gets a new field <code>rentbalance</code> of type unsigned 256-bit integer. On and after block <code>H</code>, any operation that leads to the creation of a new account, deducts the amount <code>ACCOUNT_PREPAYMENT</code> from <code>tx.origin</code>. This amount is added to the <code>rentbalance</code> field of the created account. On and after block <code>H</code>, any operation that modifies an account that does not yet have <code>rentbalance</code> field, deducts the amount <code>ACCOUNT_PREPAYEMENT</code> from <code>tx.origin</code>. This amount is added to the <code>rentbalance</code> field of the modified account. This is an anti-hoarding measure.</p> <p>Operations leading to the creations of a new account:</p> <ol> <li>Creation of a non-contract account by sending non-zero ETH to an address with no associated account</li> <li>Creation of a non-contract account by the block with <code>coinbase</code> pointing to an address with no associated account</li> <li>Creation of a non-contract account by <code>SELFDESTRUCT</code> with the argument being an address with no associated account</li> <li>Creation of a contract by transaction without destination but with data. This can result in either converting a non-countract account into a contract account, or creation of a contract account.</li> <li>Creation of a contract by execution of <code>CREATE</code> or <code>CREATE2</code>. This can result in either converting a non-countract account into a contract account, or creation of a contract account.</li> </ol> <p>After prepayments are introduced, there can be two reasons for ether to be deducted from <code>tx.origin</code>: purchasing and spending gas, and spending gas for prepayments. Gaslimit of a transaction currently plays a role of safety limit, where <code>gaslimit</code> * <code>gasprice</code> represents the maximum amount of wei the sender (<code>tx.origin</code>) authorises the transaction to deduct from its account. After prepayments are introduced, <code>gaslimit</code> * <code>gasprice</code> will still represent the maximum amount of wei spend, but it will be used for both gas purchases and prepayments, as necessary.</p> <h2 id="rationale">Rationale</h2> <p>Prior to rent prepayments, other alternatives were considered:</p> <ol> <li>Simple raising of the gas cost - discussed in the Motivation section.</li> <li>In <a rel="external" href="https://github.com/ledgerwatch/eth_state/blob/master/State_rent.pdf">first version of State Rent proposal</a>, there was no notion of extra levy upon account creation. It created a slight usability issue, where newly created contracts with 0 endowment would be evicted in the same block (when rent is introduced). It delays the benefits of the State Rent programme until the actual introduction of rent (in second or third hard-fork).</li> <li>In the <a rel="external" href="https://github.com/ledgerwatch/eth_state/blob/master/State_Rent_2.pdf">second version of State Rent proposal</a>, there was a notion of lock-up. It is very similar to rent prepayment, with the different that lock-up would not be covering future rent payments.</li> </ol> <p>An alternative approach to limiting the prepayments (instead of the using <code>gaslimit</code> * <code>gasprice</code> as the limit) is to introduce a new dedicated field <code>prepaymenlimit</code> into the transaction. This field would only limit prepayments. Such approach would require changes in the transaction format, as well as changes in the user interface for transaction sender, and having two counters during the transaction execution - one for gas, and one for prepayments.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires hard fork to be activated. It might have some adverse effects on the existing contracts, due to more gas needed to be allocated for the creation of new accounts. These adverse effects need to analysed in more detail.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests cases will be generated out of a reference implementation.</p> <h2 id="implementation">Implementation</h2> <p>There will be proof of concept implementation to refine and clarify the specification.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov https://wg-eips.ritovision.com/2027/ <h2 id="simple-summary">Simple Summary</h2> <p>Ethereum starts counting the number of storage slots filled and emptied in the contracts. Since the number of pre-existing slots is not currently accounted in the state, effectively, only net change in the number of slots is tracked. In the subsequent change, called <em>Gross contract size accounting</em>, the total number of storage slots starts being tracked.</p> <h2 id="abstract">Abstract</h2> <p>This is part of the State Rent roadmap. This particular change introduces initial, net accounting of the number of the contract storage slots. Though not very useful on its own, it makes it possible to introduce gross accounting of the number of storage slots, which is useful for number of things:</p> <ol> <li>Gas cost of operations suchs as <code>SLOAD</code> and <code>SSTORE</code> will need to be increased to compensate for extra bandwidth consumed by the block proofs. Although in the beginning the cost would be fixed, it will later be automatically calibrated depending on the size of the contract <code>SLOAD</code> and <code>SSTORE</code> operate on.</li> <li>Snapshot sync protocols, like <em>fast sync</em>, <em>warp sync</em>, <em>firehose</em>, <em>red queen</em>, and perhaps others, will benefit from having the correct size of the contract storage present in the state (and therefore being provable via Merkle proofs).</li> </ol> <h2 id="motivation">Motivation</h2> <p>Ethereum currently does not track the number of contract storage slots at all, and producing such number given the downloaded state cannot be done in constant <em>O(1)</em> time.</p> <h2 id="specification">Specification</h2> <p>Each contract (account with <code>codeHash</code> field not equal to 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, which the hash of the empty code) gets a new uint64 field, called <code>storagesize</code>. On and after block <code>C</code>, the semantics of the operation <code>SSTORE</code> (<code>location</code>, <code>value</code>) changes as follows:</p> <ul> <li>If previous value of the [<code>location</code>] is 0, and value is not 0, <em>increment</em> <code>storagesize</code> (semantics of <em>increment</em> described below)</li> <li>If previous value of the [<code>location</code>] is not 0, and value is 0, <em>decrement</em> <code>storagesize</code> (semantics of <em>decrement</em> described below)</li> <li>As with other state changes, changes of <code>storagesize</code> get reverted when the execution frame reverts, i.e. it needs to use the same techniques as storage values, like journalling (in Geth), and substates (in Parity). Value of <code>storagesize</code> is not observable from contracts at this point.</li> </ul> <h3 id="semantics-of-increment-storagesize">Semantics of <em>increment</em> <code>storagesize</code></h3> <p>If <code>storagesize</code> is not present, <code>storagesize</code> = <code>HUGE_NUMBER</code> + 1. If <code>storagesize</code> is present, <code>storagesize</code> = <code>storagesize</code> + 1.</p> <h3 id="semantics-of-decrement-storagesize">Semantics of <em>decrement</em> <code>storagesize</code></h3> <p>If <code>storagesize</code> is not present, <code>storagesize</code> = <code>HUGE_NUMBER</code> - 1. If <code>storagesize</code> is present, <code>storagesize</code> = <code>storagesize</code> - 1.</p> <h3 id="note-of-huge-number">Note of <code>HUGE_NUMBER</code></h3> <p>There is a constant <code>HUGE_NUMBER</code>. It needs to be large enough so that no real metrics (contract storage size, number of accounts, number of contracts, total size of code, total size of storage) will never reach that number, and small enough that it fits in an unsigned 64-bit integer. Current suggestion is to have <code>HUGE_NUMBER</code> = 2^63, which is binary representation is the a single bit in a 64-bit number.</p> <p>The idea is to make it decidable later whether the storagesize was ever incremented/decremented (presence of the field), and whether it has been converted from net to gross (by value being smaller than <code>HUGE_NUMBER/2</code> - because it will not be possible for any contract be larger than 2^62 at the block <code>C</code>).</p> <h2 id="rationale">Rationale</h2> <p>A mechanism for estimation of contract storage size has been proposed <a rel="external" href="https://medium.com/@akhounov/estimation-approximate-of-the-size-of-contracst-in-ethereum-4642fe92d6fe">here</a>. But it does have a big drawback of introducing a lot of complexity into the consensus (in the form of estimation algorithm, which has quite a few edge cases to cater for different sizes of the storage).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires hard fork to be activated. Since the newly introduced field is not observable, this change does not impact any operations of the existing smart contracts.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests cases will be generated out of a reference implementation.</p> <h2 id="implementation">Implementation</h2> <p>There will be proof of concept implementation to refine and clarify the specification.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/2014/ <h2 id="simple-summary">Simple Summary</h2> <h2 id="abstract">Abstract</h2> <p>Introduce a new system contract with an extensible interface following the <a rel="external" href="https://solidity.readthedocs.io/en/latest/abi-spec.html">Contract ABI Encoding</a> to access extended data sets, such as chain identifiers, block hashes, etc.</p> <p>This allows Ethereum contract languages to interact with this contract as if it were a regular contract and not needing any language support.</p> <h2 id="motivation">Motivation</h2> <p>Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes (<a href="https://wg-eips.ritovision.com/210/">EIP-210</a>) and chain identifiers (<a href="https://wg-eips.ritovision.com/1344/">EIP-1344</a>).</p> <p>Adding them as EVM opcodes seems to be using the scarce opcode space for relatively less frequently used features, while adding them as precompiles is perceived as more complicated due to an interface needs to be defined and agreed on for every case.</p> <p>This proposal tries to solve both issues with defining an extensible standard interface.</p> <h2 id="specification">Specification</h2> <p>A new system contract ("precompile") is introduced at address <code>0x0000000000000000000000000000000000000009</code> called ESO (Extended State Oracle).</p> <p>It can be queried using <code>CALL</code> or <code>STATICCALL</code> and follows the <a rel="external" href="https://solidity.readthedocs.io/en/latest/abi-spec.html">Contract ABI Encoding</a> for the inputs and outputs. Using elementary types in the ABI encoding is encouraged to keep complexity low.</p> <p>In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what <a href="https://wg-eips.ritovision.com/210/">EIP-210</a> proposed.</p> <p>Proposals wanting to introduce more data to the state, which is not part of blocks or transactions, should aim to extend the ESO.</p> <p>At this time it is not proposed to make the ESO into a contract existing in the state, but to include it as a precompile and leave the implementation details to the client. In the future if it is sufficiently extended and a need arises to have a state, it would make sense to move it from being a precompile and have actual code.</p> <h3 id="chain-identifier">Chain identifier</h3> <p>Initially, a feature to read the current chain identifier is introduced: <code>getCurrentChainId()</code> returns the current chain identifier as a <code>uint64</code> encoded value. It should be a non-payable function, which means sending any value would revert the transaction as described in <a href="https://wg-eips.ritovision.com/140/">EIP-140</a>. This has been proposed as <a href="https://wg-eips.ritovision.com/1344/">EIP-1344</a>.</p> <p>The contract ABI JSON is the following:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>[</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> true</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span> [</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">getCurrentChainId</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span> [</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">uint64</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> ]</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant"> false</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">stateMutability</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">pure</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>This will be translated into sending the bytes <code>5cf0e8a4</code> to the ESO and returning the bytes <code>0000000000000000000000000000000000000000000000000000000000000001</code> for Ethereum mainnet.</p> <p><strong>Note:</strong> It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see <a rel="external" href="https://github.com/ethereum/EIPs/pull/1959">EIP-1959</a> and <a rel="external" href="https://github.com/ethereum/EIPs/pull/1965">EIP-1965</a>).</p> <h2 id="rationale">Rationale</h2> <p>TBA</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>TBA</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-05-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov Eli Ben Sassoneli@starkware.co Tom Brandtom@starkware.co Louis Guthmannlouis@starkware.co Avihu Levyavihu@starkware.co https://wg-eips.ritovision.com/2028/ <h2 id="simple-summary">Simple Summary</h2> <p>We propose to reduce the gas cost of Calldata (<code>GTXDATANONZERO</code>) from its current value of 68 gas per byte to 16 gas per byte, to be backed by mathematical modeling and empirical estimates. The mathematical model is the one used in the works of Sompolinsky and Zohar [1] and Pass, Seeman and Shelat [2], which relates network security to network delay. We shall (1) evaluate the theoretical impact of lower Calldata gas cost on network delay using this model, (2) validate the model empirically, and (3) base the proposed gas cost on our findings.</p> <h2 id="motivation">Motivation</h2> <p>There are a couple of main benefits to accepting this proposal and lowering gas cost of Calldata On-Chain Scalability: Generally speaking, higher bandwidth of Calldata improves scalability, as more data can fit within a single block.</p> <ul> <li>Layer two scalability: Layer two scaling solutions can improve scalability by moving storage and computation off-chain, but often introduce data transmission instead. <ul> <li>Proof systems such as STARKs and SNARKs use a single proof that attests to the computational integrity of a large computation, say, one that processes a large batch of transactions.</li> <li>Some solutions use fraud proofs which requires a transmission of merkle proofs.</li> <li>Moreover, one optional data availability solution to layer two is to place data on the main chain, via Calldata.</li> </ul> </li> <li>Stateless clients: The same model will be used to determine the price of the state access for the stateless client regime, which will be proposed in the State Rent (from version 4). There, it is expected that the gas cost of state accessing operation will increase roughly proportional to the extra bandwidth required to transmit the “block proofs” as well as extra processing required to verify those block proofs.</li> </ul> <h2 id="specification">Specification</h2> <p>The gas per non-zero byte is reduced from 68 to 16. Gas cost of zero bytes is unchanged.</p> <h2 id="rationale">Rationale</h2> <p>Roughly speaking, reducing the gas cost of Calldata leads to potentially larger blocks, which increases the network delay associated with data transmission over the network. This is only part of the full network delay, other factors are block processing time (and storage access, as part of it). Increasing network delay affects security by lowering the cost of attacking the network, because at any given point in time fewer nodes are updated on the latest state of the blockchain.</p> <p>Yonatan Sompolinsky and Aviv Zohar suggested in [1] an elegant model to relate network delay to network security, and this model is also used in the work of Rafael Pass, Lior Seeman and Abhi Shelat [2]. We briefly explain this model below, because we shall study it theoretically and validate it by empirical measurements to reach the suggested lower gas cost for Calldata.</p> <p>The model uses the following natural parameters:</p> <ul> <li><em>lambda</em> denotes the block creation rate [1/s]: We treat the process of finding a PoW solution as a poisson process with rate <em>lambda</em>.</li> <li><em>beta</em> - chain growth rate [1/s]: the rate at which new blocks are added to the heaviest chain.</li> <li><em>D</em> - block delay [s]: The time that elapses between the mining of a new block and its acceptance by all the miners (all miners switched to mining on top of that block).</li> </ul> <h3 id="beta-lower-bound"><em>Beta</em> Lower Bound</h3> <p>Notice that <em>lambda</em> =&gt; <em>beta</em>, because not all blocks that are found will enter the main chain (as is the case with uncles). In [1] it was shown that for a blockchain using the longest chain rule, one may bound <em>beta</em> from below by <em>lambda</em>/ (1+ D * <em>lambda</em>). This lower bound holds in the extremal case where the topology of the network is a clique in which the delay between each pair of nodes is D, the maximal possible delay. Recording both the lower and upper bounds on <em>beta</em> we get</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>_lambda_ &gt;= _beta_ &gt;= _lambda_ / (1 + D * _lambda_) (*)</span></span></code></pre> <p>Notice, as a sanity check, that when there is no delay (D=0) then <em>beta</em> equals <em>lambda</em>, as expected.</p> <h3 id="security-of-the-network">Security of the network</h3> <p>An attacker attempting to reorganize the main chain needs to generate blocks at a rate that is greater than <em>beta</em>. Fixing the difficulty level of the PoW puzzle, the total hash rate in the system is correlated to <em>lambda</em>. Thus, <em>beta</em> / <em>lambda</em> is defined as the <em>efficiency</em> of the system, as it measures the fraction of total hash power that is used to generate the main chain of the network.</p> <p>Rearranging (*) gives the following lower bound on efficiency in terms of delay:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>_beta_ / _lambda_ &gt;= 1 / (1 + D * _lambda_) (**)</span></span></code></pre><h3 id="the-delay-parameter-d">The <em>delay</em> parameter D</h3> <p>The network delay depends on the location of the mining node within the network and on the current network topology (which changes dynamically), and consequently is somewhat difficult to measure directly. Previously, Christian Decker and Roger Wattenhofer [3] showed that propagation time scales with blocksize, and Vitalik Buterin showed that uncle rate, which is tightly related to efficiency (**) measure, also scales with block size [4].</p> <p>However, the delay function can be decomposed into two parts D = <em>D_t</em> + <em>D_p</em>, where <em>D_t</em> is the delay caused by the transmission of the block and <em>D_p</em> is the delay caused by the processing of the block by the node. Our model and tests will examine the effect of Calldata on each of <em>D_t</em> and <em>D_p</em>, postulating that their effect is different. This may be particularly relevant for Layer 2 Scalability and for Stateless Clients (Rationales 2, 3 above) because most of the Calldata associated with these goals are Merkle authentication paths that have a large <em>D_t</em> component but relatively small <em>D_p</em> values.</p> <h2 id="test-cases">Test Cases</h2> <p>To suggest the gas cost of calldata we shall conduct two types of tests:</p> <ol> <li>Network tests, conducted on the Ethereum mainnet, used to estimate the effect on increasing block size on <em>D_p</em> and <em>D_t</em>, on the overall network delay D and the efficiency ratio (**), as well as delays between different mining pools. Those tests will include regression tests on existing data, and stress tests to introduce extreme scenarios.</li> <li>Local tests, conducted on a single node and measuring the processing time as a function of Calldata amount and general computation limits.</li> </ol> <h2 id="reference-implementation">Reference Implementation</h2> <p><a rel="external" href="https://github.com/liorgold2/parity-ethereum/pull/1">Parity</a> <a rel="external" href="https://github.com/liorgold2/go-ethereum/pull/1">Geth</a></p> <h2 id="references">References</h2> <p>[1] Yonatan Sompolinsky, Aviv Zohar: <a rel="external" href="https://eprint.iacr.org/2013/881.pdf">Secure High-Rate Transaction Processing in Bitcoin</a>. Financial Cryptography 2015: 507-527</p> <p>[2] Rafael Pass, Lior Seeman, Abhi Shelat: <a rel="external" href="https://eprint.iacr.org/2016/454.pdf">Analysis of the Blockchain Protocol in Asynchronous Networks</a>, ePrint report 2016/454</p> <p>[3] Christian Decker, Roger Wattenhofer: <a rel="external" href="https://www.gsd.inesc-id.pt/~ler/docencia/rcs1314/papers/P2P2013_041.pdf">Information propagation in the Bitcoin network</a>. P2P 2013: 1-10</p> <p>[4] Vitalik Buterin: <a rel="external" href="https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/">Uncle Rate and Transaction Fee Analysis</a></p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Vlasovhttps://github.com/shamatar https://wg-eips.ritovision.com/1962/ <h1 id="simple-summary">Simple summary</h1> <p>This proposal is an extension and formalization of <a href="https://wg-eips.ritovision.com/1829/">EIP-1829</a> with an inclusion of pairings. <a href="https://wg-eips.ritovision.com/1109/">EIP-1109</a> is required due to low cost of some operations compared to the <code>STATICCALL</code> opcode (more information in the corresponding section below).</p> <h2 id="abstract">Abstract</h2> <p>This EIP proposes a new precompile to bring cryptographic functionality desired for privacy and scaling solutions. Functionality of such precompile will require the following:</p> <ul> <li>Implementation the following operations over elliptic curves in the Weierstrass form with curve parameters such as base field, A, B coefficients defined in runtime: <ul> <li>Point addition</li> <li>Multiplication of a single point over a scalar</li> <li>Multiexponentiation</li> </ul> </li> <li>Implementation pairing operation over elliptic curves from the following "families" with parameters such as base field, extension tower structure, coefficients defined in runtime: <ul> <li>BLS12</li> <li>BN</li> <li>MNT4/6 (Ate pairing)</li> </ul> </li> </ul> <p>Full functionality of the precompile is described below in <code>Specification</code> section.</p> <h2 id="motivation">Motivation</h2> <ul> <li>There is a pending proposal to implement base elliptic curve arithmetic is covered by <a href="https://wg-eips.ritovision.com/1829/">EIP-1829</a> and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation.</li> <li>Pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: <ul> <li>Extended set of curves will be available to allow Ethereum users to choose their security parameters and required functionality.</li> <li>Generic approach of this precompile will allow Ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks.</li> <li>EC arithmetic is indeed re-implemented in this precompile, but it's strictly required. Most of the pairing-based protocols still need to perform standard EC multiplications or additions and thus such operations must be available on generic set of curves.</li> </ul> </li> <li>Gas costs - this EIP is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. This is a strict requirement for any precompile to allow Ethereum nodes to efficiently reject transactions and operations as early as possible.</li> </ul> <p>Functionality of this newly proposed precompile is different from <a href="https://wg-eips.ritovision.com/1829/">EIP-1829</a> in the following aspects:</p> <ul> <li>Operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve</li> <li>Pairing operations are introduced</li> <li>Different ABI due to variable parameter length</li> </ul> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= XXXXX</code>, define a set of <code>10</code> new precompiles with an addresses <code>[0x.., 0x.., ...]</code> and the following functionality.</p> <ul> <li>Addition of points on the curve defined over base field</li> <li>Multiplication of a point on the curve defined over base field</li> <li>Multiexponentiation for <code>N</code> pairs of <code>(scalar, point)</code> on the curve defined over base field</li> <li>Addition of points on the curve defined over quadratic or cubic extension of the base field</li> <li>Multiplication of a point on the curve defined over quadratic or cubic extension of the base field</li> <li>Multiexponentiation for <code>N</code> pairs of <code>(scalar, point)</code> on the curve defined over quadratic or cubic extension of the base field</li> <li>Pairing operation on the curve of <code>BLS12</code> family</li> <li>Pairing operation on the curve of <code>BN</code> family</li> <li>Pairing operation on the curve of <code>MNT4</code> family</li> <li>Pairing operation on the curve of <code>MNT6</code> family</li> </ul> <p>Due to actuve development of the precompile and a lot of ongoing changes there is a single <a rel="external" href="https://github.com/matter-labs/eip1962/tree/master/documentation">source of truth</a>. It covers binary interface, gas schedule, integration guide for existing implementations.</p> <h3 id="possible-simplifications">Possible simplifications</h3> <p>Due to high complexity of the proposed operations in the aspects of implementation, debugging and evaluation of the factors for gas costs it may be appropriate to either limit the set of curves at the moment of acceptance to some list and then extend it. Another approach (if it's technically possible) would be to have the "whilelist" contract that can be updated without consensus changes (w/o fork).</p> <p>In the case of limited set of curve the following set is proposed as a minimal:</p> <ul> <li>BN254 curve from the current version of Ethereum</li> <li>BN curve from DIZK with 2^32 roots of unity</li> <li>BLS12-381</li> <li>BLS12-377 from ZEXE with large number of roots of unity</li> <li>MNT4/6 cycle from the original <a rel="external" href="https://eprint.iacr.org/2014/595.pdf">paper</a>. It's not too secure, but may give some freedom for experiments.</li> <li>MNT4/6 cycle from Coda if performance allows</li> <li>Set of CP generated curves that would allow embedding of BLS12-377 and may be some BN curve that would have large power of two divisor for both base field and scalar field modulus (example of CP curve for BLS12-377 can be found in ZEXE).</li> </ul> <h2 id="rationale">Rationale</h2> <p>Only the largest design decisions will be covered:</p> <ul> <li>While there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it's required for gas estimation purposes.</li> <li>Multiexponentiation is a separate operation due to large cost saving</li> <li>There are no point decompressions due to impossibility to get universal gas estimation of square root operation. For a limited number of "good" cases prices would be too different, so specifying the "worst case" is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is.</li> </ul> <h3 id="this-precompile-and-eip-1109">This precompile and EIP 1109</h3> <p>While there is no strict requirement of EIP 1109 for functionality, here is an example why it would be desired:</p> <ul> <li>BLS12-381 curve, 381 bit modulus, 255 bit scalar field, no native arithmetic is available in EVM for this</li> <li>Point addition would take 5000ns (quite overestimated)</li> <li>Point multiplication would take roughly 150000ns</li> <li>Crude gas schedule 15 Mgas/second from ECRecover precompile</li> <li>Point addition would cost 75 gas, with <code>STATICCALL</code> adding another 700</li> <li>Point multiplication would cost 2250 gas</li> <li>One should also add the cost of memory allocation that is at least <code>1 + 1 + 48 + 48 + 48 + 1 + 32 + 2*48 + 2*48 = 371 byte</code> that is around 12 native Ethereum "words" and will require extra 36 gas (with negligible price for memory extension)</li> </ul> <p>Based on these quite crude estimations one can see that <code>STATICCALL</code> price will dominate the total cost (in case of addition) or bring significant overhead (in case of multiplication operation) in case of calls to this precompile.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change is not backwards compatible and requires hard fork to be activated.</p> <p>Functionality of the new precompile itself does not affect any existing functionality of Ethereum or EVM.</p> <p>This precompile may serve as a complete replacement of the current set of <code>ECADD</code>, <code>ECMUL</code> and pairing check precompiles (<code>0x06</code>, <code>0x07</code>, <code>0x08</code>)</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases are the part of the implementation with a link below.</p> <h2 id="implementation">Implementation</h2> <p>There is an ongoing implementation effort <a rel="external" href="https://github.com/matter-labs/eip1829">here</a>. Right now:</p> <ul> <li>Non-pairing operations are implemented and tested.</li> <li>BLS12 family is completed and tested for BLS12-381 and BLS12-377 curves.</li> <li>BN family is completed and tested with BN254 curve.</li> <li>Cocks-Pinch method curve is tested for k=6 curve from ZEXE.</li> </ul> <h2 id="preliminary-benchmarks">Preliminary benchmarks</h2> <p>cp6 in benchmarks is a Cocks-Pinch method curve that embeds BLS12-377. Machine: Core i7, 2.9 GHz.</p> <p>Multiexponentiation benchmarks take 100 pairs <code>(generator, random scalar)</code> as input. Due to the same "base" it may be not too representative benchmark and will be updated.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>test pairings::bls12::tests::bench_bls12_381_pairing ... bench: 2,348,317 ns/iter (+/- 605,340)</span></span> <span class="giallo-l"><span>test pairings::cp::tests::bench_cp6_pairing ... bench: 86,328,825 ns/iter (+/- 11,802,073)</span></span> <span class="giallo-l"><span>test tests::bench_addition_bn254 ... bench: 388 ns/iter (+/- 73)</span></span> <span class="giallo-l"><span>test tests::bench_doubling_bn254 ... bench: 187 ns/iter (+/- 4)</span></span> <span class="giallo-l"><span>test tests::bench_field_inverse ... bench: 2,478 ns/iter (+/- 167)</span></span> <span class="giallo-l"><span>test tests::bench_field_mont_inverse ... bench: 2,356 ns/iter (+/- 51)</span></span> <span class="giallo-l"><span>test tests::bench_multiplication_bn254 ... bench: 81,744 ns/iter (+/- 6,984)</span></span> <span class="giallo-l"><span>test tests::bench_multiplication_bn254_into_affine ... bench: 81,925 ns/iter (+/- 3,323)</span></span> <span class="giallo-l"><span>test tests::bench_multiplication_bn254_into_affine_wnaf ... bench: 74,716 ns/iter (+/- 4,076)</span></span> <span class="giallo-l"><span>test tests::bench_naive_multiexp_bn254 ... bench: 10,659,911 ns/iter (+/- 559,790)</span></span> <span class="giallo-l"><span>test tests::bench_peppinger_bn254 ... bench: 2,678,743 ns/iter (+/- 148,914)</span></span> <span class="giallo-l"><span>test tests::bench_wnaf_multiexp_bn254 ... bench: 9,161,281 ns/iter (+/- 456,137)</span></span></code></pre><h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ronan Sandfordhttps://github.com/wighawag https://wg-eips.ritovision.com/1959/ <h2 id="simple-summary">Simple Summary</h2> <p>To protect off-chain messages from being reused across different chain, a mechanism need to be given to smart contract to only accept messages for that chain. Since a chain can change its chainID, the mechanism should consider old chainID valid.</p> <h2 id="abstract">Abstract</h2> <p>This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID).</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/155/">EIP-155</a> proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using <a href="https://wg-eips.ritovision.com/712/">EIP-712</a>.</p> <p><a href="https://wg-eips.ritovision.com/1344/">EIP-1344</a> is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344.</p> <h2 id="specification">Specification</h2> <p>Adds a new opcode <code>VALID_CHAINID</code> at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push <code>0x1</code> onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, <code>0x0</code> otherwise.</p> <p>The operation costs <code>G_blockhash</code> to execute.</p> <p>The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows.</p> <p>Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost. As such the gas cost is simply a necessary cost for the feature.</p> <h2 id="rationale">Rationale</h2> <p>The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID.</p> <p>The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per <a href="https://wg-eips.ritovision.com/712/">EIP-712</a> (with the previous chainID) will fails to be accepted by the contracts after the fork.</p> <p>That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract.</p> <p>While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before a hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking <code>chainID == CHAIN_ID()</code> without considering past chainIDs.</p> <p>Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages.</p> <p>Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some inconvenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become inaccessible, resulting in potentially disastrous situations.</p> <p>In other words, we should consider all off-chain messages (with valid chainID) as part of the chain's offchain state. The opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork.</p> <p>As for replay protection, the idea of considering all of the off-chain messages signed with valid chainID as part of the chain's offchain-state means that all of these off-chain messages can be reused on the different forks which share a common chainID history (up to where they differ). This is actually an important feature since as mentioned, users expect their signed messages to be valid from the time of signing. From that time onwards these messages should be considered as part of the chain's offchain state. A hardfork should not thus render them invalid. This is similar to how the previous on-chain state is shared between 2 hardforks.</p> <p>The wallets will make sure that at any time, a signing message request use the latest chainID of the chain being used. This prevent replay attack onto chain that have different chainID histories (they would not have the same latest chainID).</p> <p>Now it is argued in the <a rel="external" href="https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131">EIP1344 discussion</a> that when a contentious hardfork happen and one side of the fork decide to not update its chainID, that side of the chain would be vulnerable to replays since users will keep signing with a chainID that is also valid in the chain that forked. An issue also present in EIP-1344.</p> <p>This is simply a natural consequence of using chainID as the only anti-replay information for L2 messages. But this can indeed be an issue if the hardfork is created by a small minority. In that case if the majority ignore the fork and do not update its chainID, then all new message from the majority chain (until they update their chainID) can be replayed on the minority-led hardfork since the majority's current chainID is also part of the minority-led fork's chainID history.</p> <p>To fix this, every message could specify the block number representing the time it was signed. The contract could then verify that chainID specified as part of that message was valid at that particular block.</p> <p>While EIP-1344 can't do that accurately as the caching system might leave a gap, this proposal can solve it if it is modified to return the blockNumber at which a chainID become invalid. Unfortunately, this would be easy for contracts to not perform that check. And since it suffice of only one important applications to not follow this procedure to put the minority-led fork at a disadvantage, this would fail to achieve the desired goal of protecting the minority-led fork from replay.</p> <p>Since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, ...), if such fork get traction later, this would be at the expense of majority users who were not aware of it. As such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected.</p> <p>Similarly to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separately from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though.</p> <h2 id="references">References</h2> <p>This was previously suggested as part of <a rel="external" href="https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39">EIP-1344 discussion</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ronan Sandfordhttps://github.com/wighawag https://wg-eips.ritovision.com/1965/ <h2 id="abstract">Abstract</h2> <p>This EIP adds a precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/155/">EIP-155</a> proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using <a href="https://wg-eips.ritovision.com/712/">EIP-712</a>.</p> <p><a href="https://wg-eips.ritovision.com/1344/">EIP-1344</a> is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced.</p> <p><a href="https://wg-eips.ritovision.com/1959/">EIP-1959</a> solves the issue of EIP-1344 but does not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it removes some freedom to fork. We consider that all fork should be given equal opportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, <strong>users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.</strong></p> <h2 id="specification">Specification</h2> <p>Adds a new precompile which uses 2 arguments : a 32 bytes value that represents the chainID to test and a 32 bytes value representing the blockNumber at which the chainID is tested. It returns 0x1 if the chainID is valid at the specific blockNumber, 0x0 otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement.</p> <p>The operation will costs no more than <code>G_blockhash</code> + <code>G_verylow</code> to execute. This could be lower as chainID are only introduced during hardfork.</p> <p>The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows.</p> <p>Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost and exhibit issues for minority-led hardfork (see Rationale section below). As such the gas cost is simply a necessary cost for the feature.</p> <h2 id="rationale">Rationale</h2> <p>The rationale at EIP-1959 applies here as well too :</p> <ul> <li>An opcode is better than a caching system for past chainID, It is cheaper, safer and does not include gaps.</li> <li>Direct access to the latest chainID is dangerous since it makes it easy for contracts to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that changes the chainID. This can have disastrous consequences on users.</li> <li>all off-chain messages signed before a fork should be valid across all side of the fork.</li> </ul> <p>The only difference is that this current proposal proposes a solution to protect hardfork led by a minority.</p> <p>To summarize there is 2 possible fork scenario :</p> <ol> <li> <p>The majority decide to make a hardfork but a minority disagree with it (ETC is such example). The fork is planned for block X. If the majority is not taking any action to automate the process of assigning a different chainID for both, the minority has plenty of time to plan for a chainID upgrade to happen at that same block X. Now if they do not do it, their users will face the problem that their messages will be replayable on the majority chain (Note that this is not true the other way around as we assume the majority decided to change the chainID). As such there is no reason that they will leave it that way.</p> </li> <li> <p>A minority decide to create a hardfork that the majority disagree with (or simply ignore). Now, the same as above can happen but since we are talking about a minority there is a chance that the majority does not care about the minority. In that case, there would be no incentive for the majority to upgrade the chainID. This means that users of both sides of the fork will have the messages meant for the majority chain replayable on the minority-chain (even if this one changed its chainID) unless extra precaution is taken.</p> </li> </ol> <p>The solution is to add the blockNumber representing the time at which the message was signed and use it as an argument to the opcode proposed here. This way, when the minority forks with a new chainID, the previous chainID become invalid from that time onward. So new messages destined to the majority chain can't be replayed on the minority fork.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>EIP-712 is still in draft but would need to be updated to include the blockNumber as part of the values that wallets need to verify for the protection of their users.</p> <p>Since chainID and blockNumber will vary, they should not be part of the domain separator (meant to be generated once) but another part of the message.</p> <p>While the pair could be optional for contract that do not care about replays or have other ways to prevent them, if chainID is present, the blockNumber must be present too. And if any of them is present, wallet need to ensure that the chainID is indeed the latest one of the chain being used, while the blockNumber is the latest one at the point of signing. During fork transition, the wallet can use the blockNumber to know which chainID to use.</p> <h2 id="references">References</h2> <p>This was previously suggested as part of <a rel="external" href="https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170">EIP1959 discussion</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Hancockhttps://github.com/madeoftin https://wg-eips.ritovision.com/2025/ <h2 id="simple-summary">Simple Summary</h2> <p>Add <code>0.0055 ETH</code> per block for 18 months (A total of 17050 ETH) as a developer block reward reserved for funding specific Ethereum1.X working groups. The working groups are State rent (750k), Better sync (360k), Finality gadget (360k), Fee market (360k), Testing infrastructure (360k). Governance of the funds will be through a multisig of trusted individuals from the ecosystem including client teams, the foundation, and the community.</p> <p><a href="https://wg-eips.ritovision.com/1890/">EIP-1890</a> proposes a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. That EIP sets values and addresses to zero and so does not actually collect any rewards. This proposal is to explicitly set those values and begin collecting a portion of block rewards for 18 months in order to fund Ethereum 1.X working groups and organization efforts. This funding will be used to repay an initial loan provided by investors in the community funding this work with a small amount of interest. After 18 months the block reward would again reduce to zero.</p> <h2 id="abstract">Abstract</h2> <p>This EIP extends the mechanism established in EIP-1890 to add <code>0.0055 ETH</code> to the block reward for a specific distribution period of <code>3,100,000 BLOCKS</code>(≈ 18 months). The <code>RECIPIENT_ADDRESS</code> is set to a smart contract with hardcoded denominations that distributes incoming ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the hard fork block number and continue for <code>3,100,000 BLOCKS</code> (≈ 18 months) at which point the address and amount would again return to 0. Any further distribution would require a future hard fork.</p> <h2 id="motivation">Motivation</h2> <p>The context for this proposal came from attending the <a rel="external" href="https://www.youtube.com/watch?v=Au1Qll-86v0">Core Dev Eth1.X Meeting</a> in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted by working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation.</p> <h2 id="specification">Specification</h2> <p>Two constants will be introduced:</p> <ul> <li><code>REWARD_DURATION_IN_BLOCKS</code>, which specifies the number of blocks after <code>ISTANBUL_BLOCK_HEIGHT</code> when the reward collection will terminate (i.e., at block <code>ISTANBUL_BLOCK_HEIGHT + REWARD_DURATION_IN_BLOCKS</code>)</li> <li><code>BENEFICIARY_ADDRESSES</code>, a list of tuples containing the address and the amount to be transferred to this address per block. These amounts will be determined as the loan is collected from participating organizations and the addresses for repayment will be specified by them. The total of the amounts will sum to 0.0055. At the end of <code>REWARD_DURATION_IN_BLOCKS</code> the loan will be completely repaid.</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"></span> <span class="giallo-l"><span>REWARD_DURATION_IN_BLOCKS = 3100000</span></span> <span class="giallo-l"><span>DEVFUND_BLOCK_REWARD = 0.0055</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span>BENEFICIARY_ADDRESSES = [</span></span> <span class="giallo-l"><span> (&lt;address&gt;, &lt;amount_in_eth&gt;),</span></span> <span class="giallo-l"><span> (&lt;address&gt;, &lt;amount_in_eth&gt;)</span></span> <span class="giallo-l"><span>]</span></span></code></pre> <p>Beginning with block <code>ISTANBUL_BLOCK_HEIGHT</code>, the reward is added to the participating addresses within <code>BENEFICIARY_ADDRESSES</code> at each block until the end of the <code>REWARD_DURATION_IN_BLOCKS</code>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>IF (CURRENT_BLOCK - ISTANBUL_BLOCK_HEIGHT &lt;= REWARD_DURATION_IN_BLOCKS)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>FOR BENEFICIARY in BENEFICIARY_ADDRESSES:</span></span> <span class="giallo-l"><span> BENEFICIARY[0].balance += BENEFICIARY[1]</span></span> <span class="giallo-l"></span></code></pre><h2 id="rewards-distribution-rationale">Rewards Distribution Rationale</h2> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> Development loan repayment: 0.005 ETH per block: 15500 ETH total</span></span> <span class="giallo-l"><span> Development loan interest (10% total over the period, simple interest): 0.0005 ETH per block: 1550 ETH total</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> Total Block Reward Increase = `0.0055` ETH per block: 17050 ETH Total</span></span></code></pre> <p><em>With a price of Ethereum at $150.00 this will raise approx USD $2,325,000.00 for developing Eth1.X over the next 18 months.</em></p> <p><img src="https://wg-eips.ritovision.com/2025/./assets/block_rewards_distribution.png" alt="Block Rewards Distribution" /> *Specific Addresses to be determined</p> <ul> <li><a href="https://wg-eips.ritovision.com/2025/#why-hardcoded-values">FAQ - Why hardcoded values?</a></li> </ul> <h2 id="rationale">Rationale</h2> <p>There has been great public debate concerning EIP-1890, and one of the primary concerns is that it is difficult to evaluate the proposal without more complete information on how funds would be raised, how they would be administered, and how they would be used. There is a need for funding Eth1.x development and it is currently unclear where those funds will come from. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is fully funded before the Istanbul upgrade I will withdraw this EIP. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work.</p> <h3 id="why-a-loan">Why a loan?</h3> <p>The Eth1x initiative needs funding now, not in 18 months. A loan is necessary to complete certain stages of work before the funding mechanism begins to provide funds. A loan would provide this necessary funding today, and the investors willing to front this cost can recoup their contribution + a reward of <em>a fixed interest rate</em> for the risk on their loan. This arrangement will make it easier to find investors willing to participate who have sufficient funds.</p> <h3 id="loan-repayment">Loan Repayment</h3> <p><img src="https://wg-eips.ritovision.com/2025/./assets/loan_state.png" alt="Loan State Diagram" /></p> <p>There is a risk that the investors lose part of their contribution in the case that this EIP is rejected by the community between the time the funds have been collected and the beginning of the payout schedule. In this case all remaining funds will be returned to the contributors. The interest on the loan is an incentive for investors to participate in spite of this risk. Their downside is limited to the amount of funds spent before this EIP is accepted or rejected, which should be no more than about 5%, while their upside consists of the 10% simple interest paid over the period.</p> <h3 id="development-loan">Development Loan</h3> <p><code>Development Loan: 0.005</code> over 3.1 Million blocks = 15500 ETH</p> <p><strong>Funding Working Groups on 1.X</strong></p> <ul> <li>Funding Contractors, Coordinators, and project managers</li> <li>Working Groups defined with clear mandates</li> </ul> <p>Budget</p> <p>Working groups</p> <ul> <li>State rent (750k)</li> <li>Better sync (360k)</li> <li>finality gadget (360k)</li> <li>Fee market (360k)</li> <li>testing infrastructure (360k)</li> </ul> <p><strong>ETH1.X Core Dev Gatherings</strong></p> <p>Funding hosting, traveling, and accommodations for necessary in-person gatherings of ETH1.X core developers similar to the Stanford and Berlin ETH1.X Core Dev Meeting held earlier this year.</p> <p>At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of structurelessness forming within.</p> <ul> <li><a href="https://wg-eips.ritovision.com/2025/#how-will-funding-the-devs-be-organized">FAQ - How will the funding of the devs be organized?</a></li> </ul> <h2 id="accountability">Accountability</h2> <p>The funds will be transferred into DAI and secured in a multi-sig comprised of members of the community. Representatives from the following groups will receive a key.</p> <ul> <li>EIP Editors</li> <li>Geth</li> <li>Parity</li> <li>ConsenSys/PegaSys (PegaSys)</li> <li>The Ethereum Foundation (Hudson Jameson)</li> <li>Community</li> </ul> <h2 id="personal-notes-and-disclosure">Personal Notes and Disclosure</h2> <p>I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I will accept no additional funding collected by the mechanism proposed in this EIP.</p> <p>Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal.</p> <h3 id="coi">COI</h3> <p>Previously I was PM for Tennagraph, a signalling solution for Ethereum. An Aragon grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project beyond this grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly.</p> <h3 id="disclaimer">Disclaimer</h3> <p>I do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. This is as fair of a proposal as I can personally conceive.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP has no impact on backwards compatibility.</p> <h2 id="test-cases">Test Cases</h2> <p>Not Implemented</p> <h2 id="implementation">Implementation</h2> <p>Not Implemented</p> <h2 id="faq">FAQ</h2> <h3 id="why-hardcoded-values">Why Hardcoded Values?</h3> <p>Why not use a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective?</p> <p><em>TLDR: This EIP is not about governance reform</em></p> <p>First, the payment of the loan will be hardcoded. Once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. As long as blocks are created the debt will be paid back. This is the essence of a trustless smart contract.</p> <p>After the loan, there is the option to allow the amounts (limited to less than .05ETH), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. It is pretty easy to imagine a smart contract or DAO fulfilling this role. However, there are three classes of options available today we can consider when governing changes.</p> <ul> <li><strong>Give the Keys to the Hands of the Few (Oligarchy)</strong></li> </ul> <p>Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not a trusted/adopted governance mechanism to make these decisions within the Ethereum ecosystem. Also, preventing changing the contract in self interest is difficult without a well-engineered governance system of checks and balances. This EIP does not claim nor aim to solve these issues.</p> <ul> <li><strong>Give the Keys to the Hands of the Many (Plutarchy)</strong></li> </ul> <p>Allow ethereum holders with coin votes to update the smart contract. Using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. This has some benefits as the entire network can participate. However, the problem is that some individuals in the network are over represented -- the wealthy. Without a solution to identity that has been agreed to and implemented by the entire Ethereum Network, there is no way around giving more power in votes to the rich. This EIP does not claim, nor aim to solve these issues.</p> <ul> <li><strong>Use Ethereum Governance as it is Today</strong></li> </ul> <p>Criticisms or support aside, there is a system that governs Ethereum today. It is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. It includes yelling or not yelling on twitter and reddit. It is complicated and I don’t claim to understand it. Even without a clear view of how it works, there is evidence of its existence. This evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in Ethereum.</p> <p>I do not aim to change Ethereum governance. Because this EIP has hardcoded values, it must go through the existing governance process, whatever that is, before it is implemented. It will then continue to operate until the end of the emission schedule. This is intentional. This makes it uncapturable. No party other then the ecosystem itself can modify the contract once it has been deployed.</p> <p>This EIP is not about governance reform.</p> <h3 id="why-not-allow-current-client-implementors-fund-this-work-ef-consensys-parity-etc">Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...)</h3> <p>Historically there has been a precedent that the Ethereum Foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguchi observed in a recent <a rel="external" href="https://www.coindesk.com/ethereum-foundation-director-sets-new-vision-for-blockchain-non-profit">Coindesk article</a>, “it really is not only Ethereum Foundation people who are building [Ethereum]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum <em>the network</em> is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.</p> <h3 id="how-will-funding-the-devs-be-organized">How Will Funding the Devs be Organized</h3> <p>I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a <a rel="external" href="https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60">recent medium article</a>:</p> <blockquote> <p>“Going from funding a few implementation teams continuously and letting them do 'their stuff' to funding more specific and temporary initiatives requires looking at funding through different lenses. How much 'due diligence' and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post)."</p> </blockquote> <p>My suggestion would be to create an Eth1.X core developer DAO using <a rel="external" href="https://daostack.io/">DaoStack</a> to coordinate membership and payment of the Core Devs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now.</p> <h3 id="isn-t-a-loan-considered-a-security-or-is-it">Isn't a loan considered a security, or is it?</h3> <p>I am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. From the research I have done and conversations I have had there is a very good argument that a loan of this nature will not be considered a security by the US Supreme Court. As the result of <a rel="external" href="https://casetext.com/case/reves-v-ernst-young">REVES ET AL. v . ERNST YOUNG 1990</a>, the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. If the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. The Supreme Court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. (<a rel="external" href="https://www.invigorlaw.com/loan-subject-securities-regulations/">source</a>)</p> <p><strong>Family Resemblance Test</strong></p> <ol> <li>The intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security.</li> <li>The plan of distribution—the more widely the note is offered, the more likely it is to be found a security.</li> <li>The expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security.</li> <li>Other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security.</li> </ol> <p>The loan is for the specific use of supporting Eth1.X research and development. The distribution will not be widely offered and the note will be collateralized by the network itself, provided in ETH and repaid in ETH. In coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the due dilegence I can, seek legal counsel, and accept any legal repercussions resulting from this work.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin Eric Connerhttps://github.com/econoar Rick Dudleyhttps://github.com/AFDudley Matthew Slipperhttps://github.com/mslipper Ian Nordenhttps://github.com/i-norden Abdelhamid Bakhtahttps://github.com/abdelhamidbakhta https://wg-eips.ritovision.com/1559/ <h2 id="simple-summary">Simple Summary</h2> <p>A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.</p> <h2 id="abstract">Abstract</h2> <p>We introduce a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction type, with the format <code>0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])</code>.</p> <p>There is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block. The algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target. The base fee per gas is burned. Transactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee). Transactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block's network fee per gas (aka: base fee). Senders will always pay the base fee per gas of the block their transaction was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn't exceed the transaction's maximum fee per gas.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum historically priced transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency:</p> <ul> <li><strong>Mismatch between volatility of transaction fee levels and social cost of transactions</strong>: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. It's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 10x more when the cost per gas is 10 nanoeth compared to when the cost per gas is 1 nanoeth; in both cases, it's a difference between 8 million gas and 8.02 million gas.</li> <li><strong>Needless delays for users</strong>: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no "slack" mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand.</li> <li><strong>Inefficiencies of first price auctions</strong>: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment.</li> <li><strong>Instability of blockchains with no block reward</strong>: In the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are known issues with this that likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this.</li> </ul> <p>The proposal in this EIP is to start with a base fee amount which is adjusted up and down by the protocol based on how congested the network is. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. Because these base fee changes are constrained, the maximum difference in base fee from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users the base fee will be estimated by their wallet and a small priority fee, which compensates miners taking on orphan risk (e.g. 1 nanoeth), will be automatically set. Users can also manually set the transaction max fee to bound their total costs.</p> <p>An important aspect of this fee system is that miners only get to keep the priority fee. The base fee is always burned (i.e. it is destroyed by the protocol). This ensures that only ETH can ever be used to pay for transactions on Ethereum, cementing the economic value of ETH within the Ethereum platform and reducing risks associated with miner extractable value (MEV). Additionally, this burn counterbalances Ethereum inflation while still giving the block reward and priority fee to miners. Finally, ensuring the miner of a block does not receive the base fee is important because it removes miner incentive to manipulate the fee in order to extract more fees from users.</p> <h2 id="specification">Specification</h2> <p>Block validity is defined in the reference implementation below. The <code>GASPRICE</code> (<code>0x3a</code>) opcode <strong>MUST</strong> return the <code>effective_gas_price</code> as defined in the reference implementation below.</p> <p>As of <code>FORK_BLOCK_NUMBER</code>, a new <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> transaction is introduced with <code>TransactionType</code> 2.</p> <p>The intrinsic cost of the new transaction is inherited from <a href="https://wg-eips.ritovision.com/2930/">EIP-2930</a>, specifically <code>21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>TransactionPayload</code> for this transaction is <code>rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])</code>.</p> <p>The <code>signature_y_parity, signature_r, signature_s</code> elements of this transaction represent a secp256k1 signature over <code>keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list]))</code>.</p> <p>The <a href="https://wg-eips.ritovision.com/2718/">EIP-2718</a> <code>ReceiptPayload</code> for this transaction is <code>rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p> <p><em>Note: <code>//</code> is integer division, round down.</em></p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">from</span><span> typing</span><span class="z-keyword"> import</span><span> Union</span><span>,</span><span> Dict</span><span>,</span><span> Sequence</span><span>,</span><span> List</span><span>,</span><span> Tuple</span><span>,</span><span> Literal</span></span> <span class="giallo-l"><span class="z-keyword">from</span><span> dataclasses</span><span class="z-keyword"> import</span><span> dataclass</span><span>,</span><span> field</span></span> <span class="giallo-l"><span class="z-keyword">from</span><span> abc</span><span class="z-keyword"> import</span><span class="z-constant"> ABC</span><span>,</span><span> abstractmethod</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> TransactionLegacy</span><span>:</span></span> <span class="giallo-l"><span> signer_nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_price</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> destination</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span class="z-support"> bytes</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> v</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> r</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> s</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Transaction2930Payload</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> signer_nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_price</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> destination</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span class="z-support"> bytes</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> List</span><span>[</span><span>Tuple</span><span>[</span><span class="z-support">int</span><span>,</span><span> List</span><span>[</span><span class="z-support">int</span><span>]</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">list</span><span>)</span></span> <span class="giallo-l"><span> signature_y_parity</span><span>:</span><span class="z-support"> bool</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> signature_r</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> signature_s</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Transaction2930Envelope</span><span>:</span></span> <span class="giallo-l"><span class="z-support"> type</span><span>:</span><span> Literal</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> Transaction2930Payload</span><span class="z-keyword"> =</span><span> Transaction2930Payload</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Transaction1559Payload</span><span>:</span></span> <span class="giallo-l"><span> chain_id</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> signer_nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_priority_fee_per_gas</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_fee_per_gas</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> destination</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span class="z-support"> bytes</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> List</span><span>[</span><span>Tuple</span><span>[</span><span class="z-support">int</span><span>,</span><span> List</span><span>[</span><span class="z-support">int</span><span>]</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">list</span><span>)</span></span> <span class="giallo-l"><span> signature_y_parity</span><span>:</span><span class="z-support"> bool</span><span class="z-keyword"> =</span><span class="z-constant"> False</span></span> <span class="giallo-l"><span> signature_r</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> signature_s</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Transaction1559Envelope</span><span>:</span></span> <span class="giallo-l"><span class="z-support"> type</span><span>:</span><span> Literal</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span> Transaction1559Payload</span><span class="z-keyword"> =</span><span> Transaction1559Payload</span><span>(</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>Transaction2718</span><span class="z-keyword"> =</span><span> Union</span><span>[</span><span>Transaction1559Envelope</span><span>,</span><span> Transaction2930Envelope</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>Transaction</span><span class="z-keyword"> =</span><span> Union</span><span>[</span><span>TransactionLegacy</span><span>,</span><span> Transaction2718</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> NormalizedTransaction</span><span>:</span></span> <span class="giallo-l"><span> signer_address</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> signer_nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_priority_fee_per_gas</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> max_fee_per_gas</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> destination</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> amount</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> payload</span><span>:</span><span class="z-support"> bytes</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> access_list</span><span>:</span><span> List</span><span>[</span><span>Tuple</span><span>[</span><span class="z-support">int</span><span>,</span><span> List</span><span>[</span><span class="z-support">int</span><span>]</span><span>]</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">list</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Block</span><span>:</span></span> <span class="giallo-l"><span> parent_hash</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> uncle_hashes</span><span>:</span><span> Sequence</span><span>[</span><span class="z-support">int</span><span>]</span><span class="z-keyword"> =</span><span> field</span><span>(</span><span class="z-variable">default_factory</span><span class="z-keyword">=</span><span class="z-support">list</span><span>)</span></span> <span class="giallo-l"><span> author</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> state_root</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> transaction_root</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> transaction_receipt_root</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> logs_bloom</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> difficulty</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> number</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> gas_limit</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> note the gas_limit is the gas_target * ELASTICITY_MULTIPLIER</span></span> <span class="giallo-l"><span> gas_used</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> timestamp</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> extra_data</span><span>:</span><span class="z-support"> bytes</span><span class="z-keyword"> =</span><span class="z-support"> bytes</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> proof_of_work</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> base_fee_per_gas</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name">@</span><span class="z-entity z-name">dataclass</span></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> Account</span><span>:</span></span> <span class="giallo-l"><span> address</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> nonce</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> balance</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> storage_root</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> code_hash</span><span>:</span><span class="z-support"> int</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-constant">INITIAL_BASE_FEE</span><span class="z-keyword"> =</span><span class="z-constant"> 1000000000</span></span> <span class="giallo-l"><span class="z-constant">INITIAL_FORK_BLOCK_NUMBER</span><span class="z-keyword"> =</span><span class="z-constant"> 10</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> TBD</span></span> <span class="giallo-l"><span class="z-constant">BASE_FEE_MAX_CHANGE_DENOMINATOR</span><span class="z-keyword"> =</span><span class="z-constant"> 8</span></span> <span class="giallo-l"><span class="z-constant">ELASTICITY_MULTIPLIER</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> World</span><span>(</span><span class="z-constant">ABC</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> validate_block</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-constant"> None</span><span>:</span></span> <span class="giallo-l"><span> parent_gas_target</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_limit</span><span class="z-keyword"> //</span><span class="z-constant"> ELASTICITY_MULTIPLIER</span></span> <span class="giallo-l"><span> parent_gas_limit</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_limit</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> on the fork block, don&#39;t account for the ELASTICITY_MULTIPLIER to avoid</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> unduly halving the gas target.</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> INITIAL_FORK_BLOCK_NUMBER</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>number</span><span>:</span></span> <span class="giallo-l"><span> parent_gas_target</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_limit</span></span> <span class="giallo-l"><span> parent_gas_limit</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_limit</span><span class="z-keyword"> *</span><span class="z-constant"> ELASTICITY_MULTIPLIER</span><span> </span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> parent_base_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>base_fee_per_gas</span></span> <span class="giallo-l"><span> parent_gas_used</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>parent</span><span>(</span><span>block</span><span>)</span><span>.</span><span>gas_used</span></span> <span class="giallo-l"><span> transactions</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>transactions</span><span>(</span><span>block</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check if the block used too much gas</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>gas_used</span><span class="z-keyword"> &lt;=</span><span> block</span><span>.</span><span>gas_limit</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: too much gas used</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check if the block changed the gas limit too much</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>gas_limit</span><span class="z-keyword"> &lt;</span><span> parent_gas_limit</span><span class="z-keyword"> +</span><span> parent_gas_limit</span><span class="z-keyword"> //</span><span class="z-constant"> 1024</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: gas limit increased too much</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>gas_limit</span><span class="z-keyword"> &gt;</span><span> parent_gas_limit</span><span class="z-keyword"> -</span><span> parent_gas_limit</span><span class="z-keyword"> //</span><span class="z-constant"> 1024</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: gas limit decreased too much</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check if the gas limit is at least the minimum gas limit</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> block</span><span>.</span><span>gas_limit</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 5000</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check if the base fee is correct</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-constant"> INITIAL_FORK_BLOCK_NUMBER</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>number</span><span>:</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-constant"> INITIAL_BASE_FEE</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> parent_gas_used</span><span class="z-keyword"> ==</span><span> parent_gas_target</span><span>:</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span> parent_gas_used</span><span class="z-keyword"> &gt;</span><span> parent_gas_target</span><span>:</span></span> <span class="giallo-l"><span> gas_used_delta</span><span class="z-keyword"> =</span><span> parent_gas_used</span><span class="z-keyword"> -</span><span> parent_gas_target</span></span> <span class="giallo-l"><span> base_fee_per_gas_delta</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>parent_base_fee_per_gas</span><span class="z-keyword"> *</span><span> gas_used_delta</span><span class="z-keyword"> //</span><span> parent_gas_target</span><span class="z-keyword"> //</span><span class="z-constant"> BASE_FEE_MAX_CHANGE_DENOMINATOR</span><span>,</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> +</span><span> base_fee_per_gas_delta</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> gas_used_delta</span><span class="z-keyword"> =</span><span> parent_gas_target</span><span class="z-keyword"> -</span><span> parent_gas_used</span></span> <span class="giallo-l"><span> base_fee_per_gas_delta</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> *</span><span> gas_used_delta</span><span class="z-keyword"> //</span><span> parent_gas_target</span><span class="z-keyword"> //</span><span class="z-constant"> BASE_FEE_MAX_CHANGE_DENOMINATOR</span></span> <span class="giallo-l"><span> expected_base_fee_per_gas</span><span class="z-keyword"> =</span><span> parent_base_fee_per_gas</span><span class="z-keyword"> -</span><span> base_fee_per_gas_delta</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> expected_base_fee_per_gas</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>base_fee_per_gas</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: base fee not correct</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> execute transactions and do gas accounting</span></span> <span class="giallo-l"><span> cumulative_transaction_gas_used</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> unnormalized_transaction</span><span class="z-keyword"> in</span><span> transactions</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Note: this validates transaction signature and chain ID which must happen before we normalize below since normalized transactions don&#39;t include signature or chain ID</span></span> <span class="giallo-l"><span> signer_address</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>validate_and_recover_signer_address</span><span>(</span><span>unnormalized_transaction</span><span>)</span></span> <span class="giallo-l"><span> transaction</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>normalize_transaction</span><span>(</span><span>unnormalized_transaction</span><span>,</span><span> signer_address</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> signer</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>signer_address</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> -=</span><span> transaction</span><span>.</span><span>amount</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 0</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid transaction: signer does not have enough ETH to cover attached value</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> the signer must be able to afford the transaction</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> &gt;=</span><span> transaction</span><span>.</span><span>gas_limit</span><span class="z-keyword"> *</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ensure that the user was willing to at least pay the base fee</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> block</span><span>.</span><span>base_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Prevent impossibly large numbers</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> Prevent impossibly large numbers</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">256</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> The total must be the larger of the two</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> &gt;=</span><span> transaction</span><span>.</span><span>max_priority_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> priority fee is capped because the base fee is filled first</span></span> <span class="giallo-l"><span> priority_fee_per_gas</span><span class="z-keyword"> =</span><span class="z-support"> min</span><span>(</span><span>transaction</span><span>.</span><span>max_priority_fee_per_gas</span><span>,</span><span> transaction</span><span>.</span><span>max_fee_per_gas</span><span class="z-keyword"> -</span><span> block</span><span>.</span><span>base_fee_per_gas</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> signer pays both the priority fee and the base fee</span></span> <span class="giallo-l"><span> effective_gas_price</span><span class="z-keyword"> =</span><span> priority_fee_per_gas</span><span class="z-keyword"> +</span><span> block</span><span>.</span><span>base_fee_per_gas</span></span> <span class="giallo-l"><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> -=</span><span> transaction</span><span>.</span><span>gas_limit</span><span class="z-keyword"> *</span><span> effective_gas_price</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 0</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid transaction: signer does not have enough ETH to cover gas</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"><span> gas_used</span><span class="z-keyword"> =</span><span class="z-variable z-language"> self</span><span>.</span><span>execute_transaction</span><span>(</span><span>transaction</span><span>,</span><span> effective_gas_price</span><span>)</span></span> <span class="giallo-l"><span> gas_refund</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>gas_limit</span><span class="z-keyword"> -</span><span> gas_used</span></span> <span class="giallo-l"><span> cumulative_transaction_gas_used</span><span class="z-keyword"> +=</span><span> gas_used</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> signer gets refunded for unused gas</span></span> <span class="giallo-l"><span> signer</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> gas_refund</span><span class="z-keyword"> *</span><span> effective_gas_price</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> miner only receives the priority fee; note that the base fee is not given to anyone (it is burned)</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>account</span><span>(</span><span>block</span><span>.</span><span>author</span><span>)</span><span>.</span><span>balance</span><span class="z-keyword"> +=</span><span> gas_used</span><span class="z-keyword"> *</span><span> priority_fee_per_gas</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> check if the block spent too much gas transactions</span></span> <span class="giallo-l"><span class="z-keyword"> assert</span><span> cumulative_transaction_gas_used</span><span class="z-keyword"> ==</span><span> block</span><span>.</span><span>gas_used</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">invalid block: gas_used does not equal total gas used in all transactions</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-keyword"> TODO</span><span class="z-comment">: verify account balances match block&#39;s account balances (via state root comparison)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-keyword"> TODO</span><span class="z-comment">: validate the rest of the block</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> normalize_transaction</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> transaction</span><span>:</span><span> Transaction</span><span>,</span><span class="z-variable z-parameter z-function"> signer_address</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span> NormalizedTransaction</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> legacy transactions</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-support"> isinstance</span><span>(</span><span>transaction</span><span>,</span><span> TransactionLegacy</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> NormalizedTransaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> signer_address</span><span class="z-keyword"> =</span><span> signer_address</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> signer_nonce</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>signer_nonce</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> gas_limit</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>gas_limit</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_priority_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>gas_price</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>gas_price</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> destination</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>destination</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> amount</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>amount</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> payload</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> access_list</span><span class="z-keyword"> =</span><span> [</span><span>]</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 2930 transactions</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span class="z-support"> isinstance</span><span>(</span><span>transaction</span><span>,</span><span> Transaction2930Envelope</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> NormalizedTransaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> signer_address</span><span class="z-keyword"> =</span><span> signer_address</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> signer_nonce</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>signer_nonce</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> gas_limit</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>gas_limit</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_priority_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>gas_price</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>gas_price</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> destination</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>destination</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> amount</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>amount</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> payload</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>payload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> access_list</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>access_list</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> 1559 transactions</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span class="z-support"> isinstance</span><span>(</span><span>transaction</span><span>,</span><span> Transaction1559Envelope</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> NormalizedTransaction</span><span>(</span></span> <span class="giallo-l"><span class="z-variable"> signer_address</span><span class="z-keyword"> =</span><span> signer_address</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> signer_nonce</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>signer_nonce</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> gas_limit</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>gas_limit</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_priority_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>max_priority_fee_per_gas</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> max_fee_per_gas</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>max_fee_per_gas</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> destination</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>destination</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> amount</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>amount</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> payload</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>payload</span><span>,</span></span> <span class="giallo-l"><span class="z-variable"> access_list</span><span class="z-keyword"> =</span><span> transaction</span><span>.</span><span>payload</span><span>.</span><span>access_list</span><span>,</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> raise</span><span class="z-support"> Exception</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">invalid transaction: unexpected number of items</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> parent</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span> Block</span><span>:</span><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> block_hash</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> transactions</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> block</span><span>:</span><span> Block</span><span>)</span><span> -&gt;</span><span> Sequence</span><span>[</span><span>Transaction</span><span>]</span><span>:</span><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> effective_gas_price is the value returned by the GASPRICE (0x3a) opcode</span></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> execute_transaction</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> transaction</span><span>:</span><span> NormalizedTransaction</span><span>,</span><span class="z-variable z-parameter z-function"> effective_gas_price</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> validate_and_recover_signer_address</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> transaction</span><span>:</span><span> Transaction</span><span>)</span><span> -&gt;</span><span class="z-support"> int</span><span>:</span><span class="z-keyword"> pass</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> @</span><span class="z-entity z-name">abstractmethod</span></span> <span class="giallo-l"><span class="z-storage z-type"> def</span><span class="z-entity z-name"> account</span><span>(</span><span class="z-variable z-parameter z-function">self</span><span>,</span><span class="z-variable z-parameter z-function"> address</span><span>:</span><span class="z-support"> int</span><span>)</span><span> -&gt;</span><span> Account</span><span>:</span><span class="z-keyword"> pass</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Legacy Ethereum transactions will still work and be included in blocks, but they will not benefit directly from the new pricing system. This is due to the fact that upgrading from legacy transactions to new transactions results in the legacy transaction's <code>gas_price </code> entirely being consumed either by the <code>base_fee_per_gas</code> and the <code>priority_fee_per_gas</code>.</p> <h3 id="block-hash-changing">Block Hash Changing</h3> <p>The datastructure that is passed into keccak256 to calculate the block hash is changing, and all applications that are validating blocks are valid or using the block hash to verify block contents will need to be adapted to support the new datastructure (one additional item). If you only take the block header bytes and hash them you should still correctly get a hash, but if you construct a block header from its constituent elements you will need to add in the new one at the end.</p> <h3 id="gasprice">GASPRICE</h3> <p>Previous to this change, <code>GASPRICE</code> represented both the ETH paid by the signer per gas for a transaction as well as the ETH received by the miner per gas. As of this change, <code>GASPRICE</code> now only represents the amount of ETH paid by the signer per gas, and the amount a miner was paid for the transaction is no longer accessible directly in the EVM.</p> <h2 id="security-considerations">Security Considerations</h2> <h3 id="increased-max-block-size-complexity">Increased Max Block Size/Complexity</h3> <p>This EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block. Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts. It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size.</p> <h3 id="transaction-ordering">Transaction Ordering</h3> <p>With most people not competing on priority fees and instead using a baseline fee to get included, transaction ordering now depends on individual client internal implementation details such as how they store the transactions in memory. It is recommended that transactions with the same priority fee be sorted by time the transaction was received to protect the network from spamming attacks where the attacker throws a bunch of transactions into the pending pool in order to ensure that at least one lands in a favorable position. Miners should still prefer higher gas premium transactions over those with a lower gas premium, purely from a selfish mining perspective.</p> <h3 id="miners-mining-empty-blocks">Miners Mining Empty Blocks</h3> <p>It is possible that miners will mine empty blocks until such time as the base fee is very low and then proceed to mine half full blocks and revert to sorting transactions by the priority fee. While this attack is possible, it is not a particularly stable equilibrium as long as mining is decentralized. Any defector from this strategy will be more profitable than a miner participating in the attack for as long as the attack continues (even after the base fee reached 0). Since any miner can anonymously defect from a cartel, and there is no way to prove that a particular miner defected, the only feasible way to execute this attack would be to control 50% or more of hashing power. If an attacker had exactly 50% of hashing power, they would make no Ether from priority fee while defectors would make double the Ether from priority fees. For an attacker to turn a profit, they need to have some amount over 50% hashing power, which means they can instead execute double spend attacks or simply ignore any other miners which is a far more profitable strategy.</p> <p>Should a miner attempt to execute this attack, we can simply increase the elasticity multiplier (currently 2x) which requires they have even more hashing power available before the attack can even be theoretically profitable against defectors.</p> <h3 id="eth-burn-precludes-fixed-supply">ETH Burn Precludes Fixed Supply</h3> <p>By burning the base fee, we can no longer guarantee a fixed Ether supply. This could result in economic instability as the long term supply of ETH will no longer be constant over time. While a valid concern, it is difficult to quantify how much of an impact this will have. If more is burned on base fee than is generated in mining rewards then ETH will be deflationary and if more is generated in mining rewards than is burned then ETH will be inflationary. Since we cannot control user demand for block space, we cannot assert at the moment whether ETH will end up inflationary or deflationary, so this change causes the core developers to lose some control over Ether's long term quantity.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-04-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ronan Sandfordhttps://github.com/wighawag https://wg-eips.ritovision.com/1930/ <h2 id="simple-summary">Simple Summary</h2> <p>Add the ability for smart contract to execute calls with a specific amount of gas. If this is not possible the execution should revert.</p> <h2 id="abstract">Abstract</h2> <p>The current CALL, DELEGATE_CALL, STATIC_CALL opcode do not enforce the gas being sent, they simply consider the gas value as a maximum. This pose serious problem for applications that require the call to be executed with a precise amount of gas.</p> <p>This is for example the case for meta-transaction where the contract needs to ensure the call is executed exactly as the signing user intended.</p> <p>But this is also the case for common use cases, like checking "on-chain" if a smart contract support a specific interface (via <a href="https://wg-eips.ritovision.com/165/">EIP-165</a> for example).</p> <p>The solution presented here is to add new call semantic that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert.</p> <h3 id="specification">Specification</h3> <p>There are 2 possibilities</p> <p>a) one is to add opcode variant that have a stricter gas semantic</p> <p>b) The other is to consider a specific gas value range (one that have never been used before) to have strict gas semantic, while leaving other values as before</p> <p>Here are the details description</p> <h4 id="option-a">option a)</h4> <ul> <li>add a new variant of the CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert</li> <li>add a new variant of the DELEGATE_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert</li> <li>add a new variant of the STATIC_CALL opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert</li> </ul> <h5 id="rational-for-a">Rational for a)</h5> <p>This solution has the merit to avoid any possibility of old contract be affected by the change. On the other hand it introduce 3 new opcodes. With EIP-1702, we could render the old opcode obsolete though.</p> <h4 id="option-b">option b)</h4> <p>For all opcode that allow to pass gas to another contract, do the following:</p> <ul> <li>If the most significant bit is one, consider the 31 less significant bit as the amount of gas to be given to the receiving contract in the strict sense. SO like a) if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert.</li> <li>If the 2nd most significant bit is zero, consider the whole value to behave like before, that is, it act as a maximum value, and even if not enough gas is present, the gas that can be given is given to the receiving contract</li> </ul> <h5 id="rational-for-b">Rational for b)</h5> <p>This solution relies on the fact that no contract would have given any value bigger or equal to 0x8000000000000000000000000000000000000000000000000000000000000000</p> <p>Note that solidity for example do not use value like 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as it is more expensive than passing the gasLeft.</p> <p>Its main benefit though is that it does not require extra opcodes.</p> <h4 id="strict-gas-semantic">strict gas semantic</h4> <p>To be precise, regarding the strict gas semantic, based on <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>, the current call must revert unless G &gt;= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified.</p> <p>So instead of</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>availableGas = availableGas - base</span></span> <span class="giallo-l"><span>gas := availableGas - availableGas/64</span></span> <span class="giallo-l"><span>...</span></span> <span class="giallo-l"><span>if !callCost.IsUint64() || gas &lt; callCost.Uint64() {</span></span> <span class="giallo-l"><span> return gas, nil</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>see https://github.com/ethereum/go-ethereum/blob/7504dbd6eb3f62371f86b06b03ffd665690951f2/core/vm/gas.go#L41-L48</p> <p>we would have</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>availableGas = availableGas - base</span></span> <span class="giallo-l"><span>gas := availableGas - availableGas/64</span></span> <span class="giallo-l"><span>if !callCost.IsUint64() || gas &lt; callCost.Uint64() {</span></span> <span class="giallo-l"><span> return 0, errNotEnoughGas</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="rationale">Rationale</h3> <p>Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max <code>G - Math.floor(G/64)</code> where G is the gasleft() at the point of the CALL, the rest of the current call is given <code>Math.floor(G/64)</code> which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed.</p> <p>This is an issue for contracts that require external call to only fails if they would fails with enough gas. This requirement is present in smart contract wallet and meta transaction in general, where the one executing the transaction is not the signer of the execution data. Because in such case, the contract needs to ensure the call is executed exactly as the signing user intended.</p> <p>But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the <code>supporstInterface</code> method is bounded to use 30,000 gas so that it is theoretically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call.</p> <p>Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interpreting wrongly that the callee is not implementing the interface in question.</p> <p>While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that <a rel="external" href="https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9">bug report</a> or after the call (see the native meta transaction implementation <a rel="external" href="https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176">here</a>, it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> behavior and the current gas pricing so closely.</p> <p>This would also allow the behaviour of <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> to be changed without having to affect contract that require this strict gas behaviour.</p> <p>As mentioned, such strict gas behaviour is important for smart contract wallet and meta transaction in general. The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unnecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100</p> <p>As for EIP-165, the issue already exists in the example implementation presented in the EIP. Please see the details of the issue <a rel="external" href="https://github.com/ethereum/EIPs/pull/881#issuecomment-491677748">here</a></p> <p>The same issue exists also on OpenZeppelin implementation, a library used by many. It does not for perform any check on gas before calling <code>supportsInterface</code> with 30,000 gas (see <a rel="external" href="https://github.com/OpenZeppelin/openzeppelin-solidity/blob/fa004a7f5de572b3dbcde1a8a81f9a87e353e799/contracts/introspection/ERC165Checker.sol#L37">here</a> and is thus vulnerable to the issue mentioned.</p> <p>While such issue can be prevented today by checking the gas with EIP-150 in mind, a solution at the opcode level is more elegant.</p> <p>Indeed, the two possible ways to currently enforce that the correct amount of gas is sent are as follow :</p> <ol> <li>check done before the call</li> </ol> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>uint256 gasAvailable = gasleft() - E;</span></span> <span class="giallo-l"><span>require(gasAvailable - gasAvailable / 64 &gt;= `txGas`, &quot;not enough gas provided&quot;)</span></span> <span class="giallo-l"><span>to.call.gas(txGas)(data); // CALL</span></span></code></pre> <p>where E is the gas required for the operation between the call to <code>gasleft()</code> and the actual call PLUS the gas cost of the call itself. While it is possible to simply over estimate <code>E</code> to prevent call to be executed if not enough gas is provided to the current call it would be better to have the EVM do the precise work itself. As gas pricing continue to evolve, this is important to have a mechanism to ensure a specific amount of gas is passed to the call so such mechanism can be used without having to relies on a specific gas pricing.</p> <ol start="2"> <li>check done after the call:</li> </ol> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>to.call.gas(txGas)(data); // CALL</span></span> <span class="giallo-l"><span>require(gasleft() &gt; txGas / 63, &quot;not enough gas left&quot;);</span></span></code></pre> <p>This solution does not require to compute a <code>E</code> value and thus do not relies on a specific gas pricing (except for the behaviour of EIP-150) since if the call is given not enough gas and fails for that reason, the condition above will always fail, ensuring the current call will revert. But this check still pass if the gas given was less AND the external call reverted or succeeded EARLY (so that the gas left after the call &gt; txGas / 63). This can be an issue if the code executed as part of the CALL is reverting as a result of a check against the gas provided. Like a meta transaction in a meta transaction.</p> <p>Similarly to the previous solution, an EVM mechanism would be much better.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>for specification a) : Backwards compatible as it introduce new opcodes.</p> <p>for specification b) : Backwards compatible as it use value range outside of what is used by existing contract (to be verified)</p> <h2 id="test-cases">Test Cases</h2> <h2 id="implementation">Implementation</h2> <p>None fully implemented yet. But see Specifications for an example in geth.</p> <h2 id="references">References</h2> <ol> <li>EIP-150, ./00150.md</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-03-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gregory Markougreg@chainsafe.io Kevin Owockikevin@gitcoin.co Lane Rettiglane@ethereum.org https://wg-eips.ritovision.com/1890/ <h1 id="commitment-to-sustainable-ecosystem-funding">Commitment to Sustainable Ecosystem Funding</h1> <h2 id="simple-summary">Simple Summary</h2> <p>Ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. This EIP adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards.</p> <h2 id="abstract">Abstract</h2> <p>A mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. Both values are set to zero.</p> <h2 id="motivation">Motivation</h2> <p>In order for Ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. Those talented researchers and developers deserve to be paid fairly for their work. At present there is no mechanism in the Ethereum ecosystem that rewards R&amp;D teams fairly for their work on the platform.</p> <p>We recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. It will take time to work out the answer to these questions. For this reason, this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep Ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to Ethereum’s economics. Raising the amount captured above zero would require a future EIP.</p> <h2 id="specification">Specification</h2> <p>Two new constants are introduced: BENEFICIARY_ADDRESS, an Address, and DEVFUND_BLOCK_REWARD, an amount denominated in wei. Both are set to zero.</p> <p>Beginning with block ISTANBUL_BLOCK_HEIGHT, DEVFUND_BLOCK_REWARD wei is added to the balance of BENEFICIARY_ADDRESS at each block.</p> <p>We may optionally add another constant, DECAY_FACTOR, which specifies a linear or exponenential decay factor that reduces the reward at every block &gt; ISTANBUL_BLOCK_HEIGHT until it decays to zero. For simplicity, it has been omitted from this proposal.</p> <h2 id="rationale">Rationale</h2> <p>We believe that the technical design of this EIP is straightforward. The social rationale is explained in <a rel="external" href="https://medium.com/gitcoin/funding-open-source-in-the-blockchain-era-8ded753bf05f">this article</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP has no impact on backwards compatibility.</p> <h2 id="test-cases">Test Cases</h2> <p>This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient.</p> <h2 id="implementation">Implementation</h2> <p>Reference implementations are included for the Trinity, go-ethereum, and parity clients.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-03-28T00:00:00+00:00 2026-02-11T14:49:28+00:00 Martin Holst Swendehttps://github.com/holiman https://wg-eips.ritovision.com/1884/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP proposes repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption.</p> <h2 id="abstract">Abstract</h2> <p>The growth of the Ethereum state has caused certain opcodes to be more resource-intensive at this point than they were previously. This EIP proposes to raise the <code>gasCost</code> for those opcodes.</p> <h2 id="motivation">Motivation</h2> <p>An imbalance between the price of an operation and the resource consumption (CPU time, memory etc) has several drawbacks:</p> <ul> <li>It could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time.</li> <li>Underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly.</li> </ul> <p>If operations are well-balanced, we can maximise the block gaslimit and have a more stable processing time.</p> <h2 id="specification">Specification</h2> <p>At block <code>N</code>,</p> <ul> <li>The <code>SLOAD</code> (<code>0x54</code>) operation changes from <code>200</code> to <code>800</code> gas,</li> <li>The <code>BALANCE</code> (<code>0x31</code>) operation changes from <code>400</code> to <code>700</code> gas,</li> <li>The <code>EXTCODEHASH</code> (<code>0x3F</code>) operation changes from <code>400</code> to <code>700</code> gas,</li> <li>A new opcode, <code>SELFBALANCE</code> is introduced at <code>0x47</code>. <ul> <li><code>SELFBALANCE</code> pops <code>0</code> arguments off the stack,</li> <li><code>SELFBALANCE</code> pushes the <code>balance</code> of the current address to the stack,</li> <li><code>SELFBALANCE</code> is priced as <code>GasFastStep</code>, at <code>5</code> gas.</li> </ul> </li> </ul> <h2 id="rationale">Rationale</h2> <p>Here are two charts, taken from a full sync using Geth. The execution time was measured for every opcode, and aggregated for 10K blocks. These bar charts show the top 25 'heavy' opcodes in the ranges 5M to 6M and 6M to 7M:</p> <p><img src="https://wg-eips.ritovision.com/1884/./assets/run3.total-bars-5.png" alt="bars1" /> <img src="https://wg-eips.ritovision.com/1884/./assets/run3.total-bars-6.png" alt="bars2" /></p> <p>Note: It can also be seen that the <code>SLOAD</code> moves towards the top position. The <code>GASPRICE</code> (<code>0x3a</code>) opcode has position one which I believe can be optimized away within the client -- which is not the case with <code>SLOAD</code>/<code>BALANCE</code>.</p> <p>Here is another chart, showing a full sync with Geth. It represents the blocks <code>0</code> to <code>5.7M</code>, and highlights what the block processing time is spent on.</p> <p><img src="https://wg-eips.ritovision.com/1884/./assets/geth_processing.png" alt="geth" /></p> <p>It can be seen that <code>storage_reads</code> and <code>account_reads</code> are the two most significant factors contributing to the block processing time.</p> <h3 id="sload"><code>SLOAD</code></h3> <p><code>SLOAD</code> was repriced at <a href="https://wg-eips.ritovision.com/150/">EIP-150</a>, from <code>50</code> to <code>200</code>. The following graph shows a go-ethereum full sync, where each data point represents 10K blocks. During those 10K blocks, the execution time for the opcode was aggregated.</p> <p><img src="https://wg-eips.ritovision.com/1884/./assets/SLOAD-run3.png" alt="graph" /></p> <p>It can be seen that the repricing at <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> caused a steep drop, from around <code>67</code> to <code>23</code>. Around block <code>5M</code>, it started reaching pre-<a href="https://wg-eips.ritovision.com/150/">EIP-150</a> levels, and at block <code>7M</code> it was averaging on around <code>150</code> - more than double pre-eip-150 levels.</p> <p>Increasing the cost of <code>SLOAD</code> by <code>4</code> would bring it back down to around <code>40</code>. It is to be expected that it will rise again in the future, and may need future repricing, unless state clearing efforts are implemented before that happens.</p> <h3 id="balance"><code>BALANCE</code></h3> <p><code>BALANCE</code> (a.k.a <code>EXTBALANCE</code>) is an operation which fetches data from the state trie. It was repriced at <a href="https://wg-eips.ritovision.com/150/">EIP-150</a> from <code>20</code> to <code>400</code>.</p> <p><img src="https://wg-eips.ritovision.com/1884/./assets/BALANCE-run3.png" alt="graph" /></p> <p>It is comparable to <code>EXTCODESIZE</code> and <code>EXTCODEHASH</code>, which are priced at <code>700</code> already.</p> <p>It has a built-in high variance, since it is often used for checking the balance of <code>this</code>, which is an inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access.</p> <p>In hindsight, it might have been a better choice to have two opcodes: <code>EXTBALANCE(address)</code> and <code>SELFBALANCE</code>, and have two different prices.</p> <ul> <li>This EIP proposes to extend the current opcode set. <ul> <li>Unfortunately, the opcode span <code>0x3X</code> is already full, hence the suggestion to place <code>SELFBALANCE</code> in the <code>0x4X</code> range.</li> <li>As for why it is priced at <code>5</code> (<code>GasFastStep</code>) instead of <code>2</code> (<code>GasQuickStep</code>), like other similar operations: the EVM execution engine still needs a lookup into the (cached) trie, and <code>balance</code>, unlike <code>gasPrice</code> or <code>timeStamp</code>, is not constant during the execution, so it has a bit more inherent overhead.</li> </ul> </li> </ul> <h3 id="extcodehash"><code>EXTCODEHASH</code></h3> <p><code>EXTCODEHASH</code> was introduced in Constantinople, with <a href="https://wg-eips.ritovision.com/1052/">EIP-1052</a>. It was priced at <code>400</code> with the reasoning:</p> <blockquote> <p>The gas cost is the same as the gas cost for the <code>BALANCE</code> opcode because the execution of the <code>EXTCODEHASH</code> requires the same account lookup as in <code>BALANCE</code>.</p> </blockquote> <p>Ergo, if we increase <code>BALANCE</code>, we should also increase <code>EXTCODEHASH</code></p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The changes require a hardfork. The changes have the following consequences:</p> <ul> <li>Certain calls will become more expensive.</li> <li>Default-functions which access the storage and may in some cases require more than<code>2300</code> gas (the minimum gas that is always available in calls).</li> <li>Contracts that assume a certain fixed gas cost for calls (or internal sections) may cease to function. <ul> <li>A fixed gas cost is specified in <a href="https://wg-eips.ritovision.com/165/">ERC-165</a> and implementations of this interface do use the affected opcodes. <ul> <li>The ERC-165 method <code>supportsInterface</code> must return a <code>bool</code> and use at most <code>30,000</code> gas.</li> <li>The two example implementations from the EIP were, at the time of writing <ol> <li><code>586</code> gas for any input, and</li> <li><code>236</code> gas, but increases linearly with a higher number of supported interfaces</li> </ol> </li> </ul> </li> <li>It is unlikely that any ERC-165 <code>supportsInterface</code> implementation will go above <code>30.000</code> gas. That would require that the second variant is used, and thirty:ish interfaces are supported.</li> <li>However, these operations have already been repriced earlier, so there is a historical precedent that 'the gascost for these operations may change', which should have prevented such fixed-gas-cost assumptions from being implemented.</li> </ul> </li> </ul> <p>I expect that certain patterns will be less used, for example the use of multiple modifiers which <code>SLOAD</code>s the same opcode will be merged into one. It may also lead to less <code>log</code> operations containing <code>SLOAD</code>ed values that are not strictly necessary.</p> <h2 id="test-cases">Test Cases</h2> <p>Testcases that should be implemented:</p> <ul> <li>Test that <code>selfbalance == balance(address)</code>,</li> <li>Test that <code>balance(this)</code> costs as before,</li> <li>Test that <code>selfbalance</code> does not pop from stack</li> <li>Gascost verification of <code>SLOAD</code>, <code>EXTCODEHASH</code> and <code>SELFBALANCE</code></li> <li>Verify that <code>SELFBALANCE</code> is invalid before Istanbul</li> </ul> <p>Some testcases have been implemented as statetests at https://github.com/holiman/IstanbulTests/tree/master/GeneralStateTests</p> <h2 id="implementation">Implementation</h2> <p>This EIP has not yet been implemented in any client. Both these opcodes have been repriced before, and the client internals for managing reprices are already in place.</p> <h3 id="selfbalance"><code>SELFBALANCE</code></h3> <p>This is the implementation for the new opcode in go-ethereum:</p> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">func</span><span class="z-entity z-name"> opSelfBalance</span><span>(</span><span class="z-variable">pc</span><span class="z-keyword"> *</span><span class="z-storage z-type">uint64</span><span>,</span><span class="z-variable"> interpreter</span><span class="z-keyword"> *</span><span class="z-entity z-name">EVMInterpreter</span><span>,</span><span class="z-variable"> contract</span><span class="z-keyword"> *</span><span class="z-entity z-name">Contract</span><span>,</span><span class="z-variable"> memory</span><span class="z-keyword"> *</span><span class="z-entity z-name">Memory</span><span>,</span><span class="z-variable"> stack</span><span class="z-keyword"> *</span><span class="z-entity z-name">Stack</span><span>)</span><span> (</span><span>[</span><span>]</span><span class="z-storage z-type">byte</span><span>,</span><span class="z-storage z-type"> error</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-other"> stack</span><span>.</span><span class="z-entity z-name">push</span><span>(</span><span class="z-variable z-other">interpreter</span><span>.</span><span class="z-variable z-other">intPool</span><span>.</span><span class="z-entity z-name">get</span><span>(</span><span>)</span><span>.</span><span class="z-entity z-name">Set</span><span>(</span><span class="z-variable z-other">interpreter</span><span>.</span><span class="z-variable z-other">evm</span><span>.</span><span class="z-variable z-other">StateDB</span><span>.</span><span class="z-entity z-name">GetBalance</span><span>(</span><span class="z-variable z-other">contract</span><span>.</span><span class="z-entity z-name">Address</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> nil</span><span>,</span><span class="z-constant"> nil</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span></code></pre><h2 id="security-considerations">Security considerations</h2> <ul> <li>See backwards compatibility section.</li> <li>There are no special edgecases regarding <code>SELFBALANCE</code>, if we define it as <code>BALANCE</code> with <code>address</code> instead of popping an address from the stack -- since <code>BALANCE</code> is already well-defined.</li> <li>It should be investigated if Solidity contains any hardcoded expectations on the gas cost of these operations.</li> <li>In many cases, a recipient of <code>ether</code> from a <code>CALL</code> will want to issue a <code>LOG</code>. The <code>LOG</code> operation costs <code>375</code> plus <code>375</code> per topic. If the <code>LOG</code> also wants to do an <code>SLOAD</code>, this change may make some such transfers fail.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-03-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Remco BloemenRecmo@0x.org https://wg-eips.ritovision.com/1829/ <h1 id="precompile-for-elliptic-curve-linear-combinations">Precompile for Elliptic Curve Linear Combinations</h1> <h2 id="simple-summary">Simple Summary</h2> <p>Currently the EVM only supports <em>secp256k1</em> in a limited way through <code>ecrecover</code> and <em>altbn128</em> through two pre-compiles. There are draft proposals to add more curves. There are many more elliptic curves that have useful applications for integration with existing systems or newly developed curves for zero-knowledge proofs.</p> <p>This EIP adds a precompile that allows whole classes of curves to be used.</p> <h2 id="abstract">Abstract</h2> <p>A precompile that takes a curve and computes a linear combination of curve points.</p> <h2 id="motivation">Motivation</h2> <h2 id="specification">Specification</h2> <p>Given integers <code>m, α</code> and <code>β</code>, scalars <code>s_i</code>, and curve points <code>A_i</code> construct the elliptic curve</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>y² = x³ + α ⋅ x + β mod m</span></span></code></pre> <p>and compute the following</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>C = s₀ ⋅ A₀ + s₁ ⋅ A₁ + ⋯ + s_n ⋅ A_n</span></span></code></pre> <p>aka <em>linear combination</em>, <em>inner product</em>, <em>multi-multiplication</em> or even <em>multi-exponentiation</em>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(Cx, Cy) := ecmul(m, α, β, s0, Ax0, As0, s1, Ax1, As1, ...)</span></span></code></pre><h3 id="gas-cost">Gas cost</h3> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>BASE_GAS = ...</span></span> <span class="giallo-l"><span>ADD_GAS = ...</span></span> <span class="giallo-l"><span>MUL_GAS = ...</span></span></code></pre> <p>The total gas cost is <code>BASE_GAS</code> plus <code>ADD_GAS</code> for each <code>s_i</code> that is <code>1</code> and <code>MUL_GAS</code> for each <code>s_i &gt; 1</code> (<code>s_i = 0</code> is free).</p> <h3 id="encoding-of-points">Encoding of points</h3> <p>Encode as <code>(x, y')</code> where <code>s</code> indicates whether <code>y</code> or <code>-y</code> is to be taken. It follows SEC 1 v 1.9 2.3.4, except uncompressed points (<code>y' = 0x04</code>) are not supported.</p> <table><thead><tr><th><code>y'</code></th><th><code>(x, y)</code></th></tr></thead><tbody> <tr><td><code>0x00</code></td><td>Point at infinity</td></tr> <tr><td><code>0x02</code></td><td>Solution with <code>y</code> even</td></tr> <tr><td><code>0x03</code></td><td>Solution with <code>y</code> odd</td></tr> </tbody></table> <p>Conversion from affine coordinates to compressed coordinates is trivial: <code>y' = 0x02 | (y &amp; 0x01)</code>.</p> <h3 id="special-cases">Special cases</h3> <p><strong>Coordinate recovery.</strong> Set <code>s₀ = 1</code>. The output will be the recovered coordinates of <code>A₀</code>.</p> <p><strong>On-curve checking.</strong> Do coordinate recovery and compare <code>y</code> coordinate.</p> <p><strong>Addition.</strong> Set <code>s₀ = s₁ = 1</code>, the output will be <code>A₀ + A₁</code>.</p> <p><strong>Doubling.</strong> Set <code>s₀ = 2</code>. The output will be <code>2 ⋅ A₀</code>. (Note: under the current gas model, this may be more costly than self-addition!)</p> <p><strong>Scalar multiplication.</strong> Set only <code>s₀</code> and <code>A₀</code>.</p> <p><strong>Modular square root.</strong> Set <code>α = s₀ = A = 0</code> the output will have <code>Cy² = β mod m</code>.</p> <h3 id="edge-cases">Edge cases</h3> <ul> <li>Non-prime moduli or too small modulus</li> <li>Field elements larger than modulus</li> <li>Curve has singular points (<code>4 α³ + 27 β² = 0</code>)</li> <li>Invalid sign bytes</li> <li>x coordinate not on curve</li> <li>Returning the point at infinity</li> <li>(Please add if you spot more)</li> </ul> <h2 id="rationale">Rationale</h2> <p><strong>Generic Field and Curve.</strong> Many important optimizations are independent of the field and curve used. Some missed specific optimizations are:</p> <ul> <li>Reductions specific to the binary structure of the field prime.</li> <li>Precomputation of Montgomery factors.</li> <li>Precomputation of multiples of certain popular points like the generator.</li> <li>Special point addition/doubling <a rel="external" href="https://www.hyperelliptic.org/EFD/g1p/auto-shortw.html">formulas</a> for <code>α = -3</code>, <code>α = -1</code>, <code>α = 0</code>, <code>β = 0</code>.</li> </ul> <p>TODO: The special cases for <code>α</code> and <code>β</code> might be worth implementing and offering a gas discount.</p> <p><strong>Compressed Coordinates.</strong> Compressed coordinates allow contract to work with only <code>x</code> coordinates and sign bytes. It also prevents errors around points not being on-curve. Conversion to compressed coordinates is trivial.</p> <p><strong>Linear Combination.</strong> We could instead have a simple multiply <code>C = r ⋅ A</code>. In this case we would need a separate pre-compile for addition. In addition, a linear combination allows for optimizations that like Shamir's trick that are not available in a single scalar multiplication. ECDSA requires <code>s₀ ⋅ A₀ + s₁ ⋅ A₁</code> and would benefit from this.</p> <p>The BN254 (aka alt_bn8) multiplication operation introduced by the <a href="https://wg-eips.ritovision.com/196/">EIP-196</a> precompile only handles a single scalar multiplication. The missed performance is such that for two or more points it is cheaper to use EVM, as practically demonstrated by <a rel="external" href="https://medium.com/aztec-protocol/huffing-for-crypto-with-weierstrudel-9c9568c06901">Weierstrudel</a>.</p> <p><strong>Variable Time Math.</strong> When called during a transaction, there is no assumption of privacy and no mitigations for side-channel attacks are necessary.</p> <p><strong>Prime Fields.</strong> This EIP is for fields of large characteristic. It does not cover Binary fields and other fields of non-prime characteristic.</p> <p><strong>256-bit modulus.</strong> This EIP is for field moduli less than <code>2^{256}</code>. This covers many of the popular curves while still having all parameters fit in a single EVM word.</p> <p>TODO: Consider a double-word version. 512 bits would cover all known curves except E-521. In particular it will cover the NIST P-384 curve used by the Estonian e-Identity and the BLS12-381 curve used by <a rel="external" href="https://z.cash/blog/new-snark-curve/">ZCash Sappling</a>.</p> <p><strong>Short Weierstrass Curves.</strong> This EIP is for fields specified in short Weierstrass form. While any curve can be converted to short Weierstrass form through a <a rel="external" href="https://safecurves.cr.yp.to/equation.html">substitution of variables</a>, this misses out on the performance advantages of those specific forms.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h2 id="test-cases">Test Cases</h2> <h2 id="implementation">Implementation</h2> <p>There will be a reference implementation in Rust based on the existing libraries (in particular those by ZCash and The Matter Inc.).</p> <p>The reference implementation will be production grade and compile to a native library with a C api and a webassembly version. Node developers are encouraged to use the reference implementation and can use either the rust library, the native C bindings or the webassembly module. Node developers can of course always decide to implement their own.</p> <h2 id="references">References</h2> <p>This EIP overlaps in scope with</p> <ul> <li><a href="https://wg-eips.ritovision.com/196/">EIP-196</a>: ecadd, ecmul for altbn128</li> <li><a rel="external" href="https://github.com/ethereum/EIPs/issues/603">EIP issue 603</a>: ecadd, ecmul for SECP256k1.</li> <li><a href="https://wg-eips.ritovision.com/665/">EIP-665</a>: ECDSA verify for ED25519.</li> <li><a href="https://wg-eips.ritovision.com/1108/">EIP-1108</a>: Optimize ecadd and ecmul for altbn128.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-01-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Forshtatalex@tabookey.com Yoav Weissyoav@tabookey.com https://wg-eips.ritovision.com/1706/ <h2 id="simple-summary">Simple Summary</h2> <p>The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade.</p> <h2 id="abstract">Abstract</h2> <p><a href="https://wg-eips.ritovision.com/1283/">EIP-1283</a> significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls. This danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP.</p> <h2 id="motivation">Motivation</h2> <p>An attack that is described in <a rel="external" href="https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9">this article</a>. Explicitly specifying the call stipend as an invariant will have a positive effect on Ethereum protocol security: https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt</p> <h2 id="specification">Specification</h2> <p>Add the following condition to the SSTORE opcode gas cost calculation:</p> <ul> <li>If <em>gasleft</em> is less than or equal to 2300, fail the current call frame with 'out of gas' exception.</li> </ul> <h2 id="rationale">Rationale</h2> <p>In order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to 'transfer'/'send' in Solidity. These are other proposed remediations and objections to implementing them:</p> <ul> <li>Drop EIP-1283 and abstain from modifying SSTORE cost <ul> <li>EIP-1283 is an important update</li> <li>It was accepted and implemented on test networks and in clients.</li> </ul> </li> <li>Add a new call context that permits LOG opcodes but not changes to state. <ul> <li>Adds another call type beyond existing regular/staticcall</li> </ul> </li> <li>Raise the cost of SSTORE to dirty slots to &gt;=2300 gas <ul> <li>Makes net gas metering much less useful.</li> </ul> </li> <li>Reduce the gas stipend <ul> <li>Makes the stipend almost useless.</li> </ul> </li> <li>Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter <ul> <li>Still doesn’t make the invariant explicit.</li> <li>Requires callers to supply more gas, just to have it refunded</li> </ul> </li> <li>Add contract metadata specifying per-contract EVM version, and only apply SSTORE changes to contracts deployed with the new version.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Performing SSTORE has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum mainnet. Gas estimation should account for this requirement.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. TODO</p> <h2 id="implementation">Implementation</h2> <p>TODO</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2019-01-08T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Holst Swendehttps://github.com/holiman https://wg-eips.ritovision.com/1681/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a <code>valid-until</code> timestamp. This EIP is very similar to https://github.com/ethereum/EIPs/pull/599 by Nick Johnson and Konrad Feldmeier, the main difference being that this EIP is based on clock-time / walltime instead of block numbers.</p> <h2 id="motivation">Motivation</h2> <p>There are a couple of different motivators for introducing a timebased transaction validity.</p> <ul> <li>If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user.</li> <li>In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues.</li> <li>Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system.</li> </ul> <h2 id="specification">Specification</h2> <p>The roll-out would be performed in two phases, <code>X</code> (hardfork), and <code>Y</code> (softfork).</p> <p>At block <code>X</code>,</p> <ul> <li>Add an optional field <code>valid-until</code> to the RLP-encoded transaction, defined as a <code>uint64</code> (same as <code>nonce</code>).</li> <li>If the field is present in transaction <code>t</code>, then <ul> <li><code>t</code> is only eligible for inclusion in a block if <code>block.timestamp</code> &lt; <code>t.valid-until</code>.</li> </ul> </li> </ul> <p>At block <code>Y</code>,</p> <ul> <li>Make <code>valid-until</code> mandatory, and consider any transaction without <code>valid-until</code> to be invalid.</li> </ul> <h2 id="rationale">Rationale</h2> <h3 id="rationale-for-this-eip">Rationale for this EIP</h3> <p>For the dust-account clearing usecase,</p> <ul> <li>This change is much less invasive in the consensus engine. <ul> <li>No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block.</li> <li>Only touches the transaction validation part of the consensus engine</li> <li>Other schemas which uses the <code>nonce</code> can have unintended side-effects, <ul> <li>such as inability to create contracts at certain addresses.</li> <li>more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine.</li> <li>More intricate schemes like <code>highest-nonce</code> are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field.</li> </ul> </li> </ul> </li> </ul> <h3 id="rationale-for-walltime">Rationale for walltime</h3> <p>Why use walltime instead of block numbers, as proposed in https://github.com/ethereum/EIPs/pull/599 ?</p> <ul> <li>The UTC time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties.</li> <li>The correlation between time and block number is not fixed; even though a 14s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression.</li> <li>The block number is even more unreliable as a timestamp for testnets and private networks.</li> <li>UTC time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitalbe number of valid blocks.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP means that all software/hardware that creates transactions need to add timestamps to the transactions, or will otherwise be incapable of signing transactions after block <code>Y</code>. Note: this EIP does not introduce any maximum <code>valid-until</code> date, so it would still be possible to create transactions with near infinite validity.</p> <h2 id="test-cases">Test Cases</h2> <p>todo</p> <h2 id="implementation">Implementation</h2> <p>None yet</p> <h2 id="security-considerations">Security considerations</h2> <p>The most notable security impact is that pre-signed transactions stored on paper backups, will become invalid as of block <code>Y</code>. There are a couple of cases where this might be used</p> <ul> <li>Pregenerated onetime 'bootstrap' transactions, e.g. to onboard a user into Ethereum. Instead of giving a user a giftcard with actual ether on it, someone may instead give the person a one-time pregenerated transaction that will only send those ether to the card once the user actively wants to start using it.</li> <li>If a user has an offline paper-wallet, he may have pregenerated transactions to send value to e.g. an exchange. This is sometimes done to be able to send ether to an exchange without having to go through all the hoops of bringing the paper wallet back to 'life'.</li> </ul> <p>Secondary security impacts are that the addition of a timestamp would make the transactions a little bit larger.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-11-10T00:00:00+00:00 2026-02-11T14:49:28+00:00 Felix J Langehttps://github.com/fjl Martin Holst Swendehttps://github.com/holiman https://wg-eips.ritovision.com/1682/ <h2 id="abstract">Abstract</h2> <p>This EIP describes a scheme to charge for data in state, and 'archive' data which is no longer being paid for. It also describes how resurrection of 'archived' data happens.</p> <h2 id="motivation">Motivation</h2> <p>The Ethereum blockchain in its current form is not sustainable because it grows indefinitely. This is true of any blockchain, but Ethereum grows faster than most chains. Many implementation strategies to slow down growth exist. A common strategy is 'state pruning' which discards historical state, keeping only the active copy of contract data and a few recent versions to deal with short-range chain reorganizations. Several implementations also employ compression techniques to keep the active copy of the state as small as possible.</p> <p>A full node participating in consensus today requires storing large amounts of data even with advanced storage optimizations applied. Future storage requirements are unbounded because any data stored in a contract must be retained forever as dictated by the protocol. This EIP attempts to correct this by adding new consensus rules that put an upper bound on the size of the Ethereum state.</p> <p>Adding these new rules changes fundamental guarantees of the system and requires a hard fork. Users of Ethereum already pay for the creation and modification of accounts and their storage entries. Under the rules introduced in this EIP, users must also pay to keep accounts accessible. A similar rent scheme was proposed in <a rel="external" href="https://github.com/ethereum/EIPs/issues/35">EIP-103</a> but rejected even back then because the proposal would've upset peoples expectations. As implementers of Ethereum, we still feel that state rent is the right path to long-term sustainability of the Ethereum blockchain and that its undesirable implications can be overcome with off-protocol tooling and careful design.</p> <h2 id="specification">Specification</h2> <p>The cost of storing an account over time is called <code>rent</code>. The amount of <code>rent</code> due depends on the size of the account. The <code>ether</code> that is paid for <code>rent</code> is destroyed. The <code>rent</code> is deducted whenever an account is touched.</p> <p><code>rent</code> can be paid from the account's regular <code>balance</code> or from its 'rent balance'. Accounts can be endowed with <code>rent balance</code> through a new EVM opcode. When <code>rent</code> is charged, it is first taken from the <code>rent balance</code>. When <code>rent balance</code> is zero, it is instead charged from the account's regular <code>balance</code> instead.</p> <p>The reason to separate <code>balance</code> and <code>rent balance</code> is that certain contracts do not accept <code>ether</code> sends, or always send the entire balance off to some other destination. For these cases, a separate<code>rent balance</code> is required.</p> <p>When an account's <code>balance</code> is insufficient to pay rent, the account becomes <code>inactive</code>. Its storage and contract code are removed. Inactive accounts cannot be interacted with, i.e. it behaves as if it has no contract code.</p> <p>Inactive accounts can be restored by re-uploading their storage. To restore an inactive account <code>A</code>, a new account <code>B</code> is created with arbitrary code and its storage modified with <code>SSTORE</code> operations until it matches the storage root of <code>A</code>. Account <code>B</code> can restore <code>A</code> through the <code>RESTORETO</code> opcode. This means the cost of restoring an account is equivalent to recreating it via successive <code>SSTORE</code> operations.</p> <h3 id="changes-to-state">Changes To State</h3> <p>At the top level, a new key <code>size</code> is added to the accounts trie. This key tracks the total number of trie nodes across all accounts, including storage trie nodes. To track rent, the structure of account entries is changed as well.</p> <p>Before processing the block in which this EIP becomes active, clients iterate the whole state once to count the number of trie nodes and to change the representation of all accounts to the new format.</p> <h4 id="account-representation">Account Representation</h4> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>account = [nonce, balance, storageroot, codehash, rentbalance, rentblock, storagesize]</span></span></code></pre> <p>Each account gets three additional properties: <code>rentbalance</code>, <code>rentblock</code> and <code>storagesize</code>.</p> <p>The <code>rentbalace</code> field tracks the amount of <code>rent balance</code> available to the account. Upon self-destruction any remaining <code>rent balance</code> is transferred to the beneficiary. Any modification of the account recomputes its current <code>rent balance</code>.</p> <p>The <code>rentblock</code> field tracks the block number in which the <code>rent balance</code> was last recomputed. Upon creation, this field is initialized with the current block number. <code>rentblock</code> is also updated with the current block number whenever the account is modified.</p> <p>The <code>storagesize</code> field tracks the amount of storage related to the account. It is a number containing the number of storage slots currently set. The <code>storagesize</code> of an inactive account is zero.</p> <h3 id="charging-rent">Charging Rent</h3> <p>There is a new protocol constant <code>MAX_STORAGE_SIZE</code> that specifies the upper bound on the number of state tree nodes:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-constant">MAX_STORAGE_SIZE</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">32</span><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ~160GB of state</span></span></code></pre> <p>A 'storage fee factor' for each block is derived from this constant such that fees increase as the limit is approached.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> storagefee_factor</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> ramp</span><span class="z-keyword"> =</span><span class="z-constant"> MAX_STORAGE_SIZE</span><span class="z-keyword"> /</span><span> (</span><span class="z-constant">MAX_STORAGE_SIZE</span><span class="z-keyword"> -</span><span> total_storage_size</span><span>(</span><span>block</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">22</span><span class="z-keyword"> *</span><span> ramp</span></span></code></pre> <p>When a block is processed, <code>rent</code> is deducted from all accounts modified by transactions in the block after the transactions have been processed. The amount due for each account is based on the account's storage size.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> rent</span><span>(</span><span class="z-variable z-parameter z-function">prestate</span><span>,</span><span class="z-variable z-parameter z-function"> poststate</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>,</span><span class="z-variable z-parameter z-function"> currentblock</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> b</span><span class="z-keyword"> in</span><span class="z-support"> range</span><span>(</span><span>prestate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentblock</span><span class="z-keyword">+</span><span class="z-constant">1</span><span>,</span><span> currentblock</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> +=</span><span> storagefee_factor</span><span>(</span><span>b</span><span>)</span><span class="z-keyword"> *</span><span> prestate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>storagesize</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> fee</span><span class="z-keyword"> +</span><span> storagefee_factor</span><span>(</span><span>currentblock</span><span>)</span><span class="z-keyword"> *</span><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>storagesize</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> charge_rent</span><span>(</span><span class="z-variable z-parameter z-function">prestate</span><span>,</span><span class="z-variable z-parameter z-function"> poststate</span><span>,</span><span class="z-variable z-parameter z-function"> addr</span><span>,</span><span class="z-variable z-parameter z-function"> currentblock</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> =</span><span> rent</span><span>(</span><span>prestate</span><span>,</span><span> poststate</span><span>,</span><span> addr</span><span>,</span><span> currentblock</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> fee</span><span class="z-keyword"> &lt;=</span><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentbalance</span><span>:</span></span> <span class="giallo-l"><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentbalance</span><span class="z-keyword"> -=</span><span> fee</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span> fee</span><span class="z-keyword"> -=</span><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentbalance</span></span> <span class="giallo-l"><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentbalance</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span></span> <span class="giallo-l"><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>balance</span><span class="z-keyword"> -=</span><span class="z-support"> min</span><span>(</span><span>poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>balance</span><span>,</span><span> fee</span><span>)</span></span> <span class="giallo-l"><span> poststate</span><span>[</span><span>addr</span><span>]</span><span>.</span><span>rentblock</span><span class="z-keyword"> =</span><span> currentblock</span></span></code></pre><h3 id="new-evm-opcodes">New EVM Opcodes</h3> <h4 id="payrent-amount-addr"><code>PAYRENT &lt;amount&gt; &lt;addr&gt;</code></h4> <p>At any time, the <code>rent balance</code> of an account may be topped up by the <code>PAYRENT</code> opcode. <code>PAYRENT</code> deducts the given amount of <code>ether</code> from the account executing the opcode and adds it to the <code>rent balance</code> of the address specified as beneficiary.</p> <p>Any participant can pay the rent for any other participant.</p> <p>Gas cost: TBD</p> <h4 id="rentbalance-addr"><code>RENTBALANCE &lt;addr&gt;</code></h4> <p>The <code>rent balance</code> of an account may be queried through the <code>RENTBALANCE</code> opcode. It pushes the <code>rentbalance</code> field of the given address to the stack.</p> <p>Gas cost: like <code>EXTCODEHASH</code>.</p> <h4 id="ssize-addr"><code>SSIZE &lt;addr&gt;</code></h4> <p>This opcode pushes the <code>storagesize</code> field of the given account to the stack.</p> <p>Gas cost: like <code>EXTCODEHASH</code>.</p> <h4 id="restoreto-addr-codeaddr"><code>RESTORETO &lt;addr&gt; &lt;codeaddr&gt;</code></h4> <p>This opcode restores the inactive account at the given address. This is a bit like <code>SELFDESTRUCT</code> but has more specific semantics.</p> <p>The account at <code>addr</code> must be <code>inactive</code> (i.e. have <code>storagesize</code> zero) and its <code>storageroot</code> must match the <code>storageroot</code> of the contract executing <code>RESTORETO</code>. The <code>codeaddr</code> specifies the address of a contract from which code is taken. The code of the <code>codeaddr</code> account must match the <code>codehash</code> of <code>addr</code>.</p> <p>If all these preconditions are met, <code>RESTORETO</code> transfers the storage of the account executing the opcode to <code>addr</code> and resets its <code>storagesize</code> to the full size of the storage. The code of <code>addr</code> is restored as well. <code>RESTORETO</code> also transfers any remaining balance and rent balance to <code>addr</code>. The contract executing <code>RESTORETO</code> is deleted.</p> <p>Gas cost: TBD</p> <h2 id="rationale">Rationale</h2> <h3 id="why-do-we-need-a-separate-rent-balance">Why do we need a separate rent balance?</h3> <p>Accounts need a separate rent balance because some contracts are non-payable, i.e. they reject regular value transfers. Such contracts might not be able to keep themselves alive, but users of those contracts can keep them alive by paying rent for them.</p> <p>Having the additional balance also makes things easier for contracts that hold balance on behalf of a user. Consider the canonical crowdfunding example, a contract which changes behavior once a certain balance is reached and which tracks individual user's balances. Deducting rent from the main balance of the contract would mess up the contract's accounting, leaving it unable to pay back users accurately if the threshold balance isn't reached.</p> <h3 id="why-restoration">Why restoration?</h3> <p>One of the fundamental guarantees provided by Ethereum is that changes to contract storage can only be made by the contract itself and storage will persist forever. If you hold a token balance in a contract, you'll have those tokens forever. By adding restoration, we can maintain this guarantee to a certain extent.</p> <h3 id="implementation-impact">Implementation Impact</h3> <p>The proposed changes tries to fit within the existing state transition model. Note that there is no mechanism for deactivating accounts the moment they can't pay rent. Users must touch accounts to ensure their storage is removed because we'd need to track all accounts and their rent requirements in an auxlilary data structure otherwise.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>TBA</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-11-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 trustfarmtrustfarm.info@gmail.com trustfarmcpplover@trustfarm.net https://wg-eips.ritovision.com/1485/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm.</p> <h2 id="abstract">Abstract</h2> <p>This EIP pursue "obsolete current ASIC miners" by modifying PoW algorithm in a very low risk manner and update to latest hash algorithm from deprecated FNV Hash algorithms.</p> <p>Following TEthashV1 algorithm suggests safe transition of PoW algorithms and secure the FNV Algorithm in MIX Parts.</p> <h2 id="motivation">Motivation</h2> <p>Provide original Ethash proof of work verification with minimal set of changes by updating FNV0 algorithm</p> <h2 id="specification">Specification</h2> <h4 id="1-reference-materials-on-ethash-fnv0">1. Reference materials on ETHASH FNV0</h4> <h4 id="where-fnv-applied-on-ethash">Where FNV Applied on ETHASH</h4> <ul> <li> <p>In <a rel="external" href="https://web.archive.org/web/20200505215203/https://github.com/ethereum/wiki/wiki/Ethash">ETHASH</a>, FNV Hash is used on</p> <ul> <li> <ol> <li>On data aggregation function, MIX parts.</li> </ol> </li> <li>Ethash Algorithm</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> Header + Nonce</span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span> Keccak </span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span> **[MIX 0]** --&gt; **[DAG Page]**</span></span> <span class="giallo-l"><span> | |</span></span> <span class="giallo-l"><span> Mixing &lt;--|</span></span> <span class="giallo-l"><span> ...</span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span> **[Mix 63]**</span></span> <span class="giallo-l"><span> |</span></span> <span class="giallo-l"><span> |-----&gt; Mix64 [Process] ---&gt; Mix Digest [32B]</span></span></code></pre> <ul> <li>FNV used in DAG Generation and Mixing for random access or DAG Page.</li> </ul> </li> </ul> <h4 id="2-current-applied-ethash-fnv-hash-implementation-is-deprecated-now">2. Current applied Ethash FNV hash implementation is deprecated now.</h4> <p><a rel="external" href="https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-0_hash_(deprecated)">FNV-0_hash (deprecated)</a></p> <p>It is a simple way of hashing algorithm</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> hash = 0</span></span> <span class="giallo-l"><span> for each byte_of_data to be hashed</span></span> <span class="giallo-l"><span> hash = hash × FNV_prime</span></span> <span class="giallo-l"><span> hash = hash XOR octet_of_data</span></span> <span class="giallo-l"><span> return hash</span></span></code></pre> <p>When analysed FNV-0 , there's very weak <a rel="external" href="https://simple.wikipedia.org/wiki/Avalanche_effect">avalanche effect</a>, when hash input changes on 1~2bits. refer <a rel="external" href="https://github.com/tao-foundation/FNV-Analysis#how-to-test-and-analysis-reference-test-code">FNV-Analysis reference section</a></p> <p>We need to research and apply newer FNV hash or short message hash algorithm.</p> <h4 id="3-fnv1a-hash-algorithm-description">3. FNV1A hash algorithm description</h4> <p>Previous proposed algorithm based on FNV1 <a href="https://wg-eips.ritovision.com/1355/">EIP-1355</a></p> <p>There's an implementation that looks like "Missing Offset Bias" at <strong>FNV1A</strong>.</p> <p>Quotation of <a rel="external" href="https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash">original algorithm FNV1A</a></p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>use hash offset</span></span> <span class="giallo-l"><span>FNV-1a hash</span></span> <span class="giallo-l"><span>The FNV-1a hash differs from the FNV-1 hash by only the order in which the multiply and XOR is performed:[8][10]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> hash = FNV_offset_basis</span></span> <span class="giallo-l"><span> for each byte_of_data to be hashed</span></span> <span class="giallo-l"><span> hash = hash XOR byte_of_data</span></span> <span class="giallo-l"><span> hash = hash × FNV_prime</span></span> <span class="giallo-l"><span> return hash</span></span></code></pre> <p>FNV_offset_basis and computation order change of xor and multiplication Makes one more xor and multiply computation, but more secure hash effects than FNV0. and make dispersion boundary condition (0, even number, ..) by using of Prime Number.</p> <h4 id="4-real-implementation-for-fnv1a">4. Real Implementation for FNV1A</h4> <p>Consider real computation resources, in TEthashV1 uses hash byte_of_data to 4bytes aligned data.</p> <p>In TETHashV1, Adapts fully follow the FNV1A implementation.</p> <ul> <li>TETHASHV1 FNV1A implementation</li> </ul> <p>Following are reference implementation of FNV1A adapted in TETHashV1.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> Reference Pseudo c/cpp implementation</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> FNV_PRIME</span><span class="z-keyword"> 0x</span><span class="z-constant">01000193</span><span class="z-keyword">U</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> FNV_OFFSET_BASIS</span><span class="z-keyword"> 0x</span><span class="z-constant">811c9dc5</span><span class="z-keyword">U</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable">x</span><span>,</span><span class="z-variable"> y</span><span>)</span><span> (</span><span>(</span><span>(</span><span>(</span><span>FNV_OFFSET_BASIS</span><span class="z-keyword">^</span><span>(</span><span>x</span><span>)</span><span>)</span><span class="z-keyword">*</span><span>FNV_PRIME</span><span>)</span><span class="z-keyword"> ^</span><span> (</span><span>y</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> fnv1a_reduce</span><span>(</span><span class="z-variable">a</span><span>,</span><span class="z-variable">b</span><span>,</span><span class="z-variable">c</span><span>,</span><span class="z-variable">d</span><span>)</span><span> (</span><span class="z-entity z-name">fnv1a</span><span>(</span><span class="z-entity z-name">fnv1a</span><span>(</span><span class="z-entity z-name">fnv1a</span><span>(</span><span>a</span><span>,</span><span> b</span><span>)</span><span>,</span><span> c</span><span>)</span><span>,</span><span> d</span><span>)</span><span>)</span></span></code></pre> <p>Another Byte aligned implementation of FNV1A , call to FNV1c</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> FNV_PRIME</span><span class="z-keyword"> 0x</span><span class="z-constant">01000193</span><span class="z-keyword">U</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> FNV_OFFSET_BASIS</span><span class="z-keyword"> 0x</span><span class="z-constant">811c9dc5</span><span class="z-keyword">U</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> fnv1i</span><span>(</span><span class="z-variable">x</span><span>)</span><span> (</span><span> (</span><span>(</span><span> (</span><span>(</span><span> (</span><span>(</span><span class="z-constant"> \</span></span> <span class="giallo-l"><span> (</span><span> (</span><span>(</span><span>FNV_OFFSET_BASIS</span><span>)</span><span class="z-keyword">^</span><span>(</span><span> (</span><span>(</span><span>x</span><span>)</span><span class="z-keyword">&gt;&gt;</span><span class="z-constant">24</span><span>)</span><span class="z-keyword">&amp;</span><span class="z-keyword">0x</span><span class="z-constant">000000ff</span><span> )</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span><span class="z-constant"> \</span></span> <span class="giallo-l"><span class="z-keyword"> ^</span><span> (</span><span>(</span><span>(</span><span>x</span><span>)</span><span class="z-keyword">&gt;&gt;</span><span class="z-constant">16</span><span> )</span><span class="z-keyword">&amp;</span><span class="z-keyword">0x</span><span class="z-constant">000000ff</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span><span class="z-constant"> \</span></span> <span class="giallo-l"><span class="z-keyword"> ^</span><span> (</span><span>(</span><span>(</span><span>x</span><span>)</span><span class="z-keyword">&gt;&gt;</span><span class="z-constant">8</span><span> )</span><span class="z-keyword">&amp;</span><span class="z-keyword">0x</span><span class="z-constant">000000ff</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span><span class="z-constant"> \</span></span> <span class="giallo-l"><span class="z-keyword"> ^</span><span> (</span><span>(</span><span>(</span><span>x</span><span>)</span><span> )</span><span class="z-keyword">&amp;</span><span class="z-keyword">0x</span><span class="z-constant">000000ff</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span><span class="z-constant"> \</span></span> <span class="giallo-l"><span> )</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">define</span><span class="z-entity z-name"> fnv1c</span><span>(</span><span class="z-variable">x</span><span>,</span><span class="z-variable"> y</span><span>)</span><span> (</span><span>(</span><span class="z-entity z-name">fnv1i</span><span>(</span><span>x</span><span>)</span><span class="z-keyword"> ^</span><span> (</span><span>y</span><span>)</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>)</span></span></code></pre><h4 id="5-fnv-analysis">5. <a rel="external" href="https://github.com/tao-foundation/FNV-Analysis">FNV-Analysis</a></h4> <p>FNV Mix Algorithm Analysis for TEthashV1</p> <h4 id="how-to-test-and-analysis-reference-test-code">How to test and analysis reference test code.</h4> <p>You can compile it with simple in terminal. No additional library needs,</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name">gcc</span><span class="z-constant"> -</span><span class="z-constant">o</span><span class="z-string"> fnvtest</span><span class="z-string"> fnvcltest.c</span></span></code></pre> <p>And You can execute it</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fnvtest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>F(00,00)::VEC(0, 0, ffffffff, 0):: FNV :00000000, DF=00000000(00) DS(00000000), FNV1 :00000000, DF=00000000(00) DS(00000000), FNV1a:117697cd, DF=117697cd(17) DS(117697cd), FNV1c:1210d00f, DF=127f8dbf(20) DS(11a1725f), F___RC=efe1b9c4, DF:efe1b9c4(19) , F1__RC=deb68dfe, DF:deb68dfe(22) , F1A_RC=99bad28b, DF:99bad28b(17) , F1C_RC=e29fa497, DF:e29fa497(18)</span></span> <span class="giallo-l"><span>F(00,01)::VEC(0, 1, ffffffff, 0):: FNV :00000001, DF=00000001(01) DS(00000001), FNV1 :01000193, DF=01000193(06) DS(01000193), FNV1a:1076963a, DF=010001f7(09) DS(01000193), FNV1c:1110ce7c, DF=03001e73(11) DS(01000193), F___RC=fefffe6d, DF:111e47a9(14) , F1__RC=d9fd8597, DF:074b0869(12) , F1A_RC=72c287e0, DF:eb78556b(19) , F1C_RC=6b6991ef, DF:89f63578(17)</span></span> <span class="giallo-l"><span>F(00,02)::VEC(0, 2, ffffffff, 0):: FNV :00000002, DF=00000003(02) DS(00000001), FNV1 :02000326, DF=030002b5(08) DS(01000193), FNV1a:0f7694a7, DF=1f00029d(11) DS(01000193), FNV1c:1410d335, DF=05001d49(09) DS(030004b9), F___RC=d8fd8404, DF:26027a69(13) , F1__RC=9b16d24c, DF:42eb57db(19) , F1A_RC=c17f0ecb, DF:b3bd892b(18) , F1C_RC=a5be8e78, DF:ced71f97(21)</span></span> <span class="giallo-l"><span>F(00,03)::VEC(0, 3, ffffffff, 0):: FNV :00000003, DF=00000001(01) DS(00000001), FNV1 :030004b9, DF=0100079f(10) DS(01000193), FNV1a:0e769314, DF=010007b3(09) DS(01000193), FNV1c:1310d1a2, DF=07000297(09) DS(01000193), F___RC=b2fb099b, DF:6a068d9f(16) , F1__RC=5c301f01, DF:c726cd4d(17) , F1A_RC=94cf402e, DF:55b04ee5(16) , F1C_RC=aea1a025, DF:0b1f2e5d(17)</span></span> <span class="giallo-l"><span>F(00,04)::VEC(0, 4, ffffffff, 0):: FNV :00000004, DF=00000007(03) DS(00000001), FNV1 :0400064c, DF=070002f5(10) DS(01000193), FNV1a:0d769181, DF=03000295(07) DS(01000193), FNV1c:0e10c9c3, DF=1d001861(09) DS(050007df), F___RC=8cf88f32, DF:3e0386a9(14) , F1__RC=1d496bb6, DF:417974b7(17) , F1A_RC=89401d59, DF:1d8f5d77(20) , F1C_RC=e4e96c7c, DF:4a48cc59(13)</span></span> <span class="giallo-l"><span>F(00,05)::VEC(0, 5, ffffffff, 0):: FNV :00000005, DF=00000001(01) DS(00000001), FNV1 :050007df, DF=01000193(06) DS(01000193), FNV1a:0c768fee, DF=01001e6f(11) DS(01000193), FNV1c:0d10c830, DF=030001f3(09) DS(01000193), F___RC=66f614c9, DF:ea0e9bfb(20) , F1__RC=de62b86b, DF:c32bd3dd(19) , F1A_RC=346e222c, DF:bd2e3f75(21) , F1C_RC=502e5f82, DF:b4c733fe(20)</span></span> <span class="giallo-l"><span>F(00,06)::VEC(0, 6, ffffffff, 0):: FNV :00000006, DF=00000003(02) DS(00000001), FNV1 :06000972, DF=03000ead(10) DS(01000193), FNV1a:0b768e5b, DF=070001b5(09) DS(01000193), FNV1c:1010cce9, DF=1d0004d9(10) DS(030004b9), F___RC=40f39a60, DF:26058ea9(13) , F1__RC=9f7c0520, DF:411ebd4b(16) , F1A_RC=b376a527, DF:8718870b(13) , F1C_RC=1241a9a4, DF:426ff626(17)</span></span> <span class="giallo-l"><span>F(00,07)::VEC(0, 7, ffffffff, 0):: FNV :00000007, DF=00000001(01) DS(00000001), FNV1 :07000b05, DF=01000277(08) DS(01000193), FNV1a:0a768cc8, DF=01000293(06) DS(01000193), FNV1c:0f10cb56, DF=1f0007bf(15) DS(01000193), F___RC=1af11ff7, DF:5a028597(13) , F1__RC=609551d5, DF:ffe954f5(22) , F1A_RC=14293bea, DF:a75f9ecd(21) , F1C_RC=49d34bba, DF:5b92e21e(16)</span></span> <span class="giallo-l"><span>F(00,08)::VEC(0, 8, ffffffff, 0):: FNV :00000008, DF=0000000f(04) DS(00000001), FNV1 :08000c98, DF=0f00079d(12) DS(01000193), FNV1a:09768b35, DF=030007fd(12) DS(01000193), FNV1c:1a10dca7, DF=150017f1(12) DS(0b001151), F___RC=f4eea58e, DF:ee1fba79(21) , F1__RC=21ae9e8a, DF:413bcf5f(19) , F1A_RC=eeebb7a5, DF:fac28c4f(17) , F1C_RC=7da04f47, DF:347304fd(16)</span></span> <span class="giallo-l"><span>F(00,09)::VEC(0, 9, ffffffff, 0):: FNV :00000009, DF=00000001(01) DS(00000001), FNV1 :09000e2b, DF=010002b3(07) DS(01000193), FNV1a:087689a2, DF=01000297(07) DS(01000193), FNV1c:1910db14, DF=030007b3(10) DS(01000193), F___RC=ceec2b25, DF:3a028eab(14) , F1__RC=e2c7eb3f, DF:c36975b5(18) , F1A_RC=54e1aef8, DF:ba0a195d(15) , F1C_RC=d425e1af, DF:a985aee8(16)</span></span> <span class="giallo-l"><span>F(00,0a)::VEC(0, a, ffffffff, 0):: FNV :0000000a, DF=00000003(02) DS(00000001), FNV1 :0a000fbe, DF=03000195(07) DS(01000193), FNV1a:0776880f, DF=0f0001ad(10) DS(01000193), FNV1c:1c10dfcd, DF=050004d9(08) DS(030004b9), F___RC=a8e9b0bc, DF:66059b99(15) , F1__RC=a3e137f4, DF:4126dccb(15) , F1A_RC=213fcd63, DF:75de639b(20) , F1C_RC=7e1d2751, DF:aa38c6fe(18)</span></span> <span class="giallo-l"><span>F(00,0b)::VEC(0, b, ffffffff, 0):: FNV :0000000b, DF=00000001(01) DS(00000001), FNV1 :0b001151, DF=01001eef(12) DS(01000193), FNV1a:0676867c, DF=01000e73(09) DS(01000193), FNV1c:1b10de3a, DF=070001f7(11) DS(01000193), F___RC=82e73653, DF:2a0e86ef(16) , F1__RC=64fa84a9, DF:c71bb35d(19) , F1A_RC=5598ce46, DF:74a70325(14) , F1C_RC=6400c630, DF:1a1de161(14)</span></span> <span class="giallo-l"><span>F(00,0c)::VEC(0, c, ffffffff, 0):: FNV :0000000c, DF=00000007(03) DS(00000001), FNV1 :0c0012e4, DF=070003b5(10) DS(01000193), FNV1a:057684e9, DF=03000295(07) DS(01000193), FNV1c:1610d65b, DF=0d000861(07) DS(050007df), F___RC=5ce4bbea, DF:de038db9(17) , F1__RC=2613d15e, DF:42e955f7(18) , F1A_RC=6a220ff1, DF:3fbac1b7(20) , F1C_RC=6e781da4, DF:0a78db94(15)</span></span> <span class="giallo-l"><span>F(00,0d)::VEC(0, d, ffffffff, 0):: FNV :0000000d, DF=00000001(01) DS(00000001), FNV1 :0d001477, DF=01000693(07) DS(01000193), FNV1a:04768356, DF=010007bf(11) DS(01000193), FNV1c:1510d4c8, DF=03000293(07) DS(01000193), F___RC=36e24181, DF:6a06fa6b(17) , F1__RC=e72d1e13, DF:c13ecf4d(18) , F1A_RC=168d4944, DF:7caf46b5(19) , F1C_RC=65bbcfa1, DF:0bc3d205(13)</span></span> <span class="giallo-l"><span>F(00,0e)::VEC(0, e, ffffffff, 0):: FNV :0000000e, DF=00000003(02) DS(00000001), FNV1 :0e00160a, DF=0300027d(09) DS(01000193), FNV1a:037681c3, DF=07000295(08) DS(01000193), FNV1c:1810d981, DF=0d000d49(09) DS(030004b9), F___RC=10dfc718, DF:263d8699(15) , F1__RC=a8466ac8, DF:4f6b74db(20) , F1A_RC=93e667bf, DF:856b2efb(19) , F1C_RC=76f80ee3, DF:1343c142(11)</span></span> <span class="giallo-l"><span>F(00,0f)::VEC(0, f, ffffffff, 0):: FNV :0000000f, DF=00000001(01) DS(00000001), FNV1 :0f00179d, DF=01000197(07) DS(01000193), FNV1a:02768030, DF=010001f3(08) DS(01000193), FNV1c:1710d7ee, DF=0f000e6f(13) DS(01000193), F___RC=eadd4caf, DF:fa028bb7(17) , F1__RC=695fb77d, DF:c119ddb5(17) , F1A_RC=0f485682, DF:9cae313d(17) , F1C_RC=3667e8dc, DF:409fe63f(18)</span></span> <span class="giallo-l"><span>F(00,10)::VEC(0, 10, ffffffff, 0):: FNV :00000010, DF=0000001f(05) DS(00000001), FNV1 :10001930, DF=1f000ead(13) DS(01000193), FNV1a:01767e9d, DF=0300fead(14) DS(01000193), FNV1c:0210b6df, DF=15006131(09) DS(1500210f), F___RC=c4dad246, DF:2e079ee9(17) , F1__RC=2a790432, DF:4326b34f(16) , F1A_RC=d10adebd, DF:de42883f(16) , F1C_RC=1ce48e12, DF:2a8366ce(15)</span></span></code></pre> <p><code>F(00,01)</code> : is input x,y</p> <p><code>VEC(0, 1, ffffffff, 0)</code> : is <code>fnv_reduce</code> input vector (a,b,c,d)</p> <p><code>FNV :00000001, DF=00000001(01) DS(00000001)</code> :</p> <ul> <li><code>FNV(00,01)</code> result is 00000001 ,</li> <li><code>DF</code> : is changed bitcounts, compared with previous outputs, in this case prev[00,00] current[00,01] input is 1bit changed, and output result 1bit changed.</li> <li><code>DS</code> : is distances of previous result and current result , ABS(prev_fnvresult,current_fnvresult).</li> </ul> <p>** Basically, <code>DF</code> is higher is best on hash algorithm.</p> <p><code>F___RC=fefffe6d, DF:111e47a9(14)</code> : <code>fnv_reduce = fnv(fnv(fnv(a,b),c),d) </code> result is fefffe6d , and Different Bits counts are <code>14</code> bits.</p> <h2 id="rationale">Rationale</h2> <p>In case of ethash algorithm, it can't prevent ASIC forever.</p> <p>And, current ethash algorithm's FNV function is deprecated.</p> <p>So, It needs to be upgraded and it will make current ethash based ASICs obsolete.</p> <p>And current TETHASHV1 FNV1A implementation is based on most of ethash , which is verified for a long time.</p> <p>Another propose of big differencing the Ethash algorithm need to crypto analysis for a long times and need to GPU code optimization times.</p> <p><strong>Verification and Optimization timeline Examples</strong></p> <p>original ethminer (2015) -&gt; claymore optimized miner (2016) [1year]</p> <p>genoil ethminer (2015) -&gt; ethereum-mining/ethminer (2017) [2year]</p> <h2 id="test-results">Test Results::</h2> <p>Tethash miner has 2~3% of hashrate degrade on GPU, due to more core computation time.</p> <h2 id="copyright">Copyright</h2> <p>This work is licensed under a <a rel="external" href="https://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.</p> 2018-10-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Maurelianhttps://github.com/Maurelian https://wg-eips.ritovision.com/1482/ <h2 id="simple-summary">Simple Summary</h2> <p>Include an explicit definition of the acceptable timestamp drift in the protocol specification.</p> <h2 id="abstract">Abstract</h2> <p>On the basis that both Geth and Parity implement the same timestamp validation requirements, this should be written into the reference specification.</p> <h2 id="motivation">Motivation</h2> <p>There is a lack of clarity about how accurate timestamps in the block header must be. The yellow paper describes the timestamp as</p> <blockquote> <p>A scalar value equal to the reasonable output of Unix’s time() at this block’s inception</p> </blockquote> <p>This causes <a rel="external" href="https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network/5926#5926">confusion</a> about the safe use of the <code>TIMESTAMP</code> opcode (solidity's <code>block.timestamp</code> or <code>now</code>) in smart contract development.</p> <p>Differing interpretations of 'reasonable' may create a risk of consenus failures.</p> <h2 id="specification">Specification</h2> <p>The yellow paper should define a timestamp as:</p> <blockquote> <p>A scalar value equal to the output of Unix’s time() at this block’s inception. For the purpose of block validation, it must be greater than the previous block's timestamp, and no more than 15 seconds greater than system time.</p> </blockquote> <h2 id="rationale">Rationale</h2> <p>Both <a rel="external" href="https://github.com/ethereum/go-ethereum/blob/4e474c74dc2ac1d26b339c32064d0bac98775e77/consensus/ethash/consensus.go#L45">Geth</a> and <a rel="external" href="https://github.com/paritytech/parity-ethereum/blob/73db5dda8c0109bb6bc1392624875078f973be14/ethcore/src/verification/verification.rs#L296-L307">Parity</a> reject blocks with timestamp more than 15 seconds in the future. This establishes a defacto standard, which should be made explicit in the reference specification.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>It may be necessary to relax this requirement for blocks which were mined early in the main chain's history, if they would be considered invalid.</p> <h2 id="test-cases">Test Cases</h2> <p>These would be important to have.</p> <h2 id="implementation">Implementation</h2> <p>_The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. _</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-09-16T00:00:00+00:00 2026-02-11T14:49:28+00:00 William Entrikenhttps://github.com/fulldecent https://wg-eips.ritovision.com/1418/

At each block, deduct value from every account based on the quantity of storage used by that account.

<h2 id="abstract">Abstract</h2> <p>At each block, deduct an amount of value ("rent") from every account based on the quantity of storage used by that account.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum is a public utility and we are underpricing the long-term costs of storage. Storage cost can be approximately modeled as bytes × time.</p> <h2 id="specification">Specification</h2> <p><strong>Updated transaction type</strong></p> <p>A new transaction type is introduced. Whereas <a href="https://wg-eips.ritovision.com/1559/">EIP-1559</a> introduced warm access for contract state, this new type introduces warm access for contract code.</p> <p><strong>New state variables (per account)</strong></p> <ul> <li><strong>σ[a]_rent</strong> -- an amount of value, in Wei, this is a signed value</li> <li><strong>σ[a]_storageWords</strong> -- number of words in storage</li> </ul> <p><strong>New constants</strong></p> <ul> <li><strong><code>RENT_WORD_COST</code></strong> -- The rent cost, in Wei, paid for each word-block</li> <li><strong><code>RENT_ACCOUNT_COST</code></strong> -- The rent cost, in Wei, paid for each account-block</li> <li><strong><code>FORK_BLOCK</code></strong> – When implementation starts</li> </ul> <p><strong>New opcodes</strong></p> <ul> <li><strong><code>RENTBALANCE(address)</code></strong> -- G_BALANCE -- Similar to <code>BALANCE</code> <ul> <li>This returns the logical <code>σ[a]_rent</code> value which is defined to reduce each block. It is possible for the implementation to calculate this value using the recommended implementation variables, rather than storing and updating <code>σ[a]_rent</code> every block for every account.</li> </ul> </li> <li><strong><code>SENDRENT(address, amount)</code></strong> -- G_BASE -- Convert value to rent and send to account <ol> <li><code>σ[account]_rent</code> += amount</li> <li><code>σ[msg.sender]_balance</code> -= amount</li> </ol> </li> </ul> <p><strong>Updated opcodes</strong></p> <p>A new subroutine, paying for rent, is established as such:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PAYRENT(account)</span></span> <span class="giallo-l"><span> blocks_to_pay = NUMBER - σ[account]_rentLastPaid</span></span> <span class="giallo-l"><span> cost_per_block = RENT_ACCOUNT_COST + RENT_WORD_COST * (⌈∥σ[account]_code∥ / 32⌉ + * σ[a]_storageWords)</span></span> <span class="giallo-l"><span> rent_to_pay = blocks_to_pay * cost_per_block</span></span> <span class="giallo-l"><span> σ[account]_rent -= rent_to_pay</span></span> <span class="giallo-l"><span> if σ[account]_rent &lt; 0</span></span> <span class="giallo-l"><span> σ[account]_value += σ[account]_rent</span></span> <span class="giallo-l"><span> σ[account]_rent = 0</span></span> <span class="giallo-l"><span> end</span></span> <span class="giallo-l"><span> if σ[account]_value &lt; 0</span></span> <span class="giallo-l"><span> σ[account]_rent = σ[account]_value</span></span> <span class="giallo-l"><span> σ[account]_value = 0</span></span> <span class="giallo-l"><span> end</span></span> <span class="giallo-l"><span> σ[account]_rentLastPaid = NUMBER</span></span> <span class="giallo-l"><span> σ[account]_rentEvictBlock = NUMBER + ⌊σ[account]_rent / cost_per_block⌋</span></span> <span class="giallo-l"><span>END PAYRENT</span></span></code></pre> <ul> <li><strong><code>SSTORE(account, key, value)</code></strong> <ul> <li>Perform PAYRENT(account)</li> <li>If <code>account</code> is evicted (i.e. <code>NUMBER</code> &gt; <code>σ[account]_rentEvictBlock</code>) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the old storage root and calculate the new root.</li> <li>Do normal SSTORE operation</li> <li>If the old value was zero for this [account, key] and the new value is non-zero, then <code>σ[account]_storageWords++</code></li> <li>If the old value was non-zero for this [account, key] and the new value is zero, then <code>σ[account]_storageWords--</code>, and if the result is negative then set to zero</li> </ul> </li> <li><strong><code>SLOAD(account, key)</code></strong> <ul> <li>If <code>account</code> is evicted (i.e. <code>NUMBER</code> &gt; <code>σ[account]_rentEvictBlock</code>) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the existing storage root and the existing storage value.</li> <li>Do normal SLOAD operation.</li> </ul> </li> <li><strong><code>CALL (and derivatives)</code></strong> <ul> <li>If the target block is evicted (i.e. <code>NUMBER</code> &gt; <code>σ[account]_rentEvictBlock</code>) then transaction fails unless using the new transaction type and sufficient proof is included to validate the existing code.</li> <li>Do normal CALL operation</li> </ul> </li> <li><strong><code>CREATE</code></strong> <ul> <li>Set σ[account]_rentLastPaid = NUMBER</li> <li>Do normal CREATE operation</li> <li><code>σ[account]_storageWord = 0</code></li> <li>Note: it is possible there is a pre-existing rent balance here</li> </ul> </li> </ul> <p><strong>New built-in contract</strong></p> <ul> <li><code>PAYRENT(address, amount)</code> -- Calls <code>PAYRENT</code> opcode <ul> <li>This is a convenience for humans to send Ether from their accounts and turn it into rent. Note that simple accounts (CODESIZE == 0) cannot call arbitrary opcodes, they can only call CREATE or CALL.</li> <li>The gas cost of PAYRENT will be 10,000 or lower if possible.</li> </ul> </li> </ul> <p><strong>Calculating <code>σ[account]_storageWord</code> for existing accounts</strong></p> <p>DRAFT...</p> <p>It is not an acceptable upgrade if on the fork block it is necessary for only archive nodes to participate which know the full storage amount for each account.</p> <p>An acceptable upgrade will be if the required <code>σ[account]_storageWord</code> can be calculated (or estimated) incrementally based on new transaction activity.</p> <p>DRAFT: I think it is possible to make such an acceptable upgrade using an unbiased estimator</p> <ul> <li>add one bit of storage per <code>SSTORE</code> for legacy accounts on the first access of a given key</li> <li>add log(n) bits for each trie level</li> <li>assume that storage keys are a random variable</li> </ul> <p>To think more about...</p> <p><strong>No changes to current opcode gas costs.</strong></p> <h2 id="rationale">Rationale</h2> <p><strong>No call</strong></p> <p>A contract will not know or react to the receipt of rent. This is okay. Workaround: if a contract really needed to know who provided rent payments then it could create a function in its ABI to attribute these payments. It is already possible to send payments to a contract without attribution by using <code>SELFDESTRUCT</code>. Other blockchains like TRON allow to transfer value to a contract without performing a call.</p> <p><strong>Eviction responsibility / lazy evaluation</strong></p> <p>The specification gives responsibility for eviction to the consensus clients. This is the most predictable behavior because it happens exactly when it should. Also there need not be any incentive mechanism (refund gas, bounty) for outside participants (off-chain) to monitor accounts and request removal.</p> <p>It is possible that an arbitrary number of accounts will be evicted in one block. That doesn't matter. Client implementations do not need to track which accounts are evicted, consensus is achieved just by agreeing on the conditions under which an account would be evicted.</p> <p><strong>No converting rent to value</strong></p> <p>Ether converted to rent cannot be converted back. Anybody that works in accounting and knows about gifts cards should tell you this is a good idea. It makes reasoning about the system much easier.</p> <p><strong>Accounts pay rent</strong></p> <p>Yes, they pay rent. It costs resources to account for their balances so we charge them rent.</p> <p><strong>Why do you need a separate rent account?</strong></p> <p>Because anybody/everybody can contribute to the rent account. If you depend on a contract, you should contribute to its rent.</p> <p>But the contract can spend all of its value.</p> <p>By maintaining a separate rent and value balance, this allows people to contribute to the rent while being confident that this is allowing the contract to stay around.</p> <p>NOTE: cloning. With this EIP, it may become feasible to allow storage cloning. Yes really. Because the new clone will be paying rent. See other EIP, I think made by Augur team.</p> <h3 id="economics-constants">Economics &amp; constants</h3> <p>An <code>SSTORE</code> executed in 2015 cost 20,000 gas and has survived about 6 million blocks. The gas price has been around 1 ~ 50 Gwei. So basically 4,000 Wei per block per word so far. Maybe storing an account is 10 times more intensive than storing a word. But actually <code>G_transaction</code> is 21,000 and <code>G_sstore</code> is 20,000 so these are similar and they can both create new accounts / words.</p> <p>How about:</p> <ul> <li><code>RENT_WORD_COST</code> -- 4,000 Wei</li> <li><code>RENT_ACCOUNT_COST</code> -- 4,000 Wei</li> <li><code>FORK_BLOCK</code> – when implementation starts</li> </ul> <p>The rent is priced in cold, hard Ether. It is not negotiated by clients, it is not dynamic.</p> <p>A future EIP may change this pricing to be dynamic. For example to notarize a block, notaries may be required to prove they have the current storage dataset (excluding evictions). Additionally, they may also prove they have the dataset plus evictions to earn an additional fee. The relative storage of the evicted accounts, and the other accounts versus the value of the additional fee may be used as a feedback mechanism to set a market price for storage.</p> <p>FYI, there are about 15B words in the Ethereum Mainnet dataset and about 100M total Ether mined. This means if all Ether was spent on storage at current proposed prices it would be 400 terabyte-years of storage. I'm not sure if it is helpful to look at it that way.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>EIP-1559 already introduces a mechanism for nodes to participate without recording the full network state and for clients to warm cache with storage data in their type 2 transactions.</p> <p>Users will need to be educated.</p> <p>Many smart contracts allow anybody to use an arbitrary amount of storage in them. This can limit the usefulness of deploying this proposal on an existing chain.</p> <p><strong>Recommended implementation variables (per account)</strong></p> <ul> <li> <p><strong>σ[a]_rentLastPaid</strong> -- a block number that is set when:</p> <ul> <li>Value is transferred into an account (<code>CREATE</code>, <code>CALL</code>, <code>SELFDESTRUCT</code>)</li> <li>Code is set for an account (<code>CREATE</code>)</li> <li>An account's storage is updated (<code>SSTORE</code>)</li> <li>This begins with a logical value of <code>FORK_BLOCK</code> for all accounts</li> </ul> </li> <li> <p><strong>σ[a]_rentEvictBlock</strong> -- the block number when this account will be evicted</p> </li> </ul> <p><strong>Storage note</strong></p> <p>For every account that is evicted, clients may choose to delete that storage from disk. A future EIP may make an incentive to keep this extra data for a fee. A future EIP may create a mechanism for clients to exchange information about these storage states.</p> <h2 id="security-considerations">Security Considerations</h2> <p>Many smart contracts allow anybody to use an arbitrary amount of storage in them.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via CC0.</p> <!-- ## TODO To discuss: - Can/should an evicted account be allowed to be un-evicted when paying past due rent? --> 2018-08-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Jacques Wagenerhttps://github.com/jacqueswww https://wg-eips.ritovision.com/1380/ <h2 id="abstract">Abstract</h2> <p>Reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract.</p> <h2 id="motivation">Motivation</h2> <p>The current gas cost of 700 for all call types (<code>CALL</code>, <code>DELEGATECALL</code>, <code>CALLCODE</code> and <code>STATICCALL</code>) does not take into account that a call to a contract itself does not need to perform additional I/O operations, because the current contract code has already been loaded into memory.</p> <p>Reducing the call-to-self gas cost would greatly benefit smart contract languages, such as Solidity and Vyper, who would then be able to utilise <code>CALL</code> instead of <code>JUMP</code> opcodes for internal function calls. While languages can already utilise <code>CALL</code> for internal function calls, they are discouraged to do so due to the gas costs associated with it.</p> <p>Using <code>JUMP</code> comes at a considerable cost in complexity to the implementation of a smart contract language and/or compiler. The context (including stack and memory) must be swapped in and out of the calling functions context. A desired feature is having <em>pure</em> functions, which do not modify the state of memory, and realising them through <code>JUMP</code> requires a bigger effort from the compiler as opposed to being able to use <code>CALL</code>s.</p> <p>Using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both contract writers and contract consumers against potentially undetected edge cases were memory could poison the context of the internal function.</p> <p>Because of the <code>JUMP</code> usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerably faster, if nested function calls with many in and/or outputs are required.</p> <p>Reducing the gas cost, and thereby incentivising of using call-to-self instead of <code>JUMP</code>s for the internal function implementation will also benefit static analyzers and tracers.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, then decrease the cost of <code>CALL</code>, <code>DELEGATECALL</code>, <code>CALLCODE</code> and <code>STATICCALL</code> from 700 to 40, if and only if, the destination address of the call equals to the address of the caller.</p> <h2 id="rationale">Rationale</h2> <p>EIP150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the I/O charge more closely. By assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new VM instance of an already loaded contract code.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This should pose no risk to backwards compatibility. Currently existing contracts should not notice the difference, just see cheaper execution. With EIP150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change. The impact of this EIP is even less that of EIP150 because the costs are changing downwards and not upwards.</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-08-26T00:00:00+00:00 2026-02-11T14:49:27+00:00 Paweł Bylicahttps://github.com/chfast Jean M. Cyrhttps://github.com/jean-m-cyr https://wg-eips.ritovision.com/1355/ <h2 id="motivation">Motivation</h2> <p>Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining.</p> <h2 id="specification">Specification</h2> <ol> <li> <p>Define hash function <code>fnv1a()</code> as</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-parameter z-function">v1</span><span>,</span><span class="z-variable z-parameter z-function"> v2</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>(</span><span>v1</span><span class="z-keyword"> ^</span><span> v2</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> FNV1A_PRIME</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">32</span></span></code></pre> <p>where <code>FNV1A_PRIME</code> is 16777499 or 16777639.</p> </li> <li> <p>Change the hash function that determines the DAG item index in Ethash algorithm from <code>fnv()</code> to new <code>fnv1a()</code>. In <a rel="external" href="https://github.com/ethereum/eth-wiki/blob/master/concepts/ethash/ethash.md#main-loop">Main Loop</a> change</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>p</span><span class="z-keyword"> =</span><span> fnv</span><span>(</span><span>i</span><span class="z-keyword"> ^</span><span> s</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> mix</span><span>[</span><span>i</span><span class="z-keyword"> %</span><span> w</span><span>]</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span>n</span><span class="z-keyword"> //</span><span> mixhashes</span><span>)</span><span class="z-keyword"> *</span><span> mixhashes</span></span></code></pre> <p>to</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>p</span><span class="z-keyword"> =</span><span> fnv1a</span><span>(</span><span>i</span><span class="z-keyword"> ^</span><span> s</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> mix</span><span>[</span><span>i</span><span class="z-keyword"> %</span><span> w</span><span>]</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span>n</span><span class="z-keyword"> //</span><span> mixhashes</span><span>)</span><span class="z-keyword"> *</span><span> mixhashes</span></span></code></pre></li> </ol> <h2 id="rationale">Rationale</h2> <p>The usual argument for decentralization and network security.</p> <p>Unless programmable, an ASIC is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of ASICS. A second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. Minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing GPUs. It's expected that this specific change would have no effect on existing GPU performance.</p> <p>Changing fnv to fnv1a has no cryptographic implications. It is merely an efficient hash function with good dispersion characteristics used to scramble DAG indexing. We remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis.</p> <h3 id="fnv-primes">FNV Primes</h3> <p>The 16777639 satisfies all requirements from <a rel="external" href="https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV_prime">Wikipedia</a>.</p> <p>The 16777499 is preferred by FNV authors but not used in the reference FNV implementation because of historical reasons. See <a rel="external" href="http://www.isthe.com/chongo/tech/comp/fnv/index.html#fnv-prime">A few remarks on FNV primes</a>.</p> <h2 id="copyright">Copyright</h2> <p>This work is licensed under a <a rel="external" href="https://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.</p> 2018-08-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Richard Meissnerhttps://github.com/rmeissner Bryant Eisenbachhttps://github.com/fubuloubu https://wg-eips.ritovision.com/1344/ <h2 id="abstract">Abstract</h2> <p>This EIP adds an opcode that returns the current chain's EIP-155 unique identifier.</p> <h2 id="motivation">Motivation</h2> <p><a href="https://wg-eips.ritovision.com/155/">EIP-155</a> proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using <a href="https://wg-eips.ritovision.com/712/">EIP-712</a>.</p> <h2 id="specification">Specification</h2> <p>Adds a new opcode <code>CHAINID</code> at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. Chain ID is a 256-bit value. The operation costs <code>G_base</code> to execute.</p> <p>The value of the current chain ID is obtained from the chain ID configuration, which should match the EIP-155 unique identifier a client will accept from incoming transactions. Please note that per EIP-155, it is not <em>required</em> that a transaction have an EIP-155 unique identifier, but in that scenario this opcode will still return the configured chain ID and not a default.</p> <h2 id="rationale">Rationale</h2> <p>The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages. By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.</p> <p>Currently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a "contentious split" over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and "meta-transaction" use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID.</p> <p>In order to mitigate this situation, users of the proposed <code>CHAINID</code> opcode <strong>must</strong> ensure that their application can handle a potential update to the value of chain ID during their usage of their application in case this does occur, if required for the continued use of the application. A Trustless Oracle that logs the timestamp when a change is made to chain ID can be implemented either as an application-level feature inside the application contract system, or referenced as a globally standard contract. Failure to provide a mitigation for this scenario could lead to a sudden loss of legitimacy of previously signed off-chain messages, which could be an issue during settlement periods and other longer-term verification events for these types of messages. Not all applications of this opcode may need mitigations to handle this scenario, but developers should provide reasoning on a case-by-case basis.</p> <p>One example of a scenario where it would not make sense to leverage a global oracle is with the Plasma L2 paradigm. In the Plasma paradigm, an operator or group of operators submit blocks from the L2 network to the base chain (in this case Ethereum) summarizing transactions that have occurred on that chain. The submission of these blocks may not perfectly align with major events on the mainchain, such as a split causing an update of chain ID, which may cause a significant insecurity in the protocol if chain ID is utilized in signing messages. If the operators are not allowed to control the update of chain ID they will not be able to perfectly synchronize the update with their block submissions, and certain past transactions may be rejected because they do not align with the update. This is one example of the unintended consequences of trying to specify too much of the behavior of chain ID during a contentious split, and why having a simple opcode for access is most optimal, versus a more complicated precompile or contract.</p> <p>This proposed opcode would be the simplest possible way to implement this functionality, and allows developers the flexibility to implement their own global or local handling of chain ID changes, if required.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing.</p> <h2 id="references">References</h2> <p>This was previously suggested as part of <a rel="external" href="https://github.com/ethereum/EIPs/issues/901">EIP-901</a>.</p> <h2 id="test-cases">Test Cases</h2> <p>Test Cases added to <a rel="external" href="https://github.com/ethereum/tests/pull/627">ethereum/tests</a></p> <h2 id="implementation">Implementation</h2> <p>A reference implementation for the Trinity Python client is <a rel="external" href="https://github.com/ethereum/py-evm/pull/1803">here</a>.</p> <p>An example implementation of a trustless chain ID oracle was implemented <a rel="external" href="https://github.com/fubuloubu/chain-id-oracle/blob/master/ChainIdOracle.vy">here</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-08-05T00:00:00+00:00 2026-02-11T14:49:27+00:00 Brian Venturohttps://github.com/atlanticcrypto https://wg-eips.ritovision.com/1295/ <h2 id="simple-summary">Simple Summary</h2> <p>Network security and overall ecosystem maturity warrants the continued incentivization of Proof of Work participation but may allow for a reduction in ancillary ETH issuance and the delay of the Difficulty Bomb. This EIP proposes a reduction of Uncle and removal of Nephew rewards while delaying the Difficulty Bomb with the Constantinople hard fork.</p> <h2 id="abstract">Abstract</h2> <p>Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork.</p> <p>Furthermore, Uncle rewards will be adjusted and Nephew rewards will be removed to eliminate excess ancillary ETH issuance. The current ETH block reward of 3 ETH will remain constant.</p> <h2 id="motivation">Motivation</h2> <p>Network scalability and security are at the forefront of risks to the Ethereum protocol. With great strides being made towards on and off chain scalability, the existence of an artificial throughput limiting device in the protocol is not warranted. Removing the risk of reducing throughput through the initialization of the Difficulty Bomb is "low-hanging-fruit" to ensure continued operation at a minimum of current throughput through the next major hard fork (scheduled for late 2019).</p> <p>The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the security of the growing ecosystem are paramount.</p> <p>At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fake_block_number = max(0, block.number - 6_000_000) if block.number &gt;= CNSTNTNPL_FORK_BLKNUM else block.number</span></span></code></pre><h4 id="adjust-uncle-and-nephew-rewards">Adjust Uncle and Nephew rewards</h4> <p>If an uncle is included in a block for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (3 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing pre-Constantinople formula for uncle rewards, adjusted to reward 2 levels of Uncles at a reduced rate.</p> <p>The nephew reward for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = 0</span></span></code></pre> <p>This is a removal of all rewards for Nephew blocks.</p> <h2 id="rationale">Rationale</h2> <p>The security layer of the Ethereum network is and should remain robust. Incentives for continued operation of the growing ecosystem’s security are paramount.</p> <p>At the same time, the ancillary issuance benefits of the Ethereum protocol can be adjusted to reduce the overall issuance profile. Aggressively adjusting Uncle and removing Nephew rewards will reduce the inflationary aspect of ETH issuance, while keeping the current block reward constant at 3 ETH will ensure top line incentives stay in place.</p> <p>The Difficulty Bomb was instituted as a type of planned obsolescence to force the implementation of network upgrades with regular frequency. With the focus on scalability for the protocol, delaying a mechanism whereby the throughput of the network can be limited artificially, due to any circumstance, is a logical step to ensure continued minimum network operation at the current throughput level. We believe the existence of the Difficulty Bomb has allowed for the inclusion of protocol upgrades in forced hard-forks, and will continue to do so.</p> <p>Through August 4th, the 2018 year to date reward issued to Uncle blocks totaled over 635,000 ETH. The average reward per Uncle totals 2.27 ETH. The year to date average Uncle rate is 22.49%. Using the year to date metrics, the ongoing average ETH paid as an Uncle reward per block is 0.51 ETH plus the Uncle inclusion reward of 0.021 ETH (0.09375 ETH * .2249), total Uncle related reward per block being over 0.53 ETH. With total year to date block rewards totaling approximately 3,730,000 ETH, the network has paid an additional 17pct in Uncle rewards. This is issuance that can be reduced while still maintaining the overall integrity and incentivization of network security.</p> <p>Reducing the issuance of ETH in rewarding Uncle blocks (forked blocks caused by latency in propagation, a multi-faceted problem) should directly incentivize the investment in technologies and efficiencies to reduce block propagation latency which may lead to a reduction in Network wide Uncle rates, reducing ancillary issuance further.</p> <p>Reducing the Uncle rewards from the current specification to the proposed will yield two levels of ancillary ETH issuance for Uncles:</p> <p>Level 1 Uncle -&gt; 0.75 ETH</p> <p>Level 2 Uncle -&gt; 0.375 ETH</p> <p>These levels are sufficient to continue incentivizing decentralized participation, while also providing an immediate economic incentive for the upgrade of the Ethereum node network and its tangential infrastructure.</p> <p>We believe that the ETH network has been subsidizing transaction inclusion through the robust Uncle Reward structure since inception. We also believe that a removal of the set subsidy will create a dynamic response mechanism whereby Miners and transaction senders will minimize total costs of transaction inclusion. This dynamic response structure may limit unnecessary layer 1 transaction throughput while providing incentives for layer 2 scaling solutions.</p> <p>The Nephew reward structure should be entirely eliminated.</p> <p>Due to current market conditions, and the likelihood of a further USD denominated price decline (50%), we believe that any top line reduction to security incentives will put the Ethereum network at undue risk. Unlike the time of the Byzantium hard fork, current USD denominated economics for securing the Ethereum network threaten the participation of the most decentralized Miner community (at home miners), which we believe make up the largest proportion of the overall network hashrate. We believe eliminating this portion of the community will increase centralization and the probability of an organized network attack.</p> <p>For a technology so new and with so much potential, we find it extremely irresponsible to increase the likelihood of a network attack by reducing ETH Issuance past this proposal’s level.</p> <p>With a reduction to the Uncle and removal of the Nephew reward, ancillary ETH issuance should drop (under normal market conditions, i.e. 22.49% uncle rate) by over 75pct and total ETH issuance from the successful sealing and mining of valid blocks should drop over 10pct.</p> <p>Paired with the diffusal of the Difficulty Bomb, this proposal strikes a balance between ensuring status quo network throughput, reducing overall ETH issuance, and continuing top line incentives for investment in infrastructure and efficiencies to continue operating the Ethereum network’s security layer.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, Constantinople.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="implementation">Implementation</h2> <p>Forthcoming.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-08-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/1283/ <h2 id="abstract">Abstract</h2> <p>This EIP proposes net gas metering changes for <code>SSTORE</code> opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn't match how most implementations work.</p> <p>This acts as an alternative for EIP-1087, where it tries to be friendlier to implementations that use different optimization strategies for storage change caches.</p> <h2 id="motivation">Motivation</h2> <p>This EIP proposes a way for gas metering on SSTORE (as an alternative for EIP-1087 and EIP-1153), using information that is more universally available to most implementations, and requires as little change in implementation structures as possible.</p> <ul> <li><em>Storage slot's original value</em>.</li> <li><em>Storage slot's current value</em>.</li> <li>Refund counter.</li> </ul> <p>Usages that benefits from this EIP's gas reduction scheme includes:</p> <ul> <li>Subsequent storage write operations within the same call frame. This includes reentry locks, same-contract multi-send, etc.</li> <li>Exchange storage information between sub call frame and parent call frame, where this information does not need to be persistent outside of a transaction. This includes sub-frame error codes and message passing, etc.</li> </ul> <h2 id="specification">Specification</h2> <p>Definitions of terms are as below:</p> <ul> <li><em>Storage slot's original value</em>: This is the value of the storage if a reversion happens on the <em>current transaction</em>.</li> <li><em>Storage slot's current value</em>: This is the value of the storage before SSTORE operation happens.</li> <li><em>Storage slot's new value</em>: This is the value of the storage after SSTORE operation happens.</li> </ul> <p>Replace <code>SSTORE</code> opcode gas cost calculation (including refunds) with the following logic:</p> <ul> <li>If <em>current value</em> equals <em>new value</em> (this is a no-op), 200 gas is deducted.</li> <li>If <em>current value</em> does not equal <em>new value</em> <ul> <li>If <em>original value</em> equals <em>current value</em> (this storage slot has not been changed by the current execution context) <ul> <li>If <em>original value</em> is 0, 20000 gas is deducted.</li> <li>Otherwise, 5000 gas is deducted. If <em>new value</em> is 0, add 15000 gas to refund counter.</li> </ul> </li> <li>If <em>original value</em> does not equal <em>current value</em> (this storage slot is dirty), 200 gas is deducted. Apply both of the following clauses. <ul> <li>If <em>original value</em> is not 0 <ul> <li>If <em>current value</em> is 0 (also means that <em>new value</em> is not 0), remove 15000 gas from refund counter. We can prove that refund counter will never go below 0.</li> <li>If <em>new value</em> is 0 (also means that <em>current value</em> is not 0), add 15000 gas to refund counter.</li> </ul> </li> <li>If <em>original value</em> equals <em>new value</em> (this storage slot is reset) <ul> <li>If <em>original value</em> is 0, add 19800 gas to refund counter.</li> <li>Otherwise, add 4800 gas to refund counter.</li> </ul> </li> </ul> </li> </ul> </li> </ul> <p>Refund counter works as before -- it is limited to half of the gas consumed. On a transaction level, refund counter will never go below zero. However, there are some important notes depending on the implementation details:</p> <ul> <li>If an implementation uses "transaction level" refund counter (refund is checkpointed at each call frame), then the refund counter continues to be unsigned.</li> <li>If an implementation uses "execution-frame level" refund counter (a new refund counter is created at each call frame, and then merged back to parent when the call frame finishes), then the refund counter needs to be changed to signed -- at internal calls, a child refund can go below zero.</li> </ul> <h2 id="explanation">Explanation</h2> <p>The new gas cost scheme for <code>SSTORE</code> is divided into three different types:</p> <ul> <li><strong>No-op</strong>: the virtual machine does not need to do anything. This is the case if <em>current value</em> equals <em>new value</em>.</li> <li><strong>Fresh</strong>: this storage slot has not been changed, or has been reset to its original value. This is the case if <em>current value</em> does not equal <em>new value</em>, and <em>original value</em> equals <em>current value</em>.</li> <li><strong>Dirty</strong>: this storage slot has already been changed. This is the case if <em>current value</em> does not equal <em>new value</em>, and <em>original value</em> does not equal <em>current value</em>.</li> </ul> <p>We can see that the above three types cover all possible variations of <em>original value</em>, <em>current value</em>, and <em>new value</em>.</p> <p><strong>No-op</strong> is a trivial operation. Below we only consider cases for <strong>Fresh</strong> and <strong>Dirty</strong>.</p> <p>All initial (not-<strong>No-op</strong>) <code>SSTORE</code> on a particular storage slot starts with <strong>Fresh</strong>. After that, it will become <strong>Dirty</strong> if the value has been changed. When going from <strong>Fresh</strong> to <strong>Dirty</strong>, we charge the gas cost the same as current scheme. A <strong>Dirty</strong> storage slot can be reset back to <strong>Fresh</strong> via a <code>SSTORE</code> opcode. This will trigger a refund.</p> <p>When a storage slot remains at <strong>Dirty</strong>, we charge 200 gas. In this case, we would also need to keep track of <code>R_SCLEAR</code> refunds -- if we already issued the refund but it no longer applies (<em>current value</em> is 0), then removes this refund from the refund counter. If we didn't issue the refund but it applies now (<em>new value</em> is 0), then adds this refund to the refund counter. It is not possible where a refund is not issued but we remove the refund in the above case, because all storage slot starts with <strong>Fresh</strong> state.</p> <h3 id="state-transition">State Transition</h3> <p>Below is a graph (<a rel="external" href="https://github.com/ethereum/EIPs/pull/1283#issuecomment-410229053">by @Arachnid</a>) showing possible state transition of gas costs. We ignore <strong>No-op</strong> state because that is trivial:</p> <p><img src="https://wg-eips.ritovision.com/1283/./assets/state.png" alt="State Transition" /></p> <p>Below is table version of the above diagram. Vertical shows the <em>new value</em> being set, and horizontal shows the state of <em>original value</em> and <em>current value</em>.</p> <p>When <em>original value</em> is 0:</p> <table><thead><tr><th></th><th>A (<code>current=orig=0</code>)</th><th>B (<code>current!=orig</code>)</th></tr></thead><tbody> <tr><td>~0</td><td>B; 20k gas</td><td>B; 200 gas</td></tr> <tr><td>0</td><td>A; 200 gas</td><td>A; 200 gas, 19.8k refund</td></tr> </tbody></table> <p>When <em>original value</em> is not 0:</p> <table><thead><tr><th></th><th>X (<code>current=orig!=0</code>)</th><th>Y (<code>current!=orig</code>)</th><th>Z (<code>current=0</code>)</th></tr></thead><tbody> <tr><td><code>orig</code></td><td>X; 200 gas</td><td>X; 200 gas, 4.8k refund</td><td>X; 200 gas, -10.2k refund</td></tr> <tr><td><code>~orig, ~0</code></td><td>Y; 5k gas</td><td>Y; 200 gas</td><td>Y; 200 gas, -15k refund</td></tr> <tr><td>0</td><td>Z; 5k gas, 15k refund</td><td>Z; 200 gas, 15k refund</td><td>Z; 200 gas</td></tr> </tbody></table> <h2 id="rationale">Rationale</h2> <p>This EIP mostly achieves what a transient storage tries to do (EIP-1087 and EIP-1153), but without the complexity of introducing the concept of "dirty maps", or an extra storage struct.</p> <ul> <li>We don't suffer from the optimization limitation of EIP-1087. EIP-1087 requires keeping a dirty map for storage changes, and implicitly makes the assumption that a transaction's storage changes are committed to the storage trie at the end of a transaction. This works well for some implementations, but not for others. After EIP-658, an efficient storage cache implementation would probably use an in-memory trie (without RLP encoding/decoding) or other immutable data structures to keep track of storage changes, and only commit changes at the end of a block. For them, it is possible to know a storage's original value and current value, but it is not possible to iterate over all storage changes without incurring additional memory or processing costs.</li> <li>It never costs more gas compared with the current scheme.</li> <li>It covers all usages for a transient storage. Clients that are easy to implement EIP-1087 will also be easy to implement this specification. Some other clients might require a little bit extra refactoring on this. Nonetheless, no extra memory or processing cost is needed on runtime.</li> </ul> <p>Regarding <code>SSTORE</code> gas cost and refunds, see Appendix for proofs of properties that this EIP satisfies.</p> <ul> <li>For <em>absolute gas used</em> (that is, actual <em>gas used</em> minus <em>refund</em>), this EIP is equivalent to EIP-1087 for all cases.</li> <li>For one particular case, where a storage slot is changed, reset to its original value, and then changed again, EIP-1283 would move more gases to refund counter compared with EIP-1087.</li> </ul> <p>Examine examples provided in EIP-1087's Motivation:</p> <ul> <li>If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged <code>20000 + 200 - 19800 = 400</code> gas.</li> <li>A contract with empty storage that increments slot 0 5 times will be charged <code>20000 + 5 * 200 = 21000</code> gas.</li> <li>A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, it will cost <code>5000 * 3 + 200 - 4800 = 10400</code> gas.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork to implement. No gas cost increase is anticipated, and many contracts will see gas reduction.</p> <h2 id="test-cases">Test Cases</h2> <p>Below we provide 17 test cases. 15 of them covering consecutive two <code>SSTORE</code> operations are based on work <a rel="external" href="https://github.com/ethereum/tests/issues/483">by @chfast</a>. Two additional cases with three <code>SSTORE</code> operations is used to test the case when a slot is reset and then set again.</p> <table><thead><tr><th>Code</th><th>Used Gas</th><th>Refund</th><th>Original</th><th>1st</th><th>2nd</th><th>3rd</th></tr></thead><tbody> <tr><td><code>0x60006000556000600055</code></td><td>412</td><td>0</td><td>0</td><td>0</td><td>0</td><td></td></tr> <tr><td><code>0x60006000556001600055</code></td><td>20212</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td></tr> <tr><td><code>0x60016000556000600055</code></td><td>20212</td><td>19800</td><td>0</td><td>1</td><td>0</td><td></td></tr> <tr><td><code>0x60016000556002600055</code></td><td>20212</td><td>0</td><td>0</td><td>1</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556001600055</code></td><td>20212</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td></tr> <tr><td><code>0x60006000556000600055</code></td><td>5212</td><td>15000</td><td>1</td><td>0</td><td>0</td><td></td></tr> <tr><td><code>0x60006000556001600055</code></td><td>5212</td><td>4800</td><td>1</td><td>0</td><td>1</td><td></td></tr> <tr><td><code>0x60006000556002600055</code></td><td>5212</td><td>0</td><td>1</td><td>0</td><td>2</td><td></td></tr> <tr><td><code>0x60026000556000600055</code></td><td>5212</td><td>15000</td><td>1</td><td>2</td><td>0</td><td></td></tr> <tr><td><code>0x60026000556003600055</code></td><td>5212</td><td>0</td><td>1</td><td>2</td><td>3</td><td></td></tr> <tr><td><code>0x60026000556001600055</code></td><td>5212</td><td>4800</td><td>1</td><td>2</td><td>1</td><td></td></tr> <tr><td><code>0x60026000556002600055</code></td><td>5212</td><td>0</td><td>1</td><td>2</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556000600055</code></td><td>5212</td><td>15000</td><td>1</td><td>1</td><td>0</td><td></td></tr> <tr><td><code>0x60016000556002600055</code></td><td>5212</td><td>0</td><td>1</td><td>1</td><td>2</td><td></td></tr> <tr><td><code>0x60016000556001600055</code></td><td>412</td><td>0</td><td>1</td><td>1</td><td>1</td><td></td></tr> <tr><td><code>0x600160005560006000556001600055</code></td><td>40218</td><td>19800</td><td>0</td><td>1</td><td>0</td><td>1</td></tr> <tr><td><code>0x600060005560016000556000600055</code></td><td>10218</td><td>19800</td><td>1</td><td>0</td><td>1</td><td>0</td></tr> </tbody></table> <h2 id="appendix-proof">Appendix: Proof</h2> <p>Because the <em>storage slot's original value</em> is defined as the value when a reversion happens on the <em>current transaction</em>, it's easy to see that call frames won't interfere SSTORE gas calculation. So although the below proof is discussed without call frames, it applies to all situations with call frames. We will discuss the case separately for <em>original value</em> being zero and not zero, and use <em>induction</em> to prove some properties of SSTORE gas cost.</p> <p><em>Final value</em> is the value of a particular storage slot at the end of a transaction. <em>Absolute gas used</em> is the absolute value of <em>gas used</em> minus <em>refund</em>. We use <code>N</code> to represent the total number of SSTORE operations on a storage slot. For states discussed below, refer to <em>State Transition</em> in <em>Explanation</em> section.</p> <h3 id="original-value-being-zero">Original Value Being Zero</h3> <p>When <em>original value</em> is 0, we want to prove that:</p> <ul> <li><strong>Case I</strong>: If the <em>final value</em> ends up still being 0, we want to charge <code>200 * N</code> gases, because no disk write is needed.</li> <li><strong>Case II</strong>: If the <em>final value</em> ends up being a non-zero value, we want to charge <code>20000 + 200 * (N-1)</code> gas, because it requires writing this slot to disk.</li> </ul> <h4 id="base-case">Base Case</h4> <p>We always start at state A. The first SSTORE can:</p> <ul> <li>Go to state A: 200 gas is deducted. We satisfy <em>Case I</em> because <code>200 * N == 200 * 1</code>.</li> <li>Go to state B: 20000 gas is deducted. We satisfy <em>Case II</em> because <code>20000 + 200 * (N-1) == 20000 + 200 * 0</code>.</li> </ul> <h4 id="inductive-step">Inductive Step</h4> <ul> <li>From A to A. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>200 + 200 * (N-1)</code>. It satisfy <em>Case I</em>.</li> <li>From A to B. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>20000 + 200 * (N-1)</code>. It satisfy <em>Case II</em>.</li> <li>From B to B. The previous gas cost is <code>20000 + 200 * (N-2)</code>. The current gas cost is <code>200 + 20000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> <li>From B to A. The previous gas cost is <code>20000 + 200 * (N-2)</code>. The current gas cost is <code>200 - 19800 + 20000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> </ul> <h3 id="original-value-not-being-zero">Original Value Not Being Zero</h3> <p>When <em>original value</em> is not 0, we want to prove that:</p> <ul> <li><strong>Case I</strong>: If the <em>final value</em> ends up unchanged, we want to charge <code>200 * N</code> gases, because no disk write is needed.</li> <li><strong>Case II</strong>: If the <em>final value</em> ends up being zero, we want to charge <code>5000 - 15000 + 200 * (N-1)</code> gas. Note that <code>15000</code> is the refund in actual definition.</li> <li><strong>Case III</strong>: If the <em>final value</em> ends up being a changed non-zero value, we want to charge <code>5000 + 200 * (N-1)</code> gas.</li> </ul> <h4 id="base-case-1">Base Case</h4> <p>We always start at state X. The first SSTORE can:</p> <ul> <li>Go to state X: 200 gas is deducted. We satisfy <em>Case I</em> because <code>200 * N == 200 * 1</code>.</li> <li>Go to state Y: 5000 gas is deducted. We satisfy <em>Case III</em> because <code>5000 + 200 * (N-1) == 5000 + 200 * 0</code>.</li> <li>Go to state Z: The absolute gas used is <code>5000 - 15000</code> where 15000 is the refund. We satisfy <em>Case II</em> because <code>5000 - 15000 + 200 * (N-1) == 5000 - 15000 + 200 * 0</code>.</li> </ul> <h4 id="inductive-step-1">Inductive Step</h4> <ul> <li>From X to X. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>200 + 200 * (N-1)</code>. It satisfy <em>Case I</em>.</li> <li>From X to Y. The previous gas cost is <code>200 * (N-1)</code>. The current gas cost is <code>5000 + 200 * (N-1)</code>. It satisfy <em>Case III</em>.</li> <li>From X to Z. The previous gas cost is <code>200 * (N-1)</code>. The current absolute gas cost is <code>5000 - 15000 + 200 * (N-1)</code>. It satisfy <em>Case II</em>.</li> <li>From Y to X. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The absolute current gas cost is <code>200 - 4800 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> <li>From Y to Y. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The current gas cost is <code>200 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case III</em>.</li> <li>From Y to Z. The previous gas cost is <code>5000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 - 15000 + 5000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> <li>From Z to X. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 10200 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case I</em>.</li> <li>From Z to Y. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 15000 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case III</em>.</li> <li>From Z to Z. The previous gas cost is <code>5000 - 15000 + 200 * (N-2)</code>. The current absolute gas cost is <code>200 + 5000 - 15000 + 200 * (N-2)</code>. It satisfy <em>Case II</em>.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-08-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Ben Kaufmanben@daostack.io Adam Leviadam@daostack.io https://wg-eips.ritovision.com/1285/ <h2 id="simple-summary">Simple Summary</h2> <p>Increase the <code>Gcallstipend</code> fee parameter in the <code>CALL</code> opcode from <code>2,300</code> to <code>3,500</code> gas units.</p> <h2 id="abstract">Abstract</h2> <p>Currently, the <code>CALL</code> opcode forwards a stipend of <code>2,300</code> gas units for a non zero value <code>CALL</code> operations where a contract is called. This stipend is given to the contract to allow execution of its <code>fallback</code> function. The stipend given is intentionally small in order to prevent the called contract from spending the call gas or performing an attack (like re-entrancy). While the stipend is small it should still give the sufficient gas required for some cheap opcodes like <code>LOG</code>, but it's not enough for some more complex and modern logics to be implemented. This EIP proposes to increase the given stipend from <code>2,300</code> to <code>3,500</code> to increase the usability of the <code>fallback</code> function.</p> <h2 id="motivation">Motivation</h2> <p>The main motivation behind this EIP is to allow simple fallback functions to be implemented for contracts following the <code>"Proxy"</code> pattern. Simply explained, a <code>"Proxy Contract"</code> is a contract which use <code>DELEGATECALL</code> in its <code>fallback</code> function to behave according to the logic of another contract and serve as an independent instance for the logic of the contract it points to. This pattern is very useful for saving gas per deployment (as Proxy contracts are very lean) and it opens the ability to experiment with upgradability of contracts. On average, the <code>DELEGATECALL</code> functionality of a proxy contract costs about <code>1,000</code> gas units. When a contract transfers ETH to a proxy contract, the proxy logic will consume about <code>1,000</code> gas units before the <code>fallback</code> function of the logic contract will be executed. This leaves merely about 1,300 gas units for the execution of the logic. This is a severe limitation as it is not enough for an average <code>LOG</code> operation (it might be enough for a <code>LOG</code> with one parameter). By slightly increasing the gas units given in the stipend we allow proxy contracts have proper <code>fallback</code> logic without increasing the attack surface of the calling contract.</p> <h2 id="specification">Specification</h2> <p>Increase the <code>Gcallstipend</code> fee parameter in the <code>CALL</code> opcode from <code>2,300</code> to <code>3,500</code> gas unit. The actual change to the Ethereum clients would be to change the <code>CallStipend</code> they store as a constant. For an implementation example you can find a Geth client implementation linked <a rel="external" href="https://github.com/ben-kaufman/go-ethereum/tree/eip-1285">here</a>. The actual change to the code can be found <a rel="external" href="https://github.com/ben-kaufman/go-ethereum/blob/eip-1285/params/protocol_params.go#L41">here</a>.</p> <h2 id="rationale">Rationale</h2> <p>The rational for increasing the <code>Gcallstipend</code> gas parameter by <code>1,200</code> gas units comes from the cost of performing <code>DELEGATECALL</code> and <code>SLOAD</code> with a small margin for some small additional operations. All while still keeping the stipend relatively small and insufficient for accessing the storage or changing the state.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a backwards incompatible change for the <code>Gcallstipend</code> gas parameter in the <code>CALL</code> opcode.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-08-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/1985/ <h2 id="abstract">Abstract</h2> <p>Introduce an explicit value range for certain EVM parameters (such as gas limit, block number, block timestamp, size field when returning/copying data within EVM). Some of these already have an implicit value range due to various (practical) reasons.</p> <h2 id="motivation">Motivation</h2> <p>Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, and can reduce the effort needed to create consensus critical test cases by eliminating unrealistic edge cases.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= {FORK_BLOCK}</code>, the following value ranges are introduced. They restrict the results (i.e. values pushed to the stack) of the instructions listed below.</p> <ol> <li> <p><em>gas</em>, <em>gas limit</em>, <em>block gas limit</em> is a range between <code>0</code> and <code>0x7fffffffffffffff</code> (<code>2**63 - 1</code>, <code>9223372036854775807</code>). It affects the following instructions:</p> <ul> <li><code>GASLIMIT</code> (<code>0x45</code>),</li> <li><code>GAS</code> (<code>0x5a</code>).</li> </ul> </li> <li> <p><em>block number</em>, <em>timestamp</em> is a range between <code>0</code> and <code>0x7fffffffffffffff</code> (<code>2**63 - 1</code>, <code>9223372036854775807</code>). It affects the following instructions:</p> <ul> <li><code>TIMESTAMP</code> (<code>0x42</code>),</li> <li><code>NUMBER</code> (<code>0x43</code>).</li> </ul> </li> <li> <p><em>account address</em> is a range between <code>0</code> and <code>0xffffffffffffffffffffffffffffffffffffffff</code> (<code>2**160 - 1</code>, <code>1461501637330902918203684832716283019655932542975</code>) i.e. the address occupies the 160 low bits of the 256-bit value and the remaining top 96 bits must be zeros. It affects the following instructions:</p> <ul> <li><code>ADDRESS</code> (<code>0x30</code>),</li> <li><code>ORIGIN</code> (<code>0x32</code>),</li> <li><code>CALLER</code> (<code>0x33</code>),</li> <li><code>COINBASE</code> (<code>0x41</code>),</li> <li><code>CREATE</code> (<code>0xf0</code>),</li> <li><code>CREATE2</code> (<code>0xf5</code>).</li> </ul> </li> <li> <p><em>buffer size</em>, <em>code size</em>, <em>memory size</em> is a range between <code>0</code> and <code>0xffffffff</code> (<code>2**32 - 1</code>, <code>4294967295</code>). It affects the following instructions:</p> <ul> <li><code>CALLDATASIZE</code> (<code>0x36</code>),</li> <li><code>CODESIZE</code> (<code>0x38</code>),</li> <li><code>EXTCODESIZE</code> (<code>0x3b</code>),</li> <li><code>RETURNDATASIZE</code> (<code>0x3d</code>),</li> <li><code>MSIZE</code> (<code>0x59</code>),</li> <li><code>PC</code> (<code>0x58</code>).</li> </ul> </li> </ol> <h2 id="rationale">Rationale</h2> <p>These limits have been:</p> <ul> <li>proposed by <a rel="external" href="https://github.com/ethereum/evmc">EVMC</a></li> <li>implemented partially by certain clients, such as <a rel="external" href="https://github.com/ethereum/aleth">Aleth</a>, <a rel="external" href="https://github.com/ethereum/go-ethereum">geth</a>, <a rel="external" href="https://github.com/paritytech/parity-ethereum">Parity</a> and <a rel="external" href="https://github.com/ethereumjs">ethereumjs</a></li> <li>allowed by certain test cases in the <a rel="external" href="https://github.com/ethereum/tests">Ethereum testing suite</a></li> <li>and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit</li> </ul> <p>Most of the limits proposed in this document have been previously explored and tested in <a rel="external" href="https://github.com/ethereum/evmc">EVMC</a>.</p> <p>Using the <code>2**63 - 1</code> constant to limit some of the ranges:</p> <ul> <li>allows using signed 64-bit integer type to represent it, what helps programming languages not having unsigned types,</li> <li>makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as <code>gas_counter &lt; 0</code>).</li> </ul> <h3 id="timestamp">Timestamp</h3> <p>The <a rel="external" href="https://github.com/ethereum/yellowpaper">Yellow Paper</a> defines the timestamp in block as "A scalar value equal to the reasonable output of Unix’s time() at this block’s inception". IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined.</p> <h3 id="addresses">Addresses</h3> <p>The size of addresses is specified in the <a rel="external" href="https://github.com/ethereum/yellowpaper">Yellow Paper</a> as 20 bytes. E.g. the <code>COINBASE</code> instruction is specified to return <em>H</em>_c ∈ 𝔹₂₀ which has 20 bytes.</p> <h3 id="memory-size">Memory size</h3> <p>Memory expansion cost is not linear and is determined by the following formula: cost = cost_per_word * number_of_words + (number_of_words ^ 2 / 512)</p> <p>Expanding to over <code>2^32 - 1</code> bytes would cost <code>35184774742016</code> gas. This number fits into the gas limit imposed above (<code>2 ^ 63 - 1</code>) and would cost around 35184 Ether in a transaction to exhaust, with a 1 GWei gas cost, which can be attained on mainnet.</p> <p>However, setting the limit <code>2^32 - 1</code> is beneficial from a VM design perspective and we believe limiting memory should be done via carefully selecting the block gas limit.</p> <h3 id="code-size">Code size</h3> <p><a href="https://wg-eips.ritovision.com/170/">EIP-170</a> has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding <code>2**32 - 1</code> bytes in size.</p> <h3 id="comparing-current-implementations">Comparing current implementations</h3> <ul> <li>Timestamp is implemented as a 64-bit value in <a rel="external" href="https://github.com/ethereum/aleth">Aleth</a>, <a rel="external" href="https://github.com/ethereum/go-ethereum">geth</a> and <a rel="external" href="https://github.com/paritytech/parity-ethereum">Parity</a></li> <li>Block gas limit is implemented as a 64-bit in <a rel="external" href="https://github.com/ethereum/aleth">Aleth</a> and <a rel="external" href="https://github.com/ethereum/go-ethereum">geth</a></li> <li>Memory, buffer and code sizes are implemented as 64-bit values in <a rel="external" href="https://github.com/ethereum/go-ethereum">geth</a></li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>All of these limits are already enforced mostly through the block gas limit. Since the out of range case results in a transaction failure, there should not be a change in behaviour.</p> <h2 id="test-cases">Test Cases</h2> <p>TBA</p> <h2 id="implementation">Implementation</h2> <p>TBA</p> <h2 id="references">References</h2> <ul> <li><a rel="external" href="https://github.com/ethereum/EIPs/issues/92">EIP-92</a> proposed the transaction gas limit to be limited at <code>2**63 - 1</code> and had a lengthy discussion about other limits.</li> <li><a rel="external" href="https://github.com/ethereum/EIPs/issues/106">EIP-106</a> proposed the block gas limit to be limited at <code>2**63 - 1</code>.</li> </ul> <h2 id="todo">TODO</h2> <ol> <li>Does the gas limit apply to the gas argument for call instructions?</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-07-31T00:00:00+00:00 2026-02-11T14:49:27+00:00 EOS Classichttps://github.com/eosclassicteam https://wg-eips.ritovision.com/1276/ <h2 id="simple-summary">Simple Summary</h2> <p>The average block times are increasing due to the factor of difficulty logic well known as difficulty bomb. This EIP proposes to eliminate the difficulty bomb forever and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>CNSTNTNPL_FORK_BLKNUM</code> the client will calculate the difficulty without considering the current block number. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.</p> <h2 id="motivation">Motivation</h2> <p>Block time has been played a most important role on blockchain ecosystem, and it is being adjusted by the logic of mining difficulty calculation that is already implemented on the node client as a part of proof-of-work consensus. Last year, average block time rapidly increased due to the wrong design of difficulty logic that is meant to be changed on the part of Casper upgrade, however, implementation of casper has been delayed therefore it was inevitable to delay the difficulty bomb in order to prevent the significant delay of processing transactions on ethereum network.</p> <p>Despite of the successful hardfork to delay the activation of difficulty bomb, activation of the difficulty bomb is expected to happen again on the upcoming period before implementing casper protocol on ethereum network. Therefore, completely removing the difficulty bomb is the most proper way to response the block time increase instead of delaying it again.</p> <p>Also decreasing the block mining reward along with difficulty bomb removal is expected to help the growth of the stable ethereum ecosystem, right now ethereum dominates 92% of the total hashrate share of ethash based chains, and this corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.</p> <h2 id="specification">Specification</h2> <h4 id="remove-exponential-component-of-difficulty-adjustment">Remove Exponential Component of Difficulty Adjustment</h4> <p>For the purposes of <code>calc_difficulty</code>, simply remove the exponential difficulty adjustment component, <code>epsilon</code>, i.e. the <code>int(2**((block.number // 100000) - 2))</code>.</p> <h4 id="adjust-block-uncle-and-nephew-rewards">Adjust Block, Uncle, and Nephew rewards</h4> <p>To ensure a constant Ether issuance, adjust the block reward to <code>new_block_reward</code>, where</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_block_reward = 2_000_000_000_000_000_000 if block.number &gt;= CNSTNTNPL_FORK_BLKNUM else block.reward</span></span></code></pre> <p>(2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH).</p> <p>Analogue, if an uncle is included in a block for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (8 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing pre-Constantinople formula for uncle rewards, simply adjusted with <code>new_block_reward</code>.</p> <p>The nephew reward for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = new_block_reward / 32</span></span></code></pre> <p>This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with <code>new_block_reward</code>.</p> <h2 id="rationale">Rationale</h2> <p>This will completely remove the difficulty bomb on difficulty adjustment algorithm without delaying the difficulty bomb again, therefore it is possible to prevent network delay on the beginning of 2019.</p> <p>This EIP-1276 opposes directly the intent of <a href="https://wg-eips.ritovision.com/1234/">EIP-1234</a> which should be also considered in discussions.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, <em>Constantinople</em>.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="implementation">Implementation</h2> <p>The implementation shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-07-27T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/1352/ <h2 id="simple-summary">Simple Summary</h2> <p>Specify an Ethereum address range occupied by precompiles and future system contracts. Regular accounts and contracts cannot obtain such an address.</p> <h2 id="abstract">Abstract</h2> <p>The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts.</p> <h2 id="motivation">Motivation</h2> <p>This will simplify certain future features where unless this is implemented, several exceptions must be specified.</p> <h2 id="specification">Specification</h2> <p>The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts.</p> <p>Due to the extremely low probability (and lack of adequate testing possibilities) no explicit checks should be added to ensure that external transaction signing or the invoking of the <code>CREATE</code> instruction can result in a precompile address.</p> <h2 id="rationale">Rationale</h2> <p>N/A</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>No contracts on the main network have been created at the specified addresses. As a result it should pose no backwards compatibility problems.</p> <h2 id="test-cases">Test Cases</h2> <p>N/A</p> <h2 id="implementation">Implementation</h2> <p>N/A</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-07-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/1240/ <h2 id="simple-summary">Simple Summary</h2> <p>The average block times are increasing due to the difficulty bomb (also known as the "<em>ice age</em>") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLOCK_NUMBER</code> the client will calculate the difficulty without considering the current block number.</p> <h2 id="motivation">Motivation</h2> <p>The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around.</p> <h2 id="specification">Specification</h2> <h4 id="remove-difficulty">Remove Difficulty</h4> <p>For the purposes of <code>calc_difficulty</code>, if <code>block.number &gt;= FORK_BLOCK_NUMBER</code> then change the epsilon component to <code>0</code> rather than having it be a function of block number.</p> <h2 id="rationale">Rationale</h2> <p>With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.</p> <p>Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="implementations">Implementations</h2> <p>The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-07-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Afri Schoedonhttps://github.com/5chdn https://wg-eips.ritovision.com/1234/ <h2 id="simple-summary">Simple Summary</h2> <p>The average block times are increasing due to the difficulty bomb (also known as the "<em>ice age</em>") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>CNSTNTNPL_FORK_BLKNUM</code> the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 5 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.</p> <h2 id="motivation">Motivation</h2> <p>The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another 12 months. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fake_block_number = max(0, block.number - 5_000_000) if block.number &gt;= CNSTNTNPL_FORK_BLKNUM else block.number</span></span></code></pre><h4 id="adjust-block-uncle-and-nephew-rewards">Adjust Block, Uncle, and Nephew rewards</h4> <p>To ensure a constant Ether issuance, adjust the block reward to <code>new_block_reward</code>, where</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_block_reward = 2_000_000_000_000_000_000 if block.number &gt;= CNSTNTNPL_FORK_BLKNUM else block.reward</span></span></code></pre> <p>(2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH).</p> <p>Analogue, if an uncle is included in a block for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (8 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing pre-Constantinople formula for uncle rewards, simply adjusted with <code>new_block_reward</code>.</p> <p>The nephew reward for <code>block.number &gt;= CNSTNTNPL_FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = new_block_reward / 32</span></span></code></pre> <p>This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with <code>new_block_reward</code>.</p> <h2 id="rationale">Rationale</h2> <p>This will delay the ice age by 29 million seconds (approximately 12 months), so the chain would be back at 30 second block times in winter 2019. An alternate proposal was to add special rules to the difficulty calculation to effectively <em>pause</em> the difficulty between different blocks. This would lead to similar results.</p> <p>This was previously discussed at All Core Devs Meeting <a rel="external" href="https://github.com/ethereum/pm/blob/6dbd82303bfcb697eaf9a76de37f5fa570e6379d/AllCoreDevs-EL-Meetings/Meeting%2042.md">#42</a> and subsequent meetings; and accepted in the Constantinople Session <a rel="external" href="https://github.com/ethereum/pm/issues/55">#1</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, <em>Constantinople</em>.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p> <h2 id="implementation">Implementation</h2> <p>The implementation in it's logic does not differ from <a href="https://wg-eips.ritovision.com/649/">EIP-649</a>; an implementation for Parity-Ethereum is available in <a rel="external" href="https://github.com/paritytech/parity-ethereum/pull/9187">parity-ethereum#9187</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-07-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 SmeargleUsedFlyhttps://github.com/SmeargleUsedFly https://wg-eips.ritovision.com/1227/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP proposes to permanently disable the "difficulty bomb" and reset the block reward to pre-Byzantium levels.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>FORK_BLKNUM</code> the client will calculate the difficulty without the additional exponential component. Furthermore, block rewards will be adjusted to a base of 5 ETH, uncle and nephew rewards will be adjusted accordingly.</p> <h2 id="motivation">Motivation</h2> <p>Due to the "difficulty bomb" (also known as the "ice age"), introduced in EIP <a href="https://wg-eips.ritovision.com/2/">#2</a>, an artificial exponential increase in difficulty until chain freeze, users may find it much more challenging to remain on the unforked chain after a hard-fork. This is a desirable effect of the ice age (in fact, its only stated purpose) in the case of a scheduled network upgrade, but is especially problematic when a hard-fork includes a controversial change.</p> <p>This situation has already been observed: during the Byzantium hard-fork users were given the "choice" of following the upgraded side of the chain or remaining on the original chain, the latter already experiencing block times greater than 30 seconds. In reality one will find that organizing a disperse and decentralized set of individuals to keep the original, soon-to-be-dead chain alive under such conditions impossible. This is exacerbated when a controversial change, such as EIP <a href="https://wg-eips.ritovision.com/649/">#649</a>, is merged in so close to the hard-fork date, as users cannot be organized to take an educated stance for or against the change on such short notice.</p> <p>Ultimately, the difficulty bomb serves but a single purpose: make it more difficult to keep the original chain alive after a hard-fork. This is unacceptable if the only way the community can make their voice heard is running/not running client software, and not through the EIP process, since they effectively have no choice and therefore no power. This EIP proposes to completely eliminate the difficulty bomb, returning some measure of power over Ethereum's governance process to the users, to the community.</p> <p>Given the controversy surrounding the directly relevant EIP <a href="https://wg-eips.ritovision.com/649/">#649</a>, the issuance should also be reset to pre-Byzantium levels. It may be reduced again at a later time via a new hard-fork, only this time users would actually have a meaningful choice in accepting the change or not. Note: the issuance reduction is not the focus of this proposal, and is optional; the defusing of the difficulty bomb is of primary concern.</p> <h2 id="specification">Specification</h2> <h4 id="remove-exponential-component-of-difficulty-adjustment">Remove Exponential Component of Difficulty Adjustment</h4> <p>For the purposes of <code>calc_difficulty</code>, simply remove the exponential difficulty adjustment component, <code>epsilon</code>, i.e. the <code>int(2**((block.number // 100000) - 2))</code>.</p> <h4 id="reset-block-uncle-and-nephew-rewards">Reset Block, Uncle, and Nephew rewards</h4> <p>To ensure a constant Ether issuance, adjust the block reward to <code>new_block_reward</code>, where</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_block_reward = 5_000_000_000_000_000_000 if block.number &gt;= FORK_BLKNUM else block.reward</span></span></code></pre> <p>(5E18 wei, or 5,000,000,000,000,000,000 wei, or 5 ETH).</p> <p>Analogue, if an uncle is included in a block for <code>block.number &gt;= FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (8 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing pre-Byzantium formula for uncle rewards, simply adjusted with <code>new_block_reward</code>.</p> <p>The nephew reward for <code>block.number &gt;= FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = new_block_reward / 32</span></span></code></pre> <p>This is the existing pre-Byzantium formula for nephew rewards, simply adjusted with <code>new_block_reward</code>.</p> <h2 id="rationale">Rationale</h2> <p>This will permanently, without further changes, disable the "ice age." It will also reset the block reward to pre-Byzantium levels. Both of these changes are specified similarly to EIP <a href="https://wg-eips.ritovision.com/649/">#649</a>, so they should require only minimal changes from client developers.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. However, it may be controversial in nature among different sections of the userbase—the very problem this EIP is made to address. Therefore, it should not be included in a scheduled hardfork at a certain block number. It is suggested to implement this EIP in an isolated hard-fork before the second of the two Metropolis hard-forks.</p> <h2 id="test-cases">Test Cases</h2> <p>Forthcoming.</p> <h2 id="implementation">Implementation</h2> <p>Forthcoming.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-06-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alexey Akhunovhttps://github.com/AlexeyAkhunov Moody Salemhttps://github.com/moodysalem https://wg-eips.ritovision.com/1153/

Add opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction

<h2 id="abstract">Abstract</h2> <p>This proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction, and <code>TSTORE</code> is not subject to the gas stipend check as defined in <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a>. In other words, the values of transient storage are never deserialized from storage or serialized to storage. Thus transient storage is cheaper since it never requires disk access. Transient storage is accessible to smart contracts via 2 new opcodes, <code>TLOAD</code> and <code>TSTORE</code>, where “T” stands for "transient:"</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TLOAD (0x5c)</span></span> <span class="giallo-l"><span>TSTORE (0x5d)</span></span></code></pre><h2 id="motivation">Motivation</h2> <p>Running a transaction in Ethereum can generate multiple nested frames of execution, each created by <code>CALL</code> (or similar) instructions. Contracts can be re-entered during the same transaction, in which case there are more than one frame belonging to one contract. Currently, these frames can communicate in two ways: via inputs/outputs passed via <code>CALL</code> instructions, and via storage updates. If there is an intermediate frame belonging to another untrusted contract, communication via inputs/outputs is not secure. Notable example is a reentrancy lock which cannot rely on the intermediate frame to pass through the state of the lock. Communication via storage (<code>SSTORE</code>/<code>SLOAD</code>) is costly. Transient storage is a dedicated and gas efficient solution to the problem of inter frame communication.</p> <p>Storage refunds accumulated due to inter frame communication are also limited to 20% of gas spent by a transaction due to <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a> (introduced in the London hard fork). This greatly reduces the refunds for transiently-set storage slots in otherwise low-cost transactions. For example, in order to receive the full refund of one re-entrancy lock, the transaction must spend ~80k gas on other operations.</p> <p>Language support could be added in relatively easy way. For example, in Solidity, a qualifier <code>transient</code> can be introduced (similar to the existing qualifiers <code>memory</code> and <code>storage</code>, and Java's own <code>transient</code> keyword with a similar meaning). Since the addressing scheme of <code>TSTORE</code> and <code>TLOAD</code> is the same as for <code>SSTORE</code> and <code>SLOAD</code>, code generation routines that exist for storage variables, can be easily generalised to also support transient storage.</p> <p>Potential use cases enabled or improved by this EIP include:</p> <ol> <li>Reentrancy locks</li> <li>On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of init code hash</li> <li>Single transaction <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> approvals, e.g. <code>#temporaryApprove(address spender, uint256 amount)</code></li> <li>Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction</li> <li>"Till" pattern: allowing users to perform all actions as part of a callback, and checking the "till" is balanced at the end</li> <li>Proxy call metadata: pass additional metadata to an implementation contract without using calldata, e.g. values of immutable proxy constructor arguments</li> </ol> <p>These opcodes are more efficient to execute than the <code>SSTORE</code> and <code>SLOAD</code> opcodes because the original value never needs to be loaded from storage (i.e. is always 0). The gas accounting rules are also simpler, since no refunds are required.</p> <h2 id="specification">Specification</h2> <p>Two new opcodes are added to EVM, <code>TLOAD</code> (<code>0x5c</code>) and <code>TSTORE</code> (<code>0x5d</code>). (Note that previous drafts of this EIP specified the values <code>0xb3</code> and <code>0xb4</code> for <code>TLOAD</code> and <code>TSTORE</code> respectively to avoid conflict with other EIPs. The conflict has since been removed.)</p> <p>They use the same arguments on stack as <code>SLOAD</code> (<code>0x54</code>) and <code>SSTORE</code> (<code>0x55</code>).</p> <p><code>TLOAD</code> pops one 32-byte word from the top of the stack, treats this value as the address, fetches 32-byte word from the transient storage at that address, and pushes the value on top of the stack.</p> <p><code>TSTORE</code> pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. <code>TSTORE</code> saves the value at the given address in the transient storage.</p> <p>Addressing is the same as <code>SLOAD</code> and <code>SSTORE</code>. i.e. each 32-byte address points to a unique 32-byte word.</p> <p>Gas cost for <code>TSTORE</code> is the same as a warm <code>SSTORE</code> of a dirty slot (i.e. original value is not new value and is not current value, currently 100 gas), and gas cost of <code>TLOAD</code> is the same as a hot <code>SLOAD</code> (value has been read before, currently 100 gas). Gas cost cannot be on par with memory access due to transient storage's interactions with reverts.</p> <p>All values in transient storage are discarded at the end of the transaction.</p> <p>Transient storage is private to the contract that owns it, in the same way as persistent storage. Only owning contract frames may access their transient storage. And when they do, all the frames access the same transient store, in the same way as persistent storage, but unlike memory.</p> <p>When transient storage is used in the context of <code>DELEGATECALL</code> or <code>CALLCODE</code>, then the owning contract of the transient storage is the contract that issued <code>DELEGATECALL</code> or <code>CALLCODE</code> instruction (the caller) as with persistent storage. When transient storage is used in the context of <code>CALL</code> or <code>STATICCALL</code>, then the owning contract of the transient storage is the contract that is the target of the <code>CALL</code> or <code>STATICCALL</code> instruction (the callee).</p> <p>If a frame reverts, all writes to transient storage that took place between entry to the frame and the return are reverted, including those that took place in inner calls. This mimics the behavior of persistent storage.</p> <p>If the <code>TSTORE</code> opcode is called within the context of a <code>STATICCALL</code>, it will result in an exception instead of performing the modification. <code>TLOAD</code> is allowed within the context of a <code>STATICCALL</code>.</p> <p>The behavior of the opcodes for transient storage differs from the opcodes for storage in that <code>TSTORE</code> does not require <em>gasleft</em>, as defined in <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a>, to be less than or equal to the gas stipend (currently 2,300).</p> <h2 id="rationale">Rationale</h2> <p>Another option to solve the problem of inter-frame communication is repricing the <code>SSTORE</code> and <code>SLOAD</code> opcodes to be cheaper for the transient storage use case. This has already been done as of <a href="https://wg-eips.ritovision.com/2200/">EIP-2200</a>. However, <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a> reduced the maximum refund to only 20% of the transaction gas cost, which means the use of transient storage is severely limited.</p> <p>Another approach is to keep the refund counter for transient storage separate from the refund counter for other storage uses, and remove the refund cap for transient storage. However, that approach is more complex to implement and understand. For example, the 20% refund cap must be applied to the gas used <em>after</em> subtracting the uncapped gas refund. Otherwise, the refund amount available subject to the 20% refund cap could be increased by executing transient storage writes. Thus it is preferable to have a separate mechanism that does not interact with the refund counter. Future hard forks can remove the complex refund behavior meant to support the transient storage use case, encouraging migration to contracts that are more efficient for the Ethereum clients to execute.</p> <p>There is a known objection to the word-addressed storage-like interface of the <code>TSTORE</code> and <code>TLOAD</code> opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the <a href="https://wg-eips.ritovision.com/20/">ERC-20</a> temporary approval use case which uses a mapping of <code>(owner, spender)</code> to <code>allowance</code>. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers.</p> <p>Some think that a unique transaction identifier may obviate the need for transient storage as described in this EIP. This is a misconception: a transaction identifier used in combination with regular storage has all the same issues that motivate this EIP. The two features are orthogonal.</p> <p>Relative cons of this transient storage EIP:</p> <ul> <li>Does not address transient usages of storage in existing contracts</li> <li>New code in the clients</li> <li>New concept for the yellow paper (more to update)</li> </ul> <p>Relative pros of this transient storage EIP:</p> <ul> <li>Transient storage opcodes are considered separately in protocol upgrades and not inadvertently broken (e.g. <a href="https://wg-eips.ritovision.com/3529/">EIP-3529</a>)</li> <li>Clients do not need to load the original value</li> <li>No upfront gas cost to account for non-transient writes</li> <li>Does not change the semantics of the existing operations</li> <li>No need to clear storage slots after usage</li> <li>Simpler gas accounting rules</li> <li>Future storage designs (e.g. Verkle tree) do not need to account for transient storage refunds</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork to implement.</p> <p>Since this EIP does not change behavior of any existing opcodes, it is backwards compatible with all existing smart contracts.</p> <h2 id="test-cases">Test Cases</h2> <p>A test suite for this EIP can be found <a rel="external" href="https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip1153_tstore">here</a>.</p> <h2 id="reference-implementation">Reference Implementation</h2> <p>Because the transient storage must behave almost identically to storage within the context of a single transaction with regards to revert behavior, it is necessary to be able to revert to a previous state of transient storage within a transaction. At the same time reverts are exceptional cases and loads, stores and returns should be cheap.</p> <p>A map of current state plus a journal of all changes and a list of checkpoints is recommended. This has the following time complexities:</p> <ul> <li>On entry to a call frame, a call marker is added to the list - <code>O(1)</code></li> <li>New values are written to the current state, and the previous value is written to the journal - <code>O(1)</code></li> <li>When a call exits successfully, the marker to the journal index of when that call was entered is discarded - <code>O(1)</code></li> <li>On revert all entries are reverted up to the last checkpoint, in reverse - <code>O(N)</code> where <code>N</code> = number of journal entries since last checkpoint</li> </ul> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-storage z-type">interface</span><span class="z-entity z-name"> JournalEntry</span><span> {</span></span> <span class="giallo-l"><span class="z-variable"> addr</span><span class="z-keyword">:</span><span class="z-support"> string</span></span> <span class="giallo-l"><span class="z-variable"> key</span><span class="z-keyword">:</span><span class="z-support"> string</span></span> <span class="giallo-l"><span class="z-variable"> prevValue</span><span class="z-keyword">:</span><span class="z-support"> string</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">type</span><span class="z-entity z-name"> Journal</span><span class="z-keyword"> =</span><span class="z-entity z-name"> JournalEntry</span><span>[</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">type</span><span class="z-entity z-name"> Checkpoints</span><span class="z-keyword"> =</span><span class="z-entity z-name"> Journal</span><span>[</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">length</span><span class="z-punctuation z-definition z-string">&#39;</span><span>]</span><span>[</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">interface</span><span class="z-entity z-name"> Current</span><span> {</span></span> <span class="giallo-l"><span> [</span><span class="z-variable">addr</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>]</span><span class="z-keyword">:</span><span> {</span></span> <span class="giallo-l"><span> [</span><span class="z-variable">key</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>]</span><span class="z-keyword">:</span><span class="z-support"> string</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">const</span><span class="z-variable z-other z-constant"> EMPTY_VALUE</span><span class="z-keyword"> =</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">0x0000000000000000000000000000000000000000000000000000000000000000</span><span class="z-punctuation z-definition z-string">&#39;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">class</span><span class="z-entity z-name"> TransientStorage</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * The current state of transient storage.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> private</span><span class="z-variable"> current</span><span class="z-keyword">:</span><span class="z-entity z-name"> Current</span><span class="z-keyword"> =</span><span> {</span><span>}</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * All changes are written to the journal. On revert, we apply the changes in reverse to the last checkpoint.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> private</span><span class="z-variable"> journal</span><span class="z-keyword">:</span><span class="z-entity z-name"> Journal</span><span class="z-keyword"> =</span><span> [</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * The length of the journal at the time of each checkpoint</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> private</span><span class="z-variable"> checkpoints</span><span class="z-keyword">:</span><span class="z-entity z-name"> Checkpoints</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">0</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * Returns the current value of the given contract address and key</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@</span><span class="z-storage z-type">param</span><span class="z-variable z-other"> addr</span><span class="z-comment"> The address of the contract</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@</span><span class="z-storage z-type">param</span><span class="z-variable z-other"> key</span><span class="z-comment"> The key of transient storage for the address</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> public</span><span class="z-entity z-name"> get</span><span>(</span><span class="z-variable">addr</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span><span class="z-variable"> key</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>)</span><span class="z-keyword">:</span><span class="z-support"> string</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">current</span><span>[</span><span class="z-variable z-other">addr</span><span>]</span><span>?.</span><span>[</span><span class="z-variable z-other">key</span><span>]</span><span class="z-keyword"> ??</span><span class="z-variable z-other z-constant"> EMPTY_VALUE</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * Set the current value in the map</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@</span><span class="z-storage z-type">param</span><span class="z-variable z-other"> addr</span><span class="z-comment"> the address of the contract for which the key is being set</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@</span><span class="z-storage z-type">param</span><span class="z-variable z-other"> key</span><span class="z-comment"> the slot to set for the address</span></span> <span class="giallo-l"><span class="z-comment"> * </span><span class="z-storage z-type">@</span><span class="z-storage z-type">param</span><span class="z-variable z-other"> value</span><span class="z-comment"> the new value of the slot to set</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> public</span><span class="z-entity z-name"> put</span><span>(</span><span class="z-variable">addr</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span><span class="z-variable"> key</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>,</span><span class="z-variable"> value</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">journal</span><span>.</span><span class="z-entity z-name">push</span><span>(</span><span>{</span></span> <span class="giallo-l"><span class="z-variable z-other"> addr</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> key</span><span>,</span></span> <span class="giallo-l"><span> prevValue</span><span>:</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-entity z-name">get</span><span>(</span><span class="z-variable z-other">addr</span><span>,</span><span class="z-variable z-other"> key</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">current</span><span>[</span><span class="z-variable z-other">addr</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">current</span><span>[</span><span class="z-variable z-other">addr</span><span>]</span><span class="z-keyword"> ??</span><span> {</span><span>}</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">current</span><span>[</span><span class="z-variable z-other">addr</span><span>]</span><span>[</span><span class="z-variable z-other">key</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> value</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * Commit all the changes since the last checkpoint</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> public</span><span class="z-entity z-name"> commit</span><span>(</span><span>)</span><span class="z-keyword">:</span><span class="z-support"> void</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-variable z-language">this</span><span>.</span><span class="z-variable z-other">checkpoints</span><span>.</span><span class="z-support z-variable">length</span><span class="z-keyword"> ===</span><span class="z-constant"> 0</span><span>)</span><span class="z-keyword"> throw</span><span class="z-keyword"> new</span><span class="z-entity z-name"> Error</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">Nothing to commit</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">checkpoints</span><span>.</span><span class="z-entity z-name">pop</span><span>(</span><span>)</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The last checkpoint is discarded.</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * To be called whenever entering a new context. If revert is called after checkpoint, all changes made after the latest checkpoint are reverted.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> public</span><span class="z-entity z-name"> checkpoint</span><span>(</span><span>)</span><span class="z-keyword">:</span><span class="z-support"> void</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">checkpoints</span><span>.</span><span class="z-entity z-name">push</span><span>(</span><span class="z-variable z-language">this</span><span>.</span><span class="z-variable z-other">journal</span><span>.</span><span class="z-support z-variable">length</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /**</span></span> <span class="giallo-l"><span class="z-comment"> * Revert transient storage to the state from the last call to checkpoint</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"><span class="z-storage"> public</span><span class="z-entity z-name"> revert</span><span>(</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span class="z-variable z-other z-constant"> lastCheckpoint</span><span class="z-keyword"> =</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">checkpoints</span><span>.</span><span class="z-entity z-name">pop</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span class="z-keyword">typeof</span><span class="z-variable z-other"> lastCheckpoint</span><span class="z-keyword"> ===</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">undefined</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span><span class="z-keyword"> throw</span><span class="z-keyword"> new</span><span class="z-entity z-name"> Error</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">Nothing to revert</span><span class="z-punctuation z-definition z-string">&#39;</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">let</span><span class="z-variable z-other"> i</span><span class="z-keyword"> =</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">journal</span><span>.</span><span class="z-support z-variable">length</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword"> &gt;=</span><span class="z-variable z-other"> lastCheckpoint</span><span>;</span><span class="z-variable z-other"> i</span><span class="z-keyword">--</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span> {</span><span class="z-variable z-other z-constant">addr</span><span>,</span><span class="z-variable z-other z-constant"> key</span><span>,</span><span class="z-variable z-other z-constant"> prevValue</span><span>}</span><span class="z-keyword"> =</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">journal</span><span>[</span><span class="z-variable z-other">i</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> we can assume it exists, since it was written in the journal</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">current</span><span>[</span><span class="z-variable z-other">addr</span><span>]</span><span>[</span><span class="z-variable z-other">key</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> prevValue</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">journal</span><span>.</span><span class="z-entity z-name">splice</span><span>(</span><span class="z-variable z-other">lastCheckpoint</span><span>,</span><span class="z-variable z-language"> this</span><span>.</span><span class="z-variable z-other">journal</span><span>.</span><span class="z-support z-variable">length</span><span class="z-keyword"> -</span><span class="z-variable z-other"> lastCheckpoint</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The worst case time complexity can be produced by writing the maximum number of keys that can fit in one block, and then reverting. In this case, the client is required to do twice as many writes to apply all the entries in the journal. However, the same case applies to the state journaling implementation of existing clients, and cannot be DOS'd with the following code.</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-keyword">pragma</span><span class="z-entity z-name z-tag"> solidity</span><span class="z-constant"> =0.8.13</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">contract</span><span class="z-entity z-name"> TryDOS</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint256</span><span> slot</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> constructor</span><span>(</span><span>)</span><span> {</span></span> <span class="giallo-l"><span> slot </span><span class="z-keyword">=</span><span class="z-constant"> 1</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> function</span><span class="z-entity z-name"> tryDOS</span><span>(</span><span>)</span><span class="z-storage z-type"> external</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint256</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 1</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> (</span><span class="z-variable z-language">gasleft</span><span>(</span><span>)</span><span class="z-keyword"> &gt;</span><span class="z-constant"> 5000</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> unchecked</span><span> {</span></span> <span class="giallo-l"><span> slot </span><span class="z-keyword">=</span><span> i</span><span class="z-keyword">+</span><span class="z-keyword">+</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> revert</span><span>(</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p><code>TSTORE</code> presents a new way to allocate memory on a node with linear cost. In other words, each TSTORE allows the developer to store 32 bytes for 100 gas, excluding any other required operations to prepare the stack. Given 30 million gas, the maximum amount of memory that can be allocated using TSTORE is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>30M gas * 1 TSTORE / 100 gas * 32 bytes / 1 TSTORE * 1MB / 2^20 bytes ~= 9.15MB</span></span></code></pre> <p>Given the same amount of gas, the maximum amount of memory that can be allocated in a single context by <code>MSTORE</code> is ~3.75MB:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>30M gas = 3x + x^2 / 512 =&gt; x = ~123,169 32-byte words</span></span> <span class="giallo-l"><span>~123,169 words * 32 bytes/word * 1MB / 2^20 bytes = 3.75MB</span></span></code></pre> <p>However, if you only spend 1M gas allocating memory in each context, and make calls to reset the memory expansion cost, you can allocate ~700KB per million gas, for a total of ~20MB of memory allocated:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>1M gas = 3x + x^2 / 512 =&gt; x = ~21,872 32-byte words</span></span> <span class="giallo-l"><span>30M gas * ~21,872 words / 1M gas * 32 bytes/word * 1MB / 2^20 bytes = ~20MB</span></span></code></pre> <p>Smart contract developers should understand the lifetime of transient storage variables before use. Because transient storage is automatically cleared at the end of the transaction, smart contract developers may be tempted to avoid clearing slots as part of a call in order to save gas. However, this could prevent further interactions with the contract in the same transaction (e.g. in the case of re-entrancy locks) or cause other bugs, so smart contract developers should be careful to <em>only</em> leave transient storage slots with nonzero values when those slots are intended to be used by future calls within the same transaction. Otherwise, these opcodes behave exactly the same as <code>SSTORE</code> and <code>SLOAD</code>, so all the usual security considerations apply especially in regard to reentrancy risk.</p> <p>Smart contract developers may also be tempted to use transient storage as an alternative to in-memory mappings. They should be aware that transient storage is not discarded when a call returns or reverts, as is memory, and should prefer memory for these use cases so as not to create unexpected behavior on reentrancy in the same transaction. The necessarily high cost of transient storage over memory should already discourage this usage pattern. Most usages of in-memory mappings can be better implemented with key-sorted lists of entries, and in-memory mappings are rarely required in smart contracts (i.e. the author knows of no known use cases in production).</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-05-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Jordi Baylinahttps://github.com/jbaylina https://wg-eips.ritovision.com/1109/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP creates a specific opcode named <code>PRECOMPILEDCALL</code> to call Precompiled contracts without the costs of a normal <code>CALL</code>.</p> <h2 id="abstract">Abstract</h2> <p>This EIP tries to resolve the problem of high gas consumption when calling precompiled contracts with a small gas cost. Using this opcode for calling precompiled contracts allows to define precompiled contracts whose effective cost it is less than 700.</p> <h2 id="motivation">Motivation</h2> <p>Each precompiled contract has an already defined cost for calling it. It does not make sense to add the implicit extra gas cost of the CALL opcode.</p> <p>As an example, SHA256 precompiled contract costs 60 and ECADD costs 500 (proposed to costs only 50 in <a href="https://wg-eips.ritovision.com/1108/">EIP-1108</a> . When a precompiled contract is called, 700 gas is consumed just for the CALL opcode besides the costs of the precompiled contract.</p> <p>This makes no sense, and right now it's impossible to define a precompiled contract whose effective cost for using it, is less than 700.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= XXXXX</code>, define a new opcode named <code>PRECOMPILEDCALL</code> with code value <code>0xfb</code>.</p> <p>The gas cost of the OPCODE is 2 (Gbase) plus the Specific gas cost defined for each specific precompiled smart contract.</p> <p>The OPCODE takes 5 words from the stack and returns 1 word to the stack.</p> <p>The input stack values are:</p> <p>mu_s[0] = The address of the precompiled smart contract that is called. mu_s[1] = Pointer to memory for the input parameters. mu_s[2] = Length of the input parameters in bytes. mu_s[3] = Pointer to memory where the output is stored mu_s[4] = Length of the output buffer.</p> <p>The return will be 1 in case of success call and 0 in any of the next cases:</p> <p>1.- mu_s[0] is an address of an undefined precompiled smart contract. 2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example.</p> <p>Precompiled smart contracts, does not execute opcodes, so there is no need to pass a gas parameter as a normal <code>CALL</code> (<code>0xf1</code>). If the available gas is less that 2 plus the required gas required for the specific precompiled smart contract, the context just STOPS executing with an "Out of Gas" error.</p> <p>There is no stack check for this call.</p> <p>The normal <code>CALL</code>s to the precompiled smart contracts continue to work with the exact same behavior.</p> <p>A <code>PRECOMPILEDCALL</code> to a regular address or regular smart contract, is considered a call to an "undefined smart contract", so the VM MUST not execute it and the opcode must return 0x0 .</p> <h2 id="rationale">Rationale</h2> <p>There was a first proposal for removing the gast consts for the <code>CALL</code>, but it looks that it's easier to implement and test a new opcode just for that.</p> <p>The code is just the next opcode available after the <code>STATICCALL</code> opcode.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is backwards compatible. Smart contracts that call precompiled contracts using this new opcode will cost less from now on.</p> <p>Old contracts that call precompiled smart contracts with the <code>CALL</code> method, will continue working.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>Normal call to a defined precompiled contract.</li> <li>Call to undefined precompiled contract.</li> <li>Call to a regular contract</li> <li>Call to a regular account</li> <li>Call to 0x0 smart contract (Does not exists).</li> <li>Call with large values for the offste pointers and lengths</li> <li>Call with the exact gas remaining needed to call smart contract.</li> <li>Call with the exact gas remaining minus one needed to call smart contract.</li> </ul> <h2 id="implementation">Implementation</h2> <p>Not implemented yet.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-05-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Antonio Salazar Cardozohttps://github.com/shadowfiend Zachary Williamsonhttps://github.com/zac-williamson https://wg-eips.ritovision.com/1108/ <h2 id="simple-summary">Simple Summary</h2> <p>The elliptic curve arithmetic precompiles are currently overpriced. Re-pricing the precompiles would greatly assist a number of privacy solutions and scaling solutions on Ethereum.</p> <h2 id="abstract">Abstract</h2> <p>Changes in 2018 to the underlying library used by the official Go reference implementation led to significant performance gains for the <code>ECADD</code>, <code>ECMUL</code>, and pairing check precompiled contracts on the <code>alt_bn128</code> elliptic curve.</p> <p>In the Parity client, field operations used by the precompile algorithms were optimized in 2018, and recent changes to the pairing algorithm used by the <code>bn</code> crate have brought considerable speedups.</p> <p>Faster operations on Ethereum clients should be reflected in reduced gas costs.</p> <h2 id="motivation">Motivation</h2> <p>Recently, the underlying library used by the <a rel="external" href="https://github.com/ethereum/go-ethereum">official Go reference implementation</a> to implement the <code>ECADD</code> (at address <code>0x06</code>), <code>ECMUL</code> (at address <code>0x07</code>), and pairing check (at address <code>0x08</code>) precompiled contracts was shifted to <a rel="external" href="https://github.com/cloudflare/bn256">Cloudflare's bn256 library</a>. Based on the <a rel="external" href="https://github.com/ethereum/go-ethereum/pull/16203">initial PR that introduced this change</a>, and corroborated in <a rel="external" href="https://github.com/ethereum/go-ethereum/pull/16301#issuecomment-372687543">a later note</a>, the computational cost of <code>ECADD</code>, <code>ECMUL</code>, and pairing checks (excepting the constant) has dropped roughly an order of magnitude across the board.</p> <p>Also, optimizations in the bn library <a rel="external" href="https://github.com/paritytech/bn/pull/9">in 2018</a> and <a rel="external" href="https://github.com/paritytech/bn/pull/14">2019</a> used by the <a rel="external" href="https://github.com/paritytech/parity-ethereum">Parity client</a> led to a significant performance boost we <a rel="external" href="https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53">benchmarked</a> and compared against the <a rel="external" href="https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef">previous results</a>.</p> <h2 id="specification">Specification</h2> <p>Following is a table with the current gas cost and new gas cost:</p> <table><thead><tr><th>Contract</th><th>Address</th><th>Current Gas Cost</th><th>Updated Gas Cost</th></tr></thead><tbody> <tr><td><code>ECADD</code></td><td><code>0x06</code></td><td>500^[1]</td><td>150</td></tr> <tr><td><code>ECMUL</code></td><td><code>0x07</code></td><td>40 000^[1]</td><td>6 000</td></tr> <tr><td>Pairing check</td><td><code>0x08</code></td><td>80 000 * k + 100 000^[2]</td><td>34 000 * k + 45 000</td></tr> </tbody></table> <p>The gas costs for <code>ECADD</code> and <code>ECMUL</code> are updates to the costs listed in EIP-196, while the gas costs for the pairing check are updates to the cost listed in EIP-197. Updated gas costs have been adjusted to the less performant client which is Parity, according to benchmarks^[3].</p> <p>To come up with these updates gas costs, the performance of the <code>ecrecover</code> precompile was measured at 116 microseconds per <code>ecrecover</code> invocation. Assuming the <code>ecrecover</code> gas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile algorithm's runtime. With this in mind, the pairing precompile took 3,037 microseconds to compute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing algorithm has a fixed 'base' run-time of 1,745 microseconds, plus 1,292 microseconds per pairing. We can split the run-time into 'fixed cost' and 'linear cost per pairing' components because of the structure of the algorithm.</p> <p>Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of ~<code>35,000 * k + 45,000</code> gas, where <code>k</code> is the number of pairings being computed. [4]</p> <p>[1]- Per <a href="https://wg-eips.ritovision.com/196/">EIP-196</a>.</p> <p>[2]- Per <a href="https://wg-eips.ritovision.com/197/">EIP-197</a>.</p> <p>[3]- <a rel="external" href="https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53">Parity benchmarks.</a></p> <p>[4]- <a rel="external" href="https://github.com/ethereum/EIPs/pull/1987#discussion_r280977066">PR comment clarifying gas cost math</a>.</p> <h2 id="rationale">Rationale</h2> <h3 id="existing-protocols-would-benefit-immensely-from-cheaper-elliptic-curve-cryptography">Existing protocols would benefit immensely from cheaper elliptic curve cryptography</h3> <p>Fast elliptic curve cryptography is a keystone of a growing number of protocols built on top of Ethereum. To list a few:</p> <ul> <li><a rel="external" href="https://github.com/AztecProtocol/AZTEC">The AZTEC protocol</a> utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the <a rel="external" href="https://github.com/ethereum/EIPs/issues/1723">ERC-1723</a> and <a rel="external" href="https://github.com/ethereum/EIPs/issues/1724">ERC-1724</a> standard.</li> <li><a rel="external" href="https://github.com/matter-labs/matter-network">Matter Labs</a> utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second</li> <li><a rel="external" href="https://github.com/rollup/rollup">Rollup</a> utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer</li> <li>ZEther<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup> uses precompiles <code>ECADD</code> and <code>ECMUL</code> to construct confidential transactions</li> </ul> <p>To give a concrete example, it currently costs <code>820,000</code> gas to validate the cryptography in a typical AZTEC confidential transaction. If the gas schedule for the precompiles correctly reflected their load on the Ethereum network, this cost would be <code>197,000</code> gas. This significantly increases the potential use cases for private assets on Ethereum. AZTEC is planning to deploy several cryptographic protocols Ethereum, but these are at the limits of what is practical given the current precompile costs:</p> <ul> <li>Confidential weighted voting</li> <li>Partial-order filling over encrypted orders, for private decentralized exchanges</li> <li>Anonymous identity sharing proofs (e.g. proving you are on a whitelist, without revealing who you are)</li> <li>Many-to-one payments and one-to-many confidential payments, as encrypted communication channels between main-net and L2 applications</li> </ul> <p>For zk-SNARK based protocols on Ethereum, EIP-1108 will not only reduce the gas costs of verifying zk-SNARKs substantially, but can also aid in <a rel="external" href="https://github.com/matter-labs/Groth16BatchVerifier">batching together multiple zk-SNARK proofs</a>. This is also a technique that can be used to split up monolithic zk-SNARK circuits into a batch of zk-SNARKs with smaller individual circuit sizes, which makes zk-SNARKs both easier to construct and deploy.</p> <p>ZEther transactions currently cost ~<code>6,000,000</code> gas. This EIP would reduce this to ~<code>1,000,000</code> gas, which makes the protocol more practical.</p> <p>To summarise, there are several protocols that currently exist on main-net, that would benefit immensely from this EIP. Elliptic curve cryptography can provide valuable solutions for Ethereum, such as scaling and privacy, and the scope and scale of these solutions can be increased if the gas costs for the <code>bn128</code> precompiles accurately reflects their computational load on the network.</p> <h3 id="cheaper-elliptic-curve-cryptography-can-be-used-to-trade-storage-for-computation">Cheaper elliptic curve cryptography can be used to trade storage for computation</h3> <p>Solutions such as Rollup and Ignis can be used to batch groups of individual transactions into a zk-SNARK proof, with the on-chain state being represented by a small Merkle root, instead of multiple account balances.</p> <p>If zk-SNARK verification costs are decreased, these solutions can be deployed for a wider range of use cases and more Rollup-style transactions can be processed per block.</p> <h3 id="parity-and-geth-already-have-fast-algorithms-that-justify-reduced-gas-costs">Parity and Geth already have fast algorithms that justify reduced gas costs</h3> <p>This EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement <a href="https://wg-eips.ritovision.com/1829/">EIP-1829</a> (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed.</p> <h2 id="test-cases">Test Cases</h2> <p>As no underlying algorithms are being changed, there are no additional test cases to specify.</p> <h2 id="implementation">Implementation</h2> <p>Both the Parity and Geth clients have already implemented cryptographic libraries that are fast enough to justify reducing the precompile gas costs. As a reference, here are a list of elliptic curve libraries, in <code>C++</code>, <code>golang</code> and <code>rust</code>, that support the <code>bn128</code> curve, and have run-times that are equal to or faster than the Parity benchmarks.</p> <ul> <li><a rel="external" href="https://github.com/paritytech/bn">Parity bn crate (rust)</a></li> <li><a rel="external" href="https://github.com/ethereum/go-ethereum/tree/master/crypto/bn256/cloudflare">Geth bn256 library (golang)</a></li> <li><a rel="external" href="https://github.com/herumi/mcl">MCL, a portable C++ pairing library</a></li> <li><a rel="external" href="https://github.com/scipr-lab/libff">Libff, a C++ pairing library used in many zk-SNARK libraries</a></li> </ul> <h2 id="additional-references">Additional References</h2> <p>@vbuterin independently proposed a similar reduction after this EIP was originally created, with similar rationale, as <a rel="external" href="https://github.com/ethereum/EIPs/issues/1187">ethereum/EIPs#1187</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-1"> <p>Bünz, B., Agrawal, S., Zamani, M., &amp; Boneh, D. (2020). Zether: Towards Privacy in a Smart Contract World. In J. Bonneau &amp; N. Heninger (Eds.), <span style="font-style: italic;">Financial Cryptography and Data Security</span>. https://doi.org/<a href="https://doi.org/10.1007/978-3-030-51280-4_23">10.1007/978-3-030-51280-4_23</a>These are all technologies that have been, or are in the process of being, deployed to main-net. These protocols would all benefit from reducing the gas cost of the precompiles. <a href="#fr-1-1">↩</a></p> </li> </ol> </section> 2018-05-17T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonhttps://github.com/arachnid https://wg-eips.ritovision.com/1087/ <h2 id="abstract">Abstract</h2> <p>This EIP proposes a change to how gas is charged for EVM <code>SSTORE</code> operations, in order to reduce excessive gas costs in situations where these are unwarranted, and to enable new use-cases for contract storage.</p> <h2 id="motivation">Motivation</h2> <p>Presently, <code>SSTORE</code> (<code>0x55</code>) operations are charged as follows:</p> <ul> <li>20,000 gas to set a slot from 0 to non-0</li> <li>5,000 gas for any other change</li> <li>A 10,000 gas refund when a slot is set from non-0 to 0. Refunds are applied at the end of the transaction.</li> </ul> <p>In situations where a single update is made to a storage value in a transaction, these gas costs have been determined to fairly reflect the resources consumed by the operation. However, this results in excessive gas costs for sequences of operations that make multiple updates.</p> <p>Some examples to illustrate the problem:</p> <ul> <li>If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged <code>20000 + 5000 - 10000 = 15000</code> gas, despite this sequence of operations not requiring any disk writes.</li> <li>A contract with empty storage that increments slot 0 5 times will be charged <code>20000 + 5 * 5000 = 45000</code> gas, despite this sequence of operations requiring no more disk activity than a single write, charged at 20000 gas.</li> <li>A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, will cost <code>5000 * 4 = 20000</code> gas.</li> </ul> <p>Addressing this issue would also enable new use-cases that are currently cost-prohibitive, where a sequence of operations results in no net change to storage at the end of the transaction. For instance, mutexes to prevent reentrancy, or context information passed between multiple calls to the same contract. One such example is an <code>approveAndCall</code> operation, which would permit sending to and calling a contract in a single transaction, without that contract having to be updated for a new token standard.</p> <h2 id="specification">Specification</h2> <p>The following changes are made to the EVM:</p> <ul> <li>A 'dirty map' for each transaction is maintained, tracking all storage slots in all contracts that have been modified in the current transaction. The dirty map is scoped in the same manner as updates to storage, meaning that changes to the dirty map in a call that later reverts are not retained.</li> <li>When a storage slot is written to with the value it already contains, 200 gas is deducted.</li> <li>When a storage slot's value is changed for the first time, the slot is marked as dirty. If the slot was previously set to 0, 20000 gas is deducted; otherwise, 5000 gas is deducted.</li> <li>When a storage slot that is already in the dirty map is written to, 200 gas is deducted.</li> <li>At the end of the transaction, for each slot in the dirty map: <ul> <li>If the slot was 0 before the transaction and is 0 now, refund 19800 gas.</li> <li>If the slot was nonzero before the transaction and its value has not changed, refund 4800 gas.</li> <li>If the slot was nonzero before the transaction and is 0 now, refund 15000 gas.</li> </ul> </li> </ul> <p>After these changes, transactions that make only a single change to a storage slot will retain their existing costs. However, contracts that make multiple changes will see significantly reduced costs. Repeating the examples from the Motivation section:</p> <ul> <li>If a contract with empty storage sets slot 0 to 1, then back to 0, it will be charged <code>20000 + 200 - 19800 = 400</code> gas, down from 15000.</li> <li>A contract with empty storage that increments slot 0 5 times will be charged <code>20000 + 5 * 200 = 21000</code> gas, down from 45000.</li> <li>A balance transfer from account A to account B followed by a transfer from B to C, with all accounts having nonzero starting and ending balances, will cost <code>5000 * 3 + 200 - 4800 = 10400</code> gas, down from 20000.</li> </ul> <h2 id="rationale">Rationale</h2> <p>We believe the proposed mechanism represents the simplest way to reduce storage gas costs in situations where they do not reflect the actual costs borne by nodes. Several alternative designs were considered and dismissed:</p> <ul> <li>Charging a flat 200 gas for <code>SSTORE</code> operations, and an additional 19800 / 4800 at the end of a transaction for new or modified values is simpler, and removes the need for a dirty map, but pushes a significant source of gas consumption out of the EVM stack and applies it at the end of the transaction, which is likely to complicate debugging and reduces contracts' ability to limit the gas consumption of callees, as well as introducing a new mechanism to the EVM.</li> <li>Keeping a separate refund counter for storage gas refunds would avoid the issue of refunds being limited to half the gas consumed (not necessary here), but would introduce additional complexity in tracking this value.</li> <li>Refunding gas each time a storage slot is set back to its initial value would introduce a new mechanism (instant refunds) and complicate gas accounting for contracts calling other contracts; it would also permit the possibility of a contract call with negative execution cost.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP requires a hard fork to implement.</p> <p>No contract should see an increase in gas cost for this change, and many will see decreased gas consumption, so no contract-layer backwards compatibility issues are anticipated.</p> <h2 id="test-cases">Test Cases</h2> <ul> <li>Writing x to a storage slot that contains 0, where x != 0 (20k gas, no refund)</li> <li>Writing y to a storage slot that contained x, where x != y and x != 0 (5k gas, no refund)</li> <li>Writing 0 to a storage slot that contains x, where x != 0 (5k gas, 10k refund)</li> <li>Writing 0 to a storage slot that already contains zero (200 gas, no refund)</li> <li>Writing x to a storage slot that already contains x, where x != 0 (200 gas, no refund)</li> <li>Writing x, then y to a storage slot that contains 0, where x != y (20200 gas, no refund)</li> <li>Writing x, then y to a storage slot that contains 0, where x != y != z and x != 0 (5200 gas, no refund)</li> <li>Writing x, then 0 to a storage slot that contains 0, where x != 0 (20200 gas, 19800 refund)</li> <li>Writing x, then y to a storage slot that contains y, where x != y != 0 (5200 gas, 4800 refund)</li> <li>Writing x, then 0 to a storage slot that contains 0, then reverting the stack frame in which the writes occurred (20200 gas, no refund)</li> <li>Writing x, then y to a storage slot that contains y, then reverting the stack frame in which the writes occurred (5200 gas, no refund)</li> <li>In a nested frame, writing x to a storage slot that contains 0, then returning, and writing 0 to that slot (20200 gas, 19800 refund)</li> </ul> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-05-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonarachnid@notdot.net https://wg-eips.ritovision.com/1051/ <h2 id="abstract">Abstract</h2> <p>This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags.</p> <h2 id="motivation">Motivation</h2> <p>The correct functioning of many contracts today is dependent on detecting and preventing overflow of arithmetic operations. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation.</p> <p>In the interests of facilitating efficient and secure contracts, we propose new opcodes that permit efficient detection of overflows, which can be checked periodically rather than after each operation.</p> <h2 id="specification">Specification</h2> <p>Two new flags are added to the EVM state: overflow (<code>ovf</code>) and signed overflow (<code>sovf</code>).</p> <p>The <code>ovf</code> flag is set in the following circumstances:</p> <ul> <li>When an <code>ADD</code> (<code>0x01</code>) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.</li> <li>When a <code>SUB</code> (<code>0x03</code>) opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0.</li> <li>When a <code>MUL</code> (<code>0x02</code>) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.</li> </ul> <p>The <code>sovf</code> flag is set whenever the <code>ovf</code> flag is set, and additionally in the following circumstances:</p> <ul> <li>When an <code>ADD</code> opcode with both inputs having the same MSB results in the output having a different MSB (eg, <code>(+a) + (+b) = (-c)</code> or <code>(-a) + (-b) = (+c)</code>).</li> <li>When a <code>SUB</code> opcode occurs and the result has the same MSB as the subtracted (second argument) (eg, <code>(+a) - (-b) = (-c)</code> or <code>(-a) - (+b) = (+c)</code>).</li> <li>When a <code>MUL</code> opcode with both inputs being positive has a negative output.</li> <li>When a <code>MUL</code> opcode with both inputs being negative has a negative output.</li> <li>When a <code>MUL</code> opcode with one negative input and one positive input has a positive output.</li> </ul> <p>A new opcode, <code>OFV</code> is added, with number <code>0x0c</code>. This opcode takes 0 arguments from the stack. When executed, it pushes <code>1</code> if the <code>ovf</code> flag is set, and <code>0</code> otherwise. It then sets the <code>ovf</code> flag to false.</p> <p>A new opcode, <code>SOVF</code> is added, with number <code>0x0d</code>. This opcode takes 0 arguments from the stack. When executed, it pushes <code>1</code> if the <code>sovf</code> flag is set, and <code>0</code> otherwise. It then sets the <code>sovf</code> flag to false.</p> <h2 id="rationale">Rationale</h2> <p>Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled.</p> <p>Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags.</p> <p>Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP introduces no backwards compatibility issues.</p> <h2 id="test-cases">Test Cases</h2> <p>TBD</p> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-05-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonarachnid@notdot.net Paweł Bylicapawel@ethereum.org https://wg-eips.ritovision.com/1052/ <h2 id="abstract">Abstract</h2> <p>This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.</p> <h2 id="motivation">Motivation</h2> <p>Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.</p> <p>Contracts can presently do this using the <code>EXTCODECOPY</code> (<code>0x3c</code>) opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, <code>EXTCODEHASH</code>, which returns the keccak256 hash of a contract's bytecode.</p> <h2 id="specification">Specification</h2> <p>A new opcode, <code>EXTCODEHASH</code>, is introduced, with number <code>0x3f</code>. The <code>EXTCODEHASH</code> takes one argument from the stack, zeros the first 96 bits and pushes to the stack the keccak256 hash of the code of the account at the address being the remaining 160 bits.</p> <p>In case the account does not exist or is empty (as defined by <a href="https://wg-eips.ritovision.com/161/">EIP-161</a>) <code>0</code> is pushed to the stack.</p> <p>In case the account does not have code the keccak256 hash of empty data (i.e. <code>c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code>) is pushed to the stack.</p> <p>The gas cost of the <code>EXTCODEHASH</code> is 400.</p> <h2 id="rationale">Rationale</h2> <p>As described in the motivation section, this opcode is widely useful, and saves on wasted gas in many cases.</p> <p>The gas cost is the same as the gas cost for the <code>BALANCE</code> opcode because the execution of the <code>EXTCODEHASH</code> requires the same account lookup as in <code>BALANCE</code>.</p> <p>Only the 20 last bytes of the argument are significant (the first 12 bytes are ignored) similarly to the semantics of the <code>BALANCE</code> (<code>0x31</code>), <code>EXTCODESIZE</code> (<code>0x3b</code>) and <code>EXTCODECOPY</code> (<code>0x3c</code>).</p> <p>The <code>EXTCODEHASH</code> distinguishes accounts without code and non-existing accounts. This is consistent with the way accounts are represented in the state trie. This also allows smart contracts to check whether an account exists.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There are no backwards compatibility concerns.</p> <h2 id="test-cases">Test Cases</h2> <ol> <li>The <code>EXTCODEHASH</code> of the account without code is <code>c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code> what is the keccak256 hash of empty data.</li> <li>The <code>EXTCODEHASH</code> of non-existent account is <code>0</code>.</li> <li>The <code>EXTCODEHASH</code> of a precompiled contract is either <code>c5d246...</code> or <code>0</code>.</li> <li>If <code>EXTCODEHASH</code> of <code>A</code> is <code>X</code>, then <code>EXTCODEHASH</code> of <code>A + 2**160</code> is <code>X</code>.</li> <li>The <code>EXTCODEHASH</code> of an account that selfdestructed in the current transaction.</li> <li>The <code>EXTCODEHASH</code> of an account that selfdestructed and later the selfdestruct has been reverted.</li> <li>The <code>EXTCODEHASH</code> of an account created in the current transaction.</li> <li>The <code>EXTCODEHASH</code> of an account that has been newly created and later the creation has been reverted.</li> <li>The <code>EXTCODEHASH</code> of an account that firstly does not exist and later is empty.</li> <li>The <code>EXTCODEHASH</code> of an empty account that is going to be cleared by the state clearing rule.</li> </ol> <h2 id="implementation">Implementation</h2> <p>TBD</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-05-02T00:00:00+00:00 2026-02-11T14:49:28+00:00 Greg Colvingreg@colvin.org Andrea Lanfranchihttps://github.com/AndreaLanfranchi Michael Carterhttps://github.com/bitsbetrippin IfDefElseifdefelse@protonmail.com https://wg-eips.ritovision.com/1057/ <h2 id="simple-summary">Simple Summary</h2> <p>A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts of commodity GPUs.</p> <h2 id="abstract">Abstract</h2> <p>ProgPoW is a proof-of-work algorithm designed to close the efficiency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network.</p> <p>This document presents an overview of the algorithm and examines what it means to be “ASIC-resistant.” Next, we compare existing PoW designs by analyzing how each algorithm executes in hardware. Finally, we present the detailed implementation by walking through the code.</p> <h2 id="motivation">Motivation</h2> <p>Ever since the first bitcoin mining ASIC was released, many new Proof of Work algorithms have been created with the intention of being “ASIC-resistant”. The goal of “ASIC-resistance” is to resist the centralization of PoW mining power such that these coins couldn’t be so easily manipulated by a few players.</p> <p>Ethereum's approach is to incentivize a geographically-distributed community of miners with a low barrier to entry on commodity hardware. As stated in the <a rel="external" href="https://ethereum.github.io/yellowpaper/paper.pdf">Yellow Paper</a>:</p> <blockquote> <p>11.5. Mining Proof-of-Work. The mining proof-ofwork (PoW) exists as a cryptographically secure nonce that proves beyond reasonable doubt that a particular amount of computation has been expended in the determination of some token value n. It is utilised to enforce the blockchain security by giving meaning and credence to the notion of difficulty (and, by extension, total difficulty). However, since mining new blocks comes with an attached reward, the proof-of-work not only functions as a method of securing confidence that the blockchain will remain canonical into the future, but also as a wealth distribution mechanism.</p> </blockquote> <blockquote> <p>For both reasons, there are two important goals of the proof-of-work function; firstly, it should be as accessible as possible to as many people as possible. The requirement of, or reward from, specialised and uncommon hardware should be minimised. This makes the distribution model as open as possible, and, ideally, makes the act of mining a simple swap from electricity to Ether at roughly the same rate for anyone around the world.</p> </blockquote> <blockquote> <p>Secondly, it should not be possible to make super-linear profits, and especially not so with a high initial barrier. Such a mechanism allows a well-funded adversary to gain a troublesome amount of the network’s total mining power and as such gives them a super-linear reward (thus skewing distribution in their favour) as well as reducing the network security...</p> </blockquote> <blockquote> <p>... While ASICs exist for a proof-of-work function, both goals are placed in jeopardy. Because of this, a proof-of-work function that is ASIC-resistant (i.e. difficult or economically inefficient to implement in specialised compute hardware) has been identified as the proverbial silver bullet.</p> </blockquote> <p>It is from these premises that Ethash was designed as an ASIC-resistant proof-of-work:</p> <blockquote> <p>Two directions exist for ASIC resistance; firstly make it sequential memory-hard, i.e. engineer the function such that the determination of the nonce requires a lot of memory and bandwidth such that the memory cannot be used in parallel to discover multiple nonces simultaneously. The second is to make the type of computation it would need to do general-purpose; the meaning of “specialised hardware” for a general-purpose task set is, naturally, general purpose hardware and as such commodity desktop computers are likely to be pretty close to “specialised hardware” for the task. For Ethereum 1.0 we have chosen the first path.</p> </blockquote> <p>5 years of experience with the Ethereum blockchain have demonstrated the success of our approach. This success cannot be taken for granted.</p> <ul> <li>11 years of experience with PoW Blockchains have shown a centralization in hardware development, resulting in a <a rel="external" href="https://www.asicminervalue.com/">few companies</a> controlling the lifecycle of new hardware with limited distribution.</li> <li>New ASICs for Ethash are providing higher efficiency than GPUs, such as the <a rel="external" href="https://shop.bitmain.com/product/detail?pid=00020181031134626816gh0zYNKC06A3">Antminer E3</a>.</li> <li>As much as 40% of the Ethereum network may now be secured by ASICs.</li> </ul> <p>ProgPow restores Ethash' ASIC-resistance by extending Ethash with a GPU-specific approach to the second path — making the “specialised hardware” for the PoW task commodity hardware.</p> <h3 id="progpow-overview">ProgPoW Overview</h3> <p>The design goal of ProgPoW is to have the algorithm’s requirements match what is available on commodity GPUs: If the algorithm were to be implemented on a custom ASIC there should be little opportunity for efficiency gains compared to a commodity GPU.</p> <p>The main elements of the algorithm are:</p> <ul> <li>Changes keccak_f1600 (with 64-bit words) to keccak_f800 (with 32-bit words) to reduce impact on total power</li> <li>Increases mix state.</li> <li>Adds a random sequence of math in the main loop.</li> <li>Adds reads from a small, low-latency cache that supports random addresses.</li> <li>Increases the DRAM read from 128 bytes to 256 bytes.</li> </ul> <p>The random sequence changes every <code>PROGPOW_PERIOD</code> (about 2 to 12 minutes depending on the configured value). When mining source code is generated for the random sequence and compiled on the host CPU. The GPU will execute the compiled code where what math to perform and what mix state to use are already resolved.</p> <p>While a custom ASIC to implement this algorithm is still possible, the efficiency gains available are minimal. The majority of a commodity GPU is required to support the above elements. The only optimizations available are:</p> <ul> <li>Remove the graphics pipeline (displays, geometry engines, texturing, etc)</li> <li>Remove floating point math</li> <li>A few ISA tweaks, like instructions that exactly match the merge() function</li> </ul> <p>These would result in minimal, roughly 1.1-1.2x, efficiency gains. This is much less than the 2x for Ethash or 50x for Cryptonight.</p> <h3 id="rationale-for-pow-on-commodity-hardware">Rationale for PoW on Commodity Hardware</h3> <p>With the growth of large mining pools, the control of hashing power has been delegated to the top few pools to provide a steadier economic return for small miners. While some have made the argument that large centralized pools defeats the purpose of “ASIC resistance,” it’s important to note that ASIC based coins are even more centralized for several reasons.</p> <ol> <li>No natural distribution: There isn’t an economic purpose for ultra-specialized hardware outside of mining and thus no reason for most people to have it.</li> <li>No reserve group: Thus, there’s no reserve pool of hardware or reserve pool of interested parties to jump in when coin price is volatile and attractive for manipulation.</li> <li>High barrier to entry: Initial miners are those rich enough to invest capital and ecological resources on the unknown experiment a new coin may be. Thus, initial coin distribution through mining will be very limited causing centralized economic bias.</li> <li>Delegated centralization vs implementation centralization: While pool centralization is delegated, hardware monoculture is not: only the limited buyers of this hardware can participate so there isn’t even the possibility of divesting control on short notice.</li> <li>No obvious decentralization of control even with decentralized mining: Once large custom ASIC makers get into the game, designing back-doored hardware is trivial. ASIC makers have no incentive to be transparent or fair in market participation.</li> </ol> <p>While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy. CPUs and GPUs are themselves ASICs. Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicated mining ASIC company as soon as it becomes useful.</p> <p>Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack.</p> <h3 id="review-of-existing-pow-algorithms">Review of Existing PoW Algorithms</h3> <h4 id="sha256">SHA256</h4> <ul> <li>Potential ASIC efficiency gain ~ 1000X</li> </ul> <p>The SHA algorithm is a sequence of simple math operations - additions, logical ops, and rotates.</p> <p>To process a single op on a CPU or GPU requires fetching and decoding an instruction, reading data from a register file, executing the instruction, and then writing the result back to a register file. This takes significant time and power.</p> <p>A single op implemented in an ASIC takes a handful of transistors and wires. This means every individual op takes negligible power, area, or time. A hashing core is built by laying out the sequence of required ops.</p> <p>The hashing core can execute the required sequence of ops in much less time, and using less power or area, than doing the same sequence on a CPU or GPU. A bitcoin ASIC consists of a number of identical hashing cores and some minimal off-chip communication.</p> <h4 id="scrypt-and-neoscrypt">Scrypt and NeoScrypt</h4> <ul> <li>Potential ASIC efficiency gain ~ 1000X</li> </ul> <p>Scrypt and NeoScrypt are similar to SHA in the arithmetic and bitwise operations used. Unfortunately, popular coins such as Litecoin only use a scratchpad size between 32kb and 128kb for their PoW mining algorithm. This scratch pad is small enough to trivially fit on an ASIC next to the math core. The implementation of the math core would be very similar to SHA, with similar efficiency gains.</p> <h4 id="x11-and-x16r">X11 and X16R</h4> <ul> <li>Potential ASIC efficiency gain ~ 1000X</li> </ul> <p>X11 (and similar X##) require an ASIC that has 11 unique hashing cores pipelined in a fixed sequence. Each individual hashing core would have similar efficiency to an individual SHA core, so the overall design will have the same efficiency gains.</p> <p>X16R requires the multiple hashing cores to interact through a simple sequencing state machine. Each individual core will have similar efficiency gains and the sequencing logic will take minimal power, area, or time.</p> <p>The Baikal BK-X is an existing ASIC with multiple hashing cores and a programmable sequencer. It has been upgraded to enable new algorithms that sequence the hashes in different orders.</p> <h4 id="equihash">Equihash</h4> <ul> <li>Potential ASIC efficiency gain ~ 100X</li> </ul> <p>The ~150mb of state is large but possible on an ASIC. The binning, sorting, and comparing of bit strings could be implemented on an ASIC at extremely high speed.</p> <h4 id="cuckoo-cycle">Cuckoo Cycle</h4> <ul> <li>Potential ASIC efficiency gain ~ 100X</li> </ul> <p>The amount of state required on-chip is not clear as there are Time/Memory Tradeoff attacks. A specialized graph traversal core would have similar efficiency gains to a SHA compute core.</p> <h4 id="cryptonight">CryptoNight</h4> <ul> <li>Potential ASIC efficiency gain ~ 50X</li> </ul> <p>Compared to Scrypt, CryptoNight does much less compute and requires a full 2mb of scratch pad (there is no known Time/Memory Tradeoff attack). The large scratch pad will dominate the ASIC implementation and limit the number of hashing cores, limiting the absolute performance of the ASIC. An ASIC will consist almost entirely of just on-die SRAM.</p> <h4 id="ethash">Ethash</h4> <ul> <li>Potential ASIC efficiency gain ~ 2X</li> </ul> <p>Ethash requires external memory due to the large size of the DAG. However that is all that it requires - there is minimal compute that is done on the result loaded from memory. As a result a custom ASIC could remove most of the complexity, and power, of a GPU and be just a memory interface connected to a small compute engine.</p> <h2 id="specification">Specification</h2> <p>ProgPoW can be tuned using the following parameters. The proposed settings have been tuned for a range of existing, commodity GPUs:</p> <ul> <li><code>PROGPOW_PERIOD</code>: Number of blocks before changing the random program</li> <li><code>PROGPOW_LANES</code>: The number of parallel lanes that coordinate to calculate a single hash instance</li> <li><code>PROGPOW_REGS</code>: The register file usage size</li> <li><code>PROGPOW_DAG_LOADS</code>: Number of uint32 loads from the DAG per lane</li> <li><code>PROGPOW_CACHE_BYTES</code>: The size of the cache</li> <li><code>PROGPOW_CNT_DAG</code>: The number of DAG accesses, defined as the outer loop of the algorithm (64 is the same as Ethash)</li> <li><code>PROGPOW_CNT_CACHE</code>: The number of cache accesses per loop</li> <li><code>PROGPOW_CNT_MATH</code>: The number of math operations per loop</li> </ul> <p>The values of these parameters have been tweaked between the original version and the version proposed here for Ethereum adoption. See <a rel="external" href="https://medium.com/@ifdefelse/progpow-progress-da5bb31a651b">this medium post</a> for details.</p> <table><thead><tr><th>Parameter</th><th>0.9.2</th><th>0.9.3</th></tr></thead><tbody> <tr><td><code>PROGPOW_PERIOD</code></td><td><code>50</code></td><td><code>10</code></td></tr> <tr><td><code>PROGPOW_LANES</code></td><td><code>16</code></td><td><code>16</code></td></tr> <tr><td><code>PROGPOW_REGS</code></td><td><code>32</code></td><td><code>32</code></td></tr> <tr><td><code>PROGPOW_DAG_LOADS</code></td><td><code>4</code></td><td><code>4</code></td></tr> <tr><td><code>PROGPOW_CACHE_BYTES</code></td><td><code>16x1024</code></td><td><code>16x1024</code></td></tr> <tr><td><code>PROGPOW_CNT_DAG</code></td><td><code>64</code></td><td><code>64</code></td></tr> <tr><td><code>PROGPOW_CNT_CACHE</code></td><td><code>12</code></td><td><code>11</code></td></tr> <tr><td><code>PROGPOW_CNT_MATH</code></td><td><code>20</code></td><td><code>18</code></td></tr> </tbody></table> <table><thead><tr><th>DAG Parameter</th><th>0.9.2</th><th>0.9.3</th></tr></thead><tbody> <tr><td><code>ETHASH_DATASET_PARENTS</code></td><td><code>256</code></td><td><code>256</code></td></tr> </tbody></table> <p>The random program changes every <code>PROGPOW_PERIOD</code> blocks (default <code>10</code>, roughly 2 minutes) to ensure the hardware executing the algorithm is fully programmable. If the program only changed every DAG epoch (roughly 5 days) certain miners could have time to develop hand-optimized versions of the random sequence, giving them an undue advantage.</p> <p>Sample code is written in C++, this should be kept in mind when evaluating the code in the specification. All numerics are computed using unsigned 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lengths (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures.</p> <p>ProgPoW uses a 32-bit variant of <strong>FNV1a</strong> for merging data. The existing Ethash uses a similar variant of FNV1 for merging, but FNV1a provides better distribution properties.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#fnv1a">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-storage">const</span><span class="z-storage z-type"> uint32_t</span><span> FNV_PRIME </span><span class="z-keyword">=</span><span class="z-keyword"> 0x</span><span class="z-constant">1000193</span><span>;</span></span> <span class="giallo-l"><span class="z-storage">const</span><span class="z-storage z-type"> uint32_t</span><span> FNV_OFFSET_BASIS </span><span class="z-keyword">=</span><span class="z-keyword"> 0x</span><span class="z-constant">811c9dc5</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">uint32_t</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-variable"> h</span><span>,</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> d</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>h </span><span class="z-keyword">^</span><span> d</span><span>)</span><span class="z-keyword"> *</span><span> FNV_PRIME</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>ProgPow uses <a rel="external" href="https://en.wikipedia.org/wiki/KISS_(algorithm)">KISS99</a> for random number generation. This is the simplest (fewest instruction) random generator that passes the TestU01 statistical test suite. A more complex random number generator like Mersenne Twister can be efficiently implemented on a specialized ASIC, providing an opportunity for efficiency gains.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#kiss99">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-keyword">typedef</span><span class="z-storage z-type"> struct</span><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> z</span><span>,</span><span> w</span><span>,</span><span> jsr</span><span>,</span><span> jcong</span><span>;</span></span> <span class="giallo-l"><span>}</span><span class="z-entity z-name"> kiss99_t</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> KISS99 is simple, fast, and passes the TestU01 suite</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> https://en.wikipedia.org/wiki/KISS_(algorithm)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> http://www.cse.yorku.ca/~oz/marsaglia-rng.html</span></span> <span class="giallo-l"><span class="z-storage z-type">uint32_t</span><span class="z-entity z-name"> kiss99</span><span>(</span><span class="z-support">kiss99_t</span><span class="z-storage"> &amp;</span><span class="z-variable">st</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> =</span><span class="z-constant"> 36969</span><span class="z-keyword"> *</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> &amp;</span><span class="z-constant"> 65535</span><span>)</span><span class="z-keyword"> +</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> &gt;&gt;</span><span class="z-constant"> 16</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">w</span><span class="z-keyword"> =</span><span class="z-constant"> 18000</span><span class="z-keyword"> *</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">w</span><span class="z-keyword"> &amp;</span><span class="z-constant"> 65535</span><span>)</span><span class="z-keyword"> +</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">w</span><span class="z-keyword"> &gt;&gt;</span><span class="z-constant"> 16</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> MWC </span><span class="z-keyword">=</span><span> (</span><span>(</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 16</span><span>)</span><span class="z-keyword"> +</span><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">w</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> ^=</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 17</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> ^=</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> &gt;&gt;</span><span class="z-constant"> 13</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> ^=</span><span> (</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 5</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jcong</span><span class="z-keyword"> =</span><span class="z-constant"> 69069</span><span class="z-keyword"> *</span><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jcong</span><span class="z-keyword"> +</span><span class="z-constant"> 1234567</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> (</span><span>(</span><span>MWC</span><span class="z-keyword">^</span><span class="z-variable z-other">st</span><span>.</span><span class="z-variable z-other">jcong</span><span>)</span><span class="z-keyword"> +</span><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jsr</span><span>)</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The <code>fill_mix</code> function populates an array of <code>int32</code> values used by each lane in the hash calculations.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#fill-mix">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-storage z-type">void</span><span class="z-entity z-name"> fill_mix</span><span>(</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint64_t</span><span class="z-variable"> seed</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> lane_id</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> mix</span><span>[</span><span>PROGPOW_REGS</span><span>]</span></span> <span class="giallo-l"><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Use FNV to expand the per-warp seed to per-lane</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Use KISS to expand the per-lane seed to fill mix</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> fnv_hash </span><span class="z-keyword">=</span><span> FNV_OFFSET_BASIS</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> kiss99_t</span><span> st</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span>fnv_hash</span><span>,</span><span> seed</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">w</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span>fnv_hash</span><span>,</span><span> seed </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 32</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span>fnv_hash</span><span>,</span><span> lane_id</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> st</span><span>.</span><span class="z-variable z-other">jcong</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span>fnv_hash</span><span>,</span><span> lane_id</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_REGS</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>st</span><span>)</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>Like Ethash Keccak is used to seed the sequence per-nonce and to produce the final result. The keccak-f800 variant is used as the 32-bit word size matches the native word size of modern GPUs. The implementation is a variant of SHAKE with width=800, bitrate=576, capacity=224, output=256, and no padding. The result of keccak is treated as a 256-bit big-endian number - that is result byte 0 is the MSB of the value.</p> <p>As with Ethash the input and output of the keccak function are fixed and relatively small. This means only a single "absorb" and "squeeze" phase are required. For a pseudo-code implementation of the <code>keccak_f800_round</code> function see the <code>Round[b](A,RC)</code> function in the "Pseudo-code description of the permutations" section of the <a rel="external" href="https://keccak.team/keccak_specs_summary.html">official Keccak specs</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-support">hash32_t</span><span class="z-entity z-name"> keccak_f800_progpow</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-storage">*</span><span class="z-variable"> state</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> keccak_f800 call for the single absorb pass</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> r </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> r </span><span class="z-keyword">&lt;</span><span class="z-constant"> 22</span><span>;</span><span> r</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name"> keccak_f800_round</span><span>(</span><span>st</span><span>,</span><span> r</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Squeeze phase for fixed 8 words of output</span></span> <span class="giallo-l"><span class="z-support"> hash32_t</span><span> ret</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i</span><span class="z-keyword">=</span><span class="z-constant">0</span><span>;</span><span> i</span><span class="z-keyword">&lt;</span><span class="z-constant">8</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> ret</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> st</span><span>[</span><span>i</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> ret</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The inner loop uses FNV and KISS99 to generate a random sequence from the <code>prog_seed</code>. This random sequence determines which mix state is accessed and what random math is performed.</p> <p>Since the <code>prog_seed</code> changes only once per <code>PROGPOW_PERIOD</code> (10 blocks or about 2 minutes) it is expected that while mining <code>progPowLoop</code> will be evaluated on the CPU to generate source code for that period's sequence. The source code will be compiled on the CPU before running on the GPU. You can see an example sequence and generated source code in <a rel="external" href="https://github.com/ifdefelse/ProgPOW/blob/824cd791634204c4cc7e31f84bb76c0c84895bd3/test/kernel.cu">kernel.cu</a>.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#progpowinit">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-support">kiss99_t</span><span class="z-entity z-name"> progPowInit</span><span>(</span><span class="z-storage z-type">uint64_t</span><span class="z-variable"> prog_seed</span><span>,</span><span class="z-storage z-type"> int</span><span class="z-variable"> mix_seq_dst</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>,</span><span class="z-storage z-type"> int</span><span class="z-variable"> mix_seq_src</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> kiss99_t</span><span> prog_rnd</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> prog_rnd</span><span>.</span><span class="z-variable z-other">z</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span>FNV_OFFSET_BASIS</span><span>,</span><span> prog_seed</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> prog_rnd</span><span>.</span><span class="z-variable z-other">w</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-other">prog_rnd</span><span>.</span><span class="z-variable z-other">z</span><span>,</span><span> prog_seed </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 32</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> prog_rnd</span><span>.</span><span class="z-variable z-other">jsr</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-other">prog_rnd</span><span>.</span><span class="z-variable z-other">w</span><span>,</span><span> prog_seed</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> prog_rnd</span><span>.</span><span class="z-variable z-other">jcong</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-other">prog_rnd</span><span>.</span><span class="z-variable z-other">jsr</span><span>,</span><span> prog_seed </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 32</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Create a random sequence of mix destinations for merge() and mix sources for cache reads</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> guarantees every destination merged once</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> guarantees no duplicate cache reads, which could be optimized away</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Uses Fisher-Yates shuffle</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_REGS</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span> i</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix_seq_src</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span> i</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span> PROGPOW_REGS </span><span class="z-keyword">-</span><span class="z-constant"> 1</span><span>;</span><span> i </span><span class="z-keyword">&gt;</span><span class="z-constant"> 0</span><span>;</span><span> i</span><span class="z-keyword">--</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> j</span><span>;</span></span> <span class="giallo-l"><span> j </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span>i </span><span class="z-keyword">+</span><span class="z-constant"> 1</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name"> swap</span><span>(</span><span class="z-variable z-other">mix_seq_dst</span><span>[</span><span>i</span><span>]</span><span>,</span><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>j</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> j </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span>i </span><span class="z-keyword">+</span><span class="z-constant"> 1</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name"> swap</span><span>(</span><span class="z-variable z-other">mix_seq_src</span><span>[</span><span>i</span><span>]</span><span>,</span><span class="z-variable z-other"> mix_seq_src</span><span>[</span><span>j</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> prog_rnd</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The math operations that merges values into the mix data are ones chosen to maintain entropy.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#math">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> Merge new data from b into the value in a</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> Assuming A has high entropy only do ops that retain entropy</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> even if B is low entropy</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> (IE don&#39;t do A&amp;B)</span></span> <span class="giallo-l"><span class="z-storage z-type">uint32_t</span><span class="z-entity z-name"> merge</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-variable"> a</span><span>,</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> b</span><span>,</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> r</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-keyword"> switch</span><span> (</span><span>r </span><span class="z-keyword">%</span><span class="z-constant"> 4</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 0</span><span>:</span><span class="z-keyword"> return</span><span> (</span><span>a </span><span class="z-keyword">*</span><span class="z-constant"> 33</span><span>)</span><span class="z-keyword"> +</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 1</span><span>:</span><span class="z-keyword"> return</span><span> (</span><span>a </span><span class="z-keyword">^</span><span> b</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 33</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> prevent rotate by 0 which is a NOP</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 2</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> ROTL32</span><span>(</span><span>a</span><span>,</span><span> (</span><span>(</span><span>r </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 16</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> ^</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 3</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> ROTR32</span><span>(</span><span>a</span><span>,</span><span> (</span><span>(</span><span>r </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 16</span><span>)</span><span class="z-keyword"> %</span><span class="z-constant"> 31</span><span>)</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> ^</span><span> b</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The math operations chosen for the random math are ones that are easy to implement in CUDA and OpenCL, the two main programming languages for commodity GPUs. The <a rel="external" href="https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/mul_hi.html">mul_hi</a>, <a rel="external" href="https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/integerMax.html">min</a>, <a rel="external" href="https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/clz.html">clz</a>, and <a rel="external" href="https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/popcount.html">popcount</a> functions match the corresponding OpenCL functions. ROTL32 matches the OpenCL <a rel="external" href="https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/rotate.html">rotate</a> function. ROTR32 is rotate right, which is equivalent to <code>rotate(i, 32-v)</code>.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#math">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> Random math between two input values</span></span> <span class="giallo-l"><span class="z-storage z-type">uint32_t</span><span class="z-entity z-name"> math</span><span>(</span><span class="z-storage z-type">uint32_t</span><span class="z-variable"> a</span><span>,</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> b</span><span>,</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> r</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-keyword"> switch</span><span> (</span><span>r </span><span class="z-keyword">%</span><span class="z-constant"> 11</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 0</span><span>:</span><span class="z-keyword"> return</span><span> a </span><span class="z-keyword">+</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 1</span><span>:</span><span class="z-keyword"> return</span><span> a </span><span class="z-keyword">*</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 2</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> mul_hi</span><span>(</span><span>a</span><span>,</span><span> b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 3</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> min</span><span>(</span><span>a</span><span>,</span><span> b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 4</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> ROTL32</span><span>(</span><span>a</span><span>,</span><span> b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 5</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> ROTR32</span><span>(</span><span>a</span><span>,</span><span> b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 6</span><span>:</span><span class="z-keyword"> return</span><span> a </span><span class="z-keyword">&amp;</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 7</span><span>:</span><span class="z-keyword"> return</span><span> a </span><span class="z-keyword">|</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 8</span><span>:</span><span class="z-keyword"> return</span><span> a </span><span class="z-keyword">^</span><span> b</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 9</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> clz</span><span>(</span><span>a</span><span>)</span><span class="z-keyword"> +</span><span class="z-entity z-name"> clz</span><span>(</span><span>b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> case</span><span class="z-constant"> 10</span><span>:</span><span class="z-keyword"> return</span><span class="z-entity z-name"> popcount</span><span>(</span><span>a</span><span>)</span><span class="z-keyword"> +</span><span class="z-entity z-name"> popcount</span><span>(</span><span>b</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The flow of the inner loop is:</p> <ul> <li>Lane <code>(loop % LANES)</code> is chosen as the leader for that loop iteration</li> <li>The leader's <code>mix[0]</code> value modulo the number of 256-byte DAG entries is used to select where to read from the full DAG</li> <li>Each lane reads <code>DAG_LOADS</code> sequential words, using <code>(lane ^ loop) % LANES</code> as the starting offset within the entry.</li> <li>The random sequence of math and cache accesses is performed</li> <li>The DAG data read at the start of the loop is merged at the end of the loop</li> </ul> <p><code>prog_seed</code> and <code>loop</code> come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number. <code>mix</code> is the state array, initially filled by <code>fill_mix</code>. <code>dag</code> is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in little-endian format. On little-endian architectures this is just a normal int32 pointer to the existing DAG.</p> <p><code>DAG_BYTES</code> is set to the number of bytes in the current DAG, which is generated identically to the existing Ethash algorithm.</p> <p>Test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#progpowloop">in the test vectors file</a>.</p> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-storage z-type">void</span><span class="z-entity z-name"> progPowLoop</span><span>(</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint64_t</span><span class="z-variable"> prog_seed</span><span>,</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> loop</span><span>,</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable"> mix</span><span>[</span><span>PROGPOW_LANES</span><span>]</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>,</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint32_t</span><span class="z-storage"> *</span><span class="z-variable">dag</span><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> dag_entry holds the 256 bytes of data loaded from the DAG</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable z-other"> dag_entry</span><span>[</span><span>PROGPOW_LANES</span><span>]</span><span>[</span><span>PROGPOW_DAG_LOADS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> On each loop iteration rotate which lane is the source of the DAG address.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The source lane&#39;s mix[0] value is used to ensure the last loop&#39;s DAG data feeds into this loop&#39;s address.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> dag_addr_base is which 256-byte entry within the DAG will be accessed</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> dag_addr_base </span><span class="z-keyword">=</span><span class="z-variable z-other"> mix</span><span>[</span><span>loop</span><span class="z-keyword">%</span><span>PROGPOW_LANES</span><span>]</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> %</span></span> <span class="giallo-l"><span> (</span><span>DAG_BYTES </span><span class="z-keyword">/</span><span> (</span><span>PROGPOW_LANES</span><span class="z-keyword">*</span><span>PROGPOW_DAG_LOADS</span><span class="z-keyword">*</span><span class="z-keyword">sizeof</span><span>(</span><span class="z-storage z-type">uint32_t</span><span>)</span><span>)</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Lanes access DAG_LOADS sequential words from the dag entry</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Shuffle which portion of the entry each lane accesses each iteration by XORing lane and loop.</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> This prevents multi-chip ASICs from each storing just a portion of the DAG</span></span> <span class="giallo-l"><span class="z-storage z-type"> size_t</span><span> dag_addr_lane </span><span class="z-keyword">=</span><span> dag_addr_base </span><span class="z-keyword">*</span><span> PROGPOW_LANES </span><span class="z-keyword">+</span><span> (</span><span>l </span><span class="z-keyword">^</span><span> loop</span><span>)</span><span class="z-keyword"> %</span><span> PROGPOW_LANES</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_DAG_LOADS</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> dag_entry</span><span>[</span><span>l</span><span>]</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> dag</span><span>[</span><span>dag_addr_lane </span><span class="z-keyword">*</span><span> PROGPOW_DAG_LOADS </span><span class="z-keyword">+</span><span> i</span><span>]</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Initialize the program seed and sequences</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> When mining these are evaluated on the CPU and compiled away</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span class="z-variable z-other"> mix_seq_src</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> mix_seq_dst_cnt </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> mix_seq_src_cnt </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> kiss99_t</span><span> prog_rnd </span><span class="z-keyword">=</span><span class="z-entity z-name"> progPowInit</span><span>(</span><span>prog_seed</span><span>,</span><span> mix_seq_dst</span><span>,</span><span> mix_seq_src</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> max_i </span><span class="z-keyword">=</span><span class="z-entity z-name"> max</span><span>(</span><span>PROGPOW_CNT_CACHE</span><span>,</span><span> PROGPOW_CNT_MATH</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> max_i</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>i </span><span class="z-keyword">&lt;</span><span> PROGPOW_CNT_CACHE</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Cached memory access</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> lanes access random 32-bit locations within the first portion of the DAG</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> src </span><span class="z-keyword">=</span><span class="z-variable z-other"> mix_seq_src</span><span>[</span><span>(</span><span>mix_seq_src_cnt</span><span class="z-keyword">++</span><span>)</span><span class="z-keyword">%</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> dst </span><span class="z-keyword">=</span><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>(</span><span>mix_seq_dst_cnt</span><span class="z-keyword">++</span><span>)</span><span class="z-keyword">%</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> sel </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> offset </span><span class="z-keyword">=</span><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>src</span><span>]</span><span class="z-keyword"> %</span><span> (</span><span>PROGPOW_CACHE_BYTES</span><span class="z-keyword">/</span><span class="z-keyword">sizeof</span><span>(</span><span class="z-storage z-type">uint32_t</span><span>)</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> merge</span><span>(</span><span class="z-variable z-other">mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span>,</span><span class="z-variable z-other"> dag</span><span>[</span><span>offset</span><span>]</span><span>,</span><span> sel</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>i </span><span class="z-keyword">&lt;</span><span> PROGPOW_CNT_MATH</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Random Math</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Generate 2 unique sources</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> src_rnd </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span class="z-keyword"> %</span><span> (</span><span>PROGPOW_REGS </span><span class="z-keyword">*</span><span> (</span><span>PROGPOW_REGS</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>)</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> src1 </span><span class="z-keyword">=</span><span> src_rnd </span><span class="z-keyword">%</span><span> PROGPOW_REGS</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 0 &lt;= src1 &lt; PROGPOW_REGS</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> src2 </span><span class="z-keyword">=</span><span> src_rnd </span><span class="z-keyword">/</span><span> PROGPOW_REGS</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 0 &lt;= src2 &lt; PROGPOW_REGS - 1</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>src2 </span><span class="z-keyword">&gt;=</span><span> src1</span><span>)</span><span class="z-keyword"> ++</span><span>src2</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> src2 is now any reg other than src1</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> sel1 </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> dst </span><span class="z-keyword">=</span><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>(</span><span>mix_seq_dst_cnt</span><span class="z-keyword">++</span><span>)</span><span class="z-keyword">%</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> sel2 </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span> data </span><span class="z-keyword">=</span><span class="z-entity z-name"> math</span><span>(</span><span class="z-variable z-other">mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>src1</span><span>]</span><span>,</span><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>src2</span><span>]</span><span>,</span><span> sel1</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> merge</span><span>(</span><span class="z-variable z-other">mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span>,</span><span> data</span><span>,</span><span> sel2</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Consume the global load data at the very end of the loop to allow full latency hiding</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Always merge into mix[0] to feed the offset calculation</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_DAG_LOADS</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> dst </span><span class="z-keyword">=</span><span> (</span><span>i</span><span class="z-keyword">==</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> ?</span><span class="z-constant"> 0</span><span class="z-keyword"> :</span><span class="z-variable z-other"> mix_seq_dst</span><span>[</span><span>(</span><span>mix_seq_dst_cnt</span><span class="z-keyword">++</span><span>)</span><span class="z-keyword">%</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-storage z-type"> int</span><span> sel </span><span class="z-keyword">=</span><span class="z-entity z-name"> kiss99</span><span>(</span><span>prog_rnd</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> merge</span><span>(</span><span class="z-variable z-other">mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>dst</span><span>]</span><span>,</span><span class="z-variable z-other"> dag_entry</span><span>[</span><span>l</span><span>]</span><span>[</span><span>i</span><span>]</span><span>,</span><span> sel</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>The flow of the overall algorithm is:</p> <ul> <li>A keccak hash of the header + nonce to create a digest of 256 bits from keccak_f800 (padding is consistent with custom one in ethash)</li> <li>Use first two words of digest as seed to generate initial mix data</li> <li>Loop multiple times, each time hashing random loads and random math into the mix data</li> <li>Hash all the mix data into a single 256-bit value</li> <li>A final keccak hash using carry-over digest from initial data + mix_data final 256 bit value (padding is consistent with custom one in ethash)</li> <li>When mining this final value is compared against a <code>hash32_t</code> target</li> </ul> <pre class="giallo z-code"><code data-lang="cpp"><span class="giallo-l"><span class="z-support">hash32_t</span><span class="z-entity z-name"> progPowHash</span><span>(</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint64_t</span><span class="z-variable"> prog_seed</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> value is (block_number/PROGPOW_PERIOD)</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint64_t</span><span class="z-variable"> nonce</span><span>,</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-support"> hash32_t</span><span class="z-variable"> header</span><span>,</span></span> <span class="giallo-l"><span class="z-storage"> const</span><span class="z-storage z-type"> uint32_t</span><span class="z-storage"> *</span><span class="z-variable">dag</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> gigabyte DAG located in framebuffer - the first portion gets cached</span></span> <span class="giallo-l"><span>)</span></span> <span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> hash32_t</span><span> hash_init</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> hash32_t</span><span> hash_final</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable z-other"> mix</span><span>[</span><span>PROGPOW_LANES</span><span>]</span><span>[</span><span>PROGPOW_REGS</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /*</span><span class="z-comment"> </span></span> <span class="giallo-l"><span class="z-comment"> ========================================</span></span> <span class="giallo-l"><span class="z-comment"> Absorb phase for initial keccak pass</span></span> <span class="giallo-l"><span class="z-comment"> ========================================</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">25</span><span>]</span><span class="z-keyword"> =</span><span> {</span><span class="z-keyword">0x</span><span class="z-constant">0</span><span>}</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 1st fill with header data (8 words)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span class="z-constant"> 8</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> header</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>i</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 2nd fill with nonce (2 words)</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">8</span><span>]</span><span class="z-keyword"> =</span><span> nonce</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">9</span><span>]</span><span class="z-keyword"> =</span><span> nonce </span><span class="z-keyword">&gt;&gt;</span><span class="z-constant"> 32</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 3rd apply padding</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">10</span><span>]</span><span class="z-keyword"> =</span><span class="z-keyword"> 0x</span><span class="z-constant">00000001</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">18</span><span>]</span><span class="z-keyword"> =</span><span class="z-keyword"> 0x</span><span class="z-constant">80008081</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> keccak(header..nonce)</span></span> <span class="giallo-l"><span> hash_init </span><span class="z-keyword">=</span><span class="z-entity z-name"> keccak_f800_progpow</span><span>(</span><span>state</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> get the seed to initialize mix</span></span> <span class="giallo-l"><span> seed </span><span class="z-keyword">=</span><span> (</span><span>(</span><span class="z-storage z-type">uint64_t</span><span>)</span><span class="z-variable z-other">hash_init</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> &lt;&lt;</span><span class="z-constant"> 32</span><span>)</span><span class="z-keyword"> |</span><span class="z-variable z-other"> hash_init</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span class="z-constant">0</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> initialize mix for all lanes</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name"> fill_mix</span><span>(</span><span>seed</span><span>,</span><span> l</span><span>,</span><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> execute the randomly generated inner loop</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_CNT_DAG</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-entity z-name"> progPowLoop</span><span>(</span><span>prog_seed</span><span>,</span><span> i</span><span>,</span><span> mix</span><span>,</span><span> dag</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Reduce mix data to a per-lane 32-bit digest</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable z-other"> digest_lane</span><span>[</span><span>PROGPOW_LANES</span><span>]</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-variable z-other"> digest_lane</span><span>[</span><span>l</span><span>]</span><span class="z-keyword"> =</span><span> FNV_OFFSET_BASIS</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span> PROGPOW_REGS</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> digest_lane</span><span>[</span><span>l</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-other">digest_lane</span><span>[</span><span>l</span><span>]</span><span>,</span><span class="z-variable z-other"> mix</span><span>[</span><span>l</span><span>]</span><span>[</span><span>i</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Reduce all lanes to a single 256-bit digest</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span class="z-constant"> 8</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> digest</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span> FNV_OFFSET_BASIS</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> l </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> l </span><span class="z-keyword">&lt;</span><span> PROGPOW_LANES</span><span>;</span><span> l</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> digest</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>l</span><span class="z-keyword">%</span><span class="z-constant">8</span><span>]</span><span class="z-keyword"> =</span><span class="z-entity z-name"> fnv1a</span><span>(</span><span class="z-variable z-other">digest</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>l</span><span class="z-keyword">%</span><span class="z-constant">8</span><span>]</span><span>,</span><span class="z-variable z-other"> digest_lane</span><span>[</span><span>l</span><span>]</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> /*</span><span class="z-comment"> </span></span> <span class="giallo-l"><span class="z-comment"> ========================================</span></span> <span class="giallo-l"><span class="z-comment"> Absorb phase for final keccak pass</span></span> <span class="giallo-l"><span class="z-comment"> ========================================</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> */</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-storage z-type"> uint32_t</span><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">25</span><span>]</span><span class="z-keyword"> =</span><span> {</span><span class="z-keyword">0x</span><span class="z-constant">0</span><span>}</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 1st fill with hash_init (8 words)</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span class="z-constant"> 8</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> hash_init</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>i</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 2nd fill with digest from main loop</span></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span class="z-storage z-type">int</span><span> i </span><span class="z-keyword">=</span><span class="z-constant"> 8</span><span>;</span><span> i </span><span class="z-keyword">&lt;</span><span class="z-constant"> 16</span><span>;</span><span> i</span><span class="z-keyword">++</span><span>)</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span>i</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable z-other"> digest</span><span>.</span><span class="z-variable z-other">uint32s</span><span>[</span><span>i </span><span class="z-keyword">-</span><span class="z-constant"> 8</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> 3rd apply padding</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">17</span><span>]</span><span class="z-keyword"> =</span><span class="z-keyword"> 0x</span><span class="z-constant">00000001</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> state</span><span>[</span><span class="z-constant">24</span><span>]</span><span class="z-keyword"> =</span><span class="z-keyword"> 0x</span><span class="z-constant">80008081</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> keccak(header..nonce)</span></span> <span class="giallo-l"><span> hash_final </span><span class="z-keyword">=</span><span class="z-entity z-name"> keccak_f800_progpow</span><span>(</span><span>state</span><span>)</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Compare hash final to target</span></span> <span class="giallo-l"><span> [</span><span>...</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="security-considerations">Security Considerations</h2> <p>This proposal has been software and hardware audited:</p> <ul> <li><a rel="external" href="https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf">Least Authority — ProgPoW Software Audit PDF</a></li> <li><a rel="external" href="https://github.com/ethereum-cat-herders/progpow-audit/raw/master/Bob%20Rao%20-%20ProgPOW%20Hardware%20Audit%20Report%20Final.pdf">Bob Rao - ProgPoW Hardware Audit PDF</a></li> </ul> <p>Least Authority in their findings suggest a change to DAG generation -- modification of <code>ETHASH_DATASET_PARENTS</code> from a value of 256 to the new value of 512 -- in order to mitigate vulnerability to a "Light Evaluation" attack. Due to this the DAG memory file used by ProgPoW is would no longer compatible with the one used by Ethash (epoch length and size increase ratio remain the same though).</p> <p>We do not recommend implementing this fix at this time. Ethash will not be exploitable for years, and it's not clear ProgPoW will ever be exploitable. It's better to deploy the audited code.</p> <p>After the completion of the audits a clever finding by <a rel="external" href="https://github.com/kik/">Kik</a> disclosed a vulnerability to <a rel="external" href="https://github.com/kik/progpow-exploit">bypassing ProgPoW memory hardness</a>. The vulnerability is present in Ethash as well but is near-impossible to exploit. In progPoW it is not possible to exploit -- it assumes the ability to create variants of the candidate block's header hash in a fashion similar to bitcoin, which is actually not possible in Ethereum. An attacker would need modified block headers, would need customized nodes able to accept the modified block headers, and uses extraNonce/extraData as entropy -- which isn’t the standard. And the required brute-force search would be difficult to accomplish in one blocktime. And even if supported by a customized node the block propagation of such mined blocks would be immediately blocked by other peers as the header hash is invalid.</p> <p>The authors have since found another vulnerability similar to Kik's, but it adds too much overhead to be ASIC-friendly. See Lanfranchi's full explanation <a rel="external" href="https://github.com/ifdefelse/ProgPOW/issues/51#issuecomment-690155355">here</a>. To completely prevent such exploits we could change the condition modifying the input state of the last keccak pass from</p> <ul> <li>header (256 bits) +</li> <li>seed for mix initiator (64 bits) +</li> <li>mix from main loop (256 bits)</li> <li>no padding</li> </ul> <p>to</p> <ul> <li>digest from initial keccak (256 bits) +</li> <li>mix from main loop (256 bits) +</li> <li>padding</li> </ul> <p>thus widening the constraint to target in keccak <a rel="external" href="https://github.com/kik/progpow-exploit">brute force keccak linear searches</a> from 64 to 256 bits.</p> <p>This fix is available as a PR to the reference implementation. Again, we do not recommend implementing this fix at this time. Kik's vulnerability and others like it cannot be exploited now and likely never will be. It's better to deploy the audited code.</p> <p>Note that these vulnerabilities cannot be exploited to deny service, double spend, or otherwise damage the network. They could at worst give their deployer an efficiency advantage over other miners.</p> <h2 id="test-cases">Test Cases</h2> <p>The random sequence generated for block 30,000 (prog_seed 3,000) can been seen in <a rel="external" href="https://github.com/ifdefelse/ProgPOW/blob/824cd791634204c4cc7e31f84bb76c0c84895bd3/test/kernel.cu">kernel.cu</a>.</p> <p>The algorithm run on block 30,000 produces the following digest and result:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Header : 0xffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff</span></span> <span class="giallo-l"><span>Nonce : 0x123456789abcdef0</span></span> <span class="giallo-l"><span>Hash init : 0xee304846ddd0a47b98179e96b60ec5ceeae2727834367e593de780e3e6d1892f</span></span> <span class="giallo-l"><span>Mix seed : 0x7ba4d0dd464830ee</span></span> <span class="giallo-l"><span>Mix hash : 0x493c13e9807440571511b561132834bbd558dddaa3b70c09515080a6a1aff6d0</span></span> <span class="giallo-l"><span>Hash final : 0x46b72b75f238bea3fcfd227e0027dc173dceaa1fb71744bd3d5e030ed2fed053</span></span></code></pre> <p>Additional test vectors can be found <a href="https://wg-eips.ritovision.com/1057/assets/test-vectors/#progpowhash">in the test vectors file</a>.</p> <p>Machine-readable test vectors (T.B.D)</p> <h2 id="implementation">Implementation</h2> <p>The reference ProgPoW mining implementation is located at <a rel="external" href="https://github.com/ifdefelse/ProgPOW">the @ifdefelse ProgPOW repository</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> <p>The reference ProgPoW mining implementation located at <a rel="external" href="https://github.com/ifdefelse/ProgPOW">ProgPOW</a> is a derivative of ethminer so retains the GPL license.</p> 2018-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Danny Ryanhttps://github.com/djrtwo Chih-Cheng Lianghttps://github.com/ChihChengLiang https://wg-eips.ritovision.com/1011/ <h2 id="simple-summary">Simple Summary</h2> <p>Specification of the first step to transition Ethereum main net from Proof of Work (PoW) to Proof of Stake (PoS). The resulting consensus model is a PoW/PoS hybrid.</p> <h2 id="abstract">Abstract</h2> <p>This EIP specifies a hybrid PoW/PoS consensus model for Ethereum main net. Existing PoW mechanics are used for new block creation, and a novel PoS mechanism called Casper the Friendly Finality Gadget (FFG) is layered on top using a smart contract.</p> <p>Through the use of Ether deposits, slashing conditions, and a modified fork choice, FFG allows the underlying PoW blockchain to be finalized. As network security is greatly shifted from PoW to PoS, PoW block rewards are reduced.</p> <p>This EIP does not contain safety and liveness proofs or validator implementation details, but these can be found in the <a rel="external" href="https://arxiv.org/abs/1710.09437">Casper FFG paper</a> and <a rel="external" href="https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md">Validator Implementation Guide</a> respectively.</p> <h2 id="glossary">Glossary</h2> <ul> <li><strong>epoch</strong>: The span of blocks between checkpoints. Epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch.</li> <li><strong>finality</strong>: The point at which a block has been decided upon by a client to <em>never</em> revert. Proof of Work does not have the concept of finality, only of further deep block confirmations.</li> <li><strong>checkpoint</strong>: The block/hash under consideration for finality for a given epoch. This block is the <em>last</em> block of the previous epoch. Rather than dealing with every block, Casper FFG only considers checkpoints for finalization. When a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized.</li> <li><strong>validator</strong>: A participant in the Casper FFG consensus that has deposited ether in the casper contract and has the responsibility to vote and finalize checkpoints.</li> <li><strong>validator set</strong>: The set of validators in the casper contract at any given time.</li> <li><strong>dynasty</strong>: The number of finalized checkpoints in the chain from root to the parent of a block. The dynasty is used to define when a validator starts and ends validating. The current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality.</li> <li><strong>slash</strong>: The burning of some amount of a validator's deposit along with an immediate logout from the validator set. Slashing occurs when a validator signs two conflicting <code>vote</code> messages that violate a slashing condition. For an in-depth discussion of slashing conditions, see the <a rel="external" href="https://arxiv.org/abs/1710.09437">Casper FFG Paper</a>.</li> </ul> <h2 id="motivation">Motivation</h2> <p>Transitioning the Ethereum network from PoW to PoS has been on the roadmap and in the <a rel="external" href="https://github.com/ethereum/yellowpaper">Yellow Paper</a> since the launch of the protocol. Although effective in coming to a decentralized consensus, PoW consumes an incredible amount of energy, has no economic finality, and has no effective strategy in resisting cartels. Excessive energy consumption, issues with equal access to mining hardware, mining pool centralization, and an emerging market of ASICs each provide a distinct motivation to make the transition as soon as possible.</p> <p>Until recently, the proper way to make this transition was still an open area of research. In October of 2017 <a rel="external" href="https://arxiv.org/abs/1710.09437">Casper the Friendly Finality Gadget</a> was published, solving open questions of economic finality through validator deposits and crypto-economic incentives. For a detailed discussion and proofs of "accountable safety" and "plausible liveness", see the <a rel="external" href="https://arxiv.org/abs/1710.09437">Casper FFG</a> paper.</p> <p>The Casper FFG contract can be layered on top of any block proposal mechanism, providing finality to the underlying chain. This EIP proposes layering FFG on top of the existing PoW block proposal mechanism as a conservative step-wise approach in the transition to full PoS. The new FFG staking mechanism requires minimal changes to the protocol, allowing the Ethereum network to fully test and evaluate Casper FFG on top of PoW before moving to a validator based block proposal mechanism.</p> <h2 id="parameters">Parameters</h2> <ul> <li><code>HYBRID_CASPER_FORK_BLKNUM</code>: TBD</li> <li><code>CASPER_ADDR</code>: TBD</li> <li><code>CASPER_CODE</code>: see below</li> <li><code>CASPER_BALANCE</code>: 1.25e24 wei (1,250,000 ETH)</li> <li><code>MSG_HASHER_ADDR</code>: TBD</li> <li><code>MSG_HASHER_CODE</code>: see below</li> <li><code>PURITY_CHECKER_ADDR</code>: TBD</li> <li><code>PURITY_CHECKER_CODE</code>: see below</li> <li><code>NULL_SENDER</code>: <code>2**160 - 1</code></li> <li><code>NEW_BLOCK_REWARD</code>: 6e17 wei (0.6 ETH)</li> <li><code>REWARD_STEPDOWN_BLOCK_COUNT</code>: 5.5e5 blocks (~3 months)</li> <li><code>CASPER_INIT_DATA</code>: TBD</li> <li><code>VOTE_BYTES</code>: <code>0xe9dc0614</code></li> <li><code>INITIALIZE_EPOCH_BYTES</code>: <code>0x5dcffc17</code></li> <li><code>NON_REVERT_MIN_DEPOSIT</code>: amount in wei configurable by client</li> </ul> <h3 id="casper-contract-parameters">Casper Contract Parameters</h3> <ul> <li><code>EPOCH_LENGTH</code>: 50 blocks</li> <li><code>WARM_UP_PERIOD</code>: 1.8e5 blocks (~1 month)</li> <li><code>WITHDRAWAL_DELAY</code>: 1.5e4 epochs</li> <li><code>DYNASTY_LOGOUT_DELAY</code>: 700 dynasties</li> <li><code>BASE_INTEREST_FACTOR</code>: 7e-3</li> <li><code>BASE_PENALTY_FACTOR</code>: 2e-7</li> <li><code>MIN_DEPOSIT_SIZE</code>: 1.5e21 wei (1500 ETH)</li> </ul> <h2 id="specification">Specification</h2> <h4 id="deploying-casper-contract">Deploying Casper Contract</h4> <p>If <code>block.number == HYBRID_CASPER_FORK_BLKNUM</code>, then when processing the block before processing any transactions:</p> <ul> <li>set the code of <code>MSG_HASHER_ADDR</code> to <code>MSG_HASHER_CODE</code></li> <li>set the code of <code>PURITY_CHECKER_ADDR</code> to <code>PURITY_CHECKER_CODE</code></li> <li>set the code of <code>CASPER_ADDR</code> to <code>CASPER_CODE</code></li> <li>set balance of <code>CASPER_ADDR</code> to <code>CASPER_BALANCE</code></li> </ul> <p>Then execute a <code>CALL</code> with the following parameters before executing any normal block transactions:</p> <ul> <li><code>SENDER</code>: <code>NULL_SENDER</code></li> <li><code>GAS</code>: 3141592</li> <li><code>TO</code>: <code>CASPER_ADDR</code></li> <li><code>VALUE</code>: 0</li> <li><code>NONCE</code>: 0</li> <li><code>GASPRICE</code>: 0</li> <li><code>DATA</code>: <code>CASPER_INIT_DATA</code></li> </ul> <p>This <code>CALL</code> utilizes no gas and does not increment the nonce of <code>NULL_SENDER</code></p> <h4 id="initialize-epochs">Initialize Epochs</h4> <p>If <code>block.number &gt;= (HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD)</code> and <code>block.number % EPOCH_LENGTH == 0</code>, execute a <code>CALL</code> with the following parameters before executing any normal block transactions:</p> <ul> <li><code>SENDER</code>: <code>NULL_SENDER</code></li> <li><code>GAS</code>: 3141592</li> <li><code>TO</code>: <code>CASPER_ADDR</code></li> <li><code>VALUE</code>: 0</li> <li><code>NONCE</code>: 0</li> <li><code>GASPRICE</code>: 0</li> <li><code>DATA</code>: <code>INITIALIZE_EPOCH_BYTES</code> followed by the 32-byte encoding of <code>floor(block.number / EPOCH_LENGTH)</code></li> </ul> <p>This <code>CALL</code> utilizes no gas and does not increment the nonce of <code>NULL_SENDER</code></p> <h4 id="casper-votes">Casper Votes</h4> <p>A <code>vote</code> transaction is defined as a transaction with the following parameters:</p> <ul> <li><code>TO</code>: <code>CASPER_ADDR</code></li> <li><code>DATA</code>: Begins with <code>VOTE_BYTES</code></li> </ul> <p>If <code>block.number &gt;= HYBRID_CASPER_FORK_BLKNUM</code>, then:</p> <ul> <li>A valid <code>vote</code> transaction to <code>CASPER_ADDR</code> must satisfy each of the following: <ul> <li>Must have the following signature <code>(CHAIN_ID, 0, 0)</code> (ie. <code>r = s = 0, v = CHAIN_ID</code>)</li> <li>Must have <code>value == nonce == gasprice == 0</code></li> </ul> </li> <li>When producing and validating a block, when handling <code>vote</code> transactions to <code>CASPER_ADDR</code>: <ul> <li>Only include "valid" <code>vote</code> transactions as defined above</li> <li>Place all <code>vote</code> transactions at the end of the block</li> <li>Track cumulative gas used by votes separately from cumulative gas used by normal transactions via <code>vote_gas_used</code></li> <li>Total <code>vote_gas_used</code> of <code>vote</code> transactions cannot exceed the <code>block_gas_limit</code>, independent of gas used by normal block transactions</li> </ul> </li> <li>When applying <code>vote</code> transactions to <code>CASPER_ADDR</code> to vm state: <ul> <li>Set sender to <code>NULL_SENDER</code></li> <li>Count gas of <code>vote</code> toward <code>vote_gas_used</code></li> <li>Do not count gas of <code>vote</code> toward the normal <code>gas_used</code>. For all <code>vote</code> transaction receipts, cumulative gas used is equal to last non-<code>vote</code> transaction receipt</li> <li>Do not increment the nonce of <code>NULL_SENDER</code></li> </ul> </li> <li>All unsuccessful <code>vote</code> transactions to <code>CASPER_ADDR</code> are invalid and must not be included in the block</li> </ul> <h4 id="fork-choice-and-finalization">Fork Choice and Finalization</h4> <p>If <code>block.number &gt;= HYBRID_CASPER_FORK_BLKNUM</code>, the fork choice rule is the logic represented by the following pseudocode. Note that options <code>--casper-fork-choice</code> and <code>--exclude</code> are discussed below in "Client Settings".</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> handle_block</span><span>(</span><span class="z-variable z-parameter z-function">new_block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> not</span><span> is_new_head</span><span>(</span><span>new_block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> set_head</span><span>(</span><span>new_block</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-invalid z-illegal"> --</span><span>casper</span><span class="z-keyword">-</span><span>fork</span><span class="z-keyword">-</span><span>choice</span><span class="z-keyword"> is</span><span> on</span><span>:</span></span> <span class="giallo-l"><span> check_and_finalize_new_checkpoint</span><span>(</span><span>new_block</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> is_new_head</span><span>(</span><span class="z-variable z-parameter z-function">new_block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-invalid z-illegal"> --</span><span>casper</span><span class="z-keyword">-</span><span>fork</span><span class="z-keyword">-</span><span>choice</span><span class="z-keyword"> is</span><span> off</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> old pure PoW chain scoring rule</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> new_block</span><span>.</span><span>total_difficuty</span><span class="z-keyword"> &gt;</span><span> current_head</span><span>.</span><span>total_difficulty</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> new_block</span><span class="z-keyword"> is</span><span class="z-keyword"> in</span><span class="z-invalid z-illegal"> --</span><span>exclude</span><span class="z-support"> list</span><span class="z-keyword"> or</span><span> one</span><span> of</span><span> its</span><span> descendants</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> don&#39;t revert finalized blocks</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> db</span><span>.</span><span>last_finalized_block</span><span class="z-keyword"> is</span><span class="z-keyword"> not</span><span class="z-keyword"> in</span><span> new_block</span><span>.</span><span>ancestors</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> new casper chain scoring rule</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> highest_justified_epoch</span><span>(</span><span>new_block</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 10</span><span class="z-keyword">**</span><span class="z-constant">40</span><span class="z-keyword"> +</span><span> new_block</span><span>.</span><span>total_difficuty</span><span class="z-keyword"> &gt;</span></span> <span class="giallo-l"><span> highest_justified_epoch</span><span>(</span><span>current_head</span><span>)</span><span class="z-keyword"> *</span><span class="z-constant"> 10</span><span class="z-keyword">**</span><span class="z-constant">40</span><span class="z-keyword"> +</span><span> current_head</span><span>.</span><span>total_difficulty</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> highest_justified_epoch</span><span>(</span><span class="z-variable z-parameter z-function">block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> casper</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>post_state</span><span>.</span><span>casper_contract</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> casper</span><span>.</span><span>highest_justified_epoch</span><span>(</span><span class="z-constant">NON_REVERT_MIN_DEPOSITS</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> check_and_finalize_new_checkpoint</span><span>(</span><span class="z-variable z-parameter z-function">new_block</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> casper</span><span class="z-keyword"> =</span><span> new_block</span><span>.</span><span>post_state</span><span>.</span><span>casper_contract</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> If no finalized blocks, db.last_finalized_epoch initialized to -1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> finalized_epoch</span><span class="z-keyword"> =</span><span> casper</span><span>.</span><span>highest_finalized_epoch</span><span>(</span><span class="z-constant">NON_REVERT_MIN_DEPOSITS</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> finalized_epoch</span><span class="z-keyword"> &gt;</span><span> db</span><span>.</span><span>last_finalized_epoch</span><span>:</span></span> <span class="giallo-l"><span> finalized_hash</span><span class="z-keyword"> =</span><span> casper</span><span>.</span><span>checkpoint_hashes</span><span>(</span><span>finalized_epoch</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> ensure not trivially finalized</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> finalized_hash</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> b</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-constant">\x00</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-keyword"> *</span><span class="z-constant"> 32</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> db</span><span>.</span><span>last_finalized_epoch</span><span class="z-keyword"> =</span><span> finalized_epoch</span></span> <span class="giallo-l"><span> db</span><span>.</span><span>last_finalized_block</span><span class="z-keyword"> =</span><span> finalized_hash</span></span></code></pre> <p>The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (<code>NON_REVERT_MIN_DEPOSITS</code>). The <code>10**40</code> multiplier ensures that the justified epoch takes precedence over block mining difficulty. <code>total_difficulty</code> only serves as a tie breaker if the two blocks in question have an equivalent <code>highest_justified_epoch</code>.</p> <p><em>Note</em>: If the client has no justified checkpoints, the contract returns <code>highest_justified_epoch</code> as <code>0</code> essentially reverting the fork choice rule to pure PoW.</p> <p>When assessing a new block as the chain's head, clients must <em>never revert finalized blocks</em> as seen by the code commented as "don't revert finalized blocks".</p> <p>When a new block is added as the chain's head, clients then check for a new finalized block. This is handled by the <code>check_and_finalized_new_checkpoint(new_block)</code> method above. If the highest finalized epoch in the casper contract is greater than the previous finalized epoch, then the client finalizes the block with the hash <code>casper.checkpoint_hashes(finalized_epoch)</code>, storing this block and the related epoch number in the client database as finalized.</p> <p>Clients only consider checkpoints justified or finalized if deposits were greater than <code>NON_REVERT_MIN_DEPOSIT</code> <em>during the epoch in question</em>. This logic is encapsulated in <code>casper.highest_justified_epoch(NON_REVERT_MIN_DEPOSIT)</code> and <code>casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSIT)</code>, respectively.</p> <h4 id="block-reward">Block Reward</h4> <p>If <code>block.number &gt;= HYBRID_CASPER_FORK_BLKNUM</code>, then <code>block_reward</code> is defined by the following logic and utilizes the same formulas for ommer rewards but with the updated <code>block_reward</code>.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &lt;</span><span class="z-constant"> HYBRID_CASPER_FORK_BLKNUM</span><span class="z-keyword"> +</span><span class="z-constant"> REWARD_STEPDOWN_BLOCK_COUNT</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> 5</span><span class="z-keyword"> *</span><span class="z-constant"> NEW_BLOCK_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &lt;</span><span class="z-constant"> HYBRID_CASPER_FORK_BLKNUM</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword">*</span><span class="z-constant">REWARD_STEPDOWN_BLOCK_COUNT</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> 4</span><span class="z-keyword"> *</span><span class="z-constant"> NEW_BLOCK_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &lt;</span><span class="z-constant"> HYBRID_CASPER_FORK_BLKNUM</span><span class="z-keyword"> +</span><span class="z-constant"> 3</span><span class="z-keyword">*</span><span class="z-constant">REWARD_STEPDOWN_BLOCK_COUNT</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> 3</span><span class="z-keyword"> *</span><span class="z-constant"> NEW_BLOCK_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> &lt;</span><span class="z-constant"> HYBRID_CASPER_FORK_BLKNUM</span><span class="z-keyword"> +</span><span class="z-constant"> 4</span><span class="z-keyword">*</span><span class="z-constant">REWARD_STEPDOWN_BLOCK_COUNT</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> 2</span><span class="z-keyword"> *</span><span class="z-constant"> NEW_BLOCK_REWARD</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span> block_reward</span><span class="z-keyword"> =</span><span class="z-constant"> NEW_BLOCK_REWARD</span></span></code></pre><h4 id="validators">Validators</h4> <p>The mechanics and responsibilities of validators are not specified in this EIP because they rely upon network transactions to the contract at <code>CASPER_ADDR</code> rather than on protocol level implementation and changes. See the <a rel="external" href="https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md">Validator Implementation Guide</a> for validator details.</p> <h4 id="msg-hasher-code">MSG_HASHER_CODE</h4> <p>The source code for <code>MSG_HASHER_CODE</code> is located <a rel="external" href="https://github.com/ethereum/casper/blob/master/casper/contracts/msg_hash.se.py">here</a>. The source is to be migrated to Vyper LLL before the bytecode is finalized for this EIP.</p> <p>The EVM init code is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre> <p>The EVM bytecode that the contract should be set to is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre><h4 id="purity-checker-code">PURITY_CHECKER_CODE</h4> <p>The source code for <code>PURITY_CHECKER_CODE</code> is located <a rel="external" href="https://github.com/ethereum/research/blob/master/impurity/check_for_impurity.se">here</a>. The source is to be migrated to Vyper LLL before the bytecode is finalized for this EIP.</p> <p>The EVM init code is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre> <p>The EVM bytecode that the contract should be set to is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre><h4 id="casper-code">CASPER_CODE</h4> <p>The source code for <code>CASPER_CODE</code> is located at <a rel="external" href="https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py">here</a>. The contract is to be formally verified and further tested before the bytecode is finalized for this EIP.</p> <p>The EVM init code with the above specified params is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre> <p>The EVM bytecode that the contract should be set to is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>TBD</span></span></code></pre><h4 id="client-settings">Client Settings</h4> <p>Clients should be implemented with the following configurable settings:</p> <h5 id="enable-casper-fork-choice">Enable Casper Fork Choice</h5> <p>The ability to enable/disable the Casper Fork Choice. A suggested implementation is <code>--casper-fork-choice</code>.</p> <p>This setting should ship as default disabled in client versions during the initial casper fork. This setting should ship as default enabled in subsequent client versions.</p> <h5 id="non-revert-min-deposit">NON_REVERT_MIN_DEPOSIT</h5> <p>The minimum size of total deposits that the client must observe in the FFG contract for the state of the contract to affect the client's fork choice. A suggested implementation is <code>--non-revert-min-deposit WEI_VALUE</code>.</p> <p>The suggested default value that clients should ship with is at least 2e23 wei (200K ETH).</p> <p>See "Fork Choice" more details.</p> <h5 id="exclusion">Exclusion</h5> <p>The ability to exclude a specified blockhash and all of its descendants from a client's fork choice. A suggested implementation is <code>--exclude BLOCKHASHES</code>, where <code>BLOCK_HASHES</code> is a comma delimited list of blockhashes to exclude.</p> <p>Note: this <em>can</em> by design override a client's forkchoice and revert finalized blocks.</p> <h5 id="join-fork">Join Fork</h5> <p>The ability to manually join a fork specified by a blockhash. A suggested implementation is <code>--join-fork BLOCKHASH</code> where the client automatically sets the head to the block defined by<code>BLOCKHASH</code> and locally finalizes it.</p> <p>Note: this <em>can</em> by design override a client's forkchoice and revert finalized blocks.</p> <h5 id="monitor-votes">Monitor Votes</h5> <p>The ability to monitor incoming <code>vote</code> transactions for slashing conditions and submit proof to the casper contract for a finder's fee if found. A suggested implementation is <code>--monitor-votes</code>.</p> <p>The setting should default to disabled.</p> <p>The following pseudocode defines when two <code>vote</code> messages violate a slashing condition. A <code>vote</code> message is the singular argument included in a <code>vote</code> transaction.</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> decode_rlp_list</span><span>(</span><span class="z-variable z-parameter z-function">vote_msg</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> #</span><span class="z-comment"> [validator_index, target_hash, target_epoch, source_epoch, signature]</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> RLPList</span><span>(</span><span>vote_msg</span><span>,</span><span> [</span><span class="z-support">int</span><span>,</span><span class="z-support"> bytes</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> int</span><span>,</span><span class="z-support"> bytes</span><span>]</span><span>)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> same_target_epoch</span><span>(</span><span class="z-variable z-parameter z-function">vote_msg_1</span><span>,</span><span class="z-variable z-parameter z-function"> vote_msg_2</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> decoded_values_1</span><span class="z-keyword"> =</span><span> decode_rlp_msg</span><span>(</span><span>vote_msg_1</span><span>)</span></span> <span class="giallo-l"><span> target_epoch_1</span><span class="z-keyword"> =</span><span> decoded_values_1</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> decoded_values_2</span><span class="z-keyword"> =</span><span> decode_rlp_msg</span><span>(</span><span>vote_msg_2</span><span>)</span></span> <span class="giallo-l"><span> target_epoch_2</span><span class="z-keyword"> =</span><span> decoded_values_2</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> target_epoch_1</span><span class="z-keyword"> ==</span><span> target_epoch_2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> surrounds</span><span>(</span><span class="z-variable z-parameter z-function">vote_msg_1</span><span>,</span><span class="z-variable z-parameter z-function"> vote_msg_2</span><span>)</span><span>:</span></span> <span class="giallo-l"><span> decoded_values_1</span><span class="z-keyword"> =</span><span> decode_rlp_msg</span><span>(</span><span>vote_msg_1</span><span>)</span></span> <span class="giallo-l"><span> target_epoch_1</span><span class="z-keyword"> =</span><span> decoded_values_1</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"><span> source_epoch_1</span><span class="z-keyword"> =</span><span> decoded_values_1</span><span>[</span><span class="z-constant">3</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> decoded_values_2</span><span class="z-keyword"> =</span><span> decode_rlp_msg</span><span>(</span><span>vote_msg_2</span><span>)</span></span> <span class="giallo-l"><span> target_epoch_2</span><span class="z-keyword"> =</span><span> decoded_values_2</span><span>[</span><span class="z-constant">2</span><span>]</span></span> <span class="giallo-l"><span> source_epoch_1</span><span class="z-keyword"> =</span><span> decoded_values_1</span><span>[</span><span class="z-constant">3</span><span>]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> vote_1_surrounds_vote_2</span><span class="z-keyword"> =</span><span> target_epoch_1</span><span class="z-keyword"> &gt;</span><span> target_epoch_2</span><span class="z-keyword"> and</span><span> source_epoch_1</span><span class="z-keyword"> &lt;</span><span> source_epoch_2</span></span> <span class="giallo-l"><span> vote_2_surrounds_vote_1</span><span class="z-keyword"> =</span><span> target_epoch_2</span><span class="z-keyword"> &gt;</span><span> target_epoch_1</span><span class="z-keyword"> and</span><span> source_epoch_2</span><span class="z-keyword"> &lt;</span><span> source_epoch_1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> vote_1_surrounds_vote_2</span><span class="z-keyword"> or</span><span> vote_2_surrounds_vote_1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">def</span><span class="z-entity z-name"> violates_slashing_condition</span><span>(</span><span class="z-variable z-parameter z-function">vote_msg_1</span><span>,</span><span class="z-variable z-parameter z-function"> vote_msg_2</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> same_target_epoch</span><span>(</span><span>vote_msg_1</span><span>,</span><span> vote_msg_2</span><span>)</span><span class="z-keyword"> or</span><span> surrounds</span><span>(</span><span>vote_msg_1</span><span>,</span><span> vote_msg_2</span><span>)</span></span></code></pre> <p>The casper contract also provides a helper method <code>slashable(vote_msg_1, vote_msg_2)</code> to check if two votes violate a slashing condition. Clients should use the above pseudocode in combination with <code>casper.slashable()</code> as a final check when deciding whether to submit a <code>slash</code> to the contract.</p> <p>The <code>--monitor-votes</code> setting is to be used for clients that wish to monitor vote transactions for slashing conditions. If a slashing condition is found, the client creates and sends a transaction to <code>slash</code> on the casper contract. The first transaction to include the slashing condition proof slashes the validator in question and sends a 4% finder's fee to the transaction sender.</p> <h2 id="rationale">Rationale</h2> <p>Naive PoS specifications and implementations have existed since early blockchain days, but most are vulnerable to serious attacks and do not hold up under crypto-economic analysis. Casper FFG solves problems such as "Nothing at Stake" and "Long Range Attacks" through requiring validators to post slashable deposits and through defining economic finality.</p> <h4 id="minimize-consensus-changes">Minimize Consensus Changes</h4> <p>The finality gadget is designed to minimize changes across clients. For this reason, FFG is implemented within the EVM, so that the contract byte code encapsulates most of the complexity of the fork.</p> <p>Most other decisions were made to minimize changes across clients. For example, it would be possible to allow <code>CASPER_ADDR</code> to mint Ether each time it paid rewards (as compared to creating the contract with <code>CASPER_BALANCE</code>), but this would be more invasive and error-prone than relying on existing EVM mechanics.</p> <h4 id="deploying-casper-contract-1">Deploying Casper Contract</h4> <p>The <code>MSG_HASHER_CODE</code> and <code>PURITY_CHECKER_CODE</code> both do not require any initialization so the EVM bytecode can simply be placed at <code>MSG_HASHER_ADDR</code> and <code>PURITY_CHECKER_ADDR</code>. On the other hand, the casper contract <em>does</em> require passing in parameters and initialization of state. This initialization would normally occur by the EVM init code interacting with the CREATE opcode. Due to the nature of this contract being deployed outside of normal block transactions and to a particular address, the EVM init code/CREATE method requires client specific "hacks" to make it work. For simplicity of specifying across clients, the EVM bytecode -- <code>CASPER_CODE</code> -- is placed at <code>CASPER_ADDR</code> followed by an explicit <code>CALL</code> to a one-time <code>init</code> method on the casper contract. <code>init</code> handles all of the logic that a constructor normally would, accepting contract parameters as arguments and setting initial variable values, and can only be run <em>once</em>.</p> <p><code>CASPER_INIT_DATA</code> is composed of the byte signature of the <code>init</code> method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order:</p> <ul> <li><code>EPOCH_LENGTH</code></li> <li><code>WITHDRAWAL_DELAY</code></li> <li><code>DYNASTY_LOGOUT_DELAY</code></li> <li><code>MSG_HASHER_ADDR</code></li> <li><code>PURITY_CHECKER_ADDR</code></li> <li><code>BASE_INTEREST_FACTOR</code></li> <li><code>BASE_PENALTY_FACTOR</code></li> <li><code>MIN_DEPOSIT_SIZE</code></li> </ul> <p>The entirety of this data is provided as a bytestring -- <code>CASPER_INIT_DATA</code> -- to reduce the chance of encoding errors across clients, especially regarding fixed decimal types which are new in vyper and not yet supported by all clients.</p> <h4 id="casper-contract-params">Casper Contract Params</h4> <p><code>EPOCH_LENGTH</code> is set to 50 blocks as a balance between time to finality and message overhead.</p> <p><code>WARM_UP_PERIOD</code> is set to 1.8e5 blocks to provide validators with an approximate 1 month period to make initial deposits before full contract functionality and voting begin. This helps prevent degenerate cases such as having very few or even just one validator in the initial dynasty. This 1 month period also gives the network time to observe on the order of how many validators will initially be participating in consensus. If for some reason there is an unexpectedly low turnout, the community might choose to delay validation and consider design alternatives.</p> <p><code>WITHDRAWAL_DELAY</code> is set to 15000 epochs to freeze a validator's funds for approximately 4 months after logout. This allows for at least a 4 month window to identify and slash a validator for attempting to finalize two conflicting checkpoints. This also defines the window of time with which a client must log on to sync the network due to weak subjectivity.</p> <p><code>DYNASTY_LOGOUT_DELAY</code> is set to 700 dynasties to prevent immediate logout in the event of an attack from being a viable strategy.</p> <p><code>BASE_INTEREST_FACTOR</code> is set to 7e-3 such that if there are ~10M ETH in total deposits, then validators earn approximately 5% per year in ETH rewards under optimal FFG conditions.</p> <p><code>BASE_PENALTY_FACTOR</code> is set to 2e-7 such that if 50% of deposits go offline, then offline validators lose half of their deposits in approximately 3 weeks, at which the online portion of validators becomes a 2/3 majority and can begin finalizing checkpoints again.</p> <p><code>MIN_DEPOSIT_SIZE</code> is set to 1500 ETH to form a natural upper bound on the total number of validators, bounding the overhead due to <code>vote</code> messages. Using formulas found <a rel="external" href="https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">here</a> under "From validator count to minimum staking ETH", we estimate that with 1500 ETH minimum deposit at an assumed ~10M in total deposits there will be approximately 900 validators at any given time. <code>vote</code>s are only sent after the first quarter of an epoch so 900 votes have to fit into 37 blocks or ~24 <code>vote</code>s per block. We have experimented with more dynamic models for <code>MIN_DEPOSIT_SIZE</code>, but these tend to introduce significant complexities and without data from a live network seem to be premature optimizations.</p> <h4 id="initialize-epochs-1">Initialize Epochs</h4> <p>The call to the method at <code>INITIALIZE_EPOCH_BYTES</code> at <code>CASPER_ADDR</code> at the start of each epoch is a call to the <code>initialize_epoch</code> method in the casper contract. This method can only be called once per epoch and is guaranteed by the protocol to be called at the start block of each epoch by <code>NULL_SENDER</code>. This method performs a number of bookkeeping tasks around incrementing variables, updating rewards, etc.</p> <p>Any call to this method fails prior to the end of the <code>WARM_UP_PERIOD</code>. Thus the protocol does not begin executing <code>initialize_epoch</code> calls until <code>block.number &gt;= HYBRID_CASPER_FORK_BLKNUM + WARM_UP_PERIOD</code>.</p> <h4 id="issuance">Issuance</h4> <p>A fixed amount of 1.25M ETH was chosen as <code>CASPER_BALANCE</code> to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS.</p> <p>The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (<code>REWARD_STEPDOWN_BLOCK_COUNT</code>) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See <a rel="external" href="https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a">here</a> for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG.</p> <p>In addition to block rewards, miners now receive an issuance reward for including successful <code>vote</code> transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful <code>vote</code> transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract.</p> <p>Below is a table of deposit sizes with associated annual interest rate and approximate time until funding crunch:</p> <table><thead><tr><th>Deposit Size</th><th>Annual Validator Interest</th><th>Funding Crunch</th></tr></thead><tbody> <tr><td>2.5M ETH</td><td>10.12%</td><td>~4 years</td></tr> <tr><td>10M ETH</td><td>5.00%</td><td>~2 years</td></tr> <tr><td>20M ETH</td><td>3.52%</td><td>~1.4 years</td></tr> <tr><td>40M ETH</td><td>2.48%</td><td>~1 year</td></tr> </tbody></table> <h4 id="gas-changes">Gas Changes</h4> <p>Normal block transactions cannot affect casper <code>vote</code> validation results, but casper <code>vote</code> validation results can affect normal block transaction execution. Due to this asymmetrical relationship, <code>vote</code> transactions can be processed in parallel with normal block transactions if <code>vote</code> transactions are placed after all normal block transactions. Because <code>vote</code> transactions can be processed in parallel to normal block transactions, <code>vote</code> transactions cost 0 gas for validators, ensuring that validators can submit votes even in highly congested or high gas-price periods.</p> <p><code>vote_gas_used</code> is introduced to ensure that <code>vote</code> transactions do not put an undue burden on block processing. The additional overhead from <code>vote</code> transactions is capped at the same limit as normal block transactions so that, when run in parallel, neither sets of transactions exceed the overhead defined by the <code>block_gas_limit</code>.</p> <p>The call to <code>initialize_epoch</code> at the beginning of each epoch requires 0 gas so that this protocol state transition does not take any gas allowance away from normal transactions.</p> <h4 id="null-sender-and-account-abstraction">NULL_SENDER and Account Abstraction</h4> <p>This EIP implements a limited version of account abstraction for validators' <code>vote</code> transactions. The general design was borrowed from <a href="https://wg-eips.ritovision.com/86/">EIP-86</a>. Rather than relying upon native transaction signatures, each validator specifies a signature contract when sending their <code>deposit</code> to <code>CASPER_ADDR</code>. When casting a <code>vote</code>, the validator bundles and signs the parameters of their <code>vote</code> according to the requirements of their signature contract. The <code>vote</code> method of the casper contract checks the signature of the parameters against the validator's signature contract, exiting the transaction as unsuccessful if the signature is not successfully verified.</p> <p>This allows validators to customize their own signing scheme for votes. Use cases include:</p> <ul> <li>quantum-secure signature schemes</li> <li>multisig wallets</li> <li>threshold schemes</li> </ul> <p>For more details on validator account abstraction, see the <a rel="external" href="https://github.com/ethereum/casper/blob/master/VALIDATOR_GUIDE.md">Validator Implementation Guide</a>.</p> <h4 id="client-settings-1">Client Settings</h4> <h5 id="enable-casper-fork-choice-1">Enable Casper Fork Choice</h5> <p>Releasing client versions with the casper fork choice as initially default disabled allows for a more conservative transition to hybrid Casper FFG. Under normal operating conditions there are no disparities between the PoW fork choice and the hybrid Casper FFG fork choice. The two fork choice rules can only diverge if either 51% of miners or 51% of validators are faulty.</p> <p>Validators will begin to log on, vote, and finalize the FFG contract before the majority of the network begins explicitly relying upon the new finality mechanism. Once a significant number of validators have logged on and the finality mechanism has been tested on the live network, new client software versions that change the default to enabled will be released.</p> <h5 id="non-revert-min-deposit-1">NON_REVERT_MIN_DEPOSIT</h5> <p><code>NON_REVERT_MIN_DEPOSIT</code> is defined and configurable locally by each client. Clients are in charge of deciding upon the minimum deposits (security) at which they will accept the chain as finalized. In the general case, differing values in the choice of this local constant will not create any fork inconsistencies because clients with very strict finalization requirements will revert to follow the longest PoW chain.</p> <p>Arguments have been made to hardcode a value into clients or the contract, but we cannot reasonably define security required for all clients especially in the context of massive fluctuations in the value of ETH.</p> <h5 id="exclusion-1">Exclusion</h5> <p>This setting is useful in coordinating minority forks in cases of majority collusion.</p> <h5 id="join-fork-1">Join Fork</h5> <p>This setting is to be used by new clients that are syncing the network for the first time. Due to weak subjectivity, a blockhash should be supplied to successfully sync the network when initially starting a node.</p> <p>This setting is also useful for coordinating minority forks in cases of majority collusion.</p> <h5 id="monitor-votes-1">Monitor Votes</h5> <p>Monitoring the network for slashing conditions is key to Casper FFG's "accountable safety" as submitting proof of nefarious activity burns a validator's deposit.</p> <p>This setting is suggested default disabled because the block producer will almost certainly frontrun anyone else submitting a <code>slash</code> transaction. To prevent every client on the network from submitting a <code>slash</code> transaction in the event of a slashing condition, this setting should only be enabled by block producers and those clients who explicitly choose to monitor votes.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the state, fork choice rule, block reward, transaction validity, and gas calculations on certain transactions. Therefore, all changes should be included in a scheduled hardfork at <code>HYBRID_CASPER_FORK_BLKNUM</code>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/1014/ <h3 id="specification">Specification</h3> <p>Adds a new opcode (<code>CREATE2</code>) at <code>0xf5</code>, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to <code>CREATE</code> (<code>0xf0</code>), except using <code>keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]</code> instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.</p> <p>The <code>CREATE2</code> has the same <code>gas</code> schema as <code>CREATE</code>, but also an extra <code>hashcost</code> of <code>GSHA3WORD * ceil(len(init_code) / 32)</code>, to account for the hashing that must be performed. The <code>hashcost</code> is deducted at the same time as memory-expansion gas and <code>CreateGas</code> is deducted: <em>before</em> evaluation of the resulting address and the execution of <code>init_code</code>.</p> <ul> <li><code>0xff</code> is a single byte,</li> <li><code>address</code> is always <code>20</code> bytes,</li> <li><code>salt</code> is always <code>32</code> bytes (a stack item).</li> </ul> <p>The preimage for the final hashing round is thus always exactly <code>85</code> bytes long.</p> <p>The coredev-call at 2018-08-10 decided to use the formula above.</p> <h3 id="motivation">Motivation</h3> <p>Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.</p> <h3 id="rationale">Rationale</h3> <h4 id="address-formula">Address formula</h4> <ul> <li>Ensures that addresses created with this scheme cannot collide with addresses created using the traditional <code>keccak256(rlp([sender, nonce]))</code> formula, as <code>0xff</code> can only be a starting byte for RLP for data many petabytes long.</li> <li>Ensures that the hash preimage has a fixed size,</li> </ul> <h4 id="gas-cost">Gas cost</h4> <p>Since address calculation depends on hashing the <code>init_code</code>, it would leave clients open to DoS attacks if executions could repeatedly cause hashing of large pieces of <code>init_code</code>, since expansion of memory is paid for only once. This EIP uses the same cost-per-word as the <code>SHA3</code> opcode.</p> <h3 id="clarifications">Clarifications</h3> <p>The <code>init_code</code> is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a 'constructor'.</p> <p>This EIP makes collisions possible. The behaviour at collisions is specified by <a rel="external" href="https://github.com/ethereum/EIPs/issues/684">EIP-684</a>:</p> <blockquote> <p>If a contract creation is attempted, due to either a creation transaction or the <code>CREATE</code> (or future <code>CREATE2</code>) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.</p> </blockquote> <p>Specifically, if <code>nonce</code> or <code>code</code> is nonzero, then the create-operation fails.</p> <p>With <a href="https://wg-eips.ritovision.com/161/">EIP-161</a></p> <blockquote> <p>Account creation transactions and the <code>CREATE</code> operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one</p> </blockquote> <p>This means that if a contract is created in a transaction, the <code>nonce</code> is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the <code>init_code</code> itself.</p> <p>It should also be noted that <code>SELFDESTRUCT</code> (<code>0xff</code>) has no immediate effect on <code>nonce</code> or <code>code</code>, thus a contract cannot be destroyed and recreated within one transaction.</p> <h3 id="examples">Examples</h3> <p>Example 0</p> <ul> <li>address <code>0x0000000000000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>init_code <code>0x00</code></li> <li>gas (assuming no mem expansion): <code>32006</code></li> <li>result: <code>0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38</code></li> </ul> <p>Example 1</p> <ul> <li>address <code>0xdeadbeef00000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>init_code <code>0x00</code></li> <li>gas (assuming no mem expansion): <code>32006</code></li> <li>result: <code>0xB928f69Bb1D91Cd65274e3c79d8986362984fDA3</code></li> </ul> <p>Example 2</p> <ul> <li>address <code>0xdeadbeef00000000000000000000000000000000</code></li> <li>salt <code>0x000000000000000000000000feed000000000000000000000000000000000000</code></li> <li>init_code <code>0x00</code></li> <li>gas (assuming no mem expansion): <code>32006</code></li> <li>result: <code>0xD04116cDd17beBE565EB2422F2497E06cC1C9833</code></li> </ul> <p>Example 3</p> <ul> <li>address <code>0x0000000000000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>init_code <code>0xdeadbeef</code></li> <li>gas (assuming no mem expansion): <code>32006</code></li> <li>result: <code>0x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e</code></li> </ul> <p>Example 4</p> <ul> <li>address <code>0x00000000000000000000000000000000deadbeef</code></li> <li>salt <code>0x00000000000000000000000000000000000000000000000000000000cafebabe</code></li> <li>init_code <code>0xdeadbeef</code></li> <li>gas (assuming no mem expansion): <code>32006</code></li> <li>result: <code>0x60f3f640a8508fC6a86d45DF051962668E1e8AC7</code></li> </ul> <p>Example 5</p> <ul> <li>address <code>0x00000000000000000000000000000000deadbeef</code></li> <li>salt <code>0x00000000000000000000000000000000000000000000000000000000cafebabe</code></li> <li>init_code <code>0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef</code></li> <li>gas (assuming no mem expansion): <code>32012</code></li> <li>result: <code>0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C</code></li> </ul> <p>Example 6</p> <ul> <li>address <code>0x0000000000000000000000000000000000000000</code></li> <li>salt <code>0x0000000000000000000000000000000000000000000000000000000000000000</code></li> <li>init_code <code>0x</code></li> <li>gas (assuming no mem expansion): <code>32000</code></li> <li>result: <code>0xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0</code></li> </ul> 2018-04-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Van de Sandeavsa@ethereum.org https://wg-eips.ritovision.com/1015/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would <strong>not be a generic governance solution</strong>, which is a much broader and harder topic, would <strong>not</strong> affect technical upgrade decisions or other hard forks, but seen as <em>a forum to attempt to prevent contentious hard forks</em> that can be solved with the issuance.</p> <h2 id="summary">Summary</h2> <h3 id="thesis-many-controversial-issues-boil-down-to-resources">Thesis: many controversial issues boil down to resources</h3> <p>These are current EIPs that are being developed or debated. They might seem unrelated but they have something in common, that they can be resolved by proper channel of funds.</p> <h4 id="casper-and-pos">Casper and PoS</h4> <p>Moving to PoS has been on the roadmap since day 0 for ethereum, along with a reduction in issuance to a cost equivalent to the Validator's cost of security (considered to be more efficient than PoW). But the exact issuance necessary for PoS has yet to be determined and is currently being researched. Casper validation will be an on chain contract and therefore it will need to be funded. It's unlikely that a definitive final answer on how much issuance is needed for validation will be reached in the next years as new research will uncover new arguments, so it would make sense to allow some flexibility on this matter</p> <h4 id="issuance-cap-at-120-million">Issuance Cap at 120 Million</h4> <p><a rel="external" href="https://github.com/ethereum/EIPs/issues/960">EIP-960</a>, Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by <a rel="external" href="https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd">we don't know enough to know what that ether can be used for</a> and Vitalik's counterpoint is that <a rel="external" href="https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c">reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0</a>. Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider <em>not issuing</em> as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.</p> <h4 id="asics-and-advantages-of-pow">Asics and advantages of PoW</h4> <p><a rel="external" href="https://eips.ethereum.org/EIPS/eip-969">EIP-960</a> proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than <a rel="external" href="https://pdaian.com/blog/anti-asic-forks-considered-harmful/">resisting economies of scale is futile and there might be specific security advantages to specialized hardware</a>. One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that <strong>PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls</strong>.</p> <h4 id="recovery-forks">Recovery Forks</h4> <p>After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: <a rel="external" href="https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3">a general protocol improvement to allow reviving self destructed contracts</a> (which was considered dangerous), a <a rel="external" href="https://github.com/ethereum/EIPs/pull/867">general process to recover funds</a> and a <a href="https://wg-eips.ritovision.com/999/">specific recovery of the multisig library</a>. The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, <a rel="external" href="https://github.com/ethereum/EIPs/issues/156">there are many other special cases of ether provably burnt or stuck</a> that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers.</p> <h4 id="other-public-goods">Other Public Goods</h4> <p>There are many other types of public goods that could be funded by issuance. By <em>Public Good</em>, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, <a href="https://wg-eips.ritovision.com/908/">incentivize full clients and networking</a>, fair distribution of tokens etc.</p> <h2 id="proposed-solution">Proposed Solution</h2> <h3 id="issuance-contract">Issuance Contract</h3> <p>This EIP proposes a future hard fork where block reward is not issued to miners/validators etherbase, but instead to a single contract, that then will activate the default function (with a fixed amount of gas) and then it will forward the ether to other contracts which will finally distribute to their final destinations.</p> <h4 id="limits-on-the-contract">Limits on the contract</h4> <h5 id="it-can-only-deal-with-issuance">It can only deal with issuance</h5> <p>It's not meant to be a general governance contract. The contract <strong>should NOT be used</strong> to decide software updates, to freeze funds, change contract balances or anything on the consensus layer other than the strict definition of <em>where block rewards go</em>. It should be seen as a platform to settle disputes to avoid the implementation of contentious hard forks, not as a mean to remove the power of users and developers to execute them.</p> <h5 id="it-cannot-only-decrease-issuance-and-once-decreased-it-cannot-be-increased-again">It cannot only decrease issuance, and once decreased it cannot be increased again</h5> <p>In order to reduce future abuse and uncertainty, <strong>once issuance is reduced, it cannot be increased</strong>. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the <strong>decision assembly</strong> is aggressively to reduce issuance to zero, it would take a known number of years.</p> <h5 id="results-are-locked-for-s">Results are locked for s</h5> <p>Whenever a new decision on either reducing the issuance or changing the target is made, the effects will have a six-month delay to it. Once a decision is made it is final, it will take place six months after that, but if it's shortly reversed, then that change will be short lived. The rationale behind is that it allows time to anyone disagreeing with the decision to:</p> <ul> <li>Sell their coins so that if a bad actor takes over they will have a reduced reward</li> <li>Attempt to revert the decision as soon as possible, to reduce the duration that the change will take place</li> <li>Organize to create counter measures against the decision</li> <li>Implement a hard fork changing the decision contract or to remove the issuance contract altogether, as a last resort measure</li> </ul> <h5 id="interface">Interface</h5> <p>It would have the following interface:</p> <p><code>function targetContract() returns (address)</code></p> <p>There's a single target contract that should ether issued to. At each new block, that contract would have the default function called so it would forward to the intended addresses.</p> <p><code>function decisionAssembly() returns (address)</code></p> <p>A contract that would represent the internal governance of decisions. More on this later.</p> <p><code>function reduceIssuance(uint)</code></p> <p>Can only be called by <strong>decision assembly</strong>. The contract is allowed to reduce or maintain the issuance per block. <strong>Change is not executed immediately, effects only happen six months later, but once a decision is committed it is irrevocable</strong>.</p> <p><code>function changeTargetContract(address)</code></p> <p>Can only be called by <strong>decision assembly</strong>. It changes the contract that will receive the funds in the future. Only one contract can be appointed, but if the community desires to split issuance or even burn a part of it (in a non-irrevocable manner) it can be done in that contract. Change is not executed immediately, <strong>effects only happen six months later</strong>, but once a decision is committed it is certain, even if it's later reverted: if a new target contract is changed after a few hours, then it still means that in six month's time, it would issue for that contract for a few hours.</p> <p><code>function executeDecision(uint)</code></p> <p>Can be called by anyone: it executes a change to issuance amount or target that had been scheduled six months prior.</p> <h5 id="decision-assembly">Decision Assembly</h5> <p>A contract that has the power to decide the changes to issuance, the core of the governance of these decisions. The exact format of this governance is open to debate, but what follows is a suggestion:</p> <p>The decision would be made by multiple signalling contracts, each one implemented by separate groups and representing one aspect of the community or one sort of measurement. Each signaling process would have a <code>int</code> bound in which they could vote and they would have their own internal process to decide that. As new governance methods are tested and debated, new signalling contracts should be added and removed. Suggested signalling contracts:</p> <ul> <li>Futarchy and prediction markets based on multiple measures</li> <li>Votes weighted by ether balance (optionally with multipliers if the voters were committed to locking votes)</li> <li>Token votes, weighted by their own relative ether exchange rate</li> <li>Votes by individual humans if a good sybil resistance, coercion mechanism is developed</li> <li>Block-signalling, as a way to measure validators/miners choices</li> <li>Some sort of signalling representing developers, exchanges or other stakeholders</li> <li>Any other proposed manner</li> </ul> <p>Since adding and removing signalling contracts, as well as changing their total weight would be controlled by the contract itself, it would be crucial that the first signalling contracts were a diverse set of interests, and that they were open to adding more signals as new governance is experimented as well as removing signals that stop representing the community.</p> <h3 id="questions-to-be-debated">Questions to be debated</h3> <p>A lot of things are suggested in this EIP, so I would like to propose these questions to be debated:</p> <ol> <li>Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol?</li> <li>If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have?</li> <li>If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them?</li> </ol> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-04-18T00:00:00+00:00 2026-02-11T14:49:27+00:00 Anderson Wesleyhttps://github.com/andywesley https://wg-eips.ritovision.com/1010/ <h2 id="simple-summary">Simple Summary</h2> <p>This document proposes to improve the uniformity of ether distribution between wallet address <code>0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B</code> and wallet address <code>0x15E55EF43efA8348dDaeAa455F16C43B64917e3c</code> which are currently experiencing a significant non-uniformity.</p> <h2 id="abstract">Abstract</h2> <p>As of the date of this EIP, the difference in balance between address <code>0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B</code> and address <code>0x15E55EF43efA8348dDaeAa455F16C43B64917e3c</code> is far from equitable or uniform, with the former having more than 365,000 ether more than the latter. The distribution of ether between these two addresses must be improved in order to protect the Ethereum economy from centralized control. This will be accomplished by transferring 100,000 ether from the former address to the latter. This is a properly motivated improvement in keeping with the core Ethereum philosophy of decentralization.</p> <h2 id="motivation">Motivation</h2> <p>This proposal is necessary because the Ethereum protocol does not allow the owner of an address which does not own an equitable amount of ether to claim their share of ether from an address which owns a dangerously centralized quantity. Rather than proposing an overly complicated generic mechanism for any user to claim ether to which they believe they are equitably entitled, this proposal will take the simple route of a one-time transfer of 100,000 ether from <code>0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B</code> to <code>0x15E55EF43efA8348dDaeAa455F16C43B64917e3c</code>. This avoids duplicating the effort of other proposals and provides a net improvement to the Ethereum project and community.</p> <h2 id="specification">Specification</h2> <p>The balance of <code>0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B</code> will be decreased by 100,000 ether. The balance of <code>0x15E55EF43efA8348dDaeAa455F16C43B64917e3c</code> will be increased by 100,000 ether. No net change in the amount of extant ether will occur unless at the time of implementation the former address does not contain sufficient ether for such a deduction.</p> <h2 id="rationale">Rationale</h2> <p>The value 100,000 was chosen after careful technically sound analysis of various economic theories developed over the past century. In spite of the fact that it is a convenient round number, it is actually the exact output of a complex statistical process iterated to determine the optimal distribution of ether between these addresses.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Clients that fail to implement this change will not be aware of the correct balances for these addresses. This will create a hard fork. The implementation of this change consistently among all clients as intended by the proposal process will be sufficient to ensure that backwards compatibility is not a concern.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-04-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Afri Schoedonhttps://github.com/5chdn https://wg-eips.ritovision.com/999/ <h2 id="simple-summary">Simple Summary</h2> <p>This document proposes to restore the contract code of the <code>WalletLibrary</code> contract at <code>0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with a patched version. The contract was accidentally self-destructed and renders a significant amount of Ether inaccessible.</p> <h2 id="abstract">Abstract</h2> <p>The <code>WalletLibrary</code> contract was used by the <a rel="external" href="https://www.parity.io/">Parity Wallet</a> to reduce gas costs for users deploying multi-signature wallets on the Ethereum blockchain. It contained basic functionality such as confirming or revoking multi-signature transactions for any wallet deployed that depends on this library. The <a rel="external" href="https://github.com/paritytech/parity/issues/6995">accidental self-destruction</a> of the library contract caused significant amounts of Ether and other assets owned by many different parties to be inaccessible. This proposal suggests restoring the <code>WalletLibrary</code> by a <a rel="external" href="https://github.com/parity-contracts/0x863df6bfa4">patched</a> version to allow the owners of the dependent multi-signature wallets regain access to their assets.</p> <h2 id="motivation">Motivation</h2> <p>This proposal is necessary because the Ethereum protocol does not allow the restoration of self-destructed contracts and there is no other simple way to enable the affected users and companies regaining access to their tokens and Ether. In opposite to previously discussed proposals, this will not change any EVM semantics and tries to achieve the goal of unfreezing the funds by a single state transition as specified in the next section.</p> <h2 id="specification">Specification</h2> <p>The self-destructed contract code at <a rel="external" href="https://etherscan.io/address/0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4#code"><code>0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code></a> shall be replaced with a patched version of the <a rel="external" href="https://github.com/parity-contracts/0x863df6bfa4/blob/master/contracts/walletLibrary.sol"><code>walletLibrary.sol</code></a> as reviewed, tested, and approved in <a rel="external" href="https://github.com/parity-contracts/0x863df6bfa4">parity-contracts/0x863df6bfa4</a>:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">object</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">606060405234156200000d57fe5b5b6000808054806001018281620000259190620002d9565b916000526020600020900160005b6000909190916101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550506200012081805480602002602001604051908101604052809291908181526020018280548015620000fd57602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019060010190808311620000b2575b505050505060016000620001286401000000000262001d46176401000000009004565b5b5062000330565b600060015411156200013a5760006000fd5b6200015981620001806401000000000262001d71176401000000009004565b620001798383620001c26401000000000262001d9c176401000000009004565b5b5b505050565b60006001541115620001925760006000fd5b80600281905550620001b7620002c16401000000000262001bcf176401000000009004565b6004819055505b5b50565b600060006001541115620001d65760006000fd5b600082111515620001e75760006000fd5b81835110151515620001f95760006000fd5b8251600181905550600090505b8251811015620002b35782818151811015156200021f57fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff16600582600101610100811015156200025357fe5b0160005b508190555080600101610105600085848151811015156200027457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b80600101905062000206565b816000819055505b5b505050565b60006201518042811515620002d257fe5b0490505b90565b815481835581811511620003035781836000526020600020918201910162000302919062000308565b5b505050565b6200032d91905b80821115620003295760008160009055506001016200030f565b5090565b90565b611ebf80620003406000396000f300606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582016889f0740f073d397f9d00b0d19900fb050b957e3e2942f861085beb9baab180029</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">opcodes</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH3 0xD JUMPI INVALID JUMPDEST JUMPDEST PUSH1 0x0 DUP1 DUP1 SLOAD DUP1 PUSH1 0x1 ADD DUP3 DUP2 PUSH3 0x25 SWAP2 SWAP1 PUSH3 0x2D9 JUMP JUMPDEST SWAP2 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST PUSH1 0x0 SWAP1 SWAP2 SWAP1 SWAP2 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP POP PUSH3 0x120 DUP2 DUP1 SLOAD DUP1 PUSH1 0x20 MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD DUP1 ISZERO PUSH3 0xFD JUMPI PUSH1 0x20 MUL DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 PUSH1 0x1 ADD SWAP1 DUP1 DUP4 GT PUSH3 0xB2 JUMPI JUMPDEST POP POP POP POP POP PUSH1 0x1 PUSH1 0x0 PUSH3 0x128 PUSH5 0x100000000 MUL PUSH3 0x1D46 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST POP PUSH3 0x330 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x13A JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH3 0x159 DUP2 PUSH3 0x180 PUSH5 0x100000000 MUL PUSH3 0x1D71 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH3 0x179 DUP4 DUP4 PUSH3 0x1C2 PUSH5 0x100000000 MUL PUSH3 0x1D9C OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x192 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH3 0x1B7 PUSH3 0x2C1 PUSH5 0x100000000 MUL PUSH3 0x1BCF OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x1D6 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH3 0x1E7 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH3 0x1F9 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH3 0x2B3 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x21F JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH3 0x253 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x274 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH3 0x206 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH3 0x2D2 JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH3 0x303 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH3 0x302 SWAP2 SWAP1 PUSH3 0x308 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH3 0x32D SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH3 0x329 JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH3 0x30F JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1EBF DUP1 PUSH3 0x340 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE CALLDATASIZE ISZERO PUSH2 0xEF JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0x173825D9 EQ PUSH2 0x16D JUMPI DUP1 PUSH4 0x2F54BF6E EQ PUSH2 0x1A3 JUMPI DUP1 PUSH4 0x4123CB6B EQ PUSH2 0x1F1 JUMPI DUP1 PUSH4 0x52375093 EQ PUSH2 0x217 JUMPI DUP1 PUSH4 0x5C52C2F5 EQ PUSH2 0x23D JUMPI DUP1 PUSH4 0x659010E7 EQ PUSH2 0x24F JUMPI DUP1 PUSH4 0x7065CB48 EQ PUSH2 0x275 JUMPI DUP1 PUSH4 0x746C9171 EQ PUSH2 0x2AB JUMPI DUP1 PUSH4 0x797AF627 EQ PUSH2 0x2D1 JUMPI DUP1 PUSH4 0xB20D30A9 EQ PUSH2 0x30D JUMPI DUP1 PUSH4 0xB61D27F6 EQ PUSH2 0x32D JUMPI DUP1 PUSH4 0xB75C7DC6 EQ PUSH2 0x39C JUMPI DUP1 PUSH4 0xBA51A6DF EQ PUSH2 0x3C0 JUMPI DUP1 PUSH4 0xC2CF7326 EQ PUSH2 0x3E0 JUMPI DUP1 PUSH4 0xC41A360A EQ PUSH2 0x43B JUMPI DUP1 PUSH4 0xF00D4B5D EQ PUSH2 0x49B JUMPI DUP1 PUSH4 0xF1736D86 EQ PUSH2 0x4F0 JUMPI JUMPDEST PUSH2 0x16B JUMPDEST PUSH1 0x0 CALLVALUE GT ISZERO PUSH2 0x168 JUMPI PUSH32 0xE1FFFCC4923D04B559F4D29A8BFC6CDA04EB5B0D3C460751C2402C5C5CC9109C CALLER CALLVALUE PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x175 JUMPI INVALID JUMPDEST PUSH2 0x1A1 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x516 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x1AB JUMPI INVALID JUMPDEST PUSH2 0x1D7 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x659 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x1F9 JUMPI INVALID JUMPDEST PUSH2 0x201 PUSH2 0x691 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x21F JUMPI INVALID JUMPDEST PUSH2 0x227 PUSH2 0x697 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x245 JUMPI INVALID JUMPDEST PUSH2 0x24D PUSH2 0x69D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x257 JUMPI INVALID JUMPDEST PUSH2 0x25F PUSH2 0x6D7 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x27D JUMPI INVALID JUMPDEST PUSH2 0x2A9 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x6DD JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x2B3 JUMPI INVALID JUMPDEST PUSH2 0x2BB PUSH2 0x829 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x2D9 JUMPI INVALID JUMPDEST PUSH2 0x2F3 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x82F JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x315 JUMPI INVALID JUMPDEST PUSH2 0x32B PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0xDCC JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x335 JUMPI INVALID JUMPDEST PUSH2 0x37E PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP3 ADD DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP2 SWAP1 SWAP2 SWAP3 SWAP1 POP POP PUSH2 0xE06 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x3A4 JUMPI INVALID JUMPDEST PUSH2 0x3BE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x127D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3C8 JUMPI INVALID JUMPDEST PUSH2 0x3DE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x1392 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3E8 JUMPI INVALID JUMPDEST PUSH2 0x421 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x141A JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x443 JUMPI INVALID JUMPDEST PUSH2 0x459 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x149C JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x4A3 JUMPI INVALID JUMPDEST PUSH2 0x4EE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x14BF JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x4F8 JUMPI INVALID JUMPDEST PUSH2 0x500 PUSH2 0x1672 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x53F DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x653 JUMPI PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x57F JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD SUB PUSH1 0x0 SLOAD GT ISZERO PUSH2 0x593 JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x5A5 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH2 0x5E6 PUSH2 0x1890 JUMP JUMPDEST PUSH2 0x5EE PUSH2 0x19D0 JUMP JUMPDEST PUSH32 0x58619076ADF5BB0943D100EF88D52D7C3FD691B19D3A9071B555B651FBF418DA DUP4 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD GT SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x4 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x6C4 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x6D3 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x3 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x704 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x824 JUMPI PUSH2 0x712 DUP3 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x71C JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH2 0x724 PUSH2 0x1890 JUMP JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x739 JUMPI PUSH2 0x738 PUSH2 0x19D0 JUMP JUMPDEST JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x74A JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x785 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SLOAD PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0x994A936646FE87FFE4F1E469D3D6AA417D6B855598397F323DE5B449F765F0C3 DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 DUP3 PUSH2 0x83D DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xDC4 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO DUP1 PUSH2 0x8C7 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ ISZERO JUMPDEST DUP1 PUSH2 0x906 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ ISZERO JUMPDEST ISZERO PUSH2 0xDC2 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xA50 JUMPI PUSH2 0xA49 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xA3F JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xA14 JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xA3F JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xA22 JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP2 POP PUSH2 0xB71 JUMP JUMPDEST PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD PUSH1 0x40 MLOAD DUP1 DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xB4A JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xB1F JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xB4A JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xB2D JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP2 POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xB70 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0xE3A3A4111A84DF27D76B68DC721E65C7711605EA5EEE4AFD3A9C58195217365C CALLER DUP6 PUSH2 0x108 PUSH1 0x0 DUP9 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP10 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP11 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP8 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP2 DUP2 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xD47 JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xD1C JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xD47 JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xD2A JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0xDB7 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x1 SWAP3 POP PUSH2 0xDC3 JUMP JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0xDF3 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xE01 JUMPI DUP2 PUSH1 0x2 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0xE13 CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1273 JUMPI PUSH1 0x0 DUP5 DUP5 SWAP1 POP EQ DUP1 ISZERO PUSH2 0xE30 JUMPI POP PUSH2 0xE2F DUP6 PUSH2 0x1B51 JUMP JUMPDEST JUMPDEST DUP1 PUSH2 0xE3D JUMPI POP PUSH1 0x1 PUSH1 0x0 SLOAD EQ JUMPDEST ISZERO PUSH2 0xFED JUMPI PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xEA4 JUMPI PUSH2 0xE9D DUP6 DUP6 DUP6 DUP1 DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP4 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP1 POP PUSH2 0xEF3 JUMP JUMPDEST DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP6 DUP6 DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xEF2 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0x9738CD1A8777C86B011F7B01D87D484217DC6AB5154A9D41EDA5D14AF8CAF292 CALLER DUP7 DUP9 DUP8 DUP8 DUP7 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 DUP2 MSTORE PUSH1 0x20 ADD DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP6 DUP6 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x1271 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE NUMBER PUSH1 0x40 MLOAD DUP1 DUP5 DUP5 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP4 POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 SWAP2 POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ DUP1 ISZERO PUSH2 0x1099 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ JUMPDEST DUP1 ISZERO PUSH2 0x10D8 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ JUMPDEST ISZERO PUSH2 0x118F JUMPI DUP6 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP DUP5 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP DUP4 DUP4 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SWAP2 SWAP1 PUSH2 0x118D SWAP3 SWAP2 SWAP1 PUSH2 0x1C2E JUMP JUMPDEST POP JUMPDEST PUSH2 0x1198 DUP3 PUSH2 0x82F JUMP JUMPDEST ISZERO ISZERO PUSH2 0x1270 JUMPI PUSH32 0x1733CBB53659D713B79580F79F3F9FF215F78A7C7AA45890F3B89FC5CDDFBF32 DUP3 CALLER DUP8 DUP10 DUP9 DUP9 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP5 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP SWAP5 SWAP4 POP POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x12BE JUMPI PUSH2 0x138C JUMP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP2 POP PUSH2 0x106 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP1 POP PUSH1 0x0 DUP3 DUP3 PUSH1 0x1 ADD SLOAD AND GT ISZERO PUSH2 0x138B JUMPI DUP1 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 DUP2 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD SUB SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH32 0xC7FB647E59B18047309AA15AAD418E5D7CA96D173AD704F1031A2C3D7591734B CALLER DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x13B9 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x1415 JUMPI PUSH1 0x1 SLOAD DUP3 GT ISZERO PUSH2 0x13CD JUMPI PUSH2 0x1414 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP PUSH2 0x13DC PUSH2 0x1890 JUMP JUMPDEST PUSH32 0xACBDB084C721332AC59F9B8E392196C9EB0E4932862DA8EB9BEAF0DAD4F550DA DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP3 POP PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x147F JUMPI PUSH1 0x0 SWAP4 POP PUSH2 0x1493 JUMP JUMPDEST DUP2 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP5 PUSH1 0x1 ADD SLOAD AND EQ ISZERO SWAP4 POP JUMPDEST POP POP POP SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 DUP4 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x14B1 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x14E8 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x166B JUMPI PUSH2 0x14F6 DUP4 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1500 JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x153B JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x1543 PUSH2 0x1890 JUMP JUMPDEST DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x156A JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP DUP2 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0xB532073B38C83145E3E5135377A08BF9AAB55BC0FD7C1179CD4FB995D2A5159C DUP5 DUP5 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x2 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x16BB JUMPI PUSH2 0x1888 JUMP JUMPDEST PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP2 POP PUSH1 0x0 DUP3 PUSH1 0x0 ADD SLOAD EQ ISZERO PUSH2 0x1745 JUMPI PUSH1 0x0 SLOAD DUP3 PUSH1 0x0 ADD DUP2 SWAP1 SSTORE POP PUSH1 0x0 DUP3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP PUSH2 0x107 DUP1 SLOAD DUP1 SWAP2 SWAP1 PUSH1 0x1 ADD PUSH2 0x1710 SWAP2 SWAP1 PUSH2 0x1CAE JUMP JUMPDEST DUP3 PUSH1 0x2 ADD DUP2 SWAP1 SSTORE POP DUP5 PUSH2 0x107 DUP4 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x172D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP DUP2 PUSH1 0x0 NOT AND SWAP1 SSTORE POP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP4 PUSH1 0x1 ADD SLOAD AND EQ ISZERO PUSH2 0x1887 JUMPI PUSH32 0xE1C52DC63B719ADE82E8BEA94CC41A0D5D28E4AAF536ADB5E9CCCC9FF8C1AEDA CALLER DUP7 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH1 0x1 DUP3 PUSH1 0x0 ADD SLOAD GT ISZERO ISZERO PUSH2 0x185E JUMPI PUSH2 0x107 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x180A JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP PUSH1 0x0 SWAP1 SSTORE PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP PUSH1 0x1 SWAP4 POP PUSH2 0x1888 JUMP JUMPDEST DUP2 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP DUP1 DUP3 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD OR SWAP3 POP POP DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x107 DUP1 SLOAD SWAP1 POP SWAP2 POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP2 DUP2 LT ISZERO PUSH2 0x19BC JUMPI PUSH2 0x108 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x18BF JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0x1926 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x0 PUSH1 0x1 MUL PUSH2 0x107 DUP3 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x193D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND EQ ISZERO ISZERO PUSH2 0x19B0 JUMPI PUSH2 0x106 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x196D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP JUMPDEST JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x18A2 JUMP JUMPDEST PUSH2 0x107 PUSH1 0x0 PUSH2 0x19CB SWAP2 SWAP1 PUSH2 0x1CDA JUMP JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SWAP1 POP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT ISZERO PUSH2 0x1B33 JUMPI JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A09 JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A00 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST ISZERO PUSH2 0x1A1B JUMPI DUP1 DUP1 PUSH1 0x1 ADD SWAP2 POP POP PUSH2 0x19E2 JUMP JUMPDEST JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD GT DUP1 ISZERO PUSH2 0x1A45 JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A3D JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1A62 JUMPI PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP PUSH2 0x1A1C JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A8B JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A82 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST DUP1 ISZERO PUSH2 0x1AAC JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AA4 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1B2E JUMPI PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AC3 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AD9 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH2 0x105 PUSH1 0x0 PUSH1 0x5 DUP5 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AF8 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1B24 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP JUMPDEST PUSH2 0x19D7 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 DUP2 MLOAD PUSH1 0x20 DUP4 ADD DUP5 CREATE SWAP1 POP DUP1 EXTCODESIZE ISZERO PUSH2 0x0 JUMPI JUMPDEST SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH2 0x1B5C CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1BC9 JUMPI PUSH1 0x4 SLOAD PUSH2 0x1B6C PUSH2 0x1BCF JUMP JUMPDEST GT ISZERO PUSH2 0x1B89 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP PUSH2 0x1B82 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST PUSH1 0x3 SLOAD DUP3 PUSH1 0x3 SLOAD ADD LT ISZERO DUP1 ISZERO PUSH2 0x1BA5 JUMPI POP PUSH1 0x2 SLOAD DUP3 PUSH1 0x3 SLOAD ADD GT ISZERO JUMPDEST ISZERO PUSH2 0x1BC3 JUMPI DUP2 PUSH1 0x3 PUSH1 0x0 DUP3 DUP3 SLOAD ADD SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SWAP1 POP PUSH2 0x1BC8 JUMP JUMPDEST PUSH1 0x0 SWAP1 POP JUMPDEST JUMPDEST JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH2 0x1BDF JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV PUSH1 0x0 DUP3 SSTORE DUP1 PUSH1 0x1F LT PUSH2 0x1C0C JUMPI POP PUSH2 0x1C2B JUMP JUMPDEST PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1C2A SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH1 0x1F LT PUSH2 0x1C6F JUMPI DUP1 CALLDATALOAD PUSH1 0xFF NOT AND DUP4 DUP1 ADD OR DUP6 SSTORE PUSH2 0x1C9D JUMP JUMPDEST DUP3 DUP1 ADD PUSH1 0x1 ADD DUP6 SSTORE DUP3 ISZERO PUSH2 0x1C9D JUMPI SWAP2 DUP3 ADD JUMPDEST DUP3 DUP2 GT ISZERO PUSH2 0x1C9C JUMPI DUP3 CALLDATALOAD DUP3 SSTORE SWAP2 PUSH1 0x20 ADD SWAP2 SWAP1 PUSH1 0x1 ADD SWAP1 PUSH2 0x1C81 JUMP JUMPDEST JUMPDEST POP SWAP1 POP PUSH2 0x1CAA SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH2 0x1CD5 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH2 0x1CD4 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x0 DUP3 SSTORE SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1CF8 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH2 0x1D1E SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D1A JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D02 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1D43 SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D3F JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D27 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D57 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH2 0x1D60 DUP2 PUSH2 0x1D71 JUMP JUMPDEST PUSH2 0x1D6A DUP4 DUP4 PUSH2 0x1D9C JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D82 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH2 0x1D91 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1DAF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH2 0x1DBF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH2 0x1DD0 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH2 0x1E85 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1DF4 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1E27 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1E47 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x1DDD JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP STOP LOG1 PUSH6 0x627A7A723058 SHA3 AND DUP9 SWAP16 SMOD BLOCKHASH CREATE PUSH20 0xD397F9D00B0D19900FB050B957E3E2942F861085 0xbe 0xb9 0xba 0xab XOR STOP 0x29 </span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">sourceMap</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">2715:10853:0:-;;;3523:112;;;;;;;3552:18;3574:8;:27;;;;;;;;;;;:::i;:::-;;;;;;;;;;;3596:3;3574:27;;;;;;;;;;;;;;;;;;;;;;;3605:26;3616:8;3605:26;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;3626:1;3629;3605:10;;;;;:26;;;:::i;:::-;3523:112;;2715:10853;;7697:168;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7800:23;7813:9;7800:12;;;;;:23;;;:::i;:::-;7827:34;7842:7;7851:9;7827:14;;;;;:34;;;:::i;:::-;7595:1;7697:168;;;;:::o;6966:115::-;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7048:6;7033:12;:21;;;;7070:7;:5;;;;;:7;;;:::i;:::-;7058:9;:19;;;;7595:1;6966:115;;:::o;3977:349::-;4171:6;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;4088:1;4076:9;:13;4068:22;;;;;;;;4120:9;4102:7;:14;:27;;4094:36;;;;;;;;4148:7;:14;4134:11;:28;;;;4180:1;4171:10;;4166:131;4187:7;:14;4183:1;:18;4166:131;;;4238:7;4246:1;4238:10;;;;;;;;;;;;;;;;;;4233:16;;4215:8;4228:1;4224;:5;4215:15;;;;;;;;;;;;:34;;;;;4291:1;4287;:5;4254:12;:30;4272:7;4280:1;4272:10;;;;;;;;;;;;;;;;;;4267:16;;4254:30;;;;;;;;;;;:38;;;;4166:131;4203:3;;;;;4166:131;;;4313:9;4300:10;:22;;;;7595:1;3977:349;;;;:::o;12529:73::-;12572:4;12593:6;12587:3;:12;;;;;;;;12580:19;;12529:73;;:::o;2715:10853::-;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::i;:::-;;;;;:::o;:::-;;;;;;;;;;;;;;;;;;;;;;;;;;;:::o;:::-;;;;;;;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span></span> <span class="giallo-l"><span class="z-support"> &quot;</span><span class="z-support">linkReferences</span><span class="z-support">&quot;</span><span>:</span><span> {</span><span>}</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>To verify the byte-code above, a patched version is deployed at <a rel="external" href="https://etherscan.io/address/0x21C9E434c669c4d73f55215A6F2130A185E127AC#code"><code>0x21C9E434c669c4d73f55215A6F2130A185E127AC</code></a> to be reviewed. The compiler settings used can be extracted from the following meta-data:</p> <pre class="giallo z-code"><code data-lang="json"><span class="giallo-l"><span>{</span><span class="z-support">&quot;</span><span class="z-support">compiler</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">version</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0.4.10+commit.f0d539ae</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">language</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">Solidity</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">output</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">abi</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">removeOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_addr</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">isOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bool</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">m_numOwners</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">m_lastDay</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">resetSpentToday</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">m_spentToday</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">addOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">m_required</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_h</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">confirm</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">o_success</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bool</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_newLimit</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">setDailyLimit</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_to</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_value</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_data</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">execute</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">o_hash</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">revoke</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_newRequired</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">changeRequirement</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">hasConfirmed</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bool</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">ownerIndex</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">getOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_from</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_to</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">changeOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">constant</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">m_dailyLimit</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">outputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">function</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">constructor</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">payable</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">true</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">fallback</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">Confirmation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">Revoke</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">oldOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">newOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">OwnerChanged</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">newOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">OwnerAdded</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">oldOwner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">OwnerRemoved</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">newRequirement</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">RequirementChanged</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">_from</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">value</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">Deposit</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">value</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">to</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">data</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">created</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">SingleTransact</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">owner</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">value</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">to</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">data</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">created</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">MultiTransact</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">anonymous</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">inputs</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">operation</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes32</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">initiator</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">value</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">uint256</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">to</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">address</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">indexed</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">data</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bytes</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">name</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">ConfirmationNeeded</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">type</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">event</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>]</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">devdoc</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">methods</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span>}</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">userdoc</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">methods</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span>}</span><span>}</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">settings</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">compilationTarget</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">browser/WalletLibrary.sol</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">WalletLibrary</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">libraries</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">optimizer</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">enabled</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">false</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">runs</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">200</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">remappings</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span>]</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">sources</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">browser/WalletLibrary.sol</span><span class="z-support">&quot;</span><span>:</span><span>{</span><span class="z-support">&quot;</span><span class="z-support">keccak256</span><span class="z-support">&quot;</span><span>:</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0xf72fcdc85e15f93172878ca6a61fb81604d1052e9e724bc3896d65b3b4ab1bb0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">urls</span><span class="z-support">&quot;</span><span>:</span><span>[</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">bzzr://009bd59bd78f59804eaffb6111d341caea58888f8e5b5f75aebdf009fc6136c0</span><span class="z-punctuation z-definition z-string">&quot;</span><span>]</span><span>}</span><span>}</span><span>,</span><span class="z-support">&quot;</span><span class="z-support">version</span><span class="z-support">&quot;</span><span>:</span><span class="z-constant">1</span><span>}</span></span></code></pre> <p>The differences to the originally deployed contract code can be reviewed at:</p> <ul> <li><a rel="external" href="https://github.com/parity-contracts/0x863df6bfa4/pull/2">parity-contracts/0x863df6bfa4#2</a>: Remove the <code>selfdestruct()</code></li> <li><a rel="external" href="https://github.com/parity-contracts/0x863df6bfa4/pull/3">parity-contracts/0x863df6bfa4#3</a>: Initialize the library owner to <code>0x0</code></li> </ul> <p>The following sections propose two equivalent specifications, 999a and 999b, which technically achieve the same results. To implement this proposal only one of them has to be applied.</p> <h3 id="direct-state-transition-via-bytecode-999a">Direct State Transition via Bytecode (999a)</h3> <p>At <code>CNSTNTNPL_FORK_BLKNUM</code>, directly recreate the account <code>0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with the following parameters:</p> <ul> <li>Nonce: <code>0x1</code></li> <li>Code:</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0x606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582084feb3505964efa62a6ffa78d913a175fe7bc168dd50067d25b1d5ddb6d10a1e0029</span></span></code></pre> <ul> <li>Storage: <ul> <li><code>0x0000000000000000000000000000000000000000000000000000000000000000</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> <li><code>0x0000000000000000000000000000000000000000000000000000000000000001</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> <li><code>0x0000000000000000000000000000000000000000000000000000000000000004</code>: <code>0x00000000000000000000000000000000000000000000000000000000000044e1</code></li> <li><code>0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> </ul> </li> </ul> <p>The balance of the account shall be left unchanged.</p> <h3 id="alternate-specification-via-codehash-999b">Alternate Specification via Codehash (999b)</h3> <p>At <code>CNSTNTNPL_FORK_BLKNUM</code>, directly recreate the account <code>0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with the following parameters:</p> <ul> <li>Nonce: <code>0x1</code></li> <li>Storage: <ul> <li><code>0x0000000000000000000000000000000000000000000000000000000000000000</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> <li><code>0x0000000000000000000000000000000000000000000000000000000000000001</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> <li><code>0x0000000000000000000000000000000000000000000000000000000000000004</code>: <code>0x00000000000000000000000000000000000000000000000000000000000044e1</code></li> <li><code>0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d</code>: <code>0x0000000000000000000000000000000000000000000000000000000000000001</code></li> </ul> </li> </ul> <p>In addition, the codehash at that address shall be replaced by the codehash at address <code>0x21C9E434c669c4d73f55215A6F2130A185E127AC</code>. The codehash is <code>0x6209d55547da7b035d54ef8d73275e863d3072b91da6ace1614fa6381f4e2c09</code>. The balance of the account shall be left unchanged.</p> <h2 id="rationale">Rationale</h2> <p>The design decision to restore the <code>WalletLibrary</code> contract code in a single state transition was made after lengthy discussions of <a rel="external" href="https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3">alternate proposals</a> that explored different ways to improve the Ethereum protocol to allow contract revivals by adding different built-in contracts. It was eventually concluded that all of these proposals changing the EVM semantics around self-destructed contracts were introducing unwanted side-effects and <a rel="external" href="https://medium.com/@weka/on-paritys-proposed-changes-to-selfdestruct-behaviour-c3f0e5bc0f49">potential risks</a> to the existing smart-contract ecosystem on the Ethereum platform.</p> <p>The total supply of Ether is neither changed nor does this proposal require the transfer of any tokens or assets including Ether. It is assumed that this change is aligned with the interests both of (A) Parity Technologies that intended to provide a smart-contracts library for multi-signature wallets to last forever for its users and (B) the users of the multi-signature wallets that meant to safely store their assets in a contract accessible any time they desire. Lastly, the client-side implementation cost of this proposal is estimated to be low. A sample implementation will be attached and linked in the following sections.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal introduces backwards incompatibilities in the state of the contract at <code>0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code>. The Ethereum protocol does not allow the restoration of self-destructed contracts. To implement this on the Ethereum blockchain, it is recommended to add the necessary state transition in a future hard-fork at a well-defined block number, e.g., <code>CNSTNTNPL_FORK_BLKNUM</code> for the Constantinople milestone which is supposed to be the next scheduled hard-fork on the Ethereum road-map.</p> <h2 id="implementation">Implementation</h2> <p>A proof-of-concept implementation is available for the Parity client on branch <a rel="external" href="https://github.com/paritytech/parity/compare/a5-eip999-poc"><code>a5-eip999-poc</code></a> (<a rel="external" href="https://github.com/paritytech/parity/pull/8406">#8406</a>). A sample chain configuration for Parity can be found at the same branch in <a rel="external" href="https://github.com/paritytech/parity/blob/891e633021eec78dd62104bf5a99af50f66b06c7/ethcore/res/ethereum/multisig_test.json#L38-L51"><code>multisig_test.json</code></a> describing the state change as specified above.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-04-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 David Stanfilldavid@airsquirrels.com https://wg-eips.ritovision.com/969/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm.</p> <h2 id="abstract">Abstract</h2> <p>There are companies who currently have dedicated hardware based ethereum miners in production, and may be actively mining. This EIP aims to "poison the well" by modifying the block mining algorithm in a low risk manner that may <em>"break"</em> these miners if they are in-fact built as traditional ASICs.</p> <h2 id="motivation">Motivation</h2> <p>ASIC-based miners will have lower operational costs than GPU-based miners, which will result in GPU-based mining quickly becoming unprofitable. Given that production of ASIC-based miners has a high barrier to entry and few market players, this will cause a trend towards centralization of mining power.</p> <p>Risks include market dominance by a single manufacturer that may utilize production stock to mine themselves, introduce backdoors in their hardware, or facilitate a 51% attack that would otherwise be infeasible.</p> <p>This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities.</p> <p>Ethash remains ASIC-resistant, however ASIC manufacturer technology is advancing and ethash may require further changes in order to remain resistant to unforeseen design techniques. This EIP seeks explicitly to buy time during which newly-developed ASIC technology will face a barrier while more long-term mechanisms to ensure continued ASIC resistance can be explored.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= ASIC_MITIGATION_FORK_BLKNUM</code>, require that the ethash solution sealing the block has been mined using <code>ethashV2</code>.</p> <h2 id="ethashv2">EthashV2</h2> <p><code>ethashV2</code> will be identical in specification to the current <code>ethash</code>(v1) algorithm, with the exception of the implementation of <code>fnv</code>.</p> <p>The new algorithm replaces the 5 current uses of <code>fnv</code> inside <code>hashimoto</code> with 5 separate instances defined as <code>fnvA</code>, <code>fnvB</code>, <code>fnvC</code>, <code>fnvD</code>, and <code>fnvE</code>, utilizing</p> <pre class="giallo z-code"><code data-lang="c"><span class="giallo-l"><span>FNV_PRIME_A</span><span class="z-keyword">=</span><span class="z-keyword">0x</span><span class="z-constant">10001a7</span></span> <span class="giallo-l"><span>FNV_PRIME_B</span><span class="z-keyword">=</span><span class="z-keyword">0x</span><span class="z-constant">10001ab</span></span> <span class="giallo-l"><span>FNV_PRIME_C</span><span class="z-keyword">=</span><span class="z-keyword">0x</span><span class="z-constant">10001cf</span></span> <span class="giallo-l"><span>FNV_PRIME_D</span><span class="z-keyword">=</span><span class="z-keyword">0x</span><span class="z-constant">10001e3</span></span> <span class="giallo-l"><span>FNV_PRIME_E</span><span class="z-keyword">=</span><span class="z-keyword">0x</span><span class="z-constant">10001f9</span></span></code></pre> <p><code>fnvA</code> replaces <code>fnv</code> in the DAG item selection step; <code>fnvB</code> replaces <code>fnv</code> in the DAG item mix step; <code>fnvC(fnvD(fnvE</code> replaces <code>fnv(fnv(fnv(</code> in the compress mix step.</p> <p><code>fnv</code> as utilized in DAG-item creation should remain unchanged.</p> <h2 id="agent-changes-optional-variant">Agent Changes (Optional Variant)</h2> <p>The JSON-RPC <code>eth_GetWork</code> call may optionally return the proposed blocks algorithm. While a miner or pool may infer the requirement for <code>ethashV2</code> based on the computed epoch of the provided seedHash, it is beneficial to explicitly provide this field so a miner does not require special configuration when mining on a chain that chooses not to implement the <code>ASIC_Mitigation</code> hardfork.</p> <p>Due to compatibility concerns with implementations that already add additional parameters to <code>GetWork</code>, it is desired to add <code>BlockNumber</code> as an explicit 4th parameter as suggested in https://github.com/ethereum/go-ethereum/issues/2333. Algorithm should then be returned as either <code>"ethash"</code> or <code>"ethashV2"</code> according to the <code>block.number &gt;= ASIC_MITIGATION_FORK_BLKNUM</code> criteria.</p> <h2 id="rationale">Rationale</h2> <p>This EIP is aimed at breaking existing ASIC-based miners via small changes to the existing ethash algorithm. We hope to accomplish the following:</p> <ol> <li>Break existing ASIC-based miners.</li> <li>Demonstrate a willingness to fork in the event of future ASIC miner production.</li> </ol> <p>Goal #1 is something that we can only do probabilistically without detailed knowledge of existing ASIC miner design. The known released miner is available for purchase <a rel="external" href="https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7">here</a>, with delivery slated for mid-summer 2018.</p> <p>Our approach should balance the inherent security risks involved with changing the mining algorithm with the risk that the change we make does not break existing ASIC miners. This EIP leans towards minimizing the security risks by making minimal changes to the algorithm, accepting the risk that the change may not break dedicated hardware miners that utilize partially- or fully-configurable logic.</p> <p>Furthermore, we do not wish to introduce significant algorithm changes that may alter the power utilization or performance profile of existing GPU hardware.</p> <p>The change of FNV constant is a minimal change that can be quickly implemented across the various network node and miner implementations.</p> <p>It is proposed that <code>ASIC_MITIGATION_FORK_BLKNUM</code> be no more than 5550000 (epoch 185), giving around 30 days of notice to node and miner developers and a sufficient window for formal analysis of the changes by experts. We must weigh this window against the risk introduced by allowing ASICs that may exist to continue to propagate on the network, as well as the risk of providing too much advanced warning to ASIC developers.</p> <p>It is further understood that this change will not prevent redesign of existing dedicated hardware with new ASIC chips. The intention of this change is only to disable currently active or mid-production hardware and provide time for POS development as well as larger algorithm changes to be well analyzed by experts.</p> <p>The choice of FNV constants is made based on the formal specification at https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1</p> <p>@goobur provided the following python code to output primes matching this criteria:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>candidates</span><span class="z-keyword"> =</span><span> [</span><span class="z-constant">2</span><span class="z-keyword">**</span><span class="z-constant">24</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">8</span><span class="z-keyword"> +</span><span> _</span><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span class="z-variable"> xrange</span><span>(</span><span class="z-constant">256</span><span>)</span><span>]</span></span> <span class="giallo-l"><span>candidates</span><span class="z-keyword"> =</span><span> [</span><span>_</span><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span> candidates</span><span class="z-keyword"> if</span><span> is_prime</span><span>(</span><span>_</span><span>)</span><span>]</span></span> <span class="giallo-l"><span>[</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">0x</span><span class="z-constant">%x</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword"> %</span><span> _</span><span class="z-keyword"> for</span><span> _</span><span class="z-keyword"> in</span><span> candidates</span><span class="z-keyword"> if</span><span> _</span><span class="z-keyword"> %</span><span> (</span><span class="z-constant">2</span><span class="z-keyword">**</span><span class="z-constant">40</span><span class="z-keyword"> -</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">24</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> &gt;</span><span> (</span><span class="z-constant">2</span><span class="z-keyword">**</span><span class="z-constant">24</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">8</span><span class="z-keyword"> +</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">7</span><span>)</span><span>]</span></span></code></pre> <p>The minimal prime constraint was relaxed, as has already been the case in <code>ethashV1</code>.</p> <p>Typical ASIC synthesis tools would optimize multiplication of a constant in the FNV algorithm, while reducing the area needed for the multiplier according to the hamming weight of the constant. To reduce the chance of ASIC adaptation through minor mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too large of a weight.</p> <p>The current FNV prime, <code>0x1000193</code>, has a hamming weight of 6.</p> <pre class="giallo z-code"><code data-lang="c"><span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001a7</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 7</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001ab</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 7</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001cf</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 8</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001e3</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 7</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001ef</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 9</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Not chosen</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001f9</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 8</span><span>;</span></span> <span class="giallo-l"><span class="z-entity z-name">HammingWeight</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">10001fb</span><span>)</span><span class="z-keyword"> =</span><span class="z-constant"> 9</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Not chosen</span></span></code></pre> <p>An analysis can be done regarding the dispersion of these constants as compared to <code>0x01000193</code>, using the following snippet.</p> <pre class="giallo z-code"><code data-lang="c"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> https://eips.ethereum.org/EIPS/eip-969</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">include</span><span class="z-punctuation z-definition z-string"> &lt;</span><span class="z-string">stdlib.h</span><span class="z-punctuation z-definition z-string">&gt;</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">include</span><span class="z-punctuation z-definition z-string"> &lt;</span><span class="z-string">stdio.h</span><span class="z-punctuation z-definition z-string">&gt;</span></span> <span class="giallo-l"><span class="z-keyword">#</span><span class="z-keyword">include</span><span class="z-punctuation z-definition z-string"> &lt;</span><span class="z-string">string.h</span><span class="z-punctuation z-definition z-string">&gt;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">int</span><span class="z-entity z-name"> main</span><span>(</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> u_int32_t</span><span> candidate </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> u_int32_t</span><span> dups </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> u_int32_t</span><span> fnv_candidate </span><span class="z-keyword">=</span><span class="z-keyword"> 0x</span><span class="z-constant">10001a7</span><span>;</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> MODIFY!</span></span> <span class="giallo-l"><span class="z-support"> u_int8_t</span><span class="z-keyword"> *</span><span>counts </span><span class="z-keyword">=</span><span class="z-entity z-name"> malloc</span><span>(</span><span class="z-keyword">0x</span><span class="z-constant">FFFFFFFF</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name"> memset</span><span>(</span><span>counts</span><span>,</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-constant">\0</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-keyword"> 0x</span><span class="z-constant">FFFFFFFF</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> for</span><span> (</span><span>candidate </span><span class="z-keyword">=</span><span class="z-constant"> 0</span><span>;</span><span> candidate </span><span class="z-keyword">&lt;</span><span class="z-keyword"> 0x</span><span class="z-constant">FFFFFFFF</span><span>;</span><span> candidate</span><span class="z-keyword">++</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> u_int32_t</span><span> result </span><span class="z-keyword">=</span><span> (</span><span class="z-support">u_int32_t</span><span>)</span><span>(</span><span>candidate </span><span class="z-keyword">*</span><span> fnv_candidate</span><span>)</span><span>;</span></span> <span class="giallo-l"><span class="z-support"> u_int8_t</span><span> oldCount </span><span class="z-keyword">=</span><span class="z-variable"> counts</span><span>[</span><span>result</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-variable"> counts</span><span>[</span><span>result</span><span>]</span><span class="z-keyword"> =</span><span class="z-variable"> counts</span><span>[</span><span>result</span><span>]</span><span class="z-keyword">+</span><span class="z-constant">1</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> (</span><span>oldCount </span><span class="z-keyword">!=</span><span class="z-constant"> 0</span><span>)</span><span> {</span></span> <span class="giallo-l"><span> dups</span><span class="z-keyword">++</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> ////</span><span class="z-comment"> progress display: remove comment to speed down</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment">if ((candidate &amp; 0xFFFFF) == 0xFFFFF) printf(&quot;0x%08x\n&quot;, candidate);</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span class="z-entity z-name"> printf</span><span>(</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-constant">\n</span><span class="z-string">FNV candidate 0x</span><span class="z-constant">%08x</span><span class="z-string"> : </span><span class="z-constant">%i</span><span class="z-string"> dups</span><span class="z-constant">\n</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span> fnv_candidate</span><span>,</span><span> dups</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-constant"> 0</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>It can be empirically confirmed that no more than 1 duplicate occurs in the 32-bit word space with these constants.</p> <p>It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. That said, a more invasive hash algorithm change could be considered.</p> <p>One suggestion has been <a rel="external" href="https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp">MurmurHash3</a>.</p> <p><a rel="external" href="https://twitter.com/el33th4xor/status/981292363627810818">Other suggestions have been made</a>: <a rel="external" href="https://github.com/P-H-C/phc-winner-argon2">Argon2</a>, <a rel="external" href="https://blog.z.cash/why-equihash/">Equihash</a> of Zcash fame, and <a rel="external" href="https://crypto.stanford.edu/balloon/">Balloon Hashing</a>.</p> <p>Another possible candidate is <a rel="external" href="https://github.com/tromp/cuckoo">Cuckoo Cycle</a>, although there are some concerns regarding unaddressed optimization vulnerabilities. One review can be found <a rel="external" href="https://da-data.blogspot.com/2014/03/a-public-review-of-cuckoo-cycle.html">here</a>.</p> <p>This may be considered once the exact mechanism of the released ASICs is known and their effectiveness against its optimisations can be fully evaluated.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change implements a backwards incompatible change to proof of work based block mining. All existing miners will be required to update to clients which implement this new algorithm, and all nodes will require updates to accept solutions from the new proof of work algorithm.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO: will need to generate test cases for <code>ethereum/tests</code> repository corresponding to the consensus changes.</p> <h2 id="implementation">Implementation</h2> <p>TODO</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-03-31T00:00:00+00:00 2026-02-11T14:49:28+00:00 Alexandre Bellingalexandrebelling8@gmail.com https://wg-eips.ritovision.com/1895/ <h2 id="simple-summary">Simple Summary</h2> <p>The EVM currently supports elliptic curves operations for curve <em>alt-bn128</em> thanks to precompiles <code>ecadd</code> and <code>ecmul</code> and <code>ecpairing</code>. The classes MNT4 and 6 contain cycles of curves. Those cycles enable doing operations on one curve inside a SNARK on the other curve (and reversely). This EIP suggests adding support for those curves.</p> <h2 id="abstract">Abstract</h2> <p>Adds supports for the following operations through precompiles:</p> <ul> <li><code>ecadd</code> on MNT4</li> <li><code>ecmul</code> on MNT4</li> <li><code>ecpairing</code> on MNT4</li> </ul> <h2 id="motivation">Motivation</h2> <p>Elliptic curve is the basic block of recursive SNARKs (ie: verifying a SNARK inside a SNARK) and this addresses the issue of scalable zero-knowledge. More generally this addresses partly the scalability issue as SNARKs verification are constant time in the size of the circuit being verified.</p> <p>More concretely, today if the EVM has to deal with 1000s of SNARK verification it would take around 1.5 billion gas and would be impractical for Ethereum. Recursive SNARKs for instance make it possible to aggregate multiple proofs into a single one that can be verified like any other SNARK. It results in a massive cost reduction for the verification.</p> <p>However, this is impossible using <em>alt-bn128</em> and in my knowledge, the only family of pairing-friendly curves known to produce cycles are MNT4 and MNT6. A complete characterization of the cycles existing between those two families is proposed in <a rel="external" href="https://arxiv.org/pdf/1803.02067.pdf">On cycles of pairing-friendly elliptic curves </a></p> <h2 id="specification">Specification</h2> <h3 id="the-curve">The curve</h3> <p>The proposed cycle has been introduced in <a rel="external" href="https://eprint.iacr.org/2014/595.pdf">Scalable Zero Knowledge via Cycles of Elliptic Curves</a>.</p> <h3 id="mnt4-definition">MNT4 definition</h3> <p>The groups <code>G_1</code> and <code>G_2</code> are cyclic groups of prime order :</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>q = 475922286169261325753349249653048451545124878552823515553267735739164647307408490559963137</span></span></code></pre> <p><code>G_1</code> is defined over the field <code>F_p</code> of prime order :</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>p = 475922286169261325753349249653048451545124879242694725395555128576210262817955800483758081</span></span></code></pre> <p>with generator P:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>P = (</span></span> <span class="giallo-l"><span> 60760244141852568949126569781626075788424196370144486719385562369396875346601926534016838,</span></span> <span class="giallo-l"><span> 363732850702582978263902770815145784459747722357071843971107674179038674942891694705904306</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Both p and q can be written in 298 bits.</p> <p>The group G_1 is defined on the curve defined by the equation <code>Y² = X³ + aX + b</code> where:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> a = 2</span></span> <span class="giallo-l"><span> b = 423894536526684178289416011533888240029318103673896002803341544124054745019340795360841685</span></span></code></pre> <p>The twisted group G_2 is defined over the field <code>F_p^2 = F_p / &lt;&lt;To be completed&gt;&gt;</code></p> <p>The twisted group G_2 is defined on the curve defined by the equation <code>Y² = X² + aX + b</code> where :</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> a = 34 + i * 0</span></span> <span class="giallo-l"><span> b = 0 + i * 67372828414711144619833451280373307321534573815811166723479321465776723059456513877937430</span></span></code></pre> <p>G_2 generator is generated by :</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> P2 = (</span></span> <span class="giallo-l"><span> 438374926219350099854919100077809681842783509163790991847867546339851681564223481322252708 +</span></span> <span class="giallo-l"><span> i * 37620953615500480110935514360923278605464476459712393277679280819942849043649216370485641,</span></span> <span class="giallo-l"><span> 37437409008528968268352521034936931842973546441370663118543015118291998305624025037512482 +</span></span> <span class="giallo-l"><span> i * 424621479598893882672393190337420680597584695892317197646113820787463109735345923009077489</span></span> <span class="giallo-l"><span> )</span></span></code></pre><h3 id="the-operations-and-gas-cost">The operations and gas cost</h3> <p>The following operations and their gas cost would be implemented</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>MNT_X_ADD = &lt;&lt;To be estimated&gt;&gt;</span></span> <span class="giallo-l"><span>MNT_X_MUL = &lt;&lt;To be estimated&gt;&gt;</span></span> <span class="giallo-l"><span>MNT_X_PAIRING = &lt;&lt;To be estimated&gt;&gt;</span></span></code></pre> <p>Where <code>X</code> is either 4.</p> <h3 id="encoding">Encoding</h3> <p>The curves points P(X, Y) over F_p are represented in their compressed form C(X, Y):</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> C = X | s</span></span></code></pre> <p>where <code>s</code> represents <code>Y</code> as follow:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> | `s&#39;` | `Y` |</span></span> <span class="giallo-l"><span> |--------|--------------------------|</span></span> <span class="giallo-l"><span> | `0x00` | Point at infinity |</span></span> <span class="giallo-l"><span> | `0x02` | Solution with `y` even |</span></span> <span class="giallo-l"><span> | `0x03` | Solution with `y` odd |</span></span></code></pre> <p>Compression operation from affine coordinate is trivial:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> s = 0x02 | (s &amp; 0x01)</span></span></code></pre> <p>In the EVM the compressed form allows us to represents curve points with 2 uint256 instead of 3.</p> <h3 id="edge-cases">Edge cases</h3> <ul> <li>Several acceptable representations for the point at infinity</li> </ul> <h2 id="rationale">Rationale</h2> <p>The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transferring several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found).</p> <p>Independently of the cycle chosen, the groups and field elements are represented with integers larger than 256 bits (even for the 80 bits of security), therefore it might be necessary to also add support for larger field size operations.</p> <p>We currently don't know more efficient pairing-friendly cycles and don't know if there are. It might be possible to circumvent this problem though by relaxing the constraint that all the curves of the cycle must be pairing friendly). If we had a cycle with only one pairing friendly curve we would still be able to compose proofs by alternating between SNARKs and any other general purpose zero-knowledge cryptosystems.</p> <p>Assuming we find a convenient cycle, we don't need to implement support for all the curves it contains, only one. The best choice would be the fastest one as the overall security of the recursive snark do not depends on which curve the verification is made.</p> <p>Proper benchmarks will be done in order to make this choice and to price the operations in gas.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="references">References</h2> <ul> <li><em>Eli-Ben-Sasson, Alessandro Chiesa, Eran Tromer, Madars Virza, [BCTV14], April 28, 2015, Scalable Zero Knowledge via Cycles of Elliptic Curves : https://eprint.iacr.org/2014/595.pdf</em></li> <li><em>Alessandro Chiesa, Lynn Chua, Matthew Weidner, [CCW18], November 5, 2018, On cycles of pairing-friendly elliptic curves : https://arxiv.org/pdf/1803.02067.pdf</em></li> </ul> <h2 id="implementation">Implementation</h2> <ul> <li><a rel="external" href="https://github.com/AlexandreBelling/go-boojum">go-boojum</a> : A PoC demo of an application of recursive SNARKs</li> <li><a rel="external" href="https://github.com/scipr-lab/libff">libff</a> : a C++ library for finite fields and elliptic curves</li> <li><a rel="external" href="https://github.com/CodaProtocol/coda">coda</a> : a new cryptocurrency protocol with a lightweight, constant sized blockchain.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-03-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Tobias Obersteintobias.oberstein@crossbario.com https://wg-eips.ritovision.com/665/ <h2 id="simple-summary">Simple Summary</h2> <p>Support performant and cheap verification of Ed25519 cryptographic signatures in smart contracts in general by adding a precompiled contract for Ed25519 signature verification to the EVM.</p> <h2 id="abstract">Abstract</h2> <p>Verification of Ed25519 cryptographic signatures is obviously possible in EVM bytecode. However, the gas cost will be very high, and computationally expensive, as such tight, wide word operations intensive code as required for Ed25519 is not a good fit for the EVM bytecode model.</p> <p>The addition of a native compiled function, in a precompiled contract, to the EVM solves both cost and performance problems.</p> <h2 id="motivation">Motivation</h2> <p>Ed25519 and Ed448 (that is, EdDSA using Curve25519 or Curve448) are IETF recommendations (<a rel="external" href="https://tools.ietf.org/html/rfc7748">RFC7748</a>) with some attractive properties:</p> <ul> <li>Ed25519 is intended to operate at around the 128-bit security level and Ed448 at around the 224-bit security level</li> <li>EdDSA uses small public keys (32 or 57 octets) and signatures (64 or 114 octets) for Ed25519 and Ed448, respectively</li> <li>Ed25519/Ed448 are designed so that fast, constant-time (timing attack resistant) and generally side-channel resistant implementations are easier to produce</li> </ul> <p>Despite being around only for some years, post-Snowden, these curves <a rel="external" href="https://ianix.com/pub/ed25519-deployment.html">have gained wide use</a> quickly in various protocols and systems:</p> <ul> <li>TLS / ECDH(E) (session keys)</li> <li>TLS / x.509 (client and server certificates)</li> <li>DNSSEC (zone signing)</li> <li>OpenSSH (user keys)</li> <li>GNUPG/OpenPGP (user keys)</li> <li>OpenBSD Signify (software signing)</li> </ul> <p>One motivation for Ed25519 signature verification in smart contracts is to <strong>associate</strong> existing off-chain systems, records or accounts that use Ed25519 (like above) with blockchain addresses or <strong>delegate</strong> by allowing to sign data with Ed25519 (only), and then submit this Ed25519-signed data anonymously (via any Eth sender address) to the blockchain, having the contract check the Ed25519 signature of the transaction.</p> <p>Another motivation is the processing of external, Ed25519 proof-of-stake based blockchains within Ethereum smart contracts.</p> <p>When a transactions contains data that comes with an Ed25519 signature, that proves that the sender of the Ethereum transaction was also in control of the private key (and the data), and this allows the contract to establish an association between the blockchain and the external system or account, and the external system establish the reverse relation.</p> <p>For example, a contract might check a Ed25519 signed piece of data submitted to the Ethereum transaction like the current block number. That proves to the contract, that the sender is in possession of both the Ethereum private key and the Ed25519 private key, and hence the contract will accept an association between both. This again can be the root anchor for various powerful applications, as now a potentially crypto holding key owner has proven to be in control of some external off-chain system or account, like e.g. a DNS server, a DNS domain, a cluster node and so on.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= CONSTANTINOPLE_FORK_BLKNUM</code>, add a precompiled contract for Ed25519 signature verification (<code>ED25519VFY</code>).</p> <p>The proposal adds a new precompiled function <code>ED25519VFY</code> with the following input and output.</p> <p><code>ED25519VFY</code> takes as <strong>input 128 octets</strong>:</p> <ol> <li><strong>message</strong>: the 32-octet message that was signed</li> <li><strong>public key</strong>: the 32-octet Ed25519 public key of the signer</li> <li><strong>signature</strong>: the 64-octet Ed25519 signature</li> </ol> <p><code>ED25519VFY</code> returns as <strong>output 4 octets</strong>:</p> <ul> <li><code>0x00000000</code> if signature is valid</li> <li>any non-zero value indicates a signature verification failure</li> </ul> <h3 id="address">Address</h3> <p>The address of <code>ED25519VFY</code> is <strong><code>0x9</code>.</strong></p> <h3 id="gas-costs">Gas costs</h3> <p>Gas cost for <code>ED25519VFY</code> is <strong>2000</strong>.</p> <h2 id="rationale">Rationale</h2> <p>The proposed <code>ED25519VFY</code> function takes the signer public key as a call parameter, as with Ed25519, I don't believe it is possible to derive the signers public key from the signature and message alone.</p> <p>The proposed <code>ED25519VFY</code> function uses a zero return value to indicate success, since this allows for different errors to be distinguished by return value, as all non-zero return values signal a verification failure.</p> <p><code>ECRECOVER</code> has a gas cost of 3000. Since Ed25519 is computationally cheaper, the gas price should be less.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As the proposed precompiled contract is deployed at a reserved (&lt;255) and previously unused address, an implementation of the proposal should not introduce any backward compatibility issues.</p> <h2 id="test-cases">Test Cases</h2> <p>Test vectors for Ed25519 can be found in this IETF ID https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6.</p> <p>More test vectors can be found in the regression tests of NaCl (see references).</p> <h2 id="implementation">Implementation</h2> <h3 id="libsodium">libsodium</h3> <p>libsodium is a mature, high-quality C implementation of Ed25519, with bindings for many languages.</p> <p>Further, libsodium is (to my knowledge, and as of today 2018/04) the only Ed25519 implementation that has gone through a <a rel="external" href="https://www.privateinternetaccess.com/blog/2017/08/libsodium-v1-0-12-and-v1-0-13-security-assessment/">Security Assessment</a>.</p> <p>To minimize consensus failure risks, the proposal recommends to use libsodium for adding the precompile in all Ethereum client implementations.</p> <blockquote> <p>Note: as an alternative to libsodium, I looked into HACL, an implementation of Ed25519 in F* (a ML dialect) that can be transpiled to C, and that was formally verified for functional correctness and memory safety of the resulting C code. However, this is new and compared to libsodium which is a "know thing" seems risky nevertheless.</p> </blockquote> <h3 id="libsodium-bindings">libsodium bindings</h3> <p>Here is an overview of the language bindings to libsodium for four Ethereum clients this proposal recommends:</p> <table><thead><tr><th>Client</th><th>Language</th><th>libsodium binding</th></tr></thead><tbody> <tr><td>Geth</td><td>Go</td><td>use cgo with C <a rel="external" href="https://github.com/jedisct1/libsodium">libsodium</a></td></tr> <tr><td>Parity</td><td>Rust</td><td><a rel="external" href="https://github.com/dnaq/sodiumoxide">sodiumoxide</a></td></tr> <tr><td>PyEthereum</td><td>Python</td><td><a rel="external" href="https://github.com/pyca/pynacl">PyNaCl</a></td></tr> <tr><td>cpp-ethereum</td><td>C++</td><td><a rel="external" href="https://github.com/jedisct1/libsodium">libsodium</a></td></tr> </tbody></table> <hr /> <h3 id="prs">PRs</h3> <p>Implementations of this proposal are here:</p> <ol> <li><a rel="external" href="https://github.com/ethereum/go-ethereum/pull/16453">go-ethereum PR #16453</a></li> <li><a rel="external" href="https://github.com/ethereum/pyethereum/pull/862">pyethereum PR #862</a></li> <li><a rel="external" href="https://github.com/paritytech/parity/pull/8330">parity PR #8330</a></li> <li><a rel="external" href="https://github.com/ethereum/cpp-ethereum/pull/4945">cpp-ethereum PR #4945</a></li> </ol> <h2 id="references">References</h2> <ul> <li>RFC7748 - Elliptic Curves for Security https://tools.ietf.org/html/rfc7748</li> <li>Definition of Ed25519: https://ed25519.cr.yp.to/ed25519-20110926.pdf</li> <li>Ed25519 - high-speed high-security signatures: https://ed25519.cr.yp.to/</li> <li>NaCl - Networking and Cryptography library: https://nacl.cr.yp.to/sign.html</li> <li>NaCl Crypto Libraries (which contains Ed25519): https://ianix.com/pub/ed25519-deployment.html</li> <li>Test vectors for Ed25519: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6</li> <li>NaCl regression tests: https://ed25519.cr.yp.to/python/sign.py and https://ed25519.cr.yp.to/python/sign.input</li> <li>On the recoverability of public keys from signature+message (alone): https://crypto.stackexchange.com/questions/9936/what-signature-schemes-allow-recovering-the-public-key-from-a-signature</li> <li>Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006, https://cr.yp.to/ecdh.html</li> <li>Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015, https://eprint.iacr.org/2015/625&gt;</li> <li>RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (https://datatracker.ietf.org/doc/html/rfc8080)</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-03-01T00:00:00+00:00 2026-02-11T14:49:27+00:00 James Rayhttps://github.com/jamesray1 Micah Zoltuhttps://github.com/MicahZoltu https://wg-eips.ritovision.com/908/ <h2 id="a-reward-for-running-a-full-node-is-deprecated-but-the-proposal-for-a-reward-for-clients-remains">A reward for running a full node is deprecated, but the proposal for a reward for clients remains</h2> <p>While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. <a rel="external" href="https://www.pokt.network/">Pocket Network</a> is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that <a rel="external" href="https://github.com/rocket-pool/rocketpool">Rocket Pool</a> is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is <a rel="external" href="https://github.com/vipnode/vipnode.org">VIPnode</a> which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: <a rel="external" href="https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#">shasper</a>): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to <a rel="external" href="https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921">here</a>.</p> <h2 id="simple-summary">Simple Summary</h2> <p>When each transaction is validated, give a reward to clients for developing the client.</p> <h2 id="abstract">Abstract</h2> <p>The tragedy of the commons is a phenomenon that is well known in many sectors, most notably in regard to sustainability. It involves the over-utilization of shared finite resources, which detriments all participants and stakeholders involved (which in the case of a global public good can be everyone, including future generations). Without proper management of public resources, a tragedy of the commons can occur. Internalizing externalities (where externalities can be broadly defined as effects that are not accounted for in the intrinsic price of a good, service or resource) is one way of incentivizing the proper management of resources, although other methods that actually properly manage them are necessary. This EIP proposes to make a change to the protocol to provide a reward to clients for providing the software that enables Ethereum to function, where the reward can include a proportion of transaction fees (reducing the full proportion that the miner currently receives), and some newly minted ETH. Thus, clients are incentivized to maintain and improve the security and health of the Ethereum protocol and ecosystem. To summarize the mechanism in the proposal, a user agent is attached to a transaction, where this user agent contains a vector with the index of a client address in an access list. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage.</p> <p>Reward mechanisms that are external to being built in to the protocol are beyond the scope of this EIP. Such extra-protocol reward methods include state channel payments for extra services such as light client servers providing faster information such as receipts; state channel payments for buying state reads from full nodes; archival services (which is only applicable to future proposed versions of Ethereum with stateless clients); and tokens for the client and running full nodes.</p> <h2 id="motivation">Motivation</h2> <p>Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with <a href="https://wg-eips.ritovision.com/1011/">Casper FFG</a>, then full PoS with <a rel="external" href="https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf">CBC Casper</a>.</p> <p>Additionally, providing a reward for clients gives a revenue stream that is independent of state channels or other layer 2 mechanisms, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) that it provides.</p> <p>While it may be argued that the funds raised by the Ethereum pre-mine (the pre-ICO and the ICO) can be used to fund client development, that argument is questionable, since Parity is VC-funded, and other clients such as Prysmatic Labs <a rel="external" href="https://medium.com/@XYOracleNetwork?source=search_post">1</a>, <a rel="external" href="https://twitter.com/prylabs/status/996391036753666050">2</a>, <a rel="external" href="https://medium.com/prysmatic-labs/biweekly-development-update-2-d29d0c91e7d0">3</a> and <a rel="external" href="https://medium.com/compound-finance/introducing-exthereum-the-newest-ethereum-client-7a5e30d4d6aa">exthereum</a> have received funding from other parties, whereas perhaps they would not have needed to do so if there was sufficient funding from the Ethereum pre-mine funds. <a rel="external" href="https://github.com/Drops-of-Diamond/diamond_drops">Drops of Diamond</a> is yet to receive any funding.</p> <p>Incentivizing client development would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons, where there is an extreme lack of supply and excess demand, leading to the protocol being unusable.</p> <p>See <a rel="external" href="https://eprint.iacr.org/2014/452.pdf#subsection.2.1">here</a> for an analysis in the context of Bitcoin, PoW, and a hybrid PoW/PoS protocol. While Ethereum has a gas limit, the section points out that this is not enough as the market cap increases and the incentive to attack the network increases, while the ratio of security costs to transaction fees does not, while PoS will further alleviate the problem. However, the section points out that PoS is not enough, since the costs of propagating, verifying and storing transactions are not incentivised. Note that the "Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake" paper also contains a scheme for incentivizing a target participation level.</p> <blockquote> <p>The word “activity” in the phrase Proof of Activity emphasizes the point that only active stakeholders who maintain a full online node get rewarded, in exchange for the vital services that they provide for the network. This stands in contrast to earlier Proof of Stake schemes in which offline stake can accumulate weight over time, and may ultimately be utilized in double-spending attacks.</p> </blockquote> <p>We can also incentivize full nodes to propagate transactions and to store transactions or state, in addition to verifying them. While these first two incentivizations are outside the scope of this EIP, there are proposals <a rel="external" href="https://ethresear.ch/t/incentivizing-a-robust-p2p-network-relay-layer/1438">here</a> and <a rel="external" href="https://ethresear.ch/t/incentivizing-full-state-nodes/1640">here</a>, respectively.</p> <p>Implementing this as a layer 2 solution may not ensure the sustainability of the protocol, since not everyone would use it; if the protocol doesn't have any cost for full nodes to validate transactions, then people will take advantage of that and not use the layer 2 solution. It seems that you should at least have the part where the reward is provided in protocol, but then that and the user agent signature doesn't really add anything else to the protocol, so doing some part in-protocol and some part e.g. the verification or a verification-game off-protocol could be done, but it's already done in protocol. Note also that some computationally expensive tasks are too challenging to feasibly do in protocol, e.g. due to not fitting in the gas limit, could be done with Truebit, where verifiers have an incentive.</p> <p>Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node.</p> <p>Note that with a supply cap (as in <a rel="external" href="https://github.com/ethereum/EIPs/issues/960">EIP-960</a>, the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per <a href="https://wg-eips.ritovision.com/1015/">EIP-1015</a>, an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders.</p> <h2 id="specification">Specification</h2> <p>Add a new field to each block called <code>PrevBlockVerifications</code>, which is an arbitrary, unlimited size byte array. When a client verifies that a previous block is <a rel="external" href="https://ethereum.github.io/yellowpaper/paper.pdf#subsubsection.4.3.2">valid</a>, the client appends a user agent to PrevBlockVerifications via an opcode in a transaction, PREV_BLOCK_VERIF. The user agent is a vector with the immutable fields: the blockhash of the block that is validated, and the index of a client address in an access list (details are below). A miner validates a transaction before including it in a block, however they are not able to change these fields of the vector because they're immutable.</p> <p>Send 0.15 ETH to the client (see the rationale below), when the block is processed. The amounts could include a proportion of transaction fees (while the miner would then receive less), which would reduce newly issued ETH. These amounts are specified in new <code>ClientReward</code> fields in the block.</p> <p>In order to only incentivize verifying recent blocks, assert that the block number corresponding to a blockhash is less than 400 blocks ago.</p> <h3 id="attacks-and-added-specifications-to-prevent-them">Attacks and added specifications to prevent them</h3> <p>A miner could create a client and fill their block with transactions that only contain the PREV_BLOCK_VERIF opcode (or alternatively, arbitrarily complex transactions, still with the opcode), with previous blockhashes that they have validated and the address of their client. To prevent this, state would have to store a list containing lists, with each sublist listing the blockhashes up to 400 blocks ago that correspond to a miner, then a miner (or a proposer under Casper CBC) could have to put down a deposit, and be slashed if the proposer inserts such a transaction (that contains a blockhash which they have already proposed, not just in a block but at any time previously). Updating the state to remove blockhashes more than 400 blocks ago would add additional overhead, although you could add an extra window for older blocks, say 120,000 blocks (roughly every 3 weeks), still ignore blocks that are older than 400 blocks ago, and remove these older 120,000 blocks every 120,000 blocks. An attacker could bribe a miner/proposer to include transactions like above that contain an address of a client in the access list which they own. However, the above slashing condition should disincentivize this.</p> <h3 id="more-details-on-the-access-list">More details on the access list</h3> <p>The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to <a href="https://wg-eips.ritovision.com/1015/">EIP-1015</a>, which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of <a rel="external" href="https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca">on-chain governance</a> as well as of <a rel="external" href="https://vitalik.ca/general/2018/03/28/plutocracy.html">plutocracy</a>. <a rel="external" href="https://en.wikipedia.org/wiki/Proof-of-authority">Proof of Authority</a> isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users.</p> <p>However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the <a rel="external" href="https://github.com/ethereum/tests">Ethereum test suite</a>. However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by <a rel="external" href="https://dogezer.com/">Dogezer</a>). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list).</p> <p>Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could <code>assert</code> that the address found at that index matches that which can be read by the client (where the latter would be a read-only address).</p> <h2 id="rationale">Rationale</h2> <h3 id="a-rough-qualitative-analysis-of-fees">A rough qualitative analysis of fees</h3> <p>As of May 4 2018, there are <a rel="external" href="https://web.archive.org/web/20180504051128/https://ethernodes.org/network/1">16428 nodes</a>. Assume that an annual cost for an average client developer organisation is $1 million per annum. Projecting forward (and noting that the number of nodes should increase substantially if this EIP was implemented, thus aiding Ethereum's goal of decentralizing everything) assume that there are 10 clients. Thus let us assume that the number of nodes doubles to 30000 nodes within 5 years (this assumption is probably conservative, even if it is forward looking). Assume for simplicity that the costs of a client are entirely covered by this block reward.</p> <p>Average cost per client = number of nodes * Block reward per client / number of clients</p> <p>Block reward per client (worse case for ETH price) = Average revenue per client * number of clients / (ETH exchange rate * number of nodes)</p> <p>= $2,000,000 * 10 / (500 * 30,000)</p> <p>= 1.333333333 ETH</p> <p>Block reward per client (better case) = $1,000,000 * 10 / (2000 * 30,000) = 0.166666667 ETH</p> <p>Suppose that we use a block reward of 0.15 ETH for clients.</p> <!--There are more than 5552465 blocks and counting. With a reward of 0.001 ETH for each block, a full state node that verified every block would receive 5552.465 ETH. However, the difficulty of verifying blocks increases over time, so--> <h3 id="more-rationale-outdated-by-above">More rationale (outdated by above)</h3> <p>The amount of computation to validate a transaction will be the same as a miner, since the transaction will need to be executed. Thus, if there would be transaction fees for validating full nodes and clients, and transactions need to be executed by validators just like miners have to, it makes sense to have them calculated in the same way as gas fees for miners. This would controversially increase the amount of transaction fees a lot, since there can be many validators for a transaction. In other words, it is controversial whether to provide the same amount of transaction fee for a full node validator as for a miner (which in one respect is fair, since the validator has to do the same amount of computation), or prevent transaction fees from rising much higher, and have a transaction fee for a full node as, say, the transaction fee for a miner, divided by the average number of full nodes validating a transaction. The latter option seems even more controversial (but is still better than the status quo), since while there would be more of an incentive to run a full node than there is now with no incentive, validators would be paid less for performing the same amount of computation.</p> <p>And as for the absolute amounts, this will require data analysis, but clearly a full node should receive much less than a miner for processing a transaction in a block, since there are many transactions in a block, and there are many confirmations of a block. Data analysis could involve calculating the average number of full nodes verifying transactions in a block. Macroeconomic analysis could entail the economic security benefit that full nodes provide to the network.</p> <p>Now, as to the ratio of rewards to the client vs the full node, as an initial guess I would suggest something like 99:1. Why such a big difference? Well, I would guess that clients spend roughly 99 times more time on developing and maintaining the client than a full node user spends running and maintaining a full node. During a week there might be several full-time people working on the client, but a full node might only spend half an hour (or less) initially setting it up, plus running it, plus electricity and internet costs. Full node operators probably don't need to upgrade their computer (and buying a mining rig isn't worth it with Casper PoS planning on being implemented soon).</p> <p>However, on further analysis, clients would also get the benefit of a large volume of rewards from every full node running the client, so to incentivise full node operation further, the ratio could change to say, 4:1, or even 1:1, and of course could be adjusted with even further actual data analysis, rather than speculation.</p> <p>Providing rewards to full node validators and to clients would increase the issuance. In order to maintain the issuance at current levels, this EIP could also reduce the mining reward (despite being reduced previously with the Byzantium release in October 2017 from 5 ETH to 3 ETH), but that would generate more controversy and discussion.</p> <p>Another potential point of controversy with rewarding clients and full nodes is that the work previously done by them has not been paid for until now (except of course by the Ethereum Foundation or Parity VCs funding the work), so existing clients may say that this EIP gives an advantage to new entrants. However, this doesn't hold up well, because existing clients have the first mover advantage, with much development to create useful and well-used products.</p> <p>There is a tradeoff. Higher fees means you may cut out poor people and people who just don't want to pay fees. But if a laptop can run a full node and get paid for it then that would offset the fees through usage. Full nodes do provide a security benefit, so the total fees given could at least be some fraction of this benefit. Fees that go towards client development incentivise a higher quality client. To me, I think it makes more sense to internalize costs as much as possible: for computation, storage, bandwidth, I/O, client development, running full nodes, mining/validating, etc. You avoid a tragedy of the commons through externalizing costs. The more you internalize costs, the more sustainable it is, and the less you rely on rich people being generous, etc. (Although, getting philosophical, ultimately you can't force rich people to be generous, they have to do so out of the kindness of their hearts.)</p> <p>Regarding rewards for full nodes, in the <a rel="external" href="https://ethresear.ch/t/sharding-phase-1-spec/1407">draft phase 1 sharding spec</a> proposers acting as full nodes have rewards for proposing blobs (without execution) or later in phase 3 transactions (with execution) to be included into collations/blocks. So that would help. However, full nodes that do not act as proposers and just verify transactions, or <a rel="external" href="https://ethresear.ch/t/incentivizing-full-state-nodes/1640">full state nodes</a>, are still not incentivized.</p> <p>Note that while further quantitative analysis to specify fees should be done, some level of experimentation after implementing this method on-chain may be necessary.</p> <h3 id="security">Security</h3> <p>All of the below struck out information should be prevented via using an access list and verifying that the read-only address provided by the client matches with an address in the access list, as well as using a layer 2 solution such as a PoA network for censorship resistance and minimization of centralization in the access list.</p> <p>Further discussion is at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Introducing in-protocol fees is a backwards-incompatible change, so would be introduced in a hard-fork.</p> <h2 id="test-cases">Test Cases</h2> <p>TODO</p> <h2 id="implementation">Implementation</h2> <p>TODO</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2018-01-29T00:00:00+00:00 2026-02-11T14:49:27+00:00 Carl Larsoncslarson@gmail.com https://wg-eips.ritovision.com/858/ <h2 id="simple-summary">Simple Summary</h2> <p>Reduce the block reward to 1 ETH and delay the difficulty bomb.</p> <h2 id="abstract">Abstract</h2> <p>The current public Ethereum network has a hashrate that corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. Recent research developments also now time the switch to POS as sometime in 2019 and as a result there is need to further delay the difficulty bomb so the network doesn't grind to a halt.</p> <h2 id="motivation">Motivation</h2> <p>The current public Ethereum network has a hashrate of 296 TH/s. This hashrate corresponds to a power usage of roughly <a href="https://wg-eips.ritovision.com/858/assets/calculations/">1 TW</a> and yearly energy consumption of 8.8 TWh (roughly 0.04% of <a rel="external" href="https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption">total</a> global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network.</p> <h2 id="specification">Specification</h2> <p>Delay difficulty bomb by 2,000,000 blocks Adjust block, uncle, and nephew rewards to reflect a new block reward of 1 ETH.</p> <h2 id="rationale">Rationale</h2> <p>This will delay the difficulty bomb by roughly a year. The difficulty bomb remains a community supported mechanism to aid a future transition to POS.</p> <p>The network hashrate provides security by reducing the likelihood that an adversary could mount a 51% attack. A static block reward means that factors (price) may be such that participation in mining grows unchecked. This growth may be counterproductive and work to also grow and potential pool of adversaries. The means we have to arrest this growth is to reduce the appeal of mining and the most direct way to do that is to reduce the block reward.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is consensus incompatible with the current public Ethereum chain and would cause a hard fork when enacted. The resulting fork would allow users to chose between two chains: a chain with a block reward of 1 ETH/block and another with a block reward of 3 ETH/block. This is a good choice to allow users to make. In addition, the difficulty bomb would be delayed - ensuring the network would not grind to a halt.</p> <h2 id="test-cases">Test Cases</h2> <p>Tests have, as yet, not been completed.</p> <h2 id="implementation">Implementation</h2> <p>No implementation including both block reward and difficulty adjustment is currently available.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-12-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Wei Tanghttps://github.com/sorpaas https://wg-eips.ritovision.com/1702/ <h2 id="simple-summary">Simple Summary</h2> <p>Introduce account versioning for smart contracts so upgrading the VM or introducing new VMs can be easier.</p> <h2 id="abstract">Abstract</h2> <p>This defines a method of hard forking while maintaining the exact functionality of existing account by allowing multiple versions of the virtual machines to execute in the same block. This is also useful to define future account state structures when we introduce the on-chain WebAssembly virtual machine.</p> <h2 id="motivation">Motivation</h2> <p>By allowing account versioning, we can execute different virtual machine for contracts created at different times. This allows breaking features to be implemented while making sure existing contracts work as expected.</p> <p>Note that this specification might not apply to all hard forks. We have emergency hard forks in the past due to network attacks. Whether they should maintain existing account compatibility should be evaluated in individual basis. If the attack can only be executed once against some particular contracts, then the scheme defined here might still be applicable. Otherwise, having a plain emergency hard fork might still be a good idea.</p> <h2 id="specification">Specification</h2> <h3 id="account-state">Account State</h3> <p>Re-define account state stored in the world state trie to have 5 items: <code>nonce</code>, <code>balance</code>, <code>storageRoot</code>, <code>codeHash</code>, and <code>version</code>. The newly added field <code>version</code> is a 256-bit <strong>scalar</strong>. We use the definition of "scalar" from Yellow Paper. Note that this is the same type as <code>nonce</code> and <code>balance</code>, and it is equivalent to a RLP variable-sized byte array with no leading zero, of maximum length 32.</p> <p>When <code>version</code> is zero, the account is RLP-encoded with the first 4 items. When <code>version</code> is not zero, the account is RLP-encoded with 5 items.</p> <p>Account versions can also optionally define additional account state RLP fields, whose meaning are specified through its <code>version</code> field. In those cases, the parsing strategy is defined in "Additional Fields in Account State RLP" section.</p> <h3 id="contract-execution">Contract Execution</h3> <p>When fetching an account code from state, we always fetch the associated version field together. We refer to this as the <em>code's version</em> below. The code of the account is always executed in the <em>code's version</em>.</p> <p>In particular, this means that for <code>DELEGATECALL</code> and <code>CALLCODE</code>, the version of the execution call frame is the same as delegating/receiving contract's version.</p> <h3 id="contract-deployment">Contract Deployment</h3> <p>In Ethereum, a contract has a deployment method, either by a contract creation transaction, or by another contract. If we regard this deployment method a contract's <em>parent</em>, then we find them forming a family of contracts, with the <em>root</em> being a contract creation transaction.</p> <p>We let a family of contracts to always have the same <code>version</code>. That is, <code>CREATE</code> and <code>CREATE2</code> will always deploy contract that has the same <code>version</code> as the <em>code's version</em>.</p> <p>In other words, <code>CREATE</code> and <code>CREATE2</code> will execute the init code using the current <em>code's version</em>, and deploy the contract of the current <em>code's version</em>. This holds even if the to-be-deployed code is empty.</p> <h3 id="validation">Validation</h3> <p>A new phrase, <em>validation</em> is added to contract deployment (by <code>CREATE</code> / <code>CREATE2</code> opcodes, or by contract creation transaction). When <code>version</code> is <code>0</code>, the phrase does nothing and always succeeds. Future VM versions can define additional validation that has to be passed.</p> <p>If the validation phrase fails, deployment does not proceed and return out-of-gas.</p> <h3 id="contract-creation-transaction">Contract Creation Transaction</h3> <p>Define <code>LATEST_VERSION</code> in a hard fork to be the latest supported VM version. A contract creation transaction is always executed in <code>LATEST_VERSION</code> (which means the <em>code's version</em> is <code>LATEST_VERSION</code>), and deploys contracts of <code>LATEST_VERSION</code>. Before a contract creation transaction is executed, run <em>validation</em> on the contract creation code. If it does not pass, return out-of-gas.</p> <h3 id="precompiled-contract-and-externally-owned-address">Precompiled Contract and Externally-owned Address</h3> <p>Precompiled contracts and externally-owned addresses do not have <code>version</code>. If a message-call transaction or <code>CALL</code> / <code>CALLCODE</code> / <code>STATICCALL</code> / <code>DELEGATECALL</code> touches a new externally-owned address or a non-existing precompiled contract address, it is always created with <code>version</code> field being <code>0</code>.</p> <h3 id="additional-fields-in-account-state-rlp">Additional Fields in Account State RLP</h3> <p>In the future we may need to associate more information into an account, and we already have some EIPs that define new additional fields in the account state RLP. In this section, we define the parsing strategy when additional fields are added.</p> <ul> <li>Check the RLP list length, if it is 4, then set account version to <code>0</code>, and do not parse any additional fields.</li> <li>If the RLP list length more than 4, set the account version to the scalar at position <code>4</code> (counting from <code>0</code>). <ul> <li>Check version specification for the number of additional fields defined <code>N</code>, if the RLP list length is not equal to <code>5 + N</code>, return parse error.</li> <li>Parse RLP position <code>5</code> to <code>4 + N</code> as the meaning specified in additional fields.</li> </ul> </li> </ul> <h2 id="extensions">Extensions</h2> <p>In relation to the above "Specification" section, we have defined the base account versioning layer. The base account versioning layer is already useful by itself and can handle most EVM improvements. Below we define two specifications that can be deployed separately, which improves functionality of base layer account versioning.</p> <p>Note that this section is provided only for documentation purpose. When "enabling EIP-1702", those extensions should not be enabled unless the extension specification is also included.</p> <ul> <li><a rel="external" href="https://corepaper.org/ethereum/compatibility/versioning/#extensions-for-state-based-account-versioning">44-VERTXN: Account Versioning Extension for Contract Creation Transaction</a></li> <li><a rel="external" href="https://corepaper.org/ethereum/compatibility/versioning/#create-and-create2-extension">45-VEROP: Account Versioning Extension for CREATE and CREATE2</a></li> </ul> <h2 id="usage-template">Usage Template</h2> <p>This section defines how other EIPs might use this account versioning specification. Note that currently we only define the usage template for base layer.</p> <p>Account versioning is usually applied directly to a hard fork meta. EIPs in the hard fork are grouped by the virtual machine type, for example, EVM and eWASM. For each of them, we define:</p> <ul> <li><strong>Version</strong>: a non-zero scalar less than <code>2^256</code> that uniquely identifies this version. Note that it does not need to be sequential.</li> <li><strong>Parent version</strong>: the base that all new features derived from. With parent version of <code>0</code> we define the base to be legacy VM. Note that once a version other than <code>0</code> is defined, the legacy VM's feature set must be frozen. When defining an entirely new VM (such as eWASM), parent version does not apply.</li> <li><strong>Features</strong>: all additional features that are enabled upon this version.</li> </ul> <p>If a meta EIP includes EIPs that provide additional account state RLP fields, we also define:</p> <ul> <li><strong>Account fields</strong>: all account fields up to the end of this meta EIP, excluding the basic 5 fields (<code>nonce</code>, <code>balance</code>, <code>storageRoot</code>, <code>codeHash</code> and <code>version</code>). If EIPs included that are specific to modifying account fields do not modify VM execution logic, it is recommended that we specify an additional version whose execution logic is the same as previous version, but only the account fields are changed.</li> </ul> <h2 id="rationale">Rationale</h2> <p>This introduces account versioning via a new RLP item in account state. The design above gets account versioning by making the contract <em>family</em> always have the same version. In this way, versions are only needed to be provided by contract creation transaction, and there is no restrictions on formats of code for any version. If we want to support multiple newest VMs (for example, EVM and WebAssembly running together), then this will requires extensions such as 44-VERTXN and 45-VEROP.</p> <p>Alternatively, account versioning can also be done through:</p> <ul> <li><strong><a rel="external" href="https://corepaper.org/ethereum/compatibility/versioning/#prefix-based-account-versioning">26-VER</a></strong> and <strong><a rel="external" href="https://corepaper.org/ethereum/compatibility/forward/">40-UNUSED</a></strong>: This makes an account's versioning solely dependent on its code header prefix. If with only 26-VER, it is not possible to certify any code is valid, because current VM allows treating code as data. This can be fixed by 40-UNUSED, but the drawback is that it's potentially backward incompatible.</li> <li><strong>EIP-1891</strong>: Instead of writing version field into account RLP state, we write it in a separate contract. This can accomplish the same thing as this EIP and potentially reduces code complexity, but the drawback is that every code execution will require an additional trie traversal, which impacts performance.</li> </ul> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>Account versioning is fully backwards compatible, and it does not change how current contracts are executed.</p> <h2 id="discussions">Discussions</h2> <h3 id="performance">Performance</h3> <p>Currently nearly all full node implementations uses config parameters to decide which virtual machine version to use. Switching virtual machine version is simply an operation that changes a pointer using a different set of config parameters. As a result, this scheme has nearly zero impact to performance.</p> <h3 id="webassembly">WebAssembly</h3> <p>This scheme can also be helpful when we deploy on-chain WebAssembly virtual machine. In that case, WASM contracts and EVM contracts can co-exist and the execution boundary and interaction model are clearly defined as above.</p> <h2 id="test-cases-and-implementations">Test Cases and Implementations</h2> <p>To be added.</p> <h2 id="references">References</h2> <p>The source of this specification can be found at <a rel="external" href="https://corepaper.org/ethereum/compatibility/versioning/#state-based-account-versioning">43-VER</a>.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-08-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Cody BurnsdontPanic@codywburns.com https://wg-eips.ritovision.com/698/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP adds an additional opcode to the EVM which will return a finalized blocks reward value.</p> <h2 id="abstract">Abstract</h2> <p>In the EVM, the 0x40 opcodes are reserved for <code>Block Information</code>. Currently reserved opcodes are:</p> <ul> <li><code>0X40 BLOCKHASH</code></li> <li><code>0X41 COINBASE</code></li> <li><code>0X42 TIMESTAMP</code></li> <li><code>0X43 NUMBER</code></li> <li><code>0X44 DIFFICULTY</code></li> <li><code>0X45 GASLIMIT</code></li> </ul> <p>This EIP would add an additional opcode, <code>0x46 BLOCKREWARD</code>, which would return the block reward for any finalized block. The finalized block reward would include the base reward, uncle payments, and gas.</p> <h2 id="motivation">Motivation</h2> <p>Per EIP-649 ( #669 ) periodic block reward reductions/variance are now planned in the roadmap, however, this EIP is consensus system agnostic and is most useful in decentralized pool operations and for any contract that benefits from knowing a block reward payout(i.e. Merge mined tokens)</p> <h2 id="specification">Specification</h2> <p>After block <code>n</code> all clients should process opcode <code>0x46</code> as follows:</p> <ul> <li>Value: <code>0x46</code></li> <li>Mnemonic: <code>BLOCKREWARD</code></li> <li>δ:<code> 0</code> nothing removed from stack</li> <li>α:<code>1</code> block reward added to stack</li> <li>Description: <code>Get the block's reward emission</code></li> <li>GasCost: <code>G&lt;sub&gt;base&lt;/sub&gt;</code></li> </ul> <p>Where:<code>µ'&lt;sub&gt;s&lt;/sub&gt;[0] ≡ I&lt;sub&gt;HR&lt;/sub&gt;</code></p> <h2 id="rationale">Rationale</h2> <h3 id="contract-mining-pools">Contract Mining Pools</h3> <p>For distributed consensus systems(staking pools and mining pools) ad hoc groups combine resources in order to reduce variance in payouts. Broadly, pool operations function by allowing a collective of miners / stakers to verify their contribution to solving PoW or staking share by periodically submitting solutions which are representative of the miners probability of finding a true block.</p> <p>In all these schemes <code>B</code> stands for a block reward minus pool fee and <code>p</code> is a probability of finding a block in a share attempt ( <code>p=1/D</code>, where <code>D</code> is current block difficulty).</p> <p>Some common methods of mining pool payout are pay-per-share, <code>R = B * p</code>, proportional [<code>R = B * (n/N)</code> where <code>n</code> is amount of a miners shares, and <code>N</code> is amount of all shares in this round.], and pay-per-last-N-shares [<code>R = B * (n/N)</code> where miner's reward is calculated on a basis of <code>N</code> last shares, instead of all shares for the last round]. All of these methods are predicated on knowing the block reward paid for a given block. In order to provide a trust minimized solution, <code>0x46</code> can be used to call a blocks reward for computing payouts.</p> <h3 id="merge-mined-tokens">Merge mined tokens</h3> <p>Contracts could create tokens which could be variably ‘minted’ as a function of block reward by calling <code>0x46</code></p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <h3 id="currently-deployed-contracts">Currently deployed contracts</h3> <p>No impact</p> <h3 id="current-clients">Current clients</h3> <p>This EIP would be incompatible with currently deployed clients that are not able to handle <code>0x46</code> and would process all transactions and block containing the opcode as invalid.</p> <p>Implementation should occur as part of a coordinated hardfork.</p> <h2 id="implementation">Implementation</h2> <h2 id="further-reading">Further reading</h2> <p><a rel="external" href="https://en.wikipedia.org/wiki/Mining_pool">Mining Pools</a></p> <p>The Yellow Paper Appendix H. Virtual Machine Specification section H.2</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-08-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Yoichi Hiraii@yoichihirai.com https://wg-eips.ritovision.com/689/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP proposes to make contract creation fail on an account with nonempty code or non-zero nonce.</p> <h2 id="abstract">Abstract</h2> <p>Some test cases in the consensus test suite try to deploy a contract at an address already with nonempty code. Although such cases can virtually never happen on the main network before the Constantinople fork block, the test cases detected discrepancies in clients' behavior. Currently, the Yellow Paper says that the contract creation starts with the empty code and the initial nonce even in the case of address collisions. To simplify the semantics, this EIP proposes that address collisions cause failures of contract creation.</p> <h2 id="motivation">Motivation</h2> <p>This EIP has no practical relevance to the main net history, but simplifies testing and reasoning.</p> <p>This EIP has no effects after Constantinople fork because <a href="https://wg-eips.ritovision.com/86/">EIP-86</a> contains the changes proposed in this EIP. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256.</p> <p>Regarding testing, this EIP relieves clients from supporting reversion of code overwriting.</p> <p>Regarding reasoning, this EIP establishes an invariant that non-empty code is never modified.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= 0</code>, when a contract creation is on an account with non-zero nonce or non-empty code, the creation fails as if init code execution resulted in an exceptional halt. This applies to contract creation triggered by a contract creation transaction and by CREATE instruction.</p> <h2 id="rationale">Rationale</h2> <p>It seems impractical to implement never-used features just for passing tests. Client implementations will be simpler with this EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is backwards compatible on the main network.</p> <h2 id="test-cases">Test Cases</h2> <p>At least the BlockchainTest called <code>createJS\_ExampleContract\_d0g0v0\_EIP158</code> will distinguish clients that implement this EIP.</p> <h2 id="implementation">Implementation</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-07-03T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Charles Cooperhttps://github.com/charles-cooper Danno Ferrinhttps://github.com/shemnon https://wg-eips.ritovision.com/663/

Introduce additional instructions for manipulating the stack which allow accessing the stack at higher depths

<h2 id="abstract">Abstract</h2> <p>Currently, <code>SWAP*</code> and <code>DUP*</code> instructions are limited to a stack depth of 16. Introduce three new instructions, <code>SWAPN</code>, <code>DUPN</code> and <code>EXCHANGE</code> which lift this limitation and allow accessing the stack at higher depths.</p> <h2 id="motivation">Motivation</h2> <p>While the stack is 1024 items deep, easy access is only possible for the top 16 items. Supporting more local variables is possible via manually keeping them in memory or through a "stack to memory elevation" in a compiler. This can result in complex and inefficient code.</p> <p>Furthermore, implementing higher level constructs, such as functions, on top of EVM will result in a list of input and output parameters as well as an instruction offset to return to.</p> <p>The number of these arguments (or stack items) can easily exceed 16 and thus will require extra care from a compiler to lay them out in a way that all of them are still accessible.</p> <p>Lastly, swapping items besides the 1st and Nth items in the stack is very important for compilers implementing stack scheduling algorithms (the analog of register allocation for stack machines), which try to minimize stack traffic given a set of variables and usage analysis.</p> <p>Introducing <code>SWAPN</code>, <code>DUPN</code> and <code>EXCHANGE</code> will provide an option to compilers to simplify accessing deep stack items.</p> <h2 id="specification">Specification</h2> <p>We introduce three new instructions:</p> <ol> <li><code>DUPN</code> (<code>0xe6</code>)</li> <li><code>SWAPN</code> (<code>0xe7</code>)</li> <li><code>EXCHANGE</code> (<code>0xe8</code>)</li> </ol> <p>If the code is legacy bytecode, any of these instructions result in an <em>exceptional halt</em>. (<em>Note: This means no change to behaviour.</em>)</p> <p>If the code is valid EOF1, the following rules apply:</p> <ol> <li>The instructions are followed by an 8-bit immediate value, which we call <code>imm</code>, and can have a value of 0 to 255. <ol> <li>In the case of <code>DUPN</code> and <code>SWAPN</code>, we introduce the variable <code>n</code> which equals to <code>imm + 1</code>.</li> <li>In the case of <code>EXCHANGE</code>, we introduce the variable <code>n</code> which is equal to <code>(imm &gt;&gt; 4) + 1</code>, and the variable <code>m</code> which is equal to <code>(imm &amp; 0x0F) + 1</code> (i.e., the first and second nibbles of <code>imm</code>, converted to one-indexing).</li> </ol> </li> <li>Code validation is extended to check that no relative jump instruction (<code>RJUMP</code>/<code>RJUMPI</code>/<code>RJUMPV</code>) targets immediate values of <code>DUPN</code>, <code>SWAPN</code> or <code>EXCHANGE</code>.</li> <li>The stack validation algorithm of <a href="https://wg-eips.ritovision.com/5450/">EIP-5450</a> is extended: <ol> <li>Before <code>DUPN</code> if the current stack height is less than <code>n</code>, code is invalid. After <code>DUPN</code>, the stack height is incremented.</li> <li>Before <code>SWAPN</code> if the current stack height is less than <code>n + 1</code>, code is invalid. After <code>SWAPN</code>, the stack height is unchanged.</li> <li>Before <code>EXCHANGE</code> if the current stack height is less than <code>n + m + 1</code>, code is invalid. After <code>EXCHANGE</code>, the stack height is unchanged.</li> </ol> </li> <li>Execution rules: <ol> <li><code>DUPN</code>: the <code>n</code>'th stack item is duplicated at the top of the stack. (<em>Note: We use 1-based indexing here.</em>)</li> <li><code>SWAPN</code>: the <code>n + 1</code>'th stack item is swapped with the top of the stack.</li> <li><code>EXCHANGE</code>: the <code>n + 1</code>'th stack item is swapped with the <code>n + m + 1</code>'th stack item.</li> </ol> </li> </ol> <p>The gas cost for all three instructions is set at 3.</p> <h2 id="rationale">Rationale</h2> <h3 id="use-of-an-immediate-argument">Use of an immediate argument</h3> <p>Allowing dynamic selection of the arguments to swap, dup, or exchange could be used to prevent static analysis of the contents of the stack. Since static analysis is an important tool for security auditors we want to do what we can to make their jobs easier. Hence, the operands require an immediate argument that is not dynamic in nature.</p> <h3 id="eof-only">EOF-only</h3> <p>Since this instruction depends on an immediate argument encoding, it can only be enabled within EOF. In legacy bytecode that encoding could contradict jumpdest-analysis.</p> <h3 id="size-of-immediate-argument">Size of immediate argument</h3> <p>For <code>DUPN</code> and <code>SWAPN</code> a 16-bit size was considered to accommodate the full stack space of 1024 items, however:</p> <ol> <li>that would require an additional restriction/check (<code>n &lt; 1024</code>)</li> <li>the 256 depth is a large improvement over the current 16 and the overhead of an extra byte would make it less useful</li> </ol> <p>Similarly for <code>EXCHANGE</code>, the proposed scheme allows addressing of 32 items.</p> <h3 id="gas-cost">Gas cost</h3> <p>The gas cost for these operations is the same as for existing <code>DUP*</code> and <code>SWAP*</code> instructions, because they are just implemented as pointer swaps.</p> <h3 id="exchange-vs-swapn"><code>EXCHANGE</code> vs <code>SWAPN</code></h3> <p>As mentioned before, <code>EXCHANGE</code> is important to compilers implementing stack scheduling algorithms. Specifically, in the case that a stack item is scheduled to be consumed deeper in the stack (for instance, the 3rd item in the stack needs to be moved into 2nd position in order to be consumed by the next operation), that currently takes three instructions, <code>SWAP2 SWAP3 SWAP2</code>. However, in the EVM implementation, the implementation is just a pointer swap, so it could be implemented in a single instruction at no extra runtime cost to the client.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This has no effect on backwards compatibility because the opcodes were not previously allocated and the feature is only enabled in EOF.</p> <h2 id="test-cases">Test Cases</h2> <p>Given <code>stack[]</code> is a 0-based data structure, and <code>n</code>, <code>m</code> and <code>imm</code> are defined as according to the spec:</p> <ul> <li><code>DUPN imm</code> to fail validation if <code>stack_height &lt; n</code>.</li> <li><code>SWAPN imm</code> to fail validation if <code>stack_height &lt; n + 1</code>.</li> <li><code>EXCHANGE imm</code> to fail validation if <code>stack_height &lt; n + m + 1</code>.</li> <li><code>DUPN imm</code> to increment maximum stack height of a function. Validation fails if maximum stack height exceeds limit of 1023.</li> <li><code>DUPN imm</code>, <code>SWAPN imm</code>, and <code>EXCHANGE imm</code> to fail at run-time if gas available is less than 3.</li> <li><code>DUPN imm</code> should duplicate the <code>stack[n - 1]</code> item and push it to the stack</li> <li><code>SWAPN imm</code> should swap <code>stack[n]</code> with <code>stack[stack.top()]</code></li> <li><code>EXCHANGE imm</code> should swap <code>stack[n]</code> with <code>stack[n + m]</code>.</li> </ul> <h2 id="security-considerations">Security Considerations</h2> <p>The authors are not aware of any additional risks introduced here. The EVM stack is fixed at 1024 items and most implementations keep that in memory at all times. This change will increase the number of stack items accessible via single instruction.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-06-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Nick Johnsonnick@ethereum.org https://wg-eips.ritovision.com/658/ <h2 id="abstract">Abstract</h2> <p>This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed.</p> <h2 id="motivation">Motivation</h2> <p>With the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. As a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied.</p> <p>Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical.</p> <p>Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt.</p> <h2 id="specification">Specification</h2> <p>For blocks where block.number &gt;= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.</p> <h2 id="rationale">Rationale</h2> <p>This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-06-21T00:00:00+00:00 2026-02-11T14:49:27+00:00 Afri Schoedonhttps://github.com/5chdn Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/649/ <h2 id="simple-summary">Simple Summary</h2> <p>The average block times are increasing due to the difficulty bomb (also known as the "<em>ice age</em>") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the Byzantium fork, the first part of the Metropolis fork.</p> <h2 id="abstract">Abstract</h2> <p>Starting with <code>BYZANTIUM_FORK_BLKNUM</code> the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 3 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 3 ETH, uncle and nephew rewards will be adjusted accordingly.</p> <h2 id="motivation">Motivation</h2> <p>The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.</p> <h2 id="specification">Specification</h2> <h4 id="relax-difficulty-with-fake-block-number">Relax Difficulty with Fake Block Number</h4> <p>For the purposes of <code>calc_difficulty</code>, simply replace the use of <code>block.number</code>, as used in the exponential ice age component, with the formula:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>fake_block_number = max(0, block.number - 3_000_000) if block.number &gt;= BYZANTIUM_FORK_BLKNUM else block.number</span></span></code></pre><h4 id="adjust-block-uncle-and-nephew-rewards">Adjust Block, Uncle, and Nephew rewards</h4> <p>To ensure a constant Ether issuance, adjust the block reward to <code>new_block_reward</code>, where</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_block_reward = 3_000_000_000_000_000_000 if block.number &gt;= BYZANTIUM_FORK_BLKNUM else block.reward</span></span></code></pre> <p>(3E18 wei, or 3,000,000,000,000,000,000 wei, or 3 ETH).</p> <p>Analogue, if an uncle is included in a block for <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code> such that <code>block.number - uncle.number = k</code>, the uncle reward is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_uncle_reward = (8 - k) * new_block_reward / 8</span></span></code></pre> <p>This is the existing pre-Metropolis formula for uncle rewards, simply adjusted with <code>new_block_reward</code>.</p> <p>The nephew reward for <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code> is</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>new_nephew_reward = new_block_reward / 32</span></span></code></pre> <p>This is the existing pre-Metropolis formula for nephew rewards, simply adjusted with <code>new_block_reward</code>.</p> <h2 id="rationale">Rationale</h2> <p>This will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times at the end of 2018. An alternate proposal was to add special rules to the difficulty calculation to effectively <em>pause</em> the difficulty between different blocks. This would lead to similar results.</p> <p>This was previously discussed at All Core Devs Meeting <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%209.md#metropolis-timing-and-roadmap-discussion">#09</a>, <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2012.md#5-metropolis-update">#12</a>, <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2013.md#3-eip-186-reduce-eth-issuance-before-proof-of-stake-hudson">#13</a>, and <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2014.md#1-eip-186-reduce-eth-issuance-before-proof-of-stake-core-devs">#14</a>. Consensus on the specification was achieved in All Core Devs Meeting <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2019.md">#19</a> and specification drafted in EIP issue <a rel="external" href="https://github.com/ethereum/EIPs/issues/649">#649</a>. It was decided to replace EIP <a rel="external" href="https://github.com/ethereum/EIPs/issues/186">#186</a> and include the block reward reduction along with the difficulty bomb delay in All Core Devs Meeting <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2020.md">#20</a> and <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2021.md">#21</a>; accepted in <a rel="external" href="https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%2022.md">#22</a>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the first of the two Metropolis hard-forks, the <em>Byzantium</em> fork.</p> <h2 id="test-cases">Test Cases</h2> <p>Test cases exist in ethereum/tests <a rel="external" href="https://github.com/ethereum/tests/pull/269">#269</a>.</p> <h2 id="implementation">Implementation</h2> <p>The following clients implemented EIP-649:</p> <ul> <li>Geth <a rel="external" href="https://github.com/ethereum/go-ethereum/pull/15028">#15028</a></li> <li>Parity <a rel="external" href="https://github.com/paritytech/parity/pull/5855">#5855</a></li> <li>EthereumJ <a rel="external" href="https://github.com/ethereum/ethereumj/pull/927">#927</a></li> <li>Cpp-Ethereum <a rel="external" href="https://github.com/ethereum/cpp-ethereum/issues/4050">#4050</a></li> <li>PyEthereum <a rel="external" href="https://github.com/ethereum/pyethereum/pull/383">#383</a></li> </ul> <p>The Yellow Paper implements EIP-649 in <a rel="external" href="https://github.com/ethereum/yellowpaper/pull/333">#333</a>.</p> <p>Other notable implementations:</p> <ul> <li>Eth-Isabelle <a rel="external" href="https://github.com/pirapira/eth-isabelle/issues/459">#459</a></li> <li>Py-EVM <a rel="external" href="https://github.com/ethereum/py-evm/pull/123">#123</a></li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-04-25T00:00:00+00:00 2026-02-11T14:49:27+00:00 Greg Colvingreg@colvin.org https://wg-eips.ritovision.com/616/ <h2 id="abstract">ABSTRACT</h2> <p>A proposal to provide Single Instruction Multiple Data types and operations for the Ethereum Virtual Machine, making full use of the 256-bit wide EVM stack items, and offering substantial performance gains for both vector and scalar operations.</p> <h2 id="motivation">MOTIVATION</h2> <p>Most all modern CPUs include SIMD hardware that operates on wide registers of data, applying a Single Instruction to Multiple Data lanes in parallel, where lanes divide a register into a vector of scalar elements of equal size. This model is an excellent fit for the wide stack items of the EVM, offering substantial performance boosts for operations that can be expressed as parallel operations on vectors of scalars. For some examples, a brief literature search finds SIMD speedups of</p> <ul> <li>up to 7X for <a rel="external" href="http://keccak.noekeon.org/sw_performance.html">SHA-512</a></li> <li>4X for <a rel="external" href="https://link.springer.com/chapter/10.1007/3-540-45439-X_16">elliptic curve scalar multiplication</a></li> <li>3X to 4X for <a rel="external" href="https://github.com/minio/blake2b-simd">BLAKE2b</a></li> <li>up to 3X for <a rel="external" href="https://software.intel.com/en-us/articles/improving-openssl-performance">OpenSSL</a></li> <li>2X to 3X for <a rel="external" href="http://ieee-hpec.org/2013/index_htm_files/24-Simd-acceleration-Pabbuleti-2886999.pdf">elliptic curve modular multiplication</a></li> <li>1.7X to 1.9X for <a rel="external" href="https://github.com/minio/sha256-simd">SHA-256</a></li> <li>1.3X for <a rel="external" href="https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.738.1218&amp;rep=rep1&amp;type=pdf">RSA encryption</a></li> </ul> <h2 id="specification">SPECIFICATION</h2> <h3 id="encoding">Encoding</h3> <p>We propose a simple encoding of SIMD operations as extended two-byte codes. The first byte is the opcode, and the second byte is the SIMD type: scalar type, lane width, and number of elements.</p> <table><thead><tr><th>N bits</th><th>Field</th></tr></thead><tbody> <tr><td>8</td><td>opcode</td></tr> <tr><td>1</td><td>scalar type: 0 = unsigned integer, 1 = IEEE float</td></tr> <tr><td>1</td><td>reserved: 0</td></tr> <tr><td>2</td><td>lane width: log base 2 of the number of bytes, as an MSB first integer</td></tr> <tr><td>1</td><td>reserved: 0</td></tr> <tr><td>3</td><td>element count: log base 2 of the number of lanes, as an MSB first integer</td></tr> </tbody></table> <p>Thus we can specify SIMD types with unsigned integer lanes from 8 to 64 bits in vectors of 32 to 2 lanes, respectively. Floating point lanes however support only 32- and 64-bit IEEE floating point. And a type of <em>0x7F</em> represents a normal 256-bit EVM integer.</p> <p><em>Note that when the element count is one the operation is on one scalar, so this specification also provides for native operations on single scalars of native sizes.</em></p> <p><em>Note that floating point operations are <strong>not</strong> proposed for inclusion in the initial release, but we considered it important to reserve code space for possible future expansion.</em></p> <h3 id="semantics">Semantics</h3> <p>We define the following extended versions of the EVM's arithmetic, logic, and comparison operations. As with the normal versions, they consume their arguments from the stack and place their results on the stack, except that their arguments are vectors rather than scalars.</p> <table><thead><tr><th>lo\hi</th><th>B</th><th>C</th></tr></thead><tbody> <tr><td>0</td><td></td><td>XLT</td></tr> <tr><td>1</td><td>XADD</td><td>XGT</td></tr> <tr><td>2</td><td>XMUL</td><td>XSLT</td></tr> <tr><td>3</td><td>XSUB</td><td>XSGT</td></tr> <tr><td>4</td><td>XDIV</td><td>XEQ</td></tr> <tr><td>5</td><td>XSDIV</td><td>XISZERO</td></tr> <tr><td>6</td><td>XMOD</td><td>XAND</td></tr> <tr><td>7</td><td>XSMOD</td><td>XOR</td></tr> <tr><td>8</td><td></td><td>XXOR</td></tr> <tr><td>9</td><td></td><td>XNOT</td></tr> <tr><td>A</td><td></td><td>XINDEX</td></tr> <tr><td>B</td><td></td><td>XSHL</td></tr> <tr><td>C</td><td></td><td>XSHR</td></tr> <tr><td>D</td><td></td><td>XSAR</td></tr> <tr><td>E</td><td>XCAST</td><td>XROL</td></tr> <tr><td>F</td><td>XSHUFFLE</td><td>XROR</td></tr> </tbody></table> <p>Except for XSHUFFLE, XCAST, and XINDEX all the extended operations on unsigned integer values have the same semantics as the corresponding operations for codes 01 through 1F, except that the modulus varies by scalar type and the operations are applied pair-wise to the elements of the source operands to compute the destination elements. <em>The source operands must have the same element type and number of elements.</em> E.g.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH uint8[1, 2, 3]</span></span> <span class="giallo-l"><span>PUSH uint8[4, 5, 6]</span></span> <span class="giallo-l"><span>XADD</span></span></code></pre> <p>leaves</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>uint8[5, 7, 9]</span></span></code></pre> <p>on the stack.</p> <p>XSHUFFLE takes two vectors on the stack: a vector to permute and a permutation mask. E.g.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH uint64[4, 5, 6, 0]</span></span> <span class="giallo-l"><span>PUSH uint8[2, 0, 1, 3]</span></span> <span class="giallo-l"><span>SHUFFLE</span></span></code></pre> <p>leaves</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>uint64[6, 4, 5 , 0]</span></span></code></pre> <p>on the stack. The mask must have integral type, and the same number of elements as the source vector.</p> <p>The second byte of the XCAST opcode is applied to the item on the stack to create a new vector of the specified type. Elements are converted according to the usual C conventions, missing elements are set to zero, and extra elements are discarded. If the stack item is not a vector it is converted to a vector by taking its bits least-significant-bit first and copying them into the corresponding bits of each element, least-significant-element first. Again, excess data is truncated and missing data is 0-filled. Vectors are converted to 256-bit EVM integers via the reverse process., with elements that are floating point NANs normalized to all bits on.</p> <p><em>Note that MLOAD and MSTORE are valid only on 256-bit EVM integers. For SIMD vectors an XCAST is needed after a load and before a store to convert vectors to and from 256-bit integers.</em></p> <p>XINDEX has the same semantics as BYTE, except that individual elements of the vector are indexed.</p> <p>Floating point values follow IEEE 754 semantics. Since those are not defined for shifting and rotating those operations are defined here as having no effect.</p> <p>Extended operations other than XSHUFFLE and XCAST are only valid on vectors of the same SIMD type. This can be validated at contract creation time, or else checked at runtime.</p> <h3 id="subroutines">Subroutines</h3> <p>If <a rel="external" href="https://github.com/ethereum/EIPs/pull/187">EIP-187</a> is accepted a type-safe syntax for declaring subroutines taking vector arguments will be needed.</p> <ul> <li><code>BEGINSUBX n_args, arg_types... n_results, result_types...</code> marks the <strong>single</strong> entry to a subroutine. <code>n_args</code> items are taken off of the stack at entry to, and <code>n_results</code> items are placed on the stack at return from the subroutine. <code>n_args</code> and <code>n_results</code> are given as one immediate byte each. The <code>arg_types</code> and <code>result_types</code> are given in the same encoding as second byte of the SIMD opcodes, and must match the values on the stack. The bytecode for a subroutine ends at the next <code>BEGINSUB</code>, <code>BEGINSUBX</code> or <code>BEGINDATA</code> instruction or at the end of the bytecode.</li> </ul> <h2 id="rationale">RATIONALE</h2> <p>Currently, the lowest common denominator for SIMD hardware (e.g. Intel SSE2 and ARM Neon) is 16-byte registers supporting integer lanes of 1, 2, 4, and 8 bytes, and floating point lanes of 4 and 8 bytes. More recent SIMD hardware (e.g. Intel AVX) supports 32-byte registers, and EVM stack items are also 32 bytes wide. The limits above derive from these numbers, assuring that EVM code is within the bounds of available hardware - and the reserved bits provide room for growth.</p> <p>For most modern languages (including Rust, Python, Go, Java, and C++) compilers can do a good job of generating SIMD code for parallelizable loops, and/or there are intrinsics or libraries available for explicit access to SIMD hardware. So a portable software implementation will likely provide good use of the hardware on most platforms, and intrinsics or libraries can be used as available and needed. Thus we can expect these operations to take about the same (or for 256-bit vectors on 128-bit hardware up to twice) the time to execute regardless of element size or number of elements.</p> <h3 id="gas">Gas</h3> <p>One motivation for these operations, besides taking full advantage of the hardware, is assigning lower gas costs for operations on smaller scalars.</p> <p>On a machine with 64-bit registers the standard algorithms from Knuth's <a rel="external" href="https://library.aceondo.net/ebooks/Computer_Science/algorithm-the_art_of_computer_programming-knuth.pdf">Art of Computer Programming</a> require 32-bit digits, using the upper half of a register for overflows, so for 256-bit values N=8 digits are needed, and for 64-bit values N=2 digits are needed. The cycle counts for these algorithms are:</p> <table><thead><tr><th>operation</th><th>cycles</th><th>N = 2</th><th>N = 4</th><th>N = 8</th></tr></thead><tbody> <tr><td>add</td><td>10 <em>N</em> + 6</td><td>26</td><td>46</td><td>86</td></tr> <tr><td>subtract</td><td>12 <em>N</em> + 3</td><td>27</td><td>51</td><td>99</td></tr> <tr><td>multiply</td><td>28 <em>N</em>**2 + 11 <em>N</em> + 3</td><td>137</td><td>495</td><td>1883</td></tr> <tr><td>divide</td><td>15 <em>N</em>**2 + 119 <em>N</em> + 111</td><td>409</td><td>827</td><td>2023</td></tr> </tbody></table> <p>The remaining operations are of about the same complexity as addition and subtraction, or less. Given that JUMPDEST is a no-op, and is assigned a gas price of 1, this can be taken as the overhead of the interpreter. All of the arithmetic operations are assigned the same gas price of 5, for a remaining runtime of 4. The interpreter loop itself takes about 6 to 8 C instructions, so ADD and SUB are reasonably priced, but MUL is some 5 to 21 times slower than ADD or SUB, and DIV is some 15 to 23 times slower, so they are clearly mispriced.</p> <p>By comparison, on most <a rel="external" href="https://software.intel.com/sites/landingpage/IntrinsicsGuide">Intel</a> and <a rel="external" href="https://developer.arm.com/docs/100166/latest/programmers-model/instruction-set-summary/table-of-processor-instructions">ARM</a> SIMD units instructions take approximately the following cycle counts, independent of register width.</p> <table><thead><tr><th>operation</th><th>Intel cycles</th><th>ARM cycles</th><th>gas</th></tr></thead><tbody> <tr><td>add</td><td>.5</td><td>1</td><td>1</td></tr> <tr><td>subtract</td><td>.5</td><td>1</td><td>1</td></tr> <tr><td>multiply</td><td>2</td><td>1</td><td>1</td></tr> <tr><td>divide</td><td>10</td><td>12</td><td>2</td></tr> </tbody></table> <p>Since all but the divide operation take fewer cycles than the interpreter overhead they are assigned the minimal cost of 1. Division takes slightly more, and is assigned a cost of 2.</p> 2017-03-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Péter Szilágyipeterke@gmail.com https://wg-eips.ritovision.com/225/ <h2 id="abstract">Abstract</h2> <p>Clique is a proof-of-authority consensus protocol. It shadows the design of Ethereum mainnet, so it can be added to any client with minimal effort.</p> <h2 id="motivation">Motivation</h2> <p>Ethereum's first official testnet was Morden. It ran from July 2015 to about November 2016, when due to the accumulated junk and some testnet consensus issues between Geth and Parity, it was finally laid to rest in favor of a testnet reboot.</p> <p>Ropsten was thus born, clearing out all the junk and starting with a clean slate. This ran well until the end of February 2017, when malicious actors decided to abuse the low PoW and gradually inflate the block gas limits to 9 billion (from the normal 4.7 million), at which point sending in gigantic transactions crippling the entire network. Even before that, attackers attempted multiple extremely long reorgs, causing network splits between different clients, and even different versions.</p> <p>The root cause of these attacks is that a PoW network is only as secure as the computing capacity placed behind it. Restarting a new testnet from zero wouldn't solve anything, since the attacker can mount the same attack over and over again. The Parity team decided to go with an emergency solution of rolling back a significant number of blocks, and enacting a soft-fork rule that disallows gas limits above a certain threshold.</p> <p>While this solution may work in the short term:</p> <ul> <li>It's not elegant: Ethereum supposed to have dynamic block limits</li> <li>It's not portable: other clients need to implement new fork logic themselves</li> <li>It's not compatible with sync modes: fast and light clients are both out of luck</li> <li>It's just prolonging the attacks: junk can still be steadily pushed in ad infinitum</li> </ul> <p>Parity's solution although not perfect, is nonetheless workable. I'd like to propose a longer term alternative solution, which is more involved, yet should be simple enough to allow rolling out in a reasonable amount of time.</p> <h3 id="standardized-proof-of-authority">Standardized proof-of-authority</h3> <p>As reasoned above, proof-of-work cannot work securely in a network with no value. Ethereum has its long term goal of proof-of-stake based on Casper, but that is heavy research so we cannot rely on that any time soon to fix today's problems. One solution however is easy enough to implement, yet effective enough to fix the testnet properly, namely a proof-of-authority scheme.</p> <p>The main design goals of the PoA protocol described here is that it should be very simple to implement and embed into any existing Ethereum client, while at the same time allow using existing sync technologies (fast, light, warp) without needing client developers to add custom logic to critical software.</p> <h2 id="design-constraints">Design constraints</h2> <p>There are two approaches to syncing a blockchain in general:</p> <ul> <li>The classical approach is to take the genesis block and crunch through all the transactions one by one. This is tried and proven, but in Ethereum complexity networks quickly turns out to be very costly computationally.</li> <li>The other is to only download the chain of block headers and verify their validity, after which point an arbitrary recent state may be downloaded from the network and checked against recent headers.</li> </ul> <p>A PoA scheme is based on the idea that blocks may only be minted by trusted signers. As such, every block (or header) that a client sees can be matched against the list of trusted signers. The challenge here is how to maintain a list of authorized signers that can change in time? The obvious answer (store it in an Ethereum contract) is also the wrong answer: fast, light and warp sync don't have access to the state during syncing.</p> <p><strong>The protocol of maintaining the list of authorized signers must be fully contained in the block headers.</strong></p> <p>The next obvious idea would be to change the structure of the block headers so it drops the notions of PoW, and introduces new fields to cater for voting mechanisms. This is also the wrong answer: changing such a core data structure in multiple implementations would be a nightmare development, maintenance and security wise.</p> <p><strong>The protocol of maintaining the list of authorized signers must fit fully into the current data models.</strong></p> <p>So, according to the above, we can't use the EVM for voting, rather have to resort to headers. And we can't change header fields, rather have to resort to the currently available ones. Not much wiggle room.</p> <h3 id="repurposing-header-fields-for-signing-and-voting">Repurposing header fields for signing and voting</h3> <p>The most obvious field that currently is used solely as <em>fun metadata</em> is the 32 byte <strong>extra-data</strong> section in block headers. Miners usually place their client and version in there, but some fill it with alternative "messages". The protocol would extend this field <del>to</del> with 65 bytes with the purpose of a secp256k1 miner signature. This would allow anyone obtaining a block to verify it against a list of authorized signers. It also makes the <strong>miner</strong> section in block headers obsolete (since the address can be derived from the signature).</p> <p><em>Note, changing the length of a header field is a non invasive operation as all code (such as RLP encoding, hashing) is agnostic to that, so clients wouldn't need custom logic.</em></p> <p>The above is enough to validate a chain, but how can we update a dynamic list of signers. The answer is that we can repurpose the newly obsoleted <strong>miner</strong> field and the PoA obsoleted <strong>nonce</strong> field to create a voting protocol:</p> <ul> <li>During regular blocks, both of these fields would be set to zero.</li> <li>If a signer wishes to enact a change to the list of authorized signers, it will: <ul> <li>Set the <strong>miner</strong> to the signer it wishes to vote about</li> <li>Set the <strong>nonce</strong> to <code>0</code> or <code>0xff...f</code> to vote in favor of adding or kicking out</li> </ul> </li> </ul> <p>Any clients syncing the chain can "tally" up the votes during block processing, and maintain a dynamically changing list of authorized signers by popular vote.</p> <p>To avoid having an infinite window to tally up votes in, and also to allow periodically flushing stale proposals, we can reuse the concept of an epoch from ethash, where every epoch transition flushes all pending votes. Furthermore, these epoch transitions can also act as stateless checkpoints containing the list of current authorized signers within the header extra-data. This permits clients to sync up based only on a checkpoint hash without having to replay all the voting that was done on the chain up to that point. It also allows the genesis header to fully define the chain, containing the list of initial signers.</p> <h3 id="attack-vector-malicious-signer">Attack vector: Malicious signer</h3> <p>It may happen that a malicious user gets added to the list of signers, or that a signer key/machine is compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the miners can vote out the malicious user.</p> <h3 id="attack-vector-censoring-signer">Attack vector: Censoring signer</h3> <p>Another interesting attack vector is if a signer (or group of signers) attempts to censor out blocks that vote on removing them from the authorization list. To work around this, we restrict the allowed minting frequency of signers to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which case it's game over anyway.</p> <h3 id="attack-vector-spamming-signer">Attack vector: Spamming signer</h3> <p>A final small attack vector is that of malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they need to track all votes through time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a <del>moving</del> window of W blocks after which votes are considered stale. <del>A sane window might be 1-2 epochs.</del> We'll call this an epoch.</p> <h3 id="attack-vector-concurrent-blocks">Attack vector: Concurrent blocks</h3> <p>If the number of authorized signers are N, and we allow each signer to mint 1 block out of K, then at any point in time N-K+1 miners are allowed to mint. To avoid these racing for blocks, every signer would add a small random "offset" to the time it releases a new block. This ensures that small forks are rare, but occasionally still happen (as on the main net). If a signer is caught abusing it's authority and causing chaos, it can be voted out.</p> <h2 id="specification">Specification</h2> <p>We define the following constants:</p> <ul> <li><strong><code>EPOCH_LENGTH</code></strong>: Number of blocks after which to checkpoint and reset the pending votes. <ul> <li>Suggested <code>30000</code> for the testnet to remain analogous to the mainnet <code>ethash</code> epoch.</li> </ul> </li> <li><strong><code>BLOCK_PERIOD</code></strong>: Minimum difference between two consecutive block's timestamps. <ul> <li>Suggested <code>15s</code> for the testnet to remain analogous to the mainnet <code>ethash</code> target.</li> </ul> </li> <li><strong><code>EXTRA_VANITY</code></strong>: Fixed number of extra-data prefix bytes reserved for signer <em>vanity</em>. <ul> <li>Suggested <code>32 bytes</code> to retain the current extra-data allowance and/or use.</li> </ul> </li> <li><strong><code>EXTRA_SEAL</code></strong>: Fixed number of extra-data suffix bytes reserved for signer seal. <ul> <li><code>65 bytes</code> fixed as signatures are based on the standard <code>secp256k1</code> curve.</li> <li>Filled with zeros on genesis block.</li> </ul> </li> <li><strong><code>NONCE_AUTH</code></strong>: Magic nonce number <code>0xffffffffffffffff</code> to vote on adding a new signer.</li> <li><strong><code>NONCE_DROP</code></strong>: Magic nonce number <code>0x0000000000000000</code> to vote on removing a signer.</li> <li><strong><code>UNCLE_HASH</code></strong>: Always <code>Keccak256(RLP([]))</code> as uncles are meaningless outside of PoW.</li> <li><strong><code>DIFF_NOTURN</code></strong>: Block score (difficulty) for blocks containing out-of-turn signatures. <ul> <li>Suggested <code>1</code> since it just needs to be an arbitrary baseline constant.</li> </ul> </li> <li><strong><code>DIFF_INTURN</code></strong>: Block score (difficulty) for blocks containing in-turn signatures. <ul> <li>Suggested <code>2</code> to show a slight preference over out-of-turn signatures.</li> </ul> </li> </ul> <p>We also define the following per-block constants:</p> <ul> <li><strong><code>BLOCK_NUMBER</code></strong>: Block height in the chain, where the height of the genesis is block <code>0</code>.</li> <li><strong><code>SIGNER_COUNT</code></strong>: Number of authorized signers valid at a particular instance in the chain.</li> <li><strong><code>SIGNER_INDEX</code></strong>: Zero-based index of the block signer in the sorted list of current authorized signers.</li> <li><strong><code>SIGNER_LIMIT</code></strong>: Number of consecutive blocks out of which a signer may only sign one. <ul> <li>Must be <code>floor(SIGNER_COUNT / 2) + 1</code> to enforce majority consensus on a chain.</li> </ul> </li> </ul> <p>We repurpose the <code>ethash</code> header fields as follows:</p> <ul> <li><strong><code>beneficiary</code></strong> / <strong><code>miner</code></strong>: Address to propose modifying the list of authorized signers with. <ul> <li>Should be filled with zeroes normally, modified only while voting.</li> <li>Arbitrary values are permitted nonetheless (even meaningless ones such as voting out non signers) to avoid extra complexity in implementations around voting mechanics.</li> <li><strong>Must</strong> be filled with zeroes on checkpoint (i.e. epoch transition) blocks.</li> <li>Transaction execution <strong>must</strong> use the actual block signer (see <code>extraData</code>) for the <code>COINBASE</code> opcode and transaction fees <strong>must</strong> be attributed to the signer account.</li> </ul> </li> <li><strong><code>nonce</code></strong>: Signer proposal regarding the account defined by the <code>beneficiary</code> field. <ul> <li>Should be <strong><code>NONCE_DROP</code></strong> to propose deauthorizing <code>beneficiary</code> as an existing signer.</li> <li>Should be <strong><code>NONCE_AUTH</code></strong> to propose authorizing <code>beneficiary</code> as a new signer.</li> <li><strong>Must</strong> be filled with zeroes on checkpoint (i.e. epoch transition) blocks.</li> <li><strong>Must</strong> not take up any other value apart from the two above (for now).</li> </ul> </li> <li><strong><code>extraData</code></strong>: Combined field for signer vanity, checkpointing and signer signatures. <ul> <li>First <strong><code>EXTRA_VANITY</code></strong> bytes (fixed) may contain arbitrary signer vanity data.</li> <li>Last <strong><code>EXTRA_SEAL</code></strong> bytes (fixed) is the signer's signature sealing the header.</li> <li>Checkpoint blocks <strong>must</strong> contain a list of signers (<code>N*20 bytes</code>) in between, <strong>omitted</strong> otherwise.</li> <li>The list of signers in checkpoint block extra-data sections <strong>must</strong> be sorted in ascending byte order.</li> </ul> </li> <li><strong><code>mixHash</code></strong>: Reserved for fork protection logic, similar to the extra-data during the DAO. <ul> <li><strong>Must</strong> be filled with zeroes during normal operation.</li> </ul> </li> <li><strong><code>ommersHash</code></strong>: <strong>Must</strong> be <strong><code>UNCLE_HASH</code></strong> as uncles are meaningless outside of PoW.</li> <li><strong><code>timestamp</code></strong>: <strong>Must</strong> be at least the parent timestamp + <strong><code>BLOCK_PERIOD</code></strong>.</li> <li><strong><code>difficulty</code></strong>: Contains the standalone score of the block to derive the quality of a chain. <ul> <li><strong>Must</strong> be <strong><code>DIFF_NOTURN</code></strong> if <code>BLOCK_NUMBER % SIGNER_COUNT != SIGNER_INDEX</code></li> <li><strong>Must</strong> be <strong><code>DIFF_INTURN</code></strong> if <code>BLOCK_NUMBER % SIGNER_COUNT == SIGNER_INDEX</code></li> </ul> </li> </ul> <h3 id="authorizing-a-block">Authorizing a block</h3> <p>To authorize a block for the network, the signer needs to sign the block's sighash containing <strong>everything except the signature itself</strong>. This means that this hash contains every field of the header (<code>nonce</code> and <code>mixDigest</code> included), and also the <code>extraData</code> with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper. Note that this sighash differs from the final block hash which also includes the signature.</p> <p>The sighash is signed using the standard <code>secp256k1</code> curve, and the resulting 65 byte signature (<code>R</code>, <code>S</code>, <code>V</code>, where <code>V</code> is <code>0</code> or <code>1</code>) is embedded into the <code>extraData</code> as the trailing 65 byte suffix.</p> <p>To ensure malicious signers (loss of signing key) cannot wreck havoc in the network, each signer is allowed to sign <strong>maximum one</strong> out of <strong><code>SIGNER_LIMIT</code></strong> consecutive blocks. The order is not fixed, but in-turn signing weighs more (<strong><code>DIFF_INTURN</code></strong>) than out of turn one (<strong><code>DIFF_NOTURN</code></strong>).</p> <h4 id="authorization-strategies">Authorization strategies</h4> <p>As long as signers conform to the above specs, they can authorize and distribute blocks as they see fit. The following suggested strategy will however reduce network traffic and small forks, so it's a suggested feature:</p> <ul> <li>If a signer is allowed to sign a block (is on the authorized list and didn't sign recently). <ul> <li>Calculate the optimal signing time of the next block (parent + <strong><code>BLOCK_PERIOD</code></strong>).</li> <li>If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately.</li> <li>If the signer is out-of-turn, delay signing by <code>rand(SIGNER_COUNT * 500ms)</code>.</li> </ul> </li> </ul> <p>This small strategy will ensure that the in-turn signer (who's block weighs more) has a slight advantage to sign and propagate versus the out-of-turn signers. Also the scheme allows a bit of scale with the increase of the number of signers.</p> <h3 id="voting-on-signers">Voting on signers</h3> <p>Every epoch transition (genesis block included) acts as a stateless checkpoint, from which capable clients should be able to sync without requiring any previous state. This means epoch headers <strong>must not</strong> contain votes, all non settled votes are discarded, and tallying starts from scratch.</p> <p>For all non-epoch transition blocks:</p> <ul> <li>Signers may cast one vote per own block to propose a change to the authorization list.</li> <li>Only the latest proposal per target beneficiary is kept from a single signer.</li> <li>Votes are tallied live as the chain progresses (concurrent proposals allowed).</li> <li>Proposals reaching majority consensus <strong><code>SIGNER_LIMIT</code></strong> come into effect immediately.</li> <li>Invalid proposals are <strong>not</strong> to be penalized for client implementation simplicity.</li> </ul> <p><strong>A proposal coming into effect entails discarding all pending votes for that proposal (both for and against) and starting with a clean slate.</strong></p> <h4 id="cascading-votes">Cascading votes</h4> <p>A complex corner case may arise during signer deauthorization. When a previously authorized signer is dropped, the number of signers required to approve a proposal might decrease by one. This might cause one or more pending proposals to reach majority consensus, the execution of which might further cascade into new proposals passing.</p> <p>Handling this scenario is non obvious when multiple conflicting proposals pass simultaneously (e.g. add a new signer vs. drop an existing one), where the evaluation order might drastically change the outcome of the final authorization list. Since signers may invert their own votes in every block they mint, it's not so obvious which proposal would be "first".</p> <p>To avoid the pitfalls cascading executions would entail, the Clique proposal explicitly forbids cascading effects. In other words: <strong>Only the <code>beneficiary</code> of the current header/vote may be added to/dropped from the authorization list. If that causes other proposals to reach consensus, those will be executed when their respective beneficiaries are "touched" again (given that majority consensus still holds at that point).</strong></p> <h4 id="voting-strategies">Voting strategies</h4> <p>Since the blockchain can have small reorgs, a naive voting mechanism of "cast-and-forget" may not be optimal, since a block containing a singleton vote may not end up on the final chain.</p> <p>A simplistic but working strategy is to allow users to configure "proposals" on the signers (e.g. "add 0x...", "drop 0x..."). The signing code can then pick a random proposal for every block it signs and inject it. This ensures that multiple concurrent proposals as well as reorgs get eventually noted on the chain.</p> <p>This list may be expired after a certain number of blocks / epochs, but it's important to realize that "seeing" a proposal pass doesn't mean it won't get reorged, so it should not be immediately dropped when the proposal passes.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="go"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> block represents a single block signed by a particular account, where</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> the account may or may not have cast a Clique vote.</span></span> <span class="giallo-l"><span class="z-keyword">type</span><span class="z-entity z-name"> block</span><span class="z-keyword"> struct</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-other"> signer</span><span class="z-storage z-type"> string</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Account that signed this particular block</span></span> <span class="giallo-l"><span class="z-variable z-other"> voted</span><span class="z-storage z-type"> string</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Optional value if the signer voted on adding/removing someone</span></span> <span class="giallo-l"><span class="z-variable z-other"> auth</span><span class="z-storage z-type"> bool</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Whether the vote was to authorize (or deauthorize)</span></span> <span class="giallo-l"><span class="z-variable z-other"> checkpoint</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> List of authorized signers if this is an epoch block</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">//</span><span class="z-comment"> Define the various voting scenarios to test</span></span> <span class="giallo-l"><span class="z-variable z-other">tests</span><span class="z-keyword"> :=</span><span> [</span><span>]</span><span class="z-keyword">struct</span><span> {</span></span> <span class="giallo-l"><span class="z-variable z-other"> epoch</span><span class="z-storage z-type"> uint64</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Number of blocks in an epoch (unset = 30000)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Initial list of authorized signers in the genesis</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Chain of signed blocks, potentially influencing auths</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Final list of authorized signers after all blocks</span></span> <span class="giallo-l"><span class="z-variable z-other"> failure</span><span class="z-storage z-type"> error</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Failure if some block is invalid according to the rules</span></span> <span class="giallo-l"><span>}</span><span>{</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Single signer, no votes cast</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Single signer, voting to add two others (only accept first, second needs 2 votes)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Two signers, voting to add three others (only accept first two, third needs 3 votes already)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Single signer, dropping itself (weird, but one less cornercase by explicitly allowing this)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Two signers, actually needing mutual consent to drop either of them (not fulfilled)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Two signers, actually needing mutual consent to drop either of them (fulfilled)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Three signers, two of them deciding to drop the third</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Four signers, consensus of two not being enough to drop anyone</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Four signers, consensus of three already being enough to drop someone</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Authorizations are counted once per signer per target</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Authorizing multiple accounts concurrently is permitted</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Deauthorizations are counted once per signer per target</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Deauthorizing multiple accounts concurrently is permitted</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Votes from deauthorized signers are discarded immediately (deauth votes)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Votes from deauthorized signers are discarded immediately (auth votes)</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Cascading changes are not allowed, only the account being voted on may change</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Changes reaching consensus out of bounds (via a deauth) execute on touch</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Changes reaching consensus out of bounds (via a deauth) may go out of consensus on first touch</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Ensure that pending votes don&#39;t survive authorization status changes. This</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> corner case can only appear if a signer is quickly added, removed and then</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> readded (or the inverse), while one of the original voters dropped. If a</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> past vote is left cached in the system somewhere, this will interfere with</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> the final signer outcome.</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Authorize F, 3 votes needed</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Deauthorize F, 4 votes needed (leave A&#39;s previous vote &quot;unchanged&quot;)</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Almost authorize F, 2/3 votes needed</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Deauthorize A, 3 votes needed</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> false</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Finish authorizing F, 3/3 votes needed</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">D</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">E</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">F</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Epoch transitions reset all votes to allow chain checkpointing</span></span> <span class="giallo-l"><span class="z-variable z-other"> epoch</span><span>:</span><span class="z-constant"> 3</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> checkpoint</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> voted</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> auth</span><span>:</span><span class="z-constant"> true</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> results</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> An unauthorized signer should not be able to sign blocks</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> failure</span><span>:</span><span class="z-variable z-other"> errUnauthorizedSigner</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> An authorized signer that signed recently should not be able to sign again</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> failure</span><span>:</span><span class="z-variable z-other"> errRecentlySigned</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Recent signatures should not reset on checkpoint blocks imported in a batch</span></span> <span class="giallo-l"><span class="z-variable z-other"> epoch</span><span>:</span><span class="z-constant"> 3</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> signers</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> blocks</span><span>:</span><span> [</span><span>]</span><span class="z-entity z-name">block</span><span>{</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-variable z-other"> checkpoint</span><span>:</span><span> [</span><span>]</span><span class="z-storage z-type">string</span><span>{</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">B</span><span class="z-punctuation z-definition z-string">&quot;</span><span>,</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">C</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> {</span><span class="z-variable z-other">signer</span><span>:</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-string">A</span><span class="z-punctuation z-definition z-string">&quot;</span><span>}</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span class="z-variable z-other"> failure</span><span>:</span><span class="z-variable z-other"> errRecentlySigned</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>,</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="implementation">Implementation</h2> <p>A reference implementation is part of <a rel="external" href="https://github.com/ethereum/go-ethereum/tree/master/consensus/clique">go-ethereum</a> and has been functioning as the consensus engine behind the <a rel="external" href="https://www.rinkeby.io">Rinkeby</a> testnet since April, 2017.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Paweł Bylicahttps://github.com/chfast https://wg-eips.ritovision.com/145/

To Provide native bitwise shifting with cost on par with other arithmetic operations.

<h2 id="abstract">Abstract</h2> <p>Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.</p> <h2 id="motivation">Motivation</h2> <p>EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing <code>SHL</code> and <code>SHR</code> using arithmetic cost each 35 gas, while the proposed instructions take 3 gas.</p> <h2 id="specification">Specification</h2> <p>The following instructions are introduced:</p> <h3 id="0x1b-shl-shift-left"><code>0x1b</code>: <code>SHL</code> (shift left)</h3> <p>The <code>SHL</code> instruction (shift left) pops 2 values from the stack, first <code>arg1</code> and then <code>arg2</code>, and pushes on the stack <code>arg2</code> shifted to the left by <code>arg1</code> number of bits. The result is equal to</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(arg2 * 2^arg1) mod 2^256</span></span></code></pre> <p>Notes:</p> <ul> <li>The value (<code>arg2</code>) is interpreted as an unsigned number.</li> <li>The shift amount (<code>arg1</code>) is interpreted as an unsigned number.</li> <li>If the shift amount (<code>arg1</code>) is greater or equal 256 the result is 0.</li> <li>This is equivalent to <code>PUSH1 2 EXP MUL</code>.</li> </ul> <h3 id="0x1c-shr-logical-shift-right"><code>0x1c</code>: <code>SHR</code> (logical shift right)</h3> <p>The <code>SHR</code> instruction (logical shift right) pops 2 values from the stack, first <code>arg1</code> and then <code>arg2</code>, and pushes on the stack <code>arg2</code> shifted to the right by <code>arg1</code> number of bits with zero fill. The result is equal to</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>floor(arg2 / 2^arg1)</span></span></code></pre> <p>Notes:</p> <ul> <li>The value (<code>arg2</code>) is interpreted as an unsigned number.</li> <li>The shift amount (<code>arg1</code>) is interpreted as an unsigned number.</li> <li>If the shift amount (<code>arg1</code>) is greater or equal 256 the result is 0.</li> <li>This is equivalent to <code>PUSH1 2 EXP DIV</code>.</li> </ul> <h3 id="0x1d-sar-arithmetic-shift-right"><code>0x1d</code>: <code>SAR</code> (arithmetic shift right)</h3> <p>The <code>SAR</code> instruction (arithmetic shift right) pops 2 values from the stack, first <code>arg1</code> and then <code>arg2</code>, and pushes on the stack <code>arg2</code> shifted to the right by <code>arg1</code> number of bits with sign extension. The result is equal to</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>floor(arg2 / 2^arg1)</span></span></code></pre> <p>Notes:</p> <ul> <li>The value (<code>arg2</code>) is interpreted as a signed number.</li> <li>The shift amount (<code>arg1</code>) is interpreted as an unsigned number.</li> <li>If the shift amount (<code>arg1</code>) is greater or equal 256 the result is 0 if <code>arg2</code> is non-negative or -1 if <code>arg2</code> is negative.</li> <li>This is <strong>not</strong> equivalent to <code>PUSH1 2 EXP SDIV</code>, since it rounds differently. See <code>SDIV(-1, 2) == 0</code>, while <code>SAR(-1, 1) == -1</code>.</li> </ul> <p>The cost of the shift instructions is set at <code>verylow</code> tier (3 gas).</p> <h2 id="rationale">Rationale</h2> <p>Instruction operands were chosen to fit the more natural use case of shifting a value already on the stack. This means the operand order is swapped compared to most arithmetic instructions.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>The newly introduced instructions have no effect on bytecode created in the past.</p> <h2 id="test-cases">Test Cases</h2> <h3 id="shl-shift-left"><code>SHL</code> (shift left)</h3> <ol> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000002</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x8000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x0101</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x8000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHL</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe</span></span></code></pre></li> </ol> <h3 id="shr-logical-shift-right"><code>SHR</code> (logical shift right)</h3> <ol> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x4000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x0101</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SHR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> </ol> <h3 id="sar-arithmetic-shift-right"><code>SAR</code> (arithmetic shift right)</h3> <ol> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xc000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x0101</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x00</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0x01</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x4000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>PUSH 0xfe</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xf8</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x000000000000000000000000000000000000000000000000000000000000007f</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xfe</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0xff</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> <li><pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>PUSH 0x0100</span></span> <span class="giallo-l"><span>SAR</span></span> <span class="giallo-l"><span>---</span></span> <span class="giallo-l"><span>0x0000000000000000000000000000000000000000000000000000000000000000</span></span></code></pre></li> </ol> <h3 id="implementation">Implementation</h3> <p>Client support:</p> <ul> <li>cpp-ethereum: https://github.com/ethereum/cpp-ethereum/pull/4054</li> </ul> <p>Compiler support:</p> <ul> <li>Solidity/LLL: https://github.com/ethereum/solidity/pull/2541</li> </ul> <h3 id="tests">Tests</h3> <p>Sources:</p> <ul> <li>https://github.com/ethereum/tests/tree/develop/src/GeneralStateTestsFiller/stShift</li> </ul> <p>Filled Tests:</p> <ul> <li>https://github.com/ethereum/tests/tree/develop/GeneralStateTests/stShift</li> <li>https://github.com/ethereum/tests/tree/develop/BlockchainTests/GeneralStateTests/stShift</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Christian Reitwiessnerchris@ethereum.org https://wg-eips.ritovision.com/211/ <h2 id="simple-summary">Simple Summary</h2> <p>A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.</p> <h2 id="abstract">Abstract</h2> <p>Please see summary.</p> <h2 id="motivation">Motivation</h2> <p>In some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls.</p> <p>Compiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use <code>RETURNDATACOPY</code> in conjunction with <code>RETURNDATASIZE</code> to actually retrieve the data.</p> <p>Note that this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion (<a href="https://wg-eips.ritovision.com/140/">EIP-140</a>) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code>, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like <code>CALL</code>, <code>CREATE</code>, <code>DELEGATECALL</code>, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see <a href="https://wg-eips.ritovision.com/140/">EIP-140</a>) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, <code>CREATE</code> and <code>CREATE2</code> are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty.</p> <p>As an optimization, it is possible to share the return data buffer across call frames because at most one will be non-empty at any time.</p> <p><code>RETURNDATASIZE</code>: <code>0x3d</code></p> <p>Pushes the size of the return data buffer onto the stack. Gas costs: 2 (same as <code>CALLDATASIZE</code>)</p> <p><code>RETURNDATACOPY</code>: <code>0x3e</code></p> <p>This opcode has similar semantics to <code>CALLDATACOPY</code>, but instead of copying data from the call data, it copies data from the return data buffer. Furthermore, accessing the return data buffer beyond its size results in a failure; i.e. if <code>start + length</code> overflows or results in a value larger than <code>RETURNDATASIZE</code>, the current call stops in an out-of-gas condition. In particular, reading 0 bytes from the end of the buffer will read 0 bytes; reading 0 bytes from one-byte out of the buffer causes an exception.</p> <p>Gas costs: <code>3 + 3 * ceil(amount / 32)</code> (same as <code>CALLDATACOPY</code>)</p> <h2 id="rationale">Rationale</h2> <p>Other solutions that would allow returning dynamic data were considered, but they all had to deduct the gas from the call opcode and thus were both complicated to implement and specify (<a rel="external" href="https://github.com/ethereum/EIPs/issues/8">5/8</a>). Since this proposal is very similar to the way calldata is handled, it fits nicely into the concept. Furthermore, the eWASM architecture already handles return data in exactly the same way.</p> <p>Note that the EVM implementation needs to keep the return data until the next call or the return from the current call. Since this resource was already paid for as part of the memory of the callee, it should not be a problem. Implementations may either choose to keep the full memory of the callee alive until the next call or copy only the return data to a special memory area.</p> <p>Keeping the memory of the callee until the next call-like opcode does not increase the peak memory usage in the following sense; any memory allocation in the caller's frame that happens after the return from the call can be moved before the call without a change in gas costs, but will add this allocation to the peak allocation.</p> <p>The number values of the opcodes were allocated in the same nibble block that also contains <code>CALLDATASIZE</code> and <code>CALLDATACOPY</code>.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal introduces two new opcodes and stays fully backwards compatible apart from that.</p> <h2 id="test-cases">Test Cases</h2> <h2 id="implementation">Implementation</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-13T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinvitalik@ethereum.org Christian Reitwiessnerchris@ethereum.org https://wg-eips.ritovision.com/214/ <h2 id="simple-summary">Simple Summary</h2> <p>To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).</p> <h2 id="abstract">Abstract</h2> <p>This proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). Any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification.</p> <h2 id="motivation">Motivation</h2> <p>Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases.</p> <p>This EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call.</p> <h2 id="specification">Specification</h2> <p>Introduce a new <code>STATIC</code> flag to the virtual machine. This flag is set to <code>false</code> initially. Its value is always copied to sub-calls with an exception for the new opcode below.</p> <p>Opcode: <code>0xfa</code>.</p> <p><code>STATICCALL</code> functions equivalently to a <code>CALL</code>, except it takes only 6 arguments (the "value" argument is not included and taken to be zero), and calls the child with the <code>STATIC</code> flag set to <code>true</code> for the execution of the child. Once this call returns, the flag is reset to its value before the call.</p> <p>Any attempts to make state-changing operations inside an execution instance with <code>STATIC</code> set to <code>true</code> will instead throw an exception. These operations include <code>CREATE</code>, <code>CREATE2</code>, <code>LOG0</code>, <code>LOG1</code>, <code>LOG2</code>, <code>LOG3</code>, <code>LOG4</code>, <code>SSTORE</code>, and <code>SELFDESTRUCT</code>. They also include <code>CALL</code> with a non-zero value. As an exception, <code>CALLCODE</code> is not considered state-changing, even with a non-zero value.</p> <h2 id="rationale">Rationale</h2> <p>This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode.</p> <h2 id="test-cases">Test Cases</h2> <p>To be written.</p> <h2 id="implementation">Implementation</h2> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/210/ <h3 id="summary">Summary</h3> <p>Stores blockhashes in the state, reducing the protocol complexity and the need for client implementation complexity in order to process the BLOCKHASH opcode. Also extends the range of how far back blockhash checking can go, with the side effect of creating direct links between blocks with very distant block numbers, facilitating much more efficient initial light client syncing.</p> <h3 id="parameters">Parameters</h3> <ul> <li><code>CONSTANTINOPLE_FORK_BLKNUM</code>: TBD</li> <li><code>SUPER_USER</code>: 2**160 - 2</li> <li><code>BLOCKHASH_CONTRACT_ADDR</code>: 0xf0 (ie. 240)</li> <li><code>BLOCKHASH_CONTRACT_CODE</code>: see below</li> </ul> <h3 id="specification">Specification</h3> <p>If <code>block.number == CONSTANTINOPLE_FORK_BLKNUM</code>, then when processing the block, before processing any transactions set the code of BLOCKHASH_CONTRACT_ADDR to BLOCKHASH_CONTRACT_CODE.</p> <p>If <code>block.number &gt;= CONSTANTINOPLE_FORK_BLKNUM</code>, then when processing a block, before processing any transactions execute a call with the parameters:</p> <ul> <li><code>SENDER</code>: SUPER_USER</li> <li><code>GAS</code>: 1000000</li> <li><code>TO</code>: BLOCKHASH_CONTRACT_ADDR</li> <li><code>VALUE</code>: 0</li> <li><code>DATA</code>: &lt;32 bytes corresponding to the block's prevhash&gt;</li> </ul> <p>If <code>block.number &gt;= CONSTANTINOPLE_FORK_BLKNUM + 256</code>, then the BLOCKHASH opcode instead returns the result of executing a call (NOT a transaction) with the parameters:</p> <ul> <li><code>SENDER</code>: &lt;account from which the opcode was called&gt;</li> <li><code>GAS</code>: 1000000</li> <li><code>TO</code>: BLOCKHASH_CONTRACT_ADDR</li> <li><code>VALUE</code>: 0</li> <li><code>DATA</code>: 32 byte zero-byte-leftpadded integer representing the stack argument with which the opcode was called</li> </ul> <p>Also, for blocks where <code>block.number &gt;= CONSTANTINOPLE_FORK_BLKNUM</code>, the gas cost is increased from 20 to 800 to reflect the higher costs of processing the algorithm in the contract code.</p> <h3 id="blockhash-contract-code">BLOCKHASH_CONTRACT_CODE</h3> <p>The Serpent source code is:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">with</span><span> offset</span><span class="z-keyword"> =</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> msg</span><span>.</span><span>sender</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">fffffffffffffffffffffffffffffffffffffffe</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> with</span><span> bn</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> bn</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span>sstore</span><span>(</span><span>offset</span><span class="z-keyword"> +</span><span class="z-keyword"> ~</span><span>mod</span><span>(</span><span>bn</span><span>,</span><span class="z-constant"> 256</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-keyword"> ~</span><span>mod</span><span>(</span><span>bn</span><span>,</span><span class="z-constant"> 256</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span>stop</span><span>(</span><span>)</span></span> <span class="giallo-l"><span> bn</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>div</span><span>(</span><span>bn</span><span>,</span><span class="z-constant"> 256</span><span>)</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> +=</span><span class="z-constant"> 256</span></span> <span class="giallo-l"><span class="z-keyword"> elif</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 0</span><span class="z-keyword"> and</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> &lt;</span><span> block</span><span>.</span><span>number</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> with</span><span> tbn</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> with</span><span> dist_minus_one</span><span class="z-keyword"> =</span><span> block</span><span>.</span><span>number</span><span class="z-keyword"> -</span><span> tbn</span><span class="z-keyword"> -</span><span class="z-constant"> 1</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> while</span><span> dist_minus_one</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 256</span><span class="z-invalid z-illegal"> &amp;&amp;</span><span class="z-keyword"> ~</span><span>mod</span><span>(</span><span>tbn</span><span>,</span><span class="z-constant"> 256</span><span>)</span><span class="z-keyword"> ==</span><span class="z-constant"> 0</span><span>:</span></span> <span class="giallo-l"><span> offset</span><span class="z-keyword"> +=</span><span class="z-constant"> 256</span></span> <span class="giallo-l"><span> tbn</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>div</span><span>(</span><span>tbn</span><span>,</span><span class="z-constant"> 256</span><span>)</span><span> </span></span> <span class="giallo-l"><span> dist_minus_one</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>div</span><span>(</span><span>dist_minus_one</span><span>,</span><span class="z-constant"> 256</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span> dist_minus_one</span><span class="z-keyword"> &gt;=</span><span class="z-constant"> 256</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span>(</span><span class="z-keyword">~</span><span>sload</span><span>(</span><span>offset</span><span class="z-keyword"> +</span><span class="z-keyword"> ~</span><span>mod</span><span>(</span><span>tbn</span><span>,</span><span class="z-constant"> 256</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span>(</span><span class="z-constant">0</span><span>)</span></span></code></pre> <p>The EVM init code is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0x6100f58061000e60003961010356600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b505b6000f3</span></span></code></pre> <p>The EVM bytecode that the contract code should be set to is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0x600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b50</span></span></code></pre><h3 id="rationale">Rationale</h3> <p>This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols.</p> 2017-02-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/86/ <h1 id="summary">Summary</h1> <p>Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.</p> <h1 id="parameters">Parameters</h1> <ul> <li>METROPOLIS_FORK_BLKNUM: TBD</li> <li>CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet)</li> <li>NULL_SENDER: 2**160 - 1</li> </ul> <h1 id="specification">Specification</h1> <p>If <code>block.number &gt;= METROPOLIS_FORK_BLKNUM</code>, then:</p> <ol> <li>If the signature of a transaction is <code>(CHAIN_ID, 0, 0)</code> (ie. <code>r = s = 0</code>, <code>v = CHAIN_ID</code>), then treat it as valid and set the sender address to <code>NULL_SENDER</code></li> <li>Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account NULL_SENDER.</li> <li>Create a new opcode at <code>0xfb</code>, <code>CREATE2</code>, with 4 stack arguments (value, salt, mem_start, mem_size) which sets the creation address to <code>sha3(sender + salt + sha3(init code)) % 2**160</code>, where <code>salt</code> is always represented as a 32-byte value.</li> <li>Add to <em>all</em> contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed.</li> </ol> <h1 id="rationale">Rationale</h1> <p>The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.</p> <p>Under EIP 86, we can expect users to store their ether in contracts, whose code might look like the following (example in Serpent):</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Get signature from tx data</span></span> <span class="giallo-l"><span>sig_v</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span></span> <span class="giallo-l"><span>sig_r</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">32</span><span>)</span></span> <span class="giallo-l"><span>sig_s</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">64</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Get tx arguments</span></span> <span class="giallo-l"><span>tx_nonce</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">96</span><span>)</span></span> <span class="giallo-l"><span>tx_to</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">128</span><span>)</span></span> <span class="giallo-l"><span>tx_value</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">160</span><span>)</span></span> <span class="giallo-l"><span>tx_gasprice</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">192</span><span>)</span></span> <span class="giallo-l"><span>tx_data</span><span class="z-keyword"> =</span><span> string</span><span>(</span><span class="z-keyword">~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 224</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>calldataload</span><span>(</span><span>tx_data</span><span>,</span><span class="z-constant"> 224</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Get signing hash</span></span> <span class="giallo-l"><span>signing_data</span><span class="z-keyword"> =</span><span> string</span><span>(</span><span class="z-keyword">~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 64</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>mstore</span><span>(</span><span>signing_data</span><span>,</span><span> tx</span><span>.</span><span>startgas</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>calldataload</span><span>(</span><span>signing_data</span><span class="z-keyword"> +</span><span class="z-constant"> 32</span><span>,</span><span class="z-constant"> 96</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 96</span><span>)</span></span> <span class="giallo-l"><span>signing_hash</span><span class="z-keyword"> =</span><span> sha3</span><span>(</span><span>signing_data</span><span>:</span><span class="z-support">str</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Perform usual checks</span></span> <span class="giallo-l"><span>prev_nonce</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>sload</span><span>(</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> tx_nonce</span><span class="z-keyword"> ==</span><span> prev_nonce</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-variable z-language"> self</span><span>.</span><span>balance</span><span class="z-keyword"> &gt;=</span><span> tx_value</span><span class="z-keyword"> +</span><span> tx_gasprice</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>startgas</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-keyword"> ~</span><span>ecrecover</span><span>(</span><span>signing_hash</span><span>,</span><span> sig_v</span><span>,</span><span> sig_r</span><span>,</span><span> sig_s</span><span>)</span><span class="z-keyword"> ==</span><span class="z-keyword"> &lt;</span><span>pubkey</span><span class="z-support"> hash</span><span> here</span><span class="z-keyword">&gt;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Update nonce</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>sstore</span><span>(</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>,</span><span> prev_nonce</span><span class="z-keyword"> +</span><span class="z-constant"> 1</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Pay for gas</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>send</span><span>(</span><span class="z-constant">MINER_CONTRACT</span><span>,</span><span> tx_gasprice</span><span class="z-keyword"> *</span><span> tx</span><span>.</span><span>startgas</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Make the main call</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>call</span><span>(</span><span>msg</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span class="z-constant"> 50000</span><span>,</span><span> tx_to</span><span>,</span><span> tx_value</span><span>,</span><span> tx_data</span><span>,</span><span class="z-support"> len</span><span>(</span><span>tx_data</span><span>)</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Get remaining gas payments back</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>call</span><span>(</span><span class="z-constant">20000</span><span>,</span><span class="z-constant"> MINER_CONTRACT</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span> [</span><span>msg</span><span>.</span><span>gas</span><span>]</span><span>,</span><span class="z-constant"> 32</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span></code></pre> <p>This can be thought of as a "forwarding contract". It accepts data from the "entry point" address 2**160 - 1 (an account that anyone can send transactions from), expecting that data to be in the format <code>[sig, nonce, to, value, gasprice, data]</code>. The forwarding contract verifies the signature, and if the signature is correct it sets up a payment to the miner and then sends a call to the desired address with the provided value and data.</p> <p>The benefits that this provides lie in the most interesting cases:</p> <ul> <li><strong>Multisig wallets</strong>: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees.</li> <li><strong>Ring signature mixers</strong>: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins.</li> <li><strong>Custom cryptography</strong>: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA.</li> <li><strong>Non-cryptographic modifications</strong>: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications.</li> </ul> <p>(2) and (3) introduce a feature similar to bitcoin's P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that's a basic functionality that exists in all blockchain protocols today.</p> <h1 id="miner-and-transaction-replaying-strategy">Miner and transaction replaying strategy</h1> <p>Note that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current).</p> <p>One simple strategy is to have a set of regexps that the to address of an account would be checked against, each regexp corresponding to a "standard account type" which is known to be "safe" (in the sense that if an account has that code, and a particular check involving the account balances, account storage and transaction data passes, then if the transaction is included in a block the miner will get paid), and mine and relay transactions that pass these checks.</p> <p>One example would be to check as follows:</p> <ol> <li>Check that the to address has code which is the compiled version of the Serpent code above, with <code>&lt;pubkey hash here&gt;</code> replaced with any public key hash.</li> <li>Check that the signature in the transaction data verifies with that key hash.</li> <li>Check that the gasprice in the transaction data is sufficiently high</li> <li>Check that the nonce in the state matches the nonce in the transaction data</li> <li>Check that there is enough ether in the account to pay for the fee</li> </ol> <p>If all five checks pass, relay and/or mine the transaction.</p> <p>A looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner's balance is appropriately higher after executing the transaction than before it.</p> <h1 id="copyright">Copyright</h1> <p>Copyright and related rights waived via CC0.</p> 2017-02-09T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic https://wg-eips.ritovision.com/141/ <h2 id="abstract">Abstract</h2> <p>An instruction is designated to remain as an invalid instruction.</p> <h2 id="motivation">Motivation</h2> <p>The invalid instruction can be used as a distinct reason to abort execution.</p> <h2 id="specification">Specification</h2> <p>The opcode <code>0xfe</code> is the <code>INVALID</code> instruction. It can be used to abort the execution (i.e. duplicates as an <code>ABORT</code> instruction).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This instruction was never used and therefore has no effect on past contracts.</p> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Alex Beregszaszihttps://github.com/axic Nikolai Mushegiannikolai@nexusdev.us https://wg-eips.ritovision.com/140/ <h2 id="simple-summary">Simple Summary</h2> <p>The <code>REVERT</code> instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.</p> <h2 id="abstract">Abstract</h2> <p>The <code>REVERT</code> instruction will stop execution, roll back all state changes done so far and provide a pointer to a memory section, which can be interpreted as an error code or message. While doing so, it will not consume all the remaining gas.</p> <h2 id="motivation">Motivation</h2> <p>Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting an EVM execution means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting an EVM execution.</p> <h2 id="specification">Specification</h2> <p>On blocks with <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code>, the <code>REVERT</code> instruction is introduced at <code>0xfd</code>. It expects two stack items, the top item is the <code>memory_offset</code> followed by <code>memory_length</code>. It does not produce any stack elements because it stops execution.</p> <p>The semantics of <code>REVERT</code> with respect to memory and memory cost are identical to those of <code>RETURN</code>. The sequence of bytes given by <code>memory_offset</code> and <code>memory_length</code> is called "error message" in the following.</p> <p>The effect of <code>REVERT</code> is that execution is aborted, considered as failed, and state changes are rolled back. The error message will be available to the caller in the returndata buffer and will also be copied to the output area, i.e. it is handled in the same way as the regular return data is handled.</p> <p>The cost of the <code>REVERT</code> instruction equals to that of the <code>RETURN</code> instruction, i.e. the rollback itself does not consume all gas, the contract only has to pay for memory.</p> <p>In case there is not enough gas left to cover the cost of <code>REVERT</code> or there is a stack underflow, the effect of the <code>REVERT</code> instruction will equal to that of a regular out of gas exception, i.e. it will consume all gas.</p> <p>In the same way as all other failures, the calling opcode returns <code>0</code> on the stack following a <code>REVERT</code> opcode in the callee.</p> <p>In case <code>REVERT</code> is used in the context of a <code>CREATE</code> or <code>CREATE2</code> call, no code is deployed, <code>0</code> is put on the stack and the error message is available in the returndata buffer.</p> <p>The content of the optionally provided memory section is not defined by this EIP, but is a candidate for another Informational EIP.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>This change has no effect on contracts created in the past unless they contain <code>0xfd</code> as an instruction.</p> <h2 id="test-cases">Test Cases</h2> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>6c726576657274656420646174616000557f726576657274206d657373616765000000000000000000000000000000000000600052600e6000fd</span></span></code></pre> <p>should:</p> <ul> <li>return <code>0x726576657274206d657373616765</code> as <code>REVERT</code> data,</li> <li>the storage at key <code>0x0</code> should be left as unset and</li> <li>use 20024 gas in total.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-06T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinvitalik@ethereum.org Christian Reitwiessnerchris@ethereum.org https://wg-eips.ritovision.com/197/ <h2 id="simple-summary">Simple Summary</h2> <p>Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.</p> <h2 id="abstract">Abstract</h2> <p>This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with <a href="https://wg-eips.ritovision.com/196/">EIP-196</a> to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).</p> <h2 id="motivation">Motivation</h2> <p>Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.</p> <p>Note that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork.</p> <p>Pairing functions can be used to perform a limited form of multiplicatively homomorphic operations, which are necessary for current zkSNARKs. This precompile can be used to run such computations within the block gas limit. This precompiled contract only specifies a certain check, and not an evaluation of a pairing function. The reason is that the codomain of a pairing function is a rather complex field which could provide encoding problems and all known uses of pairing function in zkSNARKs only require the specified check.</p> <h2 id="specification">Specification</h2> <p>For blocks where <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code>, add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below.</p> <p>Address: 0x8</p> <p>For a cyclic group <code>G</code> (written additively) of prime order <code>q</code> let <code>log_P: G -&gt; F_q</code> be the discrete logarithm on this group with respect to a generator <code>P</code>, i.e. <code>log_P(x)</code> is the smallest non-negative integer <code>n</code> such that <code>n * P = x</code>.</p> <p>The precompiled contract is defined as follows, where the two groups <code>G_1</code> and <code>G_2</code> are defined by their generators <code>P_1</code> and <code>P_2</code> below. Both generators have the same prime order <code>q</code>.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k</span></span> <span class="giallo-l"><span>Output: If the length of the input is incorrect or any of the inputs are not elements of</span></span> <span class="giallo-l"><span> the respective group or are not encoded correctly, the call fails.</span></span> <span class="giallo-l"><span> Otherwise, return one if</span></span> <span class="giallo-l"><span> log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0</span></span> <span class="giallo-l"><span> (in F_q) and zero else.</span></span></code></pre> <p>Note that <code>k</code> is determined from the length of the input. Following the section on the encoding below, <code>k</code> is the length of the input divided by <code>192</code>. If the input length is not a multiple of <code>192</code>, the call fails. Empty input is valid and results in returning one.</p> <p>In order to check that an input is an element of <code>G_1</code>, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For <code>G_2</code>, in addition to that, the order of the element has to be checked to be equal to the group order <code>q = 21888242871839275222246405745257275088548364400416034343698204186575808495617</code>.</p> <h3 id="definition-of-the-groups">Definition of the groups</h3> <p>The groups <code>G_1</code> and <code>G_2</code> are cyclic groups of prime order <code>q = 21888242871839275222246405745257275088548364400416034343698204186575808495617</code>.</p> <p>The group <code>G_1</code> is defined on the curve <code>Y^2 = X^3 + 3</code> over the field <code>F_p</code> with <code>p = 21888242871839275222246405745257275088696311157297823662689037894645226208583</code> with generator <code>P1 = (1, 2)</code>.</p> <p>The group <code>G_2</code> is defined on the curve <code>Y^2 = X^3 + 3/(i+9)</code> over a different field <code>F_p^2 = F_p[i] / (i^2 + 1)</code> (p is the same as above) with generator</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>P2 = (</span></span> <span class="giallo-l"><span> 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i +</span></span> <span class="giallo-l"><span> 10857046999023057135944570762232829481370756359578518086990519993285655852781,</span></span> <span class="giallo-l"><span> 4082367875863433681332203403145435568316851327593401208105741076214120093531 * i +</span></span> <span class="giallo-l"><span> 8495653923123431417604973247489272438418190587263600148770280649306958101930</span></span> <span class="giallo-l"><span>)</span></span></code></pre> <p>Note that <code>G_2</code> is the only group of order <code>q</code> of that elliptic curve over the field <code>F_p^2</code>. Any other generator of order <code>q</code> instead of <code>P2</code> would define the same <code>G_2</code>. However, the concrete value of <code>P2</code> is useful for skeptical readers who doubt the existence of a group of order <code>q</code>. They can be instructed to compare the concrete values of <code>q * P2</code> and <code>P2</code>.</p> <h3 id="encoding">Encoding</h3> <p>Elements of <code>F_p</code> are encoded as 32 byte big-endian numbers. An encoding value of <code>p</code> or larger is invalid.</p> <p>Elements <code>a * i + b</code> of <code>F_p^2</code> are encoded as two elements of <code>F_p</code>, <code>(a, b)</code>.</p> <p>Elliptic curve points are encoded as a Jacobian pair <code>(X, Y)</code> where the point at infinity is encoded as <code>(0, 0)</code>.</p> <p>Note that the number <code>k</code> is derived from the input length.</p> <p>The length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number.</p> <h3 id="gas-costs">Gas costs</h3> <p>The gas costs of the precompiled contract are <code>80 000 * k + 100 000</code>, where <code>k</code> is the number of points or, equivalently, the length of the input divided by 192.</p> <h2 id="rationale">Rationale</h2> <p>The specific curve <code>alt_bn128</code> was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.</p> <p>The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification; the gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation.</p> <p>A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).</p> <p>The encoding of field elements in <code>F_p^2</code> was chosen in this order to be in line with the big endian encoding of the elements themselves.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256.</p> <h2 id="test-cases">Test Cases</h2> <p>To be written.</p> <h2 id="implementation">Implementation</h2> <p>The precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the alt_bn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function <code>e: G_1 x G_2 -&gt; G_T</code> fulfills the following properties (<code>G_1</code> and <code>G_2</code> are written additively, <code>G_T</code> is written multiplicatively):</p> <p>(1) <code>e(m * P1, n * P2) = e(P1, P2)^(m * n)</code> (2) <code>e</code> is non-degenerate</p> <p>Now observe that</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q)</span></span></code></pre> <p>if and only if</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T)</span></span></code></pre> <p>Furthermore, the left hand side of this equation is equal to</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>e(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2)</span></span> <span class="giallo-l"><span>= e(a1, b1) * ... * e(ak, bk)</span></span></code></pre> <p>And thus, the precompiled contract can be implemented by verifying that <code>e(a1, b1) * ... * e(ak, bk) = 1</code></p> <p>Implementations are available here:</p> <ul> <li><a rel="external" href="https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp">libff</a> (C++)</li> <li><a rel="external" href="https://github.com/zcash/bn/blob/master/src/groups/mod.rs">bn</a> (Rust)</li> <li><a rel="external" href="https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_pairing.py">Python</a></li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-02-02T00:00:00+00:00 2026-02-11T14:49:27+00:00 Christian Reitwiessnerchris@ethereum.org https://wg-eips.ritovision.com/196/ <h2 id="simple-summary">Simple Summary</h2> <p>Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.</p> <h2 id="abstract">Abstract</h2> <p>This EIP suggests to add precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve. This can in turn be combined with <a href="https://wg-eips.ritovision.com/197/">EIP-197</a> to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).</p> <h2 id="motivation">Motivation</h2> <p>Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.</p> <p>Note that while fixing these parameters might look like limiting the use-cases for zkSNARKs, the primitives are so basic that they can be combined in ways that are flexible enough so that it should even be possible to allow future advances in zkSNARK research without the need for a further hard fork.</p> <h2 id="specification">Specification</h2> <p>If <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code>, add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "alt_bn128".</p> <p>Address of ADD: 0x6 Address for MUL: 0x7</p> <p>The curve is defined by:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Y^2 = X^3 + 3</span></span> <span class="giallo-l"><span>over the field F_p with</span></span> <span class="giallo-l"><span>p = 21888242871839275222246405745257275088696311157297823662689037894645226208583</span></span></code></pre><h3 id="encoding">Encoding</h3> <p>Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements <code>(x, y)</code>, where the point at infinity is encoded as <code>(0, 0)</code>.</p> <p>Tuples of objects are encoded as their concatenation.</p> <p>For both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the <code>CALLDATALOAD</code> opcode). If the input is longer than expected, surplus bytes at the end are ignored.</p> <p>The length of the returned data is always as specified (i.e. it is not "unpadded").</p> <h3 id="exact-semantics">Exact semantics</h3> <p>Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between <code>0</code> and <code>2**256-1</code>.</p> <h4 id="add">ADD</h4> <p>Input: two curve points <code>(x, y)</code>. Output: curve point <code>x + y</code>, where <code>+</code> is point addition on the elliptic curve <code>alt_bn128</code> specified above. Fails on invalid input and consumes all gas provided.</p> <h4 id="mul">MUL</h4> <p>Input: curve point and scalar <code>(x, s)</code>. Output: curve point <code>s * x</code>, where <code>*</code> is the scalar multiplication on the elliptic curve <code>alt_bn128</code> specified above. Fails on invalid input and consumes all gas.</p> <h3 id="gas-costs">Gas costs</h3> <ul> <li>Gas cost for <code>ECADD</code>: 500</li> <li>Gas cost for <code>ECMUL</code>: 40000</li> </ul> <h2 id="rationale">Rationale</h2> <p>The specific curve <code>alt_bn128</code> was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.</p> <p>The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve.</p> <p>A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256.</p> <h2 id="test-cases">Test Cases</h2> <p>Inputs to test:</p> <ul> <li>Curve points which would be valid if the numbers were taken mod p (should fail).</li> <li>Both contracts should succeed on empty input.</li> <li>Truncated input that results in a valid curve point.</li> <li>Points not on curve (but valid otherwise).</li> <li>Multiply point with scalar that lies between the order of the group and the field (should succeed).</li> <li>Multiply point with scalar that is larger than the field order (should succeed).</li> </ul> <h2 id="implementation">Implementation</h2> <p>Implementation of these primitives are available here:</p> <ul> <li><a rel="external" href="https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.cpp">libff</a> (C++)</li> <li><a rel="external" href="https://github.com/zcash/bn/blob/master/src/groups/mod.rs">bn</a> (Rust)</li> </ul> <p>In both codebases, a specific group on the curve alt_bn128 is used and is called G1.</p> <ul> <li><a rel="external" href="https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_curve.py">Python</a> - probably most self-contained and best readable.</li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2017-01-30T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/198/ <h1 id="parameters">Parameters</h1> <ul> <li><code>GQUADDIVISOR: 20</code></li> </ul> <h1 id="specification">Specification</h1> <p>At address 0x00......05, add a precompile that expects input in the following format:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>&lt;length_of_BASE&gt; &lt;length_of_EXPONENT&gt; &lt;length_of_MODULUS&gt; &lt;BASE&gt; &lt;EXPONENT&gt; &lt;MODULUS&gt;</span></span></code></pre> <p>Where every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes <code>floor(mult_complexity(max(length_of_MODULUS, length_of_BASE)) * max(ADJUSTED_EXPONENT_LENGTH, 1) / GQUADDIVISOR)</code> gas, and if there is enough gas, returns an output <code>(BASE**EXPONENT) % MODULUS</code> as a byte array with the same length as the modulus.</p> <p><code>ADJUSTED_EXPONENT_LENGTH</code> is defined as follows.</p> <ul> <li>If <code>length_of_EXPONENT &lt;= 32</code>, and all bits in <code>EXPONENT</code> are 0, return 0</li> <li>If <code>length_of_EXPONENT &lt;= 32</code>, then return the index of the highest bit in <code>EXPONENT</code> (eg. 1 -&gt; 0, 2 -&gt; 1, 3 -&gt; 1, 255 -&gt; 7, 256 -&gt; 8).</li> <li>If <code>length_of_EXPONENT &gt; 32</code>, then return <code>8 * (length_of_EXPONENT - 32)</code> plus the index of the highest bit in the first 32 bytes of <code>EXPONENT</code> (eg. if <code>EXPONENT = \x00\x00\x01\x00.....\x00</code>, with one hundred bytes, then the result is 8 * (100 - 32) + 253 = 797). If all of the first 32 bytes of <code>EXPONENT</code> are zero, return exactly <code>8 * (length_of_EXPONENT - 32)</code>.</li> </ul> <p><code>mult_complexity</code> is a function intended to approximate the difficulty of Karatsuba multiplication (used in all major bigint libraries) and is defined as follows.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>def mult_complexity(x):</span></span> <span class="giallo-l"><span> if x &lt;= 64: return x ** 2</span></span> <span class="giallo-l"><span> elif x &lt;= 1024: return x ** 2 // 4 + 96 * x - 3072</span></span> <span class="giallo-l"><span> else: return x ** 2 // 16 + 480 * x - 199680</span></span></code></pre> <p>For example, the input data:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>03</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f</span></span></code></pre> <p>Represents the exponent <code>3**(2**256 - 2**32 - 978) % (2**256 - 2**32 - 977)</code>. By Fermat's little theorem, this equals 1, so the result is:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000001</span></span></code></pre> <p>Returned as 32 bytes because the modulus length was 32 bytes. The <code>ADJUSTED_EXPONENT_LENGTH</code> would be 255, and the gas cost would be <code>mult_complexity(32) * 255 / 20 = 13056</code> gas (note that this is ~8 times the cost of using the EXP opcode to compute a 32-byte exponent). A 4096-bit RSA exponentiation would cost <code>mult_complexity(512) * 4095 / 100 = 22853376</code> gas in the worst case, though RSA verification in practice usually uses an exponent of 3 or 65537, which would reduce the gas consumption to 5580 or 89292, respectively.</p> <p>This input data:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f</span></span></code></pre> <p>Would be parsed as a base of 0, exponent of <code>2**256 - 2**32 - 978</code> and modulus of <code>2**256 - 2**32 - 977</code>, and so would return 0. Notice how if the length_of_BASE is 0, then it does not interpret <em>any</em> data as the base, instead immediately interpreting the next 32 bytes as EXPONENT.</p> <p>This input data:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe</span></span> <span class="giallo-l"><span>fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd</span></span></code></pre> <p>Would parse a base length of 0, an exponent length of 32, and a modulus length of <code>2**256 - 1</code>, where the base is empty, the exponent is <code>2**256 - 2</code> and the modulus is <code>(2**256 - 3) * 256**(2**256 - 33)</code> (yes, that's a really big number). It would then immediately fail, as it's not possible to provide enough gas to make that computation.</p> <p>This input data:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000002</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>03</span></span> <span class="giallo-l"><span>ffff</span></span> <span class="giallo-l"><span>8000000000000000000000000000000000000000000000000000000000000000</span></span> <span class="giallo-l"><span>07</span></span></code></pre> <p>Would parse as a base of 3, an exponent of 65535, and a modulus of <code>2**255</code>, and it would ignore the remaining 0x07 byte.</p> <p>This input data:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000001</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000002</span></span> <span class="giallo-l"><span>0000000000000000000000000000000000000000000000000000000000000020</span></span> <span class="giallo-l"><span>03</span></span> <span class="giallo-l"><span>ffff</span></span> <span class="giallo-l"><span>80</span></span></code></pre> <p>Would also parse as a base of 3, an exponent of 65535 and a modulus of <code>2**255</code>, as it attempts to grab 32 bytes for the modulus starting from 0x80 - but there is no further data, so it right-pads it with 31 zero bytes.</p> <h1 id="rationale">Rationale</h1> <p>This allows for efficient RSA verification inside of the EVM, as well as other forms of number theory-based cryptography. Note that adding precompiles for addition and subtraction is not required, as the in-EVM algorithm is efficient enough, and multiplication can be done through this precompile via <code>a * b = ((a + b)**2 - (a - b)**2) / 4</code>.</p> <p>The bit-based exponent calculation is done specifically to fairly charge for the often-used exponents of 2 (for multiplication) and 3 and 65537 (for RSA verification).</p> <h1 id="copyright">Copyright</h1> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2016-12-10T00:00:00+00:00 2026-02-11T14:49:27+00:00 Greg Colvingreg@colvin.org Brooklyn Zelenkahttps://github.com/expede Paweł Bylicahttps://github.com/chfast Christian Reitwiessnerhttps://github.com/chriseth https://wg-eips.ritovision.com/615/ <h2 id="simple-summary">Simple Summary</h2> <p>In the 21st century, on a blockchain circulating billions of ETH, formal specification and verification are an essential tool against loss. Yet the design of the EVM makes this unnecessarily difficult. Further, the design of the EVM makes near-linear-time compilation to machine code difficult. We propose to move forward with proposals to resolve these problems by tightening EVM security guarantees and reducing barriers to performance.</p> <h2 id="abstract">Abstract</h2> <p>EVM code is currently difficult to statically analyze, hobbling critical tools for preventing the many expensive bugs our blockchain has experienced. Further, none of the current implementations of the Ethereum Virtual Machine—including the compilers—are sufficiently performant to reduce the need for precompiles and otherwise meet the network's long-term demands. This proposal identifies dynamic jumps as a major reason for these issues, and proposes changes to the EVM specification to address the problem, making further efforts towards a safer and more performant the EVM possible.</p> <p>We also propose to validate—in near-linear time—that EVM contracts correctly use subroutines, avoid misuse of the stack, and meet other safety conditions <em>before</em> placing them on the blockchain. Validated code precludes most runtime exceptions and the need to test for them. And well-behaved control flow and use of the stack makes life easier for interpreters, compilers, formal analysis, and other tools.</p> <h2 id="motivation">Motivation</h2> <p>Currently the EVM supports only dynamic jumps, where the address to jump to is an argument on the stack. Worse, the EVM fails to provide ordinary, alternative control flow facilities like subroutines and switches provided by Wasm and most CPUs. So dynamic jumps cannot be avoided, yet they obscure the structure of the code and thus mostly inhibit control- and data-flow analysis. This puts the quality and speed of optimized compilation fundamentally at odds. Further, since many jumps can potentially be to any jump destination in the code, the number of possible paths through the code can go up as the product of the number of jumps by the number of destinations, as does the time complexity of static analysis. Many of these cases are undecidable at deployment time, further inhibiting static and formal analyses.</p> <p>However, given Ethereum's security requirements, <strong>near-linear</strong> <strong><code>n log n</code></strong> <strong>time complexity</strong> is essential. Otherwise, Contracts can be crafted or discovered with quadratic complexity to use as denial of service attack vectors against validations and optimizations.</p> <p>But absent dynamic jumps code can be statically analyzed in linear time. That allows for <em>linear time validation</em>. It also allows for code generation and such optimizations as can be done in <code>log n</code> time to comprise an <em><code>n log n</code></em> <em>time compiler</em>.</p> <p>And absent dynamic jumps, and with proper subroutines the EVM is a better target for code generation from other languages, including</p> <ul> <li>Solidity</li> <li>Vyper</li> <li>LLVM IR <ul> <li>front ends include C, C++, Common Lisp, D, Fortran, Haskell, Java, Javascript, Kotlin, Lua, Objective-C, Pony, Pure, Python, Ruby, Rust, Scala, Scheme, and Swift</li> </ul> </li> </ul> <p>The result is that all of the following validations and optimizations can be done at deployment time with near-linear <code>(n log n)</code> time complexity.</p> <ul> <li>The absence of most exceptional halting states can be validated.</li> <li>The maximum use of resources can be sometimes be calculated.</li> <li>Bytecode can be compiled to machine code in near-linear time.</li> <li>Compilation can more effectively optimize use of smaller registers.</li> <li>Compilation can more effectively optimize injection of gas metering.</li> </ul> <h2 id="specification">Specification</h2> <h3 id="dependencies">Dependencies</h3> <blockquote> <p><strong><a href="https://wg-eips.ritovision.com/1702/">EIP-1702</a>. Generalized Account Versioning Scheme.</strong> This proposal needs a versioning scheme to allow for its bytecode (and eventually eWasm bytecode) to be deployed with existing bytecode on the same blockchain.</p> </blockquote> <h3 id="proposal">Proposal</h3> <p>We propose to deprecate two existing instructions—<code>JUMP</code> and <code>JUMPI</code>—and propose new instructions to support their legitimate uses. In particular, it must remain possible to compile Solidity and Vyper code to EVM bytecode, with no significant loss of performance or increase in gas price.</p> <p>Especially important is efficient translation to and from <a rel="external" href="https://github.com/ewasm/design">eWasm</a> and to machine code. To that end we maintain a close correspondence between <a rel="external" href="https://webassembly.github.io/spec/core/_download/WebAssembly.pdf">Wasm</a>, <a rel="external" href="https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf">x86</a>, <a rel="external" href="https://static.docs.arm.com/100076/0100/arm_instruction_set_reference_guide_100076_0100_00_en.pdf">ARM</a> and proposed EVM instructions.</p> <table><thead><tr><th>EIP-615</th><th>Wasm</th><th>x86</th><th>ARM</th></tr></thead><tbody> <tr><td>JUMPTO</td><td>br</td><td>JMP</td><td>B</td></tr> <tr><td>JUMPIF</td><td>br_if</td><td>JE</td><td>BEQ</td></tr> <tr><td>JUMPV</td><td>br_table</td><td>JMP</td><td>TBH</td></tr> <tr><td>JUMPSUB</td><td>call</td><td>CALL</td><td>BL</td></tr> <tr><td>JUMPSUBV</td><td>call_indirect</td><td>CALL</td><td>BL</td></tr> <tr><td>RETURN</td><td>return</td><td>RET</td><td>RET</td></tr> <tr><td>GETLOCAL</td><td>local.get</td><td>POP</td><td>POP</td></tr> <tr><td>PUTLOCAL</td><td>local.put</td><td>PUSH</td><td>PUSH</td></tr> <tr><td>BEGINSUB</td><td>func</td><td></td><td></td></tr> <tr><td>BEGINDATA</td><td>tables</td><td></td><td></td></tr> </tbody></table> <h4 id="preliminaries">Preliminaries</h4> <p>These forms</p> <blockquote> <p><em><code>INSTRUCTION</code></em></p> <p><em><code>INSTRUCTION x</code></em></p> <p><em><code>INSTRUCTION x, y</code></em></p> </blockquote> <p>name an <em><code>INSTRUCTION</code></em> with no, one and two arguments, respectively. An instruction is represented in the bytecode as a single-byte opcode. Any arguments are laid out as immediate data bytes following the opcode inline, interpreted as fixed length, MSB-first, two's-complement, two-byte positive integers. (Negative values are reserved for extensions.)</p> <h4 id="branches-and-subroutines">Branches and Subroutines</h4> <p>The two most important uses of <code>JUMP</code> and <code>JUMPI</code> are static jumps and return jumps. Conditional and unconditional static jumps are the mainstay of control flow. Return jumps are implemented as a dynamic jump to a return address pushed on the stack. With the combination of a static jump and a dynamic return jump you can—and Solidity does—implement subroutines. The problem is that static analysis cannot tell the one place the return jump is going, so it must analyze every possibility (a heavy analysis).</p> <p>Static jumps are provided by</p> <blockquote> <p><code>JUMPTO jump_target</code></p> <p><code>JUMPIF jump_target</code></p> <p>which are the same as <code>JUMP</code> and <code>JUMPI</code> except that they jump to an immediate <code>jump_target</code> rather than an address on the stack.</p> </blockquote> <p>To support subroutines, <code>BEGINSUB</code>, <code>JUMPSUB</code>, and <code>RETURNSUB</code> are provided. Brief descriptions follow, and full semantics are given below.</p> <blockquote> <p><code>BEGINSUB n_args, n_results</code></p> <p>marks the <strong>single</strong> entry to a subroutine. <code>n_args</code> items are taken off of the stack at entry to, and <code>n_results</code> items are placed on the stack at return from the subroutine. The subroutine ends at the next <code>BEGINSUB</code> instruction (or <code>BEGINDATA</code>, below) or at the end of the bytecode.</p> </blockquote> <blockquote> <p><code>JUMPSUB jump_target</code></p> <p>jumps to an immediate subroutine address.</p> </blockquote> <blockquote> <p><code>RETURNSUB</code></p> <p>returns from the current subroutine to the instruction following the JUMPSUB that entered it.</p> </blockquote> <h4 id="switches-callbacks-and-virtual-functions">Switches, Callbacks, and Virtual Functions</h4> <p>Dynamic jumps are also used for <code>O(1)</code> indirection: an address to jump to is selected to push on the stack and be jumped to. So we also propose two more instructions to provide for constrained indirection. We support these with vectors of <code>JUMPDEST</code> or <code>BEGINSUB</code> offsets stored inline, which can be selected with an index on the stack. That constrains validation to a specified subset of all possible destinations. The danger of quadratic blow up is avoided because it takes as much space to store the jump vectors as it does to code the worst case exploit.</p> <p>Dynamic jumps to a <code>JUMPDEST</code> are used to implement <code>O(1)</code> jumptables, which are useful for dense switch statements. Wasm and most CPUs provide similar instructions.</p> <blockquote> <p><code>JUMPV n, jump_targets</code></p> <p>jumps to one of a vector of <code>n</code> <code>JUMPDEST</code> offsets via a zero-based index on the stack. The vector is stored inline at the <code>jump_targets</code> offset after the BEGINDATA bytecode as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to <code>n - 1</code> the last (default) offset is used.</p> </blockquote> <p>Dynamic jumps to a <code>BEGINSUB</code> are used to implement <code>O(1)</code> virtual functions and callbacks, which take at most two pointer dereferences on most CPUs. Wasm provides a similar instruction.</p> <blockquote> <p><code>JUMPSUBV n, jump_targets</code></p> <p>jumps to one of a vector of <code>n</code> <code>BEGINSUB</code> offsets via a zero-based index on the stack. The vector is stored inline at the <code>jump_targets</code> offset after the DATA bytecode, as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to <code>n - 1</code> the last (default) offset is used.</p> </blockquote> <h4 id="variable-access">Variable Access</h4> <p>These operations provide convenient access to subroutine parameters and local variables at fixed stack offsets within a subroutine. Otherwise only sixteen variables can be directly addressed.</p> <blockquote> <p><code>PUTLOCAL n</code></p> <p>Pops the stack to the local variable <code>n</code>.</p> </blockquote> <blockquote> <p><code>GETLOCAL n</code></p> <p>Pushes the local variable <code>n</code> onto the stack.</p> </blockquote> <p>Local variable <code>n</code> is the nth stack item below the frame pointer, <code>FP[-n]</code>, as defined below.</p> <h4 id="data">Data</h4> <p>There needs to be a way to place unreachable data into the bytecode that will be skipped over and not validated. Indirect jump vectors will not be valid code. Initialization code must create runtime code from data that might not be valid code. And unreachable data might prove useful to programs for other purposes.</p> <blockquote> <p><code>BEGINDATA</code></p> <p>specifies that all of the following bytes to the end of the bytecode are data, and not reachable code.</p> </blockquote> <h4 id="structure">Structure</h4> <p>Valid EIP-615 EVM bytecode begins with a valid header. This is the magic number ‘\0evm’ followed by the semantic versioning number '\1\5\0'. (For Wasm the header is '\0asm\1').</p> <p>Following the header is the BEGINSUB opcode for the <em>main</em> routine. It takes no arguments and returns no values. Other subroutines may follow the <em>main</em> routine, and an optional BEGINDATA opcode may mark the start of a data section.</p> <h3 id="semantics">Semantics</h3> <p>Jumps to and returns from subroutines are described here in terms of</p> <ul> <li>The EVM data stack, (as defined in the <a rel="external" href="https://ethereum.github.io/yellowpaper/paper.pdf">Yellow Paper</a>) usually just called “the stack.”</li> <li>A return stack of <code>JUMPSUB</code> and <code>JUMPSUBV</code> offsets.</li> <li>A frame stack of frame pointers.</li> </ul> <p>We will adopt the following conventions to describe the machine state:</p> <ul> <li>The <em>program counter</em> <code>PC</code> is (as usual) the byte offset of the currently executing instruction.</li> <li>The <em>stack pointer</em> <code>SP</code> corresponds to the <a rel="external" href="https://ethereum.github.io/yellowpaper/paper.pdf">Yellow Paper</a>'s substate <code>s</code> of the machine state. <ul> <li><code>SP[0]</code> is where a new item is can be pushed on the stack.</li> <li><code>SP[1]</code> is the first item on the stack, which can be popped off the stack.</li> <li>The stack grows towards lower addresses.</li> </ul> </li> <li>The <em>frame pointer</em> <code>FP</code> is set to <code>SP + n_args</code> at entry to the currently executing subroutine. <ul> <li>The <em>stack items</em> between the frame pointer and the current stack pointer are called the <em>frame</em>.</li> <li>The current number of items in the frame, <code>FP - SP</code>, is the <em>frame size</em>.</li> </ul> </li> </ul> <blockquote> <p><strong>Note</strong>: Defining the frame pointer so as to include the arguments is unconventional, but better fits our stack semantics and simplifies the remainder of the proposal.</p> </blockquote> <p>The frame pointer and return stacks are internal to the subroutine mechanism, and not directly accessible to the program. This is necessary to prevent the program from modifying its own state in ways that could be invalid.</p> <p>Execution of EVM bytecode begins with the <em>main</em> routine with no arguments, <code>SP</code> and <code>FP</code> set to 0, and with one value on the return stack—<code>code_size - 1</code>. (Executing the virtual byte of 0 after this offset causes an EVM to stop. Thus executing a <code>RETURNSUB</code> with no prior <code>JUMPSUB</code> or <code>JUMBSUBV</code>—that is, in the <em>main</em> routine—executes a <code>STOP</code>.)</p> <p>Execution of a subroutine begins with <code>JUMPSUB</code> or <code>JUMPSUBV</code>, which</p> <ul> <li>pushes <code>PC</code> on the return stack,</li> <li>pushes <code>FP</code> on the frame stack <ul> <li>thus suspending execution of the current subroutine,</li> </ul> </li> <li>sets <code>FP</code> to <code>SP + n_args</code>, and</li> <li>sets <code>PC</code> to the specified <code>BEGINSUB</code> address <ul> <li>thus beginning execution of the new subroutine.</li> </ul> </li> </ul> <p>Execution of a subroutine is suspended during and resumed after execution of nested subroutines, and ends upon encountering a <code>RETURNSUB</code>, which</p> <ul> <li>sets <code>FP</code> to the top of the virtual frame stack and pops the stack,</li> <li>sets <code>SP</code> to <code>FP + n_results</code>,</li> <li>sets <code>PC</code> to top of the return stack and pops the stack, and</li> <li>advances <code>PC</code> to the next instruction</li> </ul> <p>thus resuming execution of the enclosing subroutine or <em>main</em> routine. A <code>STOP</code> or <code>RETURN</code> also ends the execution of a subroutine.</p> <p>For example, starting from this stack,</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>_________________</span></span> <span class="giallo-l"><span> | locals 20 &lt;- FP</span></span> <span class="giallo-l"><span>frame | 21</span></span> <span class="giallo-l"><span>______|___________ 22</span></span> <span class="giallo-l"><span> &lt;- SP</span></span></code></pre> <p>and after pushing two arguments and branching with <code>JUMPSUB</code> to a <code>BEGINSUB 2, 3</code></p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 10</span></span> <span class="giallo-l"><span>PUSH 11</span></span> <span class="giallo-l"><span>JUMPSUB beginsub</span></span></code></pre> <p>and initializing three local variables</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>PUSH 99</span></span> <span class="giallo-l"><span>PUSH 98</span></span> <span class="giallo-l"><span>PUSH 97</span></span></code></pre> <p>the stack looks like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 20</span></span> <span class="giallo-l"><span> 21</span></span> <span class="giallo-l"><span>__________________ 22</span></span> <span class="giallo-l"><span> | arguments 10 &lt;- FP</span></span> <span class="giallo-l"><span>frame |___________ 11</span></span> <span class="giallo-l"><span> | locals 99</span></span> <span class="giallo-l"><span> | 98</span></span> <span class="giallo-l"><span>______|___________ 97</span></span> <span class="giallo-l"><span> &lt;- SP</span></span></code></pre> <p>After some amount of computation the stack could look like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> 20</span></span> <span class="giallo-l"><span> 21</span></span> <span class="giallo-l"><span>__________________ 22</span></span> <span class="giallo-l"><span> | returns 44 &lt;- FP</span></span> <span class="giallo-l"><span> | 43</span></span> <span class="giallo-l"><span>frame |___________ 42</span></span> <span class="giallo-l"><span> | locals 13</span></span> <span class="giallo-l"><span>______|___________ 14</span></span> <span class="giallo-l"><span> &lt;- SP</span></span></code></pre> <p>and after <code>RETURNSUB</code> would look like this</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>_________________</span></span> <span class="giallo-l"><span> | locals 20 &lt;- FP</span></span> <span class="giallo-l"><span> | 21</span></span> <span class="giallo-l"><span>frame |___________ 22</span></span> <span class="giallo-l"><span> | returns 44</span></span> <span class="giallo-l"><span> | 43</span></span> <span class="giallo-l"><span>______|___________ 42</span></span> <span class="giallo-l"><span> &lt;- SP</span></span></code></pre><h3 id="validity">Validity</h3> <p>We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state, but we must validate code in linear time. So our validation does not consider the code’s data and computations, only its control flow and stack use. This means we will reject programs with invalid code paths, even if those paths are not reachable. Most conditions can be validated, and will not need to be checked at runtime; the exceptions are sufficient gas and sufficient stack. As such, static analysis may yield false negatives belonging to well-understood classes of code requiring runtime checks. Aside from those cases, we can validate large classes at validation time and with linear complexity.</p> <p><em>Execution</em> is as defined in the <a rel="external" href="https://ethereum.github.io/yellowpaper/paper.pdf">Yellow Paper</a>—a sequence of changes in the EVM state. The conditions on valid code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines five such states.</p> <blockquote> <p><strong>1</strong> Insufficient gas</p> </blockquote> <blockquote> <p><strong>2</strong> More than 1024 stack items</p> </blockquote> <blockquote> <p><strong>3</strong> Insufficient stack items</p> </blockquote> <blockquote> <p><strong>4</strong> Invalid jump destination</p> </blockquote> <blockquote> <p><strong>5</strong> Invalid instruction</p> </blockquote> <p>We propose to expand and extend the Yellow Paper conditions to handle the new instructions we propose.</p> <p>To handle the return stack we expand the conditions on stack size:</p> <blockquote> <p><strong>2a</strong> The size of the data stack does not exceed 1024.</p> </blockquote> <blockquote> <p><strong>2b</strong> The size of the return stack does not exceed 1024.</p> </blockquote> <p>Given our more detailed description of the data stack we restate condition 3—stack underflow—as</p> <blockquote> <p><strong>3</strong> <code>SP</code> must be less than or equal to <code>FP</code></p> </blockquote> <p>Since the various <code>DUP</code> and <code>SWAP</code> operations—as well as <code>PUTLOCAL</code> and <code>GETLOCAL</code>—are defined as taking items off the stack and putting them back on, this prevents them from accessing data below the frame pointer, since taking too many items off of the stack would mean that <code>SP</code> is less than <code>FP</code>.</p> <p>To handle the new jump instructions and subroutine boundaries, we expand the conditions on jumps and jump destinations.</p> <blockquote> <p><strong>4a</strong> <code>JUMPTO</code>, <code>JUMPIF</code>, and <code>JUMPV</code> address only <code>JUMPDEST</code> instructions.</p> </blockquote> <blockquote> <p><strong>4b</strong> <code>JUMPSUB</code> and <code>JUMPSUBV</code> address only <code>BEGINSUB</code> instructions.</p> </blockquote> <blockquote> <p><strong>4c</strong> <code>JUMP</code> instructions do not address instructions outside of the subroutine they occur in.</p> </blockquote> <p>We have two new conditions on execution to ensure consistent use of the stack by subroutines:</p> <blockquote> <p><strong>6</strong> For <code>JUMPSUB</code> and <code>JUMPSUBV</code> the frame size is at least the <code>n_args</code> of the <code>BEGINSUB</code>(s) to jump to.</p> </blockquote> <blockquote> <p><strong>7</strong> For <code>RETURNSUB</code> the frame size is equal to the <code>n_results</code> of the enclosing <code>BEGINSUB</code>.</p> </blockquote> <p>Finally, we have one condition that prevents pathological uses of the stack:</p> <blockquote> <p><strong>8</strong> For every instruction in the code the frame size is constant.</p> </blockquote> <p>In practice, we must test at runtime for conditions 1 and 2—sufficient gas and sufficient stack. We don’t know how much gas there will be, we don’t know how deep a recursion may go, and analysis of stack depth even for non-recursive programs is nontrivial.</p> <p>All of the remaining conditions we validate statically.</p> <h4 id="costs-codes">Costs &amp; Codes</h4> <p>All of the instructions are <code>O(1)</code> with a small constant, requiring just a few machine operations each, whereas a <code>JUMP</code> or <code>JUMPI</code> typically does an <code>O(log n)</code> binary search of an array of <code>JUMPDEST</code> offsets before every jump. With the cost of <code>JUMPI</code> being <em>high</em> and the cost of <code>JUMP</code> being <em>mid</em>, we suggest the cost of <code>JUMPV</code> and <code>JUMPSUBV</code> should be <em>mid</em>, <code>JUMPSUB</code> and <code>JUMPIF</code> should be <em>low</em>, and<code>JUMPTO</code> and the rest should be <em>verylow</em>. Measurement will tell.</p> <p>We suggest the following opcodes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0xb0 JUMPTO</span></span> <span class="giallo-l"><span>0xb1 JUMPIF</span></span> <span class="giallo-l"><span>0xb2 JUMPV</span></span> <span class="giallo-l"><span>0xb3 JUMPSUB</span></span> <span class="giallo-l"><span>0xb4 JUMPSUBV</span></span> <span class="giallo-l"><span>0xb5 BEGINSUB</span></span> <span class="giallo-l"><span>0xb6 BEGINDATA</span></span> <span class="giallo-l"><span>0xb7 RETURNSUB</span></span> <span class="giallo-l"><span>0xb8 PUTLOCAL</span></span> <span class="giallo-l"><span>0xb9 GETLOCAL</span></span></code></pre><h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>These changes would need to be implemented in phases at decent intervals:</p> <blockquote> <p><strong>1.</strong> If this EIP is accepted, invalid code should be deprecated. Tools should stop generating invalid code, users should stop writing it, and clients should warn about loading it.</p> </blockquote> <blockquote> <p><strong>2.</strong> A later hard fork would require clients to place only valid code on the block chain. Note that despite the fork old EVM code will still need to be supported indefinitely; older contracts will continue to run, and to create new contracts.</p> </blockquote> <p>If desired, the period of deprecation can be extended indefinitely by continuing to accept code not versioned as new—but without validation. That is, by delaying or canceling phase 2.</p> <p>Regardless, we will need a versioning scheme like <a href="https://wg-eips.ritovision.com/1702/">EIP-1702</a> to allow current code and EIP-615 code to coexist on the same blockchain.</p> <h2 id="rationale">Rationale</h2> <p>This design was highly constrained by the existing EVM semantics, the requirement for eWasm compatibility, and the security demands of the Ethereum environment. It was also informed by the lead author's previous work implementing Java and Scheme interpreters. As such there was very little room for alternative designs.</p> <p>As described above, the approach was simply to deprecate the problematic dynamic jumps, then ask what opcodes were necessary to provide for the features they supported. These needed to include those provided by eWasm, which themselves were modeled after typical hardware. The only real innovation was to move the frame pointer and the return pointer to their own stacks, so as to prevent any possibility of overwriting them. (Although Forth also uses a return stack.) This allowed for treating subroutine arguments as local variables, and facilitated the return of multiple values.</p> <h2 id="implementation">Implementation</h2> <p>Implementation of this proposal need not be difficult. At the least, interpreters can simply be extended with the new opcodes and run unchanged otherwise. The new opcodes require only stacks for the frame pointers and return offsets and the few pushes, pops, and assignments described above. The bulk of the effort is the validator, which in most languages can almost be transcribed from the pseudocode above.</p> <p>A lightly tested C++ reference implementation is available in <a rel="external" href="https://github.com/gcolvin/aleth/tree/master/libaleth-interpreter">Greg Colvin's Aleth fork.</a> This version required circa 110 lines of new interpreter code and a well-commented, 178-line validator.</p> <h2 id="appendix-a">Appendix A</h2> <h3 id="validation">Validation</h3> <p>Validation comprises two tasks:</p> <ul> <li>Check that jump destinations are correct and instructions valid.</li> <li>Check that subroutines satisfy the conditions on control flow and stack use.</li> </ul> <p>We sketch out these two validation functions in pseudo-C below. To simplify the presentation only the five primitives are handled (<code>JUMPV</code> and <code>JUMPSUBV</code> would just add more complexity to loop over their vectors), we assume helper functions for extracting instruction arguments from immediate data and managing the stack pointer and program counter, and some optimizations are forgone.</p> <h4 id="validating-jumps">Validating Jumps</h4> <p>Validating that jumps are to valid addresses takes two sequential passes over the bytecode—one to build sets of jump destinations and subroutine entry points, another to check that addresses jumped to are in the appropriate sets.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> bytecode[code_size] // contains EVM bytecode to validate</span></span> <span class="giallo-l"><span> is_sub[code_size] // is there a BEGINSUB at PC?</span></span> <span class="giallo-l"><span> is_dest[code_size] // is there a JUMPDEST at PC?</span></span> <span class="giallo-l"><span> sub_for_pc[code_size] // which BEGINSUB is PC in?</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> bool validate_jumps(PC)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> current_sub = PC</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // build sets of BEGINSUBs and JUMPDESTs</span></span> <span class="giallo-l"><span> for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC))</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> if instruction is invalid</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> if instruction is BEGINDATA</span></span> <span class="giallo-l"><span> break;</span></span> <span class="giallo-l"><span> if instruction is BEGINSUB</span></span> <span class="giallo-l"><span> is_sub[PC] = true</span></span> <span class="giallo-l"><span> current_sub = PC</span></span> <span class="giallo-l"><span> sub_for_pc[PC] = current_sub</span></span> <span class="giallo-l"><span> if instruction is JUMPDEST</span></span> <span class="giallo-l"><span> is_dest[PC] = true</span></span> <span class="giallo-l"><span> sub_for_pc[PC] = current_sub</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check that targets are in subroutine</span></span> <span class="giallo-l"><span> for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC))</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> if instruction is BEGINDATA</span></span> <span class="giallo-l"><span> break;</span></span> <span class="giallo-l"><span> if instruction is BEGINSUB</span></span> <span class="giallo-l"><span> current_sub = PC</span></span> <span class="giallo-l"><span> if instruction is JUMPSUB</span></span> <span class="giallo-l"><span> if is_sub[jump_target(PC)] is false</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> if instruction is JUMPTO or JUMPIF</span></span> <span class="giallo-l"><span> if is_dest[jump_target(PC)] is false</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> if sub_for_pc[PC] is not current_sub</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"><span> }</span></span></code></pre> <p>Note that code like this is already run by EVMs to check dynamic jumps, including building the jump destination set every time a contract is run, and doing a lookup in the jump destination set before every jump.</p> <h4 id="subroutine-validation">Subroutine Validation</h4> <p>This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertices and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is <code>O(|E|+|V|)</code>: The sum of the number of edges and number of vertices in the graph.</p> <p>The basic approach is to call <code>validate_subroutine(i, 0, 0)</code>, for <code>i</code> equal to the first instruction in the EVM code through each <code>BEGINDATA</code> offset. <code>validate_subroutine()</code> traverses instructions sequentially, recursing when <code>JUMP</code> and <code>JUMPI</code> instructions are encountered. When a destination is reached that has been visited before it returns, thus breaking cycles. It returns true if the subroutine is valid, false otherwise.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> bytecode[code_size] // contains EVM bytecode to validate</span></span> <span class="giallo-l"><span> frame_size[code_size ] // is filled with -1</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // we validate each subroutine individually, as if at top level</span></span> <span class="giallo-l"><span> // * PC is the offset in the code to start validating at</span></span> <span class="giallo-l"><span> // * return_pc is the top PC on return stack that RETURNSUB returns to</span></span> <span class="giallo-l"><span> // * at top level FP = SP = 0 is both the frame size and the stack size</span></span> <span class="giallo-l"><span> // * as items are pushed SP get more negative, so the stack size is -SP</span></span> <span class="giallo-l"><span> validate_subroutine(PC, return_pc, SP)</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> // traverse code sequentially, recurse for jumps</span></span> <span class="giallo-l"><span> while true</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> instruction = bytecode[PC]</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // if frame size set we have been here before</span></span> <span class="giallo-l"><span> if frame_size[PC] &gt;= 0</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> // check for constant frame size</span></span> <span class="giallo-l"><span> if instruction is JUMPDEST</span></span> <span class="giallo-l"><span> if -SP != frame_size[PC]</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // return to break cycle</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> frame_size[PC] = -SP</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // effect of instruction on stack</span></span> <span class="giallo-l"><span> n_removed = removed_items(instructions)</span></span> <span class="giallo-l"><span> n_added = added_items(instruction)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check for stack underflow</span></span> <span class="giallo-l"><span> if -SP &lt; n_removed</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // net effect of removing and adding stack items</span></span> <span class="giallo-l"><span> SP += n_removed</span></span> <span class="giallo-l"><span> SP -= n_added</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check for stack overflow</span></span> <span class="giallo-l"><span> if -SP &gt; 1024</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if instruction is STOP, RETURN, or SUICIDE</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // violates single entry</span></span> <span class="giallo-l"><span> if instruction is BEGINSUB</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // return to top or from recursion to JUMPSUB</span></span> <span class="giallo-l"><span> if instruction is RETURNSUB</span></span> <span class="giallo-l"><span> return true;;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> if instruction is JUMPSUB</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> // check for enough arguments</span></span> <span class="giallo-l"><span> sub_pc = jump_target(PC)</span></span> <span class="giallo-l"><span> if -SP &lt; n_args(sub_pc)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // reset PC to destination of jump</span></span> <span class="giallo-l"><span> if instruction is JUMPTO</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> PC = jump_target(PC)</span></span> <span class="giallo-l"><span> continue</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // recurse to jump to code to validate</span></span> <span class="giallo-l"><span> if instruction is JUMPIF</span></span> <span class="giallo-l"><span> {</span></span> <span class="giallo-l"><span> if not validate_subroutine(jump_target(PC), return_pc, SP)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // advance PC according to instruction</span></span> <span class="giallo-l"><span> PC = advance_pc(PC)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> // check for right number of results</span></span> <span class="giallo-l"><span> if (-SP != n_results(return_pc)</span></span> <span class="giallo-l"><span> return false</span></span> <span class="giallo-l"><span> return true</span></span> <span class="giallo-l"><span> }</span></span></code></pre><h2 id="appendix-b">Appendix B</h2> <h3 id="evm-analysis">EVM Analysis</h3> <p>There is a large and growing ecosystem of researchers, authors, teachers, auditors, and analytic tools--providing software and services focused on the correctness and security of EVM code. A small sample is given here.</p> <h4 id="some-tools">Some Tools</h4> <ul> <li><a rel="external" href="https://contract-library.com/">Contract Library</a></li> <li><a rel="external" href="https://github.com/ethereum/ethereumj">EthereumJ</a></li> <li><a rel="external" href="https://github.com/exthereum/blockchain">Exthereum</a></li> <li><a rel="external" href="https://github.com/ether-camp/ethereum-harmony">Harmony</a></li> <li><a rel="external" href="https://www.pnfsoftware.com/blog/ethereum-smart-contract-decompiler/">JEB</a></li> <li><a rel="external" href="https://github.com/ConsenSys/mythril">Mythril</a></li> <li><a rel="external" href="https://github.com/eth-sri/securify">Securify</a></li> <li><a rel="external" href="https://www.skalelabs.com/">Skale</a></li> <li><a rel="external" href="https://status.im/">Status</a></li> </ul> <h4 id="some-papers">Some Papers</h4> <ul> <li><a rel="external" href="https://www.google.com/url?q=http://fsl.cs.illinois.edu/FSL/papers/2018/park-zhang-saxena-daian-rosu-2018-fse/park-zhang-saxena-daian-rosu-2018-fse-public.pdf">A Formal Verification Tool for Ethereum VM Bytecode</a></li> <li><a rel="external" href="https://github.com/pirapira/eth-isabelle">A Lem formalization of EVM and some Isabelle/HOL proofs</a></li> <li><a rel="external" href="https://eprint.iacr.org/2016/1007.pdf">A survey of attacks on Ethereum smart contracts</a></li> <li><a rel="external" href="https://www.google.com/url?q=http://fc17.ifca.ai/wtsc/Defining%2520the%2520Ethereum%2520Virtual%2520Machine%2520for%2520Interactive%2520Theorem%2520Provers.pdf">Defining the Ethereum Virtual Machine for Interactive Theorem Provers</a></li> <li><a rel="external" href="https://github.com/ethereum/eth2.0-specs">Ethereum 2.0 Specifications</a></li> <li><a rel="external" href="https://www.cs.umd.edu/~aseem/solidetherplas.pdf">Formal Verification of Smart Contracts</a></li> <li><a rel="external" href="https://jellopaper.org/">JelloPaper: Human Readable Semantics of EVM in K</a></li> <li><a rel="external" href="https://www.ideals.illinois.edu/items/102260">KEVM: A Complete Semantics of the Ethereum Virtual Machine.</a></li> <li><a rel="external" href="https://eprint.iacr.org/2016/633.pdf">Making Smart Contracts Smarter</a></li> <li><a rel="external" href="https://arxiv.org/pdf/1806.01143.pdf">Securify: Practical Security Analysis of Smart Contracts</a></li> <li><a rel="external" href="https://docs.thundercore.com/thunder-whitepaper.pdf">The Thunder Protocol</a></li> <li><a rel="external" href="https://trustworthy.systems/publications/full_text/Amani_BBS_18.pdf">Towards Verifying Ethereum Smart Contract Bytecode in Isabelle/HOL</a> *<a rel="external" href="https://github.com/seed/eth-isabelle/tree/evm15">A Lem formalization of EVM 1.5</a></li> </ul> <h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2016-11-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/170/ <h3 id="hard-fork">Hard fork</h3> <p><a href="https://wg-eips.ritovision.com/607/">Spurious Dragon</a></p> <h3 id="parameters">Parameters</h3> <ul> <li><code>MAX_CODE_SIZE</code>: <code>0x6000</code> (<code>2**14 + 2**13</code>)</li> <li><code>FORK_BLKNUM</code>: 2,675,000</li> <li><code>CHAIN_ID</code>: 1 (Mainnet)</li> </ul> <h3 id="specification">Specification</h3> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, then if contract creation initialization returns data with length of <strong>more than</strong> <code>MAX_CODE_SIZE</code> bytes, contract creation fails with an out of gas error.</p> <h3 id="rationale">Rationale</h3> <p>Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.</p> <h3 id="references">References</h3> <ol> <li>EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170</li> <li>pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397</li> </ol> 2016-10-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Gavin Woodhttps://github.com/gavofyork https://wg-eips.ritovision.com/161/ <h3 id="hard-fork">Hard fork</h3> <p><a href="https://wg-eips.ritovision.com/607/">Spurious Dragon</a></p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code>: 2,675,000</li> <li><code>CHAIN_ID</code>: 1 (Mainnet)</li> </ul> <h3 id="specification">Specification</h3> <p>a. Account creation transactions and the <code>CREATE</code> operation SHALL, prior to the execution of the initialisation code, <strong>increment</strong> the <strong>nonce</strong> over and above its normal starting value by <strong>one</strong> (for normal networks, this will be simply 1, however test-nets with non-zero default starting nonces will be different).</p> <p>b. Whereas <code>CALL</code> and <code>SUICIDE</code> would charge 25,000 gas when the destination is non-existent, now the charge SHALL <strong>only</strong> be levied if the operation transfers <strong>more than zero value</strong> and the destination account is <em>dead</em>.</p> <p>c. No account may <em>change state</em> from non-existent to existent-but-<em>empty</em>. If an operation would do this, the account SHALL instead remain non-existent.</p> <p>d. <em>At the end of the transaction</em>, any account <em>touched</em> by the execution of that transaction which is now <em>empty</em> SHALL instead become non-existent (i.e. <strong>deleted</strong>).</p> <p>Where:</p> <p>An account is considered to be <em>touched</em> when it is involved in any potentially <em>state-changing</em> operation. This includes, but is not limited to, being the recipient of a <strong>transfer of zero value</strong>.</p> <p>An account is considered <em>empty</em> when it has <strong>no code</strong> and <strong>zero nonce</strong> and <strong>zero balance</strong>.</p> <p>An account is considered <em>dead</em> when either it is non-existent or it is <em>empty</em>.</p> <p><em>At the end of the transaction</em> is immediately following the execution of the suicide list, prior to the determination of the state trie root for receipt population.</p> <p>An account <em>changes state</em> when:</p> <ul> <li>it is the target or refund of a <code>SUICIDE</code> operation for <strong>zero or more</strong> value;</li> <li>it is the source or destination of a <code>CALL</code> operation or message-call transaction transferring <strong>zero or more</strong> value;</li> <li>it is the source or creation of a <code>CREATE</code> operation or contract-creation transaction endowing <strong>zero or more</strong> value;</li> <li>as the block author ("miner") it is the recipient of block-rewards or transaction-fees of <strong>zero or more</strong> value.</li> </ul> <h4 id="notes">Notes</h4> <p>In the present Ethereum protocol, it should be noted that very few state changes can ultimately result in accounts that are empty following the execution of the transaction. In fact there are only four contexts that current implementations need track:</p> <ul> <li>an empty account has zero value transferred to it through <code>CALL</code>;</li> <li>an empty account has zero value transferred to it through <code>SUICIDE</code>;</li> <li>an empty account has zero value transferred to it through a message-call transaction;</li> <li>an empty account has zero value transferred to it through a zero-gas-price fees transfer.</li> </ul> <h3 id="rationale">Rationale</h3> <p>Same as #158 except that several edge cases are avoided since we do not break invariants:</p> <ul> <li><del>that an account can go from having code and storage to not having code or storage mid-way through the execution of a transaction;</del> [corrected]</li> <li>that a newly created account cannot be deleted prior to being deployed.</li> </ul> <p><code>CREATE</code> avoids zero in the nonce to avoid any suggestion of the oddity of <code>CREATE</code>d accounts being reaped half-way through their creation.</p> <h3 id="addendum-2017-08-15">Addendum (2017-08-15)</h3> <p>On 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.[3] The specification was amended to clarify that empty account deletions are reverted when the state is reverted.</p> <h3 id="references">References</h3> <ol> <li>EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158</li> <li>EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161</li> <li>https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/</li> </ol> <blockquote> <p>Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.</p> </blockquote> 2016-10-20T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/160/ <h3 id="hard-fork">Hard fork</h3> <p><a href="https://wg-eips.ritovision.com/607/">Spurious Dragon</a></p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code>: 2,675,000</li> <li><code>CHAIN_ID</code>: 1</li> </ul> <h3 id="specification">Specification</h3> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, increase the gas cost of EXP from 10 + 10 per byte in the exponent to 10 + 50 per byte in the exponent.</p> <h3 id="rationale">Rationale</h3> <p>Benchmarks suggest that EXP is currently underpriced by a factor of about 4–8.</p> <h3 id="references">References</h3> <ol> <li>EIP-160 issue and discussion: https://github.com/ethereum/EIPs/issues/160</li> </ol> 2016-10-16T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/158/ <h1 id="specification">Specification</h1> <p>For all blocks where <code>block.number &gt;= FORK_BLKNUM</code> (TBA):</p> <ol> <li>In all cases where a state change is made to an account, and this state change results in the account state being saved with nonce = 0, balance = 0, code empty, storage empty (hereinafter "empty account"), the account is instead deleted.</li> <li>If an address is "touched" and that address contains an empty account, then it is deleted. A "touch" is defined as any situation where if the account at the given address were nonexistent it would be created.</li> <li>Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution.</li> <li>Zero-value calls and zero-value suicides no longer consume the 25000 account creation gas cost in any circumstance</li> </ol> <p>The cases where a "touch" takes place can be enumerated as follows:</p> <ul> <li>Zero-value-bearing CALLs</li> <li>CREATEs (if the code that is ultimately saved is empty and there is no ether remaining in the account when it is saved)</li> <li>Zero-value-bearing SUICIDEs</li> <li>Transaction recipients</li> <li>Contracts created in contract creation transactions</li> <li>Miners receiving transaction fees (note the case where the gasprice is zero, and the account does not yet exist because it only receives the block/uncle/nephew rewards <em>after</em> processing every transaction)</li> </ul> <h3 id="specification-1b">Specification (1b)</h3> <p>When the EVM checks for emptiness (for the purpose of possibly applying the 25000 gas cost), emptiness is defined by <code>is_empty(acct): return get_balance(acct) == 0 and get_code(acct) == "" and get_nonce(acct) == 0</code>; emptiness of storage does not matter. This simplifies client implementation because there is no need to add extra complexity to make caches enumerable in the correct way and does not significantly affect the intended result, as the cases where balance/code/nonce are empty but storage is nonempty where this change would lead to an extra 25000 gas being paid are pathological and have no real use value.</p> <h3 id="specification-1c">Specification (1c)</h3> <p>Do not implement point 2 above (ie. no new empty accounts can be created, but existing ones are not automatically destroyed unless their state is actually <em>changed</em>). Instead, during each block starting from (and including) N and ending when there are no null accounts left, select the 1000 null accounts that are left-most in order of sha3(address), and delete them (ordering by hash is necessary so as to allow the accounts to be easily found by iterating the tree).</p> <h1 id="rationale">Rationale</h1> <p>This removes a large number of empty accounts that have been put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol, thereby greatly reducing state size and hence both reducing the hard disk load of a full client and reducing the time for a fast sync. Additionally, it simplifies the protocol in the long term, as once all "empty" objects are cleared out there is no longer any meaningful distinction between an account being empty and being nonexistent, and indeed one can simply view nonexistence as a compact representation of emptiness.</p> <p>Note that this proposal does introduce a <strong>temporary</strong> breaking of existing guarantees, in that by repeatedly zero-value-calling already existing empty accounts one can create a state change at a cost of 700 gas per account instead of the usual 5000 per gas minimum (with SUICIDE refunds this goes down further to 350 gas per account). Allowing such a large number of state writes per block will lead to heightened block processing times and increase uncle rates in the short term while the existing empty accounts are being cleared, and eventually once all empty accounts are cleared this issue will no longer exist.</p> <h1 id="references">References</h1> <ol> <li>EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158</li> <li>EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161</li> </ol> 2016-10-14T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/155/ <h3 id="hard-fork">Hard fork</h3> <p><a href="https://wg-eips.ritovision.com/607/">Spurious Dragon</a></p> <h3 id="parameters">Parameters</h3> <ul> <li><code>FORK_BLKNUM</code>: 2,675,000</li> <li><code>CHAIN_ID</code>: 1 (main net)</li> </ul> <h3 id="specification">Specification</h3> <p>If <code>block.number &gt;= FORK_BLKNUM</code> and <code>CHAIN_ID</code> is available, then when computing the hash of a transaction for the purposes of signing, instead of hashing only six rlp encoded elements <code>(nonce, gasprice, startgas, to, value, data)</code>, you <strong>SHOULD</strong> hash nine rlp encoded elements <code>(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)</code>. If you do, then the <code>v</code> of the signature <strong>MUST</strong> be set to <code>{0,1} + CHAIN_ID * 2 + 35</code> where <code>{0,1}</code> is the parity of the <code>y</code> value of the curve point for which <code>r</code> is the x-value in the secp256k1 signing process. If you choose to only hash 6 values, then <code>v</code> continues to be set to <code>{0,1} + 27</code> as previously.</p> <p>If <code>block.number &gt;= FORK_BLKNUM</code> and <code>v = CHAIN_ID * 2 + 35</code> or <code>v = CHAIN_ID * 2 + 36</code>, then when computing the hash of a transaction for purposes of recovering, instead of hashing six rlp encoded elements <code>(nonce, gasprice, startgas, to, value, data)</code>, hash nine rlp encoded elements <code>(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)</code>. The currently existing signature scheme using <code>v = 27</code> and <code>v = 28</code> remains valid and continues to operate under the same rules as it did previously.</p> <h3 id="example">Example</h3> <p>Consider a transaction with <code>nonce = 9</code>, <code>gasprice = 20 * 10**9</code>, <code>startgas = 21000</code>, <code>to = 0x3535353535353535353535353535353535353535</code>, <code>value = 10**18</code>, <code>data=''</code> (empty).</p> <p>The "signing data" becomes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080</span></span></code></pre> <p>The "signing hash" becomes:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0xdaf5a779ae972f972197303d7b574746c7ef83eadac0f2791ad23db92e4c8e53</span></span></code></pre> <p>If the transaction is signed with the private key <code>0x4646464646464646464646464646464646464646464646464646464646464646</code>, then the v,r,s values become:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>(37, 18515461264373351373200002665853028612451056578545711640558177340181847433846, 46948507304638947509940763649030358759909902576025900602547168820602576006531)</span></span></code></pre> <p>Notice the use of 37 instead of 27. The signed tx would become:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83</span></span></code></pre><h3 id="rationale">Rationale</h3> <p>This would provide a way to send transactions that work on Ethereum without working on ETC or the Morden testnet. ETC is encouraged to adopt this EIP but replacing <code>CHAIN_ID</code> with a different value, and all future testnets, consortium chains and alt-etherea are encouraged to adopt this EIP replacing <code>CHAIN_ID</code> with a unique value.</p> <h3 id="list-of-chain-id-s">List of Chain ID's:</h3> <table><thead><tr><th><code>CHAIN_ID</code></th><th>Chain(s)</th></tr></thead><tbody> <tr><td>1</td><td>Ethereum mainnet</td></tr> <tr><td>2</td><td>Morden (disused), Expanse mainnet</td></tr> <tr><td>3</td><td>Ropsten</td></tr> <tr><td>4</td><td>Rinkeby</td></tr> <tr><td>5</td><td>Goerli</td></tr> <tr><td>42</td><td>Kovan</td></tr> <tr><td>1337</td><td>Geth private chains (default)</td></tr> </tbody></table> <p>Find more chain ID's on <a rel="external" href="https://chainid.network">chainid.network</a> and contribute to <a rel="external" href="https://github.com/ethereum-lists/chains">ethereum-lists/chains</a>.</p> 2016-10-04T00:00:00+00:00 2026-02-11T14:49:27+00:00 Tjaden Hesstah83@cornell.edu Matt Luongohttps://github.com/mhluongo Piotr Dyragahttps://github.com/pdyraga James Hancockhttps://github.com/MadeOfTin https://wg-eips.ritovision.com/152/ <h2 id="simple-summary">Simple Summary</h2> <p>This EIP will enable the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins.</p> <h2 id="abstract">Abstract</h2> <p>This EIP introduces a new precompiled contract which implements the compression function <code>F</code> used in the BLAKE2 cryptographic hashing algorithm, for the purpose of allowing interoperability between the EVM and Zcash, as well as introducing more flexible cryptographic hash primitives to the EVM.</p> <h2 id="motivation">Motivation</h2> <p>Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2 allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2 is used.</p> <p>BLAKE2b, the common 64-bit BLAKE2 variant, is highly optimized and faster than MD5 on modern processors.</p> <p>Interoperability with Zcash could enable contracts like trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain.</p> <h2 id="specification">Specification</h2> <p>We propose adding a precompiled contract at address <code>0x09</code> wrapping the <a rel="external" href="https://tools.ietf.org/html/rfc7693#section-3.2">BLAKE2 <code>F</code> compression function</a>.</p> <p>The precompile requires 6 inputs tightly encoded, taking exactly 213 bytes, as explained below. The encoded inputs are corresponding to the ones specified in the <a rel="external" href="https://tools.ietf.org/html/rfc7693#section-3.2">BLAKE2 RFC Section 3.2</a>:</p> <ul> <li><code>rounds</code> - the number of rounds - 32-bit unsigned big-endian word</li> <li><code>h</code> - the state vector - 8 unsigned 64-bit little-endian words</li> <li><code>m</code> - the message block vector - 16 unsigned 64-bit little-endian words</li> <li><code>t_0, t_1</code> - offset counters - 2 unsigned 64-bit little-endian words</li> <li><code>f</code> - the final block indicator flag - 8-bit word</li> </ul> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>[4 bytes for rounds][64 bytes for h][128 bytes for m][8 bytes for t_0][8 bytes for t_1][1 byte for f]</span></span></code></pre> <p>The boolean <code>f</code> parameter is considered as <code>true</code> if set to <code>1</code>. The boolean <code>f</code> parameter is considered as <code>false</code> if set to <code>0</code>. All other values yield an invalid encoding of <code>f</code> error.</p> <p>The precompile should compute the <code>F</code> function as <a rel="external" href="https://tools.ietf.org/html/rfc7693#section-3.2">specified in the RFC</a> and return the updated state vector <code>h</code> with unchanged encoding (little-endian).</p> <h3 id="example-usage-in-solidity">Example Usage in Solidity</h3> <p>The precompile can be wrapped easily in Solidity to provide a more development-friendly interface to <code>F</code>.</p> <pre class="giallo z-code"><code data-lang="solidity"><span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> F</span><span>(</span><span class="z-support">uint32</span><span class="z-variable"> rounds</span><span>,</span><span class="z-support"> bytes32</span><span>[</span><span class="z-variable">2</span><span>]</span><span class="z-storage z-type"> memory</span><span class="z-variable"> h</span><span>,</span><span class="z-support"> bytes32</span><span>[</span><span class="z-variable">4</span><span>]</span><span class="z-storage z-type"> memory</span><span class="z-variable"> m</span><span>,</span><span class="z-support"> bytes8</span><span>[</span><span class="z-variable">2</span><span>]</span><span class="z-storage z-type"> memory</span><span class="z-variable"> t</span><span>,</span><span class="z-support"> bool</span><span class="z-variable"> f</span><span>)</span><span class="z-storage z-type"> public</span><span class="z-storage z-type"> view</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">bytes32</span><span>[</span><span class="z-variable">2</span><span>]</span><span class="z-storage z-type"> memory</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-storage z-type"> memory</span><span> output</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> bytes</span><span class="z-storage z-type"> memory</span><span> args </span><span class="z-keyword">=</span><span class="z-variable z-language"> abi</span><span>.</span><span class="z-entity z-name">encodePacked</span><span>(</span><span>rounds</span><span>,</span><span> h</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> h</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span> m</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> m</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span> m</span><span>[</span><span class="z-constant">2</span><span>]</span><span>,</span><span> m</span><span>[</span><span class="z-constant">3</span><span>]</span><span>,</span><span> t</span><span>[</span><span class="z-constant">0</span><span>]</span><span>,</span><span> t</span><span>[</span><span class="z-constant">1</span><span>]</span><span>,</span><span> f</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> assembly</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> if</span><span class="z-entity z-name"> iszero</span><span>(</span><span class="z-entity z-name">staticcall</span><span>(</span><span class="z-entity z-name">not</span><span>(</span><span class="z-constant">0</span><span>)</span><span>,</span><span class="z-constant"> 0x09</span><span>,</span><span class="z-entity z-name"> add</span><span>(</span><span>args</span><span>,</span><span class="z-constant"> 32</span><span>)</span><span>,</span><span class="z-constant"> 0xd5</span><span>,</span><span> output</span><span>,</span><span class="z-constant"> 0x40</span><span>)</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-keyword"> revert</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword"> return</span><span> output</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">function</span><span class="z-entity z-name"> callF</span><span>(</span><span>)</span><span class="z-storage z-type"> public</span><span class="z-storage z-type"> view</span><span class="z-keyword"> returns</span><span> (</span><span class="z-support">bytes32</span><span>[</span><span class="z-variable">2</span><span>]</span><span class="z-storage z-type"> memory</span><span>)</span><span> {</span></span> <span class="giallo-l"><span class="z-support"> uint32</span><span> rounds </span><span class="z-keyword">=</span><span class="z-constant"> 12</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-storage z-type"> memory</span><span> h</span><span>;</span></span> <span class="giallo-l"><span> h</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5&quot;</span><span>;</span></span> <span class="giallo-l"><span> h</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b&quot;</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> bytes32</span><span>[</span><span class="z-constant">4</span><span>]</span><span class="z-storage z-type"> memory</span><span> m</span><span>;</span></span> <span class="giallo-l"><span> m</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;6162630000000000000000000000000000000000000000000000000000000000&quot;</span><span>;</span></span> <span class="giallo-l"><span> m</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;0000000000000000000000000000000000000000000000000000000000000000&quot;</span><span>;</span></span> <span class="giallo-l"><span> m</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;0000000000000000000000000000000000000000000000000000000000000000&quot;</span><span>;</span></span> <span class="giallo-l"><span> m</span><span>[</span><span class="z-constant">3</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;0000000000000000000000000000000000000000000000000000000000000000&quot;</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> bytes8</span><span>[</span><span class="z-constant">2</span><span>]</span><span class="z-storage z-type"> memory</span><span> t</span><span>;</span></span> <span class="giallo-l"><span> t</span><span>[</span><span class="z-constant">0</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;0300000000000000&quot;</span><span>;</span></span> <span class="giallo-l"><span> t</span><span>[</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> =</span><span> hex</span><span class="z-string">&quot;0000000000000000&quot;</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support"> bool</span><span> f </span><span class="z-keyword">=</span><span class="z-constant"> true</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> Expected output:</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d1</span></span> <span class="giallo-l"><span class="z-comment"> //</span><span class="z-comment"> 7d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923</span></span> <span class="giallo-l"><span class="z-keyword"> return</span><span class="z-entity z-name"> F</span><span>(</span><span>rounds</span><span>,</span><span> h</span><span>,</span><span> m</span><span>,</span><span> t</span><span>,</span><span> f</span><span>)</span><span>;</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h3 id="gas-costs-and-benchmarks">Gas costs and benchmarks</h3> <p>Each operation will cost <code>GFROUND * rounds</code> gas, where <code>GFROUND = 1</code>. Detailed benchmarks are presented in the benchmarks appendix section.</p> <h2 id="rationale">Rationale</h2> <p>BLAKE2 is an excellent candidate for precompilation. BLAKE2 is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and little-endian arithmetic. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5.</p> <p>In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficient implementation of BLAKE2, and thus the gas cost associated with computing the hash on the EVM is disproportionate to the true cost of computing the function natively.</p> <p>An obvious implementation would be a direct BLAKE2b hash function precompile. At first glance, a BLAKE2b precompile satisfies most hashing and interoperability requirements on the EVM. Once we started digging in, however, it became clear that any BLAKE2b implementation would need specific features and internal modifications based on different projects' requirements and libraries.</p> <p>A <a rel="external" href="https://github.com/ethereum/EIPs/issues/152#issuecomment-499240310">thread with the Zcash team</a> makes the issue clear.</p> <blockquote> <p>The minimal thing that is necessary for a working ZEC-ETH relay is an implementation of BLAKE2b Compression F in a precompile.</p> </blockquote> <blockquote> <p>A BLAKE2b Compression Function F precompile would also suffice for the Filecoin and Handshake interop goals.</p> </blockquote> <blockquote> <p>A full BLAKE2b precompile would suffice for a ZEC-ETH relay, provided that the implementation provided the parts of the BLAKE2 API that we need (personalization, maybe something else—I'm not sure).</p> </blockquote> <blockquote> <p>I'm not 100% certain if a full BLAKE2b precompile would also suffice for the Filecoin and Handshake goals. It almost certainly could, provided that it supports all the API that they need.</p> </blockquote> <blockquote> <p>BLAKE2s — whether the Compression Function F or the full hash — is only a nice-to-have for the purposes of a ZEC-ETH relay.</p> </blockquote> <p>From this and other conversations with teams in the space, we believe we should focus first on the <code>F</code> precompile as a strictly necessary piece for interoperability projects. A BLAKE2b precompile is a nice-to-have, and we support any efforts to add one-- but it's unclear whether complete requirements and a flexible API can be found in time for Istanbul.</p> <p>Implementation of only the core F compression function also allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM.</p> <h2 id="backwards-compatibility">Backwards Compatibility</h2> <p>There is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at <code>0x09</code> being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision.</p> <h2 id="test-cases">Test Cases</h2> <h4 id="test-vector-0">Test vector 0</h4> <ul> <li>input: (empty)</li> <li>output: error "input length for BLAKE2 F precompile should be exactly 213 bytes"</li> </ul> <h4 id="test-vector-1">Test vector 1</h4> <ul> <li>input: <code>00000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: error "input length for BLAKE2 F precompile should be exactly 213 bytes"</li> </ul> <h4 id="test-vector-2">Test vector 2</h4> <ul> <li>input: <code>000000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: error "input length for BLAKE2 F precompile should be exactly 213 bytes"</li> </ul> <h4 id="test-vector-3">Test vector 3</h4> <ul> <li>input: <code>0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000002</code></li> <li>output: error "incorrect final block indicator flag"</li> </ul> <h4 id="test-vector-4">Test vector 4</h4> <ul> <li>input: <code>0000000048c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: <code>08c9bcf367e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d282e6ad7f520e511f6c3e2b8c68059b9442be0454267ce079217e1319cde05b</code></li> </ul> <h4 id="test-vector-5">Test vector 5</h4> <ul> <li>input: <code>0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: <code>ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923</code></li> </ul> <h4 id="test-vector-6">Test vector 6</h4> <ul> <li>input: <code>0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000</code></li> <li>output: <code>75ab69d3190a562c51aef8d88f1c2775876944407270c42c9844252c26d2875298743e7f6d5ea2f2d3e8d226039cd31b4e426ac4f2d3d666a610c2116fde4735</code></li> </ul> <h4 id="test-vector-7">Test vector 7</h4> <ul> <li>input: <code>0000000148c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: <code>b63a380cb2897d521994a85234ee2c181b5f844d2c624c002677e9703449d2fba551b3a8333bcdf5f2f7e08993d53923de3d64fcc68c034e717b9293fed7a421</code></li> </ul> <h4 id="test-vector-8">Test vector 8</h4> <ul> <li>input: <code>ffffffff48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001</code></li> <li>output: <code>fc59093aafa9ab43daae0e914c57635c5402d8e3d2130eb9b3cc181de7f0ecf9b22bf99a7815ce16419e200e01846e6b5df8cc7703041bbceb571de6631d2615</code></li> </ul> <h2 id="implementation">Implementation</h2> <p>An initial implementation of the <code>F</code> function in Go, adapted from the standard library, can be found in our <a rel="external" href="https://github.com/keep-network/blake2-f">Golang BLAKE2 library fork</a>. There's also an implementation of the precompile in our fork of <a rel="external" href="https://github.com/keep-network/go-ethereum/pull/4">go-ethereum</a>.</p> <h2 id="references">References</h2> <p>For reference, further discussion on this EIP also occurred in the following PRs and issues</p> <ul> <li><a rel="external" href="https://github.com/ethereum/EIPs/issues/152">Original Issue</a></li> <li><a rel="external" href="https://ethereum-magicians.org/t/blake2b-f-precompile/3157">Ethereum Magicians</a></li> <li><a rel="external" href="https://github.com/ethereum/EIPs/pull/2129">PR 2129</a></li> </ul> <h2 id="appendix-benchmarks">Appendix - benchmarks</h2> <p>Assuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine.</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name">$</span><span class="z-string"> sysctl</span><span class="z-constant"> -</span><span class="z-constant">n</span><span class="z-string"> machdep.cpu.brand_string</span></span> <span class="giallo-l"><span class="z-entity z-name">Intel(R</span><span>) Core(</span><span class="z-entity z-name">TM</span><span>) i7-7920HQ CPU @ 3.10GHz</span></span></code></pre><h3 id="12-rounds">12 rounds</h3> <p>An average gas price of F precompile call with 12 rounds compared to ecRecover should have been <code>6.74153</code> and it gives <code>0.5618</code> gas per round.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq</span></span> <span class="giallo-l"><span>----------------------------------------- --------- ---------------- --------- ----------------------- -----------------------</span></span> <span class="giallo-l"><span>PrecompiledEcrecover/ 3000 152636 19.6546 1526.36 3000</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_0 12 338 35.503 3.38 6.64326</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_3 12 336 35.7143 3.36 6.60395</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_70 12 362 33.1492 3.62 7.11497</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_140 12 339 35.3982 3.39 6.66291</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_230 12 339 35.3982 3.39 6.66291</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_300 12 343 34.9854 3.43 6.74153</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_370 12 336 35.7143 3.36 6.60395</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_440 12 337 35.6083 3.37 6.6236</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_510 12 345 34.7826 3.45 6.78084</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_580 12 355 33.8028 3.55 6.97738</span></span></code></pre> <p>Columns</p> <ul> <li><code>MGas/S</code> - Shows what MGas per second was measured on that machine at that time</li> <li><code>Gasprice for 10MGas/S</code> shows what the gasprice should have been, in order to reach 10 MGas/second</li> <li><code>Gasprice for ECDSA eq</code> shows what the gasprice should have been, in order to have the same cost/cycle as ecRecover</li> </ul> <h3 id="1200-rounds">1200 rounds</h3> <p>An average gas price of F precompile call with 1200 rounds compared to ecRecover should have been <code>436.1288</code> and it gives <code>0.3634</code> gas per round.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq</span></span> <span class="giallo-l"><span>----------------------------------------- --------- ---------------- --------- ----------------------- -----------------------</span></span> <span class="giallo-l"><span>PrecompiledEcrecover/ 3000 156152 19.212 1561.52 3000</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_0 1200 22642 52.9989 226.42 434.999</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_3 1200 22885 52.4361 228.85 439.668</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_70 1200 22737 52.7774 227.37 436.824</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_140 1200 22602 53.0926 226.02 434.231</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_230 1200 22501 53.331 225.01 432.29</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_300 1200 22435 53.4879 224.35 431.022</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_370 1200 22901 52.3995 229.01 439.975</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_440 1200 23134 51.8717 231.34 444.452</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_510 1200 22608 53.0786 226.08 434.346</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_580 1200 22563 53.1844 225.63 433.481</span></span></code></pre><h3 id="1-round">1 round</h3> <p>An average gas price of F precompile call with 1 round compared to ecRecover should have been <code>2.431701</code>. However, in this scenario the call cost would totally overshadow the dynamic cost anyway.</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>Name Gascost Time (ns) MGas/S Gasprice for 10MGas/S Gasprice for ECDSA eq</span></span> <span class="giallo-l"><span>----------------------------------------- --------- ---------------- ---------- ----------------------- -----------------------</span></span> <span class="giallo-l"><span>PrecompiledEcrecover/ 3000 157544 19.0423 1575.44 3000</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_0 1 126 7.93651 1.26 2.39933</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_3 1 127 7.87402 1.27 2.41837</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_70 1 128 7.8125 1.28 2.43741</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_140 1 125 8 1.25 2.38029</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_230 1 128 7.8125 1.28 2.43741</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_300 1 127 7.87402 1.27 2.41837</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_370 1 131 7.63359 1.31 2.49454</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_440 1 129 7.75194 1.29 2.45646</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_510 1 125 8 1.25 2.38029</span></span> <span class="giallo-l"><span>PrecompiledBlake2F/testVectors2bX_580 1 131 7.63359 1.31 2.49454</span></span></code></pre><h2 id="copyright">Copyright</h2> <p>Copyright and related rights waived via <a href="https://wg-eips.ritovision.com/license/">CC0</a>.</p> 2016-09-24T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/150/ <h3 id="meta-reference">Meta reference</h3> <p><a href="https://wg-eips.ritovision.com/608/">Tangerine Whistle</a>.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>FORK_BLKNUM</th><th>CHAIN_ID</th><th>CHAIN_NAME</th></tr></thead><tbody> <tr><td>2,463,000</td><td>1</td><td>Main net</td></tr> </tbody></table> <h3 id="specification">Specification</h3> <p>If <code>block.number &gt;= FORK_BLKNUM</code>, then:</p> <ul> <li>Increase the gas cost of EXTCODESIZE to 700 (from 20).</li> <li>Increase the base gas cost of EXTCODECOPY to 700 (from 20).</li> <li>Increase the gas cost of BALANCE to 400 (from 20).</li> <li>Increase the gas cost of SLOAD to 200 (from 50).</li> <li>Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40).</li> <li>Increase the gas cost of SELFDESTRUCT to 5000 (from 0).</li> <li>If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs).</li> <li>Increase the recommended gas limit target to 5.5 million.</li> <li>Define "all but one 64th" of <code>N</code> as <code>N - floor(N / 64)</code>.</li> <li>If a call asks for more gas than the maximum allowed amount (i.e. the total amount of gas remaining in the parent after subtracting the gas cost of the call and memory expansion), do not return an OOG error; instead, if a call asks for more gas than all but one 64th of the maximum allowed amount, call with all but one 64th of the maximum allowed amount of gas (this is equivalent to a version of EIP-90^{<a rel="external" href="https://github.com/ethereum/EIPs/issues/90">1</a>} plus EIP-114^{<a rel="external" href="https://github.com/ethereum/EIPs/issues/114">2</a>}). CREATE only provides all but one 64th of the parent gas to the child call.</li> </ul> <p>That is, substitute:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \</span></span> <span class="giallo-l"><span> (value &gt; 0) * opcodes.GCALLVALUETRANSFER</span></span> <span class="giallo-l"><span> if compustate.gas &lt; gas + extra_gas:</span></span> <span class="giallo-l"><span> return vm_exception(&#39;OUT OF GAS&#39;, needed=gas+extra_gas)</span></span> <span class="giallo-l"><span> submsg_gas = gas + opcodes.GSTIPEND * (value &gt; 0)</span></span></code></pre> <p>With:</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span> def max_call_gas(gas):</span></span> <span class="giallo-l"><span> return gas - (gas // 64)</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span> extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \</span></span> <span class="giallo-l"><span> (value &gt; 0) * opcodes.GCALLVALUETRANSFER</span></span> <span class="giallo-l"><span> if compustate.gas &lt; extra_gas:</span></span> <span class="giallo-l"><span> return vm_exception(&#39;OUT OF GAS&#39;, needed=extra_gas)</span></span> <span class="giallo-l"><span> if compustate.gas &lt; gas + extra_gas:</span></span> <span class="giallo-l"><span> gas = min(gas, max_call_gas(compustate.gas - extra_gas))</span></span> <span class="giallo-l"><span> submsg_gas = gas + opcodes.GSTIPEND * (value &gt; 0)</span></span></code></pre><h3 id="rationale">Rationale</h3> <p>Recent denial-of-service attacks have shown that opcodes that read the state tree are under-priced relative to other opcodes. There are software changes that have been made, are being made and can be made in order to mitigate the situation; however, the fact will remain that such opcodes will be by a substantial margin the easiest known mechanism to degrade network performance via transaction spam. The concern arises because it takes a long time to read from disk, and is additionally a risk to future sharding proposals as the "attack transactions" that have so far been most successful in degrading network performance would also require tens of megabytes to provide Merkle proofs for. This EIP increases the cost of storage reading opcodes to address this concern. The costs have been derived from an updated version of the calculation table used to generate the 1.0 gas costs: https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0; the rules attempt to target a limit of 8 MB of data that needs to be read in order to process a block, and include an estimate of 500 bytes for a Merkle proof for SLOAD and 1000 for an account.</p> <p>This EIP aims to be simple, and adds a flat penalty of 300 gas on top of the costs calculated in this table to account for the cost of loading the code (~17–21 kb in the worst case).</p> <p>The EIP 90 gas mechanic is introduced because without it, all current contracts that make calls would stop working as they use an expression like <code>msg.gas - 40</code> to determine how much gas to make a call with, relying on the gas cost of calls being 40. Additionally, EIP 114 is introduced because, given that we are making the cost of a call higher and less predictable, we have an opportunity to do it at no extra cost to currently available guarantees, and so we also achieve the benefit of replacing the call stack depth limit with a "softer" gas-based restriction, thereby eliminating call stack depth attacks as a class of attack that contract developers have to worry about and hence increasing contract programming safety. Note that with the given parameters, the de-facto maximum call stack depth is limited to ~340 (down from ~1024), mitigating the harm caused by any further potential quadratic-complexity DoS attacks that rely on calls.</p> <p>The gas limit increase is recommended so as to preserve the de-facto transactions-per-second processing capability of the system for average contracts.</p> <h2 id="references">References</h2> <ol> <li>EIP-90, https://github.com/ethereum/EIPs/issues/90</li> <li>EIP-114, https://github.com/ethereum/EIPs/issues/114</li> </ol> 2016-04-28T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/100/ <h3 id="specification">Specification</h3> <p>Currently, the formula to compute the difficulty of a block includes the following logic:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>adj_factor</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">1</span><span class="z-keyword"> -</span><span> (</span><span>(</span><span>timestamp</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>timestamp</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 10</span><span>)</span><span>,</span><span class="z-keyword"> -</span><span class="z-constant">99</span><span>)</span></span> <span class="giallo-l"><span>child_diff</span><span class="z-keyword"> =</span><span class="z-support"> int</span><span>(</span><span class="z-support">max</span><span>(</span><span>parent</span><span>.</span><span>difficulty</span><span class="z-keyword"> +</span><span> (</span><span>parent</span><span>.</span><span>difficulty</span><span class="z-keyword"> //</span><span class="z-constant"> BLOCK_DIFF_FACTOR</span><span>)</span><span class="z-keyword"> *</span><span> adj_factor</span><span>,</span><span class="z-support"> min</span><span>(</span><span>parent</span><span>.</span><span>difficulty</span><span>,</span><span class="z-constant"> MIN_DIFF</span><span>)</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-constant">...</span></span></code></pre> <p>If <code>block.number &gt;= BYZANTIUM_FORK_BLKNUM</code>, we change the first line to the following:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>adj_factor</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span>(</span><span class="z-constant">2</span><span class="z-keyword"> if</span><span class="z-support"> len</span><span>(</span><span>parent</span><span>.</span><span>uncles</span><span>)</span><span class="z-keyword"> else</span><span class="z-constant"> 1</span><span>)</span><span class="z-keyword"> -</span><span> (</span><span>(</span><span>timestamp</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>timestamp</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 9</span><span>)</span><span>,</span><span class="z-keyword"> -</span><span class="z-constant">99</span><span>)</span></span></code></pre><h3 id="rationale">Rationale</h3> <p>This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span>adj_factor</span><span class="z-keyword"> =</span><span class="z-support"> max</span><span>(</span><span class="z-constant">1</span><span class="z-keyword"> +</span><span class="z-support"> len</span><span>(</span><span>parent</span><span>.</span><span>uncles</span><span>)</span><span class="z-keyword"> -</span><span> (</span><span>(</span><span>timestamp</span><span class="z-keyword"> -</span><span> parent</span><span>.</span><span>timestamp</span><span>)</span><span class="z-keyword"> //</span><span class="z-constant"> 9</span><span>)</span><span>,</span><span class="z-keyword"> -</span><span class="z-constant">99</span><span>)</span></span></code></pre> <p>can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with <code>k</code> uncles is equivalent to a sequence of <code>k+1</code> blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash).</p> <p>Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%).</p> <h3 id="references">References</h3> <ol> <li>EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100</li> <li>https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/</li> </ol> 2015-11-22T00:00:00+00:00 2026-02-11T14:49:27+00:00 Christian Reitwiessnerc@ethdev.com https://wg-eips.ritovision.com/5/ <h3 id="abstract">Abstract</h3> <p>This EIP makes it possible to call functions that return strings and other dynamically-sized arrays. Currently, when another contract / function is called from inside the Ethereum Virtual Machine, the size of the output has to be specified in advance. It is of course possible to give a larger size, but gas also has to be paid for memory that is not written to, which makes returning dynamically-sized data both costly and inflexible to the extent that it is actually unusable.</p> <p>The solution proposed in this EIP is to charge gas only for memory that is actually written to at the time the <code>CALL</code> returns.</p> <h3 id="specification">Specification</h3> <p>The gas and memory semantics for <code>CALL</code>, <code>CALLCODE</code> and <code>DELEGATECALL</code> (called later as <code>CALL*</code>) are changed in the following way (<code>CREATE</code> does not write to memory and is thus unaffected):</p> <p>Suppose the arguments to <code>CALL*</code> are <code>gas, address, value, input_start, input_size, output_start, output_size</code>, then, at the beginning of the opcode, gas for growing memory is only charged for <code>input_start + input_size</code>, but not for <code>output_start + output_size</code>.</p> <p>If the called contract returns data of size <code>n</code>, the memory of the calling contract is grown to <code>output_start + min(output_size, n)</code> (and the calling contract is charged gas for that) and the output is written to the area <code>[output_start, output_start + min(n, output_size))</code>.</p> <p>The calling contract can run out of gas both at the beginning of the opcode and at the end of the opcode.</p> <p>After the call, the <code>MSIZE</code> opcode should return the size the memory was actually grown to.</p> <h3 id="motivation">Motivation</h3> <p>In general, it is good practice to reserve a certain memory area for the output of a call, because letting a subroutine write to arbitrary areas in memory might be dangerous. On the other hand, it is often hard to know the output size of a call prior to performing the call: The data could be in the storage of another contract which is generally inaccessible and determining its size would require another call to that contract.</p> <p>Furthermore, charging gas for areas of memory that are not actually written to is unnecessary.</p> <p>This proposal tries to solve both problems: A caller can choose to provide a gigantic area of memory at the end of their memory area. The callee can "write" to it by returning and the caller is only charged for the memory area that is actually written.</p> <p>This makes it possible to return dynamic data like strings and dynamically-sized arrays in a very flexible way. It is even possible to determine the size of the returned data: If the caller uses <code>output_start = MSIZE</code> and <code>output_size = 2**256-1</code>, the area of memory that was actually written to is <code>(output_start, MSIZE)</code> (here, <code>MSIZE</code> as evaluated after the call). This is important because it allows "proxy" contracts which call other contracts whose interface they do not know and just return their output, i.e. they both forward the input and the output. For this, it is important that the caller (1) does not need to know the size of the output in advance and (2) can determine the size of the output after the call.</p> <h3 id="rationale">Rationale</h3> <p>This way of dealing with the problem requires a minimal change to the Ethereum Virtual Machine. Other means of achieving a similar goal would have changed the opcodes themselves or the number of their arguments. Another possibility would have been to only change the gas mechanics if <code>output_size</code> is equal to <code>2**256-1</code>. Since the main difficulty in the implementation is that memory has to be enlarged at two points in the code around <code>CALL</code>, this would not have been a simplification.</p> <p>At an earlier stage, it was proposed to also add the size of the returned data on the stack, but the <code>MSIZE</code> mechanism described above should be sufficient and is much better backwards compatible.</p> <p>Some comments are available at https://github.com/ethereum/EIPs/issues/8</p> <h3 id="backwards-compatibility">Backwards Compatibility</h3> <p>This proposal changes the semantics of contracts because contracts can access the gas counter and the size of memory.</p> <p>On the other hand, it is unlikely that existing contracts will suffer from this change due to the following reasons:</p> <p>Gas:</p> <p>The VM will not charge more gas than before. Usually, contracts are written in a way such that their semantics do not change if they use up less gas. If more gas were used, contracts might go out-of-gas if they perform a tight estimation for gas needed by sub-calls. Here, contracts might only return more gas to their callers.</p> <p>Memory size:</p> <p>The <code>MSIZE</code> opcode is typically used to allocate memory at a previously unused spot. The change in semantics affects existing contracts in two ways:</p> <ol> <li> <p>Overlaps in allocated memory. By using <code>CALL</code>, a contract might have wanted to allocate a certain slice of memory, even if that is not written to by the called contract. Subsequent uses of <code>MSIZE</code> to allocate memory might overlap with this slice that is now smaller than before the change. It is, though, unlikely that such contracts exist.</p> </li> <li> <p>Memory addresses change. Rather general, if memory is allocated using <code>MSIZE</code>, the addresses of objects in memory will be different after the change. Contracts should all be written in a way, though, such that objects in memory are <em>relocatable</em>, i.e. their absolute position in memory and their relative position to other objects does not matter. This is of course not the case for arrays, but they are allocated in a single allocation and not with an intermediate <code>CALL</code>.</p> </li> </ol> <h3 id="implementation">Implementation</h3> <p>VM implementers should take care not to grow the memory until the end of the call and after a check that sufficient gas is still available. Typical uses of the EIP include "reserving" <code>2**256-1</code> bytes of memory for the output.</p> <p>Python implementation:</p> <p>old: http://vitalik.ca/files/old.py new: http://vitalik.ca/files/new.py</p> 2015-11-19T00:00:00+00:00 2026-02-11T14:49:27+00:00 Martin Holst Swendemartin@swende.se https://wg-eips.ritovision.com/3/ <h1 id="abstract">Abstract</h1> <p>This is a proposal to add a new opcode, <code>CALLDEPTH</code>. The <code>CALLDEPTH</code> opcode would return the remaining available call stack depth.</p> <h1 id="motivation">Motivation</h1> <p>There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently <code>256</code>. If a contract invokes another contract (either via <code>CALL</code> or <code>CALLCODE</code>), the operation will fail if the call stack depth limit has been reached.</p> <p>This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging.</p> <p>Example:</p> <ol> <li>Contract <code>A</code> wants to be invoked regularly, and pays Ether to the invoker in every block.</li> <li>When contract <code>A</code> is invoked, it calls contracts <code>B</code> and <code>C</code>, which consumes a lot of gas. After invocation, contract <code>A</code> pays Ether to the caller.</li> <li>Malicious user <code>X</code> ensures that the stack depth is shallow before invoking A. Both calls to <code>B</code> and <code>C</code> fail, but <code>X</code> can still collect the reward.</li> </ol> <p>It is possible to defend against this in two ways:</p> <ol> <li>Check return value after invocation.</li> <li>Check call stack depth experimentally. A library [2] by Piper Merriam exists for this purpose. This method is quite costly in gas.</li> </ol> <p>[1] a.k.a "shallow stack attack" and "stack attack". However, to be precise, the word ''stack'' has a different meaning within the EVM, and is not to be confused with the ''call stack''.</p> <p>[2] https://github.com/pipermerriam/ethereum-stack-depth-lib</p> <h1 id="specification">Specification</h1> <p>The opcode <code>CALLDEPTH</code> should return the remaining call stack depth. A value of <code>0</code> means that the call stack is exhausted, and no further calls can be made.</p> <h1 id="rationale">Rationale</h1> <p>The actual call stack depth, as well as the call stack depth limit, are present in the EVM during execution, but just not available within the EVM. The implementation should be fairly simple and would provide a cheap and way to protect against call stack attacks.</p> <h1 id="implementation">Implementation</h1> <p>Not implemented.</p> 2015-11-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/101/ <h3 id="specification">Specification</h3> <ol> <li>Accounts now have only two fields in their RLP encoding: <strong>code</strong> and <strong>storage</strong>.</li> <li>Ether is no longer stored in account objects directly; instead, at address <code>0</code>, we premine a contract which contains all ether holdings. The <code>eth.getBalance</code> command in web3 is remapped appropriately.</li> <li><code>msg.value</code> no longer exists as an opcode.</li> <li>A transaction now only has four fields: <strong>to</strong>, <strong>startgas</strong>, <strong>data</strong> and <strong>code</strong>.</li> <li>Aside from an RLP validity check, and checking that the <strong>to</strong> field is twenty bytes long, the <strong>startgas</strong> is an integer, and <strong>code</strong> is either empty or hashes to the <strong>to</strong> address, there are no other validity constraints; anything goes. However, the block gas limit remains, so miners are disincentivized from including junk.</li> <li>Gas is charged for bytes in <strong>code</strong> at the same rate as <strong>data</strong>.</li> <li>When a transaction is sent, if the receiving account does not yet exist, the account is created, and its code is set to the code provided in the transaction; otherwise the code is ignored.</li> <li>A <code>tx.gas</code> opcode is added alongside the existing <code>msg.gas</code> at index <code>0x5c</code>; this new opcode allows the transaction to access the original amount of gas allotted for the transaction</li> </ol> <p>Note that <code>ECRECOVER</code>, sequence number/nonce incrementing and ether are now nowhere in the bottom-level spec (NOTE: ether is going to continue to have a privileged role in Casper PoS). To replicate existing functionality under the new model, we do the following.</p> <p>Simple user accounts can have the following default standardized code:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> We assume that data takes the following schema:</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 0-31: v (ECDSA sig)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 32-63: r (ECDSA sig)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 64-95: s (ECDSA sig)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 96-127: sequence number (formerly called &quot;nonce&quot;)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 128-159: gasprice</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 172-191: to</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> bytes 192+: data</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Get the hash for transaction signing</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>mstore</span><span>(</span><span class="z-constant">0</span><span>,</span><span> msg</span><span>.</span><span>gas</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>calldatacopy</span><span>(</span><span class="z-constant">32</span><span>,</span><span class="z-constant"> 96</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 96</span><span>)</span></span> <span class="giallo-l"><span>h</span><span class="z-keyword"> =</span><span> sha3</span><span>(</span><span class="z-constant">96</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 96</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Call ECRECOVER contract to get the sender</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>call</span><span>(</span><span class="z-constant">5000</span><span>,</span><span class="z-constant"> 3</span><span>,</span><span> [</span><span>h</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">32</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">64</span><span>)</span><span>]</span><span>,</span><span class="z-constant"> 128</span><span>,</span><span> ref</span><span>(</span><span>addr</span><span>)</span><span>,</span><span class="z-constant"> 32</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Check sender correctness</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span> addr</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">82a978b3f5962a5b0957d9ee9eef472ee55b42f1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Check sequence number correctness</span></span> <span class="giallo-l"><span class="z-keyword">assert</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">96</span><span>)</span><span class="z-keyword"> ==</span><span class="z-variable z-language"> self</span><span>.</span><span>storage</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Increment sequence number</span></span> <span class="giallo-l"><span class="z-variable z-language">self</span><span>.</span><span>storage</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span><span class="z-keyword"> +=</span><span class="z-constant"> 1</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Make the sub-call and discard output</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>call</span><span>(</span><span>msg</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span class="z-constant"> 50000</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">160</span><span>)</span><span>,</span><span class="z-constant"> 192</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span class="z-keyword"> -</span><span class="z-constant"> 192</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment">#</span><span class="z-comment"> Pay for gas</span></span> <span class="giallo-l"><span class="z-keyword">~</span><span>call</span><span>(</span><span class="z-constant">40000</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span> [</span><span class="z-constant">SEND</span><span>,</span><span> block</span><span>.</span><span>coinbase</span><span>,</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">128</span><span>)</span><span class="z-keyword"> *</span><span> (</span><span>tx</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span> msg</span><span>.</span><span>gas</span><span class="z-keyword"> +</span><span class="z-constant"> 50000</span><span>)</span><span>]</span><span>,</span><span class="z-constant"> 96</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-constant"> 0</span><span>)</span></span></code></pre> <p>This essentially implements signature and nonce checking, and if both checks pass then it uses all remaining gas minus 50000 to send the actual desired call, and then finally pays for gas.</p> <p>Miners can follow the following algorithm upon receiving transactions:</p> <ol> <li>Run the code for a maximum of 50000 gas, stopping if they see an operation or call that threatens to go over this limit</li> <li>Upon seeing that operation, make sure that it leaves at least 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with <code>msg.gas - 50000</code> as its gas limit parameter)</li> <li>Pattern-match to make sure that gas payment code at the end is <em>exactly</em> the same as in the code above.</li> </ol> <p>This process ensures that miners <em>waste</em> at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, Lamport), ring signatures, quasi-native multisig, etc. Theoretically, one can even create an account for which the <em>valid signature</em> type is a valid Merkle branch of a receipt, creating a quasi-native alarm clock.</p> <p>If someone wants to send a transaction with nonzero value, instead of the current <code>msg.sender</code> approach, we compile into a three step process:</p> <ol> <li>In the outer scope just before calling, call the ether contract to create a cheque for the desired amount</li> <li>In the inner scope, if a contract uses the <code>msg.value</code> opcode anywhere in the function that is being called, then we have the contract cash out the cheque at the start of the function call and store the amount cashed out in a standardized address in memory</li> <li>In the outer scope just after calling, send a message to the ether contract to disable the cheque if it has not yet been cashed</li> </ol> <h3 id="rationale">Rationale</h3> <p>This allows for a large increase in generality, particularly in a few areas:</p> <ol> <li>Cryptographic algorithms used to secure accounts (we could reasonably say that Ethereum is quantum-safe, as one is perfectly free to secure one's account with Lamport signatures). The nonce-incrementing approach is now also open to revision on the part of account holders, allowing for experimentation in k-parallelizable nonce techniques, UTXO schemes, etc.</li> <li>Moving ether up a level of abstraction, with the particular benefit of allowing ether and sub-tokens to be treated similarly by contracts</li> <li>Reducing the level of indirection required for custom-policy accounts such as multisigs</li> </ol> <p>It also substantially simplifies and <em>purifies</em> the underlying Ethereum protocol, reducing the minimal consensus implementation complexity.</p> <h3 id="implementation">Implementation</h3> <p>Coming soon.</p> 2015-11-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/2/ <h3 id="meta-reference">Meta reference</h3> <p><a href="https://wg-eips.ritovision.com/606/">Homestead</a>.</p> <h3 id="parameters">Parameters</h3> <table><thead><tr><th>FORK_BLKNUM</th><th>CHAIN_NAME</th></tr></thead><tbody> <tr><td>1,150,000</td><td>Main net</td></tr> <tr><td>494,000</td><td>Morden</td></tr> <tr><td>0</td><td>Future testnets</td></tr> </tbody></table> <h1 id="specification">Specification</h1> <p>If <code>block.number &gt;= HOMESTEAD_FORK_BLKNUM</code>, do the following:</p> <ol> <li>The gas cost <em>for creating contracts via a transaction</em> is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the <code>CREATE</code> opcode is unaffected.</li> <li>All transaction signatures whose s-value is greater than <code>secp256k1n/2</code> are now considered invalid. The ECDSA recover precompiled contract remains unchanged and will keep accepting high s-values; this is useful e.g. if a contract recovers old Bitcoin signatures.</li> <li>If contract creation does not have enough gas to pay for the final gas fee for adding the contract code to the state, the contract creation fails (i.e. goes out-of-gas) rather than leaving an empty contract.</li> <li>Change the difficulty adjustment algorithm from the current formula: <code>block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp &lt; 13 else -1) + int(2**((block.number // 100000) - 2))</code> (where the <code>int(2**((block.number // 100000) - 2))</code> represents the exponential difficulty adjustment component) to <code>block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2))</code>, where <code>//</code> is the integer division operator, eg. <code>6 // 2 = 3</code>, <code>7 // 2 = 3</code>, <code>8 // 2 = 4</code>. The <code>minDifficulty</code> still defines the minimum difficulty allowed and no adjustment may take it below this.</li> </ol> <h1 id="rationale">Rationale</h1> <p>Currently, there is an excess incentive to create contracts via transactions, where the cost is 21,000, rather than contracts, where the cost is 32,000. Additionally, with the help of suicide refunds, it is currently possible to make a simple ether value transfer using only 11,664 gas; the code for doing this is as follows:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">from</span><span> ethereum</span><span class="z-keyword"> import</span><span> tester</span><span class="z-keyword"> as</span><span> t</span></span> <span class="giallo-l"><span class="z-keyword">&gt;</span><span class="z-keyword"> from</span><span> ethereum</span><span class="z-keyword"> import</span><span> utils</span></span> <span class="giallo-l"><span class="z-keyword">&gt;</span><span> s</span><span class="z-keyword"> =</span><span> t</span><span>.</span><span>state</span><span>(</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">&gt;</span><span> c</span><span class="z-keyword"> =</span><span> s</span><span>.</span><span>abi_contract</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">def init():</span><span class="z-constant">\n</span><span class="z-string"> suicide(0x47e25df8822538a8596b28c637896b4d143c351e)</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-variable"> endowment</span><span class="z-keyword">=</span><span class="z-constant">10</span><span class="z-keyword">**</span><span class="z-constant">15</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">&gt;</span><span> s</span><span>.</span><span>block</span><span>.</span><span>get_receipts</span><span>(</span><span>)</span><span>[</span><span class="z-keyword">-</span><span class="z-constant">1</span><span>]</span><span>.</span><span>gas_used</span></span> <span class="giallo-l"><span class="z-constant">11664</span></span> <span class="giallo-l"><span class="z-keyword">&gt;</span><span> s</span><span>.</span><span>block</span><span>.</span><span>get_balance</span><span>(</span><span>utils</span><span>.</span><span>normalize_address</span><span>(</span><span class="z-storage z-type">0x</span><span class="z-constant">47e25df8822538a8596b28c637896b4d143c351e</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-constant">1000000000000000</span></span></code></pre> <p>This is not a particularly serious problem, but it is nevertheless arguably a bug.</p> <p>Allowing transactions with any s value with <code>0 &lt; s &lt; secp256k1n</code>, as is currently the case, opens a transaction malleability concern, as one can take any transaction, flip the s value from <code>s</code> to <code>secp256k1n - s</code>, flip the v value (<code>27 -&gt; 28</code>, <code>28 -&gt; 27</code>), and the resulting signature would still be valid. This is not a serious security flaw, especially since Ethereum uses addresses and not transaction hashes as the input to an ether value transfer or other transaction, but it nevertheless creates a UI inconvenience as an attacker can cause the transaction that gets confirmed in a block to have a different hash from the transaction that any user sends, interfering with user interfaces that use transaction hashes as tracking IDs. Preventing high s values removes this problem.</p> <p>Making contract creation go out-of-gas if there is not enough gas to pay for the final gas fee has the benefits that:</p> <ul> <li>(i) it creates a more intuitive "success or fail" distinction in the result of a contract creation process, rather than the current "success, fail, or empty contract" trichotomy;</li> <li>(ii) makes failures more easily detectable, as unless contract creation fully succeeds then no contract account will be created at all; and</li> <li>(iii) makes contract creation safer in the case where there is an endowment, as there is a guarantee that either the entire initiation process happens or the transaction fails and the endowment is refunded.</li> </ul> <p>The difficulty adjustment change conclusively solves a problem that the Ethereum protocol saw two months ago where an excessive number of miners were mining blocks that contain a timestamp equal to <code>parent_timestamp + 1</code>; this skewed the block time distribution, and so the current block time algorithm, which targets a <em>median</em> of 13 seconds, continued to target the same median but the mean started increasing. If 51% of miners had started mining blocks in this way, the mean would have increased to infinity. The proposed new formula is roughly based on targeting the mean; one can prove that with the formula in use, an average block time longer than 24 seconds is mathematically impossible in the long term.</p> <p>The use of <code>(block_timestamp - parent_timestamp) // 10</code> as the main input variable rather than the time difference directly serves to maintain the coarse-grained nature of the algorithm, preventing an excessive incentive to set the timestamp difference to exactly 1 in order to create a block that has slightly higher difficulty and that will thus be guaranteed to beat out any possible forks. The cap of -99 simply serves to ensure that the difficulty does not fall extremely far if two blocks happen to be very far apart in time due to a client security bug or other black-swan issue.</p> <h1 id="implementation">Implementation</h1> <p>This is implemented in Python here:</p> <ol> <li>https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L130</li> <li>https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L129</li> <li>https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L304</li> <li>https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/blocks.py#L42</li> </ol> 2015-11-15T00:00:00+00:00 2026-02-11T14:49:27+00:00 Vitalik Buterinhttps://github.com/vbuterin https://wg-eips.ritovision.com/7/ <h3 id="hard-fork">Hard Fork</h3> <p><a href="https://wg-eips.ritovision.com/606/">Homestead</a></p> <h3 id="parameters">Parameters</h3> <ul> <li>Activation: <ul> <li>Block &gt;= 1,150,000 on Mainnet</li> <li>Block &gt;= 494,000 on Morden</li> <li>Block &gt;= 0 on future testnets</li> </ul> </li> </ul> <h3 id="overview">Overview</h3> <p>Add a new opcode, <code>DELEGATECALL</code> at <code>0xf4</code>, which is similar in idea to <code>CALLCODE</code>, except that it propagates the sender and value from the parent scope to the child scope, i.e. the call created has the same sender and value as the original call.</p> <h3 id="specification">Specification</h3> <p><code>DELEGATECALL</code>: <code>0xf4</code>, takes 6 operands:</p> <ul> <li><code>gas</code>: the amount of gas the code may use in order to execute;</li> <li><code>to</code>: the destination address whose code is to be executed;</li> <li><code>in_offset</code>: the offset into memory of the input;</li> <li><code>in_size</code>: the size of the input in bytes;</li> <li><code>out_offset</code>: the offset into memory of the output;</li> <li><code>out_size</code>: the size of the scratch pad for the output.</li> </ul> <h4 id="notes-on-gas">Notes on gas</h4> <ul> <li>The basic stipend is not given; <code>gas</code> is the total amount the callee receives.</li> <li>Like <code>CALLCODE</code>, account creation never happens, so the upfront gas cost is always <code>schedule.callGas</code> + <code>gas</code>.</li> <li>Unused gas is refunded as normal.</li> </ul> <h4 id="notes-on-sender">Notes on sender</h4> <ul> <li><code>CALLER</code> and <code>VALUE</code> behave exactly in the callee's environment as they do in the caller's environment.</li> </ul> <h4 id="other-notes">Other notes</h4> <ul> <li>The depth limit of 1024 is still preserved as normal.</li> </ul> <h3 id="rationale">Rationale</h3> <p>Propagating the sender and value from the parent scope to the child scope makes it much easier for a contract to store another address as a mutable source of code and ''pass through'' calls to it, as the child code would execute in essentially the same environment (except for reduced gas and increased callstack depth) as the parent.</p> <p>Use case 1: split code to get around 3m gas barrier</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">~</span><span>calldatacopy</span><span>(</span><span class="z-constant">0</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">253</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span>delegate_call</span><span>(</span><span>msg</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span class="z-constant"> 10000</span><span>,</span><span class="z-invalid z-illegal"> $</span><span class="z-constant">ADDR1</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span class="z-keyword">return</span><span>(</span><span class="z-keyword">~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">elif</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> &lt;</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">253</span><span class="z-keyword"> *</span><span class="z-constant"> 2</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span>delegate_call</span><span>(</span><span>msg</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span class="z-constant"> 10000</span><span>,</span><span class="z-invalid z-illegal"> $</span><span class="z-constant">ADDR2</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span class="z-keyword">return</span><span>(</span><span class="z-keyword">~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span> <span class="giallo-l"><span class="z-constant">...</span></span></code></pre> <p>Use case 2: mutable address for storing the code of a contract:</p> <pre class="giallo z-code"><code data-lang="python"><span class="giallo-l"><span class="z-keyword">if</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">0</span><span>)</span><span class="z-keyword"> /</span><span class="z-constant"> 2</span><span class="z-keyword">**</span><span class="z-constant">224</span><span class="z-keyword"> ==</span><span class="z-storage z-type"> 0x</span><span class="z-constant">12345678</span><span class="z-keyword"> and</span><span class="z-variable z-language"> self</span><span>.</span><span>owner</span><span class="z-keyword"> ==</span><span> msg</span><span>.</span><span>sender</span><span>:</span></span> <span class="giallo-l"><span class="z-variable z-language"> self</span><span>.</span><span>delegate</span><span class="z-keyword"> =</span><span class="z-keyword"> ~</span><span>calldataload</span><span>(</span><span class="z-constant">4</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword">else</span><span>:</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span>delegate_call</span><span>(</span><span>msg</span><span>.</span><span>gas</span><span class="z-keyword"> -</span><span class="z-constant"> 10000</span><span>,</span><span class="z-variable z-language"> self</span><span>.</span><span>delegate</span><span>,</span><span class="z-constant"> 0</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-keyword"> ~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span> <span class="giallo-l"><span class="z-keyword"> ~</span><span class="z-keyword">return</span><span>(</span><span class="z-keyword">~</span><span>calldatasize</span><span>(</span><span>)</span><span>,</span><span class="z-constant"> 10000</span><span>)</span></span></code></pre> <p>The child functions called by these methods can now freely reference <code>msg.sender</code> and <code>msg.value</code>.</p> <h3 id="possible-arguments-against">Possible arguments against</h3> <ul> <li>You can replicate this functionality by just sticking the sender into the first twenty bytes of the call data. However, this would mean that code would need to be specially compiled for delegated contracts, and would not be usable in delegated and raw contexts at the same time.</li> </ul>