Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Genesis validator set is not updated completely #1150

Open
cryptoAtwill opened this issue Sep 26, 2024 · 1 comment · May be fixed by #1166
Open

Genesis validator set is not updated completely #1150

cryptoAtwill opened this issue Sep 26, 2024 · 1 comment · May be fixed by #1166

Comments

@cryptoAtwill
Copy link
Contributor

cryptoAtwill commented Sep 26, 2024

Description

When the child gateway is created, the membership is forwarded to the child, but however the validator tracker is not aware of the changes.

The validator tracker is a module in the child gateway to apply the validator changes coming from the parent. This is achieved by storing validator changes from the top down checkpoint, then confirmed in bottom up checkpoint creation, see

function confirmChange(ParentValidatorsTracker storage self, uint64 configurationNumber) internal {
.

What happens is when someone bootstraps a subnet with some federated power, the initial validator's federated power is not synced to the child gateway validator tracker. So once the next batch of validator changes arrive, the tracker's validator set does not have the initial validators' information and hence their powers are lost.

Proposed fixes

Adding permissionMode to the gateway constructor. Based on the genesis validator, we can initialized the validator tracker. Currently we cannot do that is because validator tracker requires specifying collateral and federatedPower and genesis validators only have weight which is collateral + federatedPower. Without permissionMode, one cannot tell whether the power should go to collateral or federated.

As a work around without updating the constructor, one can:

  • Initial power update set full validator sets' power. This is only feasible for federatedPower.

Considering we will have a major contract refactor such that the validators no longer need the split between federatedPower and collateral, but just power, it would be really simple to fix this.

On the other hand, perhaps it would be useful to let the child gateway be aware of where the power comes from. Maybe, say for example, an L3 is collateral based subnet, but L2 is federated, then a validator penalty propagation will stop at L2.

@gvelez17
Copy link
Contributor

I don't have a strong opinion here, I think it might be ok to prohibit some kinds of inheritance for now. The main thing is to have it simple, robust and clearly documented. If we say only federated can inherit from federated that's fine, it would simplify the test paths.

It is helpful to not have to know the full set of validators when adding one

but its ok if we do have to, as long as that requirement is clear, and maybe a warning if you are adding one only, so that you will know you are replacing full set with a single one

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

2 participants