Skip to content

Commit 26cde92

Browse files
martineckardtmartineckardt
committed
Add ACP-185 initial version
1 parent 1762904 commit 26cde92

File tree

2 files changed

+220
-0
lines changed

2 files changed

+220
-0
lines changed

‎ACPs/185-update-validator-manager/Readme.md‎

Lines changed: 219 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,219 @@
1+
| ACP | 185 |
2+
| :------------ | :-------------------------------------------------- |
3+
| **Title** | Update Validator Manager |
4+
| **Author(s)** | [Martin Eckardt](https://github.com/martineckardt) |
5+
| **Status** | Proposed |
6+
| **Track** | Standards |
7+
| **Related** | [ACP-77](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/77-reinventing-subnets/README.md) |
8+
9+
## Abstract
10+
11+
This ACP proposes an extension to ACP-77 by introducing a new transaction type `UpdateValidatorManagerTx` to facilitate validator manager migration and upgrading without requiring proxy contracts or network upgrades. This enhancement allows L1s to:
12+
13+
- Migrate validator management between different chains (e.g., from C-Chain to a native L1)
14+
- Recover from misconfigurations where validator managers were set to inaccessible chains
15+
- Avoid the need for proxy contracts and their associated security concerns
16+
- Implement smooth upgrade paths without requiring network upgrades
17+
18+
By providing a flexible mechanism for validator manager migration, this proposal significantly enhances the sovereignty and adaptability of Avalanche L1s.
19+
20+
## Motivation
21+
22+
ACP-77 introduced the concept of Avalanche Layer 1s (L1s) with the `ConvertSubnetToL1Tx` transaction that specifies a validator manager contract:
23+
24+
```golang
25+
type ConvertSubnetToL1Tx struct {
26+
// Metadata, inputs and outputs
27+
BaseTx
28+
// ID of the Subnet to convert
29+
// Restrictions:
30+
// - Must not be the Primary Network ID
31+
Subnet ids.ID `json:"subnetID"`
32+
// BlockchainID where the validator manager lives
33+
ChainID ids.ID `json:"chainID"`
34+
// Address of the validator manager
35+
Address []byte `json:"address"`
36+
// Initial continuous-fee-paying validators for the L1
37+
Validators []L1Validator `json:"validators"`
38+
// Authorizes this conversion
39+
SubnetAuth verify.Verifiable `json:"subnetAuthorization"`
40+
}
41+
```
42+
43+
Currently, standard tools like AvaCloud, Avalanche CLI, and L1 Launcher typically recommend deploying proxy contracts via genesis to ensure the validator manager can be upgraded. This proxy-based approach introduces several challenges:
44+
45+
1. **Centralization of Power**: The proxy owner has extensive control over the validator set through the ability to change the validator manager implementation - essentially equivalent to a Proof-of-Authority admin even for Proof-of-Stake chains.
46+
47+
2. **Chain Migration Barriers**: The validator manager cannot move between chains. Projects like Beam that wish to start by managing their validator set on the C-Chain before eventually moving to their own L1 face a significant roadblock.
48+
49+
3. **No Recovery Path for Misconfiguration**: There is currently no recovery path for L1s that accidentally set their validator manager chainID to a chain they cannot control. While L1s can modify contract code on their own chain via a network upgrade, there is no recovery mechanism when the manager is set to an external chain. There have been instances of production L1s that nearly set their validator manager chainID to the P-Chain chainID, which would have rendered them permanently unrecoverable.
50+
51+
These limitations constrain L1 flexibility, create security risks, and impose unnecessary technical debt on projects building on Avalanche. A more flexible approach would significantly enhance the L1 ecosystem's resilience and adaptability.
52+
53+
## Specification
54+
55+
To address these challenges, this ACP proposes a new transaction type `UpdateValidatorManagerTx` that allows an L1 to update its validator manager without requiring proxy contracts or network upgrades.
56+
57+
### New P-Chain Transaction Type
58+
59+
#### `UpdateValidatorManagerTx`
60+
61+
The `UpdateValidatorManagerTx` will allow an L1 to update its validator manager contract address and chain ID:
62+
63+
```golang
64+
type UpdateValidatorManagerTx struct {
65+
// Metadata, inputs and outputs
66+
BaseTx
67+
// ID of the L1 to update the validator manager for
68+
// Restrictions:
69+
// - Must not be the Primary Network ID
70+
// - Must be an L1 (previously converted via ConvertSubnetToL1Tx)
71+
SubnetID ids.ID `json:"subnetID"`
72+
// New BlockchainID where the validator manager will live
73+
// Restrictions:
74+
// - Cannot be the P-Chain chain ID
75+
ChainID ids.ID `json:"chainID"`
76+
// New Address of the validator manager
77+
Address []byte `json:"address"`
78+
// A UpdateValidatorManagerMessage payload that authorizes this update
79+
Message warp.Message `json:"message"`
80+
}
81+
```
82+
83+
### P-Chain Warp Message Payloads
84+
85+
To support the validator manager update mechanism, two new Warp message types are introduced:
86+
87+
#### `UpdateValidatorManagerMessage`
88+
89+
The `UpdateValidatorManagerMessage` is used to authorize the update of an L1's validator manager. It must be signed by the current validator set of the L1 itself (not where the current validator manager is deployed).
90+
91+
The `UpdateValidatorManagerMessage` is specified as an `AddressedCall` with a payload of:
92+
93+
```golang
94+
type UpdateValidatorManagerMessage struct {
95+
// Codec ID is the codec version used to serialize the payload
96+
CodecID uint16 `json:"codecID"`
97+
// TypeID is the payload type identifier (0x00000004 for this message)
98+
TypeID uint32 `json:"typeID"`
99+
// SubnetID identifies the L1 whose validator manager is being updated
100+
SubnetID ids.ID `json:"subnetID"`
101+
// NewChainID identifies the blockchain where the new validator manager will live
102+
NewChainID ids.ID `json:"newChainID"`
103+
// NewAddress is the address of the new validator manager
104+
NewAddress []byte `json:"newAddress"`
105+
// Expiry is the time at which this message becomes invalid
106+
Expiry uint64 `json:"expiry"`
107+
}
108+
```
109+
110+
- `codecID` is the codec version used to serialize the payload, and is hardcoded to `0x0000`
111+
- `typeID` is the payload type identifier and is `0x00000004` for this message
112+
- `subnetID` identifies the L1 whose validator manager is being updated
113+
- `newChainID` and `newAddress` identify the new validator manager
114+
- `expiry` is the time at which this message becomes invalid. As of a P-Chain timestamp `>= expiry`, this Avalanche Warp Message can no longer be used to update the validator manager
115+
116+
For the message to be considered valid, it must be signed by validators representing at least 67% of the L1's total stake weight.
117+
118+
#### `L1ValidatorManagerUpdatedMessage`
119+
120+
The P-Chain produces an `L1ValidatorManagerUpdatedMessage` when an L1's validator manager has been updated to confirm the change to the L1 and its validators.
121+
122+
The `L1ValidatorManagerUpdatedMessage` is specified as an `AddressedCall` with `sourceChainID` set to the P-Chain ID, the `sourceAddress` set to an empty byte array, and a payload of:
123+
124+
```golang
125+
type L1ValidatorManagerUpdatedMessage struct {
126+
// Codec ID is the codec version used to serialize the payload
127+
CodecID uint16 `json:"codecID"`
128+
// TypeID is the payload type identifier (0x00000005 for this message)
129+
TypeID uint32 `json:"typeID"`
130+
// SubnetID identifies the L1 whose validator manager was updated
131+
SubnetID ids.ID `json:"subnetID"`
132+
// OldChainID identifies the blockchain where the old validator manager lived
133+
OldChainID ids.ID `json:"oldChainID"`
134+
// OldAddress is the address of the old validator manager
135+
OldAddress []byte `json:"oldAddress"`
136+
// NewChainID identifies the blockchain where the new validator manager lives
137+
NewChainID ids.ID `json:"newChainID"`
138+
// NewAddress is the address of the new validator manager
139+
NewAddress []byte `json:"newAddress"`
140+
// ValidatorList is the serialized list of validators at the time of update
141+
ValidatorList []ValidatorData `json:"validatorList"`
142+
}
143+
```
144+
145+
- `codecID` is the codec version used to serialize the payload, and is hardcoded to `0x0000`
146+
- `typeID` is the payload type identifier and is `0x00000005` for this message
147+
- `subnetID` identifies the L1 whose validator manager was updated
148+
- `oldChainID` and `oldAddress` identify the previous validator manager
149+
- `newChainID` and `newAddress` identify the new validator manager
150+
- `validatorList` contains the list of validators at the time of the update, using the same `ValidatorData` structure from ACP-77
151+
152+
### Transaction Validation and Processing
153+
154+
When an `UpdateValidatorManagerTx` is submitted to the P-Chain, the following validation criteria apply:
155+
156+
1. The `subnetID` must refer to a valid L1 (previously converted via `ConvertSubnetToL1Tx`)
157+
2. The `Message` must be a valid `UpdateValidatorManagerMessage` with:
158+
- The correct `subnetID` that matches the transaction
159+
- A sufficient signature threshold (≥67% of the L1's validator weight)
160+
- An `expiry` timestamp that has not passed
161+
3. The `ChainID` and `Address` in the transaction must match the `NewChainID` and `NewAddress` in the message
162+
163+
If the transaction is valid, the P-Chain updates the validator manager information for the L1 and emits an `L1ValidatorManagerUpdatedMessage` to confirm the change.
164+
165+
### Implementation Considerations
166+
167+
The `UpdateValidatorManagerTx` is designed to be compatible with the existing L1 framework introduced in ACP-77. All existing validator operations (registration, weight updates, etc.) continue to work through the new validator manager after the update.
168+
169+
When migrating to a new validator manager, the L1 community must ensure:
170+
171+
1. The new validator manager is properly initialized with the current validator set state
172+
2. The update process is well-coordinated to prevent disruption to validator operations
173+
3. The old validator manager is properly decommissioned after the update
174+
175+
## Backwards Compatibility
176+
177+
This ACP introduces a new transaction type and warp message types that extend the functionality provided by ACP-77. It does not modify any existing behaviors and is fully backward compatible with the current L1 implementation.
178+
179+
Existing L1s that use proxy contracts can continue to do so, but new L1s can choose to use direct validator manager contracts and rely on this mechanism for future upgrades.
180+
181+
## Reference Implementation
182+
183+
A reference implementation will be developed and submitted as a pull request to AvalancheGo behind an appropriate upgrade flag. The implementation will follow the patterns established in ACP-77 for transaction processing and warp message handling.
184+
185+
## Security Considerations
186+
187+
### Authorization Threshold
188+
189+
The 67% threshold for authorizing validator manager updates matches the consensus threshold for the L1 and ensures that a supermajority of validators must agree to any change in the validator management system. This provides strong security against malicious attempts to take control of an L1.
190+
191+
### Timing Considerations
192+
193+
The `expiry` field in the `UpdateValidatorManagerMessage` ensures that update attempts cannot be replayed indefinitely. However, care must be taken to ensure that the expiry period is long enough to accommodate the coordination required for a smooth transition but not so long as to create an extended vulnerability window.
194+
195+
### Migration Risks
196+
197+
When migrating between validator managers or between chains, there is a risk of state inconsistency if the migration process is not carefully managed. L1 communities should:
198+
199+
1. Develop and test thorough migration plans
200+
2. Consider implementing a temporary halt in validator set changes during the migration
201+
3. Verify the state of the new validator manager before and after the update
202+
203+
### Recovery from Misconfiguration
204+
205+
This proposal provides a crucial safety mechanism for L1s that have accidentally configured their validator manager to point to a chain they cannot control. Without this mechanism, such a misconfiguration would be catastrophic and potentially unrecoverable, especially if the validator manager was set to a chain like the P-Chain where arbitrary contract deployment is not possible.
206+
207+
### Centralization Risks
208+
209+
While this proposal reduces the centralization risks associated with proxy owners, it introduces a different trust assumption: the L1 validators themselves must coordinate to authorize validator manager updates. This is arguably more aligned with the decentralized governance principles of an L1 but does require careful consideration of the social coordination aspects.
210+
211+
## Acknowledgements
212+
213+
This proposal builds upon the foundation laid by ACP-77 and was inspired by discussions within the Avalanche community about the challenges of validator manager upgrades and migrations.
214+
215+
Special thanks to the authors of ACP-77 for their groundbreaking work on Avalanche L1s, and to the projects that have shared their experiences and challenges with the current validator manager framework.
216+
217+
## Copyright
218+
219+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

‎README.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -126,6 +126,7 @@ _You can view the status of each ACP on the [ACP Tracker](https://github.com/org
126126
|[131](./ACPs/131-cancun-eips/README.md)|Activate Cancun EIPs on C-Chain and Subnet-EVM chains|Darioush Jalali (https://github.com/darioush), Ceyhun Onur (https://github.com/ceyonur)|Standards|
127127
|[151](./ACPs/151-use-current-block-pchain-height-as-context/README.md)|Use current block P-Chain height as context for state verification|Ian Suvak (https://github.com/iansuvak)|Standards|
128128
|[176](./ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates/README.md)|Dynamic EVM Gas Limits and Price Discovery Updates|Stephen Buttolph (https://github.com/StephenButtolph), Michael Kaplan (https://github.com/michaelkaplan13)|Standards|
129+
|[185](./ACPs/185-update-validator-manager/README.md)| Update Validator Manager | Martin Eckardt (https://github.com/martineckardt) |Standards|
129130

130131
## Contributing
131132

0 commit comments

Comments
 (0)