I’d like to present here the situation that we are going to face in Tanssi in a few weeks, once parathreads and coretime will be available in production. We are thinking about a couple of solutions to be able to cope with on-demand cores, and I would be happy to receive feedback on this.
As I understand it, the flow for acquiring instantaneous cores is going to be the following:
-
Purchase instantaneous core credits in the coretime system chain, which will allow you to send these credits to an account in the relay.
-
This account in the relay will be able to exchange these instantaneous core credits for an on-demand core, anytime a block needs to be produced.
-
The collator proceeds to create the block once it detects there is a core assigned to its parathread
At Tanssi however, we want to make the process:
-
Trustless: where there will be a bunch of de-centralized (rotating) collators that will be in charge of producing a block for your parathread
-
Simple: We want to abstract the complexity of going through the coretime system chain every time we need to create a block for a parathread.
-
Automatic: We want that if some very specific conditions are met (e.g., your parathread produced a block 1 hour ago, so it’s time to produce now)
We are debating between two options (but more suggestions are welcome):
Option 1::
One of the options that we are considering is making use of the proxy OnDemandOrdering. In this case the account which has the instantaneous core credits would need to have a proxy with the collator/collators so that these are capable of buying the on-demand core when needed. We see three main drawbacks here:
-
With rotating collators, a proxy would need to be set with all the collators or with an account controllable by all collators. Making the latter feasible and trustless seems difficult (as we likely cannot control whether the collator/collators will utilize the credits to buy for another parathread).
-
Collators are required to have a DOT-funded account (as they would still need to pay for fees to execute the tx)
-
Conditions upon which collators should buy the on-demand core are not verifiable in Tanssi until after the core is bought (meaning that we can slash them a posteriori, but we cannot prevent them from buying the core)
Option 2:
The other option we are considering is to control how and when collators buy the instantaneous core through XCM. In this case, instantaneous core credits would go to a (per-parathread) sovereign account controllable by the Tanssi chain itself. Collators, when they detect they need to buy the core they send a transaction to the Tanssi chain which itself sends a XCM to the relay chain to spend those credits. Some of the aforementioned drawbacks are solved with these approach because:
- in the Tanssi chain, we can control which collator is allowed to spend credits bought by a particular parathread.
- Collators are expected to have Tanssi tokens already (as they are staked), so no need to have a different account with DOT.
- We can verify the conditions upon which collators buy cores against rules defined in the tanssi chain.
The main issue we see here is the usage of XCM. Error handling is a bit more obscure in this case. In Tanssi we would need to be aware of fees and weights that executing the XCM message in the relay involves, which makes the whole process a bit more convoluted.
The purpose of this post is to discuss the viability of the solutions aforementioned proposed and hopefully get a better understanding of how coretime and on-demand cores will play a role in Polkatot in the next months. Feedback is welcome!