Beacon Portal Network implementation progress

[ogenev]

This is a tracking issue of the current progress of the beacon portal network implementation.

Tasks

• [x] https://github.com/ethereum/trin/pull/1007
• [x] Deploy Trin beacon bridge to serve the new lc finality data.
• [x] Modify light client crate to not require LC finality update for the current slot on sync startup.
  • commit: d1eb70eb722518c11ecf13286b4dc53ef3eaf4c8
• [x] Modify light client portal interface strategy for requesting LC finality update every slot (with finalized_slot as content key) when tracking the head of the chain.
  • commit: 5e89c6981f457ca90494ba67e3f3f4127df480ce
• [x] Refactor portal storage to allow custom db logic for beacon network.
• [x] Respond with the latest finality slot (if it is bigger or equal to the requested slot) on FindContent requests for LighClientFinalityUpdate. https://github.com/ethereum/trin/pull/1084
• [x] Support building a batch of LightClientUpdate records as a response to a period range request.
  • Special database for the beacon network: SQLite ?
• [x] Add static/frozen historical_roots accumulator to validate pre-Capella headers or provide it via the network.
• [x] Gossip and update historical_summaries beacon state accumulator to validate post-Capella headers: #1389
• [ ] Add a way to verify the latest headers (< ~27h or in the current period). These would/could be provided with temporary proof. The proof or the whole object would be ephemeral and updated once a new period occurs. See also issue: https://github.com/ethereum/portal-network-specs/issues/239
• [ ] (optional) Re-evaluate the bridge strategy for pushing latest LightClientUpdate data into the network?
  • [ ] (optional) implement score system for LightClientUpdate

[pipermerriam]

Reguarding the "special database for beacon network"... sqlite is quite powerful and will allow a schema'd database with complex queries... I believe that our use of rocksdb is a bit of cargo-cult leftover from execution clients storing all of the state and needing blazing fast read-write access. My intuition is that in our usage pattern the database read/write speeds are unlikely to be the bottleneck.