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.
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
ipc/contracts/contracts/lib/LibStaking.sol
Line 641 in 1fb7333
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
permissionModeto the gateway constructor. Based on the genesis validator, we can initialized the validator tracker. Currently we cannot do that is because validator tracker requires specifyingcollateralandfederatedPowerand genesis validators only haveweightwhich iscollateral + federatedPower. WithoutpermissionMode, one cannot tell whether the power should go to collateral or federated.As a work around without updating the constructor, one can:
federatedPower.Considering we will have a major contract refactor such that the validators no longer need the split between
federatedPowerandcollateral, 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.