-
Notifications
You must be signed in to change notification settings - Fork 871
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
Precompute authorities when importing blocks #8017
Precompute authorities when importing blocks #8017
Conversation
final var constIndex = index++; | ||
mergeCoordinator | ||
.getEthScheduler() | ||
.scheduleTxWorkerTask( |
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.
Precompute is asynchronous here, are we sure that the authorities are not accessed before it is finished or there is a fallback to calculate them if they don't exist yet ?
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 it is not better to precalculate all the senders than precompute all the autorities of all the transactions. Currently, we calculate sender of txn, then precomupte autorities of txn, then calculate sender of txn+1, then precomupte autorities of txn+1
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.
about your first question, if this async computation does not finish before the processing, then like for the sender it will be computed on first usage
About the order, I do not know which is the best solution, because in serial mode, should be better to precompute the authorities to txn before the sender of txn+1, but in parallel mode not sure what is the best solution, what do you suggest?
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 was thinking about this case, do we want to improve the time it takes to execute all the transaction by precalculating all the sender or improve a large one by precalculating all the authorizers.
I think it makes sens here to improve the worst case, so let's keep the current order.
1a9463c
to
fac1741
Compare
I think it makes also sens here compute the recovery in parallel, even for small amount of delegations. I suggest to do it when the number of delegation is bigger or equals to the number of cores
|
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
297545c
to
63dbb19
Compare
* Precompute authorities when importing blocks Signed-off-by: Fabio Di Fabio <[email protected]> * Using Supplier to make the authorizer thread safe Signed-off-by: Fabio Di Fabio <[email protected]> * Process code delegation in parallel if there are more that one Signed-off-by: Fabio Di Fabio <[email protected]> --------- Signed-off-by: Fabio Di Fabio <[email protected]> Signed-off-by: Daniel Lehrner <[email protected]>
PR description
Like we do for senders, when can precompute the authorities for EIP-7702 transactions, to improve the performance during block import
Fixed Issue(s)
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests