The incredible speeds and low costs of using Steem are due to the fact that it uses a consensus mechanism called Delegated Proof of Stake (DPOS), which was invented by Dan Larimer () a few years back for use in the Bitshares chain. Unlike proof-of-work mined chains like Bitcoin and Ethereum, no electrical resources are deliberately wasted in order to secure the database; rather, the shareholders in the system vote on a small number of "witnesses," who collect transactions from users of the blockchain, publish them into blocks, and receive pay for their services. In any blockchain-based system that uses Delegated Proof of Stake as its consensus mechanism (e.g. Steem, Bitshares, Peerplays, Golos, Lisk, EOS (eventually), Muse, and others), the stakeholders need to be vigilant about how well the witnesses are performing their duties, and vote out the bad ones diligently.
Under what grounds should a witness be removed?
Technically-bad performance: On steemDB, you can see a list of the current witnesses and some very basic stats about them:
The quickest and most obvious way a witness can fail to do his job is by being lazy and missing blocks; that's what it means in that screenshot where it says "weekly and total misses." If a witness is consistently failing to produce blocks (or producing invalid blocks for some reason), that witness should be voted down.
Front-running whale votes: There may be some who don't think this is bad, but I'd consider it grounds for a stern talking-to. When you cast a vote for a post, that vote transaction goes to the witnesses for inclusion in a block. It would be relatively easy for a witness to sneak a vote in ahead of you. This could actually be pretty profitable -- witnesses could easily vote ahead of whale votes and skim extra curation rewards, and with a small refactoring of the Steem source code, there's nothing preventing witnesses from reshuffling the order of transactions. Who does it hurt? The whale whose vote is front-run, who would be cheated out of some curation rewards.
Front-running market orders: This would be done in the same way as the previous one; the witness would see a big order that's walking the book, and place a pair of orders in front of it. I haven't run any kind of statistics to see how much money could be made with this, but it's probably quite a bit. It wouldn't quite hurt anybody. It takes away surplus from the person whose order is front-run, which some would argue isn't bad because the fact they placed the order they did means that they were willing to take the price of their order.
Manipulating price feeds: Unless a large number of witnesses are colluding on this, the damage here is probably limited -- but a witness could probably move the price feed around by a few cents every now and then, and this could be used to shape where awards go to a tiny extent. I'd love to do a study on how much money a witness could siphon out of the rewards pool by doing this. Probably not much, but over time it could be nontrivial.
Technically also, if an attacker could compromise a large fraction of witnesses at once (or if a bunch of witnesses could collude), the attacker could do anything they wanted to the chain's database with a hard fork. This sounds scary, but it's a more-or-less toothless attack -- because it would be obvious and could thus be reversed rather quickly and easily by another hard fork that reverts whatever changes the attacker makes.
How can we tell if a witness is misbehaving?
With most of these other than technically-bad performance, catching a misbehaving witness would be quite difficult. How can you tell if a witness is selling front-running spots? Nobody else can prove that the witness didn't receive the transactions in the order that they were published, since the only record of transactions is what shows up in the blockchain -- and the witness itself published that.
Nonetheless, it should be possible to apply the magic of statistics to catch a front-running witness. I haven't worked it out in detail, but if a witness is systematically changing vote (or market transaction) order, it would be possible to catch it with a clever application of hypothesis testing. Any statistics experts in the audience who are interested in helping me work on a project doing this should please reply here or contact me on steemit.chat!