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

Payload Attestation Sync package changes #13989

Open
wants to merge 18 commits into
base: epbs
Choose a base branch
from
Open

Conversation

potuz
Copy link
Contributor

@potuz potuz commented May 12, 2024

This PR introduces the minimal changes needed to process payload attestation messages over the wire.

  • It includes the validator and the handler for the sync package
  • It includes a cache that keeps the aggregated PTC attestation as they come over the wire.
  • It does not include any wirings to libp2p (no topics are created and the handler and validator are not called yet)
  • It does not include tests in the sync package

The design of the cache is such that a single root is tracked, this is because PTC attestations over the wire are only useful for the current slot. Any attempt to add to the cache a new root removes the previous cache.

@potuz potuz requested a review from a team as a code owner May 12, 2024 11:51
@potuz potuz requested review from nalepae, rauljordan and james-prysm and removed request for a team May 12, 2024 11:51
Comment on lines 93 to 105
ptc, err := helpers.GetPayloadTimelinessCommittee(ctx, st, a.Data.Slot)
if err != nil {
return err
}
idx := slice.Index(ptc, a.ValidatorIndex)
if idx == -1 {
return errInvalidValidatorIndex
}
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to check if the validator belongs in a PTC again if this was already done in InPayloadTimelinessCommittee and in validatePayloadAttestation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

because we need the index in the PTC, not the validator index.

beacon-chain/sync/payload_attestations.go Show resolved Hide resolved
beacon-chain/cache/payload_attestation.go Show resolved Hide resolved
beacon-chain/cache/payload_attestation.go Show resolved Hide resolved
Comment on lines 102 to 105
agg.AggregationBits.SetBitAt(idx, true)
sig, err := aggregateSigFromMessage(agg, att)
if err != nil {
return err
}
agg.Signature = sig
Copy link
Member

Choose a reason for hiding this comment

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

I know you assume that the signature is already verified, but a safer ordering might be the following, so you don't set it until everything passes. I don't see any downside here.

	sig, err := aggregateSigFromMessage(agg, att)
	if err != nil {
		return err
	}
	agg.Signature = sig
        agg.AggregationBits.SetBitAt(idx, true)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand, why is this safer? aggregateSigFromMessage does not check either.

Copy link
Member

Choose a reason for hiding this comment

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

My point is if aggregateSigFromMessage returns an error then AggregationBits is already set

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah but your code then will have a bug since you need to aggregate the incoming bit too.

beacon-chain/sync/payload_attestations.go Show resolved Hide resolved
@potuz potuz force-pushed the payload_attestation_sync branch 2 times, most recently from 936684a to 215ba50 Compare May 16, 2024 06:46
@potuz potuz force-pushed the payload_attestation_sync branch 3 times, most recently from d196aed to ed8f8ca Compare May 17, 2024 09:20
@potuz potuz force-pushed the payload_attestation_sync branch from ed8f8ca to f1c3e9b Compare May 22, 2024 14:01
@potuz potuz force-pushed the epbs branch 3 times, most recently from a97480c to 966e322 Compare May 24, 2024 19:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants