You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 storageself, uint64configurationNumber) 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.
The text was updated successfully, but these errors were encountered:
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
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
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 specifyingcollateral
andfederatedPower
and genesis validators only haveweight
which 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
federatedPower
andcollateral
, 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.
The text was updated successfully, but these errors were encountered: