Mining versus Consensus algorithms in Crypto 2.0 systems

Recently, I had the pleasure of talking with David Schwartz, Chief Cryptographer at Ripple Labs about a topic that I haven't heard covered before - the implications of using a Consensus algorithm for ledger creation rather than a Mining approach, such as the one used in Bitcoin. This seemingly insignificant difference can affect the long-term viability of a Crypto 2.0 system as it turns out. But first, some theory...

Mining algorithms

As pretty much everyone knows, new Bitcoin blocks are created through a process called mining. Every miner on the network competes to produce the next Bitcoin block by the use of Proof of Work algorithm. If you find the solution first, you have successfully created the next block and thus get the block reward plus fees for included transactions - pretty simple.

There have been a lot of tweaks made to this simple algorithm in many altcoins out there. A number of different coins use different hashing functions for their Proof of Work, some networks introduce Proof of Stake or Distributed Proof of Stake and so on. What all of those algorithms have in common is that every block is created by a single entity - it might be a lone miner, or perhaps a mining pool aggregating a number of workers, but there is still a singular authority that dictates how a block looks.

Consensus algorithms

The Consensus algorithm as popularized by Ripple and also used in Stellar works on a different principle (some videos on this subject - 1, 2). Instead of performing any mining, a number of validators agree on which transactions should be included in the next ledger. Based on that agreement, every validator creates the same ledger.

While the way the validators are chosen can be a a difficult and important design decision, the result is similar - there is no single entity that creates the next ledger.

Malicious miners - what can they do?

While most people have heard about the dangers of a 51% attack and some are also aware of the Finney attack, today we would be talking about more benign things every miner can do to every block they create.

Any miner that creates a block can:

• Control which transactions are part of the block, if any
• They can prevent certain transactions from appearing in the block they mine
• They can include any number of valid transactions into the block. Even if fees are forced for any such transactions, the miner will earn those fees back
• If there are multiple conflicting transactions, the miners get to pick which are included in the block, thus invalidating their double-spend counterparts
• Control the order the transactions are included in the block
• Decide whether to release the block they created at all
• Set the various block parameters within some limits (they control the nonce and timestamp)

In the Bitcoin world, pretty much all of those things don't really affect the network performance all that much. Sure, the miners can censor some transactions for a block, but provided the network as a whole is not compromised, those transactions should eventually make it into someone's block. They can also spam the block with any number of their own transactions for free, but in the grand scheme of things it's just an extra megabyte of data that needs to be stored. All in all, due to Bitcoin's straightforward transaction nature and the fact that we're dealing with only one currency, a malicious miner can't really do much.

Now, lets consider the same scenario on a more sophisticated Crypto 2.0 platform, such as Ripple, BitShares, Ethereum, Omni or the like. The network not only handles their native currency, but also offers a lot of other features - derivative contracts, decentralized exchanges, smart contracts and so on. Suddenly, whether a transaction is included in a given block or a block after can start to matter a lot more.

If a malicious miner sees a big buy order coming into the market that would move the price significantly, they can engage in front running - the buy order could be pushed to the back of the queue or even left out until the next block, while the miner buys up all of the current stock and re-lists it at a higher price to turn a profit. Alternatively, when they see there is a high market pressure coming in, especially in systems that are inefficient by design, they can buy the orders up one by one by using their power to include any number of their own transactions into a block for free, and similarly re-list them for people to buy up.

When we enter into the smart contract world, we have a few more exploits.

Perhaps the system in question is relying on the miners to be smart oracles and report some price data. The miners can misrepresent the price in their favour - perhaps not so blatantly as to report different orders of magnitude, but one could use data that is a bit stale or fudged on the second or third significant digit without it looking too suspicious.

The miners could also try to influence some time-sensitive contracts - maybe someone tried to make a bet on some lottery during the last possible minute, or some contract deadline is about to come up and the miner stalls the transaction by one block? That could change the outcome of the contract.

Lastly, if some smart contracts implement gambling on the blockchain with the random number generator being influenced by the mined blocks, the miners could cheat that system by only releasing blocks favourable to their bets. Say, if we have a virtual coin flip that is heads if the block hash is even and tails if the hash is odd, if the miner stands to gain more by winning the bet rather than creating the next block, they can withhold the blocks that aren't favourable to them. Provided their computing power share in the network is greater than the house edge in the game, the miners would turn a profit in the long run.

All in all, there is a lot more a malicious miner can skew in their favour in a Crypto 2.0 system than they could do in a traditional system like Bitcoin.

Validators

In comparison to the miner-based approach, the consensus model based on validators solves the listed issues in most cases. Provided the validators are not colluding with each other to overtake the network, most of the above listed attacks are reduced if not eliminated altogether.

While a malicious validator might try to do some front-running, their transactions aren't more likely to be included into the next ledger than the transactions anyone else submits. Having multiple validators act as smart oracles could allow one to average out the answer and limit the influence of one malicious report. Time-sensitive contracts could be slightly influenced by trying to stall the consensus mechanism or vote against some transactions being included in a ledger, but since the system is designed to be fault-tolerant, one malicious entity shouldn't be able to do much.

Influencing the ledger hash is possible to some degree - the validator can try predicting what the next ledger will look like and adding which transaction could influence that hash in their favour, but everyone else can do the same. Since all parties are just as likely to influence the ledger hash, the result of this influence could make the outcome just as random as it ought to be, or at least make it very hard to predict whose influence will win in the end.

All in all, a validator-based approach to ledger generation reduces the number of exploits that can be performed in a Crypto 2.0 system.

Conclusions

One could compare the mining approach to block generation to a short-term dictatorship, while the validator approach is more akin to democracy. While both systems can be exploited or used for good (the Roman Republic elected their dictators in times of need, while democracy can spiral into mob rule), the democracy of validators requires more parties to be malicious before the system becomes compromised.

While in the Crypto 1.0 world a malicious miner can't do much to harm the system, in a Crypto 2.0 world there are a lot more exploits that need to be addressed.

As this is a topic I haven't seen properly discussed before, I would love to hear the input from the developers of various Crypto 2.0 systems - Omni, Ethereum, Counterparty, NXT, BitShares and so on as to how they view this issue potentially affecting their networks.

Share on Facebook

Share on Twitter

Share on Google+

Share on LinkedIn

Subscribe to receive free email updates: