-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Update EIP-4844: Disable Blob Transaction Broadcast #5930
Conversation
A critical exception has occurred: |
814d3b5
to
71ff609
Compare
EIPS/eip-4844.md
Outdated
@@ -322,6 +322,8 @@ The actual `data_fee` as calculated via `calc_data_fee` is deducted from the sen | |||
|
|||
### Networking | |||
|
|||
Blob transactions are not automatically broadcast to peers. Instead, they are only announced using `NewPooledTransactionHashes` messages, and can then be manually requested via `GetPooledTransactions`. |
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 wonder if this shall be moved to a separate EIP addressing Network layer only
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.
As this is required behavior for all nodes implementing 4844, it seems appropriate to keep it within the EIP.
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.
While I think there is no EIP editorial policy or guideline strictly prohibiting this, as far as I know, hence I think it's ok to stay same EIP.
However, proper scoping could help improve readability and technical soundness for an EIP. For large EIPs like 4844. I humbly suggest consider discuss among your fellow coauthors to see if it make more sense to put network part of spec into the same core EIP or a separate one.
An example of split scoping: EIP-1559 depends on EIP-2718, EIP-2930 which depends on EIP-2929(Network).
|
||
- include a 1.1x (or potentially higher) data gasprice bump requirement to the mempool replacement rules | ||
- modify the Ethereum Wire Protocol to stop automatically broadcasting large transactions | ||
In addition, we recommend including a 1.1x data gasprice bump requirement to the mempool transaction replacement rules. |
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.
In addition, we recommend including a 1.1x data gasprice bump requirement to the mempool transaction replacement rules. | |
In addition, we recommend including a 1.1x data gasprice bump requirement to the mempool transaction replacement rules. |
Is the "recommendation" added here as a specification? Could you clarify if it's a comment or it's a specification?
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.
This is client-internal logic, so up to implementers to make decisions on. That's why it is not part of the EIP specification.
Co-authored-by: xinbenlv <zzn@zzn.im>
Head branch was pushed to by a user without write access
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.
LGTM
Specifies that blob transactions should not be broadcast to peers, but only announced (so that they can then be manually retrieved).
Adds a reference to #5793 which will give peers more fine-grained control by making it possible to identify blob transactions (and their size) from announcement messages.