The Steem reward system, Part 3: Curation rewards principles

This is the third post in a series about the Steem reward system. Please read my disclaimer.

Previous posts: <a href="https://the-steem-reward-system-part-1-v-shares" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">1 <a href="https://the-steem-reward-system-part-2-v-shares-from-r-shares" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">2 <a href="https://steemit.com/steem/@dantheman/changes-to-curation-reward-allocation" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">here, the core team has reached consensus on an algorithm and is proceeding with the implementation (although a few minor details remain to be discussed).I took a break from this series of blog posts because there's been an incredible acceleration in the pace of discussion of curation reward proposals, both within the community and internally at Steemit. I've barely been able to keep up with the discussion, let alone write about it. But, as <a href="/@dantheman">@dantheman posted The post I linked in the previous paragraph discusses an algorithm I developed about a month ago in some LaTeX notes which I circulated internally at Steemit. The primary feedback I got was that my notes were not easy to follow. Everybody (myself included) initially assumed that this was because those notes contained a lot of advanced mathematics. But as our internal discussions continued, it slowly became clear that another factor was at play: I had a different perspective on the problem, which I assumed others would immediately see once they read my notes, even if they couldn't quite follow the details of the math. When I finally took my focus away from the math and changed my explanations to focus on my perspective, I found it much easier to make a convincing argument and build consensus among the other core developers. My next step in this series of blog posts is to bring those same revelations to the Steem community. <h1>The principles We'll start out with a list of principles. Principles are properties that are considered desirable [1] by system designers. The algorithm itself is a direct consequence of these principles. <ul> <li>The SBS [2] princple. The SBS principle is that R-shares are fungible, homogenous, and arbitrarily finely divisible. If Alice and Bob both upvote the same post, neither Alice nor Bob's payout should change regardless of whether Alice keeps her funds in a single account or splits her funds up into accounts Alice1 and Alice2 (all else being equal). <li>The proportionality principle. Upvoters' curation rewards change proportionally for subsequent upvotes. For example, suppose Alice and Bob vote on the same post, Alice's reward is 200 V-shares, and Bob's reward is 100 V-shares. The proportionality principle states that if subsequent votes increase Bob's reward to 500 V-shares, then Alice's reward must simultaneously increase to 1000 V-shares. [3] [4] <li>The ultimate indifference principle. The ultimate indifference principle relates to the concept of an ultimate upvoter (UU), a (theoretical) upvoter who has a small balance and is always the last person to upvote a post. The ultimate indifference principle states that the UU is indifferent about which post she will upvote (assuming she only cares about how many V-shares she personally receives from curation rewards). <li>The quadratic reward principle. The total curation reward of a post in V-shares is equal to some quadratic function <code>v(R) [5] of the total R-shares upvoting the post, with a few minor technical restrictions [6]. <li>The monotonic supply schedule principle. The weight distributed per R-share decreases as the total upvoting R-shares increases. <h1>Roadmap The next posts in this series will get into some heavy math (because of the SBS principle we have to use differential equations). For the non-mathematically-inclined reader I'll summarize the most important conclusions: <ul> <li>The original curation reward algorithm was not created from differential equations and violates the SBS principle. <li>Setting rewards equal to <code>R^2 (i.e. <code>s = 0) results in a non-monotonic supply schedule, so we must set <code>s > 0. <li>I will provide suggestions for how to set the model's three parameters <code>A, <code>B and <code>s. <h1>Meta-discussion issues Any discussion of changes to the reward system may get contentious due to the non-trivial amounts of STEEM involved. I mostly prefer to stay away from blockchain politics and focus strictly on technical matters. Here are a few thoughts which I hope will clarify the boundary of the topic under discussion and hopefully keep the comments from degenerating too far: <ul> <li>Grinding of political axes fits much better <a href="https://steemit.com/steem/@dantheman/steem-governance-and-changing-the-rules" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">here or <a href="https://steemit.com/steem/@dantheman/changes-to-curation-reward-allocation" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">here, I have very little to add to what <a href="/@dantheman">@dantheman said in those posts. <li>The CEO of Steemit, Inc. is the top curation rewards recipient according to the old code. If the developers' objective was to use the curation reward system to allow whales / insiders to more easily line their pockets, we wouldn't be pushing for changes. <li>There are technical costs to maintaining multiple reward systems. If we can get a new system that's demonstrably better than the old system implemented and adequately tested before July 4, it will make me very happy as a backend developer if we can then delete the old system code. <li>There's a single unique algorithm which simultaneously follows all of the principles in this post. If you accept the principles, then you must accept my algorithm as the One True Curation Reward Algorithm, since it logically follows from the principles. <li>Selecting a set of principles is an important problem, but it is a problem of a social, political or philosophical nature. Such questions are out of scope for this series of posts. I want to focus on the strictly technical problem of deriving an algorithm from this particular set of principles. <li>If you object to any of these principles, it is up to you to lay out a viable alternative set of principles, construct a convincing social/political/philosophical argument for your principles which is accepted by the community, and solve the same technical problem of how to derive an algorithm from your principles. [1] Rewards should be fair, incentivize behavior which enhances the community, and have a simple and efficient implementation. [2] SBS stands for "satoshi by satoshi". [3] The proportionality principle is equivalent to stating that each upvote is assigned some weight, and the post's total V-shares curation reward is divided proportionally to the weights. [4] The astute reader may notice that the SBS principle and proportionality principle sound similar, and ask whether one of these principles is a special case of the other. The SBS principle and the proportionality principle both describe forms of homogeneity. However, stake may cease to be homogenous due to the time order in which it votes. The SBS principle says R-shares (the "stuff" used to vote) are homogenous, the proportionality principle says weight (the "stuff" used to assign rewards) is homogenous. The weight per R-share may change as the post is upvoted without violating the proportionality principle or the SBS principle (as long as this change only depends on the amount of R-shares seen by the post). So it is possible to have a system where (Alice votes, then Bob votes) does not have the same consequence as (Bob votes, then Alice votes) while respecting both the SBS principle and the proportionality principle. [5] I used the notation v-bar in the internal Steemit notes and my previous post. But I decided to drop the v-bar due to Unicode issues. [6] These minor technical restrictions are as follows: <ul> <li><code>v(R) has a leading coefficient of 1 <li><code>v(0) = 0 <li><code>v'(R) >= 0 when <code>R >= 0 These restrictions mean that <code>v is the parabola <code>y = x^2 with the origin shifted to the right by some amount <code>s. The general form of such <code>v is <code>v(R) = (R+s)^2 - s^2 with <code>s >= 0.