Update polkadot.js UI for coretime

[seadanda]

• I'm submitting a ... Feature request

• What is the current behavior and expected behavior? The current UI does not have dedicated views for coretime. As a change in network architecture this should be reflected in the UI. More information below motivation.

• What is the motivation for changing the behavior? Coretime has been deployed on Rococo and Westend, and will soon be deployed on Kusama with Polkadot following in a few months. This is a permanent change to the network architecture and the way parachains obtain blockspace. The crowdloan/auction mechanism will no longer be used. Currently the dedicated tabs for Parachains do not reflect the new scheme and the only way to see parachains on cores or the coretime sales status is to poke around in the chain state on the coretime and relay chains.

More information

Currently in the Network->Parachains tab there are four tabs: Overview, Parathreads, Auctions, Crowdloans.

I would suggest as a starting point that the auctions and crowdloans tabs be removed, and the parathreads tab be changed to a parachains tab. (parathreads is no longer a relevant term). The following tabs might belong on the relay chains or coretime chains.

A rough structure could then be:

Overview

• Top level summary figures of current timeslice, region, sale and human-readable timelines
• Workload for current region
• Workplan for next region
• On-demand usage (probably better for an indexer or data tool)

Parachains

Registered parachains showing:

• parachain id
• whether they're on core or not, and whether that is via reservation, bulk or on-demand, and in the short term whether they are on a legacy lease (or a link to the coretime tab)
• if they are on bulk core whether they qualify to renew their core
• if they are on a legacy lease, the last region of that lease and when they can renew
• when they're next scheduled to be on core
• their last included block and when that was
• remove lease
• Remove auction/crowdloan tabs

Bulk sales

More details specifically about bulk coretime sale

• timeline including important points in time e.g. sale start, interlude, lead-in period, fixed price period, advance notice etc.
• list of regions
• details about current sale from sale_info e.g. number of cores for sale, sold and the prices/last price
• pricing information
• price projections for the next sale based on the number of cores sold and current last

On-demand

It's a bit harder to think of what to show here that isn't already on the overview

• number of cores in the pool
• price of on-demand
• queue status
• usage of on-demand as a percentage (might be better in indexer or data tool)

Additional functionality for the coretime chain

Adding UIs for the following most-used extrinsics at a minimum would be useful:

Core acquisition

• broker.purchase - buy a region for a maximum of the specified price
• broker.assign - assign a task to a core for a region that the origin owns
• broker.renew - renew an existing core for a task which qualifies (qualifying tasks listed in broker.allowedRenewals)

Region manipulation

• broker.partition - split an owned region in two around a point in time
• broker.interlace - split a region in two in a "you go I go" way
• broker.transfer - transfer a region to another owner

On-demand pool

• broker.pool - put a region in the on-demand pool
• broker.claimRevenue - claim revenue from on-demand pool after pooling your region of a core

On-demand acquisition

• broker.purchaseCredit - buy coretime credits on the relay chain

Storage management (free from any origin, but maybe not necessary for UI)

These could be listed from the chain state when past the point where they can be dropped and dropped in batches or one by one.

• broker.dropContribution
• broker.dropHistory
• broker.dropRegion
• broker.dropRenewal

This is just a starting point and by no means the best layout or content that we could have. All feedback and ideas are welcome!

[vyto2021]

It does make sense

[chungquantin]

Hi, is this issue open for outside contributors? I am really interested in contributing to this issue.

[seadanda]

I'm sure outside contributions would be very welcome, I'd advise maybe tackling this issue in smaller chunks to keep the core devs in the loop of where it's up to. @TarikGul any input?

[TarikGul]

I'm sure outside contributions would be very welcome, I'd advise maybe tackling this issue in smaller chunks to keep the core devs in the loop of where it's up to. @TarikGul any input?

I totally agree contributions are very welcome, that being said as you mentioned it would, and should be in small chunks.

Until finished it's probably best if it sits within some experimental tag, but also would require guidance from us as to what should be the order of operations in terms of tasks, and how it should be designed.

[chungquantin]

@TarikGul @seadanda Got it! So what should be a next step from my end. Should I break down the feature into smaller chunks or the core team will be the one who manages to do it?

[TarikGul]

@chungquantin Yea I will post a set of sub-tasks soon that can get done with the following issue. For now I am going to get it started by removing the Parathreads tab from the UI as requested from the core-team then we can work from there :)

Thanks for you patience.

[TarikGul]

For starters I am thinking we should instead have a Coretime (Experimental) where we can iterate on the new coretime UI without having to remove and play with any existing tabs (for now).

@seadanda Can you share with me a link to the new logic, and storage calls for parachains? Also what do you think about the idea above?

[seadanda]

Having an experimental tab sounds good. The other tabs are necessary until all chains upgrade to coretime. Rococo and Westend don't need them any more, Kusama should be upgraded soon, but Polkadot will need them for the next few months.

The storage calls are split between the Relay in the coretimeAssignmentProvider and onDemandAssignmentProvider pallets, and the broker pallet on the Coretime Chain. Bulk is sold, allocated, transferred etc on the coretime chain all through the broker pallet, so that's where you'll get all the pricing information and meta information from. The coreDescriptors and coreSchedules outline only what is running on each core, the mask and when, not how the coretime was purchased.

To list all parachains currently on a bulk core you need to hit the coreDescriptors on the relay, for future ones it's the coreSchedules. To find out the reason they have a core (reservation/lease/normal bulk) you'll need to check broker.reservations, broker.leases and infer that the remaining parachains on a core are "normal" bulk. You can check broker.regions to see what has been bought and what is yet to be allocated. Parachains who are allowed to renew are in the broker.allowedRenewals For on-demand you'll need to check on the relay chain in the onDemandAssignmentProvider onDemandQueue and paraIdAffinity. Currently the credits are unimplemented, but at some point in the future you should be able to check how many coretime credits a given account has. Currently they are just bought directly with the native token.

The sale structure and some other characteristics are defined in the broker.configuration. The prices of bulk coretime and other details for the current sale are in the broker.saleInfo but need to be partially inferred (e.g. if we're within the lead-in period the current price needs to be calculated according to the implementation in the PriceAdapter defined in the runtime.

I hope this helps. It's a complex change, so there's no real way to fully explain it in a comment, I think there's a lot more to be gained by poking around in the state of those three pallets:

• relay coretimeAssignmentProvider
• relay onDemandAssignmentProvider
• coretime broker

But I've tried to provide enough info for a start to be made.

I'm not sure I know what you mean about the new logic. Are you talking about the code for the extrinsics or some docs for something in particular?

[TarikGul]

@seadanda Thanks so much for the explanation its super helpful.

I'm not sure I know what you mean about the new logic. Are you talking about the code for the extrinsics or some docs for something in particular?

Yea for this i mostly meant where the code for the extrinsics and storage exists.

@bee344 is going to help out with the so we can prioritize it and help make progress.

[bee344]

@seadanda @TarikGul @IkerAlus So the current workplan is to split this into a few PRs, since it's a big task and to gather some feedback on the design and UX along the way. A new tab called Coretime (Experimental) will be added to the Network item, with the following labels:

• First, I'll do the Overview, since it appears the simplest in terms of functionality but I'm more worried about the appearance, so it'll be good to have it first and iterate on how it looks.
• Then, Bulk.
• OnDemand
• Parachains

At first, the Parachains name will be duplicated on the Coretime tab and in the Parachains tab itself, and it will be confusing, so I'm leaving that for last. The naming will work while on development, but I think we'll have to name it differently when it's ready for release, at least until we can get rid of the Parachains tab.

That's the plan for now, but it'll surely evolve as we get deeper into development.

[IkerAlus]

@bee344 I agree with the approach at high level. Let's focus on the overview tab first.

Afterwards, I think most of the Bulk and onDemand relevant info will be found in the Coretime Chain, hence, it may make sense to show this info only when connected to the Coretime chain, while the interface for the Relay chain is limited to current core usage and timelines. Tagging @seadanda in case my understanding is wrong.

[bee344]

@seadanda one question regarding onDemandQueue and paraIdAffinity: currently those are not in use, right? I'm not getting any info from those calls

[castleic]

I am not a professional developer but I think this feature should be implemented. That demonstrates the unique features of the network.