generated from actions/typescript-action
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
183 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,183 @@ | ||
# 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, Robert Habermeier | | ||
|
||
|
||
## Summary | ||
|
||
In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-3, 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 background motivation for this interface is splitting out coretime allocation functions and secondary markets from the Relay-chain onto System parachains. A well-understood and general interface is necessary for ensuring the Relay-chain receives coretime allocation instructions from one or more System chains without introducing dependencies on the implementation details of either side. | ||
|
||
## 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. | ||
- 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`. | ||
|
||
The period in to the past which `when` is allowed to be may be limited; if so the limit should be understood on a channel outside of this proposal. In the case that the request cannot be serviced because `when` is too old a block then a `notify_revenue` message must still be returned, but its `revenue` field may be `None`. | ||
|
||
#### `credit_account` | ||
|
||
Prototype: | ||
|
||
``` | ||
fn credit_account( | ||
who: AccountId, | ||
amount: Balance, | ||
) | ||
``` | ||
|
||
Instructs the Relay-chain to add the `amount` of DOT to the Instantaneous Coretime Market Credit account of `who`. | ||
|
||
It is expected that Instantaneous Coretime Market Credit on the Relay-chain is NOT transferrable and only redeemable when used to assign cores in the Instantaneous Coretime Pool. | ||
|
||
#### `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 very composite number which factors into: 2 ** 8, 3 ** 2, 5 ** 2. 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_info( | ||
until: BlockNumber, | ||
revenue: Option<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, or zero for the first call. If `revenue` is `None`, this indicates that the information is no longer available. | ||
|
||
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. | ||
|
||
### Realistic Limits of the Usage | ||
|
||
For `request_revenue_info`, a successful request should be possible if `when` is no less than the Relay-chain block number on arrival of the message less 100,000. | ||
|
||
For `assign_core`, a successful request should be possible if `begin` is no less than the Relay-chain block number on arrival of the message plus 10 and `workload` contains no more than 100 items. | ||
|
||
## 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. |