Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coretime auto-renew #4424

Open
wants to merge 33 commits into
base: master
Choose a base branch
from
Open

Coretime auto-renew #4424

wants to merge 33 commits into from

Conversation

Szegoo
Copy link
Contributor

@Szegoo Szegoo commented May 9, 2024

This PR adds functionality that allows tasks to enable auto-renewal. Each task eligible for renewal can enable auto-renewal.

A new storage value is added to track all the cores with auto-renewal enabled and the associated task running on the core. The BoundedVec is sorted by CoreIndex to make disabling auto-renewal more efficient.

Cores are renewed at the start of a new bulk sale. If auto-renewal fails(e.g. due to the sovereign account of the task not holding sufficient balance), an event will be emitted, and the renewal will continue for the other cores.

The two added extrinsics are:

  • enable_auto_renew: Extrinsic for enabling auto renewal.
  • disable_auto_renew: Extrinsic for disabling auto renewal.

TODOs:

  • Write benchmarks for the newly added extrinsics.

Closes: #4351

Copy link
Member

@eskimor eskimor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is the sovereign account of the para, why don't we implement auto renew on the para itself? Major reason, I guess: It would be impossible to mess up the timing. Otherwise each para would need to keep track of the sale cycle on Coretime.

substrate/frame/broker/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/broker/src/lib.rs Outdated Show resolved Hide resolved
substrate/frame/broker/src/lib.rs Show resolved Hide resolved
@Szegoo
Copy link
Contributor Author

Szegoo commented May 10, 2024

If it is the sovereign account of the para, why don't we implement auto renew on the para itself?

But what if the parachain has multiple cores assigned to it? For example, perhaps the parachain wants to keep renewing only one core but has acquired an additional core for this bulk period due to higher demand.

The reason I am storing the TaskId here as well is to avoid having to look it up for each core when performing auto-renewals.

@Szegoo Szegoo marked this pull request as ready for review May 17, 2024 08:25
@Szegoo Szegoo requested a review from a team as a code owner May 17, 2024 08:25
@Szegoo
Copy link
Contributor Author

Szegoo commented May 17, 2024

@eskimor I would appreciate a review to see if what I implemented here is sensible before writing benchmarks.

@Polkadot-Forum
Copy link

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/kusama-coretime-renewal/8219/1

@paritytech-review-bot paritytech-review-bot bot requested a review from a team May 23, 2024 09:15
@Szegoo Szegoo requested a review from seadanda May 27, 2024 08:05
@poppyseedDev
Copy link

Could you please explain why this PR wasn't addressed with the comment, "This is out of scope for the broker pallet," similar to how it was done in this PR: link to PR?

@seadanda
Copy link
Contributor

I think this PR is totally in scope for the broker pallet, renewals are a first-class operation supported directly on the coretime chain and this is a UX improvement for teams who want to renew regularly.
The PR you've linked introduces secondary market functionality directly in the broker pallet, which is not in scope for the coretime chain as defined in RFC-1. It's not that we're making arbitrary decisions about scope, if an RFC were to be accepted that defines the functionality in that PR then it would be a welcome addition

@seadanda seadanda added the T2-pallets This PR/Issue is related to a particular pallet. label May 30, 2024
Comment on lines 154 to 170
pub trait TaskAccountInterface {
/// The type for representing accounts.
type AccountId;

/// The overarching origin type.
type OuterOrigin: Into<Result<Self::TaskOrigin, Self::OuterOrigin>>;

/// The custom task origin. Given that all tasks on Polkadot are parachains this will most
/// likely be the `Parachain` origin.
type TaskOrigin;

/// Ensures that the origin is a task origin and returns the associated `TaskId`.
fn ensure_task_sovereign_account(o: Self::OuterOrigin) -> Result<TaskId, BadOrigin>;

/// Returns the associated account of a task.
fn sovereign_account(task: TaskId) -> Option<Self::AccountId>;
}
Copy link
Contributor Author

@Szegoo Szegoo May 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized we don't need this at all. We can deal with sovereign accounts just as simple signed origin so there is no need to use the parachains custom origin.

/// Sovereign accounts use the system's `Signed` origin with an account ID derived from the
/// `LocationConverter`.
pub struct SovereignSignedViaLocation<LocationConverter, RuntimeOrigin>(

This will simplify a lot of the code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK cool, I'll abandon my review for now then - I'm not all the way through but just have some comments

@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6355563

@@ -232,5 +260,7 @@ impl pallet_broker::Config for Runtime {
type WeightInfo = weights::pallet_broker::WeightInfo<Runtime>;
type PalletId = BrokerPalletId;
type AdminOrigin = EnsureRoot<AccountId>;
type SovereignAccountOf = TaskSovereignAccount;
type MaxAutoRenewals = ConstU32<50>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set this to at least the number of cores? Slightly lower might come back to bite us

// If we couldn't find the renewal record for the current bulk period we should
// be able to find it for the upcoming bulk period.
//
// If not the core is not eligable for renewal.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// If not the core is not eligable for renewal.
// If not the core is not eligible for renewal.

@@ -85,7 +85,7 @@ mod v2 {
};

#[storage_alias]
pub type AllowedRenewals<T: Config> = StorageMap<
pub type PotentialRenewals<T: Config> = StorageMap<
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your changes to this file were accidental - these should be reverted

pub struct AutoRenewalRecord {
/// The core for which auto renewal is enabled.
pub core: CoreIndex,
/// The task is assigned to the core. We keep track of it so we don't have to look it up when
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// The task is assigned to the core. We keep track of it so we don't have to look it up when
/// The task assigned to the core. We keep track of it so we don't have to look it up when

/// will be charged at the start of every bulk period for renewing core time.
///
/// - `origin`: Must be the sovereign account of the task
/// - `core`: The core for which we want to enable auto renewal.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// - `core`: The core for which we want to enable auto renewal.
/// - `core`: The core to which the task to be renewed is currently assigned.

Comment on lines 154 to 170
pub trait TaskAccountInterface {
/// The type for representing accounts.
type AccountId;

/// The overarching origin type.
type OuterOrigin: Into<Result<Self::TaskOrigin, Self::OuterOrigin>>;

/// The custom task origin. Given that all tasks on Polkadot are parachains this will most
/// likely be the `Parachain` origin.
type TaskOrigin;

/// Ensures that the origin is a task origin and returns the associated `TaskId`.
fn ensure_task_sovereign_account(o: Self::OuterOrigin) -> Result<TaskId, BadOrigin>;

/// Returns the associated account of a task.
fn sovereign_account(task: TaskId) -> Option<Self::AccountId>;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK cool, I'll abandon my review for now then - I'm not all the way through but just have some comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T2-pallets This PR/Issue is related to a particular pallet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Coretime auto renew
6 participants