Initial draft for canonical block index network

[KolbyML]

As seen from my Pro's and Con's list in the proposal. I think it makes sense for this network to just store all the headers, because the difference in storage size is around 8GB. Storing headers instead of the hash takes 8GB more storage then having a network which stores just the block hash, which would be around 800MB.

Only 8GB more for

• less latency (you only have to make the base request to get the header instead of 2 (1 for block hash + 1 for block header)
• simpler validation
• simpler data seeding (using block hash, you would still need to have access to the block header to verify the block number in the content key is valid)

Why do we want this network?

• Most JSON-RPC calls support requesting data by block number
• Eth Call requires block number -> block hash indexes for the last 256 blocks (in Portal's case we would need access to all the blocks 0 to latest to properly support eth call)
• Being able to fetch header's by block number is more intuitive and easier to get what you want, our current model requires you to start from the latest block header from the beacon network and walk back to your desired block header, so potentially if you wanted the block header for block 1 you would have to fetch 20 million headers which is a little overkill

Thinking more about this, I think this content type should just be apart of the history network only 9GB of more storage and then you don't require the overhead of running another P2P network, for a massively better UX

My request?

Feedback/ a discussion on what should happen

[KolbyML]

If we were to include Block Number Index Content type as a type for the Execution chain history network

I think we would be good to drop Header epoch records (pre-merge only), as then instead of a block number to block header index lookup method for just pre-merge, we would have a more sustainable method for all the block headers from genesis to the future

^ dropping this type has been discussed in the past, but not doing it has been hinged on us not having a better alternative to get block number indexes

[carver]

I think this content type should just be apart of the history network only 9GB of more storage and then you don't require the overhead of running another P2P network, for a massively better UX

My intuition leads me this direction too.

[acolytec3]

I think this content type should just be apart of the history network only 9GB of more storage and then you don't require the overhead of running another P2P network, for a massively better UX

My intuition leads me this direction too.

That was my initial instinct as well

[acolytec3]

If we were to include Block Number Index Content type as a type for the Execution chain history network

I think we would be good to drop Header epoch records (pre-merge only), as then instead of a block number to block header index lookup method for just pre-merge, we would have a more sustainable method for all the block headers from genesis to the future

^ dropping this type has been discussed in the past, but not doing it has been hinged on us not having a better alternative to get block number indexes

An additional note here is that ultralight already builds a block index locally (based on it's view of content it receives) so turning this into one additional content type on history network definitely makes the most sense to me.

[kdeme]

My intuition leads me this direction too.

I agree, if it is exactly the same data but with another addressing scheme, I'd keep it in the same network.

If it were some other system where block index mappings in big chunks were provided, then perhaps that would be a good reason to get another portal sub-network for this.

But I do agree that this added content key with duplication of the header data seems to be the most straight forward, no additional round trips, type of solution.

I do think that the data storage is a bit bigger than suggested here but still in the same order. I think you missed the proofs size in your quick estimation.

[KolbyML]

Having done a quick read-through, my main take-away is that this probably needs to have more detail added about how the different ranges of history are proved. If memory serves, we have as many as three different proof paths for this data?

• Pre merge needs to be proved against the accumulators from https://eips.ethereum.org/EIPS/eip-7643
• Post merge needs to be proved against ?historical roots? up until Capella
• Post merge after Capella needs to be proved against ?historical accumulators?

Assuming this is correct, these different proving paths should be clearly explained and specified. Thoughts?

I think we should close this proposal in favor of https://github.com/ethereum/portal-network-specs/pull/334

To address your question I think we should discuss it here https://github.com/ethereum/portal-network-specs/pull/334#discussion_r1747403571

[KolbyML]

Closing for this reason https://github.com/ethereum/portal-network-specs/pull/333#issuecomment-2334418308