Open seadanda opened 4 months ago
It does make sense
Hi, is this issue open for outside contributors? I am really interested in contributing to this issue.
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'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.
@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?
@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.
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?
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:
coretimeAssignmentProvider
onDemandAssignmentProvider
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?
@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.
@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:
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.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.
@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.
@seadanda one question regarding onDemandQueue
and paraIdAffinity
: currently those are not in use, right? I'm not getting any info from those calls
I am not a professional developer but I think this feature should be implemented. That demonstrates the unique features of the network.
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
Parachains
Registered parachains showing:
Bulk sales
More details specifically about bulk coretime sale
sale_info
e.g. number of cores for sale, sold and the prices/last priceOn-demand
It's a bit harder to think of what to show here that isn't already on the overview
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 pricebroker.assign
- assign a task to a core for a region that the origin ownsbroker.renew
- renew an existing core for a task which qualifies (qualifying tasks listed inbroker.allowedRenewals
)Region manipulation
broker.partition
- split an owned region in two around a point in timebroker.interlace
- split a region in two in a "you go I go" waybroker.transfer
- transfer a region to another ownerOn-demand pool
broker.pool
- put a region in the on-demand poolbroker.claimRevenue
- claim revenue from on-demand pool after pooling your region of a coreOn-demand acquisition
broker.purchaseCredit
- buy coretime credits on the relay chainStorage management (free from any origin)
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!