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

eth: send big transactions by announce/retrieve only #27618

Merged
merged 4 commits into from
Jun 28, 2023
Merged
Changes from all 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
11 changes: 10 additions & 1 deletion eth/handler.go
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,11 @@ const (
// txChanSize is the size of channel listening to NewTxsEvent.
// The number is referenced from the size of tx pool.
txChanSize = 4096

// txMaxBroadcastSize is the max size of a transaction that will be broadcasted.
Copy link
Member

Choose a reason for hiding this comment

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

I need a newline above this :P

// All transactions with a higher size will be announced and need to be fetched
// by the peer.
txMaxBroadcastSize = 4096
Copy link
Member

Choose a reason for hiding this comment

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

Any particular reason for setting is as 4K? Or just an arbitrary number.

Lots of deployment transaction will exceed this threshold though.

Copy link
Member

Choose a reason for hiding this comment

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

TBH, I would completely remove the notion of transaction broadcasts altogether. With all the MEV infrastructure in place currently, there's not much value in trying to be 0.5ms faster at propagating a transaction.

As for deploys, probably nobody will want to front run them anyway so those are even less time sensitive.

Copy link
Member

Choose a reason for hiding this comment

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

The only catch is that this mechanism places quite a big initial burden on the node issuing the transaction, since all it's peers will want to retrieve it from this one place initially since nobody else has it. For that, perhaps we'd need a slightly smarter announcer that does it in stages, delaying announcing to everyone.

E.g. Announce to sqrt(peers), wait 100-200ms, repeat. That way by the time we "fill" announce to all our peers, most of them will have announcements maybe from other peers too, thus not hammering only the source for the data.

Copy link
Member

Choose a reason for hiding this comment

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

Yup, look goods to me.

)

var (
Expand Down Expand Up @@ -564,8 +569,12 @@ func (h *handler) BroadcastTransactions(txs types.Transactions) {
// Broadcast transactions to a batch of peers not knowing about it
for _, tx := range txs {
peers := h.peers.peersWithoutTransaction(tx.Hash())

var numDirect int
Copy link
Member

Choose a reason for hiding this comment

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

Above this too :P

if tx.Size() <= txMaxBroadcastSize {
numDirect = int(math.Sqrt(float64(len(peers))))
}
// Send the tx unconditionally to a subset of our peers
numDirect := int(math.Sqrt(float64(len(peers))))
for _, peer := range peers[:numDirect] {
txset[peer] = append(txset[peer], tx.Hash())
}
Expand Down