From 7af6a3afa494120f3a0e8828d3ee54636d0c3ada Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Wed, 25 Mar 2020 15:56:26 -0600 Subject: [PATCH 1/2] do not require non-aggregating validators to subscribe to attestation subnet for beacon committee duties --- specs/phase0/validator.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index 54cd19a93..8d0e02144 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -200,9 +200,11 @@ The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahe Specifically a validator should: * Call `get_committee_assignment(state, next_epoch, validator_index)` when checking for next epoch assignments. -* Join the pubsub topic -- `committee_index{committee_index % ATTESTATION_SUBNET_COUNT}_beacon_attestation`. - * For any current peer subscribed to the topic, the validator simply sends a `subscribe` message for the new topic. +* Find peers of the pubsub topic -- `committee_index{committee_index % ATTESTATION_SUBNET_COUNT}_beacon_attestation` -- and join if aggregator. * If an _insufficient_ number of current peers are subscribed to the topic, the validator must discover new peers on this topic. Via the discovery protocol, find peers with an ENR containing the `attnets` entry such that `ENR["attnets"][committee_index % ATTESTATION_SUBNET_COUNT] == True`. + * If the validator is assigned to be an aggregator for the slot (see `is_aggregator()`), then for any peer subscribed to the topic the validator sends a `subscribe` message for this topic. + +*Note*: If the validator is _not_ assigned to be an aggregator, the validator only needs sufficient number of peers on the topic to be able to publish messages. The validator does not need to _subscribe_ and listen to all messages on the topic. ## Beacon chain responsibilities From a83e7a5eccec74a83139a1a2a64669986e5ab220 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Thu, 26 Mar 2020 10:46:06 -0600 Subject: [PATCH 2/2] proto PR feedback --- specs/phase0/validator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index 8d0e02144..e97cf759c 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -200,9 +200,9 @@ The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahe Specifically a validator should: * Call `get_committee_assignment(state, next_epoch, validator_index)` when checking for next epoch assignments. -* Find peers of the pubsub topic -- `committee_index{committee_index % ATTESTATION_SUBNET_COUNT}_beacon_attestation` -- and join if aggregator. +* Find peers of the pubsub topic `committee_index{committee_index % ATTESTATION_SUBNET_COUNT}_beacon_attestation`. * If an _insufficient_ number of current peers are subscribed to the topic, the validator must discover new peers on this topic. Via the discovery protocol, find peers with an ENR containing the `attnets` entry such that `ENR["attnets"][committee_index % ATTESTATION_SUBNET_COUNT] == True`. - * If the validator is assigned to be an aggregator for the slot (see `is_aggregator()`), then for any peer subscribed to the topic the validator sends a `subscribe` message for this topic. + * If the validator is assigned to be an aggregator for the slot (see `is_aggregator()`), then subscribe to the topic. *Note*: If the validator is _not_ assigned to be an aggregator, the validator only needs sufficient number of peers on the topic to be able to publish messages. The validator does not need to _subscribe_ and listen to all messages on the topic.