In our last blockchain update, we announced that we were making HF20 a priority. Since then, we’ve worked hard to accelerate the release. In today’s post, we will explore an especially important part of HF20: improving the bandwidth formula of the Steem blockchain.

Reforming the Bandwidth Formula

As explained in our previous post:

as we continue to scale the blockchain to more and more users, the bandwidth formula that we use to allocate resource usage across all of those users becomes increasingly important.

Move to Resource Credit System

To address this issue, we have completely rewritten the bandwidth system and created a new, state-of-the-art resource allocation system built around a new unit called “Resource Credits” (RCs).

This resource allocation system is the first of its kind in the blockchain / cryptocurrency space and will be the most advanced “freemium” blockchain model in existence.

RC Design Goals

Three primary design goals guided our development of the new bandwidth system. We wanted to create a system that 1) more efficiently allocates blockchain resources; 2) more accurately measures the true cost of running the blockchain; and 3) enables Steem developers to create more predictable user experiences.

Intelligent Resource Allocation

The most important goal of the resource allocation system is intelligent allocation of the blockchain’s resources. The more efficiently resources are allocated, the more user activity can be sustained. This is a critical component of scaling the blockchain. It is also critical that the system disincentivize the over-consumption of resources by users as well as spam.

Accurate Transaction Cost

Every transaction on the Steem blockchain has an associated “cost” in terms of the strain it places on the blockchain’s resources. For example, storing more data in the blockchain can eventually lead to higher RAM requirements for steemd nodes. Increased resource requirements can lead to higher costs for node operators (including developers, witnesses, and exchanges).

This is why it was critical that the blockchain calculate a transaction’s cost more accurately, based on as many factors as possible, and be empowered to limit which transactions can be performed based on their cost to the network.

These factors could include things such as:

• Blockchain history size
• Reindex time
• State file size
• Memory usage
• Disk iops
• Network bandwidth

Predictable UX

Under the current bandwidth system for Steem, users are given a certain number of “bytes” to use based on the amount of Steem Power (SP) they have. The blockchain reduces or increases the number of bytes they are given based on the activity occurring on the blockchain.

While this solution got us to where we are today, it confuses end-users by providing them with a purely binary choice: either acquire more SP, or be unable to transact on Steem. End-users cannot, for example, be told how much bandwidth they will receive from their purchase of more SP. The amount of bandwidth that a certain amount of SP is worth also changes constantly, depending on the activity level of the network. In other words, as the system stands, it is all but impossible for Steem users to form an accurate mental model of bandwidth.

Enabling the formation of a mental model is critical to satisfying our third design requirement: more predictable user experiences on Steem. The predictable model that will result from this new system will enable simple and effective feedback from user interfaces (UIs) to inform users about their RC usage, their remaining RCs, the cost of new transactions (measured in RCs), and options for purchasing additional RCs by powering up SP if they would like additional bandwidth.

Dynamic Cost Calculation

An important design principle carried over from the previous bandwidth implementation was that of dynamic costs based on the blockchain’s activity, as this is a very efficient system. Transactions should “cost” more during times when the blockchain is busy and less during times when it is not. However, as we’ve discussed above, this approach comes with certain downsides in terms of users being able to form a predictable mental model of bandwidth use.

The solution we propose in our RC system is to have a one-to-one correlation between the number of RCs one can get with a certain amount of SP, but at the same time have the costs of various transactions (measured in RCs) change based on the blockchain’s current activity level. The costs are determined based on an internal, market-based system, which is explained below.

Gamification

An added benefit of the new system is that it will further gamify the Steem experience. When a user can know how many RCs they will have, how long it takes for those RCs to recharge, and how many RCs each transaction will cost, they will be able to make informed decisions about how to spend their RCs.

While a primary objective for Steem is to minimize the cognitive load on users, this system will create new opportunities for developers looking to create more engaging applications. Developers will be able to provide interfaces that encourage their users to think tactically about how best to use their limited resources, because more granular data about resource consumption by individual users will be readily available. In addition, those users who may be inclined to over-consume blockchain resources (i.e. spammers) will be discouraged from doing so, as they will be shown very clearly just how much of their limited resources their efforts are consuming.

Maintaining a Frictionless Experience

It is important to reiterate that the appropriate baseline user experience for Steem is: as little friction and cognitive load as possible. We refuse to offer solutions that interfere with this principle. However, another important aspect of any protocol is that it be maximally flexible. Users who simply want to read a few posts, leave a few comments, and send some Steem should be able to do so with ease. But it is also our responsibility to consider the people who want a more active and gamified user experience, as well as those seeking to waste network resources. In a sense, we want Steem to be a game that everyone can enjoy playing, regardless of the type of user experience they prefer or their motivation for playing.

What are RCs?

The most important thing to understand about RCs is that they will be non-transferable credits given to each account based on how much Steem Power it has, which get “spent” whenever a user transacts with the Steem blockchain. Of course, if RCs did not replenish over time, then eventually everyone would become unable to transact at some point. For that reason, RCs regenerate over time.

Fueling Transactions

Once the RC system goes into effect, all transactions on the Steem blockchain will be given a cost in terms of RCs. If an account doesn’t have sufficient credits, the transaction will not be allowed to occur. This is the same as the existing system, which does not allow transactions to occur if the account does not have sufficient bandwidth.

Resource Budget Pools

The new system differs from the current one in the creation of “resource budget pools” which will be established for each resource type (RAM usage, reindex time, etc.). Each pool could be viewed as the blockchain’s “stockpile” of the corresponding resource. RCs will be the “currency” that the blockchain uses to price the resources in those stockpiles, and the internal medium of exchange for said resources.

Again, this is all happening behind the scenes and will require no conscious engagement by the user. It is simply a technical solution to the problem of maximizing the efficient usage of the computational resources available to the network in a scalable manner. Markets, after all, are arguably humanity’s most practical method of distributing resources among populations beyond the bounds of a small tribe.

Computing Price

The price of each resource will be based on the current level of the stockpile. As the stockpile decreases, the price of that resource (in terms of RCs) increases. In other words, as the stockpile goes down, accounts will have to pay more RCs to use the remaining resources.

Cost in RCs won’t translate into anything like a price increase in terms of STEEM or USD, due to the fact that RCs are non-transferrable. The goal is only to leverage a market system to ration resources, not to create speculative opportunities or manufacture another token that can be used to purchase goods or services.

Computing Cost

For each transaction, the System will statelessly compute a value and exchange rate in RC for resources like CPU megacycles, state memory, and history size.

From the github PR:

If CPU cycles cost 5 RC / megacycle, state memory costs 8 RC / byte, and history size costs 4 RC / byte, a transaction which takes 2 megacycles, creates 50 bytes of state, and has a 150 byte transaction size will cost 25 + 508 + 150*4 = 1010 RC.

• @youkaicountry

Technical Details

For those interested in the technical details behind the new RC Bandwidth system, more information can be found in our wiki article on RC-Bandwidth-Parameters.

Summary

These changes will lead to a far more pleasant, more transparent, and more predictable user experience across all Steem applications, and will more accurately allocate network resources by leveraging an efficient market mechanism.

Discussion Welcome

The RC System is only one aspect of HF20 that we have been hard at work on. Because it is a significant change and a dramatic improvement, we wanted to take this opportunity to thoroughly explore this issue with the community.

If you’d like to learn more about the RC System, or if you have any questions relating to it, please leave them in the comments section below.

Thank you for reading.

Steemit Blockchain Team