ACP-99: Validator Manager Solidity Standard

[avalanche-foundation-admin]

Proposes a standard Solidity contract interface for managing L1 validator sets with custom security modules (i.e. proof-of-authority, proof-of-stake, etc).

https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/99-validatorsetmanager-contract

[meaghanfitzgerald]

ACP-99 Developer Community Call 🔊

Meeting Date/Time: 11-26-2024, 14:30 UTC (10:30 EST)
Meeting Duration: 1 hour
Presenter: Gauthier Leonard
Moderator: Meag FitzGerald

Purpose of the Meeting

In this meeting, we will discuss ACP-99, which proposes a standard of Avalanche L1 validator management alternative to the existing Validator Manager contracts published in preparation for the E-Upgrade. ACP-99 defines a reference interface for a minimal Validator Manager Solidity smart contract to be deployed on any Avalanche EVM chain, as well as a modular architecture to easily build custom “security modules” extensions of this contract.

Who is invited?

Any protocol developer, ACP author, researcher, or Avalanche community member is invited to attend this meeting.

Links

Sign Up Form: Google Form
Youtube Meeting Recording: To be added after the meeting concludes.

Preparation Material

Mandatory

ACP-99 ReadMe

Highly Recommended

Knowledge of the existing Validator Manager implementation would be helpful:
Overview

Agenda

The call would cover the rationale and planned implementation of ACP-99. During the call, the following topics will be discussed:

• Motivation for the proposal
• Unmet needs of validator management schemae given the current standards
• General workflows of validator initialization, addition, and removal
• Conceptual PoA, PoS, dPoS implementation using this standard

[cam-schultz]

Generalizing ACP-99

Background & Motivation

ACP-99 proposes a standard set of interfaces that should be implemented by any contract registered as a validator manager as defined in ACP-77. The specification includes a reference architecture that consists of two deployed contracts, the ACP99PoAModule and the ACP99Manager, with ACP99Manager storing validator set changes, and ACP99PoAModule acting as the manager system's "Security Module", defining how those changes to the validator set are allowed to be made.

Ava Labs have developed a set of ACP-77 compliant validator manager contracts independent of ACP-99. Rather than deploying multiple contracts like the ACP-99 reference architecture, it is contained within a single deployed contract, with distinct polymorphic implementations providing the equivalent of ACP-99's "Security Modules" - e.g. PoA or PoS. This architecture can be made to fit the ACP-99 specification, though doing so breaks encapsulation since the external methods that are exclusively called between the contracts in a two-contract design could otherwise be marked as internal in a one-contract design.

Proposed Changes

The following changes are proposed, with the goal to make ACP-99 as functionally robust as possible, while being generic to a variety of implementations.

1. Unify the interfaces to provide a single point of entry

In the current iteration of ACP-99, the two-contract architecture requires users to interact with both the ACP99Manager as well as the ACP99SecurityModule, since security modules have different interfaces for different use cases (e.g. native token staking requires payable methods, while PoA does not). Validator managers would be more user friendly if there was a single interface that captures all of the required functionality. This could be the set of methods the end user interacts with directly, or the security module could be integrated using a minimal abstract contract that implements the interface with an onlySecurityModule modifier. It would be up to the security module implementation to expose a reasonable interface for users, but the interaction between the validator manager and the rest of the system would be encapsulated in a single interface.

I put together a rough demonstration that implements this unified interface as multiple contracts here. The unified interface looks like this:

interface IACP99ValidatorManager {
    function initializeValidatorSet(
        ConversionData calldata conversionData,
        uint32 messageIndex
    ) external;

    function initializeValidatorRegistration(
        ValidatorRegistrationInput calldata input,
        uint64 weight
    ) external returns (bytes32);

    function completeValidatorRegistration(uint32 messageIndex) external  returns (bytes32) ;

    function initializeEndValidation(bytes32 validationID) external;

    function completeEndValidation(uint32 messageIndex) external returns (bytes32);

    function initializeValidatorWeightChange(bytes32 validationID, uint64 weight) external returns (uint64) ;

    function completeValidatorWeightChange(bytes32 validationID) external;
}

Each method follows the same general pattern:

• The end user calls the ERC20 security module to initiate an action. Note that the security module itself is not included in the interface.
• The security module validates this action and performs side effects (e.g. locks stake)
• The security module calls the corresponding IACP99ValidatorManager interface method to apply the validator change
• The IACP99ValidatorManager implementation signs ICM messages to post to the P-Chain to initiate a change, or verifies ICM messages from the P-Chain to complete a change

It's also worth noting that the single-contract design, is easily modified to fit this interface.

2 Abstract away deployment details

The method setSecurityModule in IACP99Manager only makes sense in a multi-contract design. If the manager and security module are implemented by the same contract at a single address, this setter is unnecessary. The corresponding getters are not restrictive in the same way (though they might be candidates for removal in a minimal interface - see point 3 below)

3. Minimize the interface

Any methods that are not strictly required to add or remove validators, or update active validator weight should be removed from the IACP99Manager interface. We could further constrain the interface by including only errors guaranteed to be emitted by the interface methods (e.g. ACP99Manager__InvalidValidatorRegistration if the call to initiateValidatorRegistration fails)

@Nuttymoon I'd greatly appreciate your feedback on this proposal. I'm not sure what changes you've made since the community call, but please let me know if anything in this proposal would conflict.

[Nuttymoon]

Amazing work @cam-schultz! Thanks for taking the time to experiment with ACP-99.

Now that you have worked on the 2 designs, do you see significant advantages for the two-contract one (current ACP-99 specs)?

On my side, as I mentioned in the community call, the latest work that I have done around the BalancerValidatorManager complies with Ava Labs' upgradeable ValidatorManager and I don't see obvious advantages to the current ACP-99 design, except maybe avoiding the contract size limit mentioned here.

I plan on writing a follow-up ACP around the BalancerValidatorManager that can use multiple security modules simultaneously, each having a total maximum weight. Maybe letting ACP-99 be even more generic (and move security modules out of scope) is preferable?

[cam-schultz]

Now that you have worked on the 2 designs, do you see significant advantages for the two-contract one (current ACP-99 specs)?

The immediate benefit is reducing the threat of the contract size limit, as you mentioned. For our implementation specificially, converting PoSValidatorManager and its derivations into a standalone security module gave us roughly an additional 10kB to work with. I didn't go through the exercise of switching the security module using setSecurityModule, but it makes sense that is could be appropriate in some use cases to deploy a new security module and redirect the validator manager to point to it. An upgrade use case we identified early on was migrating a PoA manager to PoS, which we do by upgrading the manager contract and keeping the state. Migrating state from one standalone security module to another seems like it would be a challenge.

Maybe letting ACP-99 be even more generic (and move security modules out of scope) is preferable?

I agree. I'll plan to open a PR into ACP-99 to formalize this, since it sounds like this approach fits your use case as well. It should be straightforward to modify our ValidatorManager stack to comply with the unified interface - in fact I did something similar as an exercise here.

[0xJohnnyGault]

I am working on an NFT staking implementation (sketches here https://github.com/multisig-labs/validation-managers/blob/main/contracts/validator-manager/NFTStakingManager.sol) and I feel like having a 2 contract solution (ava-labs/icm-contracts#674) would be the best way forward, as the ValidatorManager contract with all the warp complexity could be ossified and audited once for everyone. L1s just need to build a StakeManager(?) (instead of the name SecurityModule), and users would interact with the StakeManager however they need to, and the StakeManager would be the only addr allowed to call ValidatorManager fns (using ERC2771Context and trusted forwarder to retain msg.sender).

[cam-schultz]

I feel like having a 2 contract solution (ava-labs/icm-contracts#674) would be the best way forward, as the ValidatorManager contract with all the warp complexity could be ossified and audited once for everyone.

This would still be possible with the proposed unified IACP99ValidatorManager. Separate from the ACP, we can explore adding a method to deploy ValidatorManager in a standalone manner that's still compliant with the ACP. In addition to implementing IACP99ValidatorManager, the standalone variant would need to guard method access using onlySecurityModule, as well as provide a setSecurityModule method. Further investigation is required to identify a generalizable framework, which I've captured in ava-labs/icm-contracts#682.

[0xJohnnyGault]

I feel like using OZ Roles to implement guards would be a lot more flexible. For example, in the early days of an L1, a project could have direct access to ValidatorManager, allowing them to bypass the security module entrypoint in emergencies or to respond to unforeseen events. Later on the role could be removed for full permissionless-ness.