Separate type for unaggregated network attestations #14659

rkapka · 2024-11-22T16:55:19Z

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Implements ethereum/consensus-specs#3900

The above consensus change introduces a new SingleAttestation type for unaggregated attestations. AttestationElectra will still be used for aggregated atts. Using the single version in all of our code would be a huge undertaking because many components, such as the attestation pool and attestation caches, require attestations to be of the old format. Modifying these components to work both with pre-Electra attestations and the single attestation is risky and too much work for Pectra.

The main reason why SingleAttestation was introduced is to prevent a DoS attack, which means it's main value is at the level of gossip. Once we pass gossip validation checks, there is no downside to using the AttestationElectra for unaggregated attestations too. This allows us to leave most attestation-related code untouched. To have the best of both worlds, we convert the single attestation to an Electra attestation as quickly as possible and use the latter from that point on.

When converting from SingleAttestation to ElectraAttestation we need to find the index within the committee of the attester_index from the single attestation, because attester_index is the validator index within the whole state. To give an example:

Validator 9999 is an attester and the committee index to which it is assigned is 5. Within committee number 5, the attester's position/index is 7. SingleAttestation's values will be attester_index = 9999 and committee_index = 5. When converting to an ElectraAttestation, we need to set bit number 7 in attestation_bits. We need to obtain the number 7 somehow as it is not present in the SingleAttestation.

The way it's done is by using the AttestationStateFetcher to get the attestation's target state, then get the appropriate committee from that state and lastly call ToAttestationElectra on the SingleAttestation, passing the committee to the function.

Other notes for review

Obtaining the target state, getting the committee and converting takes less than 1ms. I presume it's because both the state and committee are cached.
Tested on Kurtosis with Prysm-only nodes and and Prysm+Lodestar.
The same "convert quickly to Electra attestation" design is what other clients are doing too to minimize disruption.

Acknowledgements

I have read CONTRIBUTING.md.
I have made an appropriate entry to CHANGELOG.md.
I have added a description to this PR with sufficient context for reviewers to understand this PR.

# Conflicts: # proto/prysm/v1alpha1/electra.ssz.go

terencechain · 2024-12-12T02:56:37Z

beacon-chain/sync/validate_aggregate_proof_test.go

-	att.AggregationBits = bitfield.NewBitlist(1)
-	committeeIndex, err := att.GetCommitteeIndex()
-	require.NoError(t, err)
-	_, result, err = service.validateBitLength(ctx, s, att.Data.Slot, committeeIndex, att.AggregationBits)
-	require.ErrorContains(t, "wanted participants bitfield length 4, got: 1", err)
-	assert.Equal(t, pubsub.ValidationReject, result)
-


Why is this test deleted?

Because I removed the helper function. We still test this, but it's done in https://github.com/prysmaticlabs/prysm/pull/14659/files#diff-f1d6b0b8f81c14d3cf2ef27e17d4c4e7e9b1ad1f8fc3b5a66d9bdf2eeb615853 now.

never mind, I will revert this change

terencechain · 2024-12-12T02:57:39Z

beacon-chain/sync/validate_beacon_attestation.go

+
+	preState, err := s.cfg.chain.AttestationTargetState(ctx, data.Target)
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+	committeeIndex, err := att.GetCommitteeIndex()
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+	committee, err := helpers.BeaconCommitteeFromState(ctx, preState, att.GetData().Slot, committeeIndex)
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+
+	var singleAtt *eth.SingleAttestation
+	if att.Version() >= version.Electra {
+		singleAtt, ok = att.(*eth.SingleAttestation)
+		if !ok {
+			return pubsub.ValidationIgnore, fmt.Errorf("attestation has wrong type (expected %T, got %T)", &eth.SingleAttestation{}, att)
+		}
+		att = singleAtt.ToAttestationElectra(committee)
+	}
+


Is there a DOS vector for calling AttestationTargetState and BeaconCommitteeFromState this early?

terencechain · 2024-12-12T02:58:58Z

validator/client/beacon-api/propose_attestation_test.go

-			name: "nil signature",
-			attestation: &ethpb.AttestationElectra{
-				AggregationBits: testhelpers.FillByteSlice(4, 74),
-				Data: &ethpb.AttestationData{
-					Source: &ethpb.Checkpoint{},
-					Target: &ethpb.Checkpoint{},
-				},
-				CommitteeBits: testhelpers.FillByteSlice(8, 83),
-			},
-			expectedErrorMessage: "attestation signature can't be nil",


Why nil signature test removed?

I removed it because we had two functions in the codebase checking if an attestation is nil. One is helpers.ValidateNilAttestation and the other one is validateNilAttestation on the VC side. The only difference between them was signature validation which is missing in the helpers package. I decided it's better to just have a single implementation and I expect the one in helpers to be more accurate. I am not exactly sure what happens though when the BN receives an attestation without a signature if the function in helpers doesn't fail (most likely signature validation fails in some other place).

terencechain · 2024-12-12T03:08:14Z

beacon-chain/sync/validate_beacon_attestation.go

+		if !ok {
+			return pubsub.ValidationIgnore, fmt.Errorf("attestation has wrong type (expected %T, got %T)", &eth.SingleAttestation{}, att)
+		}
+		att = singleAtt.ToAttestationElectra(committee)


This is the biggest additional performance penalty as far as I can see. For a node that subscribe to several subnets. Is this a concern? We will call this 10-30k times per slot

nisdas · 2024-12-12T04:38:58Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -71,6 +70,32 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 	if data.Slot == 0 {
 		return pubsub.ValidationIgnore, nil
 	}
+
+	preState, err := s.cfg.chain.AttestationTargetState(ctx, data.Target)


Why are we calling this here ? There must be strong justification for

fetching a state

fetching the committee from it

As these are additional bottlenecks on our highest traffic gossip path

Also why is this being called before the current gossip checks

nisdas · 2024-12-17T06:40:09Z

beacon-chain/sync/validate_aggregate_proof.go


-	committee, result, err := s.validateBitLength(ctx, bs, aggregate.GetData().Slot, committeeIndex, aggregate.GetAggregationBits())


why was this removed ? Its effectively the same as what has been added in

you're right, I will change it back

nisdas · 2024-12-17T06:41:29Z

beacon-chain/sync/validate_beacon_attestation.go

-	committee, result, err := s.validateBitLength(ctx, bs, a.GetData().Slot, committeeIndex, a.GetAggregationBits())
-	if result != pubsub.ValidationAccept {
-		return result, err
+	committee, err := helpers.BeaconCommitteeFromState(ctx, bs, a.GetData().Slot, committeeIndex)


Same here, why is validateBitLength removed

nisdas · 2024-12-17T06:44:29Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -115,6 +104,48 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 		}
 	}

+	if !s.cfg.chain.InForkchoice(bytesutil.ToBytes32(data.BeaconBlockRoot)) {


Executing all these methods before we have validated data.BeaconBlockRoot is wrong. As we might have not processed the block yet (and it has to be inserted into our pending queue)

nisdas · 2024-12-17T06:45:22Z

beacon-chain/sync/validate_beacon_attestation.go

+		return pubsub.ValidationIgnore, blockchain.ErrNotDescendantOfFinalized
+	}
+
+	if err = s.cfg.chain.VerifyLmdFfgConsistency(ctx, att); err != nil {


Same here and for the rest of the methods that follow it. If it is difficult enough, you should just stream the attestations after

potuz · 2024-12-23T10:12:39Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -141,23 +162,25 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 		tracing.AnnotateError(span, blockchain.ErrNotDescendantOfFinalized)
 		return pubsub.ValidationIgnore, blockchain.ErrNotDescendantOfFinalized
 	}
-	if err := s.cfg.chain.VerifyLmdFfgConsistency(ctx, att); err != nil {


This check is performed now after you are grabbing a full state and computing a beacon committee shuffling, this opens up the door for a malicious peer to kill the node with a crafted attestation.

terencechain · 2024-12-24T19:49:29Z

beacon-chain/rpc/prysm/v1alpha1/validator/attester.go

 	ctx, span := trace.StartSpan(ctx, "AttesterServer.ProposeAttestationElectra")
 	defer span.End()

-	committeeIndex, err := att.GetCommitteeIndex()
+	targetState, err := vs.AttestationStateFetcher.AttestationTargetState(ctx, att.Data.Target)


Any concerns with this line: for every attestation we propose, we need to retrieve the target state. What are the implications of this?

# Conflicts: # CHANGELOG.md # beacon-chain/rpc/eth/beacon/handlers_pool.go # beacon-chain/rpc/prysm/v1alpha1/validator/attester.go # beacon-chain/rpc/prysm/v1alpha1/validator/server.go # beacon-chain/rpc/service.go # proto/prysm/v1alpha1/attestation.go

rkapka · 2024-12-26T10:10:23Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

 				log.WithError(err).Error("could not save attestation")
 			}
-		} else if att.IsAggregated() {


single attestation can't be aggregated

rkapka added 11 commits November 22, 2024 17:43

definitions and gossip

f9232df

Merge branch '__develop' into single-att

76de5f4

validator

e741580

broadcast

df5338a

broadcast the correct att depending on version

c8ecac2

Merge branch '__develop' into single-att

a32321f

small updates

4215a95

don't check bits after Electra

fd296d9

nitpick

67e92e0

Merge branch '__develop' into single-att

12795fb

# Conflicts: # proto/prysm/v1alpha1/electra.ssz.go

tests

9d70083

rkapka marked this pull request as ready for review December 10, 2024 22:00

rkapka requested a review from a team as a code owner December 10, 2024 22:00

rkapka requested review from prestonvanloon, saolyn and potuz December 10, 2024 22:00

rkapka changed the title ~~Single att~~ Separate type for unaggregated network attestations Dec 10, 2024

rkapka and others added 2 commits December 11, 2024 12:23

changelog <3

b04ccbe

Merge branch 'develop' into single-att

cb58bd1

terencechain reviewed Dec 12, 2024

View reviewed changes

nisdas reviewed Dec 12, 2024

View reviewed changes

review

d3387b3

nisdas reviewed Dec 17, 2024

View reviewed changes

more review

a9f3844

terencechain previously approved these changes Dec 22, 2024

View reviewed changes

potuz requested changes Dec 23, 2024

View reviewed changes

review yet again

abf7e6d

rkapka dismissed terencechain’s stale review via abf7e6d December 23, 2024 10:41

try a different design

023c99d

rkapka force-pushed the single-att branch from e8f0569 to 023c99d Compare December 23, 2024 17:12

terencechain reviewed Dec 24, 2024

View reviewed changes

rkapka commented Dec 26, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Separate type for unaggregated network attestations #14659

Separate type for unaggregated network attestations #14659

rkapka commented Nov 22, 2024 •

edited

Loading

terencechain Dec 12, 2024

rkapka Dec 13, 2024

rkapka Dec 18, 2024

terencechain Dec 12, 2024

terencechain Dec 12, 2024

rkapka Dec 18, 2024 •

edited

Loading

terencechain Dec 12, 2024

nisdas Dec 12, 2024

nisdas Dec 12, 2024

nisdas Dec 17, 2024

rkapka Dec 18, 2024

nisdas Dec 17, 2024

nisdas Dec 17, 2024

nisdas Dec 17, 2024

potuz Dec 23, 2024

terencechain Dec 24, 2024

rkapka Dec 26, 2024


		committee, result, err := s.validateBitLength(ctx, bs, aggregate.GetData().Slot, committeeIndex, aggregate.GetAggregationBits())

Separate type for unaggregated network attestations #14659

Are you sure you want to change the base?

Separate type for unaggregated network attestations #14659

Conversation

rkapka commented Nov 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkapka Dec 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkapka commented Nov 22, 2024 •

edited

Loading

rkapka Dec 18, 2024 •

edited

Loading