Skip to content
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.

Sign up for GitHub

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

Clarify finality update FINDCONTENT handling #237

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Clarify finality update FINDCONTENT handling #237

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions beacon-chain/beacon-network.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,22 +189,24 @@ of use to the node. The content key requires the `finalized_slot` to be provided
so that this object can be more efficiently gossiped. Nodes should decide to
reject an `LightClientFinalityUpdate` in case it is not newer than the one they
already have.
For `FindContent` requests, a node will either know the last previous finalized
slot, if it has been following the updates, or it will have to guess slots that
are potentially finalized.
For `FindContent` requests:
- a requesting node will either know the last previous finalized slot, if it has been following the updates, or it will
have to guess slots that are potentially finalized.
- a responding node SHOULD reply with its current finality update if it corresponds the same or a newer slot than the one
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- a responding node SHOULD reply with its current finality update if it corresponds the same or a newer slot than the one
- a responding node SHOULD reply with its current finality update if it corresponds to the same or a newer slot than the one

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, I think we should actually make this MUST?

Suggested change
- a responding node SHOULD reply with its current finality update if it corresponds the same or a newer slot than the one
- a responding node MUST reply with its current finality update if it corresponds to the same or a newer slot than the one

specified in the `light_client_finality_update_key` in the `FINDCONTENT` message.

#### LightClientOptimisticUpdate

```
light_client_optimistic_update_key = Container(optimistic_slot: uint64)
light_client_optimistic_update_key = Container(signature_slot: uint64)
selector = 0x03

content = ForkDigest + SSZ.serialize(light_client_optimistic_update)
content_key = selector + SSZ.serialize(light_client_optimistic_update_key)
```

> The `LightClientOptimisticUpdate` objects are ephemeral and only the latest is
of use to the node. The content key requires the `optimistic_slot` (corresponding to
of use to the node. The content key requires the `signature_slot` (corresponding to
the `signature_slot` in the the update) to be provided so that this
object can be more efficiently gossiped. Nodes should decide to reject an
`LightClientOptimisticUpdate` in case it is not newer than the one they already have.
Expand Down
Loading