Current Portal beacon specifications state that all types are stored for the full range by all nodes (potentially).
Requests and gossip happen in a random way and not by targeting closest to content id.
This is fine for the latest finality and optimistic update (only is 1 for each).
It is also fine for the LightClientUpdate:
LightClientUpdate size * MIN_EPOCHS_FOR_BLOCK_REQUESTS / 256 = ~3.5MB
But for the LightClientBootstrap the total storage is too large to be negligible:
LightClientBootstrap size * MIN_EPOCHS_FOR_BLOCK_REQUESTS = ~850MB
As this type has only individual access, and the content key is by hash, I think it would work fine to store this type based on its content id.
So for this only this type in the Portal beacon network a NH gossip and RFContent would be done. The others would still use the random versions.
Current Portal beacon specifications state that all types are stored for the full range by all nodes (potentially). Requests and gossip happen in a random way and not by targeting closest to content id.
This is fine for the latest finality and optimistic update (only is 1 for each). It is also fine for the
LightClientUpdate:LightClientUpdate size * MIN_EPOCHS_FOR_BLOCK_REQUESTS / 256 = ~3.5MBBut for the
LightClientBootstrapthe total storage is too large to be negligible:LightClientBootstrap size * MIN_EPOCHS_FOR_BLOCK_REQUESTS = ~850MBAs this type has only individual access, and the content key is by hash, I think it would work fine to store this type based on its content id. So for this only this type in the Portal beacon network a NH gossip and RFContent would be done. The others would still use the random versions.