StakingManager
initiatlizer validates return value from ValidatorManager
#716
Labels
enhancement
New feature or request
Context and scope
#707 splits the validator manager deployment into two contracts for the PoS case - a
ValidatorManager
, andStakingManager
that holds a reference to theValidatorManager
. TheValidatorManager
's address is provided toStakingManager
at initialization, but there's not a great way to verify that the provided address actually contains aValidatorManager
.Formal verification of an external contract is not practical for this use case (as discussed in the description of the linked PR). Instead, the approach that is implemented mitigates against human error when initializing the
StakingManager
by calling a knownValidatorManager
function. This can be improved upon by calling a function with an agreed upon authenticating value (such as a hard coded magic number), and validating this on the caller.Open questions
How much added dev X would this buy us? Currently, we call
ValidatorManager.getChurnPeriodSeconds
. The main pitfall here is if another contract also implements this method (with the same signature) and that contract is provided to theStakingManager
. Also validating return data would be an improvement, but the failure scenario in the current setup is already very unlikely.The text was updated successfully, but these errors were encountered: