Implement Coretime credits

[bkchr]

The Broker pallet should be extended to support "Coretime credits". The idea behind Coretime credits is that they basically work like AWS credit or similar that can be handed out to people at hackathons etc. These Coretime credits can then be used to buy on-demand Coretime. These Coretime credits should be only redeemable for on-demand Coretime pool provided by the system, because normal users expect a revenue for their Coretime that they put into a pool. However, this would probably complicate the logic on the relay chain quite a lot as this is the point where these credits are redeemed. As these Coretime credits can be buyed from the system itself, we should be able to just take the money from the account holding these funds.

In the Broker pallet this will require to add some new dispatchable for buying credits with credits (best naming as always!) and then changing the following function:

polkadot-sdk/substrate/frame/broker/src/dispatchable_impls.rs

Lines 380 to 390 in 9db9211

	pub(crate) fn do_purchase_credit(
	who: T::AccountId,
	amount: BalanceOf<T>,
	beneficiary: RelayAccountIdOf<T>,
	) -> DispatchResult {
	T::Currency::transfer(&who, &Self::account_id(), amount, Expendable)?;
	let rc_amount = T::ConvertBalance::convert(amount);
	T::Coretime::credit_account(beneficiary.clone(), rc_amount);
	Self::deposit_event(Event::<T>::CreditPurchased { who, beneficiary, amount });
	Ok(())
	}

The Coretime chain will probably require the Asset pallet to hold these Coretime credits.

[eskimor]

On which core (system or user provided) does not matter. With RFC-1 you get a fraction of the revenue, depending on the size of your provided share of the pool cores. This also makes sense, as all cores are equal :-P It does not matter on which core it gets actually scheduled and indeed the on-demand assigner just picks the next suitable one (only taking into account occupation and core affinity).

[bkchr]

With RFC-1 you get a fraction of the revenue, depending on the size of your provided share of the pool cores.

Yes, but we also want (I think :P) that putting cores into the pool is paying back at least the costs of buying the coretime? I mean if we just take the costs from the account that sold the credits (as I said above), it should be fine.

[eskimor]

Yes, but we also want (I think :P) that putting cores into the pool is paying back at least the costs of buying the coretime? I mean if we just take the costs from the account that sold the credits (as I said above), it should be fine.

Not sure I am following, but let's set aside a few minutes tomorrow to discuss this.

[girazoki]

What would happen to unspent credits? Would I be able to redeem them again?

[bkchr]

Not sure I am following, but let's set aside a few minutes tomorrow to discuss this.

The point being that someone buys for example bulk coretime at the market. They split it up and put half of it into the on-demand pool. I mean they don't put it into the on-demand pool because they like Polkadot. They do this because they expect to see some revenue from doing this, at least "break even". I mean you can also argue that no one will buy your on-demand Coretime and you only make a loss. So, yeah, discussable.

What would happen to unspent credits? Would I be able to redeem them again?

When you have converted "registered" these credits in the coretime chain, they will be transferred to the relay chain. There you can only use them to get on-demand Coretime, nothing else.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/initial-coretime-pricing/5187/22

[seadanda]

I've made a start on a possible implementation of coretime vouchers. While doing it a few questions came up that would be interesting to hear people's opinion on.

I've given them an expiry so that unspent vouchers don't hang around in storage forever, but so far haven't put any limit on how far in the future the expiry can be. The funds for the voucher are kept in the broker pallet account for now, then when the voucher is exchanged, the original amount is sent from here to the relay account as usual.

I've wondered about the idea of unspent vouchers being refundable to the benefactor (the original person who purchased the voucher) if the owner (the person who receives the voucher) doesn't use it in time. This provides an incentive for them to clean it up, as well as an incentive to use it within a given time window - would be interested to hear people's thoughts on this. If we don't do this, what should happen to the unclaimed voucher funds?

I've implemented them directly in the broker, but could also take them out into their own pallet (except for the exchange extrinsic which exchanges them for coretime credits) if we want to keep things separate.

This all obviously depends on coretime credits being implemented first.

[Overkillus]

Current consensus is that the relay chain will use native DOT tokens for on-demand coretime purchases. Credits will be revisited when balances will move off the relay chain in the future. Until then this issue can be de-prioritised or closed.