関連インシデント
Security considerations override all other considerations in software in general and in blockchain specifically. If security fails, nothing else matters. Blockchain proves decentralized, trustless transactions work, but many blockchain security vulnerabilities remain nonetheless.
Security exploits exist at the design and architectural level, at the coding stage, and in the operational phase. And in case you were wondering, yes, the blockchain can be hacked.
Blockchain Security Vulnerabilities – From Here to Eternity
Diamonds are forever, and smart contracts live for as long as the blockchain they are deployed on continues to be used. Consequently, all bugs and blockchain security vulnerabilities also live as long as the contract does.
Typically, each blockchain provides its own programming language to implement smart contracts. Let’s take a closer look.
Smart Contract Languages
Blockchain environments include their own languages for developing smart contracts.
The Ethereum platform, for example, includes the Solidity language to write smart contracts. The creators designed Solidity to be a Turing complete language.
A Turing complete language essentially allows the programmer to implement anything the underlying system is capable of. Consequently, this gives programmers abilities like implementing loops in the code, which can potentially cause blockchain security vulnerabilities.
Turing Completeness
Turing complete languages contain complexity by nature, and complexity invites bugs and vulnerabilities.
The Bitcoin network also has a programming language which it calls Script. Script is purposely not Turing complete to enhance security.
The fewer options that are given to a programmer, the less likely for blockchain security vulnerabilities to enter the system.
To minimize the risk of releasing faulty code into the wild, programmers must understand common pitfalls and anti-patterns inherent in smart contract programming. (Anti-patterns represent bad programming practices).
The DAO Hack: The Reentrancy Problem
The reentrancy problem probably ranks highest among blockchain security vulnerabilities programmers coded into smart contracts. Reentrancy drains an account through multiple expenditures for the same transaction. The use case of processing refunds lends itself to this exploit, but this flaw affects any kind of transaction if not addressed at the design and coding stage.
In one of the most infamous cryptocurrency attacks to date, hackers of the DAO exploited reentrancy. No organizational leader dictated how to run the DAO (or Decentralized Autonomous Organization), and the DAO proposed to empower users with the ability to vote on projects to invest in.
It raised over $150 million in funding in its first month. On June 17, 2016, hackers drained $50 million from the organization through the reentrancy flaw. The hard fork from Ethereum Classic (ETC) to Ethereum (ETH) resulted in an effort to resolve the problems this hack created.
Anti-Pattern Vulnerable to Reentrancy
A vulnerable reentrant logic for code looks like this:
function to process a payment () {
(1) check the validity of the transaction, the recipient, and the account balance;
(2) process the transaction;
(3) update the state of the system to show the transaction has been processed;
}
At first glance, the logic looks correct and complete, but the flaw resides in the order of doing step 2 before step 3.
While the first call to the function continues processing step 2, another call for the same transaction can enter the function. Since state information remains in its initial state and not yet processed in step 3, the second call checks out as a valid transaction to process.
Consequently, the system spends currency for the same obligation a second time. Hackers rush multiple transactions to the function before the state gets set properly.
Cure for Reentrancy
This change to the algorithm corrects the above problem:
function to process a payment () {
(1) check the validity of the transaction, the recipient, and the account balance;
(2) update the state of the system to show the transaction has been processed;
(3) process the transaction;
}
The code must account for all necessary exception handling, and it must account for all logical dependencies as well.
Overflow
Overflow is another common security flaw programmers need to be aware of.
Some programming languages provide strong typing, and others provide weak typing. Strongly typed languages refuse to allow programmers to assign string data to a numeric variable, for example, and weakly typed languages allow such actions.
Strongly typed languages enforce range restrictions. If an array is ten elements, programmers cannot attempt to access the eleventh element. Weakly typed languages allow such behavior, but crashes result. If the maximum allowable value a variable holds is 99, and you assign it a value of 100, watch it crash when you run it!
Consequently, overflow is an exploit that hackers use. If a