Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Parachain/Parathread incentivisation #709

Closed
3 tasks
eskimor opened this issue Feb 21, 2023 · 4 comments
Closed
3 tasks

Design Parachain/Parathread incentivisation #709

eskimor opened this issue Feb 21, 2023 · 4 comments

Comments

@eskimor
Copy link
Member

eskimor commented Feb 21, 2023

For parathread core orders, we want some minimal price with the argument that there is some value always and also there is some effort for the network no matter the market conditions. Hence it would make sense for at least the minimum order price to go to validators directly, instead of burning everything.

Ideally from my point of view that fixed amount should go to validators directly - not even to nominators, but directly on top of the commission. This is not strictly required, as at least in theory validators can customize their commission rate freely and thus adjust it to cover their operation costs anyways. (There are issues in practice, so adding order fees to commission directly might actually be very worthwhile.)

But what ever we think for parathreads has to also consider parachains. Parachains right now only pay opportunity costs by not being able to nominate with the locked up DOT in their lease. This superficially works, because validators and nominators earn DOT via inflation - by removing the locked lease token from nominations, there are essentially more rewards for the remaining nominators. So this is basically how parachains pay the validators for their work.

For parathreads, if we just burn order fees, a similar argument holds: Those token cannot be used for nominating anymore, hence a bigger share of the inflation goes to remaining nominators. But there is also another effect: Those DOT are completely and permanently removed from the market, leading to a deflationary effect, which benefits everybody, not just the validators who actually do the work.

How is the situation for parachains on the other hand? Maybe not that different: If we assume a parachain is here to stay and keeps renewing its slot and for simplicity, assuming every time for the same amount of DOT, then those DOT are effectively also removed permanently from the market leading to that deflationary effect*).

In that vein, it has been discussed: If we scale up more: More validators, more parachains .. then the amount of work for validators will increase, while compensation would not necessarily.

Also related, there is some fixed overhead on the network per parachain block, no matter whether that block does something or is completely empty: This means either that incentives should be aligned so that parathreads are way cheaper on average, if you are not going to have data for almost every block on your parachain - or alternatively we could also charge parachains per block (which should be trivial to implement), incentivizing chains to not produce blocks if they are not filled much or empty.

The second option is tempting, but also might lead to the network being more prone to fluctuations in availability/performance. We might end up oversubscribing the network, causing issues if multiple chains start producing more blocks at the same time. A similar concern exists now already with load per block, but the issue would definitely be amplified. Could be mitigated by making block price dynamic, but then we would more and more run into similar problems as smart contracts competing for resources on Ethereum!

This problem does not exist for the first variant (at least not for parachains): If there are lots of parathreads wanting to author a block at the same time, they are competing for their set of cores - hence the parathread block price would go up, but parachains would stay unaffected - which is exactly what we want and is one of the trade-offs between parathreads and parachains.

TL;DR, we should figure out:

  • How to fairly distribute order fees?
  • How to align this with parachains, in a way that people are incentivized to use the most applicable tool for the job?
  • How do we ensure validators stay profitable when scaling up?

Just some thoughts on my end, I am not too much involved into economic considerations, so please correct me if I got some aspect wrong.

*) Things are more nuanced, DOTs staked are also locked and removed from the market, but arguably easier to bring back than DOTs locked in a lively parachain.

@eskimor eskimor changed the title Parachain/Parathread incentivisation Design Parachain/Parathread incentivisation Feb 21, 2023
@rphmeier
Copy link
Contributor

rphmeier commented Feb 22, 2023

In that vein, it has been discussed: If we scale up more: More validators, more parachains .. then the amount of work for validators will increase, while compensation would not necessarily.

Let's keep this out of scope for now - more of a governance question than a protocol design question. Governance should not expose more execution cores than the amount that validators can sustain on their rewards. Better discussed on the forum than here.

@rphmeier
Copy link
Contributor

This means either that incentives should be aligned so that parathreads are way cheaper on average, if you are not going to have data for almost every block on your parachain - or alternatively we could also charge parachains per block (which should be trivial to implement), incentivizing chains to not produce blocks if they are not filled much or empty.

Isn't this covered by a minimum price for on-demand bids?

@rphmeier
Copy link
Contributor

rphmeier commented Feb 22, 2023

Hence it would make sense for at least the minimum order price to go to validators directly, instead of burning everything.

Ideally from my point of view that fixed amount should go to validators directly - not even to nominators, but directly on top of the commission. This is not strictly required, as at least in theory validators can customize their commission rate freely and thus adjust it to cover their operation costs anyways. (There are issues in practice, so adding order fees to commission directly might actually be very worthwhile.)

Partially burned, partially to treasury, partially to validators? The validators earn reward points for creating parachain blocks, and I don't see any reason why that isn't enough. The value of those reward points is determined by the market and the quantity is determined by governance. Any arbitrage or difference between mechanisms for assigning blockspace is something for the market and governance to handle as well, in terms of which mechanisms to use and how many cores to allocate to each mechanism.

I don't think that rewarding validators and not nominators is a good idea. Validators are only in the set because of their nominators, and if validators are rewarded but not nominators then the nominators take on slashing risk without the corresponding reward. That's a huge divergence from the status quo.

But let's imagine that on-demand prices become very high, and vastly exceed the value of the reward points that validators earn for some reason. This implies high sustained demand for blockspace and therefore the underlying token as well. That also would imply a high burn rate of tokens and high accumulation in the treasury, which means that governance could increase staking rewards without affecting overall inflation.

Another point is that it's only necessary to pay validators enough to do the job and take on corresponding risks. There is more value being created, for sure, but that is the value proposition of the network. The amount that validators need to be paid should be much less than the value created by the network.

To summarize, I'm in favor of a split of on-demand purchase tokens being split between burning and the treasury. Validators are paid out of new issuance. Trying to balance these competing goals should be handled by governance, not the treasury - it'll keep the code much simpler as well.

@eskimor
Copy link
Member Author

eskimor commented Feb 22, 2023

Thanks, makes sense!

@Sophia-Gold Sophia-Gold transferred this issue from paritytech/polkadot Aug 24, 2023
@eskimor eskimor closed this as completed Jan 25, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Completed
Status: No status
Development

No branches or pull requests

2 participants