-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Staking] Validator gating #1121
Comments
@raulk I think it works. Just a small note that do we have to differentiate |
Unfortunately these have different semantics.
In this case:
We could even make it accept a variadic argument, so we could deal with a batch power change at once, which is useful with However, I am not sure how shuffling / active validator limits factor in. What are your thoughts on that front? e.g. what happens if a validator stakes but they're not picked as an active validator. Do we still intercept? (I'd say yes) Another thing I'm not sure about is whether we want a boolean return value, or simply a revert in case of rejection. |
This interface:
works for me. I just want to avoid getting into the current As of I prefer a revert over bool as default implementation. If someone needs bool, they can always catch it and return bool. Default revert feels more fiting to the current context. |
We're aligned, but I'm sure we'll find edge cases during implementation and we may need to send more data to the gater so it can make an informed decision.
To clarify, what I meant is that this interface may get calls for validators that are ultimately not active (either because they don't meet the minimum stake threshold, or because they were shuffled away). I think that's fine; we just need to make sure that the gater can call back to the subnet actor and/or the gateway to query details (i.e. we're not prohibiting all forms of reentrancy).
Who is "they"? It's the IPC contracts that will be interacting with the gater. That said, I think a revert is fine, as a denial would anyway cause a revert during stake/unstake. |
Goals
Introduce the ability to intercept staking, unstaking, and explicit validator membership adjustments (federated membership) to allow or deny the action, according to a user-defined policy.
Proposed solution
IValidatorGater
standard interface that can be implemented by any contract.IValidatorGater
interfaceImplementations
This flexible interface can back any implementation, e.g.:
The text was updated successfully, but these errors were encountered: