Min-Fee-Stake (MFS) variant on Livepeer 2.0 protocol concepts

[dob]

During the discussions on Livepeer 2.0 there have been many great ideas floated to address challenges that the protocol will face. Some are slight variations on the 2.0 concepts, and some are a larger departure to attempt solving the same issues with different approaches. Let’s take a serious look at a cohesive proposal inspired largely by @j0sh arguments around incentivizing work, the active role of delegation, and minimizing validator stagnation.

The MFS Proposal

Let’s highlight this proposal, with special attention to what changes and what stays the same from the initial 2.0 candidates:

1. Uncapped node operator set size (same), but with no minimum or fixed bond. Node operators can still post as much stake as they’d like, and attract delegated stake.

2. Still use the BME, though parameterize how many fees go to BME vs how many go direct to node operators. This incentivizes node operators to always continue to compete for more work, since they can always earn more fees.

3. When it comes to claiming rewards from LPT emissions a node is only eligible for rewards % = min(fee %, stake %). This means that a node A that earns 10% of the fees, but only has 2% of the stake, can only claim 2% of rewards. Similarly, a node B with 10% stake but only 2% fee earning, can only claim 2% of rewards. Node C, who has 3% stake and 3% fees could claim all 3% rewards. This would incentivize A to get more stake by buying it, or attracting delegators. Delegators would move away from B since they are under-earning on rewards relative to what they would earn by moving to A. The equilibrium is that stake will chase fees in exact proportion, creating an active and engaged delegator role. Passive delegators may miss out on significant returns relative to active ones.

4. Self dealing fees is unfortunately incentivized amongst high-stake nodes, but not new nodes with low stake. You still need validation to prevent this - the more stake they have at risk, the higher the cost of self dealing because the more of their capital would get locked up when validators set their rewards to zero. It’s worth recognizing that the worst case self dealing scenario is better than the current state of the network rewards - if everyone self-dealed fees up to the % of their stake, they would just receive rewards by stake, like they do today - except it would cost them money to do so, that would be used to buy + burn LPT to reduce the supply.

5. Validation votes are handled by the top N nodes by stake, instead of introducing a separate role. This maintains a high cost of attack on the validator set. It is also a self-check on the top earning and performing nodes on the network. It’s an infrequent but important responsibility, like governance. Validation incentives do not need to be significant as these nodes are already earning the majority of the LPT rewards. Infra for providing validators with data and info can be funded via treasury as a public good. There is a downside though where these nodes could work together to entrench themselves as reward owners and prevent new entrants. Delegators can take this into account prioritizing fee chasing vs honest validation for network security.

6. Therefore delegation secures the cost of attack on the validator set takeover, and secures honest node operation, as a longer unbonding period applies to nodes and their delegators - again prioritizing diligence and honest operations.

As far as implementing this protocol and transitioning to it:

• We’d have to implement the BME, validator vote accounting as an input to rewards, and update the rewards distribution logic.

• But we could retain the same staking, reward cut, fee cut, governance, mechanics without major protocol state migration or new delegator activity required.

• Micropayments impacts would need to be considered.

Questions

1. Should there be a minimum skin-in-the-game required for node operators themselves to post a certain % or value, so that they can’t just penalize delegator capital when harming the network? I think agents as users can use the self-stake as a signal, and not prioritize low-stake nodes if they don’t feel there’s enough security and too much risk.

2. Are rewards paid out liquid or in bonded state? Bonded would maintain continuity with the current protocol. Though switching to liquid (after a validation-delay period to retroactively block cheaters) would be reasonable considering the 90 day lockup. Unfortunately, unless you have a high node operator self-bond requirement, the long lockup would need to apply to both self-stake and delegated-stake. Perhaps 90 days is extreme, and there’s some lesser value as a compromise.

3. There is still a griefing attack possible - under a low fee environment, you could self-deal massive fees in order to prevent rewards from flowing to other nodes. Your rewards may get zero’d out, but very little LPT would be distributed to other nodes and their delegators, ruining their incentives. Is it worth a few thousand dollars a day to do this? Maybe if an attacker shorted LPT it would be, as people would flee the network if their rewards were griefed consistently. Defenses against this include capping the fee % contribution to the broader pool by the stake % of the node, or looking at rolling historical fees rather than single round fees, and expecting validator action.

There is lots more research and analysis to do on the nuances of this proposal, and rippling effects to the BME. But I wanted to get this out here as a starting reference point for public feedback. Thanks Josh for many of the ideas and discussions to help inform this.

[j0sh]

This is great, thanks @dob for taking the time to refine some of my very scattered thoughts into this one cohesive outline.

As mentioned, there is a lot of nuance and many, many details implicit in each of these points, so all feedback is welcome, both on the broad ideas and any specific concerns within those.

[j0sh]

I thought it might be useful to explain the motivations leading to some of the MFS design choices. Largely, the goal is to make more incremental (although still significant) tweaks to fill gaps in today’s protocol, while preserving the goals of Livepeer 2.0, such as connecting fees to network value, and ensuring the network’s security.

Some goals and gaps in today’s protocol:

Goal 1: Make it easier to become an orchestrator (node)

There are two reasons we might want to make it easier to become an orchestrator:

1. Orchestrators have been a bright spot in the ecosystem: in addition to provding supply, orchestrators build apps on top of the Livepeer network, organize and maintain public goods projects, provide invaluable governance input, and play an important role in the overall stewardship of the project. We should aim to encourage this as much as we can, and open up avenues for newer but smaller participants to jump in and contribute in their own way.

Requiring thousands of LPT to become an orchestrator may provide some economic security to the network, but harms the network in other ways: it favors well-capitalized incumbents, and deprives the ecosystem of fresh injections of creativity, talent and enthusiasm that may help Livepeer break out. We do want more independent operators on the network, doing more interesting things, not fewer.

2. Supply onboarding. Having a difficult or capital-intensive orchestrator onboarding process risks bottlenecking supply when the network needs it the most. Technical solutions such as orchestrator pools can mitigate this somewhat, but it is generally in the network’s best interests to not be captive to a few pool operators. Having a large and independent orchestrator base reduces the likelihood of cartel-like behaviors, particularly if validators are included in this set.

MFS affords orchestrators the space to show they can offer a useful service - perhaps something novel to the network that we haven’t anticipated - before requiring them to assemble a large amount of stake, while limiting the blast radius of adversarial behaviors such as self-dealing.

Goal 2: Increase delegator activity

An active delegator base is preferable to an inert one. Staking to specialized validators alone is likely to entrench this inertia. Delegators were conceived as a core accountability mechanism with the idea that “fees follow stake”, in that withholding stake would be one way to reward good behavior and discourage wrongdoing. Thus far, however, the protocol has not been structured in a way to encourage that behavior.

MFS tweaks this idea with “stake follows fees” and gives delegators an impetus to stay active on the network, rather than to stake-and-forget. Active delegators are more likely to notice when something is amiss. Delegation by itself does not guarantee honest behavior, but active delegators provide attention as one line of defense with the threat of stake (and thus rewards) being moved elsewhere. Delegation under MFS should also be a better indicator of economic value, since stake should flow towards orchestrators generating productive fees, rather than remaining parked with non-performing nodes.

Just as we want to encourage orchestrator participation, giving delegators more reasons to engage with the network also opens up avenues for new participants to join in and contribute to the network in their own way.

Goal 3: Design for positive behaviors and growth

The large fixed bond, 90-day lockup, and validation are all meant to discourage misbehavior, but don’t necessarily work to promote network growth. There are many, many ways we can steer the protocol towards growth and positive behaviors, while simultaneously guarding against misbehavior:

• Remove the orchestrator cap to encourage new entrants, but require a small and adjustable amount of self-bond for economic security.
• Incentivize holding a self-bond via priority reward distribution, while extending the self-bond lock to 90 days for commitment.
• Incentivize a larger self-bond to earn more, which also discourages Sybil behaviors.
• Use a historical fee baseline for rewards so orchestrators are working to meet the baseline, not trying to dilute each other’s fee share.
• Encourage delegator activity to invigorate the network while improving oversight.
• Encourage a large, independent and varied orchestrator base to boost the network’s resiliency, while reducing the tendency towards cartel-like behavior from a smaller and more dominant set.

Validation may still be necessary as a backstop, but that will always be subjective: not everyone will use the same information, interpretation or criteria to validate. Constitutional norms can be eroded away rather quickly. Repeated use of validation can be corrosive to network trust and devolve into a harmful political instrument. By designing the protocol carefully, we can reduce the need for validation to only the most extreme cases.

Open Questions

Here is my take on the open questions:

Should there be a minimum skin-in-the-game required for node operators themselves to post a certain % or value, so that they can’t just penalize delegator capital when harming the network?

Self-bond may need special treatment in MFS anyway, so a minimum self-bond is not a great leap from there.

The reason for this special treatment is a “delegator saturation” griefing attack: Alice can over-stake Bob’s tiny node and dilute Bob’s rewards down to nothing. This can be fixed by prioritizing self-stake when distributing rewards, with the remainder going to delegators pro rata [1].

Prioriziting self-stake means most operators would want to self-stake as much as they can, so having some reasonable minimum should not be too onerous.

Ideally this could be a sliding percentage of their overall stake. For example, 1,000 LPT or less could require at least a 50% self-bond, declining on a power-law curve to a 1% requirement at 1,000,000 LPT, with a 1% floor thereafter. This would put a 2M LPT orchestrator at a 20K LPT minimum self-bond, which is in the ballpark of the fixed-bond proposal. That provides similar level of economic security to the network, while making it much easier for smaller nodes to get started with a tiny amount of stake.

This progressive self-stake scheme is nice for a few reasons:

• The self-bond itself can be subject to a longer lock-up period, and leave delegators with a standard 7-day unbonding.
• Still easy to participate without a large up-front investment, while ensuring skin-in-the-game, and scaling to larger operators.
• The progressive scale encourages operators to consolidate their stake, rather than split them up between different on-chain identities; it discourages Sybil attacks and helps validation.
• Self-staked amounts beyond the minimum acts as a gauge for trustworthiness, because operators are tying up more capital for a longer time frame. However, this also works to their benefit, since it makes them less dependent on delegation to earn their full rewards.

[1] Increasing the fee / reward share is one knob to combat delegator saturation, but may be too coarse if operators want to retain some delegation. This attack would hurt other delegators, but not the orchestrator itself as long as they are self-staked.

Are rewards paid out liquid or in bonded state?

Leaning towards bonded for compounding. Reasons:

• Nodes (and delegators) would have to re-bond after every round with liquid rewards, which is a chore and more transactions on the network. Not doing so would limit rewards.
• With a minimum self-stake, nodes near the minimum may need to re-stake every round anyway, or they lose delegators due to being over-subscribed.
• At the extreme, delegators will race to re-stake towards favored orchestrators before they are over-subscribed. Stake may slosh around the network from one node to another, especially if orchestrators themselves need to re-up their minimum stake as the reward pool grows. Delegators will have enough economic incentives to move stake around in MFS; chasing marginal yields with liquid rewards may be unnecessary churn.

The downside of bonded rewards the 90-day lockup, although this could be avoided for delegators.

There is still a griefing attack possible - under a low fee environment, you could self-deal massive fees in order to prevent rewards from flowing to other nodes. … Defenses against this include capping the fee % contribution to the broader pool by the stake % of the node, or looking at rolling historical fees rather than single round fees, and expecting validator action.

A rolling fee baseline may be useful anyway, since it sounds like the BME emissions schedule could use one. As a general point, I’d be supportive of anything we can do to minimize the likelihood of validator action.

With this formula:

fee_cap = stake_% * fee_baseline

Then orchestrators are not necessarily competing with each other for the highest share of fees. To earn 100% of their rewards, they only have to earn fees up to the cap. Anything beyond the cap doesn’t impact the fee computation for other orchestrators, since the baseline is fixed for the round. That fixes the griefing vector, reduces some of the zero-sum economic tension between orchestrators, and creates more room for cooperative behavior. For example, this might lead to a softer stance on self-dealing, reducing the need for closer and divisive scrutiny from validators on the topic.

Calculating this baseline can get pretty tricky, but that’s a bridge we can cross when we get there.