[EIP-7805/Heze] Should IL non-compliance persist for descendants of a bad FULL payload?

[juan-altamira]

Follow-up from #4931, where the “one slot vs persist” penalty question was raised but not explicitly resolved.

Reading the current Heze/Gloas fork-choice, it looks like IL non-compliance is handled through payload_inclusion_list_satisfaction + should_extend_payload, so get_head() prefers EMPTY for the previous-slot payload when that payload failed the IL constraints. But I don’t see an explicit rule making that penalty persistent for descendants of the FULL payload.

Concretely: suppose a FULL payload at slot N is locally known to be IL-incompliant, but a branch building on that FULL survives and, by slot N+15, has the most attesting weight and an IL-compliant head. Should a FOCIL node still consider that branch eligible to become head?

If this is not already handled elsewhere, I think it may be worth making IL non-compliance sticky for the FULL payload branch only:

A fork-choice node should be ineligible to become head if its path depends on any ancestor FULL payload for which is_payload_inclusion_list_satisfied(store, root) == False.

Important distinction: this should taint only descendants that build on the bad FULL payload, not the beacon root or the EMPTY path. The EMPTY path remains the valid reorg escape.

This would preserve the current immediate reorg behavior while preventing a later head from “laundering” an old IL-incompliant payload just by building enough compliant descendants on top of it. It also seems aligned with the intuition that FOCIL enforcement should mean “do not build canonical history on top of an IL-incompliant execution payload”, rather than only “try to reorg it in the next slot”.

[jihoonsong]

An IL-non-compliant payload reorg is designed analogously to a proposer reorg, i.e., a 1-slot reorg. It is a design decision, not an unhandled exception.

a FULL payload at slot N is locally known to be IL-incompliant, but a branch building on that FULL survives

In order to this to happen, malicious attesters should be majority at slot N.

As a side note, making IL enforcement persistent is not impossible. A clean approach would be modifying get_node_children() to add FULL child only when its parent is IL-compliant. Thus, if we come to prefer persistent enforcement over 1-slot, we could easily switch.

[juan-altamira]

Thanks, that clarifies the intended design.

My remaining concern is less about a single bad branch surviving once, and more about the systematic case: if a malicious attester majority at one or more slots can make IL-incompliant FULL payloads survive, the current one-slot design seems to allow those payloads to be “laundered” by later compliant descendants.

The stronger invariant seems easier to reason about:

no honest fork-choice head should depend on an IL-incompliant FULL payload.

I understand that a surviving bad FULL requires a malicious majority of attesters at slot N, but that is exactly the case where persistent enforcement seems valuable: it prevents a malicious majority in specific slots from repeatedly inserting IL-incompliant FULL payloads into canonical history and relying on later compliant descendants to normalize them.

Also, switching to persistent enforcement only after such behavior becomes attack-relevant would itself be consensus-critical: old and updated nodes could disagree on head eligibility for the same branch. So if the persistent rule is considered desirable in that attack case, defining it before activation seems safer than relying on emergency coordination after the bad FULL payload branch has already survived.

[jihoonsong]

Imagine a case that we have split view with the following conditions:

• All active validators are honest.
• A set of 16 ILs is partitioned into two disjoint subsets IL_A and IL_B.
• Half of the validators received IL_A and the other half received IL_B, with the attesters evenly split between the two groups.
• The proposer received IL_A.
• The payload satisfies IL_A but not IL_B.

With the persistent enforcement, this will split the chain forever even without any malicious validators. This might happen when the p2p network becomes unreliable for whatever reason such as client bugs, cloud provider outages, BGP hijacks, etc.

If enforcement cannot be persistent, how long should it last? In other words, what is k in a k-slot reorg? k=1 inherits the same fork choice assumptions we have today, which doesn't add any new assumption.

Another question is whether the cost of securing a majority of attesters to canonicalize a non-IL-compliant payload is economically rational. An attacker with such resources could potentially do something worse than that.

[juan-altamira]

I agree that persistent local tainting can create a liveness problem under honest split views.

I am not arguing that fully persistent enforcement is necessarily the right rule.

But I think the “an attacker with a majority could do worse things” argument does not remove this concern. The point is not that persistent enforcement solves every majority attack. The point is that it changes this specific failure mode: a censoring majority would not be able to insert IL-incompliant FULL payloads and later have them normalized as accepted canonical history by honest fork-choice.

Without that, one-slot enforcement leaves a path where coercive censorship can be absorbed by the canonical chain once later descendants are IL-compliant again.

That is not neutral for censorship resistance.

The realistic attacker here may not be an economically motivated private attacker. It may be governments or regulated entities pressuring proposers and in-protocol builders to omit privacy-related transactions, and pressuring attesters/validators to treat those censoring payloads as acceptable, using arguments similar to those used against Tornado Cash: sanctions compliance, money laundering, DPRK-related activity, national security, etc. Ethereum has already seen OFAC-compliant block-production behavior after the Tornado Cash sanctions, so this does not seem like an exotic threat model.

So the tradeoff seems to be:

• persistent enforcement can create liveness/split-view problems;
• one-slot enforcement can allow repeated coercive censorship to be normalized later.

Is there a middle-ground rule that preserves convergence under honest split views, but prevents clearly IL-incompliant FULL payloads from being repeatedly inserted and later laundered by compliant descendants?

[lau90eth]

The three tests in #5301 make explicit the 1-slot reorg design at the
fork-choice level. In particular, test_equivocating_il_member_transactions_excluded
demonstrates the equivocation-as-censorship-channel property (FINDINGS.md §2.4).

On the persistence question raised here: the split-view liveness counterexample
from @jihoonsong (IL_A / IL_B partition with honest validators) seems to rule out
fully persistent tainting. A middle ground worth exploring: taint only the FULL
subtree within the current epoch, clearing at epoch boundaries. This preserves
the reorg incentive for recent slots while avoiding permanent chain splits from
honest disagreement.

[juan-altamira]

@lau90eth I think the middle-ground proposal above is worth analyzing.

Fully persistent tainting may indeed create unacceptable liveness risk under honest split views, as @jihoonsong pointed out. But pure one-slot enforcement may also be too weak if the goal is to preserve a strong reorg incentive against recent IL-non-compliant FULL payloads.

A bounded rule such as “taint only the FULL subtree within the current epoch, clearing at epoch boundaries” seems like a useful intermediate point in the design space. It may avoid permanent chain splits while still making recent IL violations harder to normalize immediately.

[jtraglia]

Hey @juan-altamira & @jihoonsong, what's the status of this issue?

[jihoonsong]

FOCIL is a fork-choice rule, not a protocol rule. Whether the enforcement period is 1 slot or 1 epoch does not move the needle. Making it longer than 1 slot will only complicate the protocol for no meaningful gain.

The real tradeoff here was whether to make it a fork-choice rule or a protocol rule. A protocol rule can guarantee that no payload that is not IL-compliant will ever become canonical by invalidating such payloads. To achieve this, ILs must be recorded in the block.

This will increase the block size, of course, but it will also require some sort of incentive mechanism. This is because recording data onchain is not free, a.k.a. the free DA problem. We'll likely introduce an incentive mechanism for ILs in the future, but this opens the door to significant complexity, and much research remains to be done.

We had many discussions and our conclusion was to go with fork-choice, as the name suggests.

But I think the “an attacker with a majority could do worse things” argument does not remove this concern.

It doesn't remove your concern. It does mitigate it to a great extent. You need to seize control of >50% of total staked ETH to break the security assumption. You should consider the ETH acquisition cost, sourcing strategy, attack execution, coordination, profit and loss, and so on.