ACP-99: Subnet Manager Solidity Standard

[Nuttymoon]

ACP rendered

[aaronbuchwald]

Fantastic work on this! I think this is obviously relevant for the entire Avalanche community and a good start. I think it will be easier to provide feedback and make revisions on these ideas as a draft ACP as opposed to on this discussion post, so I'd suggest creating a draft PR to streamline that process.

[meaghanfitzgerald]

seconded

[Nuttymoon]

As suggested by @aaronbuchwald I went ahead and created a draft PR: #99

[ceyonur]

This looks great! I've been thinking about "how much of a generalization" this should have. I think @aaronbuchwald also mentioned we can have 2 separate contracts (manager + staking). I was also thinking maybe we can even have 1 contract manager and many other staking/PoA etc contracts all active at the same time. I think this is similar to @aaronbuchwald's first opinion but slightly more generalized:

• Validator Manager Contract (manager) will be responsible to register/collect external contract (dapps) calls and send warp messages to relayers/P-chain
• Manager will be responsible to call registered contracts after validator txs are accepted (and relayed) in P-chain
  • Those external contracts are required to implement a certain interface
• Manager will require external contracts to be registered to "validModules" before they call the manager
  • This probably requires an permission mechanism like ownable etc directly in Manager.
• Manager will only allow SetSubnetValidatorWeight if the caller (external contract) is the one that registered the validator through RegisterValidator. So only contracts that registered the validator will only be modify it.

Sample pseudocode:

// will be called by dapp
RegisterValidator(params) {
  require(validModules[msg.sender] == true)
  warpMsg = encode(msgID, params, msg.sender)
  msgID = calcID(warpMsg)
  pendingCalls[msgID] = msg.sender 
  sendWarpMessage(encode(msgID, params, msg.sender))
}

// will be called by relayer
ReceiveRegisterValidatorTx(msgIndex) {
  warpMsg = verifyWarp(msgIndex)
  msgID = calcID(warpMsg)
  msg = decode(warpMsg.payload)
  targetAddress = pendingCalls[msgID]
  targetAddress.registeredValidator(msg.params)
  validators[msg.nodeID] = targetAddress
} 

// will be called by dapp
SetValidatorWeight(params){
  registeredDappAddress = validators[params.nodeID]
  require(registeredDappAddress == msg.sender)
  warpMsg = encode(msgID, params, msg.sender)
  msgID = calcID(warpMsg)
  pendingCalls[msgID] = msg.sender 
  sendWarpMessage(encode(msgID, params, msg.sender))
}

// will be called by relayer
ReceiveSetValidatorWeightTx(msgIndex) {
  warpMsg = verifyWarp(msgIndex)
  msgID = calcID(warpMsg)
  msg = decode(warpMsg.payload)
  targetAddress = pendingCalls[msgID]
  targetAddress.validatorWeightSet(msg.params)
} 

This would let multiple contracts to own different validators, making it possible to add validators with different mechanisms/tokens. It might be "too" generic though, so I wonder if this makes sense at all.

[Nuttymoon]

Having the registered contracts follow a standard interface with a "callback" logic is a good idea. It could solve the problem I mentioned here about having to store historical data #99 (comment)

About the generalization aspect, when drafting the ACP, I figured that if we wanted to have multiple mechanisms active at the same time, it could be done by an extra contract on top of the ValidatorSetManager itself. I think this would especially make sense if you wanted to add extra logic at that level, e.g. distribute weight between different mechanisms. In a scenario of transition from PoA to PoS, you could allocate 50% of the weight to each mechanism.

[Nuttymoon]

Hey everyone,

I just refreshed the ACP draft in commit 4ac8057. It is now named Subnet Manager Solidity Standard.

The refresher reflects the latest changes that happened on ACP-77 and the reference implementation that I have been working on in the Suzaku Contracts Library on the acp-99-implementation branch. The list of interfaces and contracts implemented are detailed in the README.

Looking forward to having everyone's feedback!

[erwindassen]

It would be good to have this merged so it attains a more legitimate status. With the summit coming up having it there is something we can point to in discussions. I wholeheartedly agree that such a standard should be in place to make managing L1s more streamlined.

[avalanche-foundation-admin]

For further discussion on this idea now that it is a proposed ACP, please see to the official discussion thread here.