Closed beer-1 closed 7 months ago
The update primarily focuses on enhancing the ImmutableTree
data structure within the mutable_tree.go
file by incorporating an initialization step for the version
field. This initialization sets the version
to an int64
value, which is obtained from opts.InitialVersion
. This modification aims to ensure that the ImmutableTree
starts with a specific version, enhancing its version management capabilities from the moment of its creation.
File(s) | Change Summary |
---|---|
mutable_tree.go |
Added initialization of version field in ImmutableTree to opts.InitialVersion . |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Thanks for reporting this issue, it seems like the InitialVersion
option is not used properly. Tree.version
should be determined in LoadVersion
so in this case, we should consider the InitialVersion
while LoadVersion
Thanks for reporting this issue, it seems like the
InitialVersion
option is not used properly.Tree.version
should be determined inLoadVersion
so in this case, we should consider theInitialVersion
whileLoadVersion
.
Not sure this is correct way to fix it. Maybe result should be same.
If you like this more, I can fix the PR .
if firstVersion == 0 {
if targetVersion <= 0 {
+ tree.version = int64(tree.ndb.opts.InitialVersion)
if !tree.skipFastStorageUpgrade {
tree.mtx.Lock()
defer tree.mtx.Unlock()
_, err := tree.enableFastStorageAndCommitIfNotEnabled()
return 0, err
}
return 0, nil
}
return 0, fmt.Errorf("no versions found while trying to load %v", targetVersion)
}
In previous iavl, the version is not affecting to working hash. but in current iavl, the version is a part of working hash, so the
InitialVersion
should be used when you make working hash to newly added moules.https://github.com/cosmos/iavl/blob/af7ae13f47a477f11c18a4856d4a0c4e4a344e45/node.go#L435
The problem is happening when you adding an new module
packetforward
, you can easily reproduce the consensus breaking with software upgrade proposal. You should run more than two nodes and after upgrade restart validator node and see other nodes.We deeply debugged it and found the working hash for the stores, which are added via upgrade, are same whatever the height you did upgrade (
[164 128 39 101 194 146 82 214 50 145 131 89 83 171 212 207 142 176 239 6 10 8 254 1 95 237 121 132 93 24 213 34]
forpacketforward
). but it should be differ in current iavl because it is using version to make working hash. and also found it is usingtree.version
, which is 0, when a new module firstly added by upgrade module. This wrong store hash is kept only in runtime. When you restart the node, it makes differentWorkingHash
and then consensus broken.