Persisting Data Columns

Currently the das branch does not act on columns received over gossip. On top of that, it persists the columns inconsistently. The inconsistency arises beacuse put_kzg_verified_blobs marks the RpcBlock as Available once all blobs have been received. Any data columns received over gossip after will be ignored and the peer will be banned.

To solve for this situation:

1. Prevent put_kzg_verified_blobs from marking the block as available
2. Act on and persist columns recevied over gossip

Persisting columns received over gossip

The data columns are persisted on the LRU cache, a key value store where the key is the block root and the value is the pending_component.

PendingComponent

The PendingComponent has the following fields relevant to DAS

• block_root
• verified_data_columns

As new data columns come in over gossip, put_gossip_data_column is executed. This codepath first checks if there is an existing PendingComponent in the LruCache for the given block_root. It pops out the existing PendingComponent (if it exists, if not it creates a new one), and merges the incoming data columns with the columns we currently have cached. The newly merged PendingComponent is then submitted to the cache.

Taking action on persisted columns

Currently put_kzg_verified_data_columns does not act upon incoming data columns. Changes should be made to this function to:

1. check if the required columns are available to begin sampling
2. execute sampling
3. on sample success set status to Available

Note that we need access to the nodes enr for custody/sampling requirements.

Additional requirements

The beacon chain needs to know about which columns to keep custody of. Column custody requirements are a function of the nodes ENR. The beacon chain itself isn't aware of any networking related info, including the ENR. If it were to have a reference to, NetworkGlobals for example, this woud introduce a circular dependency. Instead, a service should be created within the networking crate to calculate column requirements and then send that information to the beacon chain.

Outdated notes

The DA checker must have access to the local enr in order to calculate the nodes custody requirements and perform sampling.

Since everything is Arc'd, mutating fields in the DA checker where network_globals is available is not straightforward

I ended up wrapping the network_globals in a RwLock. This provides thread safety and inner mutability

PR: https://github.com/sigp/lighthouse/pull/5438/files

Here are some notes on other options I tried

• I tried getting an inner mutable ref of the arc'd network glboal. The issue is that because the ref counter for the arc > 1 I am unable to get the inner mutable ref
• I tried wrapping the Arc<NetworkGlobals> field in da checker with a Cell. The issue is that Cell isnt thread safe, so that doesn't work.

Cell<Arc<NetworkGlobals<<T as BeaconChainTypes>::EthSpec>>> cannot be shared between threads safely
within DataAvailabilityChecker<T>, the trait Sync is not implemented for Cell<Arc<NetworkGlobals<<T as BeaconChainTypes>::EthSpec>>>
if you want to do aliasing and mutation between multiple threads, use std::sync::RwLock