Code review of the new bandwidth system for HF20
In the newest update Blockchain Update 2: HF20 Progress & Bandwidth Changes, the new bandwidth system for Hardfork 20 is explained.
The remaining bandwidth is not measured in bytes, it will be measured in Resource Credits (RCs). Each account has a bandwidth which depends on the steem power as before. The unit is renamed to RC.
Instead of one bandwidth pool, several pools will be created which will be drained by broadcasted transactions differently. The current state of each pool determines the resulting costs of a transaction in RC.
If the account has more RC as the transaction costs it will be broadcasted and the bandwidth of the account is reduced by the RC costs.
Let's take a look on the current implementation in branch 2018-05-24-rc:
Three different rc_object_types are implemented
resource_history_bytes
resource_new_accounts
resource_market_bytes
Determining the resource_count of a transaction
tx_size
is the transaction size and it is now counted how many market operation and how many new account creation operation are included.
The transaction size is added to resource_history_bytes:
result.resource_count[ resource_history_bytes ] += tx_size;
A account_create_operation
or account_create_with_delegation_operation
increases
result.resource_count[ resource_new_accounts ] += vtor.new_account_op_count;
And a market operation as
- limit_order_create_operation
- limit_order_cancel_operation
- transfer_operation
- transfer_to_vesting_operation
increases addionally the resource_market_bytes
resource:
if( vtor.market_op_count > 0 )
result.resource_count[ resource_market_bytes ] += tx_size;
There will be eventually more operation added to the resource count of resource_market_bytes :
// TODO:
// Should following ops be market ops?
// withdraw_vesting, convert, set_withdraw_vesting_route, limit_order_create2
// escrow_transfer, escrow_dispute, escrow_release, escrow_approve,
// transfer_to_savings, transfer_from_savings, cancel_transfer_from_savings,
// claim_reward_balance, delegate_vesting_shares, any SMT operations
Estimating the costs
The cost of all three resource types is calculated by the resource_count array and summed up:
int64_t total_cost = 0;
for( size_t i=0; i<STEEM_NUM_RESOURCE_TYPES; i++ )
{
const rc_resource_params& params = params_obj.resource_param_array[i];
int64_t pool = pool_obj.pool_array[i];
int64_t cost = compute_rc_cost_of_resource( params.curve_params, pool, count.resource_count[i] );
total_cost += cost;
}
Increasing the RC usage by the estimated total_cost
The number of RC an account has is directly determined by its amount of vesting shares:
int64_t rc_max = account.vesting_shares.amount.value;
The available RCs are calculated by:
uint128_t regen_u128 = uint64_t(dt);
regen_u128 *= rc_max;
regen_u128 /= STEEM_RC_REGEN_TIME;
uint64_t regen = regen_u128.to_uint64();
rc_usage -= int64_t( regen );
int64_t rc_available = rc_max - rc_usage;
with
#define STEEM_RC_REGEN_TIME (60*60*24*15)
and the total_cost of the transaction are added to the usage
db.modify( rc_account, [&]( rc_account_object& rca )
{
rca.rc_usage = rc_usage + total_cost;
rca.rc_usage_last_update = gpo.time;
} );
Conclusion
At the moment, remaining bandwidth is renamed from bytes to RC.
Instead of one bandwidth pool, three recharging pool exists which influencing the transaction costs.
All transaction drain the first pool. Market transactions drain additionally the second pool. Account creation transactions drain additionally the third pool.
Market and account creation transaction will reduce the bandwidth of an account stronger than other transactions.
The number of RCs an account has is the number of its vesting shares. The RC regeneration rate is 15 days.
If you like what I'm doing, please consider @holger80 as one of your witnesses. You can use steemconnect.com for approving your vote or go to https://steemit.com/~witnesses and enter my name into the vote field:
Thank you Holger80 for giving us a clear explanation what changes are being made upon the network.