HF20 Update: Restoring Continuity
Hello Steemians, it’s been a long few days, but progress is being made and we wanted to provide you with the latest information on where things stand. We understand that people are very frustrated, and we want to assure you that we are working as fast as we can to return the blockchain to the expected level of usability. In this post, we will discuss the patches that we are planning to release tonight which will significantly improve the user experience on Steem, as well as our reasons for choosing this particular path.
We have been reviewing issues and developing patches as fast as we can, while evaluating the optimal path forward. The choices we’ve made have been driven by three priorities. The first is continuity. Steem users must be able to continue using the blockchain as we transition to a system that ensures fair pricing of resources based on proportionate stake. The second priority is minimizing disruption for businesses and exchanges. The third is ensuring that we can continue to make incremental movement toward the sustainable pricing of operations.
Based on our analysis, we believe the best path forward is to issue a series of patches tonight, the most significant of which will multiply the resource budgets by 10x. This should guarantee that users will be able to do around 10 times as many operations on the blockchain over the course of 5 days than they are able to now, although this could vary depending on the types of operations. Our #1 priority is continuity, and the root cause of the most glaring issues that users are facing is that the initial resource budgeting was far too limiting. Dramatically increasing the resource budgets is the fastest way to remove those limits and return users to the experiences they are accustomed to.
An added benefit of this path, as opposed to some of the other options we were considering, is that it would enable exchanges to get up and running as soon as possible. Because the RC plugin is non-consensus, any future updates to that system will likely not require replaying the blockchain, which means they would be able to maintain service throughout the process as we continue to make more updates.
At the same time, this solution leaves in place the RC system which is already providing us with valuable information about the real pricing of different operations. The strengths and benefits of the RC system remain too significant to risk losing. This path enables us to retain some of these advantages while restoring continuity for users. Due to the fact that many components of the RC system are non-consensus, we can continue to adjust the resource pool budgets, track trends, and adjust charges incrementally over time so that we can meet our third goal of moving us toward sustainable pricing of blockchain operations. This path grants us a degree of flexibility that we did not have with the previous bandwidth system.
What Happens Next
These patches will be going out later tonight, at which point we will immediately begin reindexing. That means within 24 hours witnesses can prepare to run the new code and deliver the improved user experience that Steemians want. It is ultimately up to the witnesses to decide whether the code is safe enough to use, however, one of the reasons we chose this particular path is due to the fact that simply multiplying the resource budgets by 10 is a simple fix, and with this simplicity, the code easy to audit. If they choose to adopt this change, user experience could begin improving as soon as tomorrow night. Other significant patches will be included that will address issues like accounts not having enough RCs upon creation and Steem Power delegation not immediately conferring mana. More details on these changes are included below.
We appreciate you all bearing with us through this challenging experience. No other community on Earth is trying to do what we are all trying to do together and it’s no mystery why: it clearly isn’t easy! Thank you all so much for your feedback and your patience.
Steem Blockchain Team
This is the draft for the 0.20.4 release notes.
Issues with fix included in patch 0.20.4:
- #2974 Parameters set too low, and many users are unable to transact
- The RC system constrained resources to too great of an extent
- We are adjusting parameters for minimal disruption
- #2968 Accounts at less than -100% RC cannot regenerate mana
- If an account was not able to get to positive RC within 5 days, it would not be able to do so at all.
- #2961 Powering up / delegating SP does not increase RC
- Bug: users powering up, were not able to vote/transact instantly
- Now, receiving SP gives an instant voting mana boost
- #2949 Voting power was not carried over properly at HF20
- Many had their voting power reset to near 0%
- No code change was made, but everyone's voting power will regenerate to normal levels within the next 3 days
- #2971 New accounts with 0 SP only have 3,000 RC
- This issue was a symptom of other issues that were addressed.
- #2942 New witness properties not returned from condenser_api
- The missing properties were added to the legacy API
- #2947 #2957 #2962 Condenser_api.get_accounts returning invalid voting_power values
- The compatibility layer for the old vote power API wasn't properly converting new mana to the older-style vote percent
- Caused irregular values to be displayed for user's current voting power, making it appear voting was buggier than it was
- Edge cases have been fixed, now fully compatible with old system
- #2953 Some accounts had negative resource credits at hardfork time
- Anyone with an active account prior to the hardfork had accumulated debt in the new calculations, unbeknownst to them.
- We reset negative value account to 0, so they can transact.
- #2958 Small accounts did not receive full mana upon the transition.
- All accounts supposed to have a minimum usable amount of RC
- This amount was calculated incorrectly, causing insufficient RC
- Now, most accounts will have a minimum 6M RC instead of 3,000 RC
- #2965 Require broadcasting nodes to have RC plugin enabled
- Using a non-standard configuration for broadcasting nodes could result in transactions not being rejected early
- To prevent configuration mistakes, RC calculations are enabled by default for any node which broadcasts transactions to the network