-
Notifications
You must be signed in to change notification settings - Fork 998
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
PeerDAS fork-choice, validator custody and parameter changes #3779
base: dev
Are you sure you want to change the base?
Changes from 4 commits
2b455c1
7c72ec8
9159bd0
56e9d38
54157a2
f98241b
e4e30f3
6723efd
40c55e6
fcca8fd
107dda6
e9398f6
22456c8
0f1e471
ef64924
82103dd
4f3c150
908f37d
1acba8b
a2db18c
19804a3
1613d2e
62006c9
3f5ba2e
8dbd874
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -73,15 +73,18 @@ We define the following Python custom types for type hinting and readability: | |||||||||||||||||||||||
|
||||||||||||||||||||||||
| Name | Value | Description | | ||||||||||||||||||||||||
| - | - | - | | ||||||||||||||||||||||||
| `DATA_COLUMN_SIDECAR_SUBNET_COUNT` | `32` | The number of data column sidecar subnets used in the gossipsub protocol | | ||||||||||||||||||||||||
| `DATA_COLUMN_SIDECAR_SUBNET_COUNT` | `128` | The number of data column sidecar subnets used in the gossipsub protocol | | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
### Custody setting | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
| Name | Value | Description | | ||||||||||||||||||||||||
| - | - | - | | ||||||||||||||||||||||||
| `SAMPLES_PER_SLOT` | `8` | Number of `DataColumn` random samples a node queries per slot | | ||||||||||||||||||||||||
| `CUSTODY_REQUIREMENT` | `1` | Minimum number of subnets an honest node custodies and serves samples from | | ||||||||||||||||||||||||
| `TARGET_NUMBER_OF_PEERS` | `70` | Suggested minimum peer count | | ||||||||||||||||||||||||
| `SAMPLES_PER_SLOT` | `16` | Number of `DataColumn` random samples a node queries per slot | | ||||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is no such thing as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice catch! |
||||||||||||||||||||||||
| `CUSTODY_REQUIREMENT` | `4` | Minimum number of subnets an honest node custodies and serves samples from | | ||||||||||||||||||||||||
| `VALIDATOR_CUSTODY_REQUIREMENT` | `6` | Minimum number of subnets an honest node with validators attached custodies and serves samples from | | ||||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think
Why not just have a single There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I would like to preserve is:
How do you feel about this, with def get_validators_custody_requirement(state: BeaconState, validator_indices: List[ValidatorIndex]) -> uint64:
total_node_balance = sum(state.balances[index] for index in validator_indices)
validator_custody_requirement = VALIDATOR_CUSTODY_REQUIREMENT
if total_node_balance >= MIN_ACTIVATION_BALANCE:
validator_custody_requirement += (total_node_balance - MIN_ACTIVATION_BALANCE) // BALANCE_PER_ADDITIONAL_CUSTODY_SUBNET
return validator_custody_requirement There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm I understand the rationale. Your alternative is generally fine, but it does feel a little overly-complex. How about something like the following? def get_validators_custody_requirement(state: BeaconState, validator_indices: List[ValidatorIndex]) -> uint64:
total_node_balance = sum(state.balances[index] for index in validator_indices)
count = total_node_balance // BALANCE_PER_ADDITIONAL_CUSTODY_SUBNET
return min(max(count, VALIDATOR_CUSTODY_REQUIREMENT), DATA_COLUMN_SIDECAR_SUBNET_COUNT) This would provide the following custody requirements:
This makes the computation relatively straight forward:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 on using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Francesco's implementation uses that too. But yes, the constant is a good idea. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah you're right. It was a pseudocode mistake & the declaration/usage of
So that it properly scales if we (1) increase the max EB again or (2) increase the subnet count. (Also, I fixed the backwards There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this version, because it only starts increasing from There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am a bit worried on the direction of dynamically increasing the custody count depending on how many validators you do run with. For context, last year we finally moved to a new attestation subnet backbone structure where the responsibility for subscribing to long-lived attestation subnets was equally distributed amongst all nodes rather than those running many validators: The way validator custody is currently specified, you would reintroduce the same downsides by requiring nodes running with many validators to custody all the subnets. Is it necessary to scale the custody count this way ? anyway we can simply have an upper bound rather than all the subnets being custodied if you run more than > 64 validators. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The rationale behind making custody-count depend on something is as follows:
This goes agains the "hiding" property achieved by equally distributing, but improves system performance. Once we change to 2D encoding, we can go back to equally distributing custody.
I'm not sure I interpret this right, but it is important that we can't stop custody requirement at 64. Otherwise, if there would be exactly 64 columns released, we would need a supernode that is by miracle subscribed to the exact same 64 columns. There are too many combinations for that, we would need too many supernodes. If really needed, we could stop before 128, but we need way more than 64. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Echoing the above, and also @dapplion's comment that validator custody means that in practice, given the actual stake distribution, most of the stake will be run on supernodes, which imho is a good thing, because it hugely derisks the whole system. It basically means that the introduction of DAS is essentially irrelevant for 90% of the validator set, other than moving from gossiping few large objects to a lot of smaller objects. And why shouldn't someone that runs hundreds of validators, with millions or even tens of millions of stake, be downloading the whole data and contributing to the security and stability of the network? This is quite different from the attestation subnets case imho, because there are huge tangible benefits to be had from linearly scaling the load based on stake. Also, validator custody does not change the fact that all nodes still share the responsibility for forming the backbone of long-lived subscriptions, though not equally. Another point here is that downloading the whole data is by far the best way to ensure that you always correctly fulfil validator duties, including protecting you when proposing. |
||||||||||||||||||||||||
| `BALANCE_PER_ADDITIONAL_CUSTODY_SUBNET` | `Gwei(16 * 10**9)` | Balance increment corresponding to one additional subnet to custody | | ||||||||||||||||||||||||
| `TARGET_NUMBER_OF_PEERS` | `100` | Suggested minimum peer count | | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
fradamt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
### Containers | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
@@ -201,7 +204,15 @@ def get_data_column_sidecars(signed_block: SignedBeaconBlock, | |||||||||||||||||||||||
|
||||||||||||||||||||||||
### Custody requirement | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
Each node downloads and custodies a minimum of `CUSTODY_REQUIREMENT` subnets per slot. The particular subnets that the node is required to custody are selected pseudo-randomly (more on this below). | ||||||||||||||||||||||||
Each node *without attached validators* downloads and custodies a minimum of `CUSTODY_REQUIREMENT` subnets per slot. A node with validators attached downloads and custodies a higher minimum of subnets per slot, determined by `get_validators_custody_requirement(state, validator_indices)`. Here, `state` is the current `BeaconState` and `validator_indices` is the list of indices corresponding to validators attached to the node. Any node with at least one validator attached downloads and custodies a minimum of `VALIDATOR_CUSTODY_REQUIREMENT` subnets per slot, as well as `total_node_balance // BALANCE_PER_ADDITIONAL_CUSTODY_SUBNET` additional subnets, where `total_node_balance` is the sum of the balances of all validators attached to that node. | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
```python | ||||||||||||||||||||||||
def get_validators_custody_requirement(state: BeaconState, validator_indices: List[ValidatorIndex]) -> uint64: | ||||||||||||||||||||||||
total_node_balance = sum(state.balances[index] for index in validator_indices) | ||||||||||||||||||||||||
return VALIDATOR_CUSTODY_REQUIREMENT + (total_node_balance // BALANCE_PER_ADDITIONAL_CUSTODY_SUBNET) | ||||||||||||||||||||||||
``` | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
The particular subnets that the node is required to custody are selected pseudo-randomly (more on this below). | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
A node *may* choose to custody and serve more than the minimum honesty requirement. Such a node explicitly advertises a number greater than `CUSTODY_REQUIREMENT` via the peer discovery mechanism -- for example, in their ENR (e.g. `custody_subnet_count: 4` if the node custodies `4` subnets each slot) -- up to a `DATA_COLUMN_SIDECAR_SUBNET_COUNT` (i.e. a super-full node). | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,173 @@ | ||
# EIP-7594 -- Fork Choice | ||
|
||
## Table of contents | ||
<!-- TOC --> | ||
<!-- START doctoc generated TOC please keep comment here to allow auto update --> | ||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> | ||
|
||
- [Introduction](#introduction) | ||
- [Containers](#containers) | ||
- [Helpers](#helpers) | ||
- [Extended `PayloadAttributes`](#extended-payloadattributes) | ||
- [`is_data_available`](#is_data_available) | ||
- [Updated fork-choice handlers](#updated-fork-choice-handlers) | ||
- [`on_block`](#on_block) | ||
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update --> | ||
<!-- /TOC --> | ||
|
||
## Introduction | ||
|
||
This is the modification of the fork choice accompanying EIP-7594 | ||
fradamt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### Helpers | ||
|
||
### `is_data_available` | ||
|
||
```python | ||
def is_data_available(beacon_block_root: Root, require_peer_sampling: bool=False) -> bool: | ||
# Unimplemented function which returns the node_id and custody_subnet_count | ||
node_id, custody_subnet_count = get_custody_parameters() | ||
columns_to_retrieve = get_custody_columns(node_id, custody_subnet_count) | ||
if require_peer_sampling: | ||
columns_to_retrieve += get_sampling_columns() | ||
column_sidecars = retrieve_column_sidecars(beacon_block_root, columns_to_retrieve) | ||
return all( | ||
verify_data_column_sidecar_kzg_proofs(column_sidecar) | ||
for column_sidecar in column_sidecars | ||
) | ||
``` | ||
|
||
### `is_chain_available` | ||
|
||
```python | ||
def is_chain_available(store: Store, beacon_block_root: Root) -> bool: | ||
block = store.blocks[beacon_block_root] | ||
block_epoch = compute_epoch_at_slot(block.slot) | ||
current_epoch = get_current_store_epoch(store) | ||
if block_epoch + MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS <= current_epoch: | ||
return True | ||
parent_root = block.parent_root | ||
return ( | ||
is_data_available(beacon_block_root, require_peer_sampling=True) | ||
and is_chain_available(store, parent_root) | ||
) | ||
|
||
``` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should delete the blank line. |
||
|
||
### `get_head` | ||
|
||
```python | ||
def get_head(store: Store) -> Root: | ||
# Get filtered block tree that only includes viable branches | ||
blocks = get_filtered_block_tree(store) | ||
# Execute the LMD-GHOST fork choice | ||
head = store.justified_checkpoint.root | ||
while True: | ||
# Get available children for the current slot | ||
children = [ | ||
root for (root, block) in blocks.items() | ||
if ( | ||
block.parent_root == head | ||
and is_data_available( | ||
root, | ||
require_peer_sampling=is_peer_sampling_required(store, block.slot) | ||
) | ||
) | ||
] | ||
if len(children) == 0: | ||
return head | ||
# Sort by latest attesting balance with ties broken lexicographically | ||
# Ties broken by favoring block with lexicographically higher root | ||
head = max(children, key=lambda root: (get_weight(store, root), root)) | ||
``` | ||
|
||
```python | ||
def is_peer_sampling_required(store, slot): | ||
return compute_epoch_at_slot(slot) + 2 <= get_current_epoch(store) | ||
``` | ||
|
||
## Updated fork-choice handlers | ||
|
||
### `on_block` | ||
|
||
*Note*: The blob data availability check is removed and replaced with an availability | ||
check on the on the justified checkpoint in the "pulled up state" of the block, after | ||
applying `process_justification_and_finalization`. | ||
|
||
```python | ||
def on_block(store: Store, signed_block: SignedBeaconBlock) -> None: | ||
""" | ||
Run ``on_block`` upon receiving a new block. | ||
""" | ||
block = signed_block.message | ||
# Parent block must be known | ||
assert block.parent_root in store.block_states | ||
# Make a copy of the state to avoid mutability issues | ||
state = copy(store.block_states[block.parent_root]) | ||
# Blocks cannot be in the future. If they are, their consideration must be delayed until they are in the past. | ||
assert get_current_slot(store) >= block.slot | ||
|
||
# Check that block is later than the finalized epoch slot (optimization to reduce calls to get_ancestor) | ||
finalized_slot = compute_start_slot_at_epoch(store.finalized_checkpoint.epoch) | ||
assert block.slot > finalized_slot | ||
# Check block is a descendant of the finalized block at the checkpoint finalized slot | ||
finalized_checkpoint_block = get_checkpoint_block( | ||
store, | ||
block.parent_root, | ||
store.finalized_checkpoint.epoch, | ||
) | ||
assert store.finalized_checkpoint.root == finalized_checkpoint_block | ||
|
||
# Check the block is valid and compute the post-state | ||
block_root = hash_tree_root(block) | ||
state_transition(state, signed_block, True) | ||
|
||
# [New in EIP7594] Do not import the block if its unrealized justified checkpoint is not available | ||
pulled_up_state = state.copy() | ||
process_justification_and_finalization(pulled_up_state) | ||
assert is_chain_available(store, pulled_up_state.current_justified_checkpoint.root) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that we shoud also check the current justified checkpoint for the non-pulled-up: |
||
|
||
# Add new block to the store | ||
store.blocks[block_root] = block | ||
# Add new state for this block to the store | ||
store.block_states[block_root] = state | ||
|
||
# Add block timeliness to the store | ||
time_into_slot = (store.time - store.genesis_time) % SECONDS_PER_SLOT | ||
is_before_attesting_interval = time_into_slot < SECONDS_PER_SLOT // INTERVALS_PER_SLOT | ||
is_timely = get_current_slot(store) == block.slot and is_before_attesting_interval | ||
store.block_timeliness[hash_tree_root(block)] = is_timely | ||
|
||
# Add proposer score boost if the block is timely and not conflicting with an existing block | ||
is_first_block = store.proposer_boost_root == Root() | ||
if is_timely and is_first_block: | ||
store.proposer_boost_root = hash_tree_root(block) | ||
|
||
# Update checkpoints in store if necessary | ||
update_checkpoints(store, state.current_justified_checkpoint, state.finalized_checkpoint) | ||
|
||
# Eagerly compute unrealized justification and finality. | ||
compute_pulled_up_tip(store, block_root, pulled_up_state) | ||
``` | ||
|
||
#### Pull-up tip helpers | ||
|
||
##### `compute_pulled_up_tip` | ||
fradamt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Modified to take `pulled_up_state`, the block's state after applying `processing_justification_and_finalization`. | ||
The application of `processing_justification_and_finalization` now happens in `on_block`. | ||
|
||
```python | ||
def compute_pulled_up_tip(store: Store, pulled_up_state: BeaconState, block_root: Root) -> None: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Has this function been modified only to avoid executing |
||
store.unrealized_justifications[block_root] = pulled_up_state.current_justified_checkpoint | ||
unrealized_justified = pulled_up_state.current_justified_checkpoint | ||
unrealized_finalized = pulled_up_state.finalized_checkpoint | ||
update_unrealized_checkpoints(store, unrealized_justified, unrealized_finalized) | ||
|
||
# If the block is from a prior epoch, apply the realized values | ||
block_epoch = compute_epoch_at_slot(store.blocks[block_root].slot) | ||
current_epoch = get_current_store_epoch(store) | ||
if block_epoch < current_epoch: | ||
update_checkpoints(store, unrealized_justified, unrealized_finalized) | ||
``` |
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.
Note that most clients don't use this config value, so I guess this is more like a reference / recommendation?
#3766 (comment)
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 have created a PR to remove
TARGET_NUMBER_OF_PEERS
as a config variable