Table Of Contents
In the previous articles we talked about EVM compatibility and decentralization as factors important in choosing the right chain to build on. We mentioned that decentralization is part of the blockchain trilemma, and the other 2 parts are security and scalability.
Let’s talk about security today.
At its core blockchain uses cryptography, decentralization, and consensus to ensure trust in transactions. Data is structured into blocks of transactions that connect to the previous one in a cryptographic chain, that makes it impossible to tamper with. All transactions within the block are validated and agreed upon by a consensus mechanism, ensuring that each transaction is true and correct.
The blocks make up a distributed ledger that is stored on multiple computers across the globe. This prevents a single point of failure.
Blockchain security can thus be viewed from multiple angles.
The decentralization part and single point of failure we talked about in our previous article. In general, a blockchain needs to be as much decentralized as possible so no bad actors can take easy advantage of it either geographically, by jurisdiction or by token holdings, or by any other means that might be possible withing less decentralized systems.
This leaves us with the core of blockchain security and that is the consensus mechanism that prevents bad actors to change transactions and prevention of tapering with the ledger history. A consensus mechanism in blockchain is a fault-tolerant method used to achieve the necessary agreement on the state of the network. In practice this means that every validator in the network is tasked with the same task and the result of the majority will be accepted as truth and added as a valid block at the end of the chain. What is important is that validators compete for a reward and the rewards can only be given to the nodes that present a truthful result. On the other hand, there must also be punishment as if bad actors don’t incur any damage by trying to fraud the system, they may keep on trying indefinitely and that greatly increases the security risk.
The most well known and arguably the most secure consensus mechanism is called Proof of Work (PoW) and it’s used by Bitcoin. In this model validators are tasked with a hard hashing task that requires a capable computer and consumes a lot of power. The power used is the stake in this system as it is the cost that will be “repaid” by the award of minted Bitcoin that go to the block producer. If a validator produces invalid (fraudulent) blocks he will never have the ability to add the block to the chain and thus will never be awarded the Bitcoin reward. His energy costs will go to waste.
Not connected to security but still relevant to PoW and also to chain selection process is the fact that mathematical equations used in PoW do not have any meaning and don’t produce anything extra. Their sole purpose is to secure the network. Although we could argue that the energy consumed is smaller than that of the systems that Bitcoin is trying to replace, we can not go around the fact that we do have other systems that are provably secure and consume way less energy.
One of such systems and currently the most popular in one version or the other is Proof of Stake. The system is similar to PoW but instead of hashing, validators need to provide a stake in terms of locked up tokens. The validators with the highest amount of tokens staked will be more likely to add blocks to the chain. Fraudulent behavior might lead to staked tokens slashing, meaning they can be taken away or rewards slashing, meaning the validator will not receive any rewards. In the case of delegated stake from multiple unconnected users, they will slowly leave the validator because of not earning the rewards and the validator will not be able to produce valid blocks anymore.
In PoS system it is wise to limit the amount of staked tokens with diminishing rewards to it. This limits the power of one single validator and prevents centralization and the connected security flaws. A perfect example of such a system in practice is Cardano. The majority of modern blockchains use this mechanism.
There are other consensus mechanisms like Proof of Capacity, Proof of Activity, Proof of Burn, Proof of History, Proof of Elapsed Time and probably many, many more.
One of the frequently mentioned security issues is the so called 51% attack. As the systems reaches consensus by the majority of validators, if an attacker would take control of more than 50% of the network validators, he would be able to change the true outcome of the processed transactions.
He would potentially also be able to change the history of the chain. Chain history is secured by adding one valid block after another and include the hash of the previous block in the current block. With this a chain is created that will break if any of the previous block are tampered with as it’s hash will inevitably change. This is what makes the blockchain so secure.
Cryptography and hashing
Besides the consensus mechanism there is the question of the used hashing algorithm. This sets the cryptographic power and hack resistance for the blockchain and it’s components like the wallet private keys. Blockchains mostly use the SHA-256 hashing algorithm. SHA-256 is one of the most secure hashing functions on the market. It is almost impossible to reconstruct the initial data from the hash value, a brute-force attack would need to make 2²⁵⁶ attempts to generate the initial data. Having 2 messages with the same hash value or collision is extremely unlikely. Even a minor change in the original data alters the has value so much it is not apparent that the value is derived from similar data, also know as the avalanche effect. To crack a SHA-256 crypto private wallet key it would take about 6 times the age of the universe. SHA-256 should be the lowest standard hashing algorithm used by blockchain.
Will quantum computers be a threat?
They may be, but with stronger computers there comes stronger algorithms and to be honest, there are far easier monetary systems to crack than blockchain.
But we hear about so many hacks…
There are many security breaches but there are almost no blockchain breaches. The blockchain is only a underlying platform that allows to build dApps. What get’s hacked or even more often, exploited are security and design flaws of these dApps. The difference between a hack and exploit is that in a hack the security of the code is breached or bypassed, as with an exploit the unusual and edge cases of the existing functionalities are used to gain economic advantage. But as said, this is more for understanding and is not in any sense connected to the flaw of the blockchain code and functioning.
There are other security issues that are usually connected to factors outside the blockchain, like phishing attacks, routing attacks, stolen keys, hacked exchanges and hacked personal computers. All these affect the blockchain user, but it is not connected to the blockchain code per se. Most of these attacks come down to user education and ease of use, that are in the realm of dApps.
Denial of service in blockchain
Because of its decentralization, some say blockchains are DDoS (Distributed Denial of Service) resistance. In a sense this is true in the traditional way of attacking and overwhelming a single server. You would need to perform a DDoS attack on all the nodes in the system to prevent it from providing service to the network.
Yet there are multiple attempts of a type of DDoS on the blockchain called flooding. In such an attack the attackers send spam transactions and fill up the blocks, causing legitimate transactions to sit in mempools and not being processed. This has happened recently with Solana, where the whole network was down for hours during the cryptocurrency crash. This in turn prevented users from accessing their funds and many got margin calls they could not fill and got liquidated causing immense damage to the users.
There is again a tradeoff to be made between fees. High fees make it unattractive for the attackers to spam the chain as they need to pay the gas fees for senseless transactions they are sending to overflood the system.
Protection against such attacks needs to be implemented in the system by ensuring adequate node requirements and overhead, by identifying a potential attack and gracefully failing rather than hard crashing and with transaction filtering that can remove spammy transactions from processing at all.