Carthage/mainnet runtime parameters#4341
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
bedeho
left a comment
There was a problem hiding this comment.
Fantastic job!
- Fees are a tad high, but it looks acceptable, thanks again for making this tool, it really makes a tremendous end-of-the-day sanity check.
- The automated fees were just fantastic. I'm slightly nervous about them not being
constbut I think it's worth it, I also secretly don't quite believe this actually breaks anything despite Parity saying so :D. - I think it would be great if we could try to isolate a few of these literal values, in particular tests, into named constants, so there is some separate space for comments and just more maintainable.
| use sp_std::mem::size_of; | ||
|
|
||
| /// Compute total fee for executing a call | ||
| pub fn compute_fee(call: Call) -> Balance { |
There was a problem hiding this comment.
This implementation looks right, but how did you arrive at this? did you extract the core logic of some other routines?
There was a problem hiding this comment.
So initially I was thinking about using TransactionPayment::compute_fee approach as described in #4300, but it had a few major drawbacks:
- The main issue was that it was reading a storage value (fee multiplier) which meant the result would change depending on it. This was very risky, because the runtime constants shouldn't change.
- It didn't work for genesis config values, only for the pallet's
Configtrait parameters
So I implemented the logic of TransactionPayment::compute_fee in this function while disregarding the fee multiplier (so assuming it's 1). The formula for inclusion fee is quite simple as it's just:
inclusion_fee = base_fee + length_fee + [targeted_fee_adjustment * weight_fee];
Source: https://docs.rs/pallet-transaction-payment/3.0.0/pallet_transaction_payment/
So if we disregard targeted_fee_adjustment (fee multiplier), it's:
inclusion_fee = base_fee + length_fee + weight_fee;
| pub const MaxThreadsInCategory: u64 = 20; | ||
| pub const MaxPostsInThread: u64 = 20; | ||
| pub const MaxModeratorsForCategory: u64 = 20; | ||
| pub const MaxSubcategories: u64 = 40; // TODO: adjust |
The considerable part of the cost of channel/video creation is a result of When it comes to inclusion fees, most of the cost is weight-driven. Notice in case of channels and videos we're using a worst case scenario number of storage/distribution buckets, the actual numbers may be much lower.
I think this is not a problem as long as the function that computes them doesn't depend on anything that may change over time. Currently the only way to make those functions (like |
Implements runtime parameters according to #4300 (proposal + discussion).
Monthly budget estimation for council:
$660,000Notable changes
max_piece_countparameter was set to40instead of100, as the value of100was causing one of the tests to fail withGenerated reward curve approximation is invalid: has more points than specified.RuntimeUpgradeWasmProposalMaxLengthwas set to 3 MB instead of 3.5 MB, asmega_bytesmacro doesn't support float valuesMissing parameter values
Those parameter values were not included in the original proposal:
contentstorageforumNote that the proposal assumes #4275 has been addressed, but it's not the case yet, so I left some of the values untouched, ie.:
There is also one new value that was introduced recently:
Current fees (examples)
Disclaimer: I was using the current weights, obviously the fees will be impacted once we re-generate weights using a proper setup.
addForumPostaddVideoCommentbuyMembershipcreateChannelcreateForumThreadcreateVideodeleteChanneldeleteForumPostdeleteForumThreaddeleteVideo┆Issue is synchronized with this Asana task by Unito