As the release of Hardfork 20 draws near, the Blockchain Team would like to take this opportunity to explore some of the progress we’ve made toward implementing our new Resource Credit (RC) system.
Steem is one of the few blockchains that operates under a “freemium” model, meaning that the blockchain enables its account holders to perform a certain amount of transactions “for free” as long as they have a sufficient amount of stake in the form of Steem Power. This new RC system will make Steem the most advanced freemium blockchain in the world.
As we discussed in a previous post, the purpose of the RC system is 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.
The first step toward achieving this was to settle on a definitive list of resource types and to develop strategies for implementing them. After performing a thorough analysis of the available options, we arrived at three RC types: blockchain size, state size, and computational load.
To understand why these were chosen, we will explore how the RC system is supposed to work. Actual measurements of these properties will not be constantly computed, as this would place exceptional demands on blockchain infrastructure. It would be self-defeating to create a resource management system that itself placed an unreasonable demand on the system’s resources.
Instead, the goal is to generate stateless estimates that are proven to closely correlate to actual measurements as established by a regression analysis. Our analysis has concluded that blockchain size, state size, and computational load are the most promising types.
The current bandwidth algorithm essentially makes the assumption that all physical resources are correlated to one resource type: transaction size. As you can imagine, this is an incredibly inexpensive computation for the blockchain to process. However, as we explained in our previous post on Resource Credits, there are many downsides to the simplicity of this model, including the likelihood that it is not especially efficient at calculating a transaction’s “true cost.”
The new system will make the assumption that all physical resources are correlated to the three aforementioned types (blockchain size, state size, computational load), as opposed to transaction size only. Much like the current system distributes bandwidth, the blockchain will then generate RCs based on its stateless estimates of each resource, and distribute those RCs to Steem account holders based on their stake. Then it will calculate the cost (in RCs) for each transaction based on the remaining availability of those resources.
Our goal is to create a more efficient and accurate system that enables Steem developers to create more predictable user experiences. Our research concluded that the three resource types discussed herein meet these objectives. Therefore, their inclusion in the RC system will maximize our odds of meeting those objectives. While Steem is already the best blockchain protocol for powering real-time dapps, this new RC system based on blockchain size, state size, and computational load, will make it even better.
One final feature of the new RC system will be its flexibility. The system is designed to enable Steem blockchain developers to add new resource metrics to the calculation if doing so will further the objective of more efficiently allocating blockchain resources.
While Steem is arguably the fastest evolving blockchain—with 19 Hardforks successfully completed—the RC system included in Hardfork 20 will enable us to improve it even faster.
Blockchain Team
As many of you have already heard, Steemit is hiring. If you’re a talented software engineer who loves the challenges of building cutting-edge dapps for cryptocurrency (and especially for Steem), then we want to hire you.
More information can be found in this recent post or on our jobs site: https://jobs.lever.co/steemit.
