## Electra Timeline

While most of the decisions about what to include in Electra have been made, there is one final decision: [EIP-7547: Inclusion Lists](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7547.md). Here's where the timeline stands right now:


Inclusion lists are shown in blue with a dotted line denoting how much extra time they might add to this fork. Mike Neuder has made a [strong case for why Inclusion Lists should be in Electra](https://notes.ethereum.org/@mikeneuder/the-case-for-ilectra).

## The Problem

As the diagram illustrates, there is already more work to do for Electra on the Consensus Layer than the Execution Layer. If we add Inclusion Lists to Electra, **this gap grows larger**. This is where we run into a **fundamental problem**: if the gap between EL & CL work on Electra grows too large, there will be a stronger motivation to include **more EL upgrades** in Electra. The diagram above will change to the following:


**This will delay Verkle trees.** Adding in more EL upgrades will not only distract EL devs from implementing Verkle Trees, it will also massively delay the testing teams, who will be forced to develop additional test vectors for the additional EL upgrades. This will interrupt their testing cycle for Electra, adding more time. And all of this will distract them from developing test vectors for Verkle Trees. **We want to avoid this at all costs.**

## The Solution

If we can simply agree strongly that we **will not include additional EL upgrades in Electra**, then I believe we can pull this off. The diagram above changes to this:


The EL teams will certainly finish their work for Electra before the CL teams. But they **MUST move straight on to Verkle Trees**. I think this is a good option. If we don't agree to this, our only alternative is moving Inclusion Lists to Fstar:


Either way, additional EL upgrades are not included in Electra, but we end up **needlessly delaying Inclusion Lists for another year.**

## BONUS: What About PeerDAS?

The following is a proposition to address data availability capacity which is **completely orthogonal to the discussion above**.

There is currently a prevailing opinion that (at least for some consensus teams) work on PeerDAS can be done largely in parallel to all the upgrades already mentioned. Because we've only just released 4844, it's difficult to estimate how soon data availability will become the bottleneck for Layer 2's again. Personally, I think a good option at this point is to plan for **a small blob capacity increase in Electra** (perhaps changing `MAX_BLOBS_PER_BLOCK = 10`) to buy us some time. We should also plan on having **one CL-only fork** before Verkle Trees.

As we get closer to the Electra fork date, we will have a better understanding of the demand for additional data availability as well as the progress on PeerDAS. We can then decide between one of the following Consensus Layer only forks before the Verkle fork:

1. Further increase `MAX_BLOBS_PER_BLOCK = 14/16`, delaying PeerDAS to the Verkle Fork
2. Full PeerDAS