Agile Coretime

[gavofyork]

This proposes a periodic, sale-based method for assigning Polkadot Coretime. The method takes into account the need for long-term capital expenditure planning for teams building on Polkadot, yet also provides a means to allow Polkadot to capture long-term value in the resource which it sells. It supports the possibility of building secondary markets to make resource allocation more efficient and largely avoids the need for parameterisation.

Implementation: https://github.com/paritytech/substrate/pull/14568

[lucasvo]

I believe this RFC makes transfer of regions lose the priority on core renewal but changing the allocation of the slot from one parachain to another does not. This would mean the system can quite easily be gamed to transfer ownership of a region without it being prevented from being renewed (for example by holding the region in a pure proxy and simply transferring ownership). Wouldn’t we want to tie the ability to renew to the paraid that the core is running and not which account controls the core?

[gavofyork]

I believe this RFC makes transfer of regions lose the priority on core renewal but changing the allocation of the slot from one parachain to another does not. This would mean the system can quite easily be gamed to transfer ownership of a region without it being prevented from being renewed (for example by holding the region in a pure proxy and simply transferring ownership). Wouldn’t we want to tie the ability to renew to the paraid that the core is running and not which account controls the core?

From the Renewals section:

[renew] has the same effect as purchase followed by allocate containing the same Vec<ParaId>...

Note containing the same [set of parachains]. This prevents transfer using proxies.

Transfer of regions would indeed lose renewal rights since the price information would be dropped. This is intentional. The point of renewals isn't to attempt to give as many entities as possible a discount for the next month: it's to ensure that committed teams get some guarantees about price for predicting future costs.

[lucasvo]

@gavofyork you write:

The point of renewals isn't to attempt to give as many entities as possible a discount for the next month: it's to ensure that committed teams get some guarantees about price for predicting future costs.

I think this point perhaps wasn't clear enough. Thanks for clarifying that this is implemented by having renew always allocate the core to the same ParaId. I would add a comment to renew section that points out that this is a specific design goal or highlight this in the problem statement.

[Tomen]

I submitted a proposal for dynamic pricing here:

https://forum.polkadot.network/t/dynamic-pricing-for-bulk-coretime-sales/3359

[gavofyork]

I submitted a proposal for dynamic pricing here:

https://forum.polkadot.network/t/dynamic-pricing-for-bulk-coretime-sales/3359

Perhaps consider opening an RFC.

[Tomen]

Perhaps consider opening an RFC.

Okay: #6

[Tomen]

I have discovered an edge case that I think is not covered for yet.

Let's say BULK_LIMIT = 50; BULK_TARGET = 35;.

A normal situation might be that we have 33 parachains that run on renewals. We are under the target and prices keep falling.

Now let's assume that 5 new parachains join and will buy renewals from now on forward. The result is a situation where renewal price increases are capped and the regular price rises at a faster rate, pushing the regular price up continuously without anyone actually paying at that price.

Governance might steer against this trend by bumping up the target, but there could be situations where that is not desired.

@gavofyork

[rphmeier]

Yeah, the pricing mechanism should account for the number of regions that are currently being priced lower than the "actual" price and avoid increasing in that case. We definitely don't want the "price" to skyrocket exponentially higher than what is actually being paid.

[gavofyork]

In the case that nothing is being sold at the nominal price then we can just keep it constant from last month.