The Reed-Solomon coding scheme builds a merkle tree of shards, by hashing each shard, and then creating a tree from these leaf hashes. This is done generically, with a shard passed directly to the hash function. In #4801 we add SIMD to hash multiple shards at once. This is great, but it means that to fully saturate hashing, you need enough shards to saturate all the SIMD lanes available in each core. For a small number of shards, this isn't ideal. I can imagine situations where you have small committees of, e.g. 20 or so nodes, in which case you might run out of lanes.
To avoid this, we could define the leaf hash to itself be the result of merkleizing "chunks" of each shard, that makes implementations free to implement SIMD in order to efficiently hash the chunks within each shard.
Another potential advantage is that you might be able to reduce memory pressure, because you're feeding adjacent data to the SIMD lanes, rather than data that's far away. e.g. compare hashing adjacent, e.g. 16 KiB chunks with instead hashing the first 16 KiB of shards that might themselves be a MiB.
One downside is that this does break the format.
Another note: BLAKE3 is advantageous in SIMD specifically because it defines hashing to work this way, for any message.
The Reed-Solomon coding scheme builds a merkle tree of shards, by hashing each shard, and then creating a tree from these leaf hashes. This is done generically, with a shard passed directly to the hash function. In #4801 we add SIMD to hash multiple shards at once. This is great, but it means that to fully saturate hashing, you need enough shards to saturate all the SIMD lanes available in each core. For a small number of shards, this isn't ideal. I can imagine situations where you have small committees of, e.g. 20 or so nodes, in which case you might run out of lanes.
To avoid this, we could define the leaf hash to itself be the result of merkleizing "chunks" of each shard, that makes implementations free to implement SIMD in order to efficiently hash the chunks within each shard.
Another potential advantage is that you might be able to reduce memory pressure, because you're feeding adjacent data to the SIMD lanes, rather than data that's far away. e.g. compare hashing adjacent, e.g. 16 KiB chunks with instead hashing the first 16 KiB of shards that might themselves be a MiB.
One downside is that this does break the format.
Another note: BLAKE3 is advantageous in SIMD specifically because it defines hashing to work this way, for any message.