Delegation For MCR

[l-monninger]

Summary

The time has come to implement delegation for MCR settlement.

At a high level, this will basically look like adding an additional bit of indirection to the mapping from validators to commitments (formerly attestors) to indicate the potential for delegating. This will enable us both to calculate commitment weights and reward modality simply by referring to this indirection.

However, there are a couple potential causes for complexity:

1. Delegations can be used as way to keep active stake even under network asynchrony or node crashes, e.g., as discussed here: Integrate block reversion #271 (comment). This, in turn, means we might want to allow delegations status to be more dynamic than overall staking status, i.e., change within an epoch.
2. Related to the above, it is actually better for the health of a network if a staker can spread their delegation over nodes, as this diminishes the incentive to for an attacker to target a node which it nodes will delegate on crash in a manner that favors said attacker. In this case, delegation is not one-one-one indirection, instead it defines a one-to-many relationship. This relationship would also allow delegations whilst non-delegating--which could be attractive for network participants who want to begin their involvement with low risk.

[mzabaluev]

1. Delegations can be used as way to keep active stake even under network asynchrony or node crashes, e.g., as discussed here: Integrate block reversion #271 (comment).

I would suggest some cautious thought before attempting autonomous delegation in a node that has already encountered anomalous behavior. Is the expectation that a delegation transaction could be sent as the last resort?

[l-monninger]

Pretty much. What you could do is delegate according to the existing weights on the network as you abort.

[l-monninger]

Same effect as actively abstaining.

[l-monninger]

Ah, actually that's not quire the same because this has to be assessed as a repeated game. With this approach you could produce different weights on the next iteration of the game.

[l-monninger]

So, naively, it could be a result of modeling whether, if we want to enable a feature like this, the node should delegate its stake around to the network or send it to the 0 address and not be counted but maybe be slashed at a known rate.

The latter would essentially be an acknowledgement of, "hey, I know I'm offline and still have to be punished, but be nice to me."

[0xPrimata]

one-to-many delegation is somewhat unusual. I would treat this as a, if you are willing to delegate to many, use multiple addresses.
Running multiple nodes with a single signature is also an issue. Address of Node is so much simpler and seems like the other way would open up to so many potential damage when the workaround is so simple.
e.g.
because we are incentivizing running multiple nodes, we need to introduce multiple node signature for a single key in the multisig scheme. How is that secured? Extra logic to allowing map of delegator and node might introduce unexpected behavior, etc

[l-monninger]

That's actually not how delegation would work here in general. You don't need to build any kind of multisig. You basically just say, I delegate my stake to this validator address (as you describe).

So, currently, there is an implied mapping on a validator's stake weight that is
address => address where the second address always equals the first address.

In a one-to-one setup, you would actually set this mapping to another address.

In a one-to-many setup, you have another layer in the mapping with potentially multiple addresses.

I disagree with one-to-many delegation being unusual. You can do this on Ankr, Avalanche, EigenLayer. You just make another deposit and select a different node (provider).

[l-monninger]

Check this out: #378