Changes

The problem is as follows in this example.

For a node A encoding to {1, 2}, its database key is {0, 0, 0, ..., 1, 2}. Another node B with > 32B encoding could (unlikely but still) hash to the same value {0, 0, 0, ..., 1, 2} as for A and that would conflict in the database.

The solution is to NOT force the database key to be 32B always, and to keep it plainly as the Merkle value of the node (32B or less). This should also occupy less space in the database eventually.

Storage KV database node key has now the length of the Merkle value and is no longer forced to 32B
Renaming XXXHashesSet to XXXMerkleValues since it's not just hashes
Renaming deletedKeys to deletedMerkleValueToBlockNumber in dot/state
Renaming methods XXXNodeHashes to XXXMerkleValues

Tests

go test -tags integration github.com/ChainSafe/gossamer

Issues

Primary Reviewer

@timwu20

Aug 04 '22 15:08 qdm12

Codecov Report

Merging #2725 (c304159) into development (9dc11e4) will decrease coverage by 0.10%. The diff coverage is 50.00%.

Additional details and impacted files

@@               Coverage Diff               @@
##           development    #2725      +/-   ##
===============================================
- Coverage        63.45%   63.34%   -0.11%     
===============================================
  Files              217      217              
  Lines            27059    27058       -1     
===============================================
- Hits             17170    17141      -29     
- Misses            8327     8352      +25     
- Partials          1562     1565       +3