Add EIP-7805 (FOCIL) specs #4003
Conversation
suggested changes
Co-authored-by: terence <[email protected]>
terencechain
force-pushed
the
focil-consensus
branch
from
165f25a
to
e678deb
Compare
| ```python | ||
| def validate_inclusion_lists(store: Store, inclusion_list_transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST * IL_COMMITTEE_SIZE], execution_payload: ExecutionPayload) -> bool: | ||
| """ | ||
| Return ``True`` if and only if the input ``inclusion_list_transactions`` satifies validation, that to verify if the `execution_payload` satisfies `inclusion_list_transactions` validity conditions either when all transactions are present in payload or when any missing transactions are found to be invalid when appended to the end of the payload unless the block is full. |
There was a problem hiding this comment.
We should line wrap this. And execution_payload and inclusion_list_transactions should be wrapped in double back-ticks; they currently use single back-ticks.
| ### Modified `Store` | ||
| **Note:** `Store` is modified to track the seen inclusion lists. |
There was a problem hiding this comment.
Need a blank line between these lines.
| - _[REJECT]_ The signature of `inclusion_list.signature` is valid with respect to the validator index. | ||
|
|
||
|
|
||
| ### The Req/Resp domain |
specs/_features/eip7805/validator.md
Outdated
| epoch: Epoch, | ||
| validator_index: ValidatorIndex) -> Optional[Slot]: | ||
| """ | ||
| Returns the slot during the requested epoch in which the validator with index `validator_index` |
There was a problem hiding this comment.
This needs double back-ticks too.
specs/_features/eip7805/validator.md
Outdated
| 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 `inclusion_list_CUT_OFF` | ||
|
|
||
|
|
||
| ## New inclusion list committee duty |
There was a problem hiding this comment.
Also, the sentence on line 89 needs punctuation.
|
|
||
| | `fork_version` | Chunk SSZ type | | ||
| |------------------------|------------------------------------------| | ||
| | `EIP-7805_FORK_VERSION` | `EIP-7805.SignedInclusionList` | |
There was a problem hiding this comment.
I don't believe this dash will work here. In most places, we need to replace EIP-7805 with EIP7805.
| `on_inclusion_list` is called to import `signed_inclusion_list` to the fork choice store. | ||
| ```python |
There was a problem hiding this comment.
Need a blank line between the paragraph & code block.
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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_equivocatorsinstead 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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
|
||
| 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`: | ||
|
|
There was a problem hiding this comment.
Aren't we also limiting IL size by MAX_BYTES_PER_INCLUSION_LIST = 8192 bytes as indicated in the EIP?
|
|
||
| #### Messages | ||
|
|
||
| ##### InclusionListByCommitteeIndices v1 |
There was a problem hiding this comment.
Do we need another endpoint like InclusionListByRange since recently joined nodes need to request past ILs to sync blocks since the last checkpoint?
There was a problem hiding this comment.
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]>
terencechain
force-pushed
the
focil-consensus
branch
from
b3371b6
to
e9fdfc6
Compare
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