## EPF Week 12 Update

This week, I started on the VC's `publish_block` flow, which includes getting the block from BN, signing, and then publishing it back to the BN for gossip. During the investigation, I realized the modifications will depend a bit on what will be the changes to the beacon api, such as:
1. the existing VC -> BN `get_block` v3 call is versioned and returns full payload, kzg_commitments, and blobs. Will they just update the version to gloas and then rip out these fields and replace with the bid + payload_attestations in the body? or will they update to a new v4 endpoint?
https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Validator/produceBlockV3

The decision above kind of impacts how we'll then `sign_and_publish_block` since structs like the `UnsignedBlock` wouldn't contain `kzg_commitments` anymore, and assumedly not blobs either

Instead of waiting for the specs to come out that will shape the answers to the questions above, I took the initiative to make a [PR](https://github.com/ethereum/beacon-APIs/pull/552) to the beacon api repo detailing all the new and modified endpoints that will be required for epbs. This was a great opportunity to make an impact on epbs that will help out all of the CL clients.

TLDR of the PR:
### Updated Endpoints:
- `GET /eth/v3/validator/blocks/{slot}`
- Retrieves the gloas `BeaconBlock` so it can be signed, no blinded/unblinded variants nor `blobs/kzg_commitments` anymore
- `POST /eth/v2/beacon/blocks`
- Publishes a signed gloas `BeaconBlock` to the network

### New Endpoints:

**ExecutionPayloadBid**
- `GET /eth/v1/validator/execution_payload_bid/{slot}/{builder_index}`
- Retrieves the builder’s execution payload bid so it can be signed
- `POST /eth/v1/beacon/execution_payload_bid`
- Publishes a signed execution payload bid to the network, and the bid must pass gossip validation for success

**ExecutionPayloadEnvelope**
- `GET /eth/v1/validator/execution_payload_envelope/{slot}/{builder_index}`
- Retrieves the builder’s execution payload envelope so it can be signed
response
- `POST /eth/v1/beacon/execution_payload_envelope`
- Publishes a signed execution payload envelope to the network, and the envelope must pass gossip validation for success

**PTC**
- `POST /eth/v1/validator/duties/ptc/{epoch}`
- Retrieves Payload Timeliness Committee (PTC) duties for a given epoch and validator indices
- `GET /eth/v1/validator/payload_attestation_data/{slot}`
- Produces the payload attestation data for a given slot, to be signed by the validator if in the PTC that slot
- `POST /eth/v1/beacon/pool/payload_attestations`
- Submits a signed payload attestation message for gossip and pool inclusion
- `GET /eth/v1/beacon/pool/payload_attestations`
- Retrieves payload attestations currently in the beacon node’s operation pool

`Post` `SignedExecutionPayloadBid`
- endpoint to submit a signed bid to the BN for gossip

## Next Week
- resolve any PR comments to the beacon api PR
- start implementing the end points relevant to self-building block proposal pipeline