Beacon Portal Network implementation progress

[ogenev]

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

Tasks

• Use finalized slot in LightClientFinalityUpdate content key and update beacon bridge to serve the data. #1007
• Deploy Trin beacon bridge to serve the new lc finality data.
• Modify light client crate to not require LC finality update for the current slot on sync startup.
  • commit: d1eb70e
• 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: 5e89c69
• Refactor portal storage to allow custom db logic for beacon network.
• Respond with the latest finality slot (if it is bigger or equal to the requested slot) on FindContent requests for LighClientFinalityUpdate. feat: add beacon storage cache for light client updates #1084
• Support building a batch of LightClientUpdate records as a response to a period range request.
  • Special database for the beacon network: SQLite ?
• Add static/frozen historical_roots accumulator to validate pre-Capella headers or provide it via the network.
• Gossip and update historical_summaries beacon state accumulator to validate post-Capella headers: feat(portal-bridge(beacon)): generate and gossip HistoricalSummariesWithProof content #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: History Network: How to deal with the Ephemeral-ness of header canonicalness proofs portal-network-specs#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.