All-in-one fork-choice for ePBS/DAS/FOCIL

Ethereum is constantly evolving, enhancing its protocols to improve security, scalability, and fairness. An important aspect of its infrastructure is the fork-choice rule, which determines the canonical chain in the presence of competing forks. This rule essentially maintains consensus across the network. Recently, a proposal has emerged to refine Ethereum’s fork-choice rule by francesco, which would work for 3 advanced and important mechanisms: enshrined Proposer-Builder Separation (ePBS), Fork-Choice Enforced Inclusion Lists (FOCIL), and Data Availability Sampling (DAS). This unified approach aims to create a more robust and efficient network by combining the strengths of these individual features.

Core Mechanisms

To appreciate the implications of this proposal, it is crucial to understand each component’s role within the Ethereum network.

enshrined Proposer-Builder Separation (ePBS) (EIP-7732)

Proposer-Builder Separation decouples the roles of block proposers (validators) and block builders. In this paradigm, specialized builders construct blocks optimized for MEV–such as including transactions with the highest fees or modify the ordering of transactions–while proposers select and propose these blocks to the network. enshrining this separation basically implies that proposer and builder will have trustless way of doing this. The best-case scenario in this case would eliminate the centralized network of relays that currently handles the majority of block production.

Fork-Choice Enforced Inclusion Lists (FOCIL)

FOCIL introduces a mechanism to ensure the inclusion of some transactions, particularly to eliminate censorship. Validators commit to inclusion lists that specify transactions which must be included in upcoming blocks. The fork-choice rule enforces these commitments by favoring chains that honor the inclusion lists. This mechanism promotes fairness and protects user transactions from being disregarded due to censorship or other exclusionary practices.

Data Availability Sampling (DAS)

As Ethereum scales, especially with the implementation of sharding, it becomes impractical for every node to store all blockchain data. DAS addresses this challenge by enabling nodes to verify data availability without downloading the entire dataset. Through probabilistic sampling techniques, nodes can ascertain that all parts of a block’s data are accessible. DAS is critical for ensuring the integrity and security of the network as it allows nodes to participate in consensus without the burden of full data storage.

Rationale for Integration

While ePBS, FOCIL, and DAS each contribute significantly to Ethereum’s robustness, they operate independently, leading to potential trade-offs:

• ePBS optimizes block creation and selection but does not inherently enforce transaction inclusion fairness.
• FOCIL ensures the inclusion of specified transactions but does not influence block-building.
• DAS guarantees data availability but does not affect or help the speed or fairness of block propagation.

Integrating these mechanisms into a unified fork-choice rule can harmonize their benefits, resulting in a network that is simultaneously secure, efficient, and fair.

The Unified Fork-Choice Rule

The proposed unified framework operates through several key components:

Availability Committee (AC)

An Availability Committee is a randomly selected subset of validators assigned to each block. Their responsibilities include:

1. Timeliness and Payload Availability: Voting on the availability of the block’s payload (the execution data) to ensure it is publicly known shortly after block proposal.
2. Data Availability Verification: Checking the availability of associated data blobs (e.g., sharded data) by verifying through DAS.
3. Inclusion List Enforcement: Performing an initial check on whether the block satisfies the inclusion lists without executing the payload.

The AC votes are crucial for the next proposer’s decisions and for guiding attesters in the subsequent slot.

Builder Behavior and Payment Processing

Builders construct payloads (blocks) with the added constraint of satisfying inclusion lists. They release the block data in stages:

1. Upon Beacon Block Receipt: After seeing the beacon block
   $B$ that commits to their payload
   $P$, builders propagate the associated data blobs.
2. After Attestation Threshold: If
   $B$ receives at least 40% of attestations and no conflicting blocks (equivocations) are detected, builders release the execution payload
   $P$.

Payment to builders is processed based on the payload becoming canonical:

• Canonical Payload: If
  $P$ becomes part of the canonical chain, payment is processed immediately.
• Non-Canonical Payload: If
  $P$ doesn’t become canonical, payment is only processed if
  $B$ received significant attestation support (e.g., 60%) and no proposer equivocations are detected by the end of the next epoch.

Proposer Behavior

The proposer in the next slot

$(N+1)$ uses the fork-choice rule to decide whether to extend

$B$ with or without

$P$:

• Extending with Payload: If the AC votes indicate that
  $P$ is available and meets inclusion list requirements, the proposer extends
  $B$ with
  $P$.
• Extending without Payload: If the AC votes do not favor
  $P$, the proposer extends
  $B$ without
  $P$.

To ensure consistency, the proposer includes all AC votes they have seen in their beacon block. Attesters use these votes to make informed decisions, aligning with the proposer’s view.

Attester Behavior and Fork-Choice Mechanism

Attesters play a critical role in solidifying the chain’s state by voting on blocks. Their behavior is guided by the unified fork-choice rule:

1. Attesters determines the head of the chain by applying the fork-choice rule.
2. Based on AC votes and data availability checks, attesters decide whether to vote for
   $B$ with
   $P$ or
   $B$ without
   $P$.
3. IL Verification: Attesters verify that the payload satisfies the inclusion lists it committed to via a bitfield included in the block header.

The fork-choice mechanism is adjusted to handle blocks with and without payloads as distinct yet competing branches. Attestations from the slot in which B was proposed count towards both branches, while attestations from subsequent slots differentiate between them.

Inclusion List Enforcement Details

Inclusion lists are enforced in two stages:

1. AC Enforcement: The AC ensures that the payload commits to satisfying the inclusion lists by checking the bitfield against inclusion lists seen by the freeze deadline (10 seconds into the slot).
2. Attester Enforcement: Attesters verify that the payload indeed includes the transactions from the inclusion lists it committed to, requiring execution of the payload.

Equivocations by inclusion list proposers are handled by propagating up to two inclusion lists per proposer and ignoring conflicting ones during verification.

Slot-by-Slot Coordination

Each slot in Ethereum’s time is divided into different intervals (currently 3 in Prysm) for integration of ePBS, FOCIL, and DAS:

1. Slot Start: The current proposer proposes a beacon block
   $B$, committing to a payload
   $P$.
2. Builder Actions: Builders construct
   $P$ satisfying inclusion lists and release data blobs and the execution payload based on attestation thresholds.
3. Availability Committee Voting: At a designated time (7 seconds into the slot), AC members vote on the availability and compliance of the payload
   $P$.
4. Next Proposer’s Decision: The proposer for slot
   $N+1$ uses AC votes to decide whether to extend Block
   $B$ with or without the payload
   $P$.
5. Finally, Attesters validate blocks and cast votes, enforcing inclusion lists and data availability, and justifying the chain’s state.

This coordination ensures that each participant—builders, proposers, AC members, and attesters—contributes to a cohesive and robust consensus mechanism.

Technical Details of the Fork-Choice Mechanism

The fork-choice rule is central to determining the canonical chain. For this framework some key components are as followed:

Block Tree Structure

• Dual Branches: For each beacon block
  $B$, there are two potential branches:
  • $B$ without payload (
    $B_{empty}$)
  • $B$ with payload (
    $B_{full}$)

These branches compete in the fork-choice, with attestations determining which one becomes canonical.

Attestation Weight Calculation

• Attestations in the same slot as
  $B$ count towards both
  $B_{empty}$ and
  $B_{full}$ since the payload
  $P$ is not yet available.
• Attestations in the next slot differentiate between
  $B_{empty}$ and
  $B_{full}$, solidifying the choice based on AC votes and data availability.

Fork-Choice Execution Steps

1. The head is determined by running the fork-choice, considering both
   $B_{empty}$ and
   $B_{full}$.
2. To check Payload Availability, use AC votes to assess whether
   $P$ is available and satisfies inclusion lists.
3. Perform DAS to ensure all required data blobs are available.
4. Verify that
   $P$ includes all required transactions as per inclusion lists.

Proposer Boost and Equivocation Handling

• Proposer Boost gives additional weight to a block proposed by the selected proposer, helping it become canonical even with limited attestation support.
• Equivocation are detected by monitoring for conflicting blocks proposed in the same slot. If detected, they adjust their fork-choice and potentially withhold releasing payloads or processing payments to prevent rewarding malicious behavior.

Availability Committee Lock-In (Headlock)

• There is a Headlock Mechanism to prevent potential equivocations. Upon seeing a Block
  $B$, AC members “lock-in” their votes to prevent equivocation from affecting the builder’s payload.
• The consistency is assured by ensuring that if the builder releases Payload
  $P$ based on observing no equivocation, the AC will support
  $P$, aiding in its adoption.

Attester Decision Logic

Attesters follow a precise logic to decide their votes:

1. AC votes are aggregated by merging their view of AC votes with those included in the proposer’s block, resolving any conflicts by prioritizing the proposer’s included votes.
2. If
   $P$ has majority support in the AC votes, proceed to the next checks.
3. Confirm that all custody columns are available and that
   $P$ satisfies the inclusion lists it committed to and also satifies the checks for DA.
4. Finally, cast their attestation for
   $B_{full}$ if all checks pass; otherwise, vote for
   $B_{empty}$ or an alternative head.

Note: For in-depth understanding refer this original article writtten by francesco.