Hector Bulgarini SBP Milestone Review 2 #76
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HB Substrate Builder Program - Milestone Review
TIP (ternoa improvement proposals)
Very good job documenting your specs for every pallet! Those were very useful at the time of the review.
State machine for state updates and checks.
I have detected that in a few places there is most of the time similar checks like the ones below:
or
I understand that checks are not strictly the same over the different functions and states of the nfts, but at least it could be one new function that might check the verifications and in case there are specific checks, they could be conducted as follow:
(Checks and logic might not be the right one but you have the idea)
I think this might help to get all the rules in one function instead of going through different parts of the code for verifying the the state transition.
This same principle could be applied for pallet call where the logic structure seems to be the same across different pallets:
Anyway i would prioritize the checks over this last recommendation for calls since in a way the
NFTExt
in a way is defining a shared behavior over this interface. But maybe the extrinsics could be reviewed under this concept and avoid code repetition (not strictly necessary to implement, it could just work as inspiration).clone()
I detected that the project that are a considerable number of
clone()
s across the code base that can be removed.Some methods in the traits might accept references instead of values, avoiding unnecessary clones when the functions are called.
Hardcoded weights in weights.rs
Even if the benchmarking functions were developed the weight files are still using the
10_000
hardcoded values. Once the benchmark function is executed, the resulting weight file should be replaced so it is processing the weights values from the bechmarking.Old release.
Please take into account that the project is running a very old version of polkadot and substate. The latest release at the time of this PR is 0.9.42 and this code base is using 0.9.30.
Please follow the releases highlights in the Polkadot Release Analysis report for further details about migrations, breaking changes or new features:
https://forum.polkadot.network/tag/release-analysis
Weights v2.
Related to the previous topic when the release 0.9.38 is reached you might want to migrate to use weights v2 functions (
from_parts
instead offrom_ref_time
).I recommend going through the following PR to migrate into Weights v2 properly:
paritytech/substrate#11637
You might also consider creating a weights template like this one to have more control over the weights process generation coming from the benchmarking.