Agile Coretime

# Agile Coretime Deployment The following document intends to describe the open items in the transition from the auction based model to the new Agile Coretime model. **Technical topics to cover** 1. Ensure auctions until deployment. 1. OnDemandAssingmentProvider launch. 2. Deploy coretime parachain and mechanism on Rococo. 3. Migrate auctions to coretime. 1. Does the team need to execute the credits periodically? 2. What will happen with the locked funds? 4. Clarify mechanism to buy coretime from parachain. 1. Does the parachain sovereign account do this? 5. Parachain registration costs 6. Paid Runtime Upgrades 7. Understanding some cases 1. What happens if a chain bricks. Can they buy coretime and continue? 2. What happens if a chain runs out of coretime. 8. PolkadotJS support for AgileCoretime. **Business topics to cover** 1. Cost of coretime. 1. Comparisson vs auction model. 2. Aquiring mechanisms 1. From ethereum - Ben's idea. 2. using own tokens and swap them on AH. ## Technical Topics ### 1. Ensure auctions until deployment Current auction schedules on Kusama (last one begins on block 21_427_200, which should be around 14th of Jan) and Polkadot (last one begins on block 18_892_800, which should be around 8th of Jan) end on January. An auction schedule has been proposed on both Polkadot and Kusama to have two more LeasePeriods worth of auctions. This means approximately three more months of auctions scheduled for Kusama, and 6 more months on Polkadot. The proposal is for 7 auctions for each lease period, which allows for all teams that currently have a slot to renovate. All details can be found on [this spreadsheet](https://docs.google.com/spreadsheets/d/1BGjZlOdcj4Jmwn7AToByRVh54RW5s0Rpthj5M3jNoeY/edit#gid=1201445856). - Kusama's Proposal -> https://kusama.subsquare.io/referenda/320 - Polkadot's Proposal -> https://polkadot.subsquare.io/referenda/335 **OnDemandAssingment (prev Parathreads) launch** Before the launch of AgileCoretime, it is expected that the current module of OnDemandAssingment will be launched on both networks. This would mean that anyone wanting to validate blocks on a Relay Chain will be able to do so, in a similar way to how instantenous markets will work. This opens the following questions: 1. What's the best way for on-demand-parachains to regularly send extrinsics to the relay chain for allowing a block to be validate? 2. How many cores will be configured for this task? Currently there's only one on Rococo. 3. How does the pricing mechanism work? 4. Will this be deprecated when AgileCoretime is live? If so, is it needed? ### 2. Deploy coretime parachain and mechanism on Rococo It would be benefitial to have as soon as possible the coretime system chain together with the broker pallet deployed on Rococo or any other testnet that plays the role of a community testnet by then. This would allow for teams to understad how the mechanism will look like. Ideally, we can propose a way for teams to periodically consume AgileCoretime (see point 4) and to have them test this together with the migration (see point 3) to understand what to expect. ### 3. Migrate auctions to coretime. The migration should allow teams to have enough coretime credits to account for all the leases they currently hold. **Lease Periods vs Bulk** Currently a Lease Period on Polkadot is 1_209_600 blocks long, which accounts for approximately 3 months. A team can go for at most 8 Lease Periods, therefore maximum is 24 months. The [RFC proposal](https://github.com/polkadot-fellows/RFCs/blob/main/text/0001-agile-coretime.md#parameter-values) is for Bulk Coretime to be 28 days. This would mean that roughly one Lease Period would account for three units of Bulk Coretime. If a team has 4 Lease Periods left, will it then have 12 Bulk Coretime _credits_? If so, does the team need to activate this somehow? **Locked Funds** The proposed migration needs to clarify what will happen with the locked funds that currently exist under the auction model. This is important for both direct bidding and also for crowdloans. ### 4. Clarify mechanism to buy coretime from parachain It's clear that teams will need to purchase credits (bulk and/or on-demand) from the Coretime System Chain. However, teams will need to recurrently buy new bulk coretime, so they could potentially automate this. It would be ideal to provide a path for teams to do this, potentially executing an XCM message from the parachain to directly buy the coretime on the coretime parachain. Does this need to be from the parachain soverign account? Can any account do this on behalf of a paraID? The HydraDX team is the first one to [actually look into the problem of renewing from the parachain](https://hydradx.subsquare.io/posts/124) and figuring out a way of executing a governance call. Providing a guide on how to execute this would be great. ### 5. Parachain registration costs This is more than anything a problem for new teams versus existing ones. If the intent of Polkadot with AgileCoretime is to allow people from using the network, then the parachaian registration model needs to evolve to something cheaper. An initial discussion of the problem can be found here: https://forum.parity.io/t/dramatically-reduce-ksm-onboarding-costs/2150. Related to this is the idea of a rent-model, proposed on [RFC #44](https://github.com/polkadot-fellows/RFCs/pull/44). ### 6. Paid Runtime Upgrades With AgileCoretime it is expected to have a growth in parachain registrations. This can potentially bring issues if all parachains are upgrading together and sending all big POVs to the network at the same time. Therefore an idea is to have parachains pay for the runtime upgrades. A proposal for this can be found here: https://github.com/paritytech/polkadot-sdk/pull/2372. This needs to be communicated very clearly to the ecosystem, so that everyone knows what to expect. ### 7. Understand some cases The folllowing is more a list of open questions rather than anything else. However, these might help showcase the new model. 1. What happens if a chain bricks. Can they buy coretime and continue? Potentially, a team could register a new chain using the latest head on their bricked chain, re-buy coretime, and continue producing blocks. If it is as easy as described, then detailing this process a bit more could be extremely interesting as a way of selling the flexibility of this model. 2. What happens if a chain runs out of coretime. Of course the straig out answer is that they can't validate more blocks of their parachain. Now the question stands on if this is something we want to look into for special cases or not. Initially my opinion (Santi) is that the market should solve this, and eventually projects will be built for teams to crowd-get coretime. ### 8. PolkadotJS support for AgileCoretime. For Auctions and Crowdloans, the PolkadotJS Team (Jaco) build special UIs. The ecosystem will expect a tool to interact with the new AgileCoretime model, and the initial expectation will be that this exists on PolkadoJS. Given the uncertainty on the development of the tool, it'd be interesting to have a discussion on how to tackle the problem, specially if providers are needed ASAP to build this functionality. ## Business Topics ### 1. Cost of coretime Currently teams use the auction model to get the right to validate blocks on the relay chain. They can do this by either self-bidding or using crowdloans to get the community to help out. Funds get locked for a duration between 1 LP and 8 LPs, being 8 LPs the most common option. Therefore, the cost of validating blocks on the relay chain today is the oportunity cost of the locked tokens for the parachain team. On top of this, they only require the liquidity every 2 years (on Polkadot). > Add the math on how much teams paid for 2 years of continuos validation. For example, Acala locked 32_515_980 DOT for 2 years, meaning that the Oportunity cost was (considering 14% staking rewards) 32M * 0.14 * 2 = 9M DOT. A coretime equivalent would be 9M / 24 = 379k DOT. Current avareage is more on the 150k DOT, which would mean a coretime equivalent of 1750 DOT. With the new AgileCoreitme model we need to get a deeper understanding of: - the cost of cores. - the availability of cores. ### 2. Aquiring mechanisms There are two very interesting aquiring mechanisms that could spark activity within Polkadot. I'd propose to build two case-projects of these two so that teams could leverage from them. 1. Parachain team using own tokens to swap on AH and then buying coretime. 2. Parachain team using ERC-20 tokens on Ethereum to bring trough Snowbridge, swap on AH and then buy coretime. --- ## Launching Checklist ### Development - [ ] Finish Audits - [ ] Paid runtime upgrade mechanism -> https://github.com/paritytech/polkadot-sdk/pull/2372 - [ ] Coretime Credits -> https://github.com/paritytech/polkadot-sdk/issues/2998 - [ ] Double-check weights ### Ecosystem - [ ] Core Price definition - [ ] Full understanding on parachains story -> leverage https://github.com/paritytech/trappist/issues/321 - [ ] Get guides done (what is coretime, how the mechanism works, how will the transition work) - [ ] What is Coretime - [ ] Transition from Auctions to Coretime - What to expect. - [ ] Coretime parameters on the relay chain. - [ ] How to understand Coretime storage items for parachains - What does each thing mean? (e.g. tasks vs paraID) - [ ] Core architecture: regions, splitting, etc. - [ ] Coretime buying process: bulk period, lead-in period, interlude, purchasing period, curves. - [ ] Buy coretime with DOT from parachain. - [ ] Buy coretime with parachain tokens - Leverage Asset Conversion/HydraDX. - [ ] Coretime credits -> https://github.com/paritytech/polkadot-sdk/issues/2998 - [ ] New runtime upgrade mechanism - [ ] Registration costs -> https://github.com/polkadot-fellows/RFCs/pull/44 ### Marketing - [ ] Landing Page - [ ] Communication plan - [ ] Wiki publication ### Others - [ ] FrontEnd support for Coretime. Will PolkadotJS deprecate auctions? Will it support Coretime? Find a new provider to create a UI? - [ ] Bricked chains story: do we want to say that if a chain bricks they can get a new core and resume block production from their previous state? Is that something we want to promote? ### Deployment - [ ] Fellowship release - [ ] Prepare Relay chain runtime upgrade - [ ] Prepare Coretime parachain deployment (will it be from seedling?) - [ ] Governance proposal: one for runtime upgrade and one for coretime deployment? - [ ] Depending on timing, governance proposal should cancel ongoing auctions too. --- ### Open Questions **Async backing (adding here as its part of the launch plan request)** - Should success be in communication with the Parachains around migrating to async backing? - Should we be tracking progress in terms of its implementation on Rococo Parachains? **Coretime** - **Kusama Launch:** When is the Kusama launch targeted? - Is there a cut of the runtime that is currently being considered - Are we tracking specific PRs with Security / audit timelines? - **Polkadot Launch:** When is the Polkadot launch targeted? - Is there a cut of the runtime that is currently being considered - Are we tracking specific PRs with Security / audit timelines? - **Infrastructure:** - For the coretime chain, who is running the collators / assumption: Parity, if so are we coordinating with DevOps in terms of spinning up the collators / timeline. - **Documentation:** - Emiliano’s guide seems reasonable from a developer learning perspective. - Would requesting a streamyard video in collaboration with DevRel be useful? - **Pricing:** Is it reasonable to assume that price per core will be 200*$7=$1,400 per 28 days? - What are the upward pressures on this price other than number of cores available / demand? How does pricing scale within the protocol? i.e. how does the "price function" work? - Do we want to build a simple cost calculator for it to simulate the pricing under different assumptions? - Frequency pointed out that in order to do a truly accurate price comparison to auctions one would need to NPV the costs. - **Tooling:** - **Coretime-buyer-pallet:** Is this something we want built at Parity? - Note that: if the method for automating coretime purchases is on the Parachain and it runs out of coretime, manual intervention would be required. - **Coretime Bot:** Frequency are considering a bot versus a pallet in the future for managing their coretime e.g. a bot with access to a wallet with some funds - **Dashboard / Alerting:** Should we have monitoring on the coretime status of parachains / alerts if a chain is going to run out? - **Coretime Staking (from Steve):** - Potentially have a dapp or implementation whereby a Parachain team can buy and stake DOT (or naive token?) and use the rewards to pay for coretime on a sustainable basis. - **Subscan:** Do we need to confirm with them that they will integrate with the Coretime chain? - **Ecosystem Feedback:** - Have we engaged with Parachains to assess how they are considering implementing / managing the transition to coretime?