Validators 2.0 - Topic Specific Thread

Research & Protocol Improvements
1

Validators 2.0 - Topic Specific Thread

This is a thematic topic thread related to the proposed Livepeer 2.0 Protocol Updates. There will be many such threads in the coming days and weeks to dive into each topic in detail.

This thread covers the new role of Validator in Livepeer 2.0 - the other half of today’s Orchestrator responsibilities. Where the Node Operator is the role that competes to perform work, the Validator is the role that determines whether that work was done honestly and whether that node is rewards eligible. Validators also continue to play a key role in the governance of the network by voting with delegated stake.

The Validator

Validators are the network role that delegators stake toward. The top candidates by delegated stake are elected into the active validator set. Rather than performing inference, transcoding, or any other work themselves, validators job is to score node operators on the quality and honesty of the work they’re doing, and that scoring determines whether a node is eligible for inflationary LPT rewards or not. While this may sound nuanced and difficult, a simplified view is that validators purely determine whether a node is acting maliciously to harm the network, and therefore is not deserving of rewards, or if they’re well intentioned and acting honestly to help the network (eligible for rewards).

Validators are also the body that carries forward protocol governance and treasury allocation by default unless overridden by their delegators, similarly to how Orchestrators cast votes today.

  • Validators are elected by delegated stake, using the same bonding, unbonding, and reward-cut mechanics delegators already know.
  • Each validator can assign a score between 0 and 1.0 to each node based on how they are performing honest, well intentioned work to help the network.
  • The median score across all validators for a node, will determine the % of rewards that node is eligible for. A median score of 1.0 means a node is doing honest work and earns 100% of their eligible rewards in proportion to the fees they generated. A score of 0.0 means they receive 0% of rewards. A score in between, say 0.5, means they receive 50% of the rewards they were eligible for.
  • They participate in protocol governance and treasury decisions, weighted by the stake they’ve attracted.
  • They earn inflationary LPT rewards for playing this role, and share a portion with their delegators through the same reward-cut mechanic used today.

Changes

Attribute Current Livepeer (Orchestrator) Livepeer 2.0 Proposal (Validator)
Scope of role Performs work AND governs/secures the network Determines rewards eligibility of the nodes on the network and participates in governance. Work is performed by the separate Node Operator role.
Election Top 100 by delegated stake Top N by delegated stake - size still to be determined
Compensation Reward cut of inflationary LPT, proportional to stake Same reward-cut mechanic, but drawing from a smaller share of total issuance (the majority now flows to node operators based on fees - see the Node Operator thread)
Core function Perform the work itself Score node operators’ honest performance; median score across all validators sets each node’s reward multiplier
Voting weight Proportional to stake Proportional to stake
Unbonding 7 rounds 7 rounds, unchanged

Since a validator’s judgment now directly determines how much of the network’s inflationary rewards a node operator receives, it’s critical that the majority of the active validator set is honest, diverse, and difficult to capture. That’s the job delegator stake is securing. The more stake on the validator set, the more expensive it is to gain ownership of the majority of the set to attack the network.

Open Questions

How many validator slots should exist?

Today’s protocol elects a top-100 active set by stake. Retaining this would be the easiest possible migration, letting Orchestrators inherit the validator set to start. This would not require any delegators to take any action to continue earning their rewards.

However we may not have 100 active operators that want to actively play the validator role - paying attention to and scoring node operator behavior. This may not be necessary either. A smaller set may be easier to coordinate and hold accountable, but concentrates more governance and reward-scoring power into fewer hands. The network benefits from independent validators each taking their own, proactive, dedicated approach to scoring - from monitoring fee generating work patterns on the network for anomalies, to running testing frameworks, to deploying agents to do periodic checks on their behalf.

A smaller set size likely means a lower cost for the network as well in terms of inflation. If we estimate that it costs $X/year to incentivize and fund a validator to build out the proper infrastructure to do a good job, then the more validators in the set, the higher inflation portion you need to allocate towards this set in order to secure the network. In the example parameters shared in other threads so far, if 25% of inflation went to the validator set, then the compensation at current inflation and LPT value would be about $4M/year for validators and delegators, or $40K/node in a 100 node set - about 5% dilluition to holders for LPT.

There’s a pretty robust argument for not needing to provide that much in incentives for this role (that’s a lot of overhead cost to enable a decentralized network with fees that don’t approach that level!), and therefore lean towards a smaller set size. Ideally the inflation rate continues to drop under the BME model, though the compensation difference for validators is made up in LPT appreciation as fees rise. The % that gets routed towards the validator set is a parameter that can be changed via governance based on network needs.

What size, or what mechanism for determining size, makes sense here?

How do we prevent validator scoring from becoming a subjective popularity contest?

Each validator scores node operators independently. There’s no universal leaderboard, and no reason to expect every validator to agree on methodology. That’s by design as we want validators competing on the quality of their judgment, not copying each other. But it does raise a real risk around if the scoring criteria are entirely opaque, delegators have no real basis to choose between validators beyond reputation, and validators have an incentive to just converge on whatever the median validator is doing rather than developing genuinely better scoring.

I think the right mitigation is something like a validator constitution - a ratified, public document that lays out agreed expectations and scoring principles. In addition, it should include some quantifiable, comparable signals (how often a validator updates scores, how closely they track the median, how transparent their methodology is). This gives delegators an actual basis for choosing between validators, rather than just picking whoever’s loudest. And it gives validators something to campaign against in terms of their own performance and track record against the expectations.

What happens to the existing orchestrator set at migration?

As with the Delegator and Node Operator threads, my initial lean is towards continuity: the existing orchestrator set inherits validator slots at launch, with a default score of 1.0 for every node operator, and active scoring/penalization only starting from there. The alternative - requiring an active election or re-qualification process from day one - is cleaner in principle, but relies on a delegator base that’s historically been too passive to act quickly. This risks rewards interruption for reasons that have nothing to do with actual performance. I’m open to pushback on this - especially around how we could start with a smaller set than the 100 active nodes, without penalizing existing delegators.

What penalties exist for poor validation?

Getting one of the scarce validator slots is an attractive opportunity financially. A node only need submit a few blockchain transactions, and it’s compensated handsomely by the network. So retaining that role should be incentive enough. It’s the role of the delegators to elect an honest and well intentioned majority (or ideally honest totality) to this set, and to delegate away from lazy or inactive validators that are not helping the network or taking their role seriously.

However with the delegator set being largely passive, this is a challenge in practice. The lower the bar there is to enter the set, the easier it is for a non-performing node to just buy their way in and leach rewards.

A smaller set size significantly raises the bar for someone to buy their way into the set, makes it easier for delegators to evaluate the high vs non-performers, increases the rewards to those who hold the role, and hence create a bigger disincentive for losing the role.

Thanks for everyone’s consideration on the validator topic. It’s a new concept in Livepeer, but not in dPos networks. Please share your thoughts and questions, and we’ll follow up with an open Community Call shortly to dive into these topics in detail.

2 Likes
2

Regarding the delegator to validator transition, such a sudden transition of responsibilities might have unforeseen second-order effects.

A delegator’s responsibilities are way more passive than a validator’s. The validator, even with the agentic infrastructure for validating tasks ready, they have to put up the work in setting up and maintaining that on the long term. This can create stress to existing less technical and/or time constrained delegators and be a decisive factor for them choosing to not do the transition and leave the protocol entirely.

According to loss aversion principles, we are feeling losses twice as hard In relation to comparable gains. In this case, the identity loss of the delegator to validator transition is pretty substantial. But the validator mechanic can be reframed so that it induces less or 0 perceived loss, we can preserve the delegator mechanism with reduced rewards or as is, but also retain the economic incentive for being a validator by offering a substantial reward boost for delegators who select to become a validator. In this way, the delegators have minimized or zero perceived loss; and they can reframe being a validator as an available option, which can be more lucrative than simply being a delegator, but also requires substantially bigger efforts.

1 Like
3

Having a notion of validation may be useful and necessary, since we don’t want a lack of confidence at the wrong time to stunt network growth, so I’m happy we are looking at this. I’m just not sure if validation needs to be a distinct protocol role. I’d be interested in understanding the alternatives that might have been considered and discarded, and what led to this particular design.

Can we simplify and give each orchestrator a validation “vote”, without splitting the role between nodes and validators?

To unpack the validator role in Livepeer 2.0, we’re asking validators to do two things:

  1. research to determine node quality
  2. scoring (voting) for whether these nodes should keep their rewards.

I believe these two can be kept distinct.

Quality Signals as a Public Good

Node quality research - the testing, the analysis, the the metrics, building the dashboards, inferring the signal from noise, publishing results and the communications around it - is actually very hard, a lot of real and nuanced work, and folks doing this should be well-compensated for it. These researchers are putting out extremely useful signals. Other validators should be considering those signals in their scoring!

It’s worth treating this research as a public good, and we already have well-established ways to solicit public goods, fund them, and hold them accountable. That doesn’t need a new protocol role. Since there only needs a few people doing this type of research, it would be much cheaper than funding dozens or a hundred validators to simply follow the crowd in scoring.

To reinforce the notion of these signals as a public good, they are useful for more than just validaton:

  • Delegators can look at the same signals, and shift stake if they don’t approve of the orchestrator’s validation patterns or performance. Less stake, less rewards (in a min-fee-stake model)
  • Gateways, signers and discovery services can route work away from orchestrators that look unreliable. No fees, no rewards.
  • Outside developers can look at the data to gain confidence in the network and commit to using it.

Orchestrators Simply Vote

Just as many orchestrators today don’t do much, I don’t think we can expect most validators to do much; a separate validator set will inherit many of the same problems as the current orchestrator set.

However, orchestrators already participate in governance processes as part of the role. Having them act as validators also acts as a check on their own validation behavior. For delegators, it greatly simplifies the picture, assuming any bonding changes still allow them to stake towards orchestrators.

We don’t have to expect orchestrators to develop proprietary scoring algorithms just to be one voice out of dozens. All they have to do is look at the data that’s out in public and score accordingly.

Validation as a Last Resort

I believe we can design other aspects of the protocol thoughtfully enough that validator action becomes a very last and extreme step to preserve the integrity of the protocol. The validator is a blunt and political instrument, and I hope we do not have to reach for it often.

The validation capability may be useful as a backstop, but I am not sure that justifies pivoting such a large part of the protocol around it. Sponsoring quality signals as a public good, and enhancing the existing orchestrator role, seems like the way to go here.

4 Likes
4

On the validator set sizing and the compensation math — flagging the sequencing problem from a delegator seat.

The numbers in the thread: 25% of inflation to the validator set is ~$4M/year for validators and delegators, ~5% dilution. Against the current bonded stake that’s roughly 9% yield. And the argument being made is that even this is too much, and the set should be leaner — so the direction is down from there.

Now put that next to where we are. LPT is down ~79% on the year, sitting at 52-week lows. The trade on offer is: accept less LPT, get compensated in appreciation as fees rise. That trade is reasonable in principle. The problem is the order it arrives in — the yield cut is immediate and certain, the appreciation is a promise.

For a lot of holders, the yield is the only thing that has made the last twelve months survivable. Cut it at the bottom, before any of the value capture has shown up, and the rational response for many won’t be to hold and wait for the burn to start biting. It’ll be to leave. Which drains exactly the validator stake the set needs for security, at exactly the wrong moment.

So everything rests on demand, and on demand arriving fast. If fees scale, the whole design works: the burn bites, appreciation more than covers the lost yield, nobody misses it. If fees don’t scale, delegators lose the yield and get no appreciation, node operators are earning issuance worth more than the fees they generate, and the token keeps sliding. The sanction lands at every level at once.

This isn’t an argument against the direction — I think fee-driven is the right end state. It’s an argument about pace: the emissions decline should track actual value capture rather than a calendar. Tie it to the burn/mint ratio and the transition is self-correcting. Tie it to a schedule and you’re asking a beaten-down holder base to fund the transition with the one thing that’s kept them here.

5

I like the direction this is going. Great job @dob for leading the way.

The principle idea is fundamental: “Incentivize good work/service, punish bad work.” The idea of having a diverse way to do this seems appealing (validators validate work in their own manner), but I’m not sure how that plays out in real life.

1. Economic challenge

I don’t see why a validator would put in the resources to come up with their own novel way to judge the work of the entire network. @j0sh said it best:

Very few will do quality work to come up with their own validation engine, even with economic incentive IMO. The moment there is economic incentive for open-ended work, low quality work will flood in, especially in the age of AI where devising “a design” is one prompt away, but creating a valuable one still requires discipline, deep context, and significant trial and error.

I personally would not trust that most validators would keep the best interest of the network in mind. I’d expect most to use this mostly to try to derank competing validators or to extract additional compensation through low cost effort. Doing good work would require the validator caring for the needs of the network over itself, and I don’t believe that will be the result.

2. Slow Scaling

If a new capability is added to the network, like a novel new avatar generating model, does this mean every validator has to come up with a new way to judge that work? This would mean any new capability requires 100 integrations, and how confident would the network be that everyone is ranking this new model properly if it doesn’t fit the mold of previous models?

I think having independent validators design their own way to judge new capabilities means anything new brought to the network now requires 100x more work, since there are 100 validators. I think Livepeer’s value proposition would be better placed in adapting quickly to the newest trends, and I don’t think the proposed structure achieves that.

I personally think it would be more resource efficient and faster to have a specialized team permissioned from the DAO, instead of a permissionless system that is subject to 100 different ways of doing something.

I know there is a lot to be fleshed out, but I feel the foundational principles should be defined first, along with the counter principle that is the result. If the foundation is:

Core Principle Counter Principle
Permissionless Open-ended
Diverse Unstructured
Decentralized Slow

The core principles sound great, but one has to be real about the counter principle each one introduces. Things like “open-ended,” “unstructured,” and “unpredictable” are the actual antithesis of QA principles themselves, so making them the foundation is going to be a real challenge IMO.

I personally think the alternative would be the DAO having a specialized team that takes capabilities and then defines the QA for them across the whole network. Validators would still run the workloads, most likely, but the structure and definitions would come from specialized professionals. So the result would be:

Core Principle Counter Principle
Permissioned (via DAO) Specialized
Singular Structured
Centralized Fast

I know those core principles don’t sound as sexy, but they come with counter principles that I believe would benefit the economics of Livepeer more. I do believe they can be done tactfully, so as to align with crypto values, so I would suggest pursuing what is most economically beneficial.

2 Likes
6

One thing that comes to mind with a 1:1 migration is what happens to existing delegations. I assume they would follow the same operator from orchestrator to validator.

Could the migration give delegators bonded to operators with a 100% reward cut a chance to opt out? Some may not know that the cut changed, even though delegators are ultimately responsible for monitoring this. Randomly redistributing their stake among validators is one idea, but I am not sure it is technically possible or ethically justifiable. A warning or explicit opt-in before carrying the delegation over might be cleaner.

More broadly, should the protocol define a minimum validator commission to avoid a race to zero and patterns like operators later moving to a 100% reward cut?

2 Likes