Coretime Integration

[SBalaguer]

Motivation

With Coretime coming to Polkadot in the near future, it would be very good to see Trappist build the first implementation of a Parachain buying Coretime directly in a recurrent manner. This will be a key feature to release to the community so that all Parachains can use the reference implementation to recurrently buy Coretime.

The Coretime Parachain with the Broker Pallet is already deployed on Rococo.

Suggested Solution

I envision this integration in two phases. In any case, we are after an action done in a programmatic way of buying and consuming Coretime.

Phase 1: Using DOT
Any account controlled by the Parachain's Governance (could be the sovereign account of the Parachain on the Relay Chain or any other, would be interesting to discuss what the best approach is) that holds DOT and buys Bulk Coretime in a recurrent manner to ensure the operation of the Parachain.

Phase 2: Using Native Tokens
Any account controlled by the Parachain's Governance (could be the sovereign account of the Parachain on the Relay Chain or any other, would be interesting to discuss what the best approach is) that holds the Parachain's native token, swaps these for DOT (could be AH or any other Parachain) and use those DOTs to buys Bulk Coretime. This is done in a recurrent manner to ensure the operation of the Parachain.

Extra credit :p
This might not be suitable for Trappist, but I'll leave it here too. It would be interesting to design a mechanism buy which users holding ERC-20 tokens on Ethereum can buy Coretime through Snowbridge.

Additional Information

• RFC0001
• RFC0005
• Coretime Parachain
  • broker pallet
• AssetHub Parachain
  • asset-conversion pallet

[natalietill]

I like the Extra Credit bucket a lot. Making the transition from other ecosystems to Polkadot as seamless as possible.

[bkchr]

@metricaez what is the status of this issue?

[metricaez]

Hey @bkchr!

I have been documenting both my workplan, progress, questions and findings here.

TL:DR - I am trying to reproduce a whole life cycle of bulk time buy and renew in a local environment to build from there but I am not able to past through a workplan becoming a workload, therefore I am not able to renew,

There are also some behaviors that I don't fully understand which are also documented as questions on the Notion.

I have gone through resources, discussions and the broker pallet and smoke tests to elaborate this.

Any point I could get some support around this blocker would be much appreciated as I am clearly missing something (or many things) and I cannot project approaching a renewal from a programatic way or any further feature if I can't past through the fundamental use case.

Thanks!

[metricaez]

As an update, every issue flagged on the previous comment has been solved and the progress has been documented here.

Which leads to the following step which is implementing some kind of logic that synchs with Sales cycles of Coretime chain and tiggers in a recurrent way the renew extrinsic, as long it has funds.

I would like to breakdown the concept of "buy Coretime" in two possible actions:

• Purchase Coretime from scratch during a sale period to assign it to a parachain that is not producing blocks. This action must be done through a bootstrapping account since no execuction from the chain itself can be fired since it is not yet producing blocks.
• Renew for the next Region an already assigned Core, this means that the beneficiary Parachain would be already producing blocks therefore this can be done by an account controlled by the Governances body of the chain, being it's Sovereign Account on Coretime chain the most straight forward.

Assuming we are focusing on the second case as the first one is expected to be (at least as how the state of development is today) a one time thing action that can be done "manually", we should:

• Fund the Sovereign Account of Trappist in Coretime chain via an XCM Teleport from Rococo.
• Create some logic that synchs with the Coretime sales cycle and fires an XCM Transact that triggers the renewal on Coretime chain. This would succeed as long as Trappist Sovereign Account on Coretime chain has funds to pay for the renewal.

Both these processes are documented on the Notion, what is missing is the logic to automate them.

@SBalaguer does this work for you ?

Thanks!

[metricaez]

I see the "extra credit" being also implemented as follows:

1. HOP is teleported to AH
2. HOP is swapped for ROC on AH
3. ROC is teleported to Coretime
4. Renewal is payed on Coretime with ROC.

Everything nicely wrapped on a recurrent logic.

[Szegoo]

ATM the XCM Transact instruction is disabled on most parachains, including the Rococo Coretime chain(link). I opened an issue some time ago regarding this. Is the plan to have this filter removed soon?

[metricaez]

Hey! QQ, isn't the XcmExecuteFilter part of pallet-xcm and not of the Executor itself? This would prevent calling executions from Coretime chain but not the incoming Transacts fired from another chain.

Also this would match the behavior that I am obtaining on Local environment in which I am able to renew with an XCM message fired from Trappist.

Finally, this is a proposal from my side of how I would approach the issue which it doesn't mean it is the best way but I think that leaving renewals to governance bodies is a good practice and using Sovereign Account's as proposed is a quick (and already existing) way to do it.

[Szegoo]

isn't the XcmExecuteFilter part of pallet-xcm and not of the Executor itself? This would prevent calling executions from Coretime chain but not the incoming Transacts fired from another chain.

Yeah, now that I look at it more closely it seems like the Coretime chain is allowing calls to be made to the broker pallet link. Not really important, however, this makes me wonder why is local XCM execution disabled if we have the SafeCallFilter?

[ozgunozerk]

This issue is completed on the board, yet open in here. And there is no PR linked to the issue. Any clarification on this?

[the-right-joyce]

guide can be found here