# PeerDAS: Beacon API `getBlobsSidecar` Change in Fulu

>*Below is a summary of a discussion thread from the #peerdas-testing channel on the Eth R&D Discord Server (March 28th 2025 to March 31st 2025).*

As part of the ongoing PeerDAS implementation client teams have been discussing important Beacon API considerations for the upcoming Fulu upgrade. The discussion around the Beacon API's `getBlobSidecars` endpoint for Fulu reveals consensus that this endpoint should be maintained for L2 users who need blobs, but avoiding exposure of implementation details like data columns should be considered.

## Key Points of Agreement

1. The `getBlobSidecars` endpoint should be maintained for users (particularly L2s) who need blobs, rather than exposing implementation details like data columns.

2. There's consensus that exposing data columns in the API would leak implementation details unnecessarily and could create future compatibility issues if the underlying implementation changes.

3. For non-super nodes without complete data, clients can either:
* Return an error with instructions to run with `--subscribe-all-subnets` option
* Reconstruct blobs if they have sufficient columns (at least 64)

4. For the proof field in responses:
* Keep the existing API schema unchanged
* Allow implementations to decide whether to provide correct blob proofs or inncorrect / empty proofs
* Most L2s don't verify the proofs anyway

## Open Discussion Points for Meeting Agenda

1. **API Functionality Requirements**:
* ~~Should the specification use "MAY" rather than "MUST" for reconstructing blobs?~~
* UPDATE: Consensus on "MAY"
* Should we clarify behavior for non-super nodes (error codes, messages)?

2. **Data Column Sidecars API**:
* Decide whether to add a separate `getDataColumnSidecars` endpoint for debugging
* Determine if this is required in the spec or left to implementation

3. **Performance Considerations**:
* Discuss reconstruction methods for different client implementations
* Evaluate CPU/resource impacts of various approaches

4. **API Stability**:
* Ensure changes provide a stable API for users regardless of future implementation changes
* Discuss deprecation strategy for any changing components

## Action Items

1. Update the PR to reflect the consensus reached on maintaining the `getBlobSidecars` endpoint

2. Determine specific error codes/messages for cases where nodes cannot provide data

3. Consider adding KZG library functions for efficient blob reconstruction that would enable nodes with 64 columns to quickly restore blobs without computing proofs, implementing simple methods that significantly improve performance for partial-data nodes:
* `recover_cells` (no proofs)
* `cells_to_Blob`
* `recover_blob`

4. Finalize specification wording around optional vs. required functionality

## Aside from Nico

"since there is plan to discuss api related topics, I am curious if it makes sense to finally consolidate prepareBeaconProposer and registerValidator as per https://github.com/ethereum/beacon-APIs/issues/435, as with validator custody we need another registration mechanism, or it the plan to just do it was part ofprepareBeaconCommitteeSubnet? doesn't seem like the best separation of concerns to me"