Steem: Change Bandwidth Reserve Ratio Algorithm

[mvandeberg]

Currently the reserve ratio decreases too quickly (can only decrease by half) which results in a sawtooth pattern at equilibrium.

Instead, we propose changing the reserve ratio as a function of the distance between the average block size and 25% of the max block size.

Long term, the desired block size should be independent of the max block size, but that will require another witness parameter to vote on and we want to get this change out asap.

Once a minute the reserve ratio will be adjusted based on the distance from 1/4 of the max block size (normalized to 1/4 of the max block size).

distance = |( average_block_size - ( max_block_size / 4 ) ) / ( max_block_size / 4 )|

Then, the reserve ratio will be adjusted up or down by reserve * distance / (distance + 1). At most, the reserve ratio can decrease to 1/4 the current value (when average block size is the max block size) and can increase to 3/2 the current value (when the average block size is 0). Most cases, the average block size will be close to 1/4 the max block size and the adjustment will be small in either direction.

This satisfies the original design goal of aggressively decreasing the reserve ratio under high use to prevent spam as soon as possible but allows for fine adjustments when the average block size is not changing over time.

[4Ykw]

@mvandeberg will this help low SP users to have a bit more chance for voting?

[mvandeberg]

Yes, because the current algorithm is too aggressively increasing SP requirements for sustained usage. We are not concerned if low SP users are prevented from voting or posting once and a while. But they should be able to log in for 30 minutes, comment and vote on some things and not worry that they will run out of bandwidth.

Before we release this new algorithm we will do some comparative analysis between both algorithms to verify that it fixes the immediate problem.

[rychardemanne]

Many thanks. Do you have a tentative timescale, assuming the analysis is positive?

[mvandeberg]

This will be included in 0.19.1. We are aiming to have a prerelease branch up asap.

[rychardemanne]

Are there any other changes planned for 19.1?
BTW I spotted the reserve_ratio anomaly and been working to get witnesses to understand it and what they can do to attenuate user distress. I like algorithmic puzzles. Thanks again.

[mvandeberg]

Anything that has been merged to master since 0.19.0. I have not compiled the release notes for 19.1, but will do so before a tagging a prerelease branch.

[mvandeberg]

Your reasoning that bandwidth is to prevent the rewards pool from fulling draining is incorrect. The rewards allocation algorithm prevents that itself. Bandwidth is purely to prevent the blockchain from being spammed. Most chains rely on transaction fees. We don't specifically because we __don't__ want Steem to be pay to play. However, we cannot have a single rate that controls every account or else those that create multiple accounts would be at an advantage. The only logical choice to rate limit based on stake (Steem Power). This argument applies to other aspects of the Steem blockchain as well.

[mvandeberg]

Understandable. Steem has a lot of moving parts. I do not try to reprimand, but educate, on the ins and outs of Steem.

[reggaemuffin]

This sounds like a reasonable fix. Great reaction.

I am currently trying to see how reserve * distance / (distance + 1) will ever increase reserve, as n / (n+1) for positive n is always < 1.

Can you link the branch/pr this gets worked on here, once it is started so we can review and discuss changes?

[mvandeberg]

This description of the algorithm is high level. Implemented, the sign of the distance is preserved. I am testing locally right now.

[mvandeberg]

Related #1250

[reggaemuffin]

Ahh that makes sense then. I'll review the code later today and see if I can find any problems.

[mvandeberg]

STEEMIT_MAX_BLOCK_SIZE * STEEMIT_MAX_RESERVE_RATIO * STEEMIT_BANDWIDTH_PRECISION * STEEMIT_BANDWIDTH_AVERAGE_WINDOW_SECONDS overflows 64-bits. We need to make the max_virtual_bandwidth calculations 128-bit.

[4Ykw]

Are we taking advantage of any AVX specific support on the code?

[theoreticalbts]

• The default value for current_reserve_ratio is 1, should this perhaps instead be RESERVE_RATIO_PRECISION?
• The API call implementation will return current_reserve_ratio = 1 if the index DNE, but throw if the object's not found. I think in both of these situations, returning a default value is better than throwing.

[mvandeberg]

It is unlikely that the index will exist and the object will not (it has the be the first time the plugin is loaded and has not yet received a block). Nonetheless, I am adding a check there to have consistent behavior in all circumstances.

I am changing the default value for current_reserve_ratio to 0 in the object because it is an impossible value when the reserve ratio is being tracked. It will act as a clear signal that the value is invalid.