search

livepeer / LIPs

Livepeer Improvement Proposals
9 stars 13 forks source link

InflationChange Parameter Update #34

Closed viktorbunin closed 3 years ago

viktorbunin commented 4 years ago

lip: To Be Assigned title: InflationChange Parameter Update author: Viktor Bunin (@viktorbunin) type: Parameter status: Draft created: 2020-07-01

Abstract

This proposal describes a change to the inflationChange parameter of the Livepeer protocol.

Specification

The inflationChange parameter is the rate at which the inflation rate decreases every round (day) while the staking rate is over 50%. As of 7/1/2020, the current inflation per round is 0.0502%, which results in an annual inflation rate of ~20%. The inflation per round will decrease every day by the inflationChange until it hits zero, resulting in an inflation rate of 0% for the Livepeer network.

It is proposed that the value of the inflationChange parameter be set to .5. The current value in the protocol is 3, which represents a change from 0.0003%/round to 0.00005%/round. This will also require some small updates to the way inflation is calculated, which will need a candidate implementation before this proposal is finalized for voting.

There are currently almost no fees being earned on the Livepeer network. Infrastructure providers are being supported almost entirely by Livepeer’s inflationary rewards. With inflation trending towards zero, infrastructure provider revenues will also approach zero, which will make supporting Livepeer unsustainable.

Livepeer’s inflation is on track to hit 0 by late 2020. If adopted, this proposal will slow the rate of decrease in Livepeer’s inflation by 83% and extend inflation through mid 2022 or 2023, depending when this protocol is adopted.

Specification Rationale

Livepeer pioneered staking rate based inflation targeting. As the protocol continues to grow, the role of inflation remains the same: subsidize infrastructure providers until fees are sufficiently high and consistent enough to enable sustainable orchestrator & transcoder businesses.

Livepeer's inflation is scheduled to hit 0% in late 2020. Since the network has not experienced sufficient adoption yet (11 ETH earned by all nodes in the last ~6 months) a 0% rate of inflation will make running infrastructure on Livepeer unsustainable and impede further adoption.

The proposed update to Livepeer's monetary policy would account for network realities and extend the runway for Livepeer to establish a self-sustaining fee market.

Decreasing the inflationChange parameter from 3 to .5 is the Minimum Viable Change (TM) that accomplishes the goal of extending Livepeer's runway to gain adoption to mid 2022 or 2023, depending when it’s adopted. It requires the least rework of Livepeer's monetary policy relative to other proposals and remains true to Livepeer's original monetary policy vision.

Lastly, time is of the essence. Every day this proposal is not implemented shaves 6 days off the extended runway. We believe this proposal represents the smallest, easiest, most straightforward change to build quick community consensus and take action before inflation falls even lower.

image

Counter Arguments and Counter Counter Arguments

Counter Argument 1

If you change the monetary policy now, you can do so again in the future, and no one can have any assumptions about it

Counter Counter Argument 1

Livepeer isn’t trying to be money. Livepeer is a protocol to provide a service and the Livepeer token (LPT) is a work token model that is used for signalling the capacity to provide service to the network. It is closer to a taxi medallion than a currency, and that’s a good thing. Unchangeable monetary policy is important for networks like Bitcoin where that’s the core feature. But on Livepeer, monetary policy is in service of the network’s main goal, which is to provide decentralized, inexpensive transcoding services for the world.

We believe that this proposal is a small enough change that it remains true to Livepeer’s stated monetary goals. The inflation mechanism remains fully intact, it just slows down so the changes in inflation aren’t as dramatic. An argument can be made that this proposal will actually make the monetary policy more true to its intended purpose. Currently, Livepeer’s inflation rate changes at about 1% per week, which is extremely fast relative to most other networks. A 1% change in the rate of inflation is a big deal and will mean hundreds of millions of dollars in rewards when the network is at scale. By slowing that rate of change down, it will give more time for the community to factor in the changes in inflation into their staking decisions.

Counter Argument 2

Some current node operators are not actually prepared to run GPUs to encode video and are just collecting inflation without providing useful work to the network. Low inflation is good because it will weed them out.

Counter Counter Argument 2

This is true and we agree it will weed those node operators out, but the problem with this argument is that it will weed out the GPU node operators even faster. GPU operators will have significantly higher costs and will become unprofitable long before non-GPU operators. This of course assumes that transaction fees will not rise to sufficiently high levels to compensate for the drop in inflation. But given that inflation is hitting zero in less than 5 months, we feel fairly confident that fees will not be sufficiently high in that time frame.

Building multi-sided marketplaces like Livepeer is notoriously difficult because both sides have to be at the table at the same time and in sufficient quantities. Having inflation go to zero can significantly reduce an infrastructure provider’s incentive to make transcoding services ready and available to the network. At a rate of zero, those services are unlikely to be provided, so when demand finally arrives, there will be limited supply available. This is typically solved in startups by throwing VC dollars at it - subsidizing one side - until sufficient scale is achieved and monetization can begin. In Livepeer, this subsidy is in the form of inflation, and removing it before there’s adoption does not benefit the network. Furthermore, it is in some ways harmful, because the immense amount of inflation to date went to non-GPU node providers so the folks that need the subsidy least are the ones that got it the most.

Counter Argument 3

The current monetary policy already accounts for this. Why not wait for the Participation rate (currently 67%) to fall below the target Staking rate (50%)? Then inflation will rise back up.

Counter Counter Argument 3

This argument currently suffers from the "tragedy of the commons". 3.8m LPT tokens (17% of the supply) would need to be unbonded in order to get the Livepeer participation rate below the target staking rate. This is a significant amount and we have not seen unbonding at this scale for any network, other than those that were failing / imploding. Even if this many tokens were successfully unbonded, what will happen to them? There is not nearly enough liquidity for the market to absorb them.

Looking at other networks, we have not seen significant changes in the participation rate as the inflation rate approaches its lowest bound. This is true for networks like Cosmos, where the inflation has been at the minimum value of 7% for months. It is also true for Kusama, where the participation rate continued rising past its target rate, which decreased inflation from 10% to 3%. As the rate fell, governance changed the target staking rate from 50% to 75% to account for this higher than expected staking.

Counter Argument 4

This is not the best path forward, we should do X instead. (insert your suggestion)

Counter Counter Argument 4

Most other proposals we’ve considered or seen mentioned are larger in scope and require much more thought and debate. Performing a larger economic overhaul is not advisable at this time for two reasons:

Thank you for reading! We look forward to your thoughtful responses. Viktor & the Bison Trails team

Copyright

Copyright and related rights waived via CC0.

kyriediculous commented 4 years ago

Thanks for writing this up, very well considered arguments and I like the fact that there's both pro's and contra's provided.

I think it's safe to say that I haven't been a fan of prolonging or changing inflation from the start.

Argument 1

While Livepeer's economic model isn't based around trying to be money it is important to have a robust and preferably unchanged monetary policy whenever possible. These were the rules of the game that were laid out at the beginning and one can't simply change rules because he/she isn't favoured by the short-term outlook as much.

The only reason to ever adjust this monetary policy would be the near certainty of a detrimental outcome for the protocol if left unchanged. I don't think we are even remotely close to that stage. Livepeer trying to be money or not is in my opinion quite irrelevant here.

Furthermore there was token model that was designed at protocol inception, its rules have not been tested to the limit so changing anything about the policy is, I feel like, unwarranted and could only be more harmful than beneficial.

Argument 2 I'm not sure how much I can say about this, perhaps Livepeer Inc should communicate this more clearly but there is no real situation in whereby the progress of Livepeer depends solely on supply and demand side coming together at the same time. That's just not a sustainable path forward and would require too many things to fall into place at once.

Secondly, Livepeer never expected anyone to set up fresh GPU rigs. The story has always revolved around existing GPU operators (for e.g. mining or rendering) that have existing revenue sources.

I also don't immeadiatly see how this proposal changes much about inflationary rewards not going to operators that plan to run GPUs, if anything wouldn't this only enforce and prolong that behaviour?

I also think the term "subsidising" is the wrong terminology to use. In reality the inflationary rewards suffers from tragedy of the commons just as much. The only subsidy that exists is for the ones that are not selling at a loss. The secondary market does not have the required liquidity to deal with every operator selling their inflation on a daily basis. So what you call subsidising is in my opinion just a plutocracy/race to the bottom.

Furthermore I think the Livepeer protocol in terms of USD value has already subsidised more than enough considering the cost of actually operating on the network in this early stage.

Let's use numbers up until streamflow for this quick math example.

A VM + tx costs for calling reward is like what , 120 USD a month? Duration 18 months. Number of operators 30. Monthly cost 120 USD per operator. 18 x 30 x120 = 65K USD

LPT at inception 10 million, LPT at streamflow launch 19 million. Inflation 9 million.

Let's be VERY conservative here and say that the average price is 1$. In reality that's likely going to be more than double.

That's 9 million USD in protocol subsidies to delegates and delegators. Let's again be conservative and say that the operators got 10%. Nearly 1 Million USD.

I don't really think it's correct to be asking for more subsidies when plenty of profit opportunity has already been created and plenty of subsidies have been given to not only cover operational cost but to provide the ability to re-invest in the network, of which the latter has rarely happened so let's stop hoping it will.

Furthermore prolonging inflation has a downward effect on price because there will be operators selling on the secondary market. Other operators are taking the risk of the future value of LPT to cover their original costs. I feel like this proposal only caters to the short term as well as large operators.

yondonfu commented 4 years ago

While the contract implementation changes required to allow setting the inflationChange parameter to a value that represents 0.00005%/round would be doable, it does expand the scope of work required for this proposal to include:

The above tasks are typical for a contract upgrade, but I think its worth acknowledging that:

If there is a sense of time urgency around this proposal, it might make sense to consider setting the inflationChange parameter to a value that would not require contract implementation changes - this would result in an earlier possible date for the parameter to be updated and would also avoid requiring an implementer for the proposal.

[1] The Solidity math library currently used by the contracts only supports 6 decimal places of precision. As a result, the smallest decimal value that can be represented in the contracts right now is .000001 which corresponds to inflationChange = 1 and 0.0001%/round.

@viktorbunin Did you also do a scenario analysis for when the inflation rate would hit zero if the inflationChange parameter is set to 1 (i.e. .0001% per round)? I know that the date that the inflation rate hits zero would be much sooner, but I think this could be a useful data point to consider when evaluating whether a different value for inflationChange could also make sense.

kylesamani commented 4 years ago

Viktor

Thanks for proposing this change. This is good thinking.

I think they way I look at this is to look at other protocols that took longer than expected to incubate. The most obvious example of this is Synthetix ($SNX). After they pivoted from Havven to Synthetix, they realized that they needed to reward their early community members who stuck by them through the depths of the bear market. So they proposed a change to the community to enable aggressive inflation - something on the order of 75% in the first year - to incentivize community members to bootstrap the new Synthetix network.

I expect to see similar behavior in the near future from Aave ($LEND), Bancor ($BNT), and Kyber ($KNC) as well. While they have not done so yet, if you spend any time in their respective discords, it's pretty clear that community members are getting ready to propose changes that reward existing community members.

So overall, I am very supportive of this change. There is a fair bit of precedent for it elsewhere in the crypto community, and it can work if designed well.

The biggest open question IMO is: is this enough? Is there more we can do to incentivize the supply side of the network?

viktorbunin commented 4 years ago

Thank you for your feedback @kyriediculous! Really appreciate hearing from you.

While Livepeer's economic model isn't based around trying to be money it is important to have a robust and preferably unchanged monetary policy whenever possible. These were the rules of the game that were laid out at the beginning and one can't simply change rules because he/she isn't favoured by the short-term outlook as much.

The only reason to ever adjust this monetary policy would be the near certainty of a detrimental outcome for the protocol if left unchanged. I don't think we are even remotely close to that stage. Livepeer trying to be money or not is in my opinion quite irrelevant here.

Furthermore there was token model that was designed at protocol inception, its rules have not been tested to the limit so changing anything about the policy is, I feel like, unwarranted and could only be more harmful than beneficial.

The goal of this proposal is to prevent the “near certainty of a detrimental outcome” that we can already anticipate. If left unchanged, infrastructure providers will not just gradually stop running nodes. Many folks will begin operating at a loss at around the same time and will likely choose to start bringing their nodes down. Why wait until the 59th minute of the 11th hour to make an adjustment when operators are disincentivzed? At this point in time, with adoption right around the corner, there’s still an opportunity to make a change to prevent adoption from being derailed.

Furthermore, even if we disagree around how much danger the protocol is in, this change can still be implemented to slow down the rate of inflation change. As the ecosystem grows, every basis point will make a huge difference in transcoder revenues. The current inflationChange parameter is too high. Inflation changing by 1% per week results in enormous swings that are highly detrimental for revenue predictability for professional infrastructure providers. For example, if it takes a few weeks for an order of GPU’s to arrive and the inflation rate drops by 3-4% in that timeframe, the GPU investment may not make sense by the time they arrive. How long would we expect professional infrastructure providers to operate under these unpredictable conditions?

Argument 2 I'm not sure how much I can say about this, perhaps Livepeer Inc should communicate this more clearly but there is no real situation in whereby the progress of Livepeer depends solely on supply and demand side coming together at the same time. That's just not a sustainable path forward and would require too many things to fall into place at once.

Secondly, Livepeer never expected anyone to set up fresh GPU rigs. The story has always revolved around existing GPU operators (for e.g. mining or rendering) that have existing revenue sources.

I think Livepeer would struggle to convince GPU operators to add support for the Livepeer network when inflation and fees are both near zero. The challenge for operators in this scenario is not just the financial costs of adding support, but the overhead and hours spent on making the decision to support Livepeer, doing due diligence, speaking to users, legal review, etc. There’s also little financial incentive for them to add support for the network by then.

"Add support now and make no money, but we think you will earn some money in the future, but we don't know how much" is not as convincing as "join now and earn an estimated X in rewards immediately while we scale the network and supplement your earnings with ETH usage fees."

I also don't immeadiatly see how this proposal changes much about inflationary rewards not going to operators that plan to run GPUs, if anything wouldn't this only enforce and prolong that behaviour?

I'm not sure if I'm following, so I'll try to respond, but please let me know if I misunderstood. I think this is addressed by arguments 2 and 4. I don't see a mechanism that would easily direct inflationary rewards to GPU providers only, but I also don't think we need to make this distinction at this time. This parameter change is only meant to extend the runway to get transcoding revenues going on the network. Achieving this milestone will incentivize token holders to delegate to orchestrators that are earning ETH fees in addition to the LPT inflation. If the parameter change is adopted, the problem solves itself.

I also think the term "subsidising" is the wrong terminology to use. In reality the inflationary rewards suffers from tragedy of the commons just as much. The only subsidy that exists is for the ones that are not selling at a loss. The secondary market does not have the required liquidity to deal with every operator selling their inflation on a daily basis. So what you call subsidising is in my opinion just a plutocracy/race to the bottom.

Furthermore I think the Livepeer protocol in terms of USD value has already subsidised more than enough considering the cost of actually operating on the network in this early stage.

Let's use numbers up until streamflow for this quick math example.

A VM + tx costs for calling reward is like what , 120 USD a month? Duration 18 months. Number of operators 30. Monthly cost 120 USD per operator. 18 x 30 x120 = 65K USD

LPT at inception 10 million, LPT at streamflow launch 19 million. Inflation 9 million.

Let's be VERY conservative here and say that the average price is 1$. In reality that's likely going to be more than double.

That's 9 million USD in protocol subsidies to delegates and delegators. Let's again be conservative and say that the operators got 10%. Nearly 1 Million USD.

I don't really think it's correct to be asking for more subsidies when plenty of profit opportunity has already been created and plenty of subsidies have been given to not only cover operational cost but to provide the ability to re-invest in the network, of which the latter has rarely happened so let's stop hoping it will.

Furthermore prolonging inflation has a downward effect on price because there will be operators selling on the secondary market. Other operators are taking the risk of the future value of LPT to cover their original costs. I feel like this proposal only caters to the short term as well as large operators.

Your calculations for infrastructure provider costs do not match what we’re seeing, but I agree with your overall point: there have been a lot of rewards already! However, the more timely issue is how we can build a future where adoption is achieved. A portion of previous rewards subsidized non-productive infrastructure providers that were not running GPUs or providing transcoding services to the network. We are submitting this proposal because we think it’s important to incentivize large GPU providers to support Livepeer.

Asking existing infrastructure providers to support Livepeer at a loss because they earned rewards before is not sustainable for providers or the network. Asking new infrastructure providers to add support with no visible participatory rewards or revenues is not reasonable given operating costs.

viktorbunin commented 4 years ago

While the contract implementation changes required to allow setting the inflationChange parameter to a value that represents 0.00005%/round would be doable, it does expand the scope of work required for this proposal to include:

  • Updating the Solidity math library to support more decimal places of precision [1]
  • Testing the updates to the Solidity math library
  • A review process for the updates to the Solidity math library
  • Migrating to a new Minter contract (serves as the LPT/ETH bank for the smart contract system and manages inflation rate changes)

The above tasks are typical for a contract upgrade, but I think its worth acknowledging that:

  • The tasks will take longer to complete meaning that the earliest possible date for the inflationChange parameter to be updated would have to be quite a bit later than if implementation changes were not necessary
  • The tasks will require an implementer

If there is a sense of time urgency around this proposal, it might make sense to consider setting the inflationChange parameter to a value that would not require contract implementation changes - this would result in an earlier possible date for the parameter to be updated and would also avoid requiring an implementer for the proposal.

[1] The Solidity math library currently used by the contracts only supports 6 decimal places of precision. As a result, the smallest decimal value that can be represented in the contracts right now is .000001 which corresponds to inflationChange = 1 and 0.0001%/round.

@viktorbunin Did you also do a scenario analysis for when the inflation rate would hit zero if the inflationChange parameter is set to 1 (i.e. .0001% per round)? I know that the date that the inflation rate hits zero would be much sooner, but I think this could be a useful data point to consider when evaluating whether a different value for inflationChange could also make sense.

Hi @yondonfu, thank you for your response! Yes, please see below for all of my scenario analyses.

image

I considered updating inflationChange to 1, but because it only prolongs the timeline by 7-9 months, I think it is not sufficient for fees to pick up to a substantial enough degree to sustain Livepeer until the network sees greater adoption. We want to see Livepeer succeed and extending the runway now, by more than 9 months, is a way to give the network more of a chance to increase adoption.

I agree that changing the inflationChange to .5 would require other changes to make sure the change is reflected accurately. I would love further feedback and assistance from the Livepeer team on how quickly an implementation could be ready.

If we can put it together quickly, then it seems reasonable to do so, but if the implementation slows development down by another 1-2 months, it might be prudent to consider altering the proposal to set inflationChange to 1. I’d look for wider community support before standing behind this change, because I don’t have enough information to have full confidence this revised proposal will extend the timeline enough to provide enough benefit to the network.

viktorbunin commented 4 years ago

Viktor

Thanks for proposing this change. This is good thinking.

I think they way I look at this is to look at other protocols that took longer than expected to incubate. The most obvious example of this is Synthetix ($SNX). After they pivoted from Havven to Synthetix, they realized that they needed to reward their early community members who stuck by them through the depths of the bear market. So they proposed a change to the community to enable aggressive inflation - something on the order of 75% in the first year - to incentivize community members to bootstrap the new Synthetix network.

I expect to see similar behavior in the near future from Aave ($LEND), Bancor ($BNT), and Kyber ($KNC) as well. While they have not done so yet, if you spend any time in their respective discords, it's pretty clear that community members are getting ready to propose changes that reward existing community members.

So overall, I am very supportive of this change. There is a fair bit of precedent for it elsewhere in the crypto community, and it can work if designed well.

The biggest open question IMO is: is this enough? Is there more we can do to incentivize the supply side of the network?

Thank you very much for your feedback @kylesamani. I see the relevance of the analogy to Synthetix. I do think Livepeer is in a similar situation. The tech works, it’s really cool, and it makes a ton of sense. The biggest question is when adoption will pick up.

“Is this enough? What else can we do?” Yes. These questions are probably relevant for both supply and demand. But it may not make sense to introduce a more significant proposal or overhaul due to Argument 4 above. I’m hoping that ideally we’d see usage and then adjust network parameters as needed to build on that momentum.

nchirls commented 4 years ago

Hi Everyone - Been interesting to follow this discussion.

A question, particularly for @viktorbunin @yondonfu - In thinking about the possibility that this may not be the last change to the rate of inflation (although I do think these changes should be far and few between and only when the community deems absolutely necessary) - Are the proposed changes both from a community standpoint and technical standpoint scalable beyond this one decision?

ie. If the community decides at some future point that an additional change to the inflation rates needs to be made, would additional technical upgrades be needed? Is this the most effective way to scale these decisions in the future?

An alternative possibility that doesn't require any technical changes would be to change the target bonding rate no? What if the community simply voted to change that to 70% rather than 50%? I'm not sure if this is the right approach but throwing out other options that may be easier, more scalable and don't require additional technical work on the protocol...

dob commented 4 years ago

As this is a proposal that clearly involves some strong opinions on either side, I thought it would be helpful to remind everyone of The Livepeer Governance Founder's Statement, which attempts to clarify the principals that should be prioritized in making decisions that govern the network.

In this case, there are a couple principals which seem particularly relevant.

1. Prioritize practicality and utility. "Livepeer should work. It should be usable. It should make an impact."

Ask yourselves if inflationary incentives in addition to fee based incentive help or hurt the Livepeer in the practical sense of encouraging a worldwide network of infrastructure providers to be available to encode video? Especially as the network continues to gain traction, but hasn't yet achieved millions of dollars in fees.

2. Incentives should encourage participation.

There is certainly a cost to extending the inflation schedule via a parameter change here in the form of additional token being generated, but it's only diluting those who are not actively participating. Does the additional token being generated encourage actors to actively participate in the network? Does inflation hitting 0 encourage active participation?

3. Community should have a clear path to come to consensus on governance decisions.

This one is likely to be draw varying opinions and it's unlikely there will be consensus through this discussion alone. Instead this discussion should just be used to inform the proposer on how to edit or modify their proposal before bringing it through Draft, Last Call, and Proposed status to a vote, in order to best reflect the outcome that they want to champion based on the input of the process. Remember that in this stage (an issue discussion), we're giving input to the proposer. If there's an alternative proposal that you'd like to champion, consider starting another issue or making a draft proposal.

Remember, ultimately we want to remember the mission of Building the World's Open Video Infrastructure. There are likely many iterations, features, and updates to the capabilities of the network coming down the pipe - each which may require incentives being addressed. Thanks for continuing to engage in the discussion around the current incentives in a thoughtful and well intentioned way.

0xVires commented 4 years ago

First of all, thank you Viktor for the proposal! Overall, I agree that Livepeer is currently no in a state where removing the LPT subsidies would be beneficial for the network (arguments can be found here: https://forum.livepeer.org/t/lpt-inflation-vs-eth-rewards-from-transcoding/1081). As far as I can tell, the main counter argument is that Livepeer should not keep subsidizing CPU transcoders since they are not useful for the network. I'd still love to see some benchmarks supporting that argument... I don't know a lot about transcoding, but from what I've read (mainly on the plex subreddit), a decent, modern CPU should be able to handle ~10 1080p streams. If that's the case, CPU transcoding is perfectly viable during the "generating more demand" phase of Livepeer - and it would be good for the protocol to keep as many transcoders operating as possible. And for that, keeping some amount of LPT inflation is necessary until a decent amount of fees are generated.

But instead of changing the inflation rate, I would actually prefer @nchirls idea:

An alternative possibility that doesn't require any technical changes would be to change the target bonding rate no? What if the community simply voted to change that to 70% rather than 50%? I'm not sure if this is the right approach but throwing out other options that may be easier, more scalable and don't require additional technical work on the protocol...

Setting a different target participation rate would be very simple change, not requiring any contract adjustment (correct me if I'm wrong @yondonfu ) and would have a very similar effect. I did some quick calculations (assuming all mintable LPT are bonded and no unbonding occurs) with the following scenarios:

image

If my calculations are correct, setting the participation target to 70% would give Livepeer at least (probably quite a few more) 2 x 94 = 188 rounds until we're back at the current inflation rate. With 75%, it would be 544. Given that LPT's main purpose is staking, setting a target participation rate of 70% or 75% is very reasonable.

kyriediculous commented 4 years ago

Here are my takeaways after today's LIP call and I actually feel there's some separate topics but only one of them is in scope here (number 2)

But I also feel like we haven't touched on a few things enough

I actually feel like the design of the token economics are quite reasonable but as mentioned earlier perhaps the initial parameters aren't optimal for good monetary policy but they worked at the start to aggressively move forward.

Therefore I feel like we shouldn't rush any changes to the protocol at current time. We can discuss what sensible parameters would be for the current maturity of the protocol and set those for the longer term rather than trying to apply short-term bandaids right now.

This would give us time to collect data as we actually approach critical stages (inflation dropping low) and make better informed decisions.

This change can actually take place after inflation drops significantly. If the drop in participation that we anticipate due to low inflation doesn't bring inflation back up we can consider increasing the participation rate threshold. At the same time we can decrease inflation volatility to not go back to the wild 150% APY days.

I feel like that way we can actually tackle all of the three points I mentioned earlier and if not we can at least learn more about what needs to be changed. It would also give us more time to gauge what fees are flowing through the network in the coming quarter.

nchirls commented 4 years ago

@kyriediculous I think this is a really thoughtful summary. And I too agree that it's worth giving it some more time and discussing options once we have more data about how the network is operating as additional demand comes onto the network, hopefully in the coming quarters. Making quick decisions / changes based on the many possible outcomes at this stage feels somewhat premature.

yondonfu commented 4 years ago

To give everyone a better understanding the technical requirements for this proposal, I've created a preliminary implementation in a fork and the code diff can be viewed here.

Implemention

A summary of the important changes:

All other changes in the fork are for testing.

A summary of the implications of these changes:

An example:

The initial state:

Given the current inflation change value of .0003%, after a new round is initialized:

Given the proposed inflation change value of .00005%, after a new round is initialized:

[1] 3 additional decimal places is a bit of an arbitrary choice right now. The main impact that might be considered as the number of decimal places is increased is that supporting more decimal places decreases the max uint256 value that can be used in percentage calculations in the contracts. The max value is (2 ** 256 - 1) / PERC_DIVISOR where PERC_DIVISOR affects the number of decimal places of precision. This is still a very very large number so in practice this shouldn't be a concern, but just mentioning for completeness.

Deployment

While the implementation would be fairly simple, the deployment steps required would be a bit more involved:

  1. Deploy the new Minter
    • The inflation parameter value should represent the inflation rate in the round that the deployment takes place
    • The targetBondingRate parameter value should represent 50% (the current value)
    • The inflationChange parameter value should represent .00005%
  2. Register the new Minter with the Controller
  3. Call migrateToNewMinter() on the old Minter in order to transfer all LPT and ETH held by the old Minter to the new Minter. This will also transfer the rights to mint new LPT to the new Minter

During the round of deployment, all active orchestrators would need to call reward before these steps are executed.

yondonfu commented 4 years ago

@nchirls

ie. If the community decides at some future point that an additional change to the inflation rates needs to be made, would additional technical upgrades be needed? Is this the most effective way to scale these decisions in the future?

Depends on what type of change to the inflation rate is desired. The changes required to support Viktor's proposal would also make it easier to decrease the inflation change parameter to a value lower than the proposed value of .00005% if ever needed - so, if the future desired change is just an update to the inflation change parameter it would likely not require any technical changes (it would just be a parameter update performed by a single contract function call). However, if the desired change in the future involves something like a different inflation rate curve (instead of a linear increase/decrease each round) then that would require additional technical changes.

nchirls commented 4 years ago

Hi All - Appreciate all the good thoughts and discussion here. Perhaps it's worth summarizing / narrowing down the issues so that at some point there can be a community vote.

As far as I see it, there are two major items that need consensus and eventually a vote:

  1. If changes need to be made to the inflation rate to incentivize ongoing participation, what are the most effective ways to do that, now and on an ongoing basis? It seems from this discussion that changes to the target participation rate may not be sufficient to make effective changes on an ongoing basis, and thus implementing upgrades to the inflationChange parameter may be the best way to do this... @viktorbunin could you summarize the pros / cons for the inflationChange parameter method v. the target participation method as currently exists?

  2. When is the appropriate time to change the economics of the protocol and associated inflation rate and by how much? I have read good arguments for both (a) Let's wait and see - Nothing right now is currently broken so no changes needed or (b) We should get ahead of potential problems when the inflation rate goes to zero later this year in order to proactively prevent any disruptions to the supply side of the network. I am open to (a) or (b) but would great to take a poll and/or summarize arguments / opinions for each. Additionally, I think it would be helpful for the community to settle on a set of goals (qualitative or quantitative) that we're trying to optimize for in order to create consensus for any additional economic changes that may be suggested in the future...and in order to be able to measure the success or failure of additional changes to the inflation rate on an ongoing basis. I'm not 100% sure what these are, but curious to hear from the community and suggest some of my own if folks think this is a scalable way to approach the subject of changes to inflation, how much, and when...

Nick

viktorbunin commented 4 years ago

Thanks again for your feedback @kyriediculous! My answers are below.

  • Inflation might not drop to 0% , there could be dynamics playing out before that even happens e.g. due to liquidity pooling becoming more attractive than staking at a certain point in the yield curve.

Unless there is a clear path for the participation rate to fall below the target staking rate (a mammoth decrease of 17% of total LPT), it is highly likely that the rate will fall to zero. For reference, we have never seen that rate of unbonding on any network that is not failing.

  • Prolonging inflation does nothing about token distribution to supply side capacity, it only tackles diluting inactive participants. But I feel like merkle mine participants have already been diluted heavily and this is not the issue at hand anymore.

This is not accurate. Inflation compensates infrastructure providers and token holders while there are no other fees being generated. It is also not applicable to dilution of merkle mine participants because those that were active on the network afterwards have also been earning rewards. Folks that have not become active participants after 2 years of token ownership should be prioritized less than current active participants. Given the merkle mine’s air-drop nature, it was likely that many folks wouldn’t use their tokens.

  • Inflation dropping to 0% could see some operators leaving the network that didn't plan to run capacity. While there is not that much liquidity on the secondary market there could be a opportunity there for token distribution to new operators.

Why would a new operator join the network if there is no inflation and no fees? What is the incentive? If there is demand, token holders will re-delegate to operators that are transcoding and earning ETH fees on top of the LPT inflation. The market solves this problem on its own because rewards from delegating to a working transcoder will be higher than a non-working one. Falling to 0% inflation is only harmful in this instance.

  • There is a conflict of interest between this proposal and the voting system, because the only voices are the direct beneficiaries of the proposal as Gavin also mentioned during the call.

This is the case with all governance systems with token-based voting, not just Livepeer. Token holders’ interest is aligned with that of the network. From working with current token holders and infrastructure providers, the only consistent thread I’ve seen is that everyone wants Livepeer to be successful and will do what it takes to make it happen.

I actually feel like the design of the token economics are quite reasonable but as mentioned earlier perhaps the initial parameters aren't optimal for good monetary policy but they worked at the start to aggressively move forward.

Therefore I feel like we shouldn't rush any changes to the protocol at current time. We can discuss what sensible parameters would be for the current maturity of the protocol and set those for the longer term rather than trying to apply short-term bandaids right now.

This would give us time to collect data as we actually approach critical stages (inflation dropping low) and make better informed decisions.

This change can actually take place after inflation drops significantly. If the drop in participation that we anticipate due to low inflation doesn't bring inflation back up we can consider increasing the participation rate threshold. At the same time we can decrease inflation volatility to not go back to the wild 150% APY days.

I feel like that way we can actually tackle all of the three points I mentioned earlier and if not we can at least learn more about what needs to be changed. It would also give us more time to gauge what fees are flowing through the network in the coming quarter.

Waiting to gather more information before making a change is dangerous for the success of the network. We do not need additional information to foresee what will happen when inflation hits zero. An inflation rate of zero will make it very difficult to continue or start running infrastructure on Livepeer. This is an outcome we all want to avoid.

I agree that the current economic policy is overall sound. I also agree that if we want to make bigger changes, we should do so with a lot of intention and with the knowledge of how real supply/demand side interact on the network.

There are times to make big changes, but this proposal asserts that this is the right time for action. We need to get to adoption, but to get there, we need to make sure the network maintains incentives for operators to continue to support it. We believe this proposal is the smallest viable change to get us there.

viktorbunin commented 4 years ago

Hi All - Appreciate all the good thoughts and discussion here. Perhaps it's worth summarizing / narrowing down the issues so that at some point there can be a community vote.

As far as I see it, there are two major items that need consensus and eventually a vote:

  1. If changes need to be made to the inflation rate to incentivize ongoing participation, what are the most effective ways to do that, now and on an ongoing basis? It seems from this discussion that changes to the target participation rate may not be sufficient to make effective changes on an ongoing basis, and thus implementing upgrades to the inflationChange parameter may be the best way to do this... @viktorbunin could you summarize the pros / cons for the inflationChange parameter method v. the target participation method as currently exists?

Happy to @nchirls! I have considered changing the target participation rate instead, but believe that will be more harmful to the network than the current proposal.

There is an abundance of evidence that the staking rate does not meaningfully respond to changes in inflation. Most token holders are long term holders and there is very little liquidity for Livepeer. This means that we are likely to see the staking rate consistently stay either above or below the target participation rate. With the current monetary policy, this will result in an inflation that begins its climb back up to stratospheric levels or quickly returns to its march towards zero. Neither circumstance is sustainable.

Changing the target participation rate will be a really powerful lever in the long term when there is a large and diversified pool of token holders, ample liquidity, and significant transcoding on the network. However in the meantime, it is a double edged sword that can end up doing more harm than good through its unpredictability.

  1. When is the appropriate time to change the economics of the protocol and associated inflation rate and by how much? I have read good arguments for both (a) Let's wait and see - Nothing right now is currently broken so no changes needed or (b) We should get ahead of potential problems when the inflation rate goes to zero later this year in order to proactively prevent any disruptions to the supply side of the network. I am open to (a) or (b) but would great to take a poll and/or summarize arguments / opinions for each. Additionally, I think it would be helpful for the community to settle on a set of goals (qualitative or quantitative) that we're trying to optimize for in order to create consensus for any additional economic changes that may be suggested in the future...and in order to be able to measure the success or failure of additional changes to the inflation rate on an ongoing basis. I'm not 100% sure what these are, but curious to hear from the community and suggest some of my own if folks think this is a scalable way to approach the subject of changes to inflation, how much, and when…

Thanks Nick - these are really great questions.

Wait and see vs. act now is a problem as old as time. In my opinion, the best way to think about whether action is warranted now is based on the likelihood of the event happening * how bad the consequences will be. In this case, I see the odds of inflation going to 0% to be 100%. There is no reasonable path to getting the participation rate below 50%. How bad will the consequences be? It’s hard to say, but what we can see paints an undesirable picture. Every current infrastructure provider will be operating at a loss for months. Every new infrastructure provider will be joining a network where they do not earn any rewards or fees. As a current transcoder, we would prefer to not operate at a loss. If I put myself in the shoes of a new infrastructure provider, I would struggle to make the business case to support Livepeer given these conditions. Is there evidence that demonstrates that new or existing infrastructure providers are comfortable operating with no earned rewards or fees?

This experiment could not unfold at a worse time with adoption around the corner. We need to proactively address this situation. Livepeer is a two-sided marketplace between supply (infrastructure providers) and demand (anyone needing transcoding, such as video services). Why risk alienating one side while the other one is ramping up?

I think the best guideline for economic model updates can be gleaned from the Doug’s founders statement:

“Incentives should encourage participation”

While it may be too early to determine exact qualitative or quantitative parameters by which to evaluate economic decisions, the overall goal is to encourage participation by both sides of the Livepeer marketplace. This proposal accomplishes that in the short term. In the long term, I agree that we need to be much more intentional as a community about larger changes or an overhaul of Livepeer’s economic model.

viktorbunin commented 4 years ago

A small, but important, update: this proposal has been split in two thanks to thoughtful feedback from the community.

Parent

Bundle

LIP-34 and LIP-40 are bundled because:

Looking forward to the LIP call tomorrow for further discussion. Barring any issues, the goal is to move to Last Call tomorrow evening. Thanks!

cfl0ws commented 4 years ago

@viktorbunin thanks for this proposal. I haven't read through the entire thread in detail, yet feel like I read enough to get the general tone. I also recognize I'm a bit late to the conversation.

That being said, rather than tie inflationary rewards to only % staked, why not consider tying it to transcoding activity on the network?

cc: @dob @yondonfu

yondonfu commented 4 years ago

LIP-34 (the LIP for this discussion thread) has just been assigned the Last Call status which kicks of a 10 day Last Call period for any remaining feedback prior to the LIP being assigned the Proposed status.

viktorbunin commented 4 years ago

@viktorbunin thanks for this proposal. I haven't read through the entire thread in detail, yet feel like I read enough to get the general tone. I also recognize I'm a bit late to the conversation.

That being said, rather than tie inflationary rewards to only % staked, why not consider tying it to transcoding activity on the network?

My initial reaction is that this seems like a very big change and would require a lot more research. It is not obvious to me that it is better to have inflationary rewards tied to work performed (transcoding) rather than the ability to perform work (i.e., staking). I'm happy to chat further on this, but for the purpose of this LIP discussion, one of my goals it to implement a smaller, surgical fix now before considering a larger overhaul down the line.

bsparango commented 4 years ago

Considering the circumstances the Livepeer network is currently in, it is apparent to me that @viktorbunin's proposal is the correct path forward at this point in time.

It's clear that we need to extend the runway of supply side incentivization to allow us enough time for the demand side to catch up. Without supply side inflation incentives, the economics of the protocol simply don't work for Orchestrators and we risk more severe consequences.

@nchirls's proposition to change the target p-rate is interesting and definitely one that we should keep in our back pockets for the future, however I do not believe that is the correct fix at this time. Primarily due to illiquidity of LPT. If we suddenly chance the target p-rate to 75%, we immediately throw the network back into a state of increasing inflation. And with LPT illiquidity, we cannot be sure that stakers will even be able to aquire the necessary LPT to reach the new p-rate. Potentially putting the network into a longterm hyper-inflationary state.

The increment change in the inflation rate proposed by Viktor appears to be the least invasive change we can make while simultaneously maximizing the impact.

yondonfu commented 4 years ago

LIP-34 has been assigned the Proposed status in #49 and LIP-35 has been assigned the Proposed status in #46. Since LIP-34 is bundled in LIP-35, it can be voted on as a part of that bundle when a poll for LIP-35 is created.

yondonfu commented 3 years ago

LIP-34 and LIP-35 have been assigned the Accepted status as a result of the LIP-35 poll.

yondonfu commented 3 years ago

LIP-34 and LIP-35 have been assigned the Final status as the the inflationChange parameter has been updated to .00005% (stored as 500 out of 1000000000 in the contract which can be viewed here).

yondonfu commented 3 years ago

Closing this thread since LIP-40 has been marked Final.