![](https://steemitimages.com/DQmfExmjckE1rTCqbzxW335EmpPGQgSdTX6mMebzXSAMeVC/image.png)

I just recently learned of these [remarks from Vitalik on reddit](https://np.reddit.com/r/ethereum/comments/6qm0y2/is_the_ethereum_team_defending_their_ground/dkyk94c/). In these remark's Vitalik brings up the issue of Fees and Voting, both of which I feel deserve to be addressed. ## Client Side Validation > Lack of in-protocol economic incentives for these master nodes to behave correctly, and the lack of client-side validation capability, mean that there is an extreme reliance on the voting mechanism. If we are going to have a discussion then defining terms is critical. I interpret the phrase "client-side validation" to mean validation by non-producing full nodes, because the other definition of "light client validation" makes no sense in this context. Since EOS, Steem, and BitShares all have more "non-producing full nodes" than block producers and anyone can sync BTS and STEEM faster than they can sync ETH it seems clear to me that his statement is fundamentally wrong. Block producers have no power to produce invalid blocks and every exchange will run a full node or at the very least a partial node and therefore directly validate the relevant subset of transactions. Ethereum light-clients have to trust the block producers calculated things properly because they only check the hashes not the logic. Thus the failure condition is collusion of mining pools which is similar to collusion of elected block producers. The critical difference being that there are more elected block producers and their power is far more evenly distributed than the concentration of mining pool power. ## Voter Turnout Vitalik then went on to discuss the problems with voting: > Voting has the following problems: > > - **Low voter participation** (the DAO carbonvote, the current EIP186 carbonvote, the DAO proposal votes, and even ?Bitshares DPOS votes in 2014 all had <10% participation) > - **Game-theoretic tragedy-of-the-commons** vulnerabilities: because each voter only has a tiny chance of influencing the result, their incentive to vote correctly is thousands of times lower than the socially optimal incentive. This means that situations like everyone putting their coins on exchanges and exchanges voting on users' behalf, with users not really caring how exchanges vote with their money, are likely to happen. > - **Coin holder interests are not perfectly aligned with user interests**, and so proposals that increase coin prices at the expense of making the system useful may get implemented. Low voter participation has been addressed over the past 3 years through a combination of voting proxies, easier user interfaces, and a reduction on the number of things people have to vote for. All told participation has increased above 20% of total tokens. Concerns over "exchanges voting" were largely remedied via Steem Power (exchanges need liquid tokens) and could be completely remedied via the constitution. Furthermore, non-voters do not make things less secure. They keep tokens off the market which still makes it more expensive for an attacker to acquire stake. Large stakeholders have a huge incentive to vote to protect their wealth and an attacker would have to acquire more stake than the largest whales in the system. Given the turnout on Steem and BitShares and a market cap like Ethereum this would cost an attacker billions of dollars (assuming their buy pressure didn't increase price) and they could easily be forked out if it became a problem. If attacker is a collusion by the largest whales, then either the whales think the "attack" is a feature that will enhance the protocol or the "community" will fork the whales out. Bitcoin and Ethereum have both seen what happens when those with large influence use it to change the rules against the minority interests (ETC and BCC). ## Fees Lastly Vitalik addresses the fees: > EOS has a mechanism where instead of having transaction fees, there is a rule that if you hold N tokens you can send a maximum of N * k transactions per period (see Steem whitepaper). This has quite an undesirable consequence for usability: it means that users have to buy N tokens, and have to be exposed to their volatility. This is especially bad for: > > - The poor, who are not interested in putting the entirety of their often very low savings into a funky new cryptoasset in order to be able to use a blockchain. > - Anyone who wants to use the blockchain only a few times and then go away (they would need to buy coins and then sell them again) > In Ethereum the latter is also true to some extent, but because you have to pay fees, the values involved are much smaller, so buying an extra few dollars of ether just in case is not a big deal. I agree, the poor shouldn't have to buy any crytpo assets just to use the platform and this is why fees are a problem. Try to implement Steem on Ethereum and you would drive all the users away due to fees alone. There is a high fixed overhead associated with buying even $0.01 of any crypto currency. You have to create an account, pay bank transfer fees, do KYC, pay market spreads, etc. You have to buy and hold over $100 of cryptocurrency to justify the time and money of acquiring it in the first place. It certainly isn't viable to expect users to go through this process for a $0.01 fee. > - Anyone who experiences prolonged unexpected spikes in demand (ie. pretty much everyone); users will have to buy enough coins to cover perhaps the 99th percentile of their expected usage, so that they don't get stuck being "out of gas" and having to go to an exchange. Due to the fractional reserve nature of the blockchain bandwidth allocation, most people only need to purchase enough for their "base load" and the network can handle the surges in demand. Only in situations where the network is 100% congested will you need to purchase enough to cover the 99th percentile usage; however, if people are buying enough to cover the 99th percentile usage then the network will never be 100% congested because they will be holding unused bandwidth during the average usage. Therefore, we can conclude that the market will automatically balance things out and people will not have to buy based on peek usage but average usage. ## Service Should Pay Lastly EOS is designed around the idea that service providers (DApp Developers) should cover network costs, not the users. A good application needs a monetization strategy that is fully independent of network operation. The existence of Steem is all the proof we need to demonstrate the value of "free" transactions and how we solve the issues with users needing stake. ## Casper Vitalik's entire critique on voting hinges on the "missing slashing conditions". Namely, that block producers are not punished for misbehaving. If you ignore the loss of future revenue and reputation, DPOS can offer trivial slashing for producing two blocks with the same timestamp and thus attempting to create a fork. It is also trivial to add a bond on producers that stake holders can vote to confiscate for a wide range of objective and subjective violations of the constitution. In my [Review of Casper, Ethereum's proposed Proof of Stake Algorithm](http://bytemaster.github.io/2015/08/08/Review-of-Casper-Ethereums-proposed-Proof-of-Stake-Algorithm/) I throughly debunk the algorithm. 1. the computational costs of the algorithm consumes the limited transaction throughput 2. making economic bets on next block producer encourages collusion and cooperation rather than competition. 3. ultimately Casper will have blocks produced round-robin by a coalition of colluding large stakeholders dividing up the rewards proportional to stake. In effect, the interest of the smaller players will have no impact on block production under Casper and the network overhead of per-block communication will be dramatically higher (favoring those with low latency connections to each other and therefore centralization). ## Conclusion Once again critiques of DPOS, EOS, and STEEM are based upon flawed economic assumptions, misinformation, and ignorance/denial of vulnerabilities in their proposed solutions. I fully recognize that voting is not ideal, but it is currently the best approach when factoring in all risks, attack vectors, and recovery options.