-
Notifications
You must be signed in to change notification settings - Fork 984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP-7805 (FOCIL) specs #4003
base: dev
Are you sure you want to change the base?
Conversation
suggested changes
Co-authored-by: terence <[email protected]>
165f25a
to
e678deb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments from an initial skim.
```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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete the extra blank line.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete extra blank line here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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]>
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