-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add and configure asset registry pallet #276
Conversation
Pass the EnsureRoot to another type instead of implementing the whole trait
for all runtimes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally approve this PR, particularly how you define the configuration parameters of the asset registry pallet (especially the AssetProcessor
and the AuthorityOrigin
).
There is a minor comment I have with the organization of the pallets in construct_runtime
.
Another thought: this is the first time (?) that we add our own weights for pallets we use. There are some very small differences in the benchmarking results of these pallets for each runtime. I suppose that these are merely statistical deviations and the weights should actually be exactly the same for each runtime.
Would it be more reasonable to move our estimated weights for this pallet into runtime/common
and avoid all the duplication?
This will set the precedent for further additions of our own benchmarked weights.
It's actually the second time. As part of the v0.9.40 upgrade, @b-yap recently added custom weights for the XCM pallet, see e.g. here.
While I see your point with the assumption that the weights should be very similar, I think it would be dangerous to have one set of weights for all runtimes. Generally speaking we of course try to have similar configurations for all our parachains, but they are not perfect copies of each other. It might happen that one day, we change some configuration on Amplitude, that we don't change for Pendulum, which would then lead to different requirements/results for the generated weight.
Astar and Moonbeam seem to use the weights that are defined/exposed by the respective pallets and don't have any custom benchmarked weights. Thus, I would suggest that we generate the weights for each runtime separately. I think this topic is a little related to #178 although it does not align perfectly since the ticket is speaking about benchmarks for custom pallets, while we also consider benchmarks for non-custom pallets here. |
Okay, sounds reasonable. |
This is necessary to have the latest CustomMetadata
Adds the orml-asset-registry pallet to all runtimes. The
CustomMetadata
struct is defined in the spacewalk primitives and should be changed to something that suits our needs. It is still to be unclear what theCustomMetadata
should be, maybe we just keep it empty.Remaining TODOs
Notes
The benchmarking for the asset registry was adopted from here. You can find some context on the macros used in the benchmarks here.
The
AssetAuthority
is configured such that only the root user can register assets. Alternatively we could also give some pallets the permission to register these assets but we don't need this right now.Closes #275.