-
Notifications
You must be signed in to change notification settings - Fork 958
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
Separate type for unaggregated network attestations #3900
base: dev
Are you sure you want to change the base?
Conversation
As a complement to ethereum#3787, this PR introduces a `SingleAttestation` type used for network propagation only. In Electra, the on-chain attestation format introduced in [EIP-7549](ethereum#3559) presents several difficulties - not only are the new fields to be interpreted differently during network processing and onchain which adds complexity in clients, they also introduce inefficiency both in hash computation and bandwidth. The new type puts the validator and committee indices directly in the attestation type, this simplifying processing and increasing security. * placing the validator index directly in the attestation allows verifying the signature without computing a shuffling - this closes a loophole where clients either must drop attestations or risk being overwhelmed by shuffling computations during attestation verification * the simpler "structure" of the attestation saves several hash calls during processing (a single-item List has significant hashing overhead compared to a field) * we save a few bytes here and there - we can also put stricter bounds on message size on the attestation topic because `SingleAttestation` is now fixed-size * the ambiguity of interpreting the `attestation_bits` list indices which became contextual under EIP-7549 is removed Because this change only affects the network encoding (and not block contents), the implementation impact on clients should be minimal.
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.
will wait for other client teams to chime in around implementation benefits but PR description makes sense and changes look reasonable
Attestation signature verification in the existing protocol implicitly runs committee association check. Without this check and with EIP-7549 a The committee association check requires shuffling computations. Given the EIP-7549 can we avoid this check anyhow? @arnetheduck |
The committee_index still needs to be checked but crucially, with this change we can do so after signature verification meaning that only validators can create new shufflings. This is why the PR doesn't remove the committe index check from the list of required checks. Since the shuffling order is needed to tell whether the validator should vote in the particular slot, I don't see that it can be avoided without more extensive surgery to the protocol. Edit: made this explicit in 5761fb4 - I thought there was a check like this but there actually isn't :) |
Considering two scenarios:
The proposed change prevents (1) but doesn’t help with (2). Is this correct? |
the shuffling is computed from the signed fields (target / block_root depending on design), so this is harmless to the extent that this shuffling will be signed by a validator (and therefore likely cached) |
I think the combination of these two conditions from the phase0 p2p spec are sufficient to handle DoS concerns around
If we are going to have |
broadly, the phase0 conditions still apply since they reference |
If this change is introduced I believe we should also make a change to the |
I wanted to surface a small concern I had regarding treating this PR as a minimal change. Introducing the
I'm not against this change, but I just wanted to push back on the idea of it being "minimal". I think we all sort of learned our lesson from EIP-7549 that changes to attestations might look simple at the surface, but end up being more complex in practice. |
Echoing @eserilev concerns, we may force on ourselves another decent churn of type changes across the codebase. While I see the benefits of this change I believe the upside of EIP-7549 is much more significant and impactful towards Ethereum participants than this change. The unified type of Attestation is annoying yes, but our codebases are already implemented to handle it. |
minimal here means that it does not affect the consensus spec significantly since the parts outside of the state transition are much less strictly specified leaving clients more leeway to implement this as they wish - in fact, one possible implementation is to simply translate to Also notable is that the comparison is done not to the work-in-progress spec but rather the deneb spec: seen through this lens, this PR (together with 3787) makes the total change of going from deneb to electra much smaller (since the changes much less invasive), even if in-between there existed a high-churn version in the development version of electra. If anything, the churn should really be attributed EIP-7549 which changed more than it needed (had it introduced just the on-chain change, it would have had much smaller impact) and with #3787 we're just reverting some of that and simplifying further). Strictly, the REST API changes are not necessary and should be judged on their own merit (since the full Attestation object is a superset). |
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.
Wouldn't you want to update the validator spec here as well, in particular how validator constructs the attestation should use SingleAttestation
?
Example: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#construct-attestation
The core change introduce by EIP-7549 is removing the |
Agreed: 1c529a8 |
this is not 100% necessary - we can also translate back and forth - Notably, web3signer is trusted so the rationale about shufflings doesn't apply and since this is the producer, the performance argument is less important as well (since you don't have to do it thousands of times per slot). All in all, I have no strong opinion either way. |
@arnetheduck |
As a complement to
#3787, this PR introduces a
SingleAttestation
type used for network propagation only.In Electra, the on-chain attestation format introduced in EIP-7549 presents several difficulties - not only are the new fields to be interpreted differently during network processing and onchain which adds complexity in clients, they also introduce inefficiency both in hash computation and bandwidth.
The new type puts the validator and committee indices directly in the attestation type, this simplifying processing and increasing security.
SingleAttestation
is now fixed-sizeattestation_bits
list indices which became contextual under EIP-7549 is removedBecause this change only affects the network encoding (and not block contents), the implementation impact on clients should be minimal.