Right now we have the following design and implementation:
let sector_id = SectorId::new(public_key_hash, sector_index);
let seed = sector_id.derive_evaluation_seed(piece_offset, history_size);
However, the observation is that history_size
is the same for all pieces in the sector. Technically according to current rules it doesn’t have to be, but it is because there is no reason for that to not be the case.
Now I’m wondering if we should move history size into sector ID derivation instead. I don’t recall that there is any value in sector IDs to be identical regardless of history size.
Moreover, I found an exploit for current design that may replace a random reads with essentially sequential reads during audit and potentially HDD-compatible plotter.
Note that this is how we derive slot challenge for a sector:
let sector_slot_challenge = sector_id.derive_sector_slot_challenge(
global_challenge,
);
And on disk for auditing purposes we store chunks sorted by s-buckets.
Here is what I would do to reduce random reads:
- Have one sector index/ID reused across multiple physical sectors
- Plot each physical sector as of different blockchain height (which is easy to do once history size is non-trivial)
- Interleave s-buckets of different physical sectors, such that all s-buckets with index
0
come first, then all s-buckets with index1
, etc.
With such disk layout one could read a whole bunch of “sectors” with a single large sequential reads without the need to jump between different sections of the disk due to the fact that sector slot challenge will be the same for all of these distinct physical sectors.
Of course these sectors will store random selection of pieces, so there is technically nothing fundamentally wrong with this.
On one hand this may allow to design HDD-friendly (to a degree at least) auditor, but proving will likely remain being a challenge with 32k of random reads across disk (spaced even further than usually).
I’m not sure if there are other exploits of current design to worry about, but I don’t like it either way and I think we should address this.