You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
let negative = first_term.saturating_sub(second_term);
multiplier.saturating_sub(negative)
// despite the fact that apply_to saturates weight (final fee cannot go below 0)
// it is crucially important to stop here and don't further reduce the weight fee
// multiplier. While at -1, it means that the network is so un-congested that all
// transactions have no weight fee. We stop here and only increase if the network
// became more busy.
.max(Multiplier::saturating_from_integer(-1))
Which in short is
next = prev + (t1 + t2)
Then the gist of the fix will be:
if positive {
// Note: this is merely bounded by how big the previous and the inner value can go,
// not by any economical reasoning.
+ let excess = first_term.saturating_add(second_term).saturating_mul(previous);- let excess = first_term.saturating_add(second_term);
previous.saturating_add(excess)
} else {
// Defensive-only: first_term > second_term. Safe subtraction.
+ let negative = first_term.saturating_sub(second_term).saturating_mul(previous);- let negative = first_term.saturating_sub(second_term);
previous.saturating_sub(negative)
// despite the fact that apply_to saturates weight (final fee cannot go below 0)
// it is crucially important to stop here and don't further reduce the weight fee
// previous. While at -1, it means that the network is so un-congested that all
// transactions have no weight fee. We stop here and only increase if the network
// became more busy.
.max(Multiplier::saturating_from_integer(-1))
}
And fixing a number of tests. I already started with this and there's a problem: Given the default parameters here, if we let multiplier go down to 0, then it will never recover, and it is unclear how to do this.
Moreover, the research says that the ratio should be computed only from the normal transaction types, with respect to the normal limit. We don't do this now and this needs fixing as well.
When applying the multiplier, we apply this +1 (multiply_accumulate) jumbo mumbo that is quite unnecessary in my opinion given the fix.
The text was updated successfully, but these errors were encountered:
kianenigma
added
I3-bug
The node fails to follow expected behavior.
U1-asap
No need to stop dead in your tracks, however issue should be addressed as soon as possible.
labels
Jun 11, 2020
The current weight multiplier implementation is unfortunately wrong. From the research page we have:
Assuming:
This is in short:
While our implementation does:
substrate/bin/node/runtime/src/impls.rs
Lines 82 to 96 in 606c56d
Which in short is
Then the gist of the fix will be:
And fixing a number of tests. I already started with this and there's a problem: Given the default parameters here, if we let multiplier go down to 0, then it will never recover, and it is unclear how to do this.
normal
transaction types, with respect to the normal limit. We don't do this now and this needs fixing as well.+1
(multiply_accumulate
) jumbo mumbo that is quite unnecessary in my opinion given the fix.The text was updated successfully, but these errors were encountered: