Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal

I can provide a “grammar” to differentiate the many combinations:

  • In the simplest case, you have a single proposer P delivering a block B(P):

    [B(P)]

  • If you have some inclusion list IL and an enforcement mechanism => (e.g., conditional vs unconditional, ToB vs BoB vs unspecified etc.), the delivered block must respect the IL enforcement conditions:

    IL => [B(P)]

  • In CBP, you have a payload delivered by two partial proposers (P1 and P2), so the block is obtained from concatenating the two partial blocks:

    [B(P1); B(P2)]

  • In FOCIL, there are m committee members each producing a local IL (yielding IL1, IL2, … ILm), which are then aggregated to the global IL, which applies to the block delivered by a single proposer P. So:

    (IL1, IL2, …, ILm) → IL => [B(P)]

A risk with CBP is that the multiple proposers deliver uncoordinated partial payloads, meaning the transactions of B(P1) have precedence over the transactions of B(P2), which may revert based on what goes on in B(P1). With FOCIL, the single proposer P has full knowledge of IL and controls fully the constrained state transition function (constrained by the IL enforcement mechanism).

As an additional note, we could also dream up of FOCIL + CBP:

(IL1, IL2, …, ILm) → IL => [B(P1); B(P2)]

But this feels hard, because who should be on the hook for satisfying the IL? If P1 believes P2 will satisfy the IL, and P2 believes P1 will, then there may be invalid blocks delivered in the case where the IL enforcement is agnostic with respect to the location of the IL transactions. There are cases where it’s not an issue however, when e.g., the IL enforcement requires all transactions of the (ordered or unordered) IL to be placed in the ToB, then we could require P1 to deliver B(P1) = [IL; *], where they can fill up * with whatever they like.

2 Likes