# **Final Project Update: Enshrined Proposer-Builder Separation (ePBS) Implementation in Nimbus**

## **Project Abstract**

**Project:** EIP-7732 Implementation - Enshrined Proposer-Builder Separation (ePBS)
**Client:** Nimbus Consensus Client
**GitHub Repository:** The initial [PR](https://github.com/status-im/nimbus-eth2/pull/6443/files) has been closed to accommodate further developments, and I am currently preparing an updated PR link.
**EIP Reference:** [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)

I set out to implement Enshrined Proposer-Builder Separation (ePBS) in the Nimbus Consensus Client because of the unique challenges it posed and the fact that it touches so many core aspects of the protocol. It was an exciting opportunity to dive deeper into Ethereum's inner workings and understand the protocol at a much more granular level. The goal was to decrease the reliance on external MEV-Boost relays and provide a trustless, protocol-native block construction marketplace. This would involve separating the beacon block and the execution payload, a significant shift that would reduce reliance on external builders while improving the efficiency of validators and the overall block propagation time.

By introducing Payload Timeliness Committees (PTCs) and splitting the slot into separate execution and consensus validation phases, ePBS addresses critical issues of centralization, validator efficiency, and block propagation times.

While the integration introduces significant breaking changes to the existing codebase, it offers a transformative path towards decentralizing Ethereum’s block construction and creating a transparent, equitable MEV market.

---

## **Technical Implementation Status**

### **Key Architectural Changes**

The implementation modifies multiple components of the Consensus layer, incorporating the core principles of enshrined Proposer-builder separation into the consensus layer. Below are some key aspects of the implementation:

1. **Processing Withdrawals**
This now takes only the state as a parameter, as withdrawals are deterministic based on the beacon state. Any execution payload with the corresponding block as the parent must honor these withdrawals in the execution layer.

   proc process_withdrawals*(state: var epbs.BeaconState): Result[void, cstring] =
       if not is_parent_block_full(state):
           return err("parent block is empty")

       let (withdrawals, partial_withdrawals_count) = get_expected_withdrawals_with_partial_count(state)

       state.pending_partial_withdrawals = 
           HashList[PendingPartialWithdrawal, Limit PENDING_PARTIAL_WITHDRAWALS_LIMIT].init(
               state.pending_partial_withdrawals.asSeq[partial_withdrawals_count .. ^1]
           )

       var withdrawals_list: List[Withdrawal, Limit MAX_WITHDRAWALS_PER_PAYLOAD]
       for i in 0 ..< min(len(withdrawals), MAX_WITHDRAWALS_PER_PAYLOAD):
           withdrawals_list[i] = withdrawals[i]

       state.latest_withdrawals_root = hash_tree_root(withdrawals_list)

       for i in 0 ..< len(withdrawals):
           let validator_index = ValidatorIndex.init(withdrawals[i].validator_index).valueOr:
               return err("process_withdrawals: invalid validator index")
           decrease_balance(state, validator_index, withdrawals[i].amount)

       ok()

2. **Processing Execution Payload Headers**
The process_execution_payload_header function validates the signed execution payload header within a beacon block. It ensures the header's signature is valid, verifies the builder has sufficient funds to cover the bid, and checks that the bid matches the current slot and parent block. Finally, it processes the fund transfer from the builder to the proposer.

    proc process_execution_payload_header*(state: var epbs.BeaconState,
        blck: epbs.BeaconBlock): Result[void, cstring] =

      let signed_header = blck.body.signed_execution_payload_header

      for vidx in state.validators.vindices:
        let pubkey = state.validators.item(vidx).pubkey()

        if not verify_execution_payload_header_signature(
          state.fork, state.genesis_validators_root, signed_header,
          state, pubkey, signed_header.signature):
          return err("payload_header: signature verification failure")

      let 
        header = signed_header.message
        builder_index = header.builder_index
        amount = header.value

      if state.balances.item(builder_index) < amount:
        return err("insufficient balance")

      if header.slot != blck.slot:
        return err("slot mismatch")

      if header.parent_block_hash != state.latest_block_hash:
        return err("parent block hash mismatch")

      if header.parent_block_root != blck.parent_root:
        return err("parent block root mismatch")

      let proposer_index = ValidatorIndex.init(blck.proposer_index).valueOr:
        return err("process_execution_payload_header: proposer index out of range")

      let builder_idx = ValidatorIndex.init(builder_index).valueOr:
        return err("process_execution_payload_header: builder index out of range")

      decrease_balance(state, builder_idx, amount)
      increase_balance(state, proposer_index, amount)

      state.latest_execution_payload_header = header

      ok()

3. **Processing Payload Attestations**
Handles the validation of payload attestations, ensuring their signatures are valid and align with the expected state

   proc process_payload_attestation*(state: var epbs.BeaconState,
       blck: epbs.BeaconBlock, payload_attestation: PayloadAttestation,
       cache: var StateCache, base_reward_per_increment: Gwei): Result[void, cstring] =
       if not is_valid_indexed_payload_attestation(state, payload_attestation):
           return err("process_payload_attestation: signature verification failed")
       ok()

### **Key Challenges**

- **Breaking Changes:** Integrating ePBS requires replacing the `ExecutionPayload` field with `SignedExecutionPayloadHeader` and updating multiple processes, including state transitions and attestation handling.
- **Cross Compatibility:** Adapting the implementation to the existing codebase introduced unique challenges due to its architectural changes.
- **Testing:** The complexity of the new state transitions and cryptographic operations requires rigorous simulation and testing.

## **Project Status**

### **Challenges**
While significant progress has been made, the transition to make it compatible with a specific hardfork required closing the initial PR and rebuilding portions of the implementation. This allows the project to align with other specifications but also introduced delays. Testing continues to be a primary focus to ensure robustness.

## **DevNet Goal (short term)**

For DevNet testing, the following goals are currently being prioritized:

- **Separation of Payload and Beacon Block:**
Ensure the successful decoupling of the execution payload from the beacon block, and validate the correct handling of both by the network.

- **No Bid Propagation Subscription:**
Demonstrate that validators can successfully self-build blocks and that block builders are no longer necessary for block construction in the new ePBS model.

- **Handling Empty Blocks (No Payload) for Fork Choice Purposes:**
Ensure that empty blocks (i.e., blocks without an execution payload) are processed correctly within the fork choice logic.

- **Valid PTC Committees and Attestations:**
Verify that PTCs are functioning correctly, validating payload timeliness and availability, and that they continue to process attestation data.

## **Fork Choice Logic Update**

Currently, there is ongoing work on a **new fork choice proposal** that incorporates the goals of ePBS, FOCIL, and PeerDAS. This proposal aims to better integrate the fork choice mechanism with the changes brought by ePBS and is essential for testing and validating the new structure. You can review the current design [here](https://hackmd.io/UX7Vhsv8RTy8I49Uxez3Ng?view).

## **Acknowledgment**

I want to express my heartfelt gratitude to **Josh** and **Mario**, the coordinators of the Ethereum Protocol Fellowship (EPF), for their incredible support and leadership. Their guidance has been instrumental in shaping this project. I am equally thankful to my mentors, **Tersec**, **Potuz**, and **Terence**, who provided invaluable insights and encouraged me to think critically while tackling the technical challenges.

This experience has been a transformative mental shift. Diving deep into Ethereum’s protocol and the **Nimbus architecture** has fundamentally expanded my understanding. The challenges have been immense, but they’ve also been worth it. I’ve learned so much—both about Ethereum and about pushing through complex technical problems.

## **Future Work**

- **Testing and Optimization:** Finalizing and verifying the implementation to ensure all edge cases are handled.
- **Updated PR:** An updated PR link will be shared soon, incorporating feedback and additional tests.
- **Exploration:** Investigating further enhancements for ePBS, including performance optimizations and extended use cases.

## **Takeaways**

Participating in EPF has been a privilege. It’s been challenging, rewarding, and filled with learning moments. This program has given me the opportunity to grow as a developer and to contribute meaningfully to Ethereum’s future. I’m excited to continue working on this project and others and to explore how ethereum and blockchain can contribute to a much more decentralised better world.