Modify Orchestrator selection curve

[stronk-dev]

What does this pull request do? Explain your changes. (required)

Currently, stake-weighted selection is independent from price-weighted selection. This means that you can never have a situation where:

• All Orchestrators regardless of their stake are incentivized to compete on price
• Stake has a meaningful impact for Orchestrators at a similar price

It allows Orchestrators to 'optimise' their utilisation by running a single high-staked orch (to maximise gains from the stake-weighted curve) and run one or more side-orchs to compete on pricing without cannibalising streams from their main orchestrator.

It also reduces network security, as any node who just barely makes the top 100 can capture a large chunk of streams based on their price alone.

The current curve can be compare with two alternative solutions here
Where x1 is the bias (closer to 0 favors price, closer to 1 favors stake). s is the stakeProb and p is the priceProb

There's also this pricing dashboard, where you can switch between the current and two alternative selection curves and it then simulates the selection algorithm.

Specific updates (required)
This PR proposes three changes to the selection algorithm:

Firstly it fixes random selection (unless that was some special golang voodoo to generate a random number?)

Secondly it normalizes the values slightly different, so that the highest probability starts at 1.0 and drops of to 0.0
(priceProb was already normalised and the stakeProb can be normalised by using the highest stake found in the set)
This change can be omitted.

Most importantly the percentages for price-weighted selection and stake-weighted selection are compounded, preventing:

• An Orchestrator with high stake running way above market pricing
• An Orchestrator with low stake able to capture majority chunks of traffic (especially in less competitive regions)

How did you test each of these updates (required)
TBA

Checklist:

• Read the contribution guide
• make runs successfully
• All tests in ./test.sh pass
• README and other documentation updated
• Pending changelog updated

[stronk-dev]

I think these changes are very important if we want to allow B nodes to use price as a factor in selection. I will simulate both alternative curves to see how that works out for the current selection algo

Alternatively, price could be taken out (back to stake weighted selection only) with LP Inc setting their max price to somewhere the mainnet is competitive.

[leszko]

Thanks for sending the PR and starting the discussion. I'd be interested in thoughts from @hthillman and @ecmulli

I think that in general, it should be B who decides about their pricing strategy. Some may favor more price, some other stake/security. Saying that, currently we're in a situation in which Livepeer Inc is the main B, so we can think what's the best strategy for Livepeer Inc.

We have the following options on the table:

• Option 1: Use the new selection curve algorithm you proposed
• Option 2: Use stake and set max ppp to a more real-market price
• Option 3: Use only price for the selection (or use stake only if price is the same)

I think that Option 3 would be the closest to the real open market, but would require some changes in how B internally blacklists Os with high stream drops.

[stronk-dev]

Use only price for the selection (or use stake only if price is the same)

That's exactly the approach which this PR promotes: it allows the B to actually set a stakeWeight so that it would prefer a larger staked orch at the same price, but if an orch is way above market pricing, their chance of getting a stream very quickly runs off.
It's important that stake has a key role in selection for network security and to prevent orchs from splitting up into multiple smaller nodes. But of course we never want to choose an orch if they're above market pricing

https://pricing.stronk.rocks/ provides a nice way to quickly see how changing the weights affects selection with the current or alternative methods. Not saying that this is the best solution, but IMO it's a big step in the right direction. Curious to hear about alternative solutions which could be considered

[hthillman]

@leszko @stronk-dev @ecmulli

1. I have no strong objections to this approach but would like to hear from Evan before fully endorsing
2. I would note that in practice, most broadcasters are likely to strongly favor price - so I'm not sure how much this will change the status quo of distribution.
3. @stronk-dev have you gotten any feedback from the community on this? Strong endorsement from a critical mass of Os could help nudge this across the line

[stronk-dev]

3. @stronk-dev have you gotten any feedback from the community on this? Strong endorsement from a critical mass of Os could help nudge this across the line

Haven't brought it up yet, but will attend the next water cooler to do so.
But just to re-emphasize: the reason LPT exists is to be a driving force in job distribution. That's how it's still being sold to Orchestrators, Delegators and HODL'ers (Delegated Proof-of-Stake for consensus/security). LP Inc broke that key aspect with the new selection algo + extremely low stakeWeight.

I'm totally on board with heavy price optimisation (and with a 0% fee cut I'm not benefitting from a higher/lower PPP), but just trying to restore the 'integrity' of the protocol. For Orchestrators the path to least resistance is simply to run more nodes (IE Vires added a third node: 0xbfedd5decda4020bf5d6e897676273581207b731)

[0xVires]

Thanks for the initiative and the awesome pricing dashboard @stronk-dev !

Re third node: It's to collect data points, not planning on setting up more or promoting them - although it looks like I could easily make an extra $200-300 per month and node with the current selection algo...

So you're suggesting the "Harmonic mean" here, right? It's a bit hard to comment on this without knowing how the parameters like price weight and stake weight will be chosen since it affects the selection algo drastically.
Looking at your pricing dashboard, if we currently have a 0.9 price weight and a 0.1 stake weight (which would make sense according to the values I'm observing), switching to the proposed model would need an adjustment to 0.9 stake and 0.1 price for me to get to roughly the same value (at a far lower PPP that is). But if the values were 0.7 stake and 0.3 price, I'd lose half my value in the best case...
Since the harmonic mean gives less significance to "outlier" values, it would also mean that low stake nodes would have almost no chance on getting any streams, regardless of their pricing. Similarly, from my perspective, it's not accurate to sell this as "make stake matter again" when this method would punish me heavily unless a really high stake weight would be chosen. Otherwise I think this would mainly benefit the 150k-350k stake Orchs, or am I wrong?

From a fairness, sybil-resistance and also simplicity point of view, I'd be strongly in favor of making the selection mainly stake weight again but with a rather low max PPP so that the Livepeer B is competitive. I really believe that the only solution that makes everyone happy is more demand.

[stronk-dev]

Since the harmonic mean gives less significance to "outlier" values, it would also mean that low stake nodes would have almost no chance on getting any streams, regardless of their pricing.

Nodes who are uncompetitive on stake would indeed have trouble getting streams, as was the case before there was random selection. It's tough, but at the moment small staked nodes can even get a majority of streams in a less competitive region like Sin, so moving to a more strict curve would be a big step in the right direction. It's not a good situation if simply spinning up a new low-staked orch can get you lots more work

Similarly, from my perspective, it's not accurate to sell this as "make stake matter again" when this method would punish me heavily unless a really high stake weight would be chosen. Otherwise I think this would mainly benefit the 150k-350k stake Orchs, or am I wrong?

This method would only punish being uncompetitive on either stake or price. It makes your stake a whole lot more significant than it is currently. Your node would have a much greater chance of a stream than another node at the same price with less stake. It would indeed require setting a much higher stakeWeight than now (but with the current implementation, setting a high stakeWeight would sideline price) and you would lose a lot of total value since you'd be forced to also compete on price.
The goal of this PR is being sold as 'make stake matter again' cause that's what it does, but within the context of an open pricing market which LP Inc seems to desire. It's not the perfect solution which restores the old balance, but moves the needle away from the current broken implementation.

From a fairness, sybil-resistance and also simplicity point of view, I'd be strongly in favor of making the selection mainly stake weight again but with a rather low max PPP so that the Livepeer B is competitive. I really believe that the only solution that makes everyone happy is more demand.

From my POV rolling back to the old selection algo or setting a very high stakeWeight + a low max PPP also seems like the best option, as LP Inc does not seem interested in taking the time to develop an actual 'fair' selection algo themselves (they seem content with the current situation).
Sidelining stake is unacceptable either way, so I want to make steps in the right direction