mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-04-26 05:07:56 +00:00
Gav
162 lines
6.6 KiB
Markdown
162 lines
6.6 KiB
Markdown
# RFC-5: Coretime Interface
|
|
|
|
| | |
|
|
| --------------- | ------------------------------------------------------------------------------------------- |
|
|
| **Start Date** | 06 July 2023 |
|
|
| **Description** | Interface for manipulating the usage of cores on the Polkadot Ubiquitous Computer. |
|
|
| **Authors** | Gavin Wood |
|
|
|
|
|
|
## Summary
|
|
|
|
In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-4, it is necessary for the allocating parachain (envisioned to be one or more pallets on a specialised Brokerage System Chain) to communicate the core assignments to the Relay-chain, which is responsible for ensuring those assignments are properly enacted.
|
|
|
|
This is a proposal for the interface which will exist around the Relay-chain in order to communicate this information and instructions.
|
|
|
|
## Motivation
|
|
|
|
The overall motivation for splitting out functions from the Relay-chain onto System parachains is well understood. An well-understood interface is necessary for ensuring multiple chains are able to coordinate their efforts.
|
|
|
|
## Requirements
|
|
|
|
- The interface MUST allow the Relay-chain to be scheduled on a low-latency basis.
|
|
- Individual cores MUST be schedulable, both in full to a single task (a ParaId or the Instantaneous Coretime Pool) or to many unique tasks in differing ratios.
|
|
- Typical usage of the interface SHOULD NOT overload the VMP message system.
|
|
- Worst case usage of the interface MUST NOT cause the Polkadot system to fail.
|
|
- The interface MUST allow for the allocating chain to be notified of all accounting information relevant for making accurate rewards for contributing to the Instantaneous Coretime Pool.
|
|
- The interface MUST allow for Instantaneous Coretime Market Credits to be communicated.
|
|
- The interface MUST allow for the allocating chain to instruct changes to the number of cores which it is able to allocate.
|
|
- The interface MUST allow for the allocating chain to be notified of changes to the number of cores which are able to be allocated by the allocating chain.
|
|
|
|
## Stakeholders
|
|
|
|
Primary stakeholder sets are:
|
|
|
|
- Developers of the Relay-chain core-management logic.
|
|
- Developers of the Brokerage System Chain and its pallets.
|
|
|
|
_Socialization:_
|
|
|
|
This content of this RFC was discussed in the Polkdot Fellows channel.
|
|
|
|
## Explanation
|
|
|
|
The interface has two sections: The messages which the Relay-chain is able to receive from the allocating parachain (the *UMP message types*), and messages which the Relay-chain is able to send to the allocating parachain (the *DMP message types*). These messages are expected to be able to be implemented in a well-known pallet and called with the XCM `Transact` instruction.
|
|
|
|
Future work may include these messages being introduced into the XCM standard.
|
|
|
|
### UMP Message Types
|
|
|
|
#### `request_core_count`
|
|
|
|
Prototype:
|
|
|
|
```
|
|
fn request_core_count(
|
|
count: u16,
|
|
)
|
|
```
|
|
|
|
Requests the Relay-chain to alter the number of schedulable cores to `count`. Under normal operation, the Relay-chain SHOULD send a `notify_core_count(count)` message back.
|
|
|
|
#### `request_revenue_info_at`
|
|
|
|
Prototype:
|
|
|
|
```
|
|
fn request_revenue_at(
|
|
when: BlockNumber,
|
|
)
|
|
```
|
|
|
|
Requests that the Relay-chain send a `notify_revenue` message back at or soon after Relay-chain block number `when` whose `until` parameter is equal to `when`.
|
|
|
|
#### `assign_core`
|
|
|
|
Prototype:
|
|
|
|
```
|
|
type PartsOf57600 = u16;
|
|
enum CoreAssignment {
|
|
InstantaneousPool,
|
|
Task(ParaId),
|
|
}
|
|
fn assign_core(
|
|
core: CoreIndex,
|
|
begin: BlockNumber,
|
|
assignment: Vec<(CoreAssignment, PartsOf57600)>,
|
|
end_hint: Option<BlockNumber>,
|
|
)
|
|
```
|
|
|
|
Requirements:
|
|
|
|
```
|
|
assert!(core < core_count);
|
|
assert!(targets.iter().map(|x| x.0).is_sorted());
|
|
assert_eq!(targets.iter().map(|x| x.0).unique().count(), targets.len());
|
|
assert_eq!(targets.iter().map(|x| x.1).sum(), 57600);
|
|
```
|
|
|
|
Where:
|
|
- `core_count` is assumed to be the sole parameter in the last received `notify_core_count` message.
|
|
|
|
Instructs the Relay-chain to ensure that the core indexed as `core` is utilised for a number of assignments in specific ratios given by `assignment` starting as soon after `begin` as possible. Core assignments take the form of a `CoreAssignment` value which can either task the core to a `ParaId` value or indicate that the core should be used in the Instantaneous Pool. Each assignment comes with a ratio value, represented as the numerator of the fraction with a denominator of 57,600.
|
|
|
|
If `end_hint` is `Some` and the inner is greater than the current block number, then the Relay-chain should optimize in the expectation of receiving a new `assign_core(core, ...)` message at or prior to the block number of the inner value. Specific functionality should remain unchanged regardless of the `end_hint` value.
|
|
|
|
On the choice of denominator: 57,600 is a highly composite number which factors into: 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 5, 5. By using it as the denominator we allow for various useful fractions to be perfectly represented including thirds, quarters, fifths, tenths, 80ths, percent and 256ths.
|
|
|
|
### DMP Message Types
|
|
|
|
#### `notify_core_count`
|
|
|
|
Prototype:
|
|
|
|
```
|
|
fn notify_core_count(
|
|
count: u16,
|
|
)
|
|
```
|
|
|
|
Indicate that from this block onwards, the range of acceptable values of the `core` parameter of `assign_core` message is `[0, count)`. `assign_core` will be a no-op if provided with a value for `core` outside of this range.
|
|
|
|
#### `notify_revenue_info`
|
|
|
|
Prototype:
|
|
|
|
```
|
|
fn notify_revenue(
|
|
until: BlockNumber,
|
|
revenue: Balance,
|
|
)
|
|
```
|
|
|
|
Provide the amount of revenue accumulated from Instantaneous Coretime Sales from Relay-chain block number `last_until` to `until`, not including `until` itself. `last_until` is defined as being the `until` argument of the last `notify_revenue` message sent.
|
|
|
|
This explicitly disregards the possibility of multiple parachains requesting and being notified of revenue information. The Relay-chain must be configured to ensure that only a single revenue information destination exists.
|
|
|
|
## Performance, Ergonomics and Compatibility
|
|
|
|
No specific considerations.
|
|
|
|
## Testing, Security and Privacy
|
|
|
|
Standard Polkadot testing and security auditing applies.
|
|
|
|
The proposal introduces no new privacy concerns.
|
|
|
|
## Future Directions and Related Material
|
|
|
|
RFC-1 proposes a means of determining allocation of Coretime using this interface.
|
|
|
|
RFC-3 proposes a means of implementing the high-level allocations within the Relay-chain.
|
|
|
|
## Drawbacks, Alternatives and Unknowns
|
|
|
|
None at present.
|
|
|
|
## Prior Art and References
|
|
|
|
None.
|