Ethereum Improvement Proposals - Informational

Genesis File Format

2025-05-19T00:00:00+00:00

Abstract</h2>
This EIP defines a canonical structure for Ethereum genesis files (`genesis.json</code>) used to bootstrap Ethereum networks. The standard aligns with the de facto structure implemented by Geth (Go-Ethereum), and already adopted by other clients. It introduces a JSON Schema to ensure consistency and tool compatibility across clients.</p>`

Motivation</h2>
The lack of an official standard for the genesis.json</code> file has led to incompatibilities, bugs and confusion, as well as added workload for those running multiple clients together in test networks. This EIP aims to reduce ambiguity by defining a consistent structure and enabling tooling through schema-based validation.</p>
Specification</h2>
The canonical genesis file MUST be a JSON object with the following top-level fields:</p>
Top-Level Fields</h3>
Field</th> Type</th> Description</th> Example</th></tr></thead>

config</code></td> Object</td> Chain configuration object.</td> (see below)</td></tr>
alloc</code></td> Object</td> Map of addresses to pre-allocated balances and/or code/storage.</td> (see below)</td></tr>
nonce</code></td> String</td> Block nonce as a hex string.</td> 0x0</code></td></tr>
timestamp</code></td> String</td> UNIX timestamp as a hex string.</td> 0x6720f180</code></td></tr>
extraData</code></td> String</td> Arbitrary extra data as hex string.</td> 0x00</code></td></tr>
gasLimit</code></td> String</td> Block gas limit as a hex string.</td> 0x1c9c380</code></td></tr>
difficulty</code></td> String</td> Block difficulty as a hex string.</td> 0x1</code></td></tr>
mixhash</code></td> String</td> Mix hash as a hex string.</td> 0x0000000000000000000000000000000000000000000000000000000000000000</code></td></tr>
coinbase</code></td> String</td> Coinbase address as a hex string.</td> 0x0000000000000000000000000000000000000000</code></td></tr>
</tbody></table>
config</code> Object</h3>
The config</code> object contains hardfork activation block numbers and fork configurations. Known keys include:</p>
Field</th> Type</th> Description</th> Example</th></tr></thead>

chainId</code></td> Integer</td> Unique identifier for the blockchain as a decimal integer.</td> 1</code> (mainnet)</td></tr>
<hardfork(Block|Time)></code></td> Integer</td> Block height or timestamp to activate the named hardfork as a decimal integer.</td> shanghaiTime: 1681338455</code></td></tr>
terminalTotalDifficulty</code></td> String</td> Total difficulty after which to switch from PoW to PoS as a hex string.</td> 0xc70d815d562d3cfa955</code></td></tr>
depositContractAddress</code></td> String</td> Ethereum address for the deposit contract as a hex string.</td> 0x00000000219ab540356cBB839Cbe05303d7705Fa</code></td></tr>
blobSchedule</code></td> Object</td> Map of hardforks and their EIP-4844 DAS configuration parameters</a>.</td> (see below)</td></tr>
</tbody></table>
blobSchedule</code> Object</h3>
Field</th> Type</th> Description</th> Example</th></tr></thead>

target</code></td> Integer</td> Desired number of blobs to include per block as a decimal integer.</td> 3</code></td></tr>
max</code></td> Integer</td> Maximum number of blobs to include per block as a decimal integer.</td> 6</code></td></tr>
baseFeeUpdateFraction</code></td> Integer</td> Input to pricing formula per EIP-4844 as a decimal integer.</td> 3338477</code></td></tr>
</tbody></table>
alloc</code> Object</h3>
The alloc</code> field defines the initial state at genesis. It maps addresses (as hex strings) to the following object:</p>
Field</th> Type</th> Description</th> Example</th></tr></thead>

balance</code></td> String</td> Account balance in wei as a hex string.</td> 0xde0b6b3a7640000</code> (1 ETH)</td></tr>
code</code></td> String</td> EVM bytecode as a hex string.</td> 0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000</code></td></tr>
nonce</code></td> String</td> Account nonce as a hex string.</td> 0x0</code></td></tr>
storage</code></td> Object</td> Key-value map where keys and values are 32-byte hex strings representing storage slots.</td> "0x0000000000000000000000000000000000000000000000000000000000000001": "0x00000000000000000000000000000000000000000000000000000000000000ff"</code></td></tr>
</tbody></table>
JSON Schema</h3>
</span>
{</span></span>
  "</span>$schema</span>"</span>:</span> "</span>http://json-schema.org/draft-07/schema#</span>"</span>,</span></span>
  "</span>$defs</span>"</span>:</span> {</span></span>
    "</span>hexUint</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>pattern</span>"</span>:</span> "</span>^0x[0-9a-fA-F]+$</span>"</span></span>
    }</span>,</span></span>
    "</span>address</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>pattern</span>"</span>:</span> "</span>^0x[0-9a-fA-F]{40}$</span>"</span></span>
    }</span>,</span></span>
    "</span>hash</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>pattern</span>"</span>:</span> "</span>^0x[0-9a-f]{64}$</span>"</span></span>
    }</span></span>
  }</span>,</span></span>
  "</span>title</span>"</span>:</span> "</span>Ethereum Genesis File</span>"</span>,</span></span>
  "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
  "</span>required</span>"</span>:</span> [</span>"</span>alloc</span>"</span>,</span> "</span>gasLimit</span>"</span>,</span> "</span>difficulty</span>"</span>]</span>,</span></span>
  "</span>properties</span>"</span>:</span> {</span></span>
    "</span>config</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
      "</span>properties</span>"</span>:</span> {</span></span>
        "</span>chainId</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>homesteadBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>daoForkBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>eip150Block</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>tangerineWhistleBlock</span>"</span>:</span> {</span>"</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>eip155Block</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>spuriousDragonBlock</span>"</span>:</span> {</span>"</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>byzantiumBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>constantinopleBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>petersburgBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>istanbulBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>muirGlacierBlock</span>"</span>:</span> {</span>"</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>berlinBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>londonBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>arrowGlacierBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>grayGlacierBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
        "</span>terminalTotalDifficulty</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
        "</span>mergeNetsplitBlock</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>shanghaiTime</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>cancunTime</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>pragueTime</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>osakaTime</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span>}</span>,</span></span>
        "</span>depositContractAddress</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/address</span>"</span>}</span>,</span></span>
        "</span>blobSchedule</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
          "</span>additionalProperties</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
            "</span>properties</span>"</span>:</span> {</span></span>
              "</span>target</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
              "</span>max</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>integer</span>"</span> }</span>,</span></span>
              "</span>baseFeeUpdateFraction</span>"</span>:</span> {</span> "</span>type</span>"</span> :</span> "</span>integer</span>"</span> }</span></span>
            }</span></span>
          }</span></span>
        }</span></span>
      }</span>,</span></span>
      "</span>additionalProperties</span>"</span>:</span> true</span></span>
    }</span>,</span></span>
    "</span>nonce</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
    "</span>timestamp</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
    "</span>extraData</span>"</span>:</span> {</span></span>
      "</span>anyOf</span>"</span>:</span> [</span></span>
        {</span>"</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span> "</span>const</span>"</span>:</span> "</span>"</span> }</span>,</span></span>
        {</span>"</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span> "</span>pattern</span>"</span>:</span> "</span>^0x([0-9a-fA-F]{2})*$</span>"</span> }</span></span>
      ]</span></span>
    }</span>,</span></span>
    "</span>gasLimit</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
    "</span>difficulty</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
    "</span>mixhash</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hash</span>"</span> }</span>,</span></span>
    "</span>coinbase</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/address</span>"</span> }</span>,</span></span>
    "</span>alloc</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
      "</span>patternProperties</span>"</span>:</span> {</span></span>
        "</span>^0x[0-9a-fA-F]{40}$</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
          "</span>properties</span>"</span>:</span> {</span></span>
            "</span>balance</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
            "</span>nonce</span>"</span>:</span> {</span> "</span>$ref</span>"</span>:</span> "</span>#/$defs/hexUint</span>"</span> }</span>,</span></span>
            "</span>code</span>"</span>:</span> {</span> "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span> "</span>pattern</span>"</span>:</span> "</span>^0x([0-9a-f])*$</span>"</span> }</span>,</span></span>
            "</span>storage</span>"</span>:</span> {</span></span>
              "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
              "</span>patternProperties</span>"</span>:</span> {</span></span>
                "</span>^0x[0-9a-f]{64}$</span>"</span>:</span> {</span></span>
                  "</span>$ref</span>"</span>:</span> "</span>#/$defs/hash</span>"</span></span>
                }</span></span>
              }</span></span>
            }</span></span>
          }</span></span>
        }</span>,</span></span>
        "</span>additionalProperties</span>"</span>:</span> false</span></span>
      }</span>,</span></span>
      "</span>additionalProperties</span>"</span>:</span> false</span></span>
    }</span></span>
  }</span>,</span></span>
  "</span>additionalProperties</span>"</span>:</span> true</span></span>
}</span></span>
</span></code></pre>Rationale</h2>
There are a growing number of EIPs that propose improvements to how a network is configured at genesis:</p>
Add Blob Schedule to EL Config File</a></p>
Blob Parameter Only Hardforks</a></p>
eth_config JSON-RPC method</a></p>
However, the root configuration element amended by these remains unspecified. Adopting a minimal schema to define that will make subsequent changes more accurate and concise.</p>
Security Considerations</h2>
Since this is an optional and informational EIP, which offers only developer convenience, and must be used with admin access to the node, no new security concerns are introduced.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Ethereum Shah
2025-04-28T00:00:00+00:00
Abstract</h2>
Ethereum needs a Shah. The role of the Shah is to be the "protector". A Shah, empowered by the community and with a mandate to represent their interests, could solve the communication gaps between the Ethereum community and core devs, represent the interests of the Ethereum community (holders, stakers, app devs & businesses especially) to the core devs with a tighter feedback loop, and eventually dissolve their position when the imminent danger of Ethereum coordination failure is meaningfully addressed.</p>
Motivation</h2>
It is clear from recent events that Ethereum is suffering from a coordination breakdown between the user ecosystem and the core devs. A case in point is the EOF debacle, with years wasted in EOF development that seems ultimately likely to be</del> was just rejected as a result of 1) fragmented communication between researchers/core devs and the greater Ethereum ecosystem, to the extent that even tentative supporters of EOF weren't aware of the toolchain update requirements on the rest of the ecosystem as well as 2) a lack of rigorous compatibility testing such that EOF exposes protocol level risks.</p>
A Shah is of course centralized, but we've seen the decentralized alternative: First a tacit acceptance of a seemingly unnecessary EIP involving years of labor, approved by committee, and ultimately rejected by the Ethereum community. The costs on our collective time are large, not to mention the opportunity cost.</p>
Ethereum could spare itself these inefficiencies by electing a Shah to manage the core dev roadmap and EIPs.</p>
Specification</h2>
The Shah SHOULD be elected by the Ethereum community, using a combination of ETH voting, social signalling, and core dev ratification.</p>
The Shah SHOULD be singularly responsible for deciding on the EIP inclusion roadmap, as well as having veto power over which EIPs to include.</p>
The Shah SHOULD maintain communication channels with the Ethereum community (holders, stakers, app devs & businesses) to understand their needs & request feedback on EIPs.</p>
The Shah SHOULD play a coordinator role in the All Core Devs (ACD) calls, and submit a quarterly progress update to Ethereum stakeholders.</p>
The Shah SHOULD NOT have any special privileges, for example: to relieve developers of duty at organizations not under the Shah's control.</p>
The Shah SHOULD explicitly call out blockers, communications breakdowns, and when deserving, the core devs that get in the way of addressing them.</p>
The Shah SHOULD NOT report to the Ethereum Foundation. The Shah's position would be paid directly from the most credibly "Ethereum" source of funding, which has received its budget from a diverse set of Ethereum community members: The Protocol Guild.</p>
The Shah SHOULD have an expiration date for their role set at the time of election, that does exceed 2 years.</p>
The Shah SHOULD be able to step down willingly before the end of their 2 year term.</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>
Rationale</h2>
During times of war, the Roman Senate would elect an "Imperator" that would be responsible for dealing with an imminent threat, and once the threat was dealt with, would abdicate their power. The Shah is a similar concept, but rooted in the culture of the Persian Empire, which pioneered a "pluralistic" multi-national empire that respected cultural and religious diversity of its member nations—as aligned with Ethereum's culture of pluralism today.</p>
This EIP is largely inspired by Greg the Greek's post (below) about the EF core devs lacking strong leadership who can take responsibility for saying "NO" to EIPs that they expect will ultimately be defeated by community consensus, and thus saving everyone their time, effort, and mental health. The Greeks pioneered democracy—if the will of the people is to elect (even for a limited time) a strong leader, would it not be undemocratic to deny it?</p>
Link: x (dot) com/gregthegreek/status/1914811701901623746</p>

All Core Devs need to centralize.
They need a leader who will say, NO.
They need to be told what not to do.
They need someone to shield them.</p>
</p>
Story Time</p>
I vividly remember hearing about EOF 4-5 years ago</p>
I asked a simple question:
Q: How does this benefit users interacting with the chain?
A: It allows future implementations of the EVM to add those things!</p>
👎</p>
Cold, hard truth. Engineers are trying to solve a problem because it's fun, not because it's needed. It has some long-tail benefits, but not enough to justify the pain that it will cause.</p>
This is a full-blown toolchain update (almost). We need to prioritize things that provide incremental wins. If the team behind EOF had spent more time improving the EVM in incremental steps (ditching EOF altogether), they could have shipped so much more, which could have, in aggregate, contributed to a 10x improvement.</p>
Instead, they continue to fight for a proposal that was shot down ~3 times?</p>
What has EOF done?</p>

Distracted ACD for the 4th time</li>
Delaying roadmap by jamming a MASSIVE change into core code</li>
Distract @ethPandaOps who will inevitably be responsible for creating an ungodly testing framework for this change</li>
Caused ProgPow level wars because they can't take "no" for an answer</li>
</ul>
ONE YEAR AGO in Brussels, I asked Marius "How's work?" and he responded:</p>

The EOF folks are back, the proposal is bigger than before.</p>
</blockquote>
ONE YEAR AGO - does no one see the problem here?</p>
@tkstanczak @hwwonx This is the hardest role to hire for, but it needs to be done. That or one of you will need to step up and actually own this. It's clear @VitalikButerin, and we shouldn't force him to, he's better on the research side. Someone needs to run DAY-To-DAY ops/product on ACD.</p>
It's exhausting.
Let the devs ship.
Stop the politics.
Turn the ship around.</p>
Please 💕</p>
</blockquote>
The role of the Shah would be primarily social, and they would not have any formal</em> power. Their power solely comes from the belief that the community has in their power. In the context of steering the ACD calls & EIP inclusion roadmap, this is actually enough. In my personal experience helping kill ProgPow, the core devs were not convinced that I adequately represented enough of the Ethereum community (despite my position as the Summoner of MolochDAO) and it took Martin Koeppelman & several others to step forward to socially signal against ProgPow and ultimately join the ACD meeting to advocate against it in order to finally convince the core devs that ProgPow was against the interest of the greater Ethereum community. The role of the Shah can help short-circuit this suspicion from the core devs by having the default understanding be that the Shah does in fact represent the will of the greater Ethereum community.</p>
In his post a few weeks ago, Tim Beiko (the current Ethereum Hard Fork Coordinator) also suggested that the ACD was missing the roadmapping role this EIP proposes to be coordinated by the Shah.</p>

Roadmap Setting</strong>
The most important missing piece in the current AllCoreDevs process is a focus on the high level roadmap (“why we do things”), rather than individual proposals (“what we do”). This is true both for when planning the next fork(s), but also when thinking about Ethereum’s longer-term direction.</p>
</blockquote>
Link: ethereum-magicians (dot) org/t/reconfiguring-allcoredevs/23370</p>
Security Considerations</h2>
The obvious risk of having a Shah is that they could veto EIPs that are</em> actually aligned with the Ethereum community stakeholders or prioritize EIPs that are not. In this case, it is the role of the community to publicly dissent from the Shah and ultimately remove them from office. I would expect that long before the Shah was officially deposed, the all core devs would start ignoring the Shah's input anyway, as the position does not hold any formal power. I think a fair minimum term would be 6 months (for there to be two quarterly reports at least) and with at least the same degree of community consensus around deposing the Shah as there was to enshrine them in the first place.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Exponential Gas Limit Increase
2025-04-27T00:00:00+00:00
Abstract</h2>
This proposal introduces a deterministic gas limit growth schedule via client-side defaults. Ethereum clients will vote to increase the gas limit according to an exponential schedule unless explicitly configured otherwise by the user. The gas limit increase occurs every beacon chain epoch, aligned to a factor-of-10 increase every approximately 164,250 epochs (2 years). It will stop after 4 years when an updated gas increase schedule should be decided and committed to.</p>
Motivation</h2>
The current gas limit mechanism relies on miner/operator voting, which lacks coordination and predictability. While flexible, this approach can lead to stagnation or overly cautious increases. By introducing a predictable exponential growth pattern as a client default, this EIP encourages a sustainable and transparent gas limit trajectory, aligned with expected advancements in hardware and protocol efficiency.</p>
Specification</h2>
Schedule</h3>
Let G0 = 50,000,000</code> be the gas limit at the activation epoch. Let the activation epoch be Ethereum beacon chain epoch 369017</strong>, which corresponds to approximately June 1, 2025.</p>
Let t</code> be the current beacon chain epoch and t0 = 369017</code> be the activation epoch.
Let T = 164,250</code> be the number of epochs for a 10x increase.</p>
The gas limit at epoch t</code> is calculated as follows:</p>
G(t) = {</span></span>
    current default limit, if t < t0</span></span>
    round(G0 * 10^((t-t0)/T)), if t0 ≤ t ≤ t0 + 2*T</span></span>
    100 * G0, if t > t0 + 2*T</span></span>
}</span></span></code></pre>
round</code> should round to the next integer.</p>
Client Behavior</h3>

At the start of each new beacon chain epoch, the default gas limit vote is recalculated using the formula above.</li>
Clients automatically vote for the calculated gas limit using the existing gas voting mechanism.</li>
Users can override this default by setting a manual gas limit policy in client configuration.</li>
</ul>
Activation</h3>

Activation is at Ethereum beacon chain epoch 369017.</li>
</ul>
Rationale</h2>
This EIP maintains Ethereum's current gas voting mechanism but enhances it with a predictable and community-coordinated trajectory. By distributing responsibility across clients rather than enforcing protocol changes via consensus rules, this proposal offers flexibility while encouraging scalability.</p>
The exponential growth model ensures gradual but significant increases, allowing the network to adapt while targeting ambitious throughput goals.</p>
Backwards Compatibility</h2>
The change is non-consensus and backward compatible. Clients not implementing the EIP will continue to behave as before. Only the default behavior changes; manual configuration remains supported.</p>
Security Considerations</h2>
A rapid increase in the gas limit may stress less-optimized nodes and increase block propagation times. However, the exponential schedule with very gradual increments per epoch gives node operators and developers ample time to adapt and optimize.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Set default gas limit to 60M
2025-04-22T00:00:00+00:00
Abstract</h2>
The gas limit on mainnet is currently 36M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.</p>
Motivation</h2>
There is currently great interest in scaling L1 execution. This can likely be done to some extent without implementing any new features. However, it requires guidance from EL devs as we expect to find bugs in clients at higher gas limits than currently used on mainnet. This will require time from client developers both to test and to fix any bugs that arise, therefore it makes sense to include as an EIP in a hard fork to commit to this.</p>
Specification</h2>
Execution layer clients have different configuration formats. They should all update the gas limit value generated in their default configurations to 60M.</p>
Rationale</h2>
In the past there has been some difficulty coordinating EL clients to update gas limit values in their default configurations. Therefore we suggest tying a new value to a hard fork release.</p>
Backwards Compatibility</h2>
A higher gas limit should not break any existing contracts. It is possible that with a higher limit new transactions could exceed the proposed 30M transaction gas limit, so the scheduling of these two EIPs should be coordinated.</p>
Security Considerations</h2>
Devnets will be stood up with nodes running all combinations of EL and CL clients in order to test if a gas limit of 60M is safe. Synthetic transactions will be created until blocks are full, and network and node health monitored. If bugs are discovered, client teams will patch them and then start the process again. If everything looks good, the gas limit will be increased incrementally.</p>
Adversarial block constructions that would increase the worst-case size have already been researched and should not be a factor below 150M gas because this is close to where the current worst-case block size of 1.79 MiB would reach the current 10MiB CL gossip limit.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Blob Parameter Only Hardforks
2025-02-28T00:00:00+00:00
Abstract</h2>
This EIP introduces Blob Parameter Only (BPO) Hardforks</strong>, a lightweight mechanism for incrementally scaling Ethereum’s blob capacity through targeted hard forks that modify only blob-related parameters: target</code>, max</code>, and baseFeeUpdateFraction</code>. Unlike traditional hard forks, which require extensive coordination and introduce broader protocol changes, BPO forks enable rapid, low-overhead scaling of blob capacity in response to real-world demand and network conditions</strong>.</p>
Motivation</h2>
Ethereum's scaling strategy relies on Layer 2 (L2) solutions for transaction execution while using Ethereum as a data availability (DA) layer</strong>. However, the demand for DA has increased rapidly, and the current approach of only modifying blob parameters in large, infrequent hard forks is not agile enough</strong> to keep up with L2 growth.</p>
The key motivations for BPO forks are as follows:</p>


Continuous Scaling</strong></p>

L2 DA demand is growing rapidly, leading to ongoing saturation of blob capacity.</li>
Large, infrequent blob parameter changes create high costs and inefficiencies.</li>
BPO forks allow for more frequent, safer capacity increases.</li>
</ul>
</li>

Reduced Operational Overhead</strong></p>

Performance improvements and further testing will continue to unlock additional capacity.</li>
It is desirable to reduce the time between core devs agreeing on a parameter increase and its effective deployment.</li>
Full Ethereum hard forks require significant coordination, testing, and upgrade efforts across clients.</li>
By isolating blob parameter changes, BPO forks reduce the complexity of upgrades.</li>
</ul>
</li>

Enhanced Stability with New Scaling Technologies</strong></p>

Major scaling upgrades introduce uncertainty in optimal blob limits.</li>
Rather than forcing core developers to accept a suboptimal tradeoff between stability and capacity, BPO forks allow developers to safely increase parameters after observing mainnet performance and stability.</li>
</ul>
</li>

Predictable Upgrades for Builders</strong></p>

Builders and L2s require confidence that Ethereum will continuously scale to support their needs.</li>
A structured BPO framework provides predictability, allowing rollups to commit to Ethereum over alternative DA solutions.</li>
</ul>
</li>
</ol>
Specification</h2>
Definition</h3>
BPO hardforks are defined as protocol upgrades that modify only blob-related parameters through configuration, without requiring any client-side code changes. The new parameters take effect immediately at the specified activation time.</p>
Blob schedule configuration</h3>
The following protocol parameters are now managed by the blob schedule configuration:</p>

Blob Target (target</code>)</strong>: The expected number of blobs per block.</li>
Blob Limit (max</code>)</strong>: The maximum number of blobs per block.</li>
Blob Base Fee Update Fraction (baseFeeUpdateFraction</code>)</strong>: Determines how blob gas pricing adjusts per block.</li>
</ul>
To ensure consistency, when a regular hardfork changes any of these parameters, it MUST do so by adding an entry to the blob schedule configuration.</p>
Execution layer configuration</h3>
To facilitate these changes on the execution layer, each fork in the blobSchedule</code> object defined in EIP-7840</a> is linked to an activation timestamp via a top-level <fork_name>Time</code> field, which holds the Unix timestamp of the activation slot as a JSON number. BPO forks SHOULD be named using the convention bpo<index></code>, where <index></code> starts at 1</code>. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur after</strong> Prague.</p>
{</span></span>
  "</span>blobSchedule</span>"</span>:</span> {</span></span>
    "</span>cancun</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 3</span>,</span></span>
      "</span>max</span>"</span>:</span> 6</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span></span>
    }</span>,</span></span>
    "</span>prague</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 6</span>,</span></span>
      "</span>max</span>"</span>:</span> 9</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
    }</span>,</span></span>
    "</span>osaka</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 6</span>,</span></span>
      "</span>max</span>"</span>:</span> 9</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
    }</span>,</span></span>
    "</span>bpo1</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 10</span>,</span></span>
      "</span>max</span>"</span>:</span> 15</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 8346193</span></span>
    }</span>,</span></span>
    "</span>bpo2</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 14</span>,</span></span>
      "</span>max</span>"</span>:</span> 21</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 11684671</span></span>
    }</span></span>
  }</span>,</span></span>
  "</span>cancunTime</span>"</span>:</span> 0</span>,</span></span>
  "</span>pragueTime</span>"</span>:</span> 0</span>,</span></span>
  "</span>osakaTime</span>"</span>:</span> 1747387400</span>,</span></span>
  "</span>bpo1Time</span>"</span>:</span> 1757387400</span>,</span></span>
  "</span>bpo2Time</span>"</span>:</span> 1767387784</span></span>
}</span></span></code></pre>
Since there is no backporting, the values for cancunTime</code> and pragueTime</code> are set to 0. It should also be noted that the other parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.</p>
Blob base fee computations</h3>
We modify the functions get_base_fee_per_blob_gas</code> and calc_excess_blob_gas</code> defined in EIP-4844</a> to explicitly use the blob schedule.
In line with how updating BLOB_BASE_FEE_UPDATE_FRACTION</code> was handled in EIP-7691</a>, the functions use the current</em> block's blob schedule.
Moreover, TARGET_BLOB_GAS_PER_BLOCK</code> is removed and replaced with GAS_PER_BLOB * blob_schedule.target</code>, as it is now redundant.</p>
class</span> BlobSchedule</span>:</span></span>
   target</span>:</span> U64</span></span>
   max</span>:</span> U64</span></span>
   base_fee_update_fraction</span>:</span> Uint</span></span>
</span>
 def</span> calc_excess_blob_gas</span>(</span>parent</span>:</span> Header</span>,</span> blob_schedule</span>:</span> BlobSchedule</span>)</span> -></span> int</span>:</span></span>
    target_blob_gas</span> =</span> GAS_PER_BLOB</span> *</span> blob_schedule</span>.</span>target</span></span>
    if</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> <</span> target_blob_gas</span> :</span></span>
        return</span> 0</span></span>
    else</span>:</span></span>
        return</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> -</span> target_blob_gas</span></span>
</span>
def</span> get_base_fee_per_blob_gas</span>(</span>header</span>:</span> Header</span>,</span> blob_schedule</span>:</span> BlobSchedule</span>)</span> -></span> int</span>:</span></span>
    return</span> fake_exponential</span>(</span></span>
        MIN_BASE_FEE_PER_BLOB_GAS</span>,</span></span>
        header</span>.</span>excess_blob_gas</span>,</span></span>
        blob_schedule</span>.</span>base_fee_update_fraction</span></span>
    )</span></span></code></pre>Consensus layer configuration</h3>
A new BLOB_SCHEDULE</code> field is added to consensus layer configuration, containing a sequence of entries representing blob parameter changes after</strong> ELECTRA_FORK_EPOCH</code>. There exists one entry per fork that changes blob parameters, whether it is a regular or a Blob-Parameter-Only fork.</p>
B</span>LOB_SCHEDULE</span>:</span></span>
  -</span> E</span>POCH</span>:</span> 400000</span>     #</span> A future anonymous BPO fork</span></span>
    M</span>AX_BLOBS_PER_BLOCK</span>:</span> 15</span></span>
  -</span> E</span>POCH</span>:</span> 420000</span>     #</span> A future anonymous BPO fork</span></span>
    M</span>AX_BLOBS_PER_BLOCK</span>:</span> 21</span></span></code></pre>
The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.</p>
Requirements:</strong></p>

Execution and consensus clients MUST</strong> share consistent BPO fork schedules.</li>
The slot number in the EL's blobSchedule</code> MUST</strong> align with the start of the epoch specified in the consensus layer configuration.</li>
The max</code> field in the EL's blobSchedule</code> MUST</strong> equal the MAX_BLOBS_PER_BLOCK</code> value in the consensus layer configuration.</li>
</ul>
Modified compute_fork_digest</code></h3>
The compute_fork_digest</code> helper is updated to account for BPO forks:</p>
@</span>dataclass</span></span>
class</span> BlobScheduleEntry</span>:</span></span>
   epoch</span>:</span> Epoch</span></span>
   max_blobs_per_block</span>:</span> uint64</span>       #</span> Aligning with the type of MAX_BLOBS_PER_BLOCK</span></span>
</span>
def</span> compute_fork_digest</span>(</span></span>
  current_version</span>:</span> Version</span>,</span>       #</span> Unchanged; refers to the baseline hardfork atop which the blob schedule is applied</span></span>
  genesis_validators_root</span>:</span> Root</span>,</span>  #</span> Unchanged</span></span>
  current_epoch</span>:</span> Epoch</span>,</span>           #</span> New</span></span>
  blob_schedule</span>:</span> Sequence</span>[</span>BlobScheduleEntry</span>]</span>  #</span> New</span></span>
)</span> -></span> ForkDigest</span>:</span></span>
    """</span></span>
    Return the 4-byte fork digest for the ``current_version`` and ``genesis_validators_root``,</span></span>
    bitmasking blob parameters after ``ELECTRA_FORK_VERSION``.</span></span>
</span>
    This is a digest primarily used for domain separation on the p2p layer.</span></span>
    4-bytes suffices for practical separation of forks/chains.</span></span>
    """</span></span>
    base_digest</span> =</span> compute_fork_data_root</span>(</span>current_version</span>,</span> genesis_validators_root</span>)</span>[</span>:</span>4</span>]</span></span>
</span>
    #</span> Find the blob parameters applicable to this epoch.</span></span>
    sorted_schedule</span> =</span> sorted</span>(</span>blob_schedule</span>,</span> key</span>=</span>lambda</span> e</span>:</span> e</span>.</span>epoch</span>,</span> reverse</span>=</span>True</span>)</span></span>
    blob_params</span> =</span> None</span></span>
    for</span> entry</span> in</span> sorted_schedule</span>:</span></span>
      if</span> current_epoch</span> >=</span> entry</span>.</span>epoch</span>:</span></span>
        blob_params</span> =</span> entry</span></span>
        break</span></span>
</span>
    #</span> This check enables us to roll out the BPO mechanism without a concurrent parameter change.</span></span>
    if</span> blob_params</span> is</span> None</span>:</span></span>
      return</span> ForkDigest</span>(</span>base_digest</span>)</span></span>
</span>
    #</span> Safely bitmask blob parameters into the digest.</span></span>
    assert</span> 0</span> <=</span> blob_params</span>.</span>max_blobs_per_block</span> <=</span> 0x</span>FFFFFFFF</span></span>
    mask</span> =</span> blob_params</span>.</span>max_blobs_per_block</span>.</span>to_bytes</span>(</span>4</span>,</span> '</span>big</span>'</span>)</span></span>
    masked_digest</span> =</span> bytes</span>(</span>a</span> ^</span> b</span> for</span> a</span>,</span> b</span> in</span> zip</span>(</span>base_digest</span>,</span> mask</span>)</span>)</span></span>
    return</span> ForkDigest</span>(</span>masked_digest</span>)</span></span></code></pre>P2P Networking</h3>
ENR</h4>
In the consensus layer, ENRs are extended with an additional entry nfd</code>, short for "next fork digest". This field communicates the digest of the next scheduled fork, regardless of whether it is a regular or BPO fork. This approach is preferred over encoding BPO-specific parameters because it is agnostic to specific use cases and offers greater long-term flexibility.</p>
Key</th> Value</th></tr></thead>

nfd</code></td> SSZ Bytes4 ForkDigest</code></td></tr>
</tbody></table>
When discovering and interfacing with peers, nodes MUST evaluate nfd</code> alongside their existing consideration of the ENRForkID::next_*</code> fields under the eth2</code> key, to form a more accurate view of the peer's intended next fork.</p>
Status</code> req/resp</h4>
No changes are needed in this interaction, but it is noted that the response payload must correctly contain the updated fork_digest</code>.</p>
Gossip topics</h4>
No changes are required to topic structure or configuration. However, all topics will automatically rotate at a BPO fork due to changes in their ForkDigestValue</code> component.</p>
Rationale</h2>
Why not just use regular hardforks?</h3>
Full hard forks require extensive coordination, testing, and implementation changes beyond parameter adjustments. For example, in Lighthouse, a typical hard fork implementation requires thousands of lines of boilerplate before any protocol changes occur. BPO forks streamline this process by avoiding the need for this boilerplate code.</p>
Why specify parameters in the node configuration instead of code?</h3>
Allowing blob parameters to be configured externally enables rapid experimentation, testing, and adjustments without requiring code changes across client implementations. Testing teams can investigate different parameters with minimal involvement from client implementers.</p>
Why not create an on-chain voting mechanism for blob parameters?</h3>

Ethereum's recent gas limit increase to 36M took nearly a year to coordinate</li>
Blob capacity is a rapidly evolving, moving target that the wider staking community is not currently well equipped to track</li>
An on-chain mechanism would require much more extensive code changes, testing cycles, and debates about governance structures.</li>
BPO forks provide a simpler, more predictable approach while leaving room for future on-chain voting mechanisms when blob capacity stabilizes</li>
</ul>
Backwards Compatibility</h2>
BPO forks introduce no backwards compatibility concerns.</p>
Security Considerations</h2>
No security risks have been identified.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Hardware and Bandwidth Recommendations
2025-01-26T00:00:00+00:00
Abstract</h2>
This proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes:</p>

Full nodes</strong>: Nodes that follow the tip of the chain without necessarily proposing blocks.</li>
Validators</strong>: Split into:

Attesters</strong>: Validators that validate and attest to blocks created by proposers.</li>
Local block builders</strong> (Proposers): Validators that create blocks locally and broadcast them to the network.</li>
</ul>
</li>
</ul>
The resource-intensive aspect for local block builders lies in creating the block and quickly broadcasting the data required for attesters to validate it in time.</p>
We note that it may be possible to run a client with less than the recommended specifications, however benchmarks and decision-making will be made with respect to these recommendations.</p>
Motivation</h2>
Clear system specifications are crucial for:</p>

Ensuring meaningful benchmark comparisons across different client implementations.</li>
Enabling informed decision-making about protocol upgrades and their resource usage implications.</li>
Providing clear guidance for node operators to ensure alignment with future network requirements.</li>
</ul>
Without a shared understanding of target hardware specifications:</p>

Benchmark results lose significance due to inconsistent testing environments.</li>
Decision-making becomes challenging for implementation choices, as performance characteristics are heavily hardware-dependent.</li>
Network participants lack clear guidance for hardware investments.</li>
</ul>
Specification</h2>
Roles and Their Recommended Specifications</h3>
Node operators typically run both an Execution Layer (EL)</strong> client and a Consensus Layer (CL)</strong> client on the same machine. The specifications below assume the combined resource usage of both.</p>
Node Type</th> Storage</th> Memory</th> CPU Cores / Threads</th> PassMark CPU Rating</strong></th> Bandwidth Download / Upload</th></tr></thead>

Full Node</strong></td> 4 TB NVMe</td> 32 GB</td> 4c / 8t</td> ~1000 ST / 3000 MT</td> 50 Mbps / 15 Mbps</td></tr>
Attester</strong></td> 4 TB NVMe</td> 64 GB</td> 8c / 16t</td> ~3500 ST / 25000 MT</td> 50 Mbps / 25 Mbps</td></tr>
Local Block Builder</strong></td> 4 TB NVMe</td> 64 GB</td> 8c / 16t</td> ~3500 ST / 25000 MT</td> 100 Mbps / 50 Mbps</td></tr>
</tbody></table>
Approximate single-thread (ST) and multi-thread (MT) PassMark CPU scores. For example, a PassMark ST rating of 3500 and an MT rating of 25000 typically corresponds to upper mid-range server CPUs circa 2024–2025.</em></p>
Rationale</h2>
Storage</h3>

Recommended</strong>: 4 TB NVMe M.2 drive with:

Sequential R/W</strong>: 7,000 MB/s</li>
Random 4K R/W</strong>: Up to 1,000,000 IOPS</li>
</ul>
</li>
Why NVMe over SATA?</strong>

NVMe drives have significantly higher throughput and lower latency than SATA SSDs.</li>
Drives without DRAM (DRAMless) or with QLC flash are not advised, due to lower endurance and potentially lower sustained performance.</li>
</ul>
</li>
On Endurance (TBW)</strong>

Running a node involves frequent writes (e.g., database updates, logs). Ensure that the SSD’s Total Bytes Written (TBW) rating is sufficient for multi-year operation.</li>
</ul>
</li>
Capacity Considerations</strong>

As of January 2025, 2 TB can still work, but daily chain growth makes 4 TB more future-proof.</li>
While EIP-4444 aims to reduce historical storage requirements, the timeline for EIP-4444 remains uncertain.</li>
</ul>
</li>
</ul>
Memory</h3>

Why 64 GB for Validators (Attesters / Local Block Builders)?</strong>

Running an Ethereum validator (both EL & CL clients) can be memory-intensive, with state cache dominating RAM usage.</li>
Certain memory intensive client combinations have historically failed with 16 GB. It is possible to tune cache size in different clients to make it work, however we do not assume that the average user will do this.</li>
Preliminary benchmarks highlighting zk-STARK memory usage suggest cryptographic operations can demand significant RAM.</li>
Relative to total hardware costs, upgrading from 32 GB to 64 GB is a small price but can improve stability and is more future proof with regards to zk-STARKs.</li>
</ul>
</li>
</ul>
CPU</h3>

Single vs. Multi-thread Performance</strong>

Attesters and local block builders benefit from both high single-thread and multi-thread performance.</li>
</ul>
</li>
</ul>
Bandwidth</h3>
Local Block Builders</h4>

Recommended</strong>: 100 Mbps download, 50 Mbps upload.</li>
Rationale</strong>:

Distributing blocks is highly bandwidth-intensive.</li>
If a builder cannot meet these speeds, they risk slower propagation and causing late blocks.</li>
In extreme cases, a low-bandwidth node could propose partially full blocks or one that includes fewer blobs to mitigate slow broadcast.</li>
</ul>
</li>
</ul>
Attesters</h4>

Recommended</strong>: 50 Mbps download, 25 Mbps upload.</li>
Minimum tested</strong>: 15 Mbps (as per ethPandaOps simulations where 40% of the network had Gigabit connections and the other 60% had 15 Mbps upload).

However, real-world performance depends on peer network topology. A node with poor bandwidth could in theory quickly share data with a well-connected peer with good bandwidth which means that this peer could quickly seed the network.</li>
</ul>
</li>
Rationale</strong>:

25 Mbps was chosen as a buffer to account for these miscellaneous factors that are harder to predict.</li>
</ul>
</li>
</ul>
Validators Using MEV-Boost</h4>

Recommended</strong>: 50 Mbps download / 25 Mbps upload.</li>
Rationale</strong>:

Most MEV-relay interactions involve fetching bundles and block headers, which can be done within typical broadband speeds.</li>
While the local validator will also share the block with its peers, the relay will do the same which reduces the need for local bandwidth.</li>
However, there may be cases where your validator will still build a local block, such as if no MEV-relay responds or if the value of the MEV reward is lower than the minimum configuration set in MEV-Boost. In these circumstances, the recommendations for Local Block Builders</strong> would be relevant.</li>
</ul>
</li>
</ul>
Full Nodes</h4>

Recommended</strong>: 50 Mbps download / 15 Mbps upload.</li>
Rationale</strong>:

Full nodes currently participate in sampling and must track the chain tip, but are not as latency-sensitive as attesters or local block builders.</li>
They can operate on lower bandwidth but risk being a slot or more behind the chain if bandwidth capacity is severely limited.</li>
</ul>
</li>
</ul>
Quick Reference Summary</h3>


Full Node</strong></p>

Storage</strong>: 4 TB NVMe</li>
RAM</strong>: 32 GB</li>
CPU</strong>: 4 cores / 8 threads (~1000 ST / ~3000 MT PassMark)</li>
Bandwidth</strong>: 50 Mbps down / 15 Mbps up</li>
</ul>
</li>

Attester</strong></p>

Storage</strong>: 4 TB NVMe</li>
RAM</strong>: 64 GB</li>
CPU</strong>: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)</li>
Bandwidth</strong>: 50 Mbps down / 25 Mbps up</li>
</ul>
</li>

Local Block Builder</strong></p>

Storage</strong>: 4 TB NVMe</li>
RAM</strong>: 64 GB</li>
CPU</strong>: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)</li>
Bandwidth</strong>: 100 Mbps down / 50 Mbps up</li>
</ul>
</li>
</ul>
Backwards Compatibility</h2>
This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.</p>
Security Considerations</h2>
N/A</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Add blob schedule to EL config files
2024-12-12T00:00:00+00:00
Abstract</h2>
Add a new object to client configuration files blobSchedule</code> which lists the
target blob count per block and max blob count per block for each fork.</p>
Motivation</h2>

ensure there is a way to dynamically adjust the target and max blob counts per
block</li>
ensure there is a way to dynamically adjust the blob base fee update fraction</li>
avoid complex handshake over engine API</li>
</ul>
Specification</h2>
Extend client configuration files with the object blobSchedule</code>, which has the
following shape:</p>
"</span>blobSchedule</span>"</span>: </span>{</span></span>
  "</span>cancun</span>"</span>:</span> {</span></span>
    "</span>target</span>"</span>:</span> 3</span>,</span></span>
    "</span>max</span>"</span>:</span> 6</span>,</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span></span>
  }</span>,</span></span>
  "</span>prague</span>"</span>:</span> {</span></span>
    "</span>target</span>"</span>:</span> 6</span>,</span></span>
    "</span>max</span>"</span>:</span> 9</span>,</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
  }</span></span>
}</span></span></code></pre>
Clients must configure the target, max and baseFeeUpdateFraction per-fork. The behavior
when the configuration is missing or incomplete for a fork is undefined. Clients
are free to choose how to handle this situation.</p>
Rationale</h2>
Although maintaining the target and max blob only in the consensus client is
desirable, we acknowledge the reality that execution clients need these values
for various activities. For example, the eth_feeHistory</code> RPC method returns a
field blobGasUsedRatio</code> that does require the max, even though the core
protocol doesn't specifically need such value. Passing this value over the
engine API every block seem overkill so we believe a configuration value is a
good middle ground. Additionally, the baseFeeUpdateFraction</code> parameter was added to adjust the responsiveness of blob gas pricing per fork.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
No security considerations found.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Upgrade Mascots
2024-10-29T00:00:00+00:00
Abstract</h2>
This EIP establishes a mascot for each Ethereum network upgrade. Mascots serve to humanize and celebrate upgrades, fostering community engagement while adhering to principles of cuteness, relevance, and inclusivity. The mascot is selected through community-driven processes, with safeguards for appropriateness, by a designated facilitator (the "Mascot Wrestler").</p>
Motivation</h2>
Ethereum network upgrades often introduce complex technical changes that can feel abstract to the broader community. Mascots provide a fun, memorable, and relatable symbol for each upgrade, drawing inspiration from its headliner(s). By mandating emoji-representable mascots that are cute and non-offensive, this process:</p>

Enhances community participation and excitement around network upgrades.</li>
Creates opportunities for creative expression in upgrade event branding (e.g., watch parties, POAPs).</li>
Builds a consistent, whimsical tradition that differentiates Ethereum's upgrade narrative from other ecosystems.</li>
</ul>
Specification</h2>
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>
1. Mascot Requirements</h3>

Relevance</strong>: The mascot SHOULD</strong> relate thematically to the network upgrade's headliner(s).</li>
Representation</strong>: The mascot MUST</strong> be expressible using one or more standard Unicode emojis (e.g., :panda: for the Merge).</li>
Form</strong>: The mascot SHOULD</strong> depict an animal (real, mythical, or stylized, but always animal-adjacent).</li>
Tone</strong>: The mascot MUST NOT</strong> be offensive (no depictions of violence, discrimination, or controversy) and SHOULD</strong> be inherently cute (e.g., avoiding aggressive or fearsome traits unless softened for adorability).</li>
</ul>
2. Roles and Responsibilities</h3>


Mascot Wrestler</strong>: A self-selected community facilitator responsible for proposing, selecting, and adopting the mascot for a network upgrade. The role MAY</strong> rotate voluntarily per upgrade cycle to encourage diverse participation.</p>

Duties include:

Soliciting and curating mascot candidates.</li>
Facilitating selection processes.</li>
Announcing the final mascot (e.g., Ethereum Magicians, All Core Devs).</li>
</ul>
</li>
</ul>
</li>

Veto Powers</strong>:</p>

The Mascot Wrestler MAY</strong> veto any candidate mascot not meeting the mascot requirements above.</li>
A rough consensus of client teams MAY</strong> veto the selected mascot, triggering fallback to the next-highest-ranked candidate mascot.</li>
</ul>
</li>
</ul>
3. Selection Process</h3>
The Mascot Wrestler SHALL</strong> conduct selection using one or more community-appropriate mechanisms.</p>
The process MUST</strong>:</p>

Run for a minimum of 7 days.</li>
Present at least 2 candidates.</li>
Rank finalists by popularity.</li>
Document results publicly.</li>
</ul>
If no consensus is reached, the Mascot Wrestler selects the top candidate by default, subject to veto.</p>
4. Usage Guidelines</h3>
All uses MUST</strong> respect the network upgrade mascot's cute, non-offensive nature and credit original concept creators where applicable.</p>
Rationale</h2>
This specification balances creativity with guardrails to prevent mascot drift (e.g., unrelated or edgy choices). Emoji-based representation ensures accessibility across digital platforms, while the animal/cute mandate aligns with Ethereum's community ethos of approachability. The self-selected Mascot Wrestler role decentralizes coordination, leveraging vetoes for accountability. Selection flexibility accommodates Ethereum's decentralized governance evolution.</p>
Alternatives considered:</p>

Fully onchain mandates: Too rigid for creative processes.</li>
No formal process: Risks ad-hoc or absent mascots.</li>
Non-animal options: Animals evoke universality and whimsy.</li>
</ul>
Backwards Compatibility</h2>
This EIP does not directly change the Ethereum protocol. It formalizes part of the current network upgrade process.  Past upgrades (e.g., Shapella's owl :owl:) are retroactively honored if they fit the criteria; future upgrades MUST</strong> comply starting with the next hard fork post-adoption.</p>
Security Considerations</h2>
None</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Controlled Gas Limit Increase Guidelines
2024-10-18T00:00:00+00:00
This proposal specifies specific parameters for the controlled gas limit increase strategy outlined in EIP-7783</a>, including block number to start the increase, initial gas limit, rate of increase per block, and gas limit cap.</p>
Abstract</strong></h2>
This proposal provides parameter recommendations for implementing the controlled gas limit increase strategy in EIP-7783</a>.</p>
Motivation</strong></h2>
The motivation for this proposal is to define practical and balanced parameters for Ethereum's gas limit increase strategy to achieve predictable and stable network scaling. While EIP-7783</a> defines the mechanism, there is still a need to establish the values needed for its implementation based on real-world conditions.</p>
Specification</strong></h2>
Proposed Parameters</strong></h3>
The parameters for the controlled gas limit increase strategy are:</p>


Block Number Start (blockNumStart</code>)</strong>: 21792420</code>

The block number at which the gas limit increase begins. this is february 7, 2024.</p>
</li>

Initial Gas Limit (initialGasLimit</code>)</strong>: 30_000_000</code>

The initial gas limit at blockNumStart</code> represents the current default gas limit of the Ethereum network, set to 30 million gas.</p>
</li>

Rate of Increase (r</code>)</strong>: 6</code>

The gas limit will increase by 6 gas per block. This results in a slow growth rate culminating to reaching the cap in approximately 694 days.</p>
</li>

Gas Limit Cap (gasLimitCap</code>)</strong>: 60_000_000</code>

The maximum gas limit is capped at 60 million gas, ensuring that the gas limit will not increase indefinitely and will prevent the network from being overwhelmed by excessively large blocks.</p>
</li>
</ul>
Rationale</strong></h2>
Starting Block Number</strong></h3>
The chosen block number (21792420</code>) provides ample time to discuss and implement the gas limit increase strategy, additionally, it allows to happen with or slightly before the pectra hard fork.</p>
Initial Gas Limit</strong></h3>
The initial gas limit is set to match the current default gas limit of 30_000_000</code>.</p>
Rate of Increase</strong></h3>
A rate of 6</code> gas per block is chosen to triple the gas limit in approximately 47 months, which is equivalent to almost 2 years.</p>
Gas Limit Cap</strong></h3>

The gas limit cap of 60_000_000</code> provides a safeguard against the gas limit growing beyond what the network can safely handle.</li>
</ul>
Backwards Compatibility</strong></h2>
These parameters do not require any protocol changes or hard forks. They are fully backward compatible with the current Ethereum network architecture.</p>
Security Considerations</strong></h2>

The gradual nature of the gas limit increase prevents sudden surges in block size that could destabilize the network.</li>
The cap on the gas limit ensures that blocks do not become excessively large, which could lead to performance degradation or DOS vulnerabilities.</li>
Validators retain the ability to make adjustments to the gas limit in response to potential network attacks or performance issues.</li>
</ul>
Copyright</strong></h2>
Copyright and related rights waived via CC0 1.0 Universal.</p>


Add Controlled Gas Limit Increase Strategy
2024-10-06T00:00:00+00:00
This proposal describes the introduction in clients of a controlled gas limit increase strategy to determine the gas limit of a specific block and set as default with conservative parameters, while keeping the possibility to change it in the future to a fixed value.</p>
Abstract</strong></h2>
The EIP proposes the introduction of a new gas limit management mechanism that automatically increases the block gas limit over time. The incremental growth is controlled by a fixed rate, ensuring predictable network scaling while preventing sudden surges in block sizes. This strategy is meant to be used as a default setting, with the option to switch to a fixed gas limit if needed (or different parameters).</p>
Motivation</strong></h2>
Predictable Gas Limit Growth</strong></h3>


Current Issue:</strong></p>

The Ethereum network faces increasing demand, but changes to the gas limit are often manually adjusted by miners or validators based on their preferences, which may cause unpredictable block sizes and network performance issues.</li>
</ul>
</li>

Need for Change:</strong></p>

A systematic and predictable increase of the gas limit will help scale the network while giving the ecosystem time to adjust to larger block sizes, without needing to rely on ad hoc decisions by network participants.</li>
</ul>
</li>
</ul>
Gradual Increase with Deactivation Safeguard</strong></h3>


Controlled Growth:</strong></p>

Instead of sudden or unpredictable changes, this EIP proposes incremental gas limit increases over a specified amount of time, ensuring a smooth transition to higher transaction throughput, while still keeping the governance of the gas limit in the hand of the community.</li>
</ul>
</li>

Automatic Deactivation:</strong></p>

A safeguard deactivation block will halt the increase after some specified time, preventing the gas Limit from growing indefinitely and allowing the community to reassess the network's needs.</li>
</ul>
</li>
</ul>
Specification</strong></h2>
There are different approaches to implement a controlled gas limit increase strategy. The following are three possible strategies that can be used:</p>
Linear Gas Limit Increase Strategy</strong></h3>
Add a new "Gas Limit" selection strategy that takes in Block Number N</code> and spits out the Gas Limit GL</code> for that block. The strategy is as follows:</p>

The gas limit GL_t</code> at block t</code> is calculated as:</li>
</ul>
def</span> compute_gas_limit</span>(</span>blockNum</span>:</span> int</span>,</span> blockNumStart</span>:</span> int</span>,</span> initialGasLimit</span>:</span> int</span>,</span> r</span>:</span> int</span>,</span> gasLimitCap</span>:</span> int</span>)</span> -></span> int</span>:</span></span>
  if</span> blockNum</span> <</span> blockNumStart</span>:</span></span>
    return</span> initialGasLimit</span></span>
  else</span>:</span></span>
    return</span> min</span>(</span>gasLimitCap</span>,</span> initialGasLimit</span> +</span> r</span> *</span> (</span>blockNum</span> -</span> blockNumStart</span>)</span>)</span></span></code></pre>
Where:</p>

blockNum</code> is the block number for which the gas limit is being calculated.</li>
blockNumStart</code> is the block number at which the gas limit increase starts.</li>
initialGasLimit</code> is the initial gas limit at block blockNumStart</code>.</li>
r</code> is the rate at which the gas limit increases per block.</li>
gasLimitCap</code> is the maximum gas limit that can be reached.</li>
</ul>
If we set blockNumStart</code> to the current block number, initialGasLimit</code> to the current gas limit (30_000_000</code>), r</code> to 6, and gasLimitCap</code> to 60_000_000</code>, the gas limit will increase by 6 gas per block for two years, reaching 30 million gas at the end of a $\approx$ 2 years period.
The result of compute_gas_limit</code> will be the gas limit aimed by the proposer for the block blockNum</code>. none of this is enforced at the protocol level, and the proposer needs to still follow protocol rules related to the gas limit.</p>
Stepwise Linear Gas Limit Increase Strategy</strong></h3>
Add a new "Gas Limit" selection strategy that takes in Block Number N</code> and spits out the Gas Limit GL</code> for that block. The strategy is as follows:</p>

The gas limit GL_t</code> at block t</code> is calculated as:</li>
</ul>
def</span> compute_gas_limit</span>(</span>blockNum</span>:</span> int</span>,</span> blockNumStart</span>:</span> int</span>,</span> r</span>:</span> int</span>,</span> step_blocks_interval</span>:</span> int</span>,</span> gasLimitCap</span>:</span> int</span>)</span> -></span> int</span>:</span></span>
  if</span> blockNum</span> <</span> blockNumStart</span>:</span></span>
    return</span> initialGasLimit</span></span>
  else</span>:</span></span>
    return</span> min</span>(</span>gasLimitCap</span>,</span> initialGasLimit</span> +</span> r</span> *</span> (</span>(</span>blockNum</span> -</span> blockNumStart</span>)</span> //</span> step_blocks_interval</span>)</span>)</span></span></code></pre>
Where:</p>

blockNum</code> is the block number for which the gas limit is being calculated.</li>
blockNumStart</code> is the block number at which the gas limit increase starts.</li>
initialGasLimit</code> is the initial gas limit at block blockNumStart</code>.</li>
step_blocks_interval</code> is the number of blocks after which the gas limit increases (cooldown period).</li>
r</code> is the rate at which the gas limit increases per step.</li>
gasLimitCap</code> is the maximum gas limit that can be reached.</li>
</ul>
This strategy has three main advantages:</p>

It provides larger, more visible, and distinct metric changes over each step.</li>
It allows for collection of more stabilized metrics over the length of the cooldown period.</li>
It gives the community more time to evaluate the impact of the gas limit increase and act accordingly.</li>
</ul>
Exponential Gas Limit Increase Strategy</strong></h3>
Add a new "Gas Limit" selection strategy that takes in Block Number N</code> and spits out the Gas Limit GL</code> for that block. The strategy is as follows:</p>

The gas limit GL_t</code> at block t</code> is calculated as:</li>
</ul>
def</span> compute_gas_limit</span>(</span>blockNum</span>:</span> int</span>,</span> blockNumStart</span>:</span> int</span>,</span> doubling_blocks_interval</span>:</span> int</span>)</span> -></span> int</span>:</span></span>
  if</span> blockNum</span> <</span> blockNumStart</span>:</span></span>
    return</span> initialGasLimit</span></span>
  else</span>:</span></span>
    return</span> min</span>(</span>gasLimitCap</span>,</span> initialGasLimit</span> *</span> (</span>2</span> **</span> (</span>(</span>blockNum</span> -</span> blockNumStart</span>)</span> /</span> doubling_interval</span>)</span>)</span>)</span></span></code></pre>
Where:</p>

blockNum</code> is the block number for which the gas limit is being calculated.</li>
blockNumStart</code> is the block number at which the gas limit increase starts.</li>
initialGasLimit</code> is the initial gas limit at block blockNumStart</code>.</li>
doubling_blocks_interval</code> is the number of blocks after which the gas limit doubles.</li>
</ul>
Rationale</strong></h2>
Predictable Growth</strong></h3>

Systematic Adjustment:</strong>

The gradual increase avoids sudden surges in gas limit that could destabilize the network. Instead, it provides a smooth transition, giving the ecosystem time to adapt to larger block sizes.</li>
</ul>
</li>
</ul>
Controlled Limit with Deactivation Block</strong></h3>


Automatic Safeguard:</strong></p>

The inclusion of a deactivation block ensures that the gas limit does not increase indefinitely, preventing potential negative impacts on network performance beyond the planned growth.</li>
</ul>
</li>

Community Consensus:</strong></p>

The deactivation block serves only as a checkpoint for the community to evaluate the impact of the gas limit increase, however, in the two-year period, the community can decide to halt the increase at any time and can also switch to a fixed gas limit if needed.</li>
</ul>
</li>
</ul>
Backwards Compatibility</strong></h2>
No Hard Fork Required</strong></p>
Security Considerations</strong></h2>

The controlled gas limit increase strategy is designed to prevent sudden changes that could lead to network instability or security vulnerabilities.</li>
The fact that validators can re-adjust the gas limit in case of a DOS attack or other issues, makes the network more secure than to just increasing the gas limit manually in a cliff-like manner.</li>
</ul>
Copyright</strong></h2>
Copyright and related rights waived via CC0 1.0 Universal.</p>


Network Upgrade Activation Triggers
2023-04-28T00:00:00+00:00
Abstract</h2>
This EIP outlines the various network upgrade activation triggers used on Ethereum over time, from the proof-of-work era to the first post-merge network upgrade, Shanghai/Capella, across both the execution and consensus layers.</p>
Motivation</h2>
This EIP aims to provide users and developers with a single source of truth for understanding the various upgrade activation patterns used throughout Ethereum's history. It does not aim to be a comprehensive, ongoing record, of upgrades and their activations mechanism. Readers should assume that future upgrades use the mechanism described in the Post Merge Upgrades</a> section, unless this EIP is superseded by another one.</p>
Specification</h2>
Proof-of-Work Network Upgrades</h3>
During the proof-of-work era, network upgrades on Ethereum were triggered based on specific block numbers. The following upgrades followed this pattern:</p>
Upgrade Name</th> Activation Block Number</th></tr></thead>

Frontier</td> 1</code></td></tr>
Frontier Thawing</td> 200000</code></td></tr>
Homestead</td> 1150000</code></td></tr>
DAO Fork</td> 1920000</code></td></tr>
Tangerine Whistle</td> 2463000</code></td></tr>
Spurious Dragon</td> 2675000</code></td></tr>
Byzantium</td> 4370000</code></td></tr>
Constantinople</td> 7280000</code></td></tr>
Petersburg</td> 7280000</code></td></tr>
Istanbul</td> 9069000</code></td></tr>
Muir Glacier</td> 9200000</code></td></tr>
Berlin</td> 12244000</code></td></tr>
London</td> 12965000</code></td></tr>
Arrow Glacier</td> 13773000</code></td></tr>
Gray Glacier</td> 15050000</code></td></tr>
</tbody></table>
Beacon Chain Launch</h3>
The Beacon Chain was launched following a set of conditions detailed in EIP-2982</a>. The launch was activated once all the following conditions were met:</p>

The Beacon Chain deposit contract received at least 524288</code> ETH from 16384</code> validators.</li>
The MIN_GENESIS_TIME</code> timestamp of 1606824000</code> (Dec 1, 2020) had been exceeded.</li>
A GENESIS_DELAY</code> of 604800</code> seconds had passed since the minimum validator count was exceeded.</li>
</ol>
Beacon Chain Upgrades</h3>
Beacon Chain upgrades are activated at specific epochs. The following upgrades followed this pattern:</p>
Upgrade Name</th> Activation Epoch</th></tr></thead>

Altair</td> 74240</code></td></tr>
Bellatrix</td> 144896</code></td></tr>
</tbody></table>
The Merge: Paris Upgrade</h3>
The Paris upgrade, the execution layer portion of "The Merge," was triggered by a proof-of-work Total Difficulty value of 58750000000000000000000</code>, as specified in EIP-3675</a>. Note that the activation of the Bellatrix upgrade on the Beacon Chain was a pre-requisite for the Paris upgrade to successfully activate on the proof-of-work chain.</p>
Post-Merge Upgrades</h3>
After The Merge, network upgrades are triggered at an epoch on the consensus layer (CL), which ideally maps to an historical roots accumulator boundary (i.e., a multiple of 8192 slots). The epoch's corresponding timestamp, rather than a block number, is then used on the execution layer (EL) as the activation trigger. The following upgrades followed this pattern:</p>
Upgrade Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead>

Capella  (CL)</td> 194048</code></td> </td></tr>
Shanghai (EL)</td> </td> 1681338455</code></td></tr>
</tbody></table>
Note that epoch 194048</code> happened at timestamp 1681338455</code>. In other words, the upgrades activated simultaneously on both the execution and consensus layers, even though they each used a different constant to trigger it.</p>
Additionally, the use of timestamps on the execution layer resulted in changes to how nodes' FORK_HASH</code> and FORK_NEXT</code> values are calculated. These are described in EIP-6122</a></p>
Rationale</h2>
Blocks and Epochs</h3>
Blocks and epochs serve as natural trigger points for upgrades, as they represent the levels at which state transitions occur on Ethereum.</p>
Terminal Total Difficulty</h3>
For the Terminal Total Difficulty mechanism, the rationale can be found in EIP-3675</a>.</p>
Timestamps</h3>
Due to the possibility of missed slots on the Beacon Chain, the execution layer cannot rely solely on block numbers to trigger upgrades in sync with the consensus layer.</p>
Timestamps are guaranteed to map to a specific epoch, and in their Unix representation, timestamps will always be greater than the block numbers previously used. This allows for a reliable method to trigger upgrades on the execution layer post-merge, while also ensuring that a post-merge upgrade based on a timestamp can never use a value that is considered lower than the last block-triggered upgrade.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Serenity Phase 0
2020-09-15T00:00:00+00:00
Abstract</h2>
This EIP specifies Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet. In Phase 0, the existing PoW chain and mechanics are entirely unaffected, while a PoS chain -- the beacon chain -- is built in parallel to serve as the core of the upgraded consensus. In subsequent phases, the beacon chain is enhanced to support and secure the consensus of a number of parallel shard chains, ultimately incorporating current Ethereum mainnet as one of those shards.</p>
At the core of the beacon chain is a proof of stake consensus mechanism called Casper the Friendly Finality Gadget (FFG) and a fork-choice rule called Latest Message Driven Greedy Heaviest Observed Sub-Tree (LMD-GHOST). Phase 0 is centered primarily around the mechanics and incentives of validators executing these algorithms. The detailed specifications for eth2 are contained in an independent repository from this EIP, and safety and liveness proofs can be found in the Combining GHOST and Casper</a> paper. To avoid duplication, this EIP just references relevant spec files and releases.</p>
Early phases of eth2 are executed without any breaking consensus changes on current Ethereum mainnet. This EIP serves to document the bootstrapping of this consensus mechanism and note the path for eth2 to supplant Ethereum's current proof-of-work (PoW) consensus.</p>
Motivation</h2>
Eth2 aims to fulfill the original vision of Ethereum to support an efficient, global-scale, general-purpose transactional platform while retaining high cryptoeconomic security and decentralization.</p>
Today, Ethereum blocks are consistently full due to increasingly high demand for decentralized applications. Ever since the first serious spikes in adoption in 2017 (cryptokitties), the Ethereum community has consistently and vocally demanded scaling solutions.</p>
Since day 0 of Ethereum, the investigation and expectation in scaling solutions has been two-pronged -- scale from both Layer 1 upgrades and Layer 2 adoption. This EIP represents the start to a multi-phased rollout of the former.</p>
Scaling through sharding</h3>
As the Ethereum network and the applications built upon it have seen increasing usage over the past 5 years, blocks have become regularly full and the gas price market continues to climb. Simple increases to the block gas-limit of the current Ethereum chain are unable to account for the increase in demand of the system without inducing an unsustainably high resource burden (in the form of bandwidth, computational, and disk resources) on consumer nodes. To retain decentralization while scaling up the Ethereum network, another path must be taken.</p>
To provide more scale to Ethereum, while not inducing a restrictively high burden on both consumer and consensus nodes, eth2 introduces a "sharded" solution in which a number of blockchain shards -- each of similar capacity to Ethereum mainnet today -- run in parallel under a unified consensus mechanism. The core consensus (the beacon chain) and a small number of these shards can be processed via a single consumer machine, while the aggregate of the system provides much higher capacity.</p>
Decentralization and economic finality through proof-of-stake</h3>
Since the early days of Ethereum, proof-of-stake has been a long-awaited desideratum for the following:</p>

Increased decentralization of the core consensus by lowering the barrier to entry and technical requirements of participation</li>
Increased cryptoeconomic security via in-protocol penalties for misbehaviour and the addition of economic finality</li>
Elimination of the energy hungry mining of the current PoW consensus mechanism</li>
</ul>
In addition to the above, PoS has synergies with the sharding scaling solution. Due to the random sampling requirement of sharding, PoS provides a more simple and direct access to the "active validator set" than PoW and thus allows for a more direct sharded protocol construction.</p>
Specification</h2>
Phase 0 is designed to require no breaking consensus changes</em> to existing Ethereum mainnet. Instead, this is the bootstrapping a new PoS consensus that can, once stable, supplant the current PoW consensus.</p>
Phase 0 specifications are maintained in a repository independent of this EIP. SPEC_RELEASE_VERSION</code> release of the specs at SPEC_RELEASE_COMMIT</code> are considered the canonical Phase 0 specs for this EIP.</p>
This EIP provides a high level view on the Phase 0 mechanisms, especially those that are relevant to Ethereum mainnet (e.g. the deposit contract) and users (e.g. validator mechanics and eth2 issuance). The extended and low level details remain in the consensus-specs</code> repository</p>
Parameters</h3>
Parameter</th> Value</th></tr></thead>

SPEC_RELEASE_VERSION</code></td> v1.0.0</code></td></tr>
SPEC_RELEASE_COMMIT</code></td> 579da6d2dc734b269dbf67aa1004b54bb9449784</code></td></tr>
DEPOSIT_CONTRACT_ADDRESS</code></td> 0x00000000219ab540356cBB839Cbe05303d7705Fa</code></td></tr>
MIN_GENESIS_TIME</code></td> 1606824000</code></td></tr>
BASE_REWARD_FACTOR</code></td> 2**6</code> (64)</td></tr>
INACTIVITY_PENALTY_QUOTIENT</code></td> 2**26</code> (67,108,864)</td></tr>
PROPORTIONAL_SLASHING_MULTIPLIER</code></td> 1</code></td></tr>
MIN_SLASHING_PENALTY_QUOTIENT</code></td> 2**7</code> (128)</td></tr>
</tbody></table>
Note:</em> Eth2 has many more Phase 0 configuration parameters but the majority are left out of this EIP for brevity.</p>
Validator deposit contract</h3>
In Phase 0, eth2 uses a contract deployed on Ethereum mainnet -- the Deposit Contract -- at DEPOSIT_CONTRACT_ADDRESS</code> to onboard validators into the PoS consensus of the beacon chain.</p>
To participate in the PoS consensus, users submit validator deposits to the deposit contract. The beacon chain comes to consensus on the state of this contract and processes new validator deposits. This uni-directional deposit mechanism is the only technical link between the two components of the system (Ethereum mainnet and beacon chain) in Phase 0.</p>
Beacon chain and validator mechanics</h3>
Users who choose to participate in eth2 consensus deposit ETH collateral into the deposit contract in order to be inducted into the beacon chain validator set. From there, these validators are responsible for constructing the beacon chain</strong> (note that these consensus participants in PoS are akin to miners in PoW).</p>
The beacon chain is a pure PoS chain that in Phase 0 is primarily concerned with maintaining its own consensus and managing the registry of validators. The consensus rules define roles</em> (e.g. block proposal, block attesting) that validators are expected to participate in; validators who perform their roles well are rewarded, and validators who perform their roles poorly or are offline are penalized. Phase 0 does not yet include any ETH transfer, sharding or smart contract / VM execution capabilities.</p>
In subsequent phases, additional mechanisms and validator responsibilities will be added to the beacon chain to manage the consensus of a number of parallel shard chains ("Phase 1"), to integrate the existing Ethereum system ("Phase 1.5") and to add full support for sharded smart contract execution ("Phase 2").</p>
Issuance</h3>
To incentivize validators to deposit ether collateral and participate in the eth2 consensus, we propose that rewards (in the form of Ethereum's native asset, ether) be regularly issued to consensus participants. Due to the beacon chain operating in parallel to the existing PoW chain in early phases of eth2, this issuance is in addition to</em> any PoW rewards until the existing chain is merged into eth2 as a shard.</p>
The amount of ether issued to validators on the beacon chain is proportional to the square root of the total ether deposited. This issuance curve was chosen as a more stable and sustainable curve to the two obvious alternatives -- fixed total issuance and fixed issuance per ether staked. For a more technical discussion on this choice see here</a>.</p>
In eth2, this curve is parameterized by BASE_REWARD_FACTOR</code> in the context of slot time and epoch length. Below is the issuance curve as a function of ether staked, along with a table of examples for illustration. Note, all figures shown are annualized.</p>
</p>
Active Deposits</th> Max Annual Validator Reward*</th> Max Annual ETH Issued*</th></tr></thead>

0.5M ETH</td> 23.50%</td> 117,527</td></tr>
1M ETH</td> 16.60%</td> 166,208</td></tr>
2M ETH</td> 11.75%</td> 235,052</td></tr>
4M ETH</td> 8.31%</td> 332,411</td></tr>
8M ETH</td> 5.88%</td> 470,104</td></tr>
16M ETH</td> 4.16%</td> 664,801</td></tr>
32M ETH</td> 2.94%</td> 940,167</td></tr>
64M ETH</td> 2.08%</td> 1,329,603</td></tr>
128M ETH</td> 1.47%</td> 1,880,334</td></tr>
</tbody></table>
*Assuming validators are online 100% of the time and behaving optimally. Suboptimal validator behavior will lead to reduced rewards and/or penalties that reduce total issuance.</em></p>
Initial punitive parameters</h3>
For PoS protocols to be crypto-economically secure, in-protocol penalties are required. Small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in the event of tail-risk scenarios.</p>
Specifically, the following significant penalties exist:</p>

Inactivity Leak</strong>: an offline penalty that increases each epoch is applied to validators during extended times of no finality (e.g. if one-third or more are offline or not on the canonical chain). This ensures the chain can eventually regain finality even under catastrophic conditions.</li>
Slashing</strong>: a penalty applied to validators that sign explicitly malicious</em> messages that could lead to the construction and finalization of two conflicting chains (e.g. two blocks or attestations in the same slot). This penalty is designed to scale up in proportion to the number of slashable validators in the same time period such that if a critical number (wrt chain safety) of slashings have occurred, validators are maximally</em> punished.</li>
</ul>
For the initial launch of Phase 0, the parameters defining the magnitude of these penalties -- INACTIVITY_PENALTY_QUOTIENT</code>, PROPORTIONAL_SLASHING_MULTIPLIER</code>, and MIN_SLASHING_PENALTY_QUOTIENT</code> -- have been tuned to be less punitive than their final intended values. This provides a more forgiving environment for early validators and client software in an effort to encourage validation in this early, higher technical-risk stage.</p>
INACTIVITY_PENALTY_QUOTIENT</code> is configured initially to four times its final value</em>. This results in a slower inactivity leak during times of non-finality, which means the chain is less responsive to such an event. If there is an extended time of non-finality during the early months of eth2, it is far more likely to be due to technical issues with client software rather than some sort of global catastrophic event.</p>
PROPORTIONAL_SLASHING_MULTIPLIER</code> is configured initially to one-third of its final value</em>. This results in a lower accountable safety margin in the event of an attack. If any validators are slashed in the early months of eth2, it is far more likely to be the result of user mismanagement of keys and/or issues with client software than an organized attack.</p>
MIN_SLASHING_PENALTY_QUOTIENT</code> configured initially to four times its final value</em>. This results in a lower guaranteed minimum penalty for a slashable offense and thus reduces the baseline punitive incentive to keep an individual validator's system secure. As with PROPORTIONAL_SLASHING_MULTIPLIER</code>, slashings during the early months of eth2 are far more likely to be due to user mismanagement, or issues with client software, than an organized attack.</p>
Rationale</h2>
Principles</h3>

Simplicity</strong>: especially since cryptoeconomic proof of stake and quadratic sharding are inherently complex, the protocol should strive for maximum simplicity in its decisions as much as possible. This is important because it (i) minimizes development costs, (ii) reduces risk of unforeseen security issues, and (iii) allows protocol designers to more easily convince users that parameter choices are legitimate. When complexity is unavoidable to achieve a given level of functionality, the preference order for where the complexity goes is: layer 2 protocols > client implementations > protocol spec.</li>
Long-term stability</strong>: the low levels of the protocol should ideally be built so that there is no need to change them for a decade or longer, and any needed innovation can happen on higher levels (client implementations or layer 2 protocols).</li>
Sufficiency</strong>: it should be fundamentally possible to build as many classes of applications as possible on top of the protocol.</li>
Defense in depth</strong>: the protocol should continue to work as well as possible under a variety of possible security assumptions (eg. regarding network latency, fault count, the motivations of users)</li>
Full light-client verifiability</strong>: given some assumptions (eg. network latency, bounds on attacker budget, 1-of-N or few-of-N honest minority), a client verifying a small fixed amount of data (ideally just the beacon chain) should be able to gain indirect assurance that all of the data in the full system is available and valid, even under a 51% attack (note: this is a form of defense-in-depth but it's important enough to be separate)</li>
</ul>
The Layer 1 vs Layer 2 Tradeoff</h3>
The Ethereum roadmap uses a mixed layer 1 / layer 2 approach. We focus on serving a particular type of layer 2 (rollups) because it's the only kind of layer 2 that both inherits the security of layer 1 and provides scaling of general-purpose applications. However, rollups come at a cost: they require some on-chain data per transaction</em>, and so a blockchain with really high capacity rollups must be able to handle a still quite high amount of data bandwidth. So make this more feasible, we are implementing on scalable data layer technologies, particularly data availability sampling.</p>
The reason to not take a pure layer 2 approach is that pure layer 2 scaling can only be done either with trust-based solutions (not desirable), or with channels or plasma (which have inherent limitations and cannot support the full EVM.</p>
The reason to not take a pure layer 1 approach is to enable more room for experimentation in execution layers, and allow the base protocol to be simpler and have less intensive governance.</p>
Why proof of stake</h3>
In short:</p>

No need to consume large quantities of electricity</strong> in order to secure a blockchain (e.g. it's estimated that both Bitcoin and Ethereum burn over $1 million worth of electricity and hardware costs per day as part of their consensus mechanism).</li>
Because of the lack of high electricity consumption, there is not as much need to issue as many new coins</strong> in order to motivate participants to keep participating in the network. It may theoretically even be possible to have negative net issuance, where a portion of transaction fees is "burned" and so the supply goes down over time.</li>
Proof of stake opens the door to a wider array of techniques that use game-theoretic mechanism design in order to better discourage centralized cartels</strong> from forming and, if they do form, from acting in ways that are harmful to the network (e.g. like selfish mining in proof of work).</li>
Reduced centralization risks</strong>, as economies of scale are much less of an issue. $10 million of coins will get you exactly 10 times higher returns than $1 million of coins, without any additional disproportionate gains because at the higher level you can afford better mass-production equipment, which is an advantage for Proof-of-Work.</li>
Ability to use economic penalties to make various forms of 51% attacks vastly more expensive</strong> to carry out than proof of work - to paraphrase Vlad Zamfir, "it's as though your ASIC farm burned down if you participated in a 51% attack".</li>
</ul>
Why Casper</h3>
There are currently three major schools of proof of stake consensus algorithm:</p>

Nakamoto-inspired</strong> (Peercoin, NXT, Ouroboros...)</li>
PBFT-inspired</strong> (Tendermint, Casper FFG, Hotstuff...)</li>
CBC Casper</strong></li>
</ul>
Within the latter two camps, there is also the question of whether and how to use security deposits and slashing (Nakamoto-inspired algorithms are incompatible with non-trivial slashing). All three are superior to proof of work, but we want to defend our own approach.</p>
Slashing</h4>
Ethereum 2.0 uses a slashing</strong> mechanism where a validator that is detected to have misbehaved can be penalized, in the best case ~1% but in the worst case up to its entire deposit.</p>
We defend our use of slashing as follows:</p>

Raising the cost of attack</strong>: We want to be able to make a hard claim that a 51% attack on a proof of stake blockchain forces the attacker to incur a very large amount of expense (think: hundreds of millions of dollars worth of coins) that get burned, and any attack can be recovered from quickly. This makes the attack/defense calculus very unfavorable for attackers, and in fact makes attacks potentially counterproductive</em>, because the disruption to service is outweighed by price gains to legitimate coin holders.</li>
Overcoming the validator's dilemma</strong>: the most realistic immediate way for nodes to start to deviate from "honest" behavior is laziness</em> (ie. not validating things that one should be validating, signing everything just in case, etc). See the validator's dilemma paper</a> (Luu et al., CC BY) for theoretical reasoning and the Bitcoin SPV mining fork for examples of this happening and leading to very harmful consequences in the wild. Having very large penalties for self-contradicting or for signing incorrect things helps to alleviate this.</li>
</ol>
A more subtle instance of (2) can be seen as follows. In July 2019 a validator on Cosmos was slashed for signing two conflicting blocks. An investigation revealed that this happened because that validator was running a primary and a backup node (to ensure that one of the two going offline would not prevent them from getting rewards) and the two were accidentally turned on at the same time, leading to them contradicting each other.</p>
If it became standard practice to have a primary and backup node, then an attacker could partition the network and get the primaries and the backups of all the validators to commit to different blocks, and thereby lead to two conflicting blocks being finalized. Slashing penalties help to heavily disincentivize this practice, reducing the risk of such a scenario taking place.</p>
Choice of consensus algorithm</h4>
Only the BFT-inspired and CBC schools of consensus algorithm have a notion of finality, where a block is confirmed in such a way that a large portion (1/3 in BFT-inspired, 1/4 in CBC) of validators would need to misbehave and get slashed for that block to get reverted in favor of some conflicting block; Nakamoto-inspired (ie. longest-chain-rule) consensus algorithms have no way of achieving finality in this sense.</p>
Note that finality requires a (super)majority of validators being online, but this is a requirement of the sharding mechanism already, as it requires 2/3 of a randomly sampled committee of validators to sign off on a crosslink for that crosslink to be accepted.</p>
Our choice of Casper FFG</a> was simply a matter of it being the simplest algorithm available at the time that part of the protocol was being finalized. Details are still subject to long-term change; in particular, we are actively exploring solutions to achieve single slot finality.</p>
Sharding - or, why do we hate supernodes?</h3>
The main alternative to sharding for layer-1 scaling is the use of supernodes - simply requiring every consensus node to have a powerful server so that it can individually process every transaction. Supernode-based scaling is convenient because it is simple to implement: it works just the same way blockchains do now, except that more software-engineering work is required to build things in a way that is more parallelizable.</p>
Our main objections to this approach are as follows:</p>

Pool centralization risk</strong>: in a supernode-based system, running a node has a high fixed cost, so far fewer users can participate. This is usually rebutted with "well consensus in most PoW and PoS coins is dominated by 5-20 pools anyway, and the pools will be able to run nodes just fine". However, this response ignores the risk of centralization pressure even between pools that can afford it. If the fixed cost of running a validator is significant relative to the returns, then larger pools will be able to offer smaller fees than smaller ones and this could lead to smaller pools being pushed out or feeling pressure to merge. In a sharded system, on the other hand, validators with more ETH need to verify more transactions, so costs are not fixed.</li>
AWS centralization risk</strong>: in a supernode-based system, home staking is infeasible and so it's more likely that most staking will happen inside cloud computing environments, of which there are only a few options to choose from. This creates a single point of failure.</li>
Reduced censorship resistance</strong>: making it impossible to participate in consensus without high computation+bandwidth requirements makes detection and censorship of validators easier.</li>
Scalability</strong>: as transaction throughput increases, in a supernode-based system the above risks increase, whereas sharded systems can more easily handle the increased load.</li>
</ul>
These centralization risks are also why we are NOT attempting to achieve super-low-latency (<1s) of the blockchain, instead opting for (relatively!) conservative numbers.</p>
Instead, Ethereum is taking an approach where each validator is only assigned to process a small portion of all data. Only validators staking large amounts of ETH (think: tens of thousands or more) are required to process the entire data in the chain.</p>
Note that there is a possible middle-ground in sharding design where block production</em> is centralized but (i) block verification</em> is decentralized and (ii) there exist "bypass channels" where users can send transactions and block producers are forced to include them, so even a monopoly producer cannot censor. We are actively considering sharding designs that lean somewhat in this direction to increase simplicity so that scaling can be deployed faster, though if desired even within this spec it's possible to run distributed builders and avoid centralization even there.</p>
Security models</h3>
It's commonly assumed that blockchains depend on an "honest majority" assumption for their security: that >=50% of participants will faithfully follow a prescribed protocol, even forgoing opportunities to defect for their own personal interest. In reality, (i) an honest majority model is unrealistic, with participants being "lazy" and signing off on blocks without validating them (see the validator's dilemma paper</a> and the Bitcoin SPV mining fork) being a very common form of defection, but fortunately (ii) blockchains maintain many or all of their security properties under much harsher models, and it's really important to preserve those extra guarantees.</p>
A common harsher model is the uncoordinated rational majority</em> model, which states that participants act in their own self-interest, but no more than some percentage (eg. 23.21% in simple PoW chains) are cooperating with each other. An even harsher model is the worst-case model where there is a single actor that controls more than 50% of hashpower or stake, and the question becomes:</p>

Can we, even under that scenario, force the attacker to have to pay a very high cost to break the chain's guarantees?</li>
What guarantees can we unconditionally preserve?</li>
</ul>
Slashing in proof of stake chains accomplishes the first objective. In non-sharded chains, every node verifying every block accomplishes the second objective for two specific guarantees: (i) that the longest chain is valid, and (ii) that the longest chain is available</em>.</p>
A major challenge in sharding is getting the same two properties without requiring each node to verify the full chain. Our defense-in-depth approach with sharding accomplishes just that. The core idea is to combine together random committee sampling, proof of custody, fraud proofs, data availability sampling (DAS)</a> and eventually ZK-SNARKs, to allow clients to detect and reject invalid or unavailable chains without downloading and verifying all of the data, even if the invalid chains are supported by a majority of all proof of stake validators.</p>
Censorship of transactions can potentially be detected by clients in a consensus-preserving way, but this research has not yet been incorporated into the ethereum roadmap.</p>
Here is the current expected security properties expressed in a table:</p>
</th> Network delay <3s</th> Network delay 3s - 6 min</th> Network delay > 6 min</th></tr></thead>

>2/3 validators honest</td> Perfect operation</td> Imperfect but acceptable operation. No rigorous proof of liveness, but liveness expected in practice.</td> Likely intermittent liveness failures, no safety failures</td></tr>
>2/3 validators rational, <1/3 coordinated</td> Perfect operation</td> Imperfect but acceptable operation, heightened centralization risk</td> Likely intermittent liveness failures, no safety failures, very high centralization risk</td></tr>
51% attacker</td> Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains</td> Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains</td> Can revert finality or censor; cannot force through invalid or unavailable chains</td></tr>
</tbody></table>
Why are the Casper incentives set the way they are?</h3>
Base rewards</h4>
During each epoch, every validator is expected to make an "attestation", a signature that expresses that validator's opinion on what the head of the chain is. There is a reward for having one's attestation included, with four components (called "duties"):</p>

Reward for the attestation getting included at all</li>
Reward for the attestation specifying the correct epoch checkpoint</li>
Reward for the attestation specifying the correct chain head</li>
Reward for correctly participating in sync committee signatures</li>
</ol>
Note also that mixed into these duties is a timeliness requirement: your attestation has to be included within a certain time to be eligible for the rewards, and for the "correct head" duty that time limit is 1 slot.</p>
For each duty, the actual reward is computed as follows. If:</p>

$R = B * \frac{nom}{den}$ equals the base reward multiplied by the fraction $\frac{nom}{den}$ that corresponds to that particular duty</li>
$P$ is the portion of validators that did the desired action</li>
</ul>
Then:</p>

Any validator that fulfilled the duty gets a reward of $R * P$</li>
Any validator that did not fulfill the duty gets a penalty $-R$</li>
</ul>
The purpose of this "collective reward" scheme where "if anyone performs better, everyone performs better" is to bound griefing factors (see this paper</a> for one description of griefing factors and why they are important).</p>
The base reward $B$ is itself calculated as $k * \frac{D_i}{\sqrt{\sum_{j=1}^{n} D_j}}$ where $D_1 ... D_n$ are deposit sizes and $k$ is a constant; this is a halfway compromise between two common models, (i) fixed reward rate, ie. $k * D_i$, and (ii) fixed total reward, ie. $k * \frac{D_i}{\sum_{j=1}^{n} D_j}$.</p>
The main argument against (i) is that it imposes too much uncertainty on the network of two kinds: uncertainty of the total level of issuance, and uncertainty of the total level of deposits (as if a fixed reward rate is set too low then almost no one will participate, threatening the network, and if a rate is set too high then very many validators will participate, leading to unexpectedly high issuance). The main argument against (ii) is greater vulnerability to discouragement attacks (again see the discouragement attacks paper</a>). The inverse-square-root approach compromises between the two and avoids the worst consequences of each one.</p>
When an attestation gets a reward, the proposer gets a fraction of that reward. This is to encourage proposers to listen well for messages and accept as many as possible.</p>
Note also that the rewards are designed to be forgiving to validators who are offline often: being offline 1% of the time only sacrifices about 1.6% of your reward. This is also to promote decentralization: the goal of a decentralized system is to create a reliable whole out of unreliable parts, so we should not be trying to force each individual node to be extremely reliable.</p>
Inactivity leak</h4>
If the chain fails to finalize for $tsf > 4$ epochs ($tsf$ = "time since finality"), then a penalty is added so that the maximum possible reward is zero (validators performing imperfectly get penalized), and a second penalty component is added, proportional to $tsf$ (that is, the longer the chain has not finalized, the higher the per-epoch</em> penalty for being offline). This ensures that if more than 1/3 of validators drop off, validators that are not online get penalized much more heavily, and the total penalty goes up quadratically over time.</p>
This has three consequences:</p>

Penalizes being offline much more heavily in the case where you being offline is actually preventing blocks from being finalized</li>
Serves the goals of being an anti-correlation penalty (see section below)</li>
Ensures that if more than 1/3 do go offline, eventually the portion online goes back up to 2/3 because of the declining deposits of the offline validators</li>
</ul>
With the current parametrization, if blocks stop being finalized, validators lose 1% of their deposits after 2.6 days, 10% after 8.4 days, and 50% after 21 days. This means for example that if 50% of validators drop offline, blocks will start finalizing again after 21 days.</p>
Slashing and anti-correlation penalties</h4>
If a validator is caught violating the Casper FFG slashing condition, they get penalized a portion of their deposit equal to three times the portion of validators that were penalized around the same time as them (specifically, between 18 days before they were penalized and roughly the time they withdrew). This is motivated by several goals:</p>

A validator misbehaving is only really bad for the network if they misbehave at the same time as many other validators, so it makes sense to punish them more in that case</li>
It heavily penalizes actual attacks, but applies very light penalties to single isolated failures that are likely to be honest mistakes</li>
It ensures that smaller validators take on less risk than larger validators (as in the normal case, a large validator would be the only one failing at the same time as themselves)</li>
It creates a disincentive against everyone joining the largest pool</li>
</ul>
BLS Signatures</h3>
BLS signatures are used because of their aggregation-friendliness: any two signatures $S_1$ and $S_2$ of a message $M$ signed by keys $k_1$ and $k_2$ (corresponding pubkeys $K_1 = G * k_1$ and $K_2 = G * k_2$ where $G$ is the generator of the elliptic curve) can simply be aggregated by elliptic curve point addition: $S_1 + S_2$, which verifies against the public key $K_1 + K_2$. This allows many thousands of signatures to be aggregated, with the marginal cost of one signature being one bit of data (to express that a particular public key is present in the aggregate signature) and one elliptic curve addition for computation.</p>
Note that BLS signatures of this form are vulnerable to rogue key attacks</em>: if you see that other validators have already published public keys $K_1 ... K_n$, then you can generate a private key $r$ and publish a public key $G * r - K_1 - ... - K_n$. The aggregate public key would simply be $G * r$, so you would be able to make a signature that verifies against the combined public key by yourself. The standard way to get around this is to require a proof of possession</em>: basically, a signature of a message (that depends on the public key, and that would normally not be signed) that verifies against the public key by itself (ie. $sign(message=H'(K), key=k)$ for privkey $k$ and pubkey $K$, where $H'$ is a hash function). This ensures that you personally control the private key connected to the public key that you publish.</p>
We use the signature of a deposit message (which specifies the signing key but also other important data such as the withdrawal key) as a proof of possession.</p>
Why 32 ETH validator sizes?</h3>
Any BFT consensus algorithm with accountable fault tolerance (ie. if two conflicting blocks get finalized you can identify which 1/3 of nodes were responsible) must have all validators participate, and furthermore for technical reasons you need two rounds of every validator participating to finalize a message.</p>
This leads to the decentralization / finality time / overhead tradeoff: if $n$ is the number of validators in a network, $f$ is the time to finalize a block, and $\omega$ is the overhead in messages per second, then we have:</p>
$$\omega \ge \frac{2 * n}{f}$$</p>
For example, if we are ok with an overhead of 10 messages per second, then a 10000-node network could only have a finality time of at least 2000 seconds (~33 minutes).</p>
In Ethereum's case, if we assume a total ETH supply of $\approx 2^{27}$ ETH, then with 32 ETH deposit sizes, there are at most $2^{22}$ validators (and that's if everyone validates; in general we expect ~10x less ETH validating). With a finality time of 2 epochs (2 * 32 * 12 = 768 seconds), that implies a max overhead of $\frac{2^{22}}{768} \approx 5461$ messages per second. We can tolerate such high overhead due to BLS aggregation reducing the marginal size of each signature to 1 bit and the marginal verification complexity to one elliptic curve addition.</p>
32 slots is a safe minimum for another reason: if an attacker manipulates the randomness used for proposer selection, this number still provides enough space to ensure that there will be at least one honest proposer in each epoch, which is sufficient to ensure blocks keep finalizing. Our calculations suggest that current levels of overhead are acceptable, but higher levels would make running a node too difficult. Finally, the validator deposit size is ideal for shard crosslinking (see below).</p>
Random sampling</h3>
Seed selection</h4>
The seed used for randomness is updated every block by "mixing in" (ie. seed <- xor(seed, new_data)</code>) a value that must be revealed by the proposer of the block. Just like proof of custody subkeys, a validator's values are all pre-determined once the validator has deposited, third parties cannot compute subkeys but can verify subkeys that are revealed voluntarily (this mechanism is sometimes called RANDAO).</p>
This ensures that each proposer has one "bit of manipulation" over the seed: they can either make a block or not make a block. Not making a block is expensive in that the proposer misses out on many rewards. Furthermore, because the persistent and beacon committee sizes (see below) are large, manipulation of the randomness almost certainly cannot allow minority attackers to get 2/3 of any committee.</p>
In the future we plan to use verifiable delay functions (VDFs) to further increase the random seeds' robustness against manipulation.</p>
Shuffling</h4>
We use the swap-or-not shuffle described by Viet Tung Hoang, Ben Morris, and Phillip Rogaway to shuffle the validator set and assign responsibilities every epoch. This algorithm ensures that:</p>

As the shuffle is a permutation, each validator is assigned to be a member of exactly one committee during each epoch (keeping their load stable and reducing the chance manipulation of randomness can be profitable)</li>
As the shuffle is pointwise-evaluable in the forward direction, a validator can determine their own responsibilities in O(1) time</li>
As the shuffle is pointwise-evaluable in the reverse direction, the members of any specific committee or the proposer of any specific block can be computed in O(1) time</li>
</ul>
Shuffling by slot</h4>
There are 32 slots in an epoch, and the validators responsible for attesting to each slot are chosen by shuffling. This ensures that attackers with a significant but still small portion of total stake cannot take over specific slots and cause short-range reorgs.</p>
Beacon committees</h4>
The committee for each slot is in turn split up into some number of beacon committees</em>. Today (2022 Jan), this design does serve one useful function, allowing different subsets of attestations to get aggregated in separate subnets and thus making the p2p network more efficient. However, it does not serve any other useful consensus-related role.</p>
In the original sharding design, the intention was that each beacon committee would be responsible for verifying a specific shard. However, this approach is likely deprecated if we switch to a single-proposer model. Hence, the more fine-grained beacon committees may well only be there vestigially and could eventually be removed or re-structured in a different way to focus on facilitating attestation aggregation.</p>
Sync committee</h4>
A sync committee of 512 validators is selected once every ~27 hours to sign a block; this committee's pubkeys are saved in an easily accessible list, allowing signatures to be easily verified by ultra-light clients.</p>
LMD GHOST fork choice rule</h3>
The beacon chain uses an LMD GHOST fork choice rule.</p>
The LMD GHOST fork choice rule incorporates information from all validators, hundreds in each slot, making it extremely unlikely in the normal case that even a single block will be reverted. Because the fork choice is dependent on all validators, this also ensures that blocks cannot be reverted unless an attacker really does control close to 50% of the entire validator set; one cannot achieve a large advantage by manipulating the randomness.</p>
The proof of custody game</h3>
For each 9-day period, each validator has the ability to privately generate a "period subkey". The validator's public key uniquely determines their period subkey for every period, so once a validator has deposited they have no further freedom to choose what their subkeys are. No one can compute any given validator's subkey except the validator themselves, but once a validator reveals a subkey voluntarily, anyone can verify its correctness (this is all done via BLS magic, and if quantum-safety is required in the future it can be done with hash-based commitments).</p>
When signing a block with data $D$ with root $R$ during period $j$, letting $s$ being the period-$j$ secret of that validator, a validator is required to compute a bitfield $M$ as follows:</p>

Split $D$ into 512-byte chunks $D[0] ... D[n-1]$</li>
Set $M$ to be the bitfield where the i'th bit is $M[i] = mix(s, D[i])$</li>
</ul>
They include get_chunk_bits_root(M)</code> (this is called the custody bit</strong>) as part of what they are signing. mix</code> and get_chunk_bits_root</code> can both be viewed as hash-like functions that output a single bit (but are designed for multi-party-computation friendliness).</p>
If a crosslink includes multiple blocks $B_1 ... B_n$ and the validator computes custody bits $c_1 ... c_n$ for these blocks, then the validator signs all $(B_i, c_i, i)$ tuples and aggregates them. This unconventional self-aggregation is used to ensure that there are only $2n$ different messages (n different block/index pairs * 2 different bit values) being signed by different validators, reducing the number of pairings needed to verify the signatures.</p>
If a validator publishes their period $j$ subkey during or before period $j$, any other validator can publish a proof-of-knowledge of the subkey to the chain, which then penalizes the validator whose subkey was revealed. The proof of knowledge also proves which validator created it; this prevents block proposers from "stealing" the whistleblowing reward (once again all done via BLS magic, if quantum-safety is required in the future this can be done with STARKs). The goal of this is to make it dangerous to outsource computation of $M$.</p>
After a validator publishes their period $j$ subkey, anyone else can check their work for any block that they signed. If they discover that a validator provided an incorrect custody bit, they can challenge this on-chain, and slash that validator. In general, random guessing (or any procedure that does not involve all of $D$) will only give a correct answer half the time, leading to a 50% risk of slashing per block signed.</p>
The purpose of this mechanism is to mitigate the validator's dilemma</a> problem, where validators have an incentive to avoid verifying data out of laziness and piggyback on the assumption that all other</em> validators are honest; if too many validators think in this way, it could lead to a tragedy of the commons leading to the chain accepting invalid blocks. With this scheme, if a validator attempts to commit to data that they did not personally process, then they would not be able to compute $M$, and so would lose the interactive challenge game.</p>
SSZ</h3>
The SimpleSerialize suite contains the following algorithms:</p>

A serialization algorithm</li>
A hashing algorithm (called SSZTreeHash</code> or hash_tree_root</code>)</li>
A generalized Merkle proof algorithm (called "SSZ partials") that can handle proofs for multiple values and optimally deduplicates Merkle tree sister nodes in such cases.</li>
</ul>
The serialization algorithm has the following design goals:</p>

Simplicity (eg. no three clauses like RLP has for long / list encoding depending on item length)</li>
Being equivalent to simple concatenation in the case of entirely fixed-size objects</li>
Being usable as both a consensus-layer serialization algorithm and an application-layer ABI</li>
</ul>
Note that the resulting SSZ serialization spec is very similar to the ethereum 1.0 ABI, with the major differences being (i) different basic data types and (ii) replacing the 32 byte length/position record size with a 4 byte size.</p>
The hashing algorithm has the following design goals:</p>

Efficiency of computing the hash of an updated object, especially in the case where the object is very large and/or complex and the change is relatively small</li>
Efficiency (in terms of verification complexity and</em> witness size) of proving the value of a specific field even in a large or complex object with a given hash</li>
</ul>
These requirements together make a Merkle tree structure the obvious choice.</p>
Generalized indices</h4>
See https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs "poking into" arbitrary positions in an object by representing paths as an integer or bitfield.</p>
The validator lifecycle</h3>
Depositing</h4>
A validator deposits by sending a transaction that calls a function on the deposit contract on the eth1 chain (eventually, a way to deposit from inside eth2 will also be added). A deposit specifies:</p>

The public key corresponding to the private key that will be used to sign messages</li>
The withdrawal credentials (hash of the public key that will be used to withdraw funds once the validator is done validating)</li>
The deposit amount</li>
</ul>
These values are all signed by the signing key. The goal of having separate signing and withdrawal keys is to allow the more dangerous withdrawal key to be kept more securely (offline, not shared with any staking pools, etc) while the signing key is used to actively sign a message every epoch.</p>
The deposit contract maintains a Merkle root of all deposits made so far. Once a merkle root containing the deposit gets included into the eth2 chains (via the Eth1Data voting mechanism), an eth2 block proposer can submit a Merkle proof of the deposit and start the deposit process.</p>
Activation</h4>
The validator immediately joins the validator registry, but is at first inactive. The validator becomes active after $N \ge 4$ epochs; the minimum of 4 is there to ensure the RANDAO is not manipulable, and $N$ may exceed 4 if too many validators try to join at the same time. If the active validator set has size $|V|$, a maximum of $max(4, \frac{|V|}{65536})$ validators can join per epoch; if more validators try to join, they are put in a queue and processed as quickly as possible.</p>
Exiting</h4>
When a validator exits (whether by publishing a voluntary exit message or being slashed), they are similarly put into an exit queue with the same maximum throughput.</p>
The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $|V| \ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time.</p>
Withdrawal</h4>
Once a validator leaves the exit queue, there is a ~27 hour period until they can withdraw. This period has several functions:</p>

It ensures that if a validator misbehaved there is a period of time within which the error can be caught and the validator can be slashed even if the exit queue is nearly empty.</li>
It provides time for the last period of shard rewards to be included.</li>
It provides time for proof of custody challenges to be made.</li>
</ul>
If a validator is slashed, a further delay of ~36 days is imposed. This further penalizes them (and forces them to hold the ETH; this makes the penalty somewhat larger for malicious validators that are trying to destroy the ethereum blockchain than those validators that want to support the platform but just made a mistake, as the former category would have to risk the exposure or pay for derivatives to cancel it out), but also allows for a period during which the number of other validators that got slashed can be calculated.</p>
In phase 0, a "withdrawn" validator cannot actually withdraw to anywhere yet; the only distinction is that it is protected from validator penalties and does not have any responsibilities. In later phases, the ability to move funds from a withdrawn validator slot to an execution environment will be made available.</p>
Effective balances</h4>
Most calculations based on a validator's balance use the validator's "effective balance"; the only exception is calculations that increase or decrease the validator's balance. Only when the validators's balance $B$ falls below $EB$ or goes above $EB + 1.5$ is $EB$ adjusted to equal $floor(B)$. This is done to ensure that effective balance changes infrequently, reducing the amount of hashing needed to recompute the state every epoch; on average, only the balances need to all be updated, and the effective balances only get updated relatively rarely per validator. Balances are all stored in a dedicated vector, so $2 * \frac{N * 8}{32} = \frac{N}{2}$ hashes are needed to recompute a balance array, whereas effective balances are stored in validator record objects, where at least $5N$ hashes would be needed per validator to adjust the SSZ hash roots. Additionally, $EB$ can be compressed more easily into a CompactValidator object, as it's only one byte.</p>
Fork mechanism</h3>
The Fork</code> data structure contains (i) the current "fork ID", (ii) the previous fork ID and (iii) the switchover slot. The fork ID at the current height influences the valid signatures of all messages; hence, a message signed with one fork ID is invalid to a verification function using any other fork ID.</p>
A fork is done by adding a state transition at some "fork slot" $n$ which sets the previous fork ID to the current fork ID, the current fork ID to a new value, and the switchover slot to $n$. Signature verification functions will verify messages using the fork ID at the slot the message is for, which could be the previous fork ID or the current one (eg. consider the case of attestations included after a delay; an attestation from before the fork slot could be included after the fork slot).</p>
If any users do not want to join the fork, they can simply continue the chain that does not change the fork ID at the fork slot. The two chains would be able to proceed and validators would be free to validate on both without getting slashed.</p>
Backwards Compatibility</h2>
Although this EIP does not introduce any immediate changes to the current Ethereum mainnet, this EIP lays the groundwork for future backwards incompatibilities through the introduction of the new eth2 consensus mechanism in which Ethereum will be integrated in subsequent phases. To secure this mechanism, users move ether into the beacon chain and additional ether is issued. This EIP is a commitment to this path being canonical, as well as directly informing the future and roadmap of Ethereum mainnet.</p>
Security Considerations</h2>
Eth2 is a major overhaul of the Ethereum's core consensus from PoW to a sharded PoS. There are inherent risks in this migration but there is extensive research literature analyzing security and trade-offs. The following only represents a high level selection of the resources available:</em></p>

Casper FFG</a></li>
Combining GHOST and Casper</a></li>
</ul>
In addition to the research supporting this path, a number of audits and formal verification of specs, cryptography, and client implementations have been performed. Many client and utility library audits are currently in progress and will be appended here upon completion.</em></p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Updates and Updated-by Header
2020-01-06T00:00:00+00:00
Simple Summary</h2>
Adds EIP header options updates</code> and updated-by</code> to frontmatter of active</code> EIPs for use as needed.</p>
Abstract</h2>
EIP headers updates</code> and updated-by</code> are used for updating active</code> EIPs. This is to make the improvement process of EIPs more modular, and have updates to existing active</code> EIPs receive similar exposures to EIPs which replace existing final</code> EIPs.</p>
Motivation</h2>
Currently, EIP1 specifies EIP headers: updated</code>, replaces</code>, and superseded-by</code>. Headers replaces</code> and superseded-by</code> indicates when an entire EIP is being replaced by another EIP, indicating when an EIP is now historical, and is updated by a new standard.</p>
The header updated</code> indicates the date an EIP has received an update by EIP authors and editors, an example EIP being EIP1. updated</code> is reserved for EIPs in draft</code> or active</code> status.</p>
In the case of active</code> status, an EIP may receive an update, but these updates don't operate as with EIPs in final</code> status, where a historical EIP is created, and the new EIP is referenced by the historical one. While these updates are not kept immutably, updates to active EIPs can be done modularly by creating a new EIP that goes through the standard discussion and auditing process EIPs undergo. The EIP headers updates</code> and updated-by</code> are to facilitate this modularity. Creating a new EIP also provides sufficient notification to affected stakeholders of an active EIP before that EIP is updated</code>.</p>
Specification</h2>
updated-by</code></h3>
updated-by</code> is reserved for EIPs in active</code> status. For an EIP in status active</code>, updates to that EIP, which update the header updated</code>, should be started by opening a new EIP to start vetting for that update. When an active</code> EIP receives a new entry to header updated</code>, an associated updated-by</code> EIP listing should be included, where that newly listed EIP has reached final</code> status.</p>
updates</code> should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:</p>
---</span></span>
updated-by: 9999, 9998, 9997</span></span>
---</span></span></code></pre>updates</code></h3>
updates</code> is reserved for EIPs updating EIPs in active</code> status. An EIP listed as updates</code> is implied to also be requires</code>; only updates</code> is needed for those EIP listings. Having an EIP listing updates</code> does not necessarily mean that referenced EIP must reference back with an updated-by</code> listing.</p>
updates</code> should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:</p>
---</span></span>
updates: 1</span></span>
---</span></span></code></pre>Rationale</h2>
updates</code> and updated-by</code> apply only to EIPs in active</code> status as updates to EIPs in final</code> status are already handled by EIP headers superseded-by</code> and replaces</code>.</p>
The syntax should align with previous EIP header syntax, as this EIP is not updating syntax, simply adding header options.</p>
Backwards Compatibility</h2>
These EIP headers are optional and do not introduce compatibility issues.</p>
Implementation</h2>
An implementation is adding a header option.</p>
Security Considerations</h2>
This standard is informational and does not introduce technical security issues.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Explicit bound to Chain ID size
2019-09-19T00:00:00+00:00
Abstract</h2>
This EIP informationally defines the "Safe Range" and "Max Range" of ChainId based on a few known restrictions such as EIP-155</a> and major wallet and JSON-RPC representation of ChainId.</p>
Motivation</h2>

We want chainId to be safe across the different components of the ecosystem such as smart contract, wallet, dApp and JSON-RPC etc.</li>
We want to enable Cross-Chain function call</li>
We want to ensure EIP-712</a> domains have a clear definition of how to pack ChainID.</li>
Enable possible expansion of chains, such as increasing amount of L2s, L3s, or shards of Ethereum mainnets.</li>
Enable hashed based temporary chain: There have been suggestions of using a hash-based identifier in place on Chain ID to allow the value to adapt over time to different contentious forks and other scenarios. This proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose.</li>
</ol>
Specification</h2>
We declared the following chainID range</p>

(1, 2^31 - 1): "Safe Range", the higher bound is decided by Javascript number</li>
(1, MAX_CHAIN_ID);  "Max Range", in which MAX_CHAIN_ID := floor(MAX_UINT64 / 2) - 36 = 9,223,372,036,854,775,771</code>:</li>
</ol>
Rationale</h2>
Beyond "Max Range", the EIP-155 will overflow as discussed below</h3>
The MAX_CHAIN_ID</code> is calculated to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed.</p>
Due to how the calculation for chain ID is performed, the maximum value seen during the arithmetic is CHAIN_ID * 2 + 36</code>, so clients must test to ensure no overflow conditions are encountered when the highest value is used. No underflow is possible.</p>
EIP-155 introduces the Chain ID parameter, which is an important parameter used for domain separation (replay protection) of Ethereum protocol signed messages. However, it does not specify any properties about the size that this parameter takes. Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the v field.</p>
and suggests a reasonable maximum enforced size in order to ensure that there are no issues when encoding this parameter. This would allow a sufficient amount of different values for this parameter, which is typically chosen by community consensus as a genesis parameter for a given chain and thus does not change often.</p>
Without a well-chosen value of Chain ID, there could be differences in the implementation of EIP-155</a> (and EIP-1344</a> by derivative) in both client codebase and external tooling that could lead to consensus-critical vulnerabilities being introduced to the network. By making this limit explicit, we avoid this scenario for Ethereum and any project which uses the Ethereum codebase.</p>
Also, the field chainID</code> has experienced increasing usage and dependencies, due more and more contracts are depending on EIP-1344</a> to expose CHAIN ID in the smart contract execution. For example when used with EIP-712</a>, ERC-1271</a> for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yields identical result for verification in
all cases.</p>
Backwards Compatibility</h2>
This EIP introduces a change that affects previous implementations of this feature. However, as of time of writing(2022-10-18) no known chain makes use of a value outside of the suggested bounds, there should not be an issue in adopting this limit on the size of this parameter, therefore the impact should be non-existent.</p>
If any other chain is operating with an incompatible chainId</code>, we advised they make proper arrangement when this EIP becomes adopted.</p>
Security Considerations</h2>
Needs discussion.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Canonicalize the name of network ID 1 and chain ID 1
2019-08-04T00:00:00+00:00
Simple Summary</h2>
The Ethereum network with network ID 1 and chain ID 1 is named Ethereum Mainnet.</p>
Abstract</h2>
The name for the Ethereum network with network ID 1 and chain ID 1 shall be Ethereum Mainnet or just Mainnet. This is a proper noun.</p>
This standard specifies the name for this network and provides reference examples in an effort to standardize the word choice and provide a common language for use to refer to this network.</p>
Motivation</h2>
The Ethereum network with network ID 1 and chain ID 1 is referenced using several conflicting names across EIPs, client implementations, and information published on the internet at large. In several locations, even documents written by the same author use inconsistent names to refer to the Ethereum network with network ID 1 and chain ID 1. Names in use at the time of this writing include:</p>

"main net"</li>
"mainnet"</li>
"Main net"</li>
"Mainnet"</li>
</ul>
Specification</h2>
The network name for network ID 1 and chain ID 1 shall be Ethereum Mainnet, or just Mainnet if the context is known to be discussing Ethereum networks. This IS a proper noun. Several examples are given below which differentiate between usage of the name of the network versus a descriptive reference to the network.</p>
Any name or word styling (i.e. capitalization of the letters) of the network which is inconsistent with the test cases cited below shall NOT be used.</p>
Trademark note</h3>
"Ethereum" is trademarked by the Ethereum Foundation. For more information on your obligations when mentioning "Ethereum", and possibly "Ethereum Mainnet", see:</p>

USPTO registration number 5110579 by Ethereum Foundation</li>
The note "you must not use [this mark] without the prior written permission of the Foundation" on the Ethereum Foundation website, Terms of Use page</li>
</ul>
Rationale</h2>
Choosing common word use promotes interoperability of implementations and increases customer awareness. Also, it adds a sense of professionalism when customers see the same word and word styling (i.e. capitalization of letters) across different implementations.</p>
Anybody that has travelled to certain countries and seen an "IPhone [sic]" repair store should immediately recognize that this is off-brand and unofficial. Likewise, the astute customer of Ethereum should recognize if they see the network referred to using inconsistent names in different software, so let's avoid this.</p>
Backwards Compatibility</h2>


MetaMask previously used "Main Ethereum Network" in the account network chooser. MetaMask has been updated consistent with this EIP.</p>
</li>

References to Mainnet that are inconsistent with this specification are made in: EIP-2</a>, EIP-779</a>, EIP-150</a>, EIP-155</a>, EIP-190</a>, EIP-225</a>, EIP-1013</a>, EIP-2028</a>, and EIP-2387</a>. For consistency, we recommend the editor will update EIPs to consistently use the name as specified in this EIP.</p>
</li>
</ul>
Test Cases</h2>
Examples referencing the name of the network ✅</h3>

The contract was deployed to Ethereum Mainnet.</p>
</blockquote>

Ethereum runs many applications, this Dapp was deployed to Mainnet.</p>
</blockquote>
No specification is made on whether Dapp, dapp, dApp, etc. is preferred.</p>

SWITCH TO MAINNET</p>
</blockquote>
This example shows a user interface which is in uppercase. To be semantically correct, this could be written in HTML as <span style="text-transform: uppercase">Switch to Mainnet</span></code>.</p>

switch to mainnet</p>
</blockquote>
This example shows a user interface which is in lowercase. To be semantically correct, this could be written in HTML as <span style="text-transform: lowercase">Switch to Mainnet</span></code>.</p>
Examples referencing the network in a descriptive way ✅</h3>

Mainnet has ### times the number of transactions as the test networks.</p>
</blockquote>
Examples of other correct word usage ✅</h3>

The main network on Ethereum is Mainnet</p>
</blockquote>
This shows that "main" is used as a descriptive word, but Mainnet is the specific network which is having network ID 1 and chain ID 1.</p>
Examples of poor word choice (avoid this) ❌</h3>

Deploy your contract to the Ethereum main network.</p>
</blockquote>
This is referring to a "main" network which is context-dependent. If you were reading this text on a page about Ethereum Classic, they would be referring to network ID 2 and chain ID 62. Therefore this word usage is less crisp. Do NOT use wording like this.</p>

Connect to mainnet.</p>
</blockquote>
These words literally mean nothing. The lowercase, not-proper-noun word "mainnet" is not a plain English word and it should not be in any dictionary. Do NOT use wording like this.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Smart Contract Weakness Classification (SWC)
2018-09-18T00:00:00+00:00
Simple Summary</h2>
This EIP proposes a classification scheme for security weaknesses in Ethereum smart contracts.</p>
Abstract</h2>
The SWC is a smart contract specific software weakness classification scheme for developers, tool vendors and security practitioners. The SWC is loosely aligned to the terminologies and structure used in the Common Weakness Enumeration - CWE</a> scheme while overlaying a wide range of weakness variants that are specific to smart contracts.</p>
The goals of the SWC scheme are as follows:</p>

Provide a straightforward way to classify weaknesses in smart contract systems.</li>
Provide a straightforward way to identify the weakness(es) that lead to a vulnerability in a smart contract system.</li>
Define a common language for describing weaknesses in smart contract systems' architecture, design and code.</li>
Train and increase the performance of smart contract security analysis tools.</li>
</ul>
Motivation</h2>
In the software security industry, it is a widely accepted practice to use a common terminology and to classify security related bugs and errors with a standardized scheme. While this has not stopped vulnerabilities from appearing in software, it has helped communities focusing on web applications, network protocols, IOT devices and various other fields to educate users and developers to understand the nature of security related issues in their software. It has also allowed the security community to quickly understand vulnerabilities that occur in production systems to perform root cause analysis or triage findings from various security analysis sources. In recent years various organizations and companies also published vulnerability data to find the most widespread security issues based on collected vulnerability data. Two examples that are widely used and referred to are the SANS TOP 25 Most Dangerous Software Errors</a> and the OWASP TOP 10</a>. None of those publications would have been possible without a common classification scheme.</p>
At present no such weakness classification scheme exists for weaknesses specific to Ethereum Smart Contracts. Common language and awareness of security weaknesses is mostly derived from academic papers, best practice guides and published articles. Findings from audit reports and security tool analysis add to the wide range of terminologies that is used to describe the discovered weaknesses. It is often time consuming to understand the technical root cause and the risk associated to findings from different sources even for security experts.</p>
Rationale</h2>
While recognizing the current gap, the SWC does not aim to reinvent the wheel in regards to classification of security weaknesses. It rather proposes to build on top of what has worked well in other parts of the software security community -  specifically the Common Weakness Enumeration (CWE), a list of software vulnerability types that stands out in terms of adoption and breadth of coverage. While CWE does not describe any weaknesses specific to smart contracts, it does describe related weaknesses at higher abstraction layers. This EIP proposes to create smart contract specific variants while linking back to the larger spectrum of software errors and mistakes listed in the CWE that different platforms and technologies have in common.</p>
Specification</h2>
Before discussing the SWC specification it is important to describe the terminology used:</p>

Weakness: A software error or mistake that in the right conditions can by itself or coupled with other weaknesses lead to a vulnerability.</li>
Vulnerability: A weakness or multiple weaknesses which directly or indirectly lead to an undesirable state in a smart contract system.</li>
Variant: A specific weakness that is described in a very low detail specific to Ethereum smart contracts. Each variant is assigned a unique SWC ID.</li>
Relationships: CWE has a wide range of Base</em> and Class</em> types that group weaknesses on higher abstraction layers. The CWE uses Relationships</em> to link SWC smart contract weakness variants to existing Base</em> or Class</em> CWE types. Relationships</em> are  used to provide context on how SWCs are linked to the wider group of software security weaknesses and to be able to generate useful visualisations and insights through issue data sets. In its current revision it is proposed to link a SWC to its closest parent in the CWE.</li>
SWC ID: A numeric identifier linked to a variant (e.g. SWC-101).</li>
Test Case: A test case constitutes a micro-sample or real-world smart contract that demonstrates concrete instances of one or multiple SWC variants. Test cases serve as the basis for meaningful weakness classification and are useful to security analysis tool developers.</li>
</ul>
The SWC in its most basic form links a numeric identifier to a weakness variant. For example the identifier SWC-101</em> is linked to the Integer Overflow and Underflow</em> variant. While a list with the weakness title and a unique id is useful by itself, it would also be ambiguous without further details. Therefore the SWC recommends to add a definition and test cases to any weakness variant.</p>
SWC definition</strong></p>
A SWC definition is formatted in markdown to allow good readability and tools to process them easily. It consists of the following attributes.</p>

Title: A name for the weakness that points to the technical root cause.</li>
Relationships: Links a CWE Base</em> or Class</em> type to its CWE variant. The Integer Overflow and Underflow</em> variant for example is linked to CWE-682 - Incorrect Calculation</a>.</li>
Description: Describes the nature and potential impact of the weakness on the contract system.</li>
Remediation: Describes ways on how to fix the weakness.</li>
References: Links to external references that contain relevant additional information on the weakness.</li>
</ul>
Test cases</strong></p>
Test cases include crafted as well as real-world samples of vulnerable smart contracts. A single test case consists of three components:</p>

Source code of a smart contract sample; e.g. Solidity, Vyper, etc.</li>
Compiled asset from an EVM compiler in machine readable format; e.g. JSON or ethPM.</li>
Test result configuration that describes which and how many instances of a weakness variant can be found in a given sample. The YAML schema for the proposed test case configuration is listed below.</li>
</ol>
t</span>itle</span>:</span> S</span>WC config</span></span>
t</span>ype</span>:</span> o</span>bject</span></span>
r</span>equired</span>:</span></span>
-</span> d</span>escription</span></span>
-</span> i</span>ssues</span></span>
p</span>roperties</span>:</span></span>
  d</span>escription</span>:</span></span>
    t</span>ype</span>:</span> s</span>tring</span></span>
  i</span>ssues</span>:</span></span>
    t</span>itle</span>:</span> I</span>ssues</span></span>
    t</span>ype</span>:</span> a</span>rray</span></span>
    i</span>tems</span>:</span></span>
      t</span>itle</span>:</span> I</span>ssue</span></span>
      t</span>ype</span>:</span> o</span>bject</span></span>
      r</span>equired</span>:</span></span>
      -</span> i</span>d</span></span>
      -</span> c</span>ount</span></span>
      p</span>roperties</span>:</span></span>
        i</span>d</span>:</span></span>
          t</span>ype</span>:</span> s</span>tring</span></span>
        c</span>ount</span>:</span></span>
          t</span>ype</span>:</span> n</span>umber</span></span>
        l</span>ocations</span>:</span></span>
          i</span>tems</span>:</span></span>
            b</span>ytecode_offsets</span>:</span></span>
              t</span>ype</span>:</span> o</span>bject</span></span>
            l</span>ine_numbers</span>:</span></span>
              t</span>ype</span>:</span> o</span>bject</span></span></code></pre>Implementation</h2>
The Smart Contract Weakness Classification registry located in this GitHub repository</a> uses the SWC scheme proposed in this EIP. A GitHub Pages rendered version is also available here</a>.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Recommendation for using YAML ABI in ERCs/EIPs
2017-02-11T00:00:00+00:00
Simple Summary</h2>
Recommendation for including contract ABI descriptions in EIPs and ERCs as YAML.</p>
Motivation</h2>
In the past, most ERCs/EIPs included an ABI description purely as a Solidity contract and/or interface. This has several drawbacks:</p>

Prefers a single language over others and could hinder the development of new languages.</li>
Locks the specification to a certain version of the Solidity language.</li>
Allows the use of syntactical elements and features of the Solidity language, which may not be well representable in the ABI. This puts other languages at even more disadvantage.</li>
</ul>
This proposal aims to solve all these issues.</p>
Specification</h2>
The Standard Contract ABI</a> is usually represented as a JSON object.  This works well and several tools – including compilers and clients – support it to handle data encoding.</p>
One shortcoming of the JSON description is its inability to contain comments.  To counter this, we suggest the use of YAML for providing user readable specifications.  Given YAML was designed to be compatible with JSON, several tools exist to convert between the two formats.</p>
The following example contains a single function, transfer</code> with one input and one output in YAML:</p>
#</span> The transfer function. Takes the recipient address</span></span>
#</span> as an input and returns a boolean signaling the result.</span></span>
-</span> n</span>ame</span>:</span> t</span>ransfer</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  p</span>ayable</span>:</span> false</span></span>
  c</span>onstant</span>:</span> false</span></span>
  s</span>tateMutability</span>:</span> n</span>onpayable</span></span>
  i</span>nputs</span>:</span></span>
  -</span> n</span>ame</span>:</span> r</span>ecipient</span></span>
    t</span>ype</span>:</span> a</span>ddress</span></span>
  -</span> n</span>ame</span>:</span> a</span>mount</span></span>
    t</span>ype</span>:</span> u</span>int256</span></span>
  o</span>utputs</span>:</span></span>
  -</span> n</span>ame</span>:</span> '</span>'</span></span>
    t</span>ype</span>:</span> b</span>ool</span></span></code></pre>
Specifications are encouraged to include comments in the YAML ABI.</p>
For details on what fields and values are valid in the ABI, please consult the Standard Contract ABI</a> specification.</p>
The same in JSON:</p>
[</span></span>
  {</span></span>
    "</span>name</span>"</span>:</span> "</span>transfer</span>"</span>,</span></span>
    "</span>type</span>"</span>:</span> "</span>function</span>"</span>,</span></span>
    "</span>payable</span>"</span>:</span> false</span>,</span></span>
    "</span>constant</span>"</span>:</span> false</span>,</span></span>
    "</span>stateMutability</span>"</span>:</span> "</span>nonpayable</span>"</span>,</span></span>
    "</span>inputs</span>"</span>:</span> [</span></span>
      {</span></span>
        "</span>name</span>"</span>:</span> "</span>recipient</span>"</span>,</span></span>
        "</span>type</span>"</span>:</span> "</span>address</span>"</span></span>
      }</span>,</span></span>
      {</span></span>
        "</span>name</span>"</span>:</span> "</span>amount</span>"</span>,</span></span>
        "</span>type</span>"</span>:</span> "</span>uint256</span>"</span></span>
      }</span></span>
    ]</span>,</span></span>
    "</span>outputs</span>"</span>:</span> [</span></span>
      {</span></span>
        "</span>name</span>"</span>:</span> "</span>"</span>,</span></span>
        "</span>type</span>"</span>:</span> "</span>bool</span>"</span></span>
      }</span></span>
    ]</span></span>
  }</span></span>
]</span></span></code></pre>Rationale</h2>
The aim was to choose a representation which is well supported by tools and supports comments. While inventing a more concise description language seems like a good idea, it felt as an unnecessary layer of complexity.</p>
Backwards Compatibility</h2>
This has no effect on backwards compatibility.</p>
Test Cases</h2>
TBA</p>
Implementation</h2>
yamabi</a> is a Javascript tool to convert between the above YAML and the more widely used JSON format.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>