-
Notifications
You must be signed in to change notification settings - Fork 234
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
Overflow related to voting power. #1157
Comments
I am currently trying to see where exactly the problem could lie. I'm no Golang developer. Though trying to debug this with some understanding of programming. See the https://github.com/cometbft/cometbft/blob/main/types/validator_set.go#L427
Some observations:
does not lead to the Panic error it could create (
and
This makes me believe this part is not the culprit. Unless for some reason the cached totalVotingPower in the ValidatorSet struct is a value that became too big at a certain point and doesn't get updated to the correct value now, because it only gets updated whenever the totalVotingPower equals 0, else it keeps getting it from cache. (see Though unsure if this could be the issue.
Just tried to research this a bit and see if anything could be of use here. I'll continue checking into this, though again, I'm no Golang developer and not really sure how I could actually debug this. |
may have something to do with decimal places. |
Yes, that is one of main concerns, maybe you can point where it can be in code? cronos have same as ETH denomination, right? So code should be compatible with state in theory. |
Doing
Seems to look okay and the total is far below the voting power for the overflow error (sum: 11220947). |
Only places where I see values that have decimals or large values and are related to validators are in keys "delegator_shares" "shares" and "tokens" in our genesis.json state. example: "shares":"10950000000000000000.000000000000000000" But I expect it would gather voting power from the "power" key and not these. Thought I should give this extra information, perhaps it gives more insight to our situation. Also is there a way to debug this better? EDIT: So, in retrospect (I still may be wrong). consensus power is calculated via 'tokens'. Power is the result of this calculation. |
@yihuang Okay, so we haven't tested this out yet, but it's highly likely that this was causing the issue. We never changed the The default value for Now a question might be whether it is okay for us to change the Are there any more places we'd have to configure this to be 18-decimals? |
For those who need some more info concerning this issue (this file in the cosmos-sdk gave some more insight to this):
It's a bit unfortunate how the naming of "power" is in here, for Now checking the Method
If the validator isn't bonded, then it simply returns 0 as consensus power. But if the validator is bonded, it calculates its consensus power based on dividing the amount of tokens with the given power reduction. An example: if a validator has 10L1, our state file states that this validator has "tokens: 10000000000000000000", (18 0's extra added). So in our case, to calculate consensus power, we would have to give a power reduction of 10^18, in order to get 10 back. Which doesn't happen, if the |
Yep, that's a common overlook, you can also checkout evmos's setting for this, they have 18 decimals as well |
Hello,
We had success in migration of genesis.json with your help and used your source code for GenesisL1 upgrade, thank you!
However faced some issue:
after ~71% of updated voting power went online, block production ended with error:
INF received proposal module=consensus proposal={"Type":32,"block_id":{"hash":"FA39B16C041A8FD631784A9CC19EB5F4F0FE4FD8824226175ED201FCE76FA3B8","parts":{"hash ":"85BA0BC72B40D89610F688B70AC47D3D07B56D3A672B456CB91A453F84227452","total":1}},"height":6751391,"pol_round":-1,"round":1,"signature":"zzMzxlERtfDtUyRmu3d3LJTPP9u7Fx B72GN77vcAKVguYS0r8FvliUIcJXPN8PBUohWKAbSO0QXj2abz8KPYBQ==","timestamp":"2023-09-07T19:04:44.225325519Z"} server=node 3:04PM INF received complete proposal block hash=FA39B16C041A8FD631784A9CC19EB5F4F0FE4FD8824226175ED201FCE76FA3B8 height=6751391 module=consensus server=node 3:04PM INF finalizing commit of block hash={} height=6751391 module=consensus num_txs=0 root=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 server=n ode 3:04PM INF minted coins from module account amount=2684871870626760975el1 from=mint module=x/bank 3:04PM INF executed block height=6751391 module=state num_invalid_txs=0 num_valid_txs=0 server=node 3:04PM ERR CONSENSUS FAILURE!!! err="failed to apply block; error commit failed for application: error changing validator set: total voting power of resulting valset exceeds max 1152921504606846975" module=consensus server=node stack="goroutine 138 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x65\ngithub.com/te ndermint/tendermint/consensus.(*State).receiveRoutine.func2()\n\tgithub.com/tendermint/[email protected]/consensus/state.go:732 +0x4c\npanic({0x26c4320, 0xc001db119 0})\n\truntime/panic.go:884 +0x213\ngithub.com/tendermint/tendermint/consensus.(*State).finalizeCommit(0xc0001f9880, 0x67049f)\n\tgithub.com/tendermint/tendermint@v0. 34.29/consensus/state.go:1670 +0xfab\ngithub.com/tendermint/tendermint/consensus.(*State).tryFinalizeCommit(0xc0001f9880, 0x67049f)\n\tgithub.com/tendermint/tendermin [email protected]/consensus/state.go:1570 +0x2ff\ngithub.com/tendermint/tendermint/consensus.(*State).enterCommit.func1()\n\tgithub.com/tendermint/[email protected]/consen sus/state.go:1505 +0xaa\ngithub.com/tendermint/tendermint/consensus.(*State).enterCommit(0xc0001f9880, 0x67049f, 0x1)\n\tgithub.com/tendermint/[email protected]/con sensus/state.go:1543 +0xccf\ngithub.com/tendermint/tendermint/consensus.(*State).addVote(0xc0001f9880, 0xc001d5c140, {0xc0912c2ed0, 0x28})\n\tgithub.com/tendermint/te [email protected]/consensus/state.go:2164 +0x18dc\ngithub.com/tendermint/tendermint/consensus.(*State).tryAddVote(0xc0001f9880, 0xc001d5c140, {0xc0912c2ed0?, 0xc004ef dc08?})\n\tgithub.com/tendermint/[email protected]/consensus/state.go:1962 +0x2c\ngithub.com/tendermint/tendermint/consensus.(*State).handleMsg(0xc0001f9880, {{0x3c 77020, 0xc00291b500}, {0xc0912c2ed0, 0x28}})\n\tgithub.com/tendermint/[email protected]/consensus/state.go:861 +0x3ff\ngithub.com/tendermint/tendermint/consensus.(* State).receiveRoutine(0xc0001f9880, 0x0)\n\tgithub.com/tendermint/[email protected]/consensus/state.go:768 +0x3f0\ncreated by github.com/tendermint/tendermint/conse nsus.(*State).OnStart\n\tgithub.com/tendermint/[email protected]/consensus/state.go:379 +0x12d\n" 3:04PM INF service stop impl={"Logger":{}} module=consensus msg={} server=node wal=/root/.genesisd/data/cs.wal/wal 3:04PM INF service stop impl={"Dir":"/root/.genesisd/data/cs.wal","Head":{"ID":"aFqa318hpH7x:/root/.genesisd/data/cs.wal/wal","Path":"/root/.genesisd/data/cs.wal/wal" },"ID":"group:aFqa318hpH7x:/root/.genesisd/data/cs.wal/wal","Logger":{}} module=consensus msg={} server=node wal=/root/.genesisd/data/cs.wal/wal
It looks like there is some miscalculation of voting power somewhere, maybe related to denomination.
Can you please point where it can be?
Thank you
The text was updated successfully, but these errors were encountered: