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.

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

Aggregator selection from RPC to validator client #4071

Merged
merged 35 commits into from
Nov 22, 2019
Merged

Conversation

terencechain
Copy link
Member

@terencechain terencechain commented Nov 20, 2019

Part of #3865

This PR implements aggregator selection for RPC server and hardness the aggregator connection between beacon node and validator client. There's no breaking logic changes. Validator client simply queries beacon node on per slot basis to check if it's an aggregator. You should see these 2 logs if the validator is also an aggregator

Beacon node:

INFO rpc/aggregator: Broadcasting aggregated attestation and proof committeeIndex=0 slot=3 validatorIndex=30

Validator client:

INFO validator: Assigned and submitted aggregation and proof request committeeIndex=0 pubKey=0x82cd058276c7 slot=3

Change list:

  • Added AttestationsBySlotCommittee, it returns to-be-aggregated attestations based on slot and committee
  • Started rpc/aggregator/server.go, it has one RPC call SubmitAggregateAndProof, it's for validator to submit slot signature, and check if the validator is an aggregator then broadcast aggregation signature and proof
  • Started /client/validator_aggregate.go, it implements SubmitAggregateAndProof, the validator computes slot signature to send it to beacon node's aggregator server
  • Added PB definitions for service AggregatorService and call SubmitAggregateAndProof

Context for reviewers: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/validator/0_beacon-chain-validator.md#attestation-aggregation

@terencechain terencechain changed the title Aggregator part 1 Aggregator selection from RPC to validator client Nov 20, 2019
@terencechain terencechain self-assigned this Nov 20, 2019
@codecov
Copy link

codecov bot commented Nov 20, 2019

Codecov Report

Merging #4071 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4071   +/-   ##
=======================================
  Coverage   57.99%   57.99%           
=======================================
  Files         203      203           
  Lines       13042    13042           
=======================================
  Hits         7564     7564           
  Misses       4398     4398           
  Partials     1080     1080

Copy link
Contributor

@rauljordan rauljordan left a comment

Choose a reason for hiding this comment

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

Comin' along! I'm excited for this feature

@@ -137,6 +138,23 @@ func (s *Service) AttestationPoolNoVerify(ctx context.Context) ([]*ethpb.Attesta
return atts, nil
}

// AttestationsBySlotCommittee returns the attestations from the attestations pool that's filtered
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// AttestationsBySlotCommittee returns the attestations from the attestations pool that's filtered
// AttestationsBySlotCommittee returns the attestations from the attestations poo filtered

// AttestationsBySlotCommittee returns the attestations from the attestations pool that's filtered
// by slot and committee index.
func (s *Service) AttestationsBySlotCommittee(ctx context.Context, slot uint64, index uint64) ([]*ethpb.Attestation, error) {
s.attestationPoolLock.Lock()
Copy link
Contributor

Choose a reason for hiding this comment

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

Can this be a read lock?

Copy link
Member Author

Choose a reason for hiding this comment

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

sure


// SubmitAggregateAndProof is called by a validator at every slot to check whether
// it's assigned to be an aggregator. If yes, server will broadcast aggregated attestation
// and proof on the validators behave.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// and proof on the validators behave.
// and proof regarding the validators' behavior.

}

validatorIndex, exists, err := as.BeaconDB.ValidatorIndex(ctx, bytesutil.ToBytes48(req.PublicKey))
if err != nil || !exists {
Copy link
Contributor

Choose a reason for hiding this comment

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

These should be two separate if's. One should throw an internal code error if err != nil and the other should through NotFound if !exists

Copy link
Member

@prestonvanloon prestonvanloon left a comment

Choose a reason for hiding this comment

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

Needs tests.

Is there a E2E evaluator you can add to test this logic at runtime?
Maybe in a follow up PR, but it would be nice to see this tested E2E in addition to the unit tests.

beacon-chain/operations/attestation.go Show resolved Hide resolved
beacon-chain/rpc/aggregator/server.go Show resolved Hide resolved
// via gRPC. Beacon node will verify the slot signature and determine if the validagtor is also
// an aggregator. If yes, then beacon node will broadcast aggregated signature and
// proof on the validator's behave.
func (v *validator) SubmitAggregateAndProof(ctx context.Context, slot uint64, pubKey [48]byte) {
Copy link
Member

Choose a reason for hiding this comment

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

Please add a test

@terencechain terencechain added the Ready For Review A pull request ready for code review label Nov 21, 2019
@terencechain
Copy link
Member Author

Needs tests.

Is there a E2E evaluator you can add to test this logic at runtime?
Maybe in a follow up PR, but it would be nice to see this tested E2E in addition to the unit tests.

definitely, that is coming

switch role {
case pb.ValidatorRole_BOTH:
go v.SubmitAttestation(slotCtx, slot, id)
v.SubmitAggregateAndProof(ctx, slot, id)
Copy link
Member

Choose a reason for hiding this comment

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

Can this be in a go routine so it doesn't block proposing a block?

Copy link
Member

Choose a reason for hiding this comment

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

Also, wouldn't this be part of SubmitAttestation?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ha. Yeah. Was going to add it next PR when we implement the logic to Wait till 3/4 of the slot and submit aggregated attestation and proof I'll add it now :)

@@ -16,6 +16,10 @@ service ProposerService {
rpc ProposeBlock(ethereum.eth.v1alpha1.BeaconBlock) returns (ProposeResponse);
}

service AggregatorService {
Copy link
Member

Choose a reason for hiding this comment

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

Why create a new service? Shouldn't this be part of the validator service?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think Aggregator should have its own role (ie. similar to proposer and attester). It makes it more extensible as the aggregating spec gets more complicated and we adopt real-life aggregation protocol. Another reason is aggregator perform time based role (ie. submits signed slot signature when it's 2/3 of the slot)

Copy link
Member

Choose a reason for hiding this comment

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

Thanks!

return nil, status.Errorf(codes.Internal, "Could not get validator index from DB: %v", err)
}
if !exists {
return nil, errors.New("could not locate validator index in DB")
Copy link
Member

Choose a reason for hiding this comment

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

status.Error?

Copy link
Member Author

Choose a reason for hiding this comment

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

done

SyncChecker sync.Checker
}

// SubmitAggregateAndProof is called by a validator at every slot to check whether
Copy link
Member

Choose a reason for hiding this comment

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

Every slot? Is there no way to determine this in assignments or at epoch level?

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated comment. Should be every slot if you are part of the committee

"slot": req.Slot,
"validatorIndex": validatorIndex,
"committeeIndex": req.CommitteeIndex,
}).Info("Broadcasting aggregated attestation and proof")
Copy link
Member

Choose a reason for hiding this comment

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

What broadcasting? This doesn't broadcast anything

Copy link
Member Author

Choose a reason for hiding this comment

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

This PR is just for selection. Will handle broadcast next. Updated log to reflect that

@@ -246,6 +246,7 @@ func MinimalSpecConfig() *BeaconChainConfig {
minimalConfig.ShuffleRoundCount = 10
minimalConfig.MinGenesisActiveValidatorCount = 64
minimalConfig.MinGenesisTime = 0
minimalConfig.TargetAggregatorsPerCommittee = 1
Copy link
Member

Choose a reason for hiding this comment

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

Why 1? Just wondering

Copy link
Member Author

Choose a reason for hiding this comment

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

For 64 validators, you get 4 validators per committee. 1 is the easiest number to see it work live given the modulus selection approach

switch role {
case pb.ValidatorRole_BOTH:
go v.SubmitAttestation(slotCtx, slot, id)
v.SubmitAggregateAndProof(ctx, slot, id)
Copy link
Member

Choose a reason for hiding this comment

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

Also, wouldn't this be part of SubmitAttestation?

"committeeIndex": assignment.CommitteeIndex,
"pubKey": fmt.Sprintf("%#x", bytesutil.Trunc(pubKey[:])),
}).Info("Assigned and submitted aggregation and proof request")
}
Copy link
Member

Choose a reason for hiding this comment

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

It feels like something is missing here...

validator/client/validator_aggregate.go Show resolved Hide resolved
@prestonvanloon
Copy link
Member

v.ProposeBlock(slotCtx, slot, id)
case pb.ValidatorRole_ATTESTER:
v.SubmitAggregateAndProof(ctx, slot, id)
Copy link
Member

Choose a reason for hiding this comment

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

If both of these wait until different times in the slot, you're going to have problems unless they run in goroutines

Copy link
Member Author

Choose a reason for hiding this comment

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

Agree. Switched to go routines

SyncChecker sync.Checker
}

// SubmitAggregateAndProof is called by a validator at every slot if you are part of the committee
Copy link
Member

Choose a reason for hiding this comment

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

Please update comment

@prylabs-bulldozer prylabs-bulldozer bot merged commit f5cb040 into master Nov 22, 2019
@delete-merged-branch delete-merged-branch bot deleted the aggregator branch November 22, 2019 05:11
cryptomental pushed a commit to cryptomental/prysm that referenced this pull request Feb 24, 2020
* Config
* Updated proto
* Updated pool
* Updated RPC
* Updated validator client
* run time works
* Clean ups
* Fix tests
* Visibility
* Merge branch 'master' of https://github.com/prysmaticlabs/prysm into aggregator
* Raul's feedback
* Tests for RPC server
* Tests for validator client
* Span
* More tests
* Use go routine for SubmitAggregateAndProof
* Go routines
* Updated comments
* Use array of roles
* Fixed tests
* Build
* Update validator/client/runner.go

Co-Authored-By: Preston Van Loon <preston@prysmaticlabs.com>
* Update validator/client/runner.go

Co-Authored-By: Preston Van Loon <preston@prysmaticlabs.com>
* If
* Merge branch 'refactor-validator-roles' of https://github.com/prysmaticlabs/prysm into refactor-validator-roles
* Empty
* Feedback
* Merge branch 'master' of https://github.com/prysmaticlabs/prysm into aggregator
* Removed proto/eth/v1alpha1/shard_chain.pb.go?
* Cleaned up
* Revert
* Comments
* Lint
* Comment
* Merge branch 'master' into aggregator
cryptomental pushed a commit to cryptomental/prysm that referenced this pull request Feb 28, 2020
* Config
* Updated proto
* Updated pool
* Updated RPC
* Updated validator client
* run time works
* Clean ups
* Fix tests
* Visibility
* Merge branch 'master' of https://github.com/prysmaticlabs/prysm into aggregator
* Raul's feedback
* Tests for RPC server
* Tests for validator client
* Span
* More tests
* Use go routine for SubmitAggregateAndProof
* Go routines
* Updated comments
* Use array of roles
* Fixed tests
* Build
* Update validator/client/runner.go

Co-Authored-By: Preston Van Loon <preston@prysmaticlabs.com>
* Update validator/client/runner.go

Co-Authored-By: Preston Van Loon <preston@prysmaticlabs.com>
* If
* Merge branch 'refactor-validator-roles' of https://github.com/prysmaticlabs/prysm into refactor-validator-roles
* Empty
* Feedback
* Merge branch 'master' of https://github.com/prysmaticlabs/prysm into aggregator
* Removed proto/eth/v1alpha1/shard_chain.pb.go?
* Cleaned up
* Revert
* Comments
* Lint
* Comment
* Merge branch 'master' into aggregator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready For Review A pull request ready for code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants