P2P sync update for 0.13.2 hashing scheme

[kirugan]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.70%. Comparing base (0c9ee5a) to head (1800c6f).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2033      +/-   ##
==========================================
- Coverage   74.71%   74.70%   -0.01%     
==========================================
  Files         110      111       +1     
  Lines       12105    12123      +18     
==========================================
+ Hits         9044     9057      +13     
- Misses       2364     2367       +3     
- Partials      697      699       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[IronGauntlets]

I don''t think I fully understand what is happening in this PR. We have a migration which is only responsible for storing p2p hashes but i don't fully understand what would happen if someone where to sync from an empty DB.

Can you please explain the work flow of this PR?

[AnkushinDaniil]

I don''t think I fully understand what is happening in this PR. We have a migration which is only responsible for storing p2p hashes but i don't fully understand what would happen if someone where to sync from an empty DB.

Can you please explain the work flow of this PR?

Migration

This migration consists of 2 steps:

1. Save post-0.13.2 hashes for pre-0.13.2 blocks. This is done in any case, even for empty db, because we need these hashes to validate blocks using post-0.13.2 algorithms.
2. Update block commitments for pre-0.13.2 blocks we have in db.

Hash calculation

The blockHash function now returns a hash and commitments. The version of these hashes matches the version of the block. Commitments must be post-0.13.2 if possible (there are some exceptions for deprecated networks and tests for them)

---

Upd.
Now we don't store post-0132 hashes in db and commitments and don't have migration. Instead, we store post-0132 hashes using embed only and compute post-0132 commitments before sending.

[rodrigo-pino]

Looks good to me