-
Notifications
You must be signed in to change notification settings - Fork 4
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
don't broadcast blob txs per eip-4844 #77
Conversation
Can we hold off on merging this? For devnet-v3, we want to broadcast blob txs as usual. So I prefer this gets merged after devnet-v3 as development is targeting that right now. |
52624ec
to
6c8b829
Compare
sure we can do that but not sure what the harm is in merging it now unless there are other ELs that we don't expect to implement this part of the spec? |
aa4e23c
to
6653a6e
Compare
Oh I see that @timbeiko had it marked as a PR to skip in his notes... I don't recall why we decided not to include it? |
iirc, the expectation was that blocking tx announces meant that client should also implement eth/68. Implementing eth/68 is non-trivial. Since it's not essential for devnet-v3, we didn't want to unnecessarily increase the scope of the devnet. But you're right, it shouldn't hurt to merge just this bit as the blob txs are still announced. |
Agree we don't want to do eth/68 for devnet. Let me convert this to draft for now while we think it through. |
@@ -524,6 +524,10 @@ func handleTransactions(backend Backend, msg Decoder, peer *Peer) error { | |||
if tx == nil { | |||
return fmt.Errorf("%w: transaction %d is nil", errDecode, i) | |||
} | |||
if tx.Tx.Type() == types.BlobTxType { | |||
// blob txs should never be broadcast | |||
return fmt.Errorf("transaction %v is a blob tx", i) |
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.
If a peer does broadcast txs (say a Nethermind client) and we're part of their inner peerset, this error will occur on both ends of the connection. I'm a bit concerned about how clients handle this failure case.
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.
Ah just seeing your comment on making this a draft. 👍
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 have commented this out and left a TODO while we're still interop testing just in case not everybody gets it implemented in time for devnet 4.
65b43c0
to
6d4d7b7
Compare
Reopening since we want this in devnet-4. |
6d4d7b7
to
b0ce32e
Compare
b0ce32e
to
55702b3
Compare
No description provided.