ABAB Pedia

Ethereum

Ethereum is an open, general-purpose smart contract blockchain that launched in 2015, and its native asset is ether (ETH). The project was proposed by Vitalik ButerinVitalik ButerinVitalik Buterin is the originator of Ethereum, the author of its whitepaper, and one of its eight co-founders, as well as a co-founder of Bitcoin Magazine. The Ethereum Foundation calls him the inventor of Ethereum; he has long been involved in protocol research and public discussion, but does not control the network as a CEO.Open the full entry and advanced jointly by eight co-founders; the network now uses proof of stake and centers on the EVM, the account model, a rollup scaling roadmap, and the open EIP process.

Contents61 sections
Key facts

The White Paper Proposes General-Purpose Blockchain Computing

In late 2013, Vitalik Buterin produced the Ethereum white paper, arguing that blockchains should be extended from a single-purpose payment ledger into a general-purpose platform capable of executing arbitrary state transitions. Accounts, contract code, persistent storage, and gas together make up the model, enabling developers to create tokens, financial contracts, organizations, and other decentralized applications on a shared state machine.⁠[1]

The Yellow Paper: From Vision Document to Executable Specification

The white paper explains why Ethereum needs general-purpose state and contracts; the Yellow Paper, written by Gavin WoodGavin WoodGavin Wood is a computer scientist and co-founder of Ethereum who wrote the Ethereum Yellow Paper and helped design core technologies such as the EVM, gas, and Solidity; after leaving the Ethereum Foundation he founded Parity Technologies and the Web3 Foundation and proposed Polkadot.Open the full entry, uses mathematical notation to define blocks, transactions, world state, gas, receipts, and EVM state transitions. Clients do not directly “run the white paper”; they implement these consensus rules and the specifications of later hard forks, and the network can remain a single chain only if different implementations produce the same result for the same input. The Yellow Paper is versioned as forks occur, and the Berlin version is not the same as all of the rules in force on mainnet in 2026. The modern protocol is also described jointly by the execution specifications, the consensus specifications, the Engine API, and individual EIPs, so no single PDF can permanently represent Ethereum’s complete, up-to-date specification.⁠[2]

Account Model: Externally Owned Accounts and Contract Accounts

Ethereum’s global state is made up of accounts. Externally owned accounts (EOAs) are controlled by private keys and can actively create and sign transactions; contract accounts have no private key and execute their deployed bytecode only when they receive a transaction or an internal message call. Both can hold ETH and tokens, but only EOAs can directly initiate top-level transactions.⁠[3]

Each account is described by at least a nonce, balance, codeHash, and storageRoot. An EOA’s nonce records the number of transactions it has sent and prevents the same signed transaction from being executed more than once; a contract account’s nonce helps determine the addresses of the new contracts it creates. The account model allows a single transaction to read and modify the state of multiple contracts in succession, but it also requires all nodes to reach the same result for the same state transition.⁠[3]

Ether, Wei, Gwei, and Gas Are Not the Same Concept

Ethereum is the network and protocol; ether is the network’s native asset and is usually written as ETH in code and market data. Wei is the smallest accounting unit, and 1 ETH equals 10^18 wei; gwei equals 10^9 wei and is commonly used to display the price per unit of gas. Gas itself is not a token but a measure of the work involved in computation, storage, and state access. A transaction’s total execution fee is roughly the gas actually used multiplied by the price per unit; since London, that price has consisted of the protocol base fee plus the user’s priority fee. Treating “high gas” as an amount of ETH, calling ETH shares in a protocol company, or taking a transfer’s gas limit as its final fee all confuse different layers.⁠[4]

Transaction Structure: Nonce, Signature, Value, Calldata, and Types

Top-level transactions are signed and broadcast by externally owned accounts; their core fields include the nonce, the recipient address, the value transferred, the call data, the gas limit, and fee parameters. The nonce both sets the order of an account’s transactions and prevents the same signed transaction from being executed more than once; an empty to field indicates contract creation, while data can carry constructor arguments or an ABI-encoded function selector and arguments. EIP-2718 introduced the typed transaction envelope, allowing new formats such as access lists, EIP-1559 fees, and blobs to coexist without breaking the legacy format. A signature only proves that the corresponding key authorized that byte string; it does not guarantee that the recipient address is trustworthy, that a contract call matches the user’s true intent, or that the result will succeed.⁠[5]

Receipts, Logs, and the Limits of On-Chain Indexing

Executing a transaction produces a receipt recording information such as success status, cumulative gas, logs, and a bloom filter; contracts emit events through the LOG opcode, and wallets, explorers, and indexers use them to retrieve ERC-20 transfers, NFT mints, or application state changes. Logs are written into receipts and protected by block commitments, but contracts cannot read them back as ordinary storage. “The transaction is on-chain” does not mean the business operation is complete: state may be unchanged because of a revert, and cross-chain services and exchanges may wait for more confirmations. Ordinary internal ETH transfers have long lacked a unified event log, so many services rely on execution traces; as of September 2026, the planned EIP-7708 was trying to fill this observability gap, but it cannot yet be treated as live.⁠[5]

EVM: Deterministic State Machine, 256-Bit Stack, and Persistent Storage

The Ethereum Virtual Machine models the network as a deterministic state transition function: given an old state and a set of valid transactions, all compatible implementations should produce the same new state. The EVM is a stack machine with a maximum depth of 1024 items of 256 bits each, and bytecode operates through opcodes; temporary memory is cleared at the end of each call, while contract storage is written to the global state tree and persists across transactions.⁠[6]

Gas prices every kind of computation and storage operation, both limiting the work a single transaction can perform and protecting validating nodes from infinite loops and costless resource consumption. When a transaction runs out of gas, its state changes are rolled back, but the computation already performed still incurs fees. EVM compatibility means compatible execution semantics; it does not guarantee application security, identical governance, or trustless transfer of assets between chains.⁠[6]

Smart Contract Storage, Memory, and Call Context

A smart contract is code running at an address, made up of functions and state data. Storage persists across transactions and counts toward state costs; memory exists only during the execution of a single call and costs less; the stack is used for local computation by EVM instructions. msg.sender denotes the current caller, which may be a user or another contract, and cannot automatically be equated with the ultimate human. An external call hands control to the called contract, and the value, calldata, gas, and return values along the call chain together determine the outcome. A contract being publicly readable does not mean it is easy to understand; bytecode, proxies, libraries, compiler versions, and off-chain components all affect its actual behavior.⁠[7]

Not Every Component of a Dapp Is Decentralized

An Ethereum dapp typically uses contracts as an on-chain backend or open API, with web pages, mobile apps, wallets, and indexing services providing the user interface. Contracts can compose calls to other people’s contracts, and front ends can be hosted on distributed storage such as IPFS, but many products still depend on centralized domain names, cloud servers, RPC providers, databases, and administrators. Therefore, “deployed on Ethereum” only shows that certain state transitions are verified by mainnet; it does not automatically imply that the front end will never go down, that price data is reliable, that upgrade authority is decentralized, or that user privacy is protected. Evaluating an application requires identifying, layer by layer, its contracts, proxies, oracles, sequencers, bridges, front end, and custodians.⁠[8]

Upgradeable Proxies: Repair Capability and Administrator Power Coexist

The code at a mainnet contract address usually cannot be replaced directly, so projects often have users call a proxy, which uses delegatecall to hand the logic off to a mutable implementation contract. ERC-1967 specifies fixed storage slots for the implementation, beacon, and admin, and recommends emitting events on upgrades to help explorers and monitoring systems identify the current logic. Proxies can patch vulnerabilities and iterate on features, but they introduce risks around administrator keys, timelocks, governance, initialization, and storage layout. When users interact with “the same address,” the code actually executed may have changed; standardized slots improve transparency but do not make an upgrade itself safe, nor do they prove that administrators cannot maliciously replace the logic.⁠[9]

Node Architecture: Execution Layer, Consensus Layer, and Validators

Since the Merge, a full Ethereum node typically runs both an execution client and a consensus client. The execution client receives transactions, maintains EVM state, and builds or validates execution payloads; the consensus client runs proof of stake, tracks the Beacon Chain, and reaches agreement on the chain head and finality. To take part in block production and attestation, validator functionality must also be connected to the consensus client.⁠[10]

The two layers cooperate through the local Engine API, so running a legacy execution client alone does not form a complete mainnet node. Full nodes verify blocks and state but can prune historical data; archive nodes retain queryable historical state at a significantly higher storage cost. Multiple client implementations provide fault isolation for the same specification, but operators still need to handle upgrades, secure configuration, and monitoring.⁠[10]

Testnets: Sepolia for Applications, Hoodi for Protocol and Staking

As of September 2026, the main public testnets maintained by client teams are Sepolia and Hoodi. Sepolia uses a permissioned validator set and is suited to contract and application development; Hoodi offers an open validator set and a larger state and is mainly used for validators, staking infrastructure, and rehearsals of mainnet upgrades. Holesky was deprecated in September 2025, and older networks such as Goerli should no longer serve as current defaults either. Testnet ETH has no economic value, and passing tests does not prove that a mainnet contract is secure: network scale, liquidity, MEV, oracles, and administrator configuration may be entirely different.⁠[11]

Eight Co-Founders and a Nonprofit Structure

The Ether Presale

The project raised development funds through a public presale in which participants used bitcoin to buy ether that would be allocated when mainnet launched. The presale established the initial allocation and a source of funding for the foundation; it took place before mainnet was available and should not be conflated with later secondary-market trading or proof-of-stake issuance.⁠[13]

Genesis Allocation: Sale, Early Contributors, and the Foundation

The 2014 public sale ultimately allocated about 60 million ETH. At mainnet genesis, early contributors and the Ethereum Foundation were each additionally allocated about 6 million ETH, at 10% of the amount sold each, bringing the initial supply to about 72 million ETH in total. The early-contributor portion was intended for people who worked on development, legal matters, organization, and community before mainnet launched, and was not equity in a traditional company.⁠[14]

The genesis allocation describes the initial ledger of July 30, 2015, and cannot be used to infer the balances of any founder, the foundation, or any purchaser at later dates. Since then, proof-of-work block rewards, Beacon Chain staking rewards, post-Merge proof-of-stake issuance, and EIP-1559 burning have together changed the total supply.⁠[14]

Frontier Mainnet Launches

The Frontier phase started the genesis block on July 30, 2015, and developers began deploying real contracts and running nodes. The initial network used proof of work, transaction execution was defined by the EVM, and ETH was used both to pay for gas and to reward miners.⁠[15]

Homestead Ends the Early Experimental Phase

Homestead activated at block 1,150,000 and was the first planned mainnet hard fork after Frontier. Through EIP-2 it adjusted the rules for failed contract creation, transaction signature malleability, and mining difficulty; through EIP-7 it added DELEGATECALL; and with EIP-8 it made the networking protocol more tolerant of future version fields. The upgrade moved the network from the Frontier phase, “usable by developers but requiring caution,” toward a more stable production environment. A hard fork does not shut down the old chain and create a new one; rather, nodes switch validation rules at an agreed height, and clients that have not upgraded reject blocks produced under the new rules from that height on.⁠[16]

EIP Governance: Proposals, Implementation, and Rough Consensus

Ethereum has no single governing body, such as a foundation board or a token-holder vote, that directly approves protocol upgrades. Anyone can draft an Ethereum Improvement Proposal; the author is responsible for providing the technical specification, rationale, and security considerations and for building consensus in forums, among client teams, and in the community. EIPs move through stages such as Draft, Review, Last Call, and Final, and core changes must also be implemented by multiple clients and reach rough consensus in public coordination venues such as AllCoreDevs.⁠[17]

Whether a hard fork is ultimately adopted is still determined jointly by client developers releasing software, node operators installing versions, validators building the chain, and users and applications choosing an ecosystem. This process reduces control by any single organization, but it can be slow, depends on a high technical bar, and puts pressure on client teams to judge non-technical disputes. An EIP number or Final status also does not mean it is live on mainnet.⁠[17]

Devcon and Public Technical Coordination

Devcon is a public conference and knowledge archive for the Ethereum ecosystem focused on protocol research, client engineering, application development, and community governance. The Ethereum Foundation’s official channel preserves keynote talks and technical discussions; Vitalik Buterin’s 30-minute retrospective at Devcon SEA explained the network, smart contracts, transactions, gas, PoS, fork choice, finality, and L2s within a single framework. Conference talks reflect the technical judgment of their authors and of the community at the time and are not equivalent to adopted EIPs or mainnet rules. Distinguishing talks, AllCoreDevs discussions, EIP status, and final client releases avoids conflating research ideas and roadmaps with deployed facts.⁠[18]

ERC-20: A Composable Token Interface and Its Limits

ERC-20 specifies the common functions and events of fungible token contracts, including totalSupply, balanceOf, transfer, approve, allowance, and transferFrom, as well as the Transfer and Approval events. As long as wallets, exchanges, and applications call the same interface, they can display balances, approvals, and transfers without knowing each token’s internal implementation, which became the foundation for ICOs, stablecoins, governance tokens, and DeFi composability.⁠[19]

The standard only defines an interface; it does not audit implementations, issuer reserves, governance permissions, legal status, or economic value. Unlimited allowances, non-standard return values, upgradeable proxies, administrator minting/freezing, and malicious token logic can still cause losses. Showing “ERC-20” on-chain cannot be treated as an endorsement by the Ethereum Foundation.⁠[19]

ENS: A Resolution Layer from Human-Readable Names to On-Chain Resources

ENS replaces hard-to-remember hexadecimal addresses with names. ERC-137 divides the system into a registry, resolvers, and registrars: the registry records which resolver handles a name, the resolver returns resources such as an address or content hash, and the registrar is responsible for allocating names; namehash deterministically maps a name at any level to a 32-byte node. ENS resolution is an on-chain protocol, not DNS, and it does not guarantee that a displayed name corresponds to a real person or organization. Name expiration, malicious registration, look-alike characters, address poisoning, and resolver updates can all mislead users, so the final address and wallet prompts should still be checked before paying.⁠[20]

The DAO Incident, the Fork, and Ethereum Classic

A vulnerability in the DAO contract led to a large amount of ETH being moved, and the community debated fiercely over whether to recover the funds through a protocol fork. The chain that the majority adopted with the state change continued to use the Ethereum name, while the chain that rejected the change became Ethereum Classic. The incident showed that on-chain code, social consensus, and client choice together determine how a public network evolves.⁠[16]

The Shanghai DoS Attacks and Two Emergency Forks

From September to October 2016, attackers repeatedly invoked operations that were underpriced at the time but actually required heavy disk and state access, significantly slowing block processing on nodes. Tangerine Whistle first raised the gas costs of the relevant opcodes on October 18, restoring network health; Spurious Dragon followed on November 22, repricing EXP, clearing empty accounts created by the attacks, limiting contract code size, and adding chain ID replay protection. The incident showed that the gas schedule is a security parameter rather than a permanent price list: changes in hardware and attack strategies can make old pricing inaccurate. The emergency forks addressed protocol resource pricing and state bloat; they did not compensate for stolen funds and should not be conflated with the DAO fork of the same year.⁠[21]

The DAO Fork’s Refund Contract, Vote, and Ethereum Classic

After more than 3.6 million ETH was drained from The DAO contract, the contract’s mechanics temporarily prevented the funds from being moved right away. The fork at block 1,920,000 transferred the affected balances into a recovery contract with only a withdrawal function, from which DAO token holders could withdraw at a rate of 100 DAO for 1 ETH. In the on-chain sentiment vote, more than 85% of votes supported the fork, but participation rates, token weighting, and whether “code should be rewritten by society” remained the subject of long-running controversy. Miners and users who rejected this state change continued the chain under the old rules, forming Ethereum Classic. It was a permanent chain split brought about by both a value judgment and software coordination, demonstrating that open code allows different groups to copy state and choose different rules; neither official bodies, the foundation, nor a majority vote can technically delete the other chain.⁠[16]

Byzantium Expands the EVM and Zero-Knowledge Capabilities

Byzantium activated at block 4,370,000, reducing the PoW block reward from 5 ETH to 3 ETH and delaying the difficulty bomb. EIP-140 added REVERT, allowing contracts to return a reason on failure without consuming all remaining gas; EIP-658 wrote success status into receipts; STATICCALL allowed read-only calls; and variable-length return data improved contract composition. EIP-196 and EIP-197 added alt_bn128 elliptic curve precompiles, lowering the on-chain cost of zk-SNARK verification at the time. These primitives provided tools for privacy and scaling applications, but the protocol only guarantees instruction semantics and does not audit each proof circuit or application parameter.⁠[16]

The Parity Multisig Shared Library Is Destroyed

On November 6, 2017, a user took ownership of the shared library contract used by Parity multisig wallets and called selfdestruct. The 587 wallets that depended on the library lost their executable logic, and 513,774.16 ETH plus additional tokens were frozen. The problem stemmed from a type of wallet architecture deployed after July 20 and from the initialization of the shared library; it was not a case of the Ethereum consensus layer deleting these balances. Recovering the funds would require changing on-chain semantics or a separate fork, and the related proposals did not take effect automatically. The incident illustrated the systemic consequences of code reuse: a single shared implementation can affect a large number of addresses at once, and “contracts are immutable” both protects the rules and can permanently entrench application errors.⁠[22]

CryptoKitties Brings the Capacity Bottleneck to Public Attention

CryptoKitties launched in November 2017, letting users buy, breed, and trade unique digital cats through contracts. Dapper Labs’ official repository says that at its peak it accounted for up to about 25% of Ethereum traffic; heavy interaction drove up pending transactions and fees, and for the first time a consumer application made the early mainnet’s limited throughput a subject of wide discussion. This was not a chain halt, nor a constant metric of CryptoKitties “using 25% of computing power”; it was an application’s share of transactions during a specific peak. The episode both spread NFTs, on-chain games, and digital scarcity and exposed the cost and scaling limits of executing every breeding action on L1.⁠[23]

ERC-721: Non-Fungible Identifiers and the Limits of Rights

ERC-721 establishes a unique owner for each tokenId and standardizes interfaces such as ownerOf, safeTransferFrom, approve, and setApprovalForAll. Unlike ERC-20’s interchangeable balances, each ERC-721 identifier can point to different metadata or application state, driving use cases such as collectibles, game items, memberships, and on-chain credentials. safeTransferFrom checks whether the receiving contract implements the corresponding interface, reducing the risk of tokens being sent to a contract that cannot handle them.⁠[24]

On-chain ownership usually only proves that a given address controls a given tokenId; images, trademarks, copyrights, physical-world rights, and metadata on servers still depend on licenses, contracts, and storage arrangements. The standard also does not prevent fake mints, phishing approvals, market manipulation, or broken metadata.⁠[24]

ERC-1155: One Contract Managing Multiple Fungible and Non-Fungible Assets

ERC-1155 allows a single contract to use different token IDs to represent fungible, semi-fungible, or unique assets at the same time, and provides single and batch balance queries and transfers. Compared with deploying a separate ERC-20 or ERC-721 contract for each asset, batching reduces repeated calls and gas, and game items, tickets, and bundled assets can share one permission and event model. Safe-receipt checks can prevent assets from being sent by mistake to contracts that do not support the interface, but the standard still does not review metadata, minting permissions, operator approvals, or issuer commitments. Managing many assets in one contract also widens the blast radius of administrator keys or implementation bugs.⁠[25]

Constantinople Delayed and Corrected the Same Day by Petersburg

Constantinople was originally scheduled to go live in January 2019, but security research found that the gas changes in EIP-1283 could expose reentrancy paths in existing contracts, and the upgrade was temporarily postponed. On February 28, Constantinople and Petersburg activated on the same day at block 7,280,000; the latter specifically disabled EIP-1283, while the other changes went live. The upgrade reduced the PoW block reward from 3 ETH to 2 ETH and again delayed the difficulty bomb, and it also added CREATE2 deterministic addresses, EXTCODEHASH, and bitwise shift operations. The delay showed that an EIP that “has been included in an upgrade bundle” can still be withdrawn before release, and that client coordination and security review are themselves part of governance.⁠[16]

Istanbul Repricing and the Muir Glacier Bomb Defusal

Istanbul activated on December 8, 2019, repricing state access to strengthen DoS resistance, lowering the cost of some zero-knowledge proof operations, supporting chain differentiation with the CHAINID opcode, and lowering calldata costs, creating better conditions for data-intensive approaches such as rollups. Gas repricing could also break older contracts that rely on the fixed 2300-gas stipend, so developers had to review compatibility. Muir Glacier, on January 2, 2020, only delayed the difficulty bomb by about 4 million blocks. The difficulty bomb was originally intended to force the PoW network to coordinate upgrades periodically and eventually move to PoS, but its repeated postponements showed that the roadmap timeline had changed; it is not the same thing as a real shortage of hash power or an attack on the chain.⁠[16]

Smart Contract Security: Reentrancy, Permissions, and Composability Risks

When a contract calls an external address, it temporarily hands over control flow; if it transfers funds before updating internal balances, a malicious recipient can reenter the same function and withdraw repeatedly. Checks-Effects-Interactions, reentrancy locks, and pull-based withdrawals can reduce the risk, but developers must also guard against access-control errors, signature replay, delegatecall, integer boundaries, denial of service, and upgradeable proxy configuration. Solidity 0.8’s default integer overflow checks do not cover all economic vulnerabilities. Audits, formal verification, and bug bounties can only reduce risk and cannot prove the absence of bugs; cross-protocol composability can also let the failure of one oracle, stablecoin, or governance module propagate along the call chain.⁠[26]

Oracles: The Trust Boundary Between a Deterministic Blockchain and the Outside World

EVM nodes must reach the same result for the same on-chain input and cannot each directly access changing web APIs during execution. An oracle consists of on-chain contracts and off-chain nodes that submit data such as prices, weather, or match results to the chain as transactions; once the data enters the state, all nodes execute based on the same value. Oracles turn “where the data comes from, whether it is timely, and whether it has been manipulated” into additional trust assumptions. Multiple nodes that all read the same faulty source still do not amount to decentralized sourcing; spot prices can also be manipulated momentarily with flash loans. Time-weighted prices, multiple independent sources, emergency pauses, and economic penalties can reduce but not eliminate the risk.⁠[27]

The Beacon Chain Launches Independently

The Beacon Chain launched independently while the mainnet PoW chain was still running; genesis required at least 16,384 validator deposits of 32 ETH each. The threshold was reached on November 27, and block production began on December 1. The early Beacon Chain ran only PoS consensus and validator accounts and did not process the user transactions or smart contracts of the mainnet at the time. This parallel period gave multi-client PoS nearly two years of real-world operation before it carried the execution layer. The 2022 Merge did not migrate user assets to an entirely new chain; rather, it had blocks for the existing execution state determined by Beacon Chain consensus, so “two tokens, ETH1/ETH2” was always a misconception.⁠[16]

A Geth Consensus Bug Triggers a Short Side Chain

The Geth team disclosed that a shallow-copy bug in state objects affected versions 1.9.7 through 1.9.16; the fix had been quietly included in 1.9.17. In November 2020, the bug was triggered at mainnet block 11,234,873, and nodes still running old versions split from the correct chain, forming a short side chain of about 30 blocks and disrupting infrastructure that relied on those nodes. This was not a successful double spend or a permanent network-wide fork, but it showed that a client supermajority amplifies the defects of a single implementation, and it exposed the dilemma between how openly security fixes are disclosed and how slowly nodes upgrade. Operators need to upgrade promptly and diversify clients, and service providers should avoid treating one node implementation as the sole source of truth.⁠[28]

Berlin Introduces Access Lists and Extensible Transaction Types

Berlin activated at block 12,244,000. EIP-2929 raised the gas for first-time access to accounts and storage slots, correcting long-underpriced state read costs; EIP-2930 allowed transactions to declare an access list in advance and gave the listed addresses and slots a lower warm-access price. EIP-2718’s typed envelope let these new transactions coexist with legacy transactions and also provided an extension framework for the later EIP-1559 and blob transactions. An access list is not a permission list and does not restrict a contract to accessing only the listed state; it is mainly used for fees and execution hints, and an incorrect or incomplete list still executes but may lose the savings.⁠[16]

London and EIP-1559: Base Fee, Priority Fee, and Burning

The London upgrade in August 2021 introduced EIP-1559. The protocol automatically raises or lowers the base fee according to the previous block’s gas usage relative to the target, and blocks can temporarily expand to twice the target during congestion; users specify a max fee and a priority fee, the base fee is permanently burned, and the priority fee is paid to the block producer. The mechanism improved wallet fee estimation and the absorption of short-term demand, but it did not make transaction fees fixed or guarantee low fees.⁠[29]

Burning makes changes in ETH supply depend on network demand: during periods of high activity, burning may exceed new issuance and produce net deflation, while during periods of low activity there may be net issuance. EIP-1559 explicitly states that the base-fee burn rules out a fixed long-term supply, so “ETH has a fixed cap” is inaccurate. MEV, transaction ordering, and application-layer congestion also do not disappear because of the change in fee mechanism.⁠[29]

Post-Merge Supply: Determined Jointly by Proof-of-Stake Issuance and Burning

During the proof-of-work era, the execution layer issued ETH to miners block by block; after the Beacon Chain launched, it also separately issued ETH to validators. The 2022 Merge ended execution-layer mining issuance, retaining only consensus-layer rewards calculated from the amount of active stake, while the base fee burn in place since London continued. An official historical example shows that with about 14 million ETH staked, daily issuance fell from about 13,000 ETH plus about 1,700 ETH before the Merge to about 1,700 ETH, though this figure changes with total stake.⁠[30]

Net supply equals issuance minus the base fee burn and some penalties; there is no permanently fixed daily issuance or guarantee of deflation. Calling negative issuance over a given period a “fixed deflationary currency” ignores declines in network usage, the scale of staking, and changes in protocol parameters.⁠[30]

Proof of Stake: Slots, Epochs, Attestations, and Finality

Ethereum proof of stake divides time into 12-second slots and epochs of 32 slots. In each slot, one validator is selected to propose a block, while other validators attest to the chain head and checkpoints in committees; when consecutive checkpoints receive the support of at least two-thirds of active stake, Gasper’s finality rules mark history as justified and finalized. 32 ETH is the minimum activation deposit for a single validator, and since Pectra a validator’s effective balance cap can be raised to 2048 ETH.⁠[31]

Honest, online validators earn proposal and attestation rewards; going offline forfeits rewards and incurs the inactivity leak; signing conflicting blocks or attestations can lead to slashing and ejection. Economic penalties raise the cost of rewriting history, but software bugs, key management, operational concentration, censorship, and social recovery remain systemic risks.⁠[31]

The Merge Moves to Proof of Stake

The Merge combined the execution layer with the Beacon Chain’s proof-of-stake consensus, ending proof-of-work mining on Ethereum mainnet. Validators stake ETH and propose and attest to blocks; the upgrade significantly reduced consensus energy consumption, but it did not directly make each transaction faster or cheaper.⁠[32]

The Merge Changed Consensus and Energy Use but Did Not Directly Raise L1 Throughput

The Merge connected the existing mainnet execution layer to Beacon Chain consensus and shut down PoW mining; official estimates put the reduction in network energy consumption at about 99.95%. The energy change came from mining machines no longer competing on hashes, not from transactions being compressed or the EVM executing less. Ordinary users’ accounts, contracts, and historical state carried over, with no need to exchange for “new ETH.” The Merge did not directly expand block capacity, significantly reduce gas, or shorten the 12-second slot; it laid the groundwork for withdrawals, single-slot finality research, and later data availability upgrades. The environmental footprint still includes node hardware, cloud services, and peripheral application infrastructure, so 99.95% is an estimate for the consensus mechanism, not absolute zero energy consumption for the entire ecosystem.⁠[32]

Additional Risks of Staking Pools and Liquid Staking Tokens

Native protocol staking requires running a validator and meeting a minimum balance, so third parties developed staking services, pools, and liquid staking tokens (LSTs) that let users with less ETH or without their own hardware participate indirectly. Pools may manage assets openly through contracts or be custodied by centralized platforms; the two differ greatly in keys, verifiability, fees, and redemption.⁠[33]

On top of the basic downtime and slashing risks, LSTs add contract vulnerabilities, secondary-market depegging, insufficient liquidity, governance upgrades, and concentration of operator sets. Large providers controlling too much stake can bring censorship, MEV, and single points of failure. The Ethereum protocol itself does not natively guarantee pools or yield products, and the listing of a service on a page is not a security endorsement.⁠[33]

Restaking: Lending Ethereum’s Economic Security to Third-Party Services

Restaking has natively staked ETH, LSTs, or positions derived from them simultaneously take on additional conditions for third-party networks such as actively validated services (AVSs) in exchange for additional rewards. It differs from simply lending out LSTs, and it is not a yield automatically provided by the Ethereum consensus protocol; users add contract and operational assumptions through external systems such as EigenLayer and Symbiotic. The same collateral may be additionally slashed because of AVS downtime, censorship, or malicious behavior; concentration among a few operators, cascading penalties across multiple services, LRT depegging, and unbonding waits all amplify the risk. Problems with third-party services do not mean mainnet PoS has failed, but large-scale shared risks could in turn affect validator behavior.⁠[34]

Client Diversity: Heterogeneous Implementations Are Both a Safeguard and a Coordination Cost

The same Ethereum protocol is implemented by execution clients such as Geth, Nethermind, Besu, and Erigon and by consensus clients such as Lighthouse, Prysm, Teku, Nimbus, and Lodestar. Implementation diversity can confine a bug in a single codebase to only some nodes; if a client with a consensus defect controls more than two-thirds of stake, an incorrect chain could still be finalized, and fixing it would require social coordination and could subject validators to heavy penalties.⁠[35]

On the Medalla testnet in 2020, a time-source problem in Prysm caused most nodes to drift from the correct time and fail to finalize for an extended period, an early demonstration of supermajority risk. The incident occurred on a testnet and cannot be described as a loss of mainnet funds; its significance was in prompting operators to diversify their client choices on both the consensus and execution layers.⁠[35]

MEV: Arbitrage, Liquidations, and Sandwich Attacks Arising from Ordering Rights

Maximal extractable value (MEV) is the value beyond protocol rewards and ordinary fees that block producers, or entities participating in the transaction supply chain, obtain by including, excluding, or reordering transactions. Cross-pool DEX arbitrage and the liquidation of undercollateralized positions can correct prices or maintain solvency, but frontrunning and sandwich attacks worsen users’ execution, and frontrunning competition also drives up fees. High MEV may incentivize time-bandit reorganizations of historical blocks, creating a risk to consensus stability. Users can reduce their exposure by setting reasonable slippage, using private transaction channels, or using batch auctions, but these approaches introduce new trust in relays, builders, and concentrated order flow.⁠[36]

PBS and MEV-Boost: Dividing Block Proposal and Block Building

After a PoS validator obtains a proposal slot, it can build the block itself or accept bids from specialized builders through a proposer-builder separation market. The current MEV-Boost is out-of-protocol software: builders assemble blocks, relays verify and forward headers carrying value commitments, and the proposer signs first and then obtains the full payload. This division of labor increases ordinary validators’ opportunities to share in MEV revenue, but it makes a few builders, relays, and private order flow bottlenecks for censorship and availability. Glamsterdam plans to bring the core exchange into the protocol through ePBS, but as of September 2026 it was still in testing, and the current MEV-Boost dependence on relays cannot be described as already eliminated by the protocol.⁠[36]

Withdrawals, Blobs, and Rollup Data Scaling

Shapella opened validator withdrawals in 2023; Dencun introduced EIP-4844 blobs in 2024, providing cheaper temporary data for rollups. Ethereum’s scaling roadmap combines L1 security, data availability, and L2 execution; L2s do not automatically inherit all security properties, and users still need to evaluate sequencers, bridges, and proof mechanisms.⁠[16]

Shapella Withdrawals: Partial Withdrawals, Full Exits, and Queues

On April 12, 2023, the Shanghai execution-layer and Capella consensus-layer upgrades activated together. EIP-4895 pushes validator withdrawals to the execution layer as a system-level operation; validators with 0x01 withdrawal credentials and a balance above their effective balance automatically receive partial withdrawals, while validators that have completed the exit process can withdraw their entire withdrawable balance. The upgrade did not unlock all stake instantly and simultaneously. Validator activations, exits, and withdrawals are constrained by churn and sweep queues, with wait times varying with demand; custodial platforms and liquid staking protocols may also have their own redemption rules. Withdrawals reduced the early risk of one-way deposits, but they do not remove slashing, offline penalties, or service-provider risk.⁠[16]

The Rollup-Centric Roadmap: Execution Moves Off Mainnet While Settlement and Data Stay on Ethereum

The early roadmap once planned to scale mainnet directly with multiple execution shards; as optimistic rollup, zero-knowledge rollup, and Danksharding designs matured, the community shifted to a rollup-centric model. L2s execute transactions in batches outside mainnet and publish compressed data, state commitments, and proofs to Ethereum, with mainnet mainly responsible for settlement, dispute resolution, and data availability.⁠[37]

Dencun’s EIP-4844 introduced blobs, whose data does not enter the EVM’s permanent storage but is propagated and retained by consensus nodes for a limited period, with KZG commitments for verification, significantly lowering the cost for rollups to publish data. Fusaka’s PeerDAS further lets nodes sample and store fragments of the data. The roadmap’s goal is not for every L2 to automatically inherit all of mainnet’s security; sequencers, proof systems, upgrade keys, escape mechanisms, and data recovery still need to be reviewed project by project.⁠[37]

Bridges and Layer 2 Security: Trust Layers Beyond Mainnet Consensus

Cross-chain bridges and L2 bridges lock assets in one place and mint representations of them elsewhere, or pass cross-domain messages. Native bridges secured directly by Ethereum validators, bridges relying on rollup fraud/validity proofs, multisig bridges run by external validators, and centralized custodial bridges have different security assumptions; “built on Ethereum” is no substitute for checking the verification logic and administrator permissions.⁠[38]

Bridge risks include contract vulnerabilities, faulty message verification, collusion among external signers, depegging of wrapped assets, abuse of upgrade permissions, and the inability to exit during congestion. Bridges have accounted for several of the largest attacks in DeFi. Users also need to distinguish ETH mainnet assets, L2 canonical bridge assets, and third-party cross-chain wrapped assets; the same name does not guarantee the same redemption path.⁠[38]

ERC-4337: Account Abstraction Infrastructure Without a Consensus Fork

ERC-4337 does not change Ethereum’s underlying transaction rules; instead, smart accounts submit UserOperations to a separate mempool, where bundlers package them and call a shared EntryPoint contract. Accounts can customize signature verification, batched operations, recovery, and multisig; paymasters can pay gas on users’ behalf and even let applications accept other tokens to settle fees. The system adds components such as bundlers, the EntryPoint, factories, and paymasters. If validation logic can consume large amounts of resources or become invalid at bundling time, it creates denial of service, so the specification restricts storage access and uses simulation, staking, and reputation rules. An ERC number and a deployed EntryPoint do not mean every smart wallet implementation is equally secure.⁠[39]

Pectra

Pectra activated at epoch 364032, including account features such as EIP-7702, an increase in the validator effective balance cap to 2048 ETH, and blob parameter adjustments. EIP-7702 allows ordinary accounts to temporarily adopt smart account code within a transaction, improving experiences such as batching and sponsored gas, while also expanding signature and authorization management risks.⁠[40]

Pectra’s EIP-7702: EOAs Can Temporarily Delegate Execution Code

EIP-7702 allows externally owned accounts to sign an authorization that delegates their code behavior to a designated implementation, gaining smart account capabilities such as batched calls, gas sponsorship, alternative authentication, spending limits, and recovery while keeping their original address. Authorizations can be bound to a chain ID and nonce and can be replaced or revoked by a new authorization. The delegation target has extensive execution power, and phishing signatures or malicious implementations can move assets without the user understanding what is happening. Wallets must clearly display the target code, the scope of the authorization, and the revocation path; “EOAs having code” also changes the security assumption that applications previously relied on when using code length to distinguish users from contracts.⁠[41]

Pectra’s Validator Operations: Consolidation, Exits, and Deposit Processing

Through EIP-7251, Pectra raised the maximum effective balance for validators that opt into a new credential type from 32 ETH to 2048 ETH, allowing rewards to compound and large operators to consolidate multiple validator indices, reducing the consensus messaging load; 32 ETH remains the minimum activation balance for ordinary new validators and is not the threshold for running every node. EIP-7002 lets the execution-layer address corresponding to the withdrawal credentials trigger exits, reducing the trust that delegated setups must place in the operator holding the validator signing key; EIP-6110 brings deposit logs directly into the execution payload, removing the long delay that had been kept for old PoW reorganizations. Efficiency gains may also drive operational concentration, so the change in the balance cap cannot be treated as an automatic improvement in decentralization.⁠[41]

Fusaka and PeerDAS

Fusaka introduced PeerDAS, allowing nodes to verify blob data availability through sampling without each node fully downloading all the data; blob parameters could then be raised gradually through BPOs. The goal is to expand rollup data capacity while keeping ordinary nodes runnable.⁠[42]

Post-Fusaka BPOs: Raising Blob Throughput Gradually Rather Than All at Once

Fusaka activated PeerDAS on December 3, 2025, letting nodes download and verify only a subset of erasure-coded blob data columns rather than having every node store all blobs. It also added execution and consensus improvements such as a per-transaction gas cap, a block RLP size limit, a secp256r1 precompile, deterministic proposer lookahead, and a blob base fee floor. The network did not use the theoretical maximum capacity on activation day; instead, it adjusted gradually through pre-programmed Blob Parameter Only forks: on December 9, 2025, the target/maximum was raised from 6/9 to 10/15, and on January 7, 2026, to 14/21. BPOs change only parameters and do not mean that L2 fees are permanently fixed; node bandwidth and blob demand still need continuous monitoring.⁠[43]

U.S. Spot Ether ETPs Approved for Listing and Trading

On May 23, 2024, the U.S. Securities and Exchange Commission approved rule changes filed by exchanges including NYSE Arca, NasdaqNasdaqNasdaq is an exchange operator and financial technology company headquartered in New York. It runs The Nasdaq Stock Market and other markets and provides capital markets technology, regulatory technology, and data and index services. Founded in 1971, it combined with OMX AB in 2008, and in March 2026 the U.S. Securities and Exchange Commission approved its rules for trading tokenized securities.Open the full entry, and Cboe BZX, allowing exchange-traded products that hold spot Ether to list once filing, custody, pricing, and market surveillance conditions were met; each product then also needed its registration statement to become effective. This let traditional securities accounts gain price exposure through regulated shares without investors directly managing private keys.⁠[44]

The approval order examined whether the exchange rules were consistent with the Exchange Act and guarded against fraud based on analyses such as correlation with the CME Ether futures market and surveillance-sharing. It is not a uniform securities classification by the SEC of all ETH trading, staking, DeFi services, or token offerings, and it does not eliminate custody, fee, tracking error, or market volatility risks.⁠[44]

State Growth, History Expiry, and Stateless Validation

Continued growth in accounts, contracts, and storage raises SSD capacity and random-read requirements, raising the bar for running a node over the long term. History expiry means nodes no longer permanently serve old block data; state expiry research would move long-unused state out of the active set; weak statelessness schemes have builders maintain the full state while other validating nodes check state transitions using witnesses. These directions partially shift responsibility for storing old data to the Portal Network, archive nodes, applications, or other services, which may create trade-offs in availability and centralization. The official roadmap explicitly states that most of these proposals are still under research, so EIP-4444, Verkle trees, or state expiry cannot be described as fully deployed.⁠[45]

Roadmap, with Glamsterdam Still in Testing

As of September 4, 2026, Glamsterdam’s scope had been frozen but its meta EIP was still a draft, the network was in devnet testing, and officials only expected a mainnet launch in the fourth quarter of 2026, with no confirmed date. The headline features include in-protocol proposer-builder separation and block-level access lists: the former extends the data propagation window and reduces reliance on out-of-protocol relays, while the latter announces in advance the accounts and storage a block accesses to support parallel reads and execution. The upgrade also plans to reprice state creation/access, lower the intrinsic gas of ordinary ETH transfers, expand contract size, and improve ETH transfer logs. All features may be adjusted before the final mainnet release; users do not need to exchange ETH, while nodes and validators must upgrade to compatible clients before the confirmed activation.⁠[46]

As of September 2026: Open Governance and the Next Stage

Ethereum has no CEO or single owner; EIPs, client teams, researchers, validators, applications, and users jointly influence upgrades. The official roadmap lists Glamsterdam as a development target for the fourth quarter of 2026 and Hegotá as a direction for 2027, but future timing and scope may change and should be treated as plans rather than established facts.⁠[16]

Sources

  1. Ethereum Whitepaper (opens in a new window)
  2. Ethereum Yellow Paper: A Secure Decentralised Generalised Transaction Ledger (opens in a new window)
  3. Ethereum accounts (opens in a new window)
  4. Ethereum gas and fees: technical overview (opens in a new window)
  5. Transactions (opens in a new window)
  6. Ethereum Virtual Machine (EVM) (opens in a new window)
  7. Anatomy of smart contracts (opens in a new window)
  8. Technical introduction to dapps (opens in a new window)
  9. ERC-1967: Proxy Storage Slots (opens in a new window)
  10. Nodes and clients (opens in a new window)
  11. Ethereum networks (opens in a new window)
  12. History of Ethereum: founder, launch and ownership (opens in a new window)
  13. Launching the Ether Sale (opens in a new window)
  14. Grayscale Ethereum Trust (ETH) Annual Report 2023 (opens in a new window)
  15. Ethereum Launches (opens in a new window)
  16. Timeline of all Ethereum forks (2014 to present) (opens in a new window)
  17. EIP-1: EIP Purpose and Guidelines (opens in a new window)
  18. Ethereum in 30 minutes by Vitalik Buterin | Devcon SEA (opens in a new window)
  19. ERC-20: Token Standard (opens in a new window)
  20. ERC-137: Ethereum Domain Name Service - Specification (opens in a new window)
  21. Hard Fork No. 4: Spurious Dragon (opens in a new window)
  22. A Postmortem on the Parity Multi-Sig Library Self-Destruct (opens in a new window)
  23. CryptoKitties Bounty 2 (opens in a new window)
  24. ERC-721: Non-Fungible Token Standard (opens in a new window)
  25. ERC-1155: Multi Token Standard (opens in a new window)
  26. Smart contract security (opens in a new window)
  27. Oracles (opens in a new window)
  28. Geth security release (opens in a new window)
  29. EIP-1559: Fee market change for ETH 1.0 chain (opens in a new window)
  30. How The Merge impacted ETH supply (opens in a new window)
  31. Proof-of-stake (PoS) (opens in a new window)
  32. The Merge (opens in a new window)
  33. Liquid and pooled staking (opens in a new window)
  34. What is restaking? (opens in a new window)
  35. Validated, staking on eth2: Why client diversity matters (opens in a new window)
  36. Maximal extractable value (MEV) (opens in a new window)
  37. Danksharding (opens in a new window)
  38. Bridges (opens in a new window)
  39. ERC-4337: Account Abstraction Using Alt Mempool (opens in a new window)
  40. Pectra upgrade (opens in a new window)
  41. Pectra Mainnet Announcement (opens in a new window)
  42. Fusaka upgrade (opens in a new window)
  43. Fusaka Mainnet Announcement (opens in a new window)
  44. Order Granting Accelerated Approval of Proposed Rule Changes to List and Trade Shares of Ether-Based Exchange-Traded Products (opens in a new window)
  45. Statelessness, state expiry and history expiry (opens in a new window)
  46. Glamsterdam (opens in a new window)