Skip to content

eth: fix transaction sender cache miss before broadcast #31657

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

Merged
merged 1 commit into from
Apr 17, 2025

Conversation

cskiraly
Copy link
Contributor

BroadcastTransactions needs the Sender address to route message flows from the same Sender address consistently to the same random subset of peers.
It however spent considerable time calculating the Sender addresses, even if the Sender address was already calculated and cached in other parts of the code.

Since we only need the mapping, we can use any signer, and the one that had already been used is a better choice because of cache reuse.

BroadcastTransactions needs the Sender address to route message
flows from the same Sender address consistently to the same
random subset of peers.
It however spent considerable time calculating Sender the
addresses, even if the Sender address was already calculated and
cached in other parts of the code.

Since we only need the mapping, we can use any signer, and the one
that had already been used is a better choice because of cache reuse.

Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
@cskiraly
Copy link
Contributor Author

I wonder if there is some case where we still need to use the old signer (LatestSignerForChainID). If so, maybe we need a switch there to select the right signer based on some condition.

Copy link
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

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

LGTM, this will return the LatestEnabledSigner instead of the LatestImplementedSigner (Cancun vs Prague if Prague is not enabled yet) which will mean we can reuse the cache which means only a single signature recovery per transaction

@fjl fjl added this to the 1.15.9 milestone Apr 17, 2025
@fjl fjl merged commit 01786f3 into ethereum:master Apr 17, 2025
4 checks passed
sivaratrisrinivas pushed a commit to sivaratrisrinivas/go-ethereum that referenced this pull request Apr 21, 2025
BroadcastTransactions needs the Sender address to route message flows
from the same Sender address consistently to the same random subset of
peers. It however spent considerable time calculating the Sender
addresses, even if the Sender address was already calculated and cached
in other parts of the code.

Since we only need the mapping, we can use any signer, and the one that
had already been used is a better choice because of cache reuse.
0g-wh pushed a commit to 0glabs/0g-geth that referenced this pull request Apr 22, 2025
BroadcastTransactions needs the Sender address to route message flows
from the same Sender address consistently to the same random subset of
peers. It however spent considerable time calculating the Sender
addresses, even if the Sender address was already calculated and cached
in other parts of the code.

Since we only need the mapping, we can use any signer, and the one that
had already been used is a better choice because of cache reuse.
0g-wh pushed a commit to 0g-wh/0g-geth that referenced this pull request May 8, 2025
BroadcastTransactions needs the Sender address to route message flows
from the same Sender address consistently to the same random subset of
peers. It however spent considerable time calculating the Sender
addresses, even if the Sender address was already calculated and cached
in other parts of the code.

Since we only need the mapping, we can use any signer, and the one that
had already been used is a better choice because of cache reuse.
Rampex1 pushed a commit to streamingfast/go-ethereum that referenced this pull request May 15, 2025
BroadcastTransactions needs the Sender address to route message flows
from the same Sender address consistently to the same random subset of
peers. It however spent considerable time calculating the Sender
addresses, even if the Sender address was already calculated and cached
in other parts of the code.

Since we only need the mapping, we can use any signer, and the one that
had already been used is a better choice because of cache reuse.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants