# Data Availability Checker in Lighthouse

ePBS fundamentally changes how clients perform data availability checks. Here's how we're simplifying things at Lighthouse to take advantage of it

### A quick primer

The Deneb fork's flagship feature was EIP-4844 Proto-Danksharding, which introduced a new transaction type that stores blob data temporarily in beacon nodes. This upgrade changed the block validation pipeline. Prior to Deneb, a block became attestable once it passed consensus verification and its payload executed successfully. Post-Deneb, validators must complete an additional data availability check. A beacon node can only consider a block valid for attestation after receiving and verifying all associated blob sidecars. A new field was added to the beacon block, `blob_kzg_commitments`. If this field is empty, no blobs are expected for this block. If this field isn't empty, blobs are expected for this block.

In Fulu, an optimization to blob storage was introduced. Now beacon nodes are only required to custody a subset of the blob data, in the form of data columns. A beacon node now considers a block attestable after receiving and verifying the subset of data columns it's required to custody, alongside consensus and payload verification.

### ePBS and block payload separation

In the upcoming Gloas upgrade we are once again updating the block validation pipeline. Enshrined Proposer Builder Separation (ePBS) separates the block from its execution payload. Instead of including the full execution payload, beacon blocks now contain an execution payload bid. The execution payload arrives separately from the beacon block in the form of an execution payload envelope.

*There's a lot more to ePBS beyond block payload separation, but those details are out of scope for this post.*

Remember back in pre-Deneb days when validators could attest to blocks without having to perform any data availability checks? Now with ePBS, beacon blocks are once again always considered available! ePBS optimizes this even further by separating the payload from the block. There is no longer a requirement to execute the payload for the beacon block to be attestable. As soon as a beacon block is received, the beacon node just needs to perform consensus verification. The heavier payload execution and data availability checks are now moved to the execution payload envelope.

### Old DA checker flow


In the old DA checker, blocks and columns are cached as they are received. It is required to both validate columns **AND** execute the block's payload in order for it to be attestable. Additionally, all of this **MUST** happen by the attestation deadline.

### New DA checker flow


In the new DA checker, the payload bid and columns are cached as they are received. The payload envelope itself arrives separately and doesn't ever make it into the DA checker. Therefore there exists an intermediate state where the payload **data** is marked as available even though the **envelope** hasn't been received. Payload execution is also extracted out of the DA checker and moved to a separate process.

To summarize the benefits:
- The DA checker no longer needs to worry about payload execution.
- We have more time to make DA checks, we aren't constrained to do everything before the attestation deadline.
- Additionally we can start making DA checks before receiving the payload thus spreading out the heavy, potentially computationally intensive work across the duration of the slot.

Note that this is a work in progress and subject to change. Heres the PR if you want to dig in further: https://github.com/sigp/lighthouse/pull/8716

### Summary

The new Lighthouse DA checker has been simplified for Gloas. My coworker Pawan has actually already simplified the existing DA checker by removing some state caching mechanisms that I won't get into in this post (Tree states ftw). But Gloas lets us simplify things even further by spreading heavy computation across the full duration of the slot instead of forcing everything to happen by the attestation deadline. ePBS gives us client devs a great chance to reduce tech debt, refactor things and build out new optimizations. It also paves the way for reduced slot times, higher gas limits, higher blob counts and plenty of other cool things. "If there's an issue, ePBS probably fixes it". Bonus points if you know who I'm quoting.