Add EIP-7805 (FOCIL) specs #4003

terencechain · 2024-11-04T13:19:16Z

This PR introduces a preliminary version of the EIP-7805 consensus specs, covering the beacon chain, fork choice, and validator. While there are still open questions regarding the consensus design, we believe it's early enough to open this up for broader community feedback. Major credit to @soispoke, @fradamt, @Ma-Julian, @jihoonsong, and everyone else who provided feedback along the way

suggested changes

Co-authored-by: terence <[email protected]>

jtraglia

Some comments from an initial skim.

specs/_features/eip7805/beacon-chain.md

specs/_features/eip7805/fork-choice.md

specs/_features/eip7805/beacon-chain.md

specs/_features/eip7805/p2p-interface.md

specs/_features/eip7805/validator.md

specs/_features/eip7805/p2p-interface.md

specs/_features/eip7805/beacon-chain.md

specs/_features/eip7805/validator.md

specs/_features/eip7805/fork-choice.md

jtraglia · 2024-11-05T20:03:42Z

specs/_features/eip7805/fork-choice.md

+        inclusion_list_committee: Vector[ValidatorIndex, IL_COMMITTEE_SIZE]]) -> None:
+    """
+    ``on_inclusion_list`` verify the inclusion list before importing it to fork choice store.
+    If there exists more than 1 inclusion list in store with the same slot and validator index, remove the original one.


I believe this is an out-of-date comment. Where is "remove the original one" happening exactly? It appears that it adds the validator to inclusion_list_equivocators instead now.

I believe this is an out-of-date comment. Where is "remove the original one" happening exactly? It appears that it adds the validator to inclusion_list_equivocators instead now.

I thought it's the other way around?

p2p only accepts an IL if it's the first or second IL broadcasted by the peer.

The responsibility of picking out the equivocators should be on the p2p side. Beacon node just replace the first IL with the second IL if that happens

The comments are outdated, and different client implementations may handle this differently. Essentially, we want to:

Cache at least one inclusion list

Re-broadcast up to two inclusion lists over P2P

Track which inclusion lists have been equivocated (e.g., identify the specific validator)

When calling the EL to validate inclusion lists, ignore those that have been equivocated (discard them from being sent to the EL)

Regarding whether to prioritize the first or second inclusion list, I'm leaning towards the first as it seems simpler

The comment is outdated, yeah. It doesn't really matter which one we keep, we could also not keep either since anyway we ignore them once we know that it is an equivocation. For spec simplicity it seemed easier to just not do anything instead of removing, and also perhaps it makes sense to keep the first, just because if you're the builder you would probably rather use it even if there's an equivocation, just in case, and you'd rather use the first since you saw it earlier and from your perspective it is more likely to be enforced by someone

specs/_features/eip7805/fork-choice.md

ensi321 · 2024-11-08T04:07:49Z

specs/_features/eip7805/p2p-interface.md

+
+This topic is used to propagate signed inclusion list as `SignedInclusionList`.
+The following validations MUST pass before forwarding the `inclusion_list` on the network, assuming the alias `message = signed_inclusion_list.message`:
+


Aren't we also limiting IL size by MAX_BYTES_PER_INCLUSION_LIST = 8192 bytes as indicated in the EIP?

ensi321 · 2024-11-08T05:00:24Z

specs/_features/eip7805/p2p-interface.md

+
+#### Messages
+
+##### InclusionListByCommitteeIndices v1


Do we need another endpoint like InclusionListByRange since recently joined nodes need to request past ILs to sync blocks since the last checkpoint?

We do not. Inclusion lists only matter for the current slot. When a node is syncing blocks from past slots, the inclusion list check can be skipped

Co-authored-by: Justin Traglia <[email protected]>

add MAX_BYTES_PER_INCLUSION_LIST, fix the related check

jihoonsong · 2024-12-30T16:50:43Z

specs/_features/eip7805/p2p-interface.md

+
+- _[REJECT]_ The size of `message` is within upperbound `MAX_BYTES_PER_INCLUSION_LIST`.
+- _[REJECT]_ The slot `message.slot` is equal to the previous or current slot.
+- _[IGNORE]_ The slot `message.slot` is equal to the current slot, or it is equal to the previous slot and the current time is less than `attestation_deadline` seconds into the slot.


Suggested change

- _[IGNORE]_ The slot `message.slot` is equal to the current slot, or it is equal to the previous slot and the current time is less than `attestation_deadline` seconds into the slot.

- _[IGNORE]_ The slot `message.slot` is equal to the previous slot and the current time is less than `attestation_deadline` seconds into the slot.

ensure valid committee with <16 validators

specs/_features/eip7805/beacon-chain.md

specs/_features/eip7805/validator.md

nflaig · 2025-01-12T22:21:38Z

specs/_features/eip7805/validator.md

+
+Some validators are selected to submit signed inclusion list. Validators should call `get_inclusion_committee_assignment` at the beginning of an epoch to be prepared to submit their inclusion list during the next epoch. 
+
+A validator should create and broadcast the `signed_inclusion_list` to the global `inclusion_list` subnet by `PROPOSER_INCLUSION_LIST_CUT_OFF` seconds into the slot, unless a block for the current slot has been processed and is the head of the chain and broadcast to the network.


In FOCIL CL & EL workflow there is the following note

If no block is received by t = 8s, they should run get_head and build and release their local ILs based on their node’s canonical head.

Is this something that should be part of the spec or up to the implementation when it should start building the IL on the block of previous slot?

Same logic, but you should use the EIP as a reference with the following timings:

Slot N, t=0 to 8s: IL committee members construct their ILs by including transactions pending in the public mempool, and broadcast them over the P2P network after processing the block for slot N and confirming it as the head. If no block is received by t=7s, they should run get_head and build and release their ILs based on the node’s local head.

https://eips.ethereum.org/EIPS/eip-7805

Rather than a strict length that might change between upgrades. This can be validated elsewhere (eg process_execution_payload).

nflaig · 2025-01-14T18:25:09Z

specs/_features/eip7805/validator.md

+
+#### Update execution client with inclusion lists
+
+The proposer should call `engine_updateInclusionListV1` at `PROPOSER_INCLUSION_LIST_CUT_OFF` into the slot with the list of the inclusion lists that gathered since `PROPOSER_INCLUSION_LIST_CUT_OFF`.


@jtraglia shouldn't this say something like "up to" instead of "since"? I think this is related to https://github.com/ethereum/consensus-specs/pull/4003/files#r1912551318, there is no specific time when we start to build the inclusion list as it depends on when the node receives the block or some other cutoff we might wanna define if the block for current slot is late.

Yes, "up to" is correct. Thanks I'll make that change.

And hmm. Would a late block change this? Wouldn't we always build the IL at PROPOSER_INCLUSION_LIST_CUT_OFF (11) seconds into the slot?

Wouldn't we always build the IL at PROPOSER_INCLUSION_LIST_CUT_OFF (11) seconds into the slot?

Yes, the cutoff for the proposer is always the same. The other cutoff I mean is for IL committee members but this one does not matter for the proposer as it would just collect all ILs it received for the slot until PROPOSER_INCLUSION_LIST_CUT_OFF

Ah got it. Well I will leave it to someone else (maybe @terencechain) to clarify.

To clarify: The proposer cutoff is always the same (11sec), but for IL committee members:

They receive a block, and can build their ILs right after they saw it

They don't receive a block until 7s, in which case they should run get_head and build and release their ILs based on the node’s local head, so they can propagate their ILs to the rest of the network before their stop doing so (at 8s).

The rest of validators (not the proposer, and not IL committee members) have the freeze deadline cutoff 1sec later, at 9s, at which point they stop storing new ILs.

nflaig · 2025-01-17T17:43:38Z

specs/_features/eip7805/p2p-interface.md

+
+| Name | Value | Unit | Duration |
+| - | - | :-: | :-: |
+| `ATTESTATION_DEADLINE` | `uint64(4)` | seconds | 4 seconds |


should time parameters be defined as a fraction of SECONDS_PER_SLOT instead, or do we just define them as part of presets to work with minimal as well?

Oh you're right, this wouldn't work with minimal... I'll look into the best way to handle this later.

Yes, that would work here. But not for other time values like:

consensus-specs/specs/_features/eip7805/validator.md

Line 45 in 2781459

| `PROPOSER_INCLUSION_LIST_CUT_OFF` | `uint64(11)` | seconds | 11 seconds |

Maybe that could be SECONDS_PER_SLOT - 1 instead.

Thanks @bleesherman. I've done just that. Please see: 7a2cb7a

Thinking about this more, not sure if having those values defined in preset will get us where we want as during testing we might use mainnet preset and just reduce seconds per slot. This would also make reducing seconds per slot in the future harder as you need to update a bunch of time parameters. But this might be something to worry about later

To be clear, these are configuration values now. As of that commit I shared.

Might be specific to how we handle this in Lodestar but even if it's part of config we can't derive the value from SECONDS_PER_SLOT

Ah dang. Well I suppose clients could use the values without deriving them.

consensus-specs/configs/mainnet.yaml

Lines 187 to 189 in 7a2cb7a

ATTESTATION_DEADLINE: 4

PROPOSER_INCLUSION_LIST_CUT_OFF: 11

VIEW_FREEZE_DEADLINE: 9

consensus-specs/configs/minimal.yaml

Lines 186 to 188 in 7a2cb7a

ATTESTATION_DEADLINE: 2

PROPOSER_INCLUSION_LIST_CUT_OFF: 5

VIEW_FREEZE_DEADLINE: 3

Well I suppose clients could use the values without deriving them.

That's what I did for now but will break if we change seconds per slot with mainnet config but it's possible to adapt these values as well now since we have them in config

terencechain and others added 20 commits September 30, 2024 10:49

Add focil containers

3a16a0e

Add process inclusion list aggregate

fa27c8f

Add inclusion list gossip conditions

3c86963

Add execution api

8a1e940

Add validator spec

833be94

Review feedback

a2b68a7

Update forkchoice

fb4a3c3

Update based on latest discussion. No more IL aggregate

c7a056b

Update fork-choice.md

f84556c

Update per https://ethresear.ch/t/focil-cl-el-workflow/20526

2787b0d

Address feedback

0b09f96

Clarify forkchoice and p2p

6056b69

Remove local

a8aec7c

suggested changes

cbe6129

Merge pull request #5 from fradamt/focil-patch

0efcf13

suggested changes

replace parent_root with il_committee_root

f151c7c

add timing logic (deaadlines) to IL processing

b181655

missing :

0681f8c

Co-authored-by: terence <[email protected]>

Merge pull request #6 from fradamt/focil-patch

2861684

Use eip7805

e678deb

terencechain force-pushed the focil-consensus branch from 165f25a to e678deb Compare November 4, 2024 13:30

jtraglia reviewed Nov 4, 2024

View reviewed changes

jtraglia reviewed Nov 5, 2024

View reviewed changes

ensi321 reviewed Nov 8, 2024

View reviewed changes

@jtraglia's suggestions

e9fdfc6

Co-authored-by: Justin Traglia <[email protected]>

terencechain force-pushed the focil-consensus branch from b3371b6 to e9fdfc6 Compare November 8, 2024 09:51

terencechain added 3 commits November 19, 2024 07:12

Update new inclusion list comments

6ce0077

P2p spec feedbacks

be471b8

Add get attester head

c443db0

fix byte limit check

7fa44f4

add MAX_BYTES_PER_INCLUSION_LIST, fix the related check

terencechain mentioned this pull request Dec 28, 2024

Implement EIP7805: Fork-choice enforced Inclusion Lists prysmaticlabs/prysm#14754

Open

ensure valid committee with <16 validators

84acfbb

jihoonsong reviewed Dec 30, 2024

View reviewed changes

Merge pull request #7 from nerolation/patch-1

702b9e5

ensure valid committee with <16 validators

nflaig mentioned this pull request Jan 9, 2025

FOCIL tracker ChainSafe/lodestar#7340

Open

37 tasks

nflaig reviewed Jan 12, 2025

View reviewed changes

jtraglia and others added 11 commits January 14, 2025 09:07

Merge branch 'dev' into focil-consensus

561aed7

Add eip7805 to list of executable specs

c762a33

Fix simple linter warnings

20b0c50

Fix some more linter issues

aca38ea

Add execution_requests_list to notify_new_payload

1c6761a

Fix things regarding engine API

d63042e

Update eth2spec before linting

86c86d0

Expand acronym in DOMAIN_IL_COMMITTEE and IL_COMMITTEE_SIZE

7d8e6fb

Rename il_transactions to inclusion_list_transactions

19b50a6

Change engine API param type to Sequence[Transaction]

f25efbf

Rather than a strict length that might change between upgrades. This can be validated elsewhere (eg process_execution_payload).

Fix various nits

5a37c91

nflaig reviewed Jan 14, 2025

View reviewed changes

jtraglia added 4 commits January 14, 2025 12:40

Replace "since" with "up to"

c411d45

Pull in electra's changes to verify_and_notify_new_payload

dcd31d6

Change inclusion_list_transactions to a Sequence

3652904

Make some improvements to fork-choice doc

2781459

nflaig reviewed Jan 17, 2025

View reviewed changes

ethereum deleted a comment from cheyenne-bot Jan 24, 2025

jtraglia added 2 commits January 24, 2025 10:53

Make time params work with minimal

7a2cb7a

Fix networking toc

91054e6

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP-7805 (FOCIL) specs #4003

Add EIP-7805 (FOCIL) specs #4003

terencechain commented Nov 4, 2024 •

edited

Loading

jtraglia left a comment

jtraglia Nov 5, 2024 •

edited

Loading

ensi321 Nov 8, 2024 •

edited

Loading

terencechain Nov 8, 2024

fradamt Nov 8, 2024

ensi321 Nov 8, 2024

ensi321 Nov 8, 2024

terencechain Nov 8, 2024

jihoonsong Dec 30, 2024

nflaig Jan 12, 2025

soispoke Jan 15, 2025

soispoke Jan 15, 2025

nflaig Jan 14, 2025 •

edited

Loading

jtraglia Jan 14, 2025

nflaig Jan 14, 2025

jtraglia Jan 14, 2025

soispoke Jan 15, 2025

nflaig Jan 17, 2025

jtraglia Jan 17, 2025

bleesherman Jan 24, 2025

jtraglia Jan 24, 2025

jtraglia Jan 24, 2025

nflaig Jan 24, 2025

jtraglia Jan 24, 2025

nflaig Jan 24, 2025

jtraglia Jan 24, 2025

nflaig Jan 24, 2025


		This topic is used to propagate signed inclusion list as `SignedInclusionList`.
		The following validations MUST pass before forwarding the `inclusion_list` on the network, assuming the alias `message = signed_inclusion_list.message`:

	- _[IGNORE]_ The slot `message.slot` is equal to the current slot, or it is equal to the previous slot and the current time is less than `attestation_deadline` seconds into the slot.
	- _[IGNORE]_ The slot `message.slot` is equal to the previous slot and the current time is less than `attestation_deadline` seconds into the slot.


		Some validators are selected to submit signed inclusion list. Validators should call `get_inclusion_committee_assignment` at the beginning of an epoch to be prepared to submit their inclusion list during the next epoch.

		A validator should create and broadcast the `signed_inclusion_list` to the global `inclusion_list` subnet by `PROPOSER_INCLUSION_LIST_CUT_OFF` seconds into the slot, unless a block for the current slot has been processed and is the head of the chain and broadcast to the network.


		#### Update execution client with inclusion lists

		The proposer should call `engine_updateInclusionListV1` at `PROPOSER_INCLUSION_LIST_CUT_OFF` into the slot with the list of the inclusion lists that gathered since `PROPOSER_INCLUSION_LIST_CUT_OFF`.

	\| `ATTESTATION_DEADLINE` \| `uint64(4)` \| seconds \| 4 seconds \|
	\| `ATTESTATION_DEADLINE` \| `SECONDS_PER_SLOT // 3` \| seconds \| 4 seconds \|

	ATTESTATION_DEADLINE: 4
	PROPOSER_INCLUSION_LIST_CUT_OFF: 11
	VIEW_FREEZE_DEADLINE: 9

	ATTESTATION_DEADLINE: 2
	PROPOSER_INCLUSION_LIST_CUT_OFF: 5
	VIEW_FREEZE_DEADLINE: 3

Add EIP-7805 (FOCIL) specs #4003

Are you sure you want to change the base?

Add EIP-7805 (FOCIL) specs #4003

Conversation

terencechain commented Nov 4, 2024 • edited Loading

jtraglia left a comment

Choose a reason for hiding this comment

jtraglia Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

ensi321 Nov 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nflaig Jan 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

terencechain commented Nov 4, 2024 •

edited

Loading

jtraglia Nov 5, 2024 •

edited

Loading

ensi321 Nov 8, 2024 •

edited

Loading

nflaig Jan 14, 2025 •

edited

Loading