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

Add EIP: Reduced Attestation Format #8372

Closed
wants to merge 11 commits into from
Closed
Changes from 10 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions EIPS/eip-7610.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
---
eip: 7610
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
eip: 7610
eip: 7670

Assigning next sequential EIP/ERC/RIP number.
Numbering changed to sequential from 7500.

Please also update the filename.

title: Reduced Attestation Format
description: <Description is one full (short) sentence>
author: Giulio Rebuffo (@Giulio2002)
discussions-to: https://ethereum-magicians.org/t/eip-7670-reduced-attestation-format-for-gossiping-attestations/19458
status: Draft
type: Standards Track
category: Core
created: 2024-03-31
---

## Abstract

This EIP introduces a reduced version of the `Attestation` format to reduce the size of attestations transmitted on the Consensus Layer's gossip network. This is achieved by replacing Checkpoint objects in gossiped `AttestationData` with their respective 8-byte digests.

## Motivation

Attestations currently dominate the bandwidth usage of the Consensus Layer's gossip network (approx. 90% of the traffic). By optimizing the size of `AttestationData`, the aim is to reduce network load to improve node performance, and, most importantly, allow for greater throughput of other significant consensus data, such as Blobs. As a matter of fact, the current `Attestation` structure is not optimized for network transmission, leading to unnecessarily high bandwidth consumption. As a matter of fact, the application of Snappy block compression only reduces the size of an attestation by less than 10%.
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
Attestations currently dominate the bandwidth usage of the Consensus Layer's gossip network (approx. 90% of the traffic). By optimizing the size of `AttestationData`, the aim is to reduce network load to improve node performance, and, most importantly, allow for greater throughput of other significant consensus data, such as Blobs. As a matter of fact, the current `Attestation` structure is not optimized for network transmission, leading to unnecessarily high bandwidth consumption. As a matter of fact, the application of Snappy block compression only reduces the size of an attestation by less than 10%.
Attestations currently dominate the bandwidth usage of the Consensus Layer's gossip network (approx. 90% of the traffic). By optimizing the size of `AttestationData`, the aim is to reduce network load to improve node performance, and, most importantly, allow for greater throughput of other significant consensus data, such as Blobs. As a matter of fact, the current `Attestation` structure is not optimized for network transmission, leading to high bandwidth consumption. As a matter of fact, the application of Snappy block compression only reduces the size of an attestation by less than 10%.
  • may be a diagram with subnets subscribed with traffic a node experiences will provide a very nice context

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 do not actually have that for now, will work on it this week.

Copy link
Contributor

Choose a reason for hiding this comment

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

ok let me know if you want to add that or you think this EIP is ready for draft?



## Specification

### Constants

```
CHECKPOINT_DIGEST_LENGTH = 8
```

### Containers

```python
class ReducedSignedAggregateAndProof(Container):
message: ReducedAggregateAndProof
signature: BLSSignature
```

```python
class ReducedAggregateAndProof(Container):
aggregator_index: ValidatorIndex
aggregate: ReducedAttestation
selection_proof: BLSSignature
```

```python
class ReducedAttestation(Container):
aggregation_bits: Bitlist[MAX_VALIDATORS_PER_COMMITTEE]
data: ReducedAttestationData
signature: BLSSignature
```

```python
class ReducedAttestationData(Container):
class AttestationData(Container):
slot: Slot
# LMD GHOST vote
beacon_block_root: Root
# FFG vote
source_digest: ByteVector[CHECKPOINT_DIGEST_LENGTH]
target_digest: ByteVector[CHECKPOINT_DIGEST_LENGTH]
```

### Gossipsub

Change the message format exchanged by the topics `beacon_attestation_{subnet_id}` and `beacon_aggregate_and_proof` in the following ways:

1) `beacon_attestation_` now gossips `ReducedAttestation`s
2) Make the `beacon_aggregate_and_proof` now gossips `ReducedAggregateAndProof`s

Whenever an `Attestation` or `AggregateAndProof` needs to be published to gossipsub, Consensus Clients MUST create the equivalent `Reduced` version by replacing the `source` and `target` with their correspondent digests:

```python
reduced_attestation_data.source_digest = attestation_data.source.hash_tree_root()[0:CHECKPOINT_DIGEST_LENGTH]
reduced_attestation_data.source_target = attestation_data.target.hash_tree_root()[0:CHECKPOINT_DIGEST_LENGTH]
```

Subsequently, Consensus Clients, as they sync up, MUST keep track of a cache, `Dict[ByteVector[CHECKPOINT_DIGEST_LENGTH], Checkpoint]` containing all checkpoints seen so far, in order to deduce `Attestation`s from `ReducedAttestation`s. Consensus Clients MAY also evict checkpoints older than the `FinalizedCheckpoint`. If the checkpoint digest has not been seen yet, then the `Attestation` MUST be ignored as a gossip rule.

Consensus Clients SHOULD insert checkpoints into the cache during epoch transitions, as that is where new checkpoints are generated.


## Rationale

The decision of introducing a cache stems from the fact that many consensus clients already maintain caches of checkpoints, implying that adapting to a system where checkpoints are referenced through digests would not significantly increase the protocol's complexity.

The choice to use 8 or 16 bytes for `CHECKPOINT_DIGEST_LENGTH` balances data efficiency with security. Considering Ethereum's slot timing, attackers have limited time to generate collisions. This constraint makes shorter digests practical, as the risk of collision within the short slot intervals is minimal. Hence, using the first few bytes of the hash as digests is efficient for network propagation without significantly increasing collision risk.

## Backwards Compatibility

Backward incompatible.

## Security Considerations

`CHECKPOINT_DIGEST_LENGTH` must not be too short, otherwise there are risks an attacker can feasably create a collision.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading