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

Potential optimization that could reduce StateDB reads in Verifyfee Function #588

Open
hsyodyssey opened this issue Dec 4, 2023 · 3 comments

Comments

@hsyodyssey
Copy link

The Verifyfee function is one of the most import process in the daily workflow.

Among this function, CalculateL1DataFee introduces some StateDB level reads. According to the current logic, if the Tx fails to validate if the L2fee is insufficient, so the StateDB reads introduced by taking the lead in calculating the L1DataFee can be avoided in this scenario.

The reason for calculating L1DataFee first at the moment seems to be because this CalculateL1DataFee contains a unit that checks whether the RLP is legal or not. If this module is can be took out, it would be possible to validate L2fee first, then L1fee, and omit the unnecessary StateDB Read mentioned above.

I can help if this is not on the working timetable.

@HAOYUatHZ
Copy link
Member

I think you are right, we can check L2fee first.

@HAOYUatHZ
Copy link
Member

HAOYUatHZ commented Dec 13, 2023

so you mean, besides simply moving l1DataFee, err := CalculateL1DataFee(tx, state) after l2Fee check, we can do further improvements?

@hsyodyssey
Copy link
Author

so you mean, besides simply moving l1DataFee, err := CalculateL1DataFee(tx, state) after l2Fee check, we can do further improments?

not really; switching the transaction fee verification logic should be enough so far. Just found many references on CalculateL1DataFee; refactoring it could be a little non-trival.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants