-
Notifications
You must be signed in to change notification settings - Fork 20.9k
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
Conversation
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 <[email protected]>
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. |
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, 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
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 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 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 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 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.