Automatic Decentralized instantaneous core acquisition

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:

  1. Purchase instantaneous core credits in the coretime system chain, which will allow you to send these credits to an account in the relay.

  2. 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.

  3. 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:

  1. Trustless: where there will be a bunch of de-centralized (rotating) collators that will be in charge of producing a block for your parathread

  2. 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.

  3. 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!


What errors are you expecting to handle? Just errors related to fees and weights? Without having a whole lot of context on the issue myself, and just based on your description, I find the second alternative far superior. If Tanssi is aiming to abstract away the complexities of buying cores and so on, all the while providing this decentralised network of Collators, Collators should interact with Tanssi’s parachain, where Tanssi can enforce its rules.

1 Like

The XCM option appears to be superior to the alternative. Addressing the drawbacks:

  1. Weights and fee conversions should be hardcoded based on the current values specified in the source code of the chains to know the execution cost beforehand. However, this introduces the challenge of keeping them up to date with new upgrades. Nevertheless, setting a sufficiently high weight limit is viable, as it won’t be charged if not actually spent. There are some project issues in the polkadot-sdk repo to solve this inconvenience.

  2. Tracking the execution, including the relay chain, is more problematic. One approach is to monitor the intended effects at the destination within a reasonable timespan, assuming an error occurred if not detected, potentially resulting in some distress like assets being trapped in the middle. Alternatively, tracking and correlating the entire XCM execution across the chains can provide a comprehensive view and easier troubleshooting (ideally with automated compensating actions), considering your scenario involves a single kind of “transaction” the scope is somewhat narrow. Still will require non-trivial efforts to be implemented.

Btw, we are developing a server (soon to be ready for production) to facilitate the tracking of XCM interactions. Maybe it could be of your interest:

1 Like