Ethereum has upgraded more in 2024 than in the last three years combined.

𝘉𝘶𝘵 𝘰𝘯𝘦 𝘱𝘳𝘰𝘱𝘰𝘴𝘢𝘭 𝘲𝘶𝘪𝘦𝘵𝘭𝘺 𝘤𝘩𝘢𝘯𝘨𝘦𝘴 𝘦𝘷𝘦𝘳𝘺𝘵𝘩𝘪𝘯𝘨: 𝘱𝘢𝘳𝘢𝘭𝘭𝘦𝘭 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘰𝘯.

EIP-7928 might be the moment Ethereum finally stops being single-threaded.👇🧵

We have seen the Fusaka ugrade, the kohaku upgrade, so many EIPs and ERCs, but EIP-7928 hits the core of the EVM.
----------------------------------------

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐄𝐈𝐏-7928?

𝘌𝘐𝘗-7928 𝘪𝘴 𝘢 𝘱𝘳𝘰𝘱𝘰𝘴𝘦𝘥 𝘶𝘱𝘨𝘳𝘢𝘥𝘦 𝘵𝘩𝘢𝘵 𝘪𝘯𝘵𝘳𝘰𝘥𝘶𝘤𝘦𝘴 𝘉𝘰𝘶𝘯𝘥𝘦𝘥 𝘈𝘵𝘰𝘮𝘪𝘤 𝘓𝘪𝘴𝘵𝘴 (𝘉𝘈𝘓𝘴), 𝘢 𝘧𝘰𝘳𝘮𝘢𝘭 𝘸𝘢𝘺 𝘧𝘰𝘳 𝘵𝘳𝘢𝘯𝘴𝘢𝘤𝘵𝘪𝘰𝘯𝘴 𝘵𝘰 𝘥𝘦𝘤𝘭𝘢𝘳𝘦 𝘸𝘩𝘢𝘵 𝘴𝘵𝘢𝘵𝘦 𝘵𝘩𝘦𝘺 𝘸𝘪𝘭𝘭 𝘳𝘦𝘢𝘥 𝘰𝘳 𝘸𝘳𝘪𝘵𝘦 𝘣𝘦𝘧𝘰𝘳𝘦 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘰𝘯.

By including a structured “state access manifest,” Ethereum clients can determine whether two transactions touch the same parts of the state, and if they don’t, they can be executed in parallel.

This solves one of Ethereum’s biggest problems, it is a system that makes executions happens sequentially, where every transaction must run in order.

With EIP-7928, Ethereum takes a major step toward a multi-threaded execution environment, enabling more throughput without redefining the EVM.
----------------------------------------

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐁𝐀𝐋 (𝐁𝐨𝐮𝐧𝐝𝐞𝐝 𝐀𝐭𝐨𝐦𝐢𝐜 𝐋𝐢𝐬𝐭)?

A Bounded Atomic List (BAL) is metadata that tells the network exactly which accounts and storage locations a transaction intends to read or modify before it even executes.

This transforms the EVM from a black-box transaction runner into a predictable system where resource usage is known ahead of time.
A BAL works like a compact, deterministic outline of the execution footprint.

It gives validators confidence that:

➢ the transaction won’t touch anything outside its declared boundaries

➢ no hidden state conflicts will appear during execution

➢ scheduling decisions made before execution will remain valid afterward

BALs are core to enabling safe parallelism because nodes can now reason about transaction conflicts without running the EVM first.

----------------------------------------

𝐓𝐡𝐞𝐫𝐞 𝐚𝐫𝐞 𝐭𝐡𝐞 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭 𝐭𝐲𝐩𝐞𝐬 𝐨𝐟 𝐁𝐀𝐋

1. The Read BAL which appears in transactions that access state but do not change any part of it. These maybe rare in normal Ethereum flows but they become extremely valuable for batched systems

2. The Write BAL which defines the subset of state the transaction will update. These transactions require conflict resolution but can still run side-by-side with others that touch different areas of the state.

3. The Read-Write BAL includes both sets, allowing clients to compare read/write overlaps across thousands of pending transactions.

This allows the scheduler to create optimal execution groups without risking inconsistent outcomes or reversion cascades.
----------------------------------------

𝐌𝐞𝐜𝐡𝐚𝐧𝐢𝐬𝐦 𝐨𝐟 𝐄𝐈𝐏-7928

The mechanism behind EIP-7928 has 3 core components: declaration, validation, and scheduling.

1. Pre-Execution Declaration

Every transaction includes a BAL, a compact manifest of all accounts and storage slots that will be accessed.
This declaration is part of the transaction payload and is verified before execution begins.
This alone makes conflict detection possible without running the EVM.

2. Static Validation of BAL

Before executing any transaction, Ethereum clients check:

➢ whether the BAL is well-formed

➢ whether the transaction attempts to access anything outside its declared sets

➢ whether the declared sets respect the limits defined in the standard

If the transaction touches something not included in the BAL, it is invalid. This protects the network and ensures trust in parallel scheduling.

3. Conflict Graph Construction

Using the BALs, the node builds a conflict graph where each transaction is a node, an edge means overlapping read/write sets, no edge means the transactions are independent

This graph tells the scheduler exactly which transactions can run simultaneously.

4. Parallel Scheduling

The client divides the transaction set into batches that can execute concurrently.
Independent batches are dispatched to different CPU cores or threads.

Examples: multiple swaps in different pools, multiple mints affecting independent contract states, unrelated transfers touching different accounts

These execute at the same time, maximizing CPU utilization.

5. Deterministic Commit

Although execution happens in parallel, the commit to state is always applied in canonical block order. This preserves determinism across all nodes. Parallelism speeds up execution, but ordering avoids consensus divergence.
----------------------------------------

𝐋𝐢𝐟𝐞 𝐂𝐲𝐜𝐥𝐞 𝐨𝐟 𝐚 7928-𝐄𝐧𝐚𝐛𝐥𝐞𝐝 𝐁𝐥𝐨𝐜𝐤

Transactions with BALs enter the mempool, nodes classify and group them, parallel execution begins, results are merged deterministically, and the block is finalized faster.
Both builders and validators benefit from reduced execution time and predictable conflict patterns.

Benefits of EIP-7928

➢ EIP-7928 unlocks true parallel execution, letting Ethereum finally utilize modern multi-core hardware to boost throughput dramatically.

➢ By clearing congestion faster, EIP-7928 smooths out gas spikes and stabilizes fee markets during high-traffic periods.

➢ Parallel execution reduces block verification time, strengthening decentralization by lowering hardware requirements for all validators.

➢ With clear state-access boundaries, block builders can structure MEV strategies and batch flows more safely and efficiently.

➢ EIP-7928 enhances Ethereum’s execution layer without requiring new virtual machines, contract rewrites, or breaking existing tooling.
----------------------------------------
In conclusion, EIP-7928 feels like one of those upgrades that quietly changes everything.

𝘍𝘳𝘰𝘮 𝘮𝘺 𝘱𝘦𝘳𝘴𝘱𝘦𝘤𝘵𝘪𝘷𝘦, 𝘵𝘩𝘪𝘴 𝘪𝘴 𝘵𝘩𝘦 𝘧𝘪𝘳𝘴𝘵 𝘵𝘪𝘮𝘦 𝘌𝘵𝘩𝘦𝘳𝘦𝘶𝘮 𝘪𝘴 𝘭𝘢𝘺𝘪𝘯𝘨 𝘳𝘦𝘢𝘭 𝘨𝘳𝘰𝘶𝘯𝘥𝘸𝘰𝘳𝘬 𝘧𝘰𝘳 𝘱𝘢𝘳𝘢𝘭𝘭𝘦𝘭, 𝘩𝘪𝘨𝘩-𝘵𝘩𝘳𝘰𝘶𝘨𝘩𝘱𝘶𝘵 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘰𝘯 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘳𝘦𝘸𝘳𝘪𝘵𝘪𝘯𝘨 𝘵𝘩𝘦 𝘦𝘯𝘵𝘪𝘳𝘦 𝘴𝘵𝘢𝘤𝘬.

If we get this right, developers win, users win, and Ethereum finally starts using the full power of modern hardware and that’s a future I’m genuinely excited about.

𝘠𝘰𝘶𝘳 𝘵𝘩𝘰𝘶𝘨𝘩𝘵𝘴 𝘰𝘯 𝘌𝘐𝘗-7928?