Today we would like to present our proposed upgrades to the blockchain protocol for the next hard fork release, 0.17.
KISS, short for Keep It Simple, Stupid, is the guiding principle behind most of the proposals. Simplicity is important for any system looking to gain widespread support and consensus via user adoption. By making the system simpler we minimize the potential for failure, maximize the potential for optimization, build a stronger case for fairness, and can more effectively communicate the system’s value to new participants. With that said, if the system can work without a feature then we propose to remove it.
Encapsulation / Isolation of Key Consensus Components
A second theme in the proposed changes is encapsulation / isolation of functionality by minimizing informational and/or ordering dependencies between different components of the system. In principle all posting and voting is fully independent of the currency with the single exception of the final payout. Also, voting on one post is almost fully independent of voting on every other post. By making some subtle changes to how transactions are processed we can enable major performance optimizations and massive parallel execution in the future. We will not be implementing the high performance / parallel version until necessary, but we want to ensure that the blockchain logic makes upgrading to higher performance code possible without another hardfork.
Separation of Blockchain Logic from Interface Requirements
A major source of complexity on the blockchain is the implementation of consensus features designed specifically for steemit.com. We feel the blockchain should be a neutral protocol that is as independent as possible from a web interface. This will ensure that the blockchain is a fair, equal opportunity platform that can support many different kinds of interfaces.
There are many examples of consensus logic being dictated by an interface concern. These include: comment depth, payout period, and edit limitations. Many of the things we will be rolling back were originally introduced in Hard Fork 0.12 and were never part of the original Steem design.
Simplifications
Removing Over Posting Reward Penalties
During the July rush we experienced a massive influx of people posting as much as they could to get as many rewards as they could. In an effort to curb this “abuse” we implemented a limit on the maximum reward a post could receive if the post made more than 4 posts in the same day. In hindsight this change was reactionary and ultimately unnecessary. It has the psychological impact of discouraging engagement and adds unnecessary complexity to a system. In the spirit of KISS we feel this should be removed.
Single Payout Period
Steem currently supports two payout periods: 24 hour and 30 day. The 24 hour payout period is weighted by the time votes were cast and could be up to 48 or more hours in some cases. The 30 day payout period was designed to catch votes/readers who were not around in the first 24 hours.
Based upon voting statistics, the vast majority of the 30 day payout comes from votes cast in the first week. We also know that there is little difference between weekly active users and monthly active users, especially among those with meaningful voting influence. It is our belief that authors (and curators) will earn more by a single 7 day (fixed) payout period than the combination of 24 (variable) and 30 day (fixed). A single vote on day 3 is worth much more to the author under this system than a dozen votes on day 3 under the old system due to the N^2 weighting algorithm.
The original 24 hour rule was an example of allowing the interface requirement for “fresh/trending” content dictate the blockchain logic. Interfaces, such as steemit.com or busy.org, can use any algorithm they want to select articles to display.
Some may ask why we don’t recommend making the voting period infinite and/or allow multiple payouts. The answer is two fold:
- Limited voter/community attention
- Scalability considerations
Users will be able to cast votes past 7 days, but those votes will not impact payouts. There are many other technical benefits from this change that enable parallel scalability, but that is a topic for github discussion.
One final benefit of a 7 day payout period is a reduction in variance. Under the current model, those who post the same day as an extremely popular post get much less. By spreading it out over 7 days, the extremely popular posts have less impact on other authors posting the same day.
Comment Payout independent of Discussion
At one point we had considered dividing the top post rewards among the comments. In a past hard fork we modified the payout algorithm to pay all comments at the same time as the parent post. This creates a tight coupling and minimizes the opportunity for a comment to get rewarded, especially if the comment was posted shortly before the post was paid.
Under the proposed changes, all comments and posts would be paid exactly 7 days after they were posted. This means comments have more time to gather votes and late commenters have a better chance. This change also facilitates massively parallel computation by eliminating sequential dependencies among posts and comments.
Removing the Comment Nesting Limit
Many people have requested the ability to reply with unlimited depth. The current comment depth limit was driven by the consensus calculations involving parent posts. With the proposed change to make all comment and post payouts fully independent of each other, we can remove the nesting limit. At the very least, it will be up to interface designers to determine the limit rather than the blockchain.
Allow Editing of any Past Post or Comment
We propose removing the restriction on editing of past posts. It is a user-interface responsibility to show revision history and enable restoration of unintentional changes made by compromised accounts.
Normalize Payout Rates
Under the existing rules, paying one post changes the potential payout of the next post. This introduces an undesirable sequential dependency among posts that prevents parallel execution of payouts. The proposed change would ensure that all posts paid out at the same time will receive the amount of STEEM per vote.
Removing Proof of Work
In our last update we attempted to move to Equihash as our proof of work algorithm, only to be bitten by a bug in the library we adopted. For most of the last month proof of work has not be a factor on the blockchain. Now that STEEM has been launched and distributed, there is no security benefit being provided by miners.
The proof of work difficulty has never been a factor in determining the best blockchain for consensus purposes and has solely been used as a means of distributing the currency in a manner that complies with U.S. regulations . Now that the currency is distributed there is no longer a need to perform this function.
Our long term roadmap includes multi-chain designs that will further render proof of work pointless and unnecessary baggage. Removing it will allow us to focus our development efforts on features that actually do matter.
Remove Bandwidth Rate limiting from Consensus
In an effort to simplify the core consensus algorithm, we will remove all code relating to bandwidth restrictions from the consensus code. Instead, the same algorithms will be implemented as a “soft” consensus by the witnesses. This means that any witness can include any transaction they like and it will no longer be considered invalid by the consensus rate limiting rules.
Witnesses can then adopt a more flexible policy toward rate limiting without requiring hard forks. In particular, we will utilize custom (non consensus) operations to inform witnesses of revocable bandwidth delegation. This will allow large account holders to sponsor smaller accounts without having to fund the smaller accounts with Steem Power.
Bandwidth rate limiting is a short-term consideration and ultimately irrelevant to the long term consensus. All that matters long-term is whether or not a transaction was included and that gets decided by the witnesses. Collectively the witnesses have the power to rate limit accounts to prevent abuse and they will apply the same algorithm they are applying with release 0.16.1.
After the above simplifications have been made, there are a few new features that we feel will help the ecosystem flourish.
Multiple Arbitrary Beneficiaries to Reward Payouts
For any given post there can be a half-dozen different people who have a financial interest in the reward. The include: voters, author, referrers, hosting providers, blogs that embedded blockchain comments, and tool developers. Whatever website or tool that is used to construct a post or comment will have the power to set how rewards from that comment are divided among various parties.
This means that if you post via Busy.org that your post will share some of its rewards with Busy. If you post through the various phone and/or desktop apps then the app developer will be able to claim some of the rewards.
Independent Comment Reward Pool
Comments have a very different level of visibility and therefore get considerably fewer votes. In the past month only 1% of rewards were paid to commenters. Due to the nature of the N^2 reward curve it means comments are not competing against other comments, but against the top bloggers.
We feel that engaging more people in discussion and encouraging higher quality comments will make the platform more desirable. While relatively few people want to blog, many more are interested in commenting.
If all comments only have to compete against other comments, then more users can participate and comments can collectively garner a larger percentage of the reward pool. We are proposing that comments be allocated 38% (golden ratio) of the current reward pool and that comments be rewarded on a N log (N) curve with some to-be-determined modifications. This should work to allocate more rewards to those who contribute to discussions and drive community engagement.
Separate Market and Rewards Balance from Checking and Savings
Currently rewards are paid as micro-payments into the "checking" balances. These micro-payments suffer from rounding errors and add tight dependency on the order of operations between rewards payment, market operations, and transfer operations. In order to support the goal of encapsulation we want to treat rewards and market operations as-if they were independent “side chains”. User rewards would accumulate in a fund which could periodically be claimed.
This change would have the impact of users seeing their rewards every time they choose to claim them while at the same time allowing exchanges to replay the blockchain without validating all of the voting operations. Advanced implementations could process the votes in parallel to transfers and/or market operations.
By separating market balances from checking balances we can accelerate the market evaluations and allow the market to be processed independently from transfers. Like voting, the idea is to view the SBD / STEEM market as a virtual “side-chain” that can be processed in parallel as the system scales.
Summary
We feel that these proposed changes will set the stage for a more flexible, modular, and simplified protocol upon which many different participants can build. Like always, the community will have the final say on what changes are adopted and which ones are rejected. Please provide your feedback below.
Note: this is not the 2017 Roadmap that we have been working on. That document is far broader and more comprehensive than this 0.17 “next step” plan. The full roadmap will include plans for steemit.com and other user-facing features.