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 Node Operator - a concept which is already played by today’s Orchestrators as a subset of their responsibilities. However, there are some key changes to what it means to compete to perform work on the Livepeer Network, and some updates to the economic incentives that secure and reward this work.
The Node Operator
Node operators are the network role that compete to perform work on the Livepeer network.
- Node operators post a fixed-bond on chain to register.
- They advertise the capabilities that their node offers.
- They are discoverable through this on chain registry so that the users of the network, such as Livepeer Agent, can discover their capabilities and negotiate QoS, availability, and pricing.
- They perform jobs and receive payments.
- They cash in the evidence of these payments on chain, and are compensated in LPT in proportion to how many fees they generated, from the Burn-Mint-Equilibrium (BME) mechanism. (More to come on the BME in a separate post).
The capabilities that they offer range from compute tasks such as open source model inference on their local GPUs, to realtime AI media workflows, to API passthrough to 3rd party services so that all media AI capabilities can be exposed through the network, to other forms of media compute such as transcoding, ffmpeg commands for muxing/stitching/cropping, and more. The agents using the network pass through payments to many different node operators, exposing many capabilities, in the process of creating media.
Changes
Here are some of the differences between current Livepeer protocol, and the proposal in Livepeer 2.0 as it relates to Orchestrators vs Node Operators.
| Attribute | Current Livepeer | Livepeer 2.0 Proposal |
|---|---|---|
| Work Eligibility | Top 100 nodes by delegated stake are active. | Remove the 100 node limit. Define a fixed-bond amount. Any node that posts the fixed bond is registered and discoverable on chain. |
| Rewards eligibility | LPT rewards are divvied up in proportion to delegated stake. | LPT rewards are divvied up in proportion to fees that the node generates for performing honest work. Validators score nodes to determine what % of their rewards they are entitled to to prevent harmful actors or non-contributors from earning rewards. |
| Unbonding period | 7 rounds | Longer capital lockup to prevent bad actors from swapping stake to a new node to earn rewards when deemed ineligible. Proposed 90 day unbonding period. |
| Fee compensation | Earn the ETH they are paid for performing work | No ETH fees. Price in USD, and the earnings are used to buy LPT in the BME. Node operators compensated with LPT in proportion to the fees generated. (Higher LPT value than the fee value during the bootstrapping period, and approaching equal to the fee amount at high network scale.) |
| Reward liquidity | LPT gets added to stake and is subject to unbonding period. | Rewards are immediate liquid. |
| Motivation for acquiring LPT and posting more stake on chain. | More stake == more work. This was true in early, transcoding-only, Livepeer with a single client. More stake meant more slashable capital for cheating. It has weakened significantly in recent times with a diverse set of job types and clients using the network, and no verifiability of work. | More stake == more registered nodes. These are each independently discoverable by the Livepeer Agent, and lead to higher probability of work selection. More capital at risk subject to validator scoring 0 reward multiplier. |
| LPT Compensation Range | 90% to orchestrators/delegators based upon stake, factoring in reward-cut dynamics. 10% to treasury. | Parameters will determine the split between node operators, validators, and treasury. In the other thread one example proposal was 70% to node operators based in proportion to how many fees they generate, 25% to validators/delegators, and 5% to treasury. (Just an example…to be determined by governance). The majority of inflationary LPT will flow to node operators. |
The above mention the changes that Orchestrators will face when it comes to performing in the role of node operator. The other half of orchestrators job today is closer to the new Validator concept in 2.0. (To be discussed in detail in an upcoming thread). In that capacity the Orchestrators will continue to attract stake in order to have an active role in the liveness and governance of the protocol. They’ll participate in the QoS scoring of the node operators, governance, and treasury voting based on the stake they’ve been delegated - and be compensated in LPT through the same reward cut mechanic they’ve been accustomed to.
Open Questions
There are several open questions that we need community input on in order to arrive at a final design. Please share reactions here in the forum, ask additional clarifying questions, and be prepared to discuss these topics in upcoming community calls.
What’s the initial fixed bond amount for node operation?
I have two schools of thought on this.
- It should be a governance determined flat amount.
For example, it could be 25,000 LPT. This means that if all LPT were used to buy node slots, there would be approximately 2000 available nodes in the registry. However, we’re currently near 50% participation rate, and most delegated stake is in the hands of delegators who would be staking towards validators initially, so it’s more likely there might be 100-500 nodes at this level for the foreseeable future.
It could also start significantly lower, say 5000 LPT, and then be moved up via governance over time to balance the desirability of supply side slots, with the network needs and LPT price/buy pressure. As it rises, existing nodes would be grandfathered into their slot, so they wouldn’t need to post LPT.
- It should be on a bonding curve, with the cost for slot N+1 costing incrementally more than slot N.
This would create a market determined price for node slots on the network. As work increases and the value of LPT rewards increase accordingly, there is higher demand and higher cost to run the next node. While this moves the pricing out of the hands of governance and into an automated, market-based system, it does bring the challenge of making it more expensive to add supply to the network as the network most needs that supply during times of scaling.
What do our existing O’s think an appropriate amount is to both ensure skin-in-the-game amongst node operators, while having a low enough bar for new entrants to participate? The answer to the next open question is very important in determining this.
What’s the role of delegated stake in posting fixed node operator bonds?
This is being discussed in the delegator thread. If delegators can post the bond on behalf of node operators in exchange for a reward cut, then it makes it far easier to activate new nodes on the network. And far easier for new operators to get a slot and begin helping the network and earning LPT, without a bit up front investment in LPT so they can post their own fixed-bond.
The downside of this is that it reduces LPT buy pressure - just attract existing delegated stake through a reward cut, rather than having to buy LPT to operate on the network. It also reduces the skin in the game of the node operator themselves, though the delegator is taking on that risk by facing the 90-day unbonding period.
One idea that was proposed was that the delegator could only post a minority amount of the total position - so that more nodes could be activated, but the node operator still had skin in the game. In either case, I’d suggest a simple transaction where the node operator can then “buy out” their full bond when they’re ready, emitting the delegators stake back to them after the node operator posts the full bond.
Does buying multiple node slots == more work and more LPT rewards?
Yes. It is impossible to enforce that work is divvied up exactly in proportion to stake, because that does not yield a high quality of service with so many diverse capabilities and job types and unverifiable work. However each registered on chain node identify is equally discoverable by the agent, and likely to be trialed in search of capabilities, reliability, redundancy, locality with low latency, and more of the desirable properties that the agent seeks out from service providers. More nodes means more security through more stake that can be held in the 90-day unbonding window, subject to validators reward ratio judgements. Randomization and probabilities will favor getting more work with more nodes.
Should the node operator unbonding period by 90 rounds, or some other value?
First, note that the validator and delegator unbonding period is being proposed to be left at the same 7-rounds that everyone is used to. The capital lockup needn’t be as long there to check bad behavior. For node operators however, who can harm the network by attempting rewards extraction by self dealing fees, or worse - return incorrect results for the capabilities they are advertising, there needs to be a real economic penalty. The long capital lockup is that penalty. If the majority of validators set a node’s reward ratio to zero, then for 90 days their capital is stuck and they aren’t earning any rewards. It’s also unlikely agents will select them for work in this state. They aren’t able to quickly take that capital and spin up a new node with a new identity to resume their rewards earning.
There’s a case the lockup should be even longer. I suggest 90 days, but am curious on other’s opinions.
What are the incentives for node operators operating long tail services?
If rewards are paid out according only to fees generated, then why would people run nodes that expose long tail, important, but less-in-demand services?
I’m curious what people think on this one. I worry about making up theoretical abstract justifications around this theme without concrete examples. I also think that there are plenty of mechanisms within the protocol or ecosystem to incentivize the important instances of this as workarounds if needed.
Is it really important to have a model available that attracts almost zero fees? Couldn’t it just be incentivized with a protocol grant? Or could it attract non-zero fees via a test “keep-alive” set of tester jobs, that validators agree are worthwhile as a public-good for the network, so that it earns some LPT incentives in proportion to those fees? Wouldn’t high fee earning nodes expose this capability additionally without dedicating significant resources to it, because it helps the network and their service offering in general in the eyes of the agent users?
This theme has come up in the feedback surveys and Discord discussions. What are the concerns here?
What are the consequences of PM security with USD based pricing and a large # of nodes?
Payments are definitely a separate topic, but this is a good question. The security model of PM breaks down if you have a large number of nodes and don’t require large gateway deposits. Let’s get to a separate design thread on payments, rather than heavily debate here. In practice, with agents as users, and low fees for ticket redemption, nodes can typically do work with confidence of a high probability of cashing in on their reward-impacting credits, as long as they monitor on chain deposits are available at the time of ticket receipt.
Thanks everyone for diving into detail on the Node Operator role. Please share any feedback or key questions, and we’ll follow up here and in a soon-to-be-scheduled community call on these topics!