## Week 18 and Week 19 Updates:

### Progress on ePBS Implementation:

In the past two weeks, we've had two significant breakout meetings (#11 and #12) focusing on ePBS (Enshrined Proposer-Builder Separation). The main highlights include rethinking fork choice rules and client implementation updates.

#### Client Progress:

**Prysm**
- First to implement the new fork choice rules
- Main challenges we're facing:
- Need to modify core functions that decide which blocks to follow. `GetHead()`: Decides which block is the head of the chain. `Insert()`: Adds new blocks to the chain
- The tricky part is making sure old blocks work the same way while adding support for new ePBS blocks
- We're aiming to launch a test network in about two weeks

**Other Clients**
- Lighthouse: Currently reviewing our approach to fork choice
- Teku: Working on making their blocks compatible with new rules

### New Design Approach:

Francesco proposed a simpler way to handle ePBS:

**Before:**
- We give builders special power to influence fork choice (chain selection)
- Had complex boost systems for when payloads were withheld
- Multiple timers and boosts made things complicated

**New Approach:**
- Remove special builder powers
- Make payment processing wait until blocks are finalized
- Add specific time windows:
- 5 seconds to reveal data
- 10 seconds freeze period
- Makes the system simpler but needs precise timing

### Updated Roles in the Protocol:

#### Builder's Role:

// Before
BuilderRole {
    submit_payload_immediately: true
    get_paid_immediately: true
}

// After
BuilderRole {
    submit_payload: "within 5 seconds"
    payment: "after finalization"
}

#### Proposer's Role:
- Still creates blocks but with stricter timing rules
- Gets final say in certain voting situations

#### Attesters and Committee Members:
- Mostly unchanged
- Simpler voting rules

### Focus for next 2 weeks

Code Changes Needed:

// Need to modify how we handle payloads
type PayloadEnvelope {
    - remove_withheld_fields
    + add_new_timing_fields
}

// Need to track votes in the beacon state
type BeaconState {
    + add_vote_tracking
    + add_payment_tracking
}

### Implementation Plan:

- Launch test network
- Test basic functionality, Make sure multiple clients work together
- Add new vote tracking, Implement delayed payments
- Update fork choice rules, Add safety checks
- Prepare for mainnet

Immediate Tasks:
- Finish fork choice implementation
- Test with other clients
- Document new behaviors
- Prepare for test network launch