- What feature(s) did you add?
To understand how my feature works I need to dive into how rewards are calculated in the steem blockchain. Whenever an account votes, the vote actually gets stored with a certain number of rshares in the database. To determine the value of a given number of rshares, you have to get both the
recent_claims, the number of currently "active" rshares and the current size of the rewards pool. The formula that needs to be applied to get an estimation for the value is the following:
value = vote_rshares / recent_claims * reward_pool * sbd_price
To read up a bit more about this read the tutorial by steemit for thist
This also was how beem calculated the vote values, until I tweaked that calculation a bit. Because if were to calculate the value of a vote, which has not yet been broadcasted into the blockchain, the rshares of that vote would be missing in the
recent_claims causing the upvote to seem bigger than it really is once it has been broadcasted. While the effect of this change is nearly not noticeable in the current Steem environment it has a lot of impact in an environment where one account has most of the steem power and does only vote rarely.
I made some graphs for this when I implemented this to visualize the impact:
This really shows that the higher the potential vote, the higher the impact on its value. But to be honest this graph already is in absurd levels, since @crokkon told me there are about 3e16 rshares being added each day, so this is really not that big of an impact in the current environment.
Another graph to show the same thing: impact gets higher, the bigger the hypothetical upvote is.
To further visualize this, I will show a REPL session checking the upvote value of the @steemit account. One time using my feature, one time without using it.
>>> from beem.account import Account >>> steemit = Account('steemit') >>> steemit.get_voting_value_SBD(not_broadcasted_vote=True) 2465.814621646523 >>> steemit.get_voting_value_SBD(not_broadcasted_vote=False) 2474.4767294899793
As you can see even for the biggest account on the blockchain, the difference is only 8 dollars, so it most likely doesn't matter a lot anyways.
I got a little fun fact for ending this point: every downvote is bigger than an upvote of the exact same size. To proof this, I got a little REPL session for you again:
>>> from beem.steem import Steem >>> stm = Steem() >>> stm.rshares_to_sbd(1e16, not_broadcasted_vote=True) 13474.605985050803 >>> stm.rshares_to_sbd(-1e16, not_broadcasted_vote=True) -14010.700287696967
- How did you implement it/them?
After I knew what I wanted to implement and how that will work, the implementation was rather easy. The first thing I did after looking into the beem code where the vote values get calculated was to fix a missed DRY (Don't Repeat Yourself) case, where the
vests_to_sbd function was nearly the same as the
rshares_to_sbd function. I changed the
vests_to_sbd function to transform the vests to rshares using the built in function, and then transforming these to sbd using the
Then I went on to actually implement my feature. In fact all I had to do to get it working was to make this little change. In fact I only add the rshares of the vote whose value shall be calculated to the recent_claims. The rest of the changes I did were only changes to make it configurable. I chose the following defaults for the function because of the following reasons:
rshares_to_sbdfunction I chose the
not_broadcasted_voteparameter to be
Falseby default, since I think that normally users use that function when they e.g. stream votes from the blockchain.
vests_to_sbdfunctions I chose
Trueas the default parameter setting, since I believe that when people use these functions, they rarely try to get the value of an already existing vote, but rather want to know how much an upvote with that much SP / vests would hypothetically be worth.
get_voting_value_SBDfunction of the beem.account module, I also chose
True, and I think it is pretty clear now why I chose this.