-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Conversation
File
|
The commit b33dc5d (as a parent of 62a74a1) contains errors. |
EIPS/eip-7610.md
Outdated
@@ -0,0 +1,99 @@ | |||
--- | |||
eip: 7610 |
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.
eip: 7610 | |
eip: 7670 |
Assigning next sequential EIP/ERC/RIP number.
Numbering changed to sequential from 7500.
Please also update the filename.
EIPS/eip-7610.md
Outdated
|
||
## 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%. |
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.
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
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.
I do not actually have that for now, will work on it this week.
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.
ok let me know if you want to add that or you think this EIP is ready for draft?
Co-authored-by: g11tech <develop@g11tech.io>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
--- | ||
eip: 7670 | ||
title: Reduced Attestation Format | ||
description: <Description is one full (short) sentence> |
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.
description: <Description is one full (short) sentence> | |
description: Introduces a shorter format for attestations transmitted on the gossip network. |
|
||
## 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%. |
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.
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 unnecessarily high bandwidth consumption. Furthermore, the application of Snappy block compression only reduces the size of an attestation by less than 10%. |
|
||
## Backwards Compatibility | ||
|
||
Backward incompatible. |
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.
You should describe the backwards incompatibility. Like "clients using a pre-7670 network format will be unable to communicate with clients post-7670."
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS
--
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: