One of the positive results of the recent Steem hard fork is an increase in discussion about and scrutiny of Steem’s witnesses. Responsibility and accountability have been the popular topics, but there also appears to be a more attention being paid to witness voting and the manner in which it can be improved. A particular point of interest is vote decay and I’d like to add the number of witness votes to the discussion and specifically for the purpose of this post.
The following ideas should be carefully considered and feedback is appreciated.
Witness Vote Decay
There seems to be a growing consensus for some type of vote decay on witness voting. There are many interested parties and plenty of discussions have taken place, but how such decay would occur hasn’t received as much widespread support. Let’s try to change that with what I believe are some common sense solutions.
But first – I’d like to briefly mention why I think vote decay is necessary. For me, it’s pretty simple: Our witnesses ought to be representative of the active invested voters.
While many people agree that these active voters should have more say in how the network is run, there is less agreement on what constitutes an “active” voter. The primary concern is whether or not inactive users/voters can adequately ensure network stability and accountability via witness votes. On that front, it’s obvious to me that truly inactive users simply cannot accomplish this.
There are many reasons why an account can become inactive and there can be legitimate arguments for casting votes from a specific inactive account and leaving them in place for an extended period of time. But to help ensure that votes are being cast by active users and to help ensure that witnesses are being routinely scrutinized/vetted and voted on accordingly, requiring “stale” votes to be recast periodically could be a beneficial protocol for the Steem blockchain.
Again – we don’t know why the voting accounts are inactive or if the users controlling them are in fact inactive on the chain, but we do know that requiring a periodic vote will mitigate against truly inactive and/or uninterested voters. It can also help mitigate against entrenched witnesses that may have veered from their witness responsibilities and their stated intentions/goals.
So the question regarding how to protect ourselves from these issues is mostly a matter of defining “active” and “periodic.”
As a proof-of-stake system, Steem’s witness voting operates similarly to a corporation or security in that voting privileges are extended to stakeholders or shareholders on a “per-share” basis. In the corporate/investment world, voting for a corporate board of directors usually takes place annually. Witnesses for the Steem blockchain essentially act as a decentralized “board of directors” for the chain. Every holder of Steem Power on this chain has a number of votes to cast for their favorite witnesses.
The main difference between voting on a corporate board of directors and voting on Steem witnesses is that our Steem witness votes can be cast once and then permanently remain in place until the voting account actively removes the vote.
There has been discussion about how often votes should decay, if we were to adopt this kind of protocol. In my opinion, one year would be an adequate period of time, so this is my proposed plan for vote decay:
1. A vote will begin to decay 52 weeks after being cast.
2. Decay will occur over a 13-week period (the same weekly influence reduction and time-frame as a full SP power-down cycle).
That’s it.
After 65 weeks (52 + 13) without being recast, the stale vote would completely decay to zero vests of influence from the voting account. This keeps the voting somewhat current without placing any unfair burden on voters. It also keeps the time frames familiar for users and consistent with other current blockchain protocols.
This also does not represent any systemic risk to the blockchain by resetting all witness votes at a specific date or time. Decay is based on the dates and times that each individual user casts their votes, which are constantly occurring and changing. However, in that regard, this could introduce some computational burden, so that will need to be further discussed – such as whether or not decay can be stateless.
If you have anything to add or critique about this proposal, please share your thoughts in the comments.
Number of Witness Votes
This is a topic that has been on my mind for a while and I believe it needs some attention. The number of Steem witness votes that we are allotted, the number of top-earning witnesses, and the number of votes needed for hard fork adoption don’t appear to be adequate for addressing concerns of collusion and potential threats to network security.
Under the current system, there are 20/21 top witnesses that earn a relatively large sum of rewards for maintaining and managing their witness nodes. Of these witnesses, 17 are needed for updating the Steem blockchain to a new version via a hard fork. Each Steem account can cast up to 30 votes for witnesses.
The main objection that I have to this is the fact that any group of colluding stakeholders with a large enough stake can “capture” the entire number of top witnesses, exploit the network in various ways, and control the ability to change blockchain protocols. This concern has been expressed in the past by other users when specifically discussing Steemit, Inc.’s stake in the blockchain and the stake of their employee and partner/affiliate accounts. This criticism is one of the reasons why Steemit, Inc. no longer votes on witnesses.
The problem isn’t that they had voted in the past and essentially “stacked” the top witnesses, but it’s the fact that this could be accomplished in the first place.
Currently, one vote from the 
| Voter | Mvests Controlled |
|---|---|
| pumpkin | 15,806 |
| blocktrades | 9676 |
| clayop | 7151 |
| haejin | 3125 |
| smooth | 2838 |
| minority.report | 2684 |
| thejohalfiles | 2230 |
| TOTAL | 43,510 |
The
This is not to say that any of these accounts would engage in any collusion in order to attack or exploit the network, but only that it could be possible with our current protocols. Our protocols must offer enough robust security measures to protect against possible exploits and attacks that could occur both now and in the future. We may be able to protect the chain at the moment, with the current user base and stakeholders, but is that enough to mitigate possible disaster going forward?
Even if harmful exploits or attacks aren’t a major concern (right now), there is still the ability to collude simply for the purpose of capturing a majority share of witness rewards. Reducing the ability to exploit the network in this case benefits non-colluding witnesses and helps to distribute rewards to a larger number of interested parties, which in turn helps with decentralization. So in actuality, it can still further mitigate potential security risks.
With this in mind, here are a few possible options that I propose:
1. Reduce the number of allotted votes per account to less than the required number of witnesses for hard fork consensus, which would be less than 17. If consensus is 17, then allotted witness votes should be 16 or less.
2. Increase the number of consensus witnesses to more than the number of allotted votes per account, which would be greater than 30. If allotted witness votes is 30, then consensus should be 31 or more.
3. Increase the number of consensus witnesses and reduce the number of allotted votes per account to one less than the required number of witnesses for hard fork consensus. If there are 30/31 top witnesses, then 25 would be needed for consensus, which would give 24 or less witness votes to each account.
Our current system is comprised of 20 top witnesses with one rotating witness from the pool of remaining witnesses. Required consensus is 17 witnesses.
Again – if you have any questions, concerns, or critiques about this specific topic or any of the options proposed above, please share them here.
tl;dr
Witness voting may need to undergo some changes in order to better improve and protect the Steem blockchain. I propose two sets of options in order to achieve this:
Witness vote decay based on a 52-week voting period followed by a 13-week decay period on “stale” votes.
Reducing the number of allotted witness votes per account to at least one less than is required for blockchain consensus.
Discussion is welcome.