# Poorman's EIP4844+ ideas

EIP4844 (proto-danksharding) marks a stride in simplifying the complexities of original data-sharding plans. With meticulous research underway to bring danksharding to fruition, we find ourselves at a fascinating crossroads. This post discusses middle-ground project ideas between EIP4844 and danksharding and seeks valuable/fun ideas to implement for those who want to write client code post-EIP4844. These ideas may further research for danksharding or improving current mainnet chain health. It aims to be theoretical and practical, and we call this EIP4844+ idea.

One constraint I impose on these ideas is they should be **additive**, **backward compatible, not consensus-breaking, and no hard fork required**. This significantly improves client development time and can use the existing mainnet as a testbed without breaking it, which is a good win.

### Idea #1 (Erasure code extending current 3/6 target max blobs)

Currently, EIP4844 uses 3/6 blobs. A node can only declare a block as the head of the chain once all the blobs have been received (if any) and verified. In more simple terms, a node can only process the block once all the blobs are received. The individual blobs are gossiped over p2p. The p2p pub/sub system is reliable, all messages get delivered to all peers subscribed to the topic, and it is resilient. Peers can join and leave the subnet without disrupting it. It's fast, efficient and straightforward.

A straightforward idea is to erase code and extend 3/6 target max blobs to 6/12. The nodes interested in the extra subnet for the erasure-coded blobs can opt in and subscribe to them. The node can process the blobs with the additional subnets after receiving 50% of the total data. (Before: 100%) This makes the network more dynamic and higher resistance to stalling. The tradeoff here is bandwidth vs. micro-optimization on when a node can declare a block as head. As for storage, the node will still store the same amount of data as in EIP4844 because it can always reconstruct the original data upon request.

Whether making the network more dynamic improves block processing latency is unclear, but it is still a fantastic research problem. The win here is utilizing the mainnet's network topology with an erasure-coded overlay network. We get to utilize and test the mainnet without possessing severe risks to the mainnet. One can view this as two types of nodes. A classic node that behaves in EIP4844 model, a new type of node that gossips erasure-coded data and provides them upon request.

The main changes for the new node are:
- New gossip net to subscribe (for erasure-coded blobs)
- New block processing rule (only 50% of the blob sidecar)
- New RPC endpoints

### Idea #2 (Apply data availability sampling to EIP4844)

Disregard the current target/max blob sidecar count in EIP4844 today. We can introduce a new node type that gossips, custody, and samples blob sidecars. This extends idea #1 and adds data sampling on top. The network could be seen as more dynamic and faster (similar pros as #1)

In this approach, we get to test out the following
- Erasure code extension
- Row and column constructions
- Data availability sampling implementations. It should be forward-compatible with Danksharding
* How does the node take samples as custody

This will require more changes, but it's more worthwhile because it's more realistic for our long-term goals. The main changes for the new node are:
- New gossip net
- New RPC request response domains
- New node duties to perform data availability sampling
- New block processing and fork choice rules