Accounting V2: Should multi-delegation also count for orchestrators ?

[kyriediculous]

Currently in streamflow both a delegator and orchestrator can only delegate LPT to a single address at a time.

In confluence there will be the introduction of multi-delegation. This means that LPT can be delegated towards different orchestrators from a single source account. However there are currently no restrictions posed, this means that an orchestrator can also delegate to other orchestrators. This poses the question whether orchestrators should be able to take part in multi-delegation or be restricted to self-delegation

considerations

• What if we want to restrict this but an address has self-delegations before declaring as an orchestrator we currently have no way of assessing this. Would need additional state variables to track this.

[yondonfu]

I can see why allowing an orchestrator account to partake in multi-delegation might result in complexities and edge cases if we continue to follow the convention established in the Streamflow BondingManager where an orchestrator is technically defined as a delegator delegated to itself.

Could these complexities and edge cases be avoided while still allowing an orchestrator account to partake in multi-delegation by having separate code paths for orchestrators and delegators and by making the technical definition of an orchestrator in the contract not depend on any delegator state in the contract? i.e. Even if an account has a self-delegation, it needs to stake separately in order to register as an orchestrator. I don't think allowing an orchestrator account to partake in multi-delegation is particularly important, but if we can avoid adding special casing logic to implement that restriction that could be a win.

[kyriediculous]

In both cases (separating concerns or adding restrictions) requires additional state-keeping on top of the current implementation. So from my perspective the thought exercise here is Do we think multi-delegation by Os can be harmful, if not we should just allow this behavioural change as long as the requirement of self-delegation to declare eligibility for work remains intact .

I don't think it is particularly harmful, neither do I think orchestrators have much economic incentive to do so. I mean a node operator can perfectly multi-delegate to multiple orchestrators from a separate account as well.

[yondonfu]

I don't think multi-delegation from orchestrators is harmful from a protocol behavior POV. But, I made note of potential complexities and edge cases with multi-delegation from orchestrators at the implementation level because reasoning about all the different states an account can be in when the account can participate in the protocol as both a delegator and orchestrator can be tricky. For example, in the past, the BondingManager had a bug caused by allowing an orchestrator to delegate its stake to another orchestrator. This restriction resolved the bug. The intent of my previous comment was mainly a suggestion to carefully consider state management and code paths for modifying state for both roles since multi-delegation from an orchestrator increases the # of states that the account can be in and if there is a way to maintain a cleaner separation of state (i.e. if an account is just an orchestrator there is only an orchestrator state tracked, if an account is also a delegator then there is also delegator state tracked) for the two roles in the contract that may help avoid having to implement any restrictions around problematic state updates that are identified.

[kyriediculous]

Thanks for providing the context, that made me think about this a little bit and I think other than solving a bug that particular restriction also prevents an orchestrator from moving it's self-stake to another node and thus circumventing potential slashing.

I do think when someone declares to be an orchestrator by self-staking they should not be allowed to move that delegation in that particular account state. This is currently not implemented and I'll create an issue to flag this, in the meantime I'll also consider other potential edge cases.

In essence I do think it would be a good idea to have the orchestrator and delegator be very separate users that interact with the protocol and set different rules for each of them. In the case we allow the same address to act as both roles we then need to indeed make sure the rulesets are separated and implemented correctly.