Beyond Consensus — Part 2
In part one we discussed consensus, proof of work, and where they fit into a blockchain system. We’ll dive deeper in this post and examine how a particular choice of hashing algorithm is really an implementation detail, being very well isolated from the behavior of the rest of the system. For example, the hash rate is fairly unrelated to things like transactions per second due to the block difficulty dynamically adjusting with each block, which keeps average block time pretty stable. So choosing an algorithm that results in 1000 hashes per second on some hardware won’t make much difference versus choosing an algorithm resulting in 1 million hashes per second on the same hardware. This is what makes it so easy to fork code that implements a blockchain system and swap in different hashing algorithms, then claim you’ve invented the greatest thing since sliced bread.
In spite of all this, there remain some interesting trade-offs to consider when it comes to hashing algorithms. But first let’s back up a bit. For Marconi, the original reason we chose to use proof of work on our global chain is because it’s a no-nonsense, tried-and-true method that everyone can easily get behind, which is great for bootstrapping a new chain. Sometimes people ask, “But what about scalability? I heard that proof of work has scalability issues.” Well sure, if you’re trying to be Visa. But we’re not trying to be Visa, nor are we trying to innovate in the financial space. Where we’re focused is networking, privacy, and security. In fact the blockchain pieces of our system are just one aspect, and the reason we decided to use any blockchain pieces at all is because they provide a very useful trustless property that we needed in order to complete our larger design. For us, the global chain just needed to do a few simple things, so using simple proof of work sufficed. No point in over-engineering the thing.
Which brings us back to the choice of hashing algorithm. Some of the trade-offs to consider are how decentralized you want mining to be and how worried you are about 51% attacks. Conventional wisdom says that an ASIC-resistant hash function helps prevent centralization by leveling the playing field between large mining operations and average users. On the flip side, an ASIC-supported network can be more secure against 51% attacks, since botnets or easy-to-rent machines generally can’t compete with the efficiency of ASICs, and the capital invested by an ASIC miner binds their fate by locking them into a narrow set of minable options as opposed to being able to bounce from coin to coin if a chain should go south.
But is ASIC resistance a myth? Is resistance futile and should we just give up, as some have claimed? Read on to the third and final installment to find out.
