-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Vesting account operations don't have represented gas prices #3817
Comments
great analysis @ValarDragon. How should we proceed to fix this ? Could you provide more context on the action items ? |
Vesting account operations should have parameterized gas charges. I don't know what is the cleanest way to do that in the code. |
Before we used to charge gas directly in the bank keeper, so it would've been easier. But we've since removed direct gas consumption calls. Thoughts @jaekwon ? |
Is this still the case? Relevant to #5492. |
Yes, this is still the case @cwgoes |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still applicable. |
Gentle ping. Still relevant? If so, anybody motivated to sketch a design for fixing it? |
Given that account abstractions are in the hot seat, this issue might become irrelevant as vesting will no longer be a concrete account type most likely. |
Vesting accounts operations don't charge more gas, however they do more computation than standard accountss. To process fees, we have to check the "spendable coins", which requires calls to getVestedCoins and getSpendableCoins https://github.com/cosmos/cosmos-sdk/blob/develop/x/auth/account.go#L398 https://github.com/cosmos/cosmos-sdk/blob/develop/x/auth/account.go#L221. Then note that if you do a bank transaction with these, this same computation gets done twice, but for free both times.
As far as transactions go, these are computationally expensive (Far more than a bank tx for instance). Lets parameterize this with the number of coin types stored in the vesting account (not appearing in the fee) While one is in the vesting time period, getVestedCoins does a high precision decimal division, and then performs a linear number of decimal multiplications on every considered coin type's amount (a big int) by this decimal scalar.
Then getSpendableCoins does n^2 searches on the coin types, and a linear number of big int additions / subtractions.
This is certainly lower total time than signature verifications with a single coin type, so it may not matter near-term, but if a vesting account with many coin types gets added, then this gets increasingly expensive. (Certain transactions also call get spendable coins multiple times, e.g. bank, which increases the importance of this problem) This is something that is not at all reflected in gas price, and it can become expensive as number of coin types increases.
As a side note, the n^2 search can be made linear with structural refactoring.
The text was updated successfully, but these errors were encountered: