𝐞𝐏𝐁𝐒, 𝐬𝐥𝐨𝐭 𝐭𝐢𝐦𝐢𝐧𝐠𝐬, 𝐚𝐧𝐝 𝐬𝐜𝐚𝐥𝐢𝐧𝐠 𝐚𝐩𝐩𝐫𝐨𝐚𝐜𝐡𝐞𝐬
Ethereum is targeting Q3 for the next major upgrade, Glamsterdam. ePBS is the headliner, restructuring the deadlines within a slot to allow for larger blocks (higher gas limit & more blobs).
In the current slot structure a block has to be selected, proposed, propagated and attested to by the network in under 4 seconds. Increasing block size means more data has to reach nodes in the same short amount of time, and you run into bandwidth constraints.
ePBS buys more time for data propagation by separating blocks into the consensus block, execution payload, and blobs, and changing the deadlines for when those different parts of the block need to arrive.
Instead of the entire block needing to reach validators before the 4 second mark, they only need to receive the consensus block- a cryptographic commitment to a certain block & set of blobs. They make their attestation without receiving the execution payload, then have the remainder of the slot to receive that payload and verify it. Blob data is propagated separately giving nodes the full 12 seconds to receive it.
This scheme makes it easier to increase the gas and blob limits, which is good for some additional scaling. However, it's more of a sidestep than a true solution to the bandwidth bottleneck.
If you want to unlock serious throughput gains you need to improve how fast and efficiently data can move across the network. That's the key to increasing block size while ALSO shortening slot times.
Removing the bandwidth bottleneck means fundamentally upgrading the way data moves across Ethereum. Optimum's Random Linear Network Coding approach propagates Ethereum blocks with lower latency AND in a way that won't slow down as the size of blocks increase, OR as the network becomes larger and even more decentralized.
Scale the L1.