I think the idea was that peers would share the seed they use for working out what droplets they’ll select, both to save a little bit of data, but also to help guarantee unbiased random selection?
Yes. The peers share the seed used to generate the droplets in the respective epoch. In the post, where I talk about:
Each droplet carries information about which original blocks were combined to produce it. Using this information, the decoder builds a bipartite graph connecting droplets to their source blocks.
this information might include the seed needed to rebuild the same bipartite graph on both nodes.
So I think your storage is just the fraction 𝑠/𝑘 versus storing all blocks.
Actually it’s approximately s/k, because blocks don’t have exactly the same size, so different encodings produce droplets with variable size. In the last paragraph you say that:
I wonder what the impact of different serialization sizes of blocks is here: if you have a droplet that’s [208, 820] and 208 is full of inscriptions and 4MB while 820 is full of runestones and 1MB, I think the droplet has to be the full 4MB.
That’s one of the reasons the storage isn’t exactly s/k of the total blocks’ data size. In a case where a difference like the one you showed occurs, could this be optimized by concatenating blocks up to a target size threshold, to avoid XORing a large block against a much smaller one, where most of the operation would just be canceling out the zero-padding on the smaller block.
I think it would be reasonable to parameterize based on 𝑘 and 𝑟 =𝑠/𝑘 instead, with the potential for 𝑟 being a per-node setting.
I agree with the above statement. The parameter s being variable per node’s storage capacity is really interesting. But I think using a fixed k is important for node coordination.
My first thought is that you’d disconnect and ban a peer that gave you bad data (so not request any additional droplets), but might keep the remaining droplets they gave you on the offchance any of them turned out to be useful.
I also agree with this statement. The remaining droplets from a murky peer should still be processed by the decoder, which will naturally accept them if they pass the header and merkle root verification when they become singletons, or reject them otherwise.