-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
bug(store,x/distribution): Rounding error in rewards claim when using QueryContext. #15533
Comments
Mhhh I don't think this has anything to do with caching TBH. Reward calculation relies heavily on the current block height, i.e. |
Yeah @alexanderbez we are using the latest height as confirmed with some printf's, here is the codepath for creating the querycontext for use in the estimate gas rpc routine. |
Notably if requested height == ctx.BlockHeight() we just return a cache context. |
I see. Maybe caching does have something to do with it. Recall that reward actually does some state modifications via This might be one of those situations where we might need to whip out the good ole |
Summary of Bug
When testing the EstimateGas for stateful precompiles in Polaris (https://github.com/berachain/polaris) we experienced a strange phenonemum where the estimated gas when using a QueryContext vs the canonical DeliverStateContxt resulted in two different numbers for the consumed gas. For context, Polaris supports stateful precompile evm contracts, which allows for smart contracts in our EVM to call Cosmos-SDK modules directly, in this example we are using x/staking (and by proxy x/distribution).
This difference in rounding lead to situations where our Ethereum JSON-RPC's Estimate Gas was reporting a lower required gas then what is actually required to execute the transaction leading to failed transactions. Most notably this occurs when a user tries to call
delegate()
. Part of delegating to a validator in the SDK requires withdrawing outstanding rewards in order to allow the passive distribution math ot functional. Notably, on an alternating fashion, we saw that when using the QueryContext the pending rewards for a user was 0, leading to the following control flow to be skipped (cosmos-sdk/x/distribution/keeper/delegation.go
Line 170 in ba9d4df
Here is a link to the issue in our repo: berachain/polaris#480
@tac0turtle and I have chatted a bit and he thinks that it may be a caching issue with the QueryContext and/or the Root Multistore, but would love others thoughts on this for sure.
Version
From our
go.mod
Steps to Reproduce
mage start
(this will start a chain)The text was updated successfully, but these errors were encountered: