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

Review Basilisk (SBP Milestone 3) #113

Closed

Conversation

apopiak
Copy link
Collaborator

@apopiak apopiak commented Jul 25, 2021

Review of the Basilisk runtime and included pallets for the Substrate Builders' Program Milestone 3.

Below is a summary of what I consider the most important points:

Runtime

  • make sure to generate weights
  • what's your dust management strategy?
  • you seem to have copied the Hydra pallets which IMO adds maintenance burden

pallet-asset-registry

  • don't use unwrap in the runtime
  • suggestion: check the genesis config for sanity

pallet-exchange

  • I don't think you cover the worst case for the on_finalize weight

pallet-lbp

  • some confusion about naming/semantics of pausing and pool activity

pallet-nft

  • mint is not marked #[transactional] but should be
  • benchmarking does not assume worst case

pallet-transaction-multi-payment

  • benchmarking does not assume worst case

@jak-pan
Copy link
Contributor

jak-pan commented Jul 26, 2021

Review of the Basilisk runtime and included pallets for the Substrate Builders' Program Milestone 3.

Below is a summary of what I consider the most important points:

Runtime

  • make sure to generate weights

In progress

  • what's your dust management strategy?

We are developing pallet-duster #104 please feel free to comment / review on it @enthusiastmartin if ready.

  • you seem to have copied the Hydra pallets which IMO adds maintenance burden

We did this because basilisk is being audited and we'll be removing them from HydraDX soon.

Others 👍🏻 on it.

@@ -446,6 +450,7 @@ impl cumulus_pallet_parachain_system::Config for Runtime {
type OnValidationData = ();
type SelfParaId = ParachainInfo;
type OutboundXcmpMessageSource = ();
// REVIEW: I'd understand holding off on XCMP, but you're not even handling DMPs, why?
Copy link
Contributor

Choose a reason for hiding this comment

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

It's wip #114

type WeightInfo = ();
}

parameter_types! {
pub const CouncilMotionDuration: BlockNumber = 5 * DAYS;
pub const CouncilMaxProposals: u32 = 20;
// REVIEW: What's the use of having a council of one?
Copy link
Contributor

Choose a reason for hiding this comment

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

We'll be increasing it after the chain runs.

@@ -504,7 +505,9 @@ pub mod pallet {

ensure!(pool.paused, Error::<T>::PoolIsNotPaused);

ensure!(Self::is_after_sale(&pool), Error::<T>::CannotUnpauseEndedPool);
// REVIEW: You want to ensure the pool is running, no? Or do you want to allow
Copy link
Contributor

Choose a reason for hiding this comment

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

we want to allow paused start -> docs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

sure, but the function did sth else AFAICT

Comment on lines +94 to +103
// REVIEW: You probably want to make sure the genesis config is sane?
assert_ne!(self.core_asset_id, self.next_asset_id, "core asset id needs to be unique");
// REVIEW: maybe even:
assert!(self.core_asset_id < self.next_asset_id, "core asset id needs to be unique");
CoreAssetId::<T>::put(self.core_asset_id);
NextAssetId::<T>::put(self.next_asset_id);
// REVIEW: Maybe track them in a btree-set? Might be overkill, not sure.
self.asset_ids.iter().for_each(|(name, asset_id)| {
// REVIEW: maybe:
assert!(asset_id < &self.next_asset_id, "asset ids need to be unique");
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, this pallet had the refactor coming for quite some time.

And now, we're completely reworking our asset-registry. It will include better handling of assets in genesis config too.

Comment on lines +28 to +29
# REVIEW: Seems like you copied the pallets from HydraDX node. Seems like a bad idea as it increases
# the maintenance burden.
Copy link
Contributor

Choose a reason for hiding this comment

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

This has been changed in HydraDX node repo. And now, the hydra repo uses pallets from Basilisk to remove the maintenance burden.

@@ -312,6 +312,7 @@ impl pallet_timestamp::Config for Runtime {
}

parameter_types! {
// REVIEW: How do you avoid dust?
Copy link
Contributor

Choose a reason for hiding this comment

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

Dust handling is done by pallet-duster and pallet-offchain-duster.

@@ -373,6 +376,7 @@ impl pallet_sudo::Config for Runtime {
}

parameter_type_with_key! {
// REVIEW: How do you plan on handling dust?
Copy link
Contributor

Choose a reason for hiding this comment

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

Dust handling is done by pallet-duster and pallet-offchain-duster.

Comment on lines +395 to +397
// REVIEW: I think you can avoid the allocation of the vec here if you use `take_while`
// https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.take_while
// on an iterator of the slice.
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks.
I finally refactored the matching part of the algorithm - using also your take_while suggestion. Also removed the unnecessary vec copy.

PR Here

Comment on lines +305 to +308
// REVIEW: I don't think one sell covers the worst-case on_finalize overhead.
// I would expect `resolve_matched_intentions` not to be called with just one intention
// because it's based on the matching. The on_finalize overhead of one sell should probably
// be based on max-buy-intentions already in the queue and vice-versa for one buy.
Copy link
Contributor

Choose a reason for hiding this comment

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

we will be refactoring the algorithm in very near future so that would be updated too. so leaving as is for now.

@enthusiastmartin
Copy link
Contributor

All review comments have been addressed and either fixed/changed or issue has been created to address it later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants