CRT constraints and AMM benchmarks#4750
CRT constraints and AMM benchmarks#4750dobertRowneySr wants to merge 343 commits intoJoystream:crt_releasefrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
| /// - respective JOY amount transferred from amm treasury account to user account | ||
| /// - event deposited | ||
| #[weight = 100_000_000] // TODO: adjust weight | ||
| fn sell_on_amm(origin, token_id: T::TokenId, member_id: T::MemberId, amount: <T as Config>::Balance, deadline: Option<<T as timestamp::Config>::Moment>, slippage_tolerance: Option<(Permill, JoyBalanceOf<T>)>) -> DispatchResult { |
There was a problem hiding this comment.
This is good, timestamp info can be manipulated by validator node (https://neptunemutual.com/blog/understanding-block-timestamp-manipulation/)
There was a problem hiding this comment.
It doesn't look like the deadline was used for any purpose anyway, so it makes sense to drop it.
| pub const ProjectTokenModuleId: PalletId = PalletId(*b"mo:token"); // module: token | ||
| pub const MaxVestingSchedulesPerAccountPerToken: u32 = 5; | ||
| pub const BlocksPerYear: u32 = 5259600; // 365,25 * 24 * 60 * 60 / 6 | ||
| pub const MaxOutputs: u32 = 256; // TODO(Martin, Ignazio) : find a suitable value |
There was a problem hiding this comment.
Need a separate issue for:
- max patronage rate
- min amm slope
| min_revenue_split_duration: days!(21), | ||
| min_revenue_split_time_to_start: 0, | ||
| sale_platform_fee: Permill::from_percent(2), | ||
| max_yearly_patronage_rate: Permill::from_percent(5).into(), |
There was a problem hiding this comment.
no migration is needed for these parameters as they are new with V2002
There was a problem hiding this comment.
Ok it appears no (data) migrations are needed here on content pallet
| let config = GenesisConfigBuilder::new_empty() | ||
| .with_token_and_owner(token_id, params.build(), owner_id, supply) | ||
| .build(); | ||
| fn claim_patronage_ok_with_correct_credit_accounting_and_more_than_100_percent_supply() { |
There was a problem hiding this comment.
This also accounts for testing numeric precision, however there are several tests in the common/numerical.rs library for this
| const specVersion = block.runtimeVersion.specVersion | ||
| const [proposalId, generalProposalParameters, runtimeProposalDetails, proposalThreadId] = | ||
| new ProposalCreatedEvent_V1001(event).params | ||
| specVersion >= 2002 ? new ProposalCreatedEvent_V2002(event).params : new ProposalCreatedEvent_V1001(event).params |
There was a problem hiding this comment.
Should we update the mappings in order to account for the new update max yearly patronage rate proposal?
If so I need to open an issue about this
There was a problem hiding this comment.
Will it depends on when we decide to enable creating tokens, or start adding integration tests then yes we would need to update the mappings starting with handling new proposal type in parseProposalDetails()
[Argus] add auth options to elastic logs config
Update librocksdb-sys from v0.6.1+6.28.2 to v0.6.3+6.28.2
mnaamani
left a comment
There was a problem hiding this comment.
I left just an initial high level review, did not go into implementation details yet.
| min_revenue_split_time_to_start: 0, | ||
| sale_platform_fee: Permill::from_percent(2), | ||
| max_yearly_patronage_rate: Permill::from_percent(20).into(), // TODO: update, raising might make benchmarks fail | ||
| min_amm_slope_parameter: 10, // TODO: update, raising might make benchmarks fail |
There was a problem hiding this comment.
The default storage value set in project-token decl_storage macro is 15% for max_yearly_patronage_rate and 0 for min_amm_slope_parameter. In a runtime upgrade those defaults will be used because they are now being introduced in nara upgrade. If we are not happy with the defaults, we need to add a migration on_runtime_upgrade.
| const specVersion = block.runtimeVersion.specVersion | ||
| const [proposalId, generalProposalParameters, runtimeProposalDetails, proposalThreadId] = | ||
| new ProposalCreatedEvent_V1001(event).params | ||
| specVersion >= 2002 ? new ProposalCreatedEvent_V2002(event).params : new ProposalCreatedEvent_V1001(event).params |
There was a problem hiding this comment.
Will it depends on when we decide to enable creating tokens, or start adding integration tests then yes we would need to update the mappings starting with handling new proposal type in parseProposalDetails()
| FixedPointNumber, FixedU128, PerThing, Permill, Perquintill, | ||
| }; | ||
|
|
||
| pub const ORDER: usize = 20; |
There was a problem hiding this comment.
could you comment what this constant stands for?
| pub(crate) fn update_max_yearly_patronage_rate_proposal() -> ProposalParameters<BlockNumber, Balance> | ||
| { | ||
| ProposalParameters { | ||
| voting_period: days!(7), |
There was a problem hiding this comment.
voting and grace periods for testing,playground need to be much lower. See values for other proposals.
runtime/src/weights/block_weights.rs
Outdated
|
|
||
| //! THIS FILE WAS AUTO-GENERATED USING THE SUBSTRATE BENCHMARK CLI VERSION 4.0.0-dev | ||
| //! DATE: 2022-10-20 (Y/M/D) | ||
| //! DATE: 2023-05-11 (Y/M/D) |
There was a problem hiding this comment.
block, extrinsics and rocksdb _weights.rs should not be modified in this PR.
| // Storage: Token TokenInfoById (r:1 w:1) | ||
| // Storage: Token MinAmmSlopeParameter (r:1 w:0) | ||
| // Storage: System Account (r:1 w:1) | ||
| fn activate_amm() -> Weight { |
There was a problem hiding this comment.
perhaps we can keep only the new weight functions (and maybe issue_new_token which was modified) in this file and checkout all other changes.
We will do a final weight generation step before nara release.
| /// - respective JOY amount transferred from amm treasury account to user account | ||
| /// - event deposited | ||
| #[weight = 100_000_000] // TODO: adjust weight | ||
| fn sell_on_amm(origin, token_id: T::TokenId, member_id: T::MemberId, amount: <T as Config>::Balance, deadline: Option<<T as timestamp::Config>::Moment>, slippage_tolerance: Option<(Permill, JoyBalanceOf<T>)>) -> DispatchResult { |
There was a problem hiding this comment.
It doesn't look like the deadline was used for any purpose anyway, so it makes sense to drop it.
| // Creator tokens | ||
| const MAX_CRT_INITIAL_ALLOCATION_MEMBERS: u32 = 1024; | ||
| const MAX_CRT_ISSUER_TRANSFER_OUTPUTS: u32 = 1024; | ||
| const MAX_CRT_ISSUER_TRANSFER_OUTPUTS: u32 = 256; // same as in Token MaxOuputs |
There was a problem hiding this comment.
If it is a runtime constant, perhaps it can be read from the pallet instead of re-defining a separate constant and having to remember to keep them in sync?
Argus fix: Cache cleanup not working properly for objects in group `0`
Orion v2 docker setup
| pub const ORDER: usize = 20; | ||
|
|
||
| // does not work with 100% interest | ||
| pub fn natural_log_1_plus_x(interest: Permill) -> Perquintill { |
There was a problem hiding this comment.
I see this is not used expect internally from one_plus_interest_pow_frac so maybe keep it private?
Similarly for one_plus_interest_pow_frac.
If this function "does not work with 100% interest" would would the output be, and should we guard against invalid input?
| result | ||
| } | ||
|
|
||
| pub fn one_plus_interest_pow_frac(interest: Permill, exp: Perquintill) -> FixedU128 { |
There was a problem hiding this comment.
Can you add rust-doc just to show what is being calculated
|
|
||
| // Patronage | ||
| const DEFAULT_PATRONAGE: YearlyRate = YearlyRate(Permill::from_percent(1)); | ||
| const DEFAULT_SPLIT_ALLOCATION: u32 = 4_000_000; // DEFAULT_REVENUE_SPLIT_RATE * DEFAULT_SPLIT_REVENUE |
There was a problem hiding this comment.
Why not evaluate it as per commentDEFAULT_REVENUE_SPLIT_RATE * DEFAULT_SPLIT_REVENUE
There was a problem hiding this comment.
because DEFAULT_PATRONAGE: Permill and the multiplaction is a non constant operation, so rustc will throw error
| }) | ||
| .collect() | ||
| ); | ||
| let mut outputs = TransferOutputsOf::<T>::with_bounded_capacity((o + 1) as usize); |
There was a problem hiding this comment.
by adding + 1 are not going over the MAX_TX_OUTPUTS. range of o starts at 1, so I don't see the need to add +1 if we are concerned calling with_bounded_capacity with args 0..
| let approx = | ||
| Token::account_info_by_token_and_member(DEFAULT_TOKEN_ID, DEFAULT_ISSUER_MEMBER_ID) | ||
| .transferrable::<Test>(System::block_number()); | ||
| let target = 1000000181215750585898368181876; |
There was a problem hiding this comment.
I'm having a hard time accepting these pre-computed values.
| use crate::{errors::Error, Config, RepayableBloatBondOf}; | ||
|
|
||
| // trait "aliases" | ||
| // `BlockNumber` will be implemented as `u64` in the runtime configuration |
There was a problem hiding this comment.
The runtime implements BlockNumber as u32, not u64. Is this assumption here problematic?
There was a problem hiding this comment.
No, it should not. According to the trait
| provided_supply: Balance::zero(), | ||
| } | ||
| } | ||
| pub(crate) fn eval<T: Config>( |
There was a problem hiding this comment.
This seemed like a better place for the 'eval' implementation., but it was made into a standalone function in the content pallet. What is the reason behind this?
| impl Add for YearlyRate { | ||
| type Output = Self; | ||
| fn add(self, rhs: Self) -> Self::Output { | ||
| Self(self.0.add(rhs.0)) |
There was a problem hiding this comment.
should we be concerned with overflows?
| macro_rules! days { | ||
| ($a:expr) => {{ | ||
| hours!(24) * $a | ||
| ((24 * 60 * 60 * 1000) / ExpectedBlockTime::get()) as u32 * $a |
There was a problem hiding this comment.
mathematically it looks the same to me, is this implementation more accurate (due to integer maths?)
There was a problem hiding this comment.
this was in order to silence clippy, I will revisit
Co-authored-by: Mokhtar Naamani <mokhtar.naamani@gmail.com>
removed the warning to allow array construction and I used iteration utilities for array transversing
b84cea5 to
28e77ab
Compare
|
@ignazio-bovo should we close this PR, it was merged into nara if I'm not mistaken? |
fixes:
Resources and References: