Steem 0.17 Change Proposal Introduction
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.
Love single curation period idea! I posted something a while back expressing such hopes! https://steemit.com/steemit/@tingaling/steemit-7-day-curation-period-rather-than-the-current-quickly-passing-24-hours
See!? I told you it was just a matter of time. :)
The one change that stands out to me as a potentially bad idea is removing the four post limit/penalty. With auto-voting what it is today - and many of those auto-votes coming from large stakeholders - I think this would be a terrible incentive for anyone receiving auto-votes to post as much as they possibly can. This may sound like a good idea ("Alright! More content!"), but more isn't always better.
It could also reinvigorate the role of sock-puppets on the platform. This is something that hasn't been much of a problem lately, but could quickly and easily be renewed.
Just something to consider.
The market can adjust though. IMO, the limit is too arbitrary. And some folks are capable of putting out more excellent content.
When the authors that got votes from bots started abusing the power, the rest of community will likely stand out and start flagging, and it will ruin the author's rep. Given that we'll have 7 days to review, it's easier for the "good people" to react. I don't think a wise author will do so, unless she/he need quick money, or the account is compromised.
By the way, it's up to the bots to implement better voting algorithms. Most bots are voting for money, they have incentives to not vote for contents that will be mass-flagged.
With the cultural stigma of the downvote this kind of abuse hasn't been discouraged even with efforts from a minority. Your votes and Dans were the only ones that mattered and they were countered by other whales to keep the rewards high despite the abuse. I'm not sure those same whales will turn a new leaf if somebody like @ozchartart went from posting 4 times daily to 10+ times daily.
That you and others disagree and your point of view doesn't happen to prevail in one instance doesn't mean the system doesn't work. It works when stakeholders actually agree on what constitutes abuse. There is no objective definition.
That said, it also works to an extent even when there is disagreement, in the sense that incentives favor choosing content to upvote that won't be downvoted at all, whether or not the downvoters succeed in driving the post value all the way down to zero.
I will agree with you there. The risk of wasting voting power wouldn't be worth it when seeking ROI, particularly from curation, which is already not that high for most users.
The question is - what can be done when the abusers are actually the larger stakeholders, as was the case a few months back? The other large stakeholders mostly took no action. So, if there is no reaction and other stakeholders don't have enough power to make a difference, the abuse goes on unabated. I don't know what the solution would be, but having the post reward limits/penalties would at least be able to curb that.
What other back-end options do you think there could be that could address abuse vs. unwillingness/ineffectiveness to mitigate it on the front-end?
I would say the same stake-holders are still "pod voting" The accounts change, but the behavior doesn't. No changes to the system will stop a few accounts that vote for a handful of accounts each day.
Maybe the builders of the bots can build a feature where they can vote on some of their fav. accounts on odd days, and different accounts on even days.
Downvote, and it is still effective in shifting the incentives even if you aren't a larger stakeholder.
Consider a whale who has a choice of where to deploy one of his or her valuable and scarce 40 (full) votes per day. Choice A will get downvoted and Choice B will not. The incentives then favor B.
Unfortunately this isn't an instant gratification solution, but because it takes time for incentives like this to work, but they do work.
Is that whining I hear? Jk ;)
I have the same concern. We may need to allow more active downvotes on these types of contents.
Or, we could just avoid the problem as much as possible by not willingly opening things up for abuse. If users want to post more than four times, they can do that. They just won't earn as much. And chances are, if they're posting more than four times per day, the quality of their posts probably won't be that great anyway and probably won't be deserving of large payouts.
The four post limit/penalty doesn't seem to be a big deal in need of a "fix."
I don't think it discourages engagement. It discourages abuse - in the form of sock puppets and spamming. This is anecdotal, but I haven't seen many complaints from users who think that this needs to be removed. The limit doesn't mean that a user cannot earn - it only limits how much can be earned after a certain number of posts. With a stake-weighted system that can be and has been abused, I don't believe the limit is an actual problem.
if they spam post the bots will run out of steempower eventually or garner flags from pitchfork wielders
You're right. We may ask this first; how many articles/posts does a professional writers create per day?
Not all posts are going to be (nor should be) professional writers. Approaching it from that angle impairs the growth potential of the system to reach a much larger audience from the start. There are many different use cases for this blockchain, professional writers being only one of them.
Am I the only one that almost peed when reading this?
lol, nope
All in all, thank you for your hard work and most of all, thank you for being transparent and bringing this out to the community as a proposal and open discussion.
I am personally good with most of them and a bit so an so (might need more time to think on) about:
Switch to 7 day payout instead of 24h
The simplest and most logical way to reward everyone imho would be indefinite, with a 24h payout cycle.
Removing the 4 posts limit, comment nesting limits and separation of posts and comments rewards plus multiple beneficiaries etc.
I think this adds a lot of complexity to the operations and might turn out to be very heavy computationally wise especially as we scale. Also opens the door to spamming by overflowing the blockchain with data.
What I didn't see mentioned in the proposal. maybe it will be in the roadmap
Reading through all the items mentioned, i think that a more streamlined (TL'DR-ish), layman description of the suggestions would be welcomed by the less tech savvy.
This is a common misconception. The 4 post limit is per account. However, nothing prevents people from creating an arbitrary number of additional accounts (potentially thousands, and there are already people with thousands of accounts) to spam. Spam control is already handled by other mechanisms which are more effective than this one.
Also, even the 4 post limit doesn't prevent spamming with a single account, it just reduces rewards. Someone who wants to be malicious or annoying can still spam.
true
This post was about blockchain features, not website features.
true and thank you for pointing it out. I removed the Adds part which was exclusively website related. Other than that I consider all other items blockchain related.
duly noted.
I like it how you are making a distinct and clean space between blockchain (database / protocol) possibilities and presentation / UI features. This way you are making it possible for multiple interfaces to coexist over the same blockchain. Or even over the separate / side blockchains....
It shows vision :)
I'm excited about the independent comment reward pool. It will increase engagement tremendously and I believe it will do a lot to help grow the platform.
At the same time, however, we should expect to see many more low-quality and bot comments. The community will need to find a way to combat these spammy replies.
Downvotes. Downvotes for everyone!
Yes! I want to downvote those crappy comments. :-)
😂
Excellent update, thank you. There's a lot here and clearly the team has been working hard. We all really appreciate the updates and the discussion. I like that we're trying things out, testing what works and what doesn't, and we're willing to remove something we previously tried if it doesn't work out as expected or doesn't benefit us all as imagined. Being willing to be "wrong" is such an important aspect of gaining new knowledge on what ends up being "right."
Curious: any talk of changing the voting power? Initially Dan proposed a pretty serious change there and it was ultimately rejected by the community. Is that topic still active or is the future approach going to be voting guilds where many things get voted up automatically not by individuals but more so by bots?
I also would love to see changing the voting power revisited at some point.
I'm not sure this will please the main stake holders. It would be like taking their power away which was not in plan when they put their stake in.
What they are referring to isn't to take power away from large stake holders , but rather bots. Bots can vote all day every day and with a 40 vote soft limit it is impossible for any human with a job and/or life to compete with that. If we were to lower that limit then every human could use their full voting power and have a better chance at reaches the same amount of votes as the bots. I hope Dan and Ned will consider revisiting this idea as nobody is exchanging curation rewards for their authentic attention with the current system and that is a real fail for the attention economy. Those who pay more attention should be making better curation rewards than those (with the same amount of SP) who are offline.
Don't personify the bots - those are indeed humans with jobs and/or lives who are competing—by operating those bots.
Paying attention isn't what's being rewarded—it's surfacing good content. It doesn't matter if you washed your clothes by hand or used a machine.
Why should those with lives and families and a bot curator be paid more for surfacing content than people who actually read the content and also have lives and families but choose to be more attentive to the job? There's a reason people pay a dry cleaners instead of using the washing machine. But if we only care about cheap clothes (content) and would rather be lazy about the quality then use the machine.
Isn't the change @lukestokes is talking about the one where you could if you wanted to, vote 8x more with 1 vote and it would drain your voting power by 8x?
here's @sigmajin's post explaining the 8x thing https://steemit.com/steem/@sigmajin/what-every-user-should-know-about-the-upcoming-change-in-voting
Thanks!
there was a confusion about that as it doesn't allow you to actually vote 8x stronger. There was a post about it specifically but i can't remember which one.
Ah, right.
Did andu sell his account btw? :P
replying here due to comments nesting limit
yup, andu sold me the account. My previous one is @anduweb. Some KISS-ing right here, cutting off a couple letters.
:D alright thanks for the info! I knew andu from some time ago, was wondering where he went haha.
what a relevant issue ;D
Why not to make some steem weighted poll about each proposed changes with 3 options to answer: 1) agree, 2) disagree, 3) don't know?
Thanks to @xtar in Golos we have special poll site for that.
Even though I don't understand a word on that website, I would fully support a blockchain based poll feature.
Words don't matter). Number before brakets means number of voters, and number inside brakets is a summ of their Golos Power.
Overall....OUTSTANDING direction, simplifications, and some improved frameworks.
Thoughts:
And as always, thanks again for your continued work to make the platform better. I appreciate everything you guys/gals are doing and the fact you engage the community on future change proposals!
Because our usage statistics indicate that this would account for 0.85% or less of all rewards. Also see my recent blog post "Building Lon Term Value from your Blog" for the real answer to long-term rewards.
Yes, but you are conforming to the current metrics and not the desired end-state.
I have a more detailed post on this concept: Advocating for Long Term Steemit Payouts https://steemit.com/steemit/@mrosenquist/advocating-for-long-term-steemit-payouts
The comment reward will bring massive engagement. I believe this along with the arbitrary beneficiaries rewards will be a game changer.
You're right. But your posts have a lot of engagement already, ha ha.