# NPoS: delegator operators and multiplicities (Author: Alfonso) In this note I describe an idea for reducing the complexity of the validation election protocol in Polkadot, while also arguably improving the UX of both nominators and validators. On both Polkadot and Kusama, operators tend to run several validator nodes. An operator is free to not link its nodes, and pretend that they have nothing to do with each other, but in general operators seem to prefer to reveal the connection, in order to build a unique strong sense of identity and reputation. For instance, currently in Polkadot, we have "Zug Capital" running 21 nodes, and "P2P" running 13 nodes. In fact, we already let operators aggregate their nodes under one identity in Polkadot.js, but we're not exploiting this aggregation in the protocol. ## Changes to the election protocol I propose that, within the context of the election protocol, we consider all nodes by the same operator as equivalent and indistinguishable. In particular, an operator would have one stash account with the operator's stake, and a series of sub accounts, the latter with no stake. The operator $o$ thus indicates the number $m_p(o)$ of *potential nodes* it can run, and in turn the election algorithm establishes its number $m_a(o)$ of *active nodes* in each era, with $m_a(o)\leq m_p(o)$. We force each operator to have all of its nodes have the same characteristics (such as commission), and we force each nominator to vote for operators (i.e., we don't allow them to vote for individual nodes), and the algorithm assigns the nominator's stake to (one or more) *operators*, not to individual nodes. Recall that in the description of the election algorithm we currently consider the bipartite approval graph $G=(N\cup V, E)$ between nominators and validators. In contrast, we would now consider the bipartite approval graph $H=(N\cup O, F)$ between nominators and operators, where we attach to each operator $o$ a *potential multiplicity* $m_p(o)$ indicating its number of potential nodes. This new graph $H$ can be thought of as obtained from the old graph $G$, after collapsing validator nodes from the same operator into single vertices. Recall also that currently every nominator $n$ has a stake $s(n)$, and for a target committee size $k$ we consider a solution of the form $(A,w)$, where $A\subseteq V$ is a subset of validators of size $k$, and $w:E\rightarrow \mathbb{R}_{\geq 0}$ is a vector of edge weights indicating how the nominators' stakes are distributed among validators. The edge weight vector is feasible if $\sum_{v:nv\in E} w(nv)\leq s(n)$ for each nominator $n$, and the main objective we care about is to maximize the least validator stake support $\min_{v\in A} supp_w(v)$, where $supp_w(v):=\sum_{n:nv\in E} w(nv)$. In contrast, we would now consider a solution of the form $(A,m_a,w)$, where $(A,m_a)$ represents a *multiset* of operators in $O$, and $m_a(o)$ is the *active multiplicity* of $o$, with $m_a(o)\leq m_p(o)$ and $\sum_{o\in A} m_a(o)=k$. The edge weight vector $w:F\rightarrow \mathbb{R}_{\geq 0}$ now indicates how the nominators' stakes are distributed among operators, and it is feasible if $\sum_{o:no\in F} w(no) \cdot m_a(o) \leq s(n)$. The main objective will be, as before, to maximize the least validator support $\min_{o\in A} supp_{w, m_a}(o)$, where $supp_w(o):=\sum_{n: no\in F} w(no)$. It is easy to adapt our algorithms (seq-Phragmen and Phragmms) so they find such a multi-set solution. ## Changes to validator payouts and slashes We would assign payouts and slashes directly to operators, not to nodes. To achieve An operator payout would be proportional to the sum of points obtained by all active nodes of the operator, and this is shared ## Advantages The most obvious advantage is operational. Both the running time and the solution size are currently linear in the number of validators, and they would become linear in the number of operators (dealing with multiplicities is cheap). Hence, we can save a constant factor, where this factor is the average number of validator nodes per operator. This factor will increase as we increase the number of active nodes, so this trick can allow us to handle 5K validators for the same price for which we currently handle 1K. Another important advantage is that the active operators' stake would be used more efficiently. Currently, an operator must decide in advance how to split its own stake among its nodes, so nodes that don't become active have wasted stake (both self stake and possibly nominated stake). Also, two active nodes belonging to the same operator may end up with considerably different backings. This is annoying for operators and nominators, and suboptimal for the security of the system. Finally, the system would become more robust in case of large validator churning. Consider a scenario where a large number of active validators get slashed and chilled, or simply become unresponsive, and hence the system needs to activate a large number of new nodes in the next era. In this case, it would be easy for the remaining operators to activate new nodes, and re-distribute the nominators' (and self) stake among all active nodes so that the new nodes also receive a considerable amount of backing. In contrast, in the current protocol non-active nodes tend to have almost no backing, even when these nodes belong to a popular operator, so the system is not be able to activate a large number of new nodes with decent amounts of backing. Other minor advantages: - By nominating operators, a nominator can select a larger number of nodes than currently. Also, nominators will see fewer options, and each option will have a larger amount of associated information (such as responsiveness, previous slashes, etc.). This amounts to a better user experience (assuming that most nominators don't mind not being able to choose among nodes of the same operator). - Nominators would also typically get paid more, and have a more diversified portfolio, which decreases their exposure to dark swan events. They'd get paid more because they're giving more freedom to the algorithm to distribute their stake (and the algorithm tends to distribute it in an optimal way in terms of nominators' rewards), and they'd have a more diversified portfolio because they are now exposed to all nodes of an operator equally, instead of just one node. If for instance one node gets slashed 10%, and another node of the same operator does not get slashed, all backing nominators would get slashed only 5%. - We'd also provide a better user experience for operators, because they would not need to decide in advance how to split their self stake among their nodes, and they wouldn't need to worry about re-balancing the nominators' support among their nodes.