Research on the Security of Blockchain Data: A Survey

12/05/2018 ∙ by Liehuang Zhu, et al. ∙ Beijing Institute of Technology 0

With the more and more extensive application of blockchain, blockchain security has been widely concerned by the society and deeply studied by scholars. Moreover, the security of blockchain data directly affects the security of various applications of blockchain. In this survey, we perform a comprehensive classification and summary of the security of blockchain data. First, we present classification of blockchain data attacks. Subsequently, we present the attacks and defenses of blockchain data in terms of privacy, availability, integrity and controllability. Data privacy attacks present data leakage or data obtained by attackers through analysis. Data availability attacks present abnormal or incorrect access to blockchain data. Data integrity attacks present blockchain data being tampered. Data controllability attacks present blockchain data accidentally manipulated by smart contract vulnerability. Finally, we present several important open research directions to identify follow-up studies in this area.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Blockchain NS08 technology combines multiple computer technologies such as encryption, distributed storage, consensus, Peer to Peer (P2P) network, and smart contracts AA14 . These key technologies make blockchain open, secure, trust and smart. Moreover, these techniques allow transactions to be continuously linked to blockchain. Blockchain records all transactions and historical data by establishing a jointly maintained and untampered database. Internet users who do not know each other can reach a credit agreement through smart contracts, point-to-point ledger, or digital encryption without any central trust PM15 . Thereby blockchain has attracted extensive research attention from various industries P17 ; BW17 ; G17 ; BGJ+17 ; ZLZ+15 ; W16 .

With the development of blockchain applications, the security of blockchain data is particularly important, and it is the fundamental enabling factors of many blockchain applications. Currently, attackers use the characteristics of the blockchain itself to conduct various attacks on the blockchain data, which makes the blockchain data face various threats. (1) The openness of blockchain data exposes users’ privacy. Attackers can find the relationship between addresses through transactions RH12 . (2) Network attacks cause abnormal or incorrect access to blockchain data, which undermine the availability of the blockchain data. A Bitcoin address can be associated with an Internet protocol (IP) address; therefore, Attackers can track the correspondence among addresses, users and real identity KPD+14 ; BAD+14 . (3) Blockchain data will be tampered if an attacker passes an attack on the blockchain consensus mechanism. Blockchain is also vulnerable to selfish mining attacks BL13 ; CNL14 ; ES14 . These undermine the integrity of blockchain data. (4) Smart contract vulnerabilities can cause serious problems by making blockchain data not controlled by users LDH16 . In addition to these enumerated problems, there are many other security threats in blockchain, such as mining pool attacks BL13 and miner attacks R11 . These threats seriously affect the data security of blockchain, which threatens the related blockchain applications.

There are some recent surveys about blockchain security. Gervais et al. AGV+16 surveyed security and adversarial strategies of proof of work (PoW). Atzei et al. ABC17 and Luu et al. LDH16 investigated the vulnerabilities of smart contracts. However, these surveys focused on the security and privacy of a certain aspect of blockchain. Li et al. LJC17 summarized some cases of attacks against blockchain 1.0 and 2.0. However, their article lacks systematic description and categorization of threats and countermeasures. With the rapid development of blockchain, many new threats and countermeasures have emerged, and up-to-date research is needed to meet the needs of blockchain development.

Our paper summarizes and analyzes the security of blockchain data. We present the attacks and defenses of blockchain data in terms of the privacy, availability, integrity and controllability. Data privacy attacks include the threats of transaction and identity privacy. Data availability attacks include the threats brought by network traceability and eclipse attacks. Data integrity attacks include the threats brought by double-spending, selfish mining, and block withholding attacks. Data controllability attacks include the vulnerabilities of smart contracts. We present corresponding countermeasures for the threats for each type of attack.

Our main contributions include the following:

  • We created a comprehensive classification and summary of the security of blockchain data.

  • We present the attacks and defenses of blockchain data in terms of the privacy, availability, integrity and controllability.

  • We describe attacks and defenses in a contrastive way. According to blockchain data security features, we present the attack mechanism and the countermeasures. We present the evolution of the attacks and countermeasures.

  • We discuss research hotspots and present several future research directions.

The rest of this paper includes: In section 2, we introduces classification of attacks. In section 3, we present blockchain data challenges. In sections 4, we present corresponding solutions. Finally, we present research directions for the future in section 5 and summarize our survey in section 6.

2 Classification of Blockchain Attacks

Data privacy attacks
Transaction privacy attacks Identity privacy attacks
RH12 ; LZD+16 ; RS13 RH12 ; LZD+16 ; RS13 ; AKR+13 ; M15 ; MPJ+13 ; Z14
Data availability attacks
Network traceability attacks Eclipse attacks
GAN17 ; BJA+15 ; ZAB15 ; KPD+14 ; BAD+14 EAA+15 ; SAT+06 ; BAD+14 ; K14 ; R14 ; BFB14 ; CVE14
Data integrity attacks
Double-spending attacks Selfish mining attacks Block withholding attacks
AJS+00 ; EST10 ; BC18 ; R14 ; GOE12 ; PR16 ES14 ; NL14 ; SSZ16 ; NKM+16 ; CKW+16 R11 ; ES14 ; NL14 ; E15 ; YDY17
Data controllability attacks
Logic problems Semantic misunderstandings Design problems verifier’s dilemma Privacy preservation
KMA16 LDH16 LJR15 KMS16 ; ZCC16
Table 1: Classification of Blockchain Attacks

As previously mentioned, the security of blockchain data is mainly divided into four aspects: privacy, availability, integrity, and controllability. Each aspect contains several attacks, as shown in Table 1. Data privacy attacks refer to data leakage or data obtained by attackers through analysis. In this aspect, we present the threats of transaction and identity privacy. Data availability attacks refer to abnormal or incorrect access to blockchain data. In this aspect, we present the threats brought by network traceability and eclipse attacks. Data integrity attacks refer to blockchain data being tampered. In this aspect, we present the threats brought by double-spending, mining pool, and miner attacks. Data controllability attacks refer to blockchain data accidentally manipulated by smart contract vulnerability. In this aspect, we present the vulnerabilities of smart contracts.

3 Blockchain Data Attacks

3.1 Data Privacy Attacks

Using the transaction process of Bitcoin as an example, we can analyze the threats and corresponding solutions of blockchain data. In Bitcoin, every transaction is traceable. A transaction output is the input to another transaction, thus forming a transaction chain. Based on the chain of transactions, the analyst can obtain the use of any coins and the relevant transactions of any address.

Figure 1: Bitcoin transactions schematic diagram.

As shown in Figure 1, an example illustrates the simple transaction process, assuming that Alice launched transaction , Bob launched transaction , and Mike launched transaction . The relationship of transaction input and output is as shown in the figure.

Potential attackers can analyze users’ transaction and identity privacy by analyzing transaction records, as shown in Figure 2.

Figure 2: Data privacy attacks.

3.1.1 Transaction Privacy Attacks

The transaction input comes from the output of another transaction. Based on the blockchain of transactions, analysts can obtain the following information:

  • The Use of Bitcoin: The Bitcoin came from the mining process, which was first recorded in the miners’ mining address and then transferred to other addresses. Both mining and transaction information will be recorded in the global ledger. Therefore, by analyzing these public data, an attacker can acquire all transactions of any Bitcoin.

  • The Blockchain Transaction Addresses: Each blockchain transaction details the information of all the input and output addresses.

Therefore, analysts can obtain the following information:

  • Finding Bitcoin Relations between Different Addresses: The transfer of the coins between accounts reflects the relationship between accounts. Reid and Harrigan RH12 analyzed the accounts published by WikiLeaks and tallied the balances , Bitcoin sources and flows of the Bitcoin addresses published on the WikiLeaks website. The paper also analyzed a stolen address in Bitcoin and found the five closest addresses to the theft address, revealing the pre- and post-theft Bitcoin flows.

  • Tracking Special Transactions: We can monitor the transaction information of special transactions involving large or suspected malicious acts such as theft, and further trace the flow of Bitcoins through continuous observation. Liao et al. LZD+16 showed the attack of CryptoLocker that extorts Bitcoin by encrypting the victim’s files. The authors studied the relation transactions of public Bitcoin ransomware addresses. 968 addresses that belong to the organization were found, and ransom transactions worth 1128.40 BTC were identified. This information assists in determining the identity of the criminals.

  • Discovering the Rule of Transactions: The Rule of Transactions can reveal the relationship between transactions. Ron and Shamir RS13 focused on the transactions statistics. They traced 364 transactions of more than 50,000 BTC and studied the transactions rules for a transaction of 90,000 BTC . The authors found that the large transactions used a variety of methods to disperse Bitcoins to different addresses. These transaction modes include long chains, fork-merge patterns and self-loops, keeping Bitcoins in , binary tree-like distributions.

3.1.2 Identity Privacy Attacks

There are many clues and side information in blockchain transactions, and it is possible to use these clues and side information to speculate about the identity privacy.

The architecture of Bitcoin can be revealed the following:

  • Multiple Input Addresses belong to the same person or organization. The multiple input transactions are initiated by the same user because each input in a multi-input transaction requires a separate signature RH12 ; LZD+16 ; RS13 .

  • Multiple Output Addresses in the same Coinbase BC18 transaction belong to the same user set. Many miners want to increase their income by joining one mining pool where they participate in collective mining. All miner addresses involved in mining are recorded as the Coinbase transaction output.

  • Input Addresses and Change Address belong to the same user. The change address is generated by the Bitcoin system, which save the change Bitcoins in one transaction CHANGE18 . The features of the change address include the following: the status of the output address is usually only once, the change address only belongs to the transaction input or output in one transaction; and only change address cannot appear in the output address.

The first clues and side information are due to the design of Bitcoin itself. By using these clues and side information, analysts can discover the correlation between different addresses and reduce the anonymity of blockchain addresses. Meiklejohn et al. MPJ+13

used heuristic analysis to analyze transaction data in the blockchain to identify the same user’s different addresses. They analyzed the public addresses of Silk Road and the addresses associated with some theft cases and found many related addresses. Zhao et al.

Z14 proposed a clustering process for Bitcoin transaction data. Based on the analysis of 35,587,286 addresses in the global ledger of Bitcoin, there were 13,062,822 different users.

The second clues and side information is the following:

  • Transaction Characteristics: The transaction characteristics are usually related to the actual transaction processes. Many transaction behaviors have their own characteristics in daily life AKR+13 . For example, transactions at breakfast stores often occur in the morning, and the transaction amount is set at one to 20 coins. The gas station transaction time is an average, but the transaction amount is concentrated in a few specific values, i.e., 100 coins, 200 coins, or full price (changes based on the change of oil price have universal regularity).

  • Transaction Rules: Each user has a different transaction behavior. Monaco M15 analyzed the transaction parameters, and then proposed a method based on parameter identification.

3.2 Data Availability Attacks

The main threat of data availability is to make abnormal or incorrect access to blockchain data.

3.2.1 Network Traceability Attacks

In Bitcoin network, IP address, topology, and transmission information can be obtained by attackers. Based on this information, the analyst can analyze user identity privacy. Each network node is connected to many other nodes through the P2P network, and the connection relationship between these nodes can be analyzed. BAI15 ; AJA+15 .

Transaction traceability is to estimate the transaction propagation path according to the time order that the different nodes send the transaction to arrive at the probe, as shown in Figure

3. Ideally, the originating node is the earliest to arrive at the probe, the neighbor arrives at the neighbor second, and the order the next neighboring nodes arrive at the probe will increase with distance. In the actual environment, the time order of different nodes’ transmitted transactions arriving at probes is affected by many factors, such as network delay and delay transmitting strategy, and the transactions transmitted by the long-distance nodes may arrive earlier. To accurately analyze the matching degree of transaction ranking and node network topology, we will consider a variety of influencing factors and calculate the trading order accuracy.

Figure 3: Transaction traceability mechanism diagram.

Network traceability technology uses the collection of Bitcoin network transmissions of information to analyze the transmission path of Bitcoin transactions in the network, then tracks the transaction-generated server IP information. This technology can directly contact an anonymous transaction via the trade originating node’s IP address to permit traceability. However, the existing network traceability technology has a low accuracy and generally needs additional computing and storage resources; therefore, it is less practical.

Bitcoin users can make double-sided transactions of Bitcoin tokens by creating Bitcoin transactions with other users on servers anywhere in the world GAN17 ; BJA+15 ; ZAB15 . Since the transaction does not require the participation of third parties, and the addresses used by both parties in the transaction are anonymous, the real identity of the Bitcoin traders is hard to find.

Transaction traceability technology desires to track the transmission path of Bitcoin transactions in the network to find the originating node of a transaction, which is the first server node of the transaction in the Bitcoin network. Once a Bitcoin transaction is associated with the IP address of the originating node, the anonymous account number in the transaction can be associated with the user identity, which helps to identify the identity information of the malicious trader and analyze the flow of the Bitcoin funds.

Network traceability technology is to analyze the transaction information transmitted by the Bitcoin network, locate the propagation path of a specific transaction, and then infer the origin node of the transaction.

Koshy et al. KPD+14 analyzed the patterns of Bitcoin transactions in the network and found that we can search for the origin node by using the special transaction mode. For example, a transaction that is transmitted only by one node is usually due to a problem with the transaction format, then this transaction is transmitted only once by the originating node. However, the effect of this method is limited due to the small proportion of all transactions in the special transaction mode (less than 9% of the special transactions in the paper trial).

Biryukov et al. BAD+14 analyzed transaction traceability using neighbor nodes. By using neighbor nodes as the basis for judgment, the accuracy of traceability can be improved. However, the solution must continuously send information to all the nodes in the Bitcoin network, which may cause serious interference to the Bitcoin network and is less practical.

3.2.2 Eclipse Attacks

Heilman et al. EAA+15 described eclipse attack, which exploits the broadcast features of P2P networks to attack. The attacker controls the reception and transmission of all information of the victim node, causing the victim node’s inbound connection to the illegal node.

The attack node maliciously fills the victim node’s routing table before the victim node of the blockchain restarts, forcing the victim node to restart and establish an outgoing connection with the attack address in the routing table EAA+15 SAT+06 . At the same time, the attack node continuously establishes an incoming connection with the victim node. Eventually, the channel of the monopolistic victim node is reached, and the purpose of its information flow is controlled so that it can only receive useless or even malicious information sent by the attack node. If the attack node can successfully implement eclipse attacks on more nodes, it can control the blockchain channel and information flow of more nodes, and gradually control most of the blockchain networks. Attackers can even launch 51% attacks and double-spending attacks on this basis, causing more serious consequences.

The eclipse attack process is usually divided into four steps, as shown in Figure 4 and detailed as follows:

Figure 4: Eclipse attack flow diagram.
  • Populating Tried and New Tables: The blockchain node is capable of receiving the addresses of the unsolicited incoming connections and the unsolicited ADDR message. The addresses of the incoming connections will be stored in the tried table, and the addresses contained in the ADDR message can be inserted directly into the new table. The nodes will not test the addresses’ connectivity. Therefore, when the attack nodes are connected to the victim node through the attack addresses, the attack node can send an ADDR message containing a lot of “trash” IP addresses that will gradually overwrite all legal addresses of the new table. The nodes rarely get network information from their neighbor nodes and DNS seeders. Therefore, when an attacker overwrites the tried and new tables of the victim node, the victim node almost never verifies its authenticity by querying a legitimate peer or sower.

  • Restarting the Victim: The victim node will be restarted by the eclipse attack. After the node is restarted, the victim node can be connected to the attack addresses. The reasons for the Bitcoin node restart include: ISP shutdown, machine shutdown, operating system upgrade of the mining machine, etc BAD+14 ; K14 ; R14 ; BFB14 ; CVE14 .

  • Selecting Outgoing Connections: After the victim node is restarted, if the address is selected from the new table to establish an outgoing connection, all connections fail. Therefore, the victim node is forced to only pick the addresses from the tried table. Because the victim node prefers to choose the updated addresses, all the outgoing connections of the victim node are connected to the attack addresses.

  • Monopolizing the Eclipsed Victim: If the above attack is successful, The attacker must control all incoming connections to the victim node in order to truly monopolize the victim node.

In addition, the eclipse attack will also cause other attacks. The main attacks are shown in Table 2, the details of the attacks will be described in detail in section 5.

Reference Attacks Description
AJS+00 ; EST10 ; BC18 ; GOE12 ; R14 ; PR16 Double-spending threat Using the same cryptocurrency in multiple transactions by a sender
ES14 ; NL14 ; SSZ16 ; NKM+16 ; CKW+16 Selfish mining attack Hiding the excavated blocks to cause the chain to fork
ES14 ; NL14 ; R11 ; E15 ; YDY17 Block withholding attack The attacker never submits any blocks
Table 2: Some other Attacks that may be caused by an Eclipse Attack

3.3 Data Integrity Attacks

Data integrity attacks primarily include double-spending, selfish mining, and block withholding attacks.

3.3.1 Double-Spending Attacks

Double-spending attacks refer to the use of the same cryptocurrency in multiple transactions by a sender. Bitcoins use the PoW system, which has approximately ten minutes of confirmation time between blocks. Therefore, an attacker will implement a the attack in this time interval. In addition, if the attacker has a significant amount of computational power, he or she will be more likely to successfully perform the attack.

Double-spending attack is a unique attack on the bitcoin system that falls into two types:

  • Attacker Used the same Bitcoin to Trade with multiple Users at the same Time: If these trading users complete the transaction without the transaction being recorded in the legal blockchain, the attacker achieves the goal of double spending or even multiple spending R14 ; AJS+00 ; EST10 ; BC18+ ; GOE12 . Although in the multiple transactions launched by the attacker, only one transaction is considered legal and recorded in the blockchain, the transaction has been completed and the attacker has benefited from the attack.

  • Attacker Used his own Computing Power to Launch an Attack: The attacker used the same Bitcoin to trade both transaction and transaction with two users. If the transactions is confirmed to be recorded in the blockchain, transaction is completed. Because the attacker has a powerful computing power, he records transaction in the private blockchain and mines a longer chain than the legal one, prompting transaction to be confirmed and completing transaction PR16 .

Ghassan et al. GOE12 analyzed the double-spending threat of Bitcoin in the fast payment scenario. Figure 5 illustrates the attack model. We assume that the attacker must pay BTCs to a vendor , and creates the transaction to . Simultaneously, to realize double-spending, creates another transaction that has the same BTCs as those involved in ’s inputs. The successful implementation of a double-spending attack must meet the following three requirements:

Figure 5: Double-spending attack model.
  • is added to ’s wallet.

  • is confirmed in the blockchain.

  • ’s service time is less than the time when detects the wrong behavior.

In fact, because of the PoW mechanism, it usually takes ten minutes to prevent double-spending attacks, so it does not apply to quick payment scenarios. Additionally, without a suitable detection mechanism, double-spending attacks can be implemented in a low-cost manner.

3.3.2 Selfish Mining Attacks

Selfish mining attack ES14 is a typical attack on blockchain. A cryptocurrency like Bitcoin requires a high computing power to solve the cryptographic problem for a miner, so the mining becomes very difficult. In view of this, a group of miners (or mining pools) are usually combined with each other and share the rewards after successfully solving the password problem. This helps individual miners produce more continuous and constant income when mining alone.

Eyal et al. ES14 proposed that if there is a group of selfish miners who use selfish mining strategies and succeed, it may invalidate the work of honest miners. A malicious mining pool does not publish the blocks it finds and creates a fork. Therefore, there are public chain maintained by honest miners and the private fork by malicious mining pools. Since the fork is the longest chain in the current network, it will be recognized as a legal chain by honest miners. Therefore, the original public chain and the honest data it contains will be discarded. The results of the study show that usually the selfish mining strategy will get more benefits. At the same time, the analysis shows that if the selfish pool exceeds one third of the total net, the existing protocol will no longer be safe.

Courtois et al. NL14 conducted experimental simulation and theoretical analysis of selfish mining. The results show that the computational waste of Bitcoin is minimal, and it is even decreasing over time. Sapirshtein et al. SSZ16 studied the optimal strategy of the selfish-mining underlying model. Nayak et al. NKM+16 shows when this attack is combined with an eclipse attack, these strategies sometimes result in a gain of 30% depending on the different parameters. Carlsten et al. CKW+16 proposed a more complex selfish mining strategy that led to uneven returns and exceeded default mining and traditional selfish mining. Once deployed, the attack will be profitable, which could result in 51% of attacks or consensus failures.

3.3.3 Block withholding Attack

Block withholding attack R11 is one of the typical attacks on blockchain. In the attack, some malicious attackers who have joined the joint mining pool do not have any mining blocks, which reduces the revenue of the mining pool and wastes the computing power provided by other miners. This kind of attack is also called sabotage attack. Usually, the malicious miners will not have any benefit. The blocker attack will cause different losses to the miners and mining pools, and the mining pools’ losses are relatively large compared to the miners’ low cost. As a result, block withholding attack is more common in competing mining pools and less common in miners ES14 . Block withholding attack diagram is shown in Figure 6.

Figure 6: Block withholding attack diagram.

Courtois et al. NL14 analyzed the actual examples and found that the main hazard of the malicious miners who can profit from this attack is to waste the computing resources of the mining pools and reduce the income of the mining pools. Eyal E15 analyzed the game of miners’ dilemmas, and there is a balance between competing mining pools, which makes miners repeatedly choose whether to attack. Kwon et al. YDY17 extended the BWH attack E15 and proposed a new attack method called fork after withholding (FAW) attack. The attack uses selfish mining attacks based on BWH attacks. The FAW attacks’ frequency is four times as often as BWH attacks, and the attack will also gain an additional 56%. In addition, the research showed that when two pools attack each other, the more computing power, the easier it is to win.

3.4 Data Controllability Attacks

Smart contracts are blockchain-based programs that directly control digital assets. Additionally, it is executed automatically by a computer system. Nick Saab KMA16 indicates that smart contracts are essentially a recognized tool for forming relationships between individuals, institutions and property, i.e., a set of agreements that form relationships and reach consensus. Smart contracts work similar to if-then statements. When a predefined trigger condition is reached, the smart contract is executed.

The most significant feature of smart contracts based on Ethereum is Turing completeness. Smart contracts are written into the blockchain in the form of digitization, which is protected by the blockchain. The entire process of storing, reading and executing by the characteristics of blockchain is transparent and traceable and cannot be changed. If a user wants to modify a smart contract, he or she must control at least 51% of the calculation power.

Figure 7: Smart contract schematic diagram.

The input to a smart contract includes transactions and events. The transactions mainly include transaction data, and the events refer to the description of the transactions. Smart contracts are triggered when conditions are met. Smart contracts exist to allow a complex set of digitized promises with triggering conditions to be properly executed according to the wishes of the participants, as shown in Figure 7.

Reference Classification Description
KMA16 Errors in encoding state machines Coins may not be returned.
KMA16 Failing to use cryptography Attackers can adjust their input according to the user’s input.
KMA16 Misaligned incentives The second user will no longer have any action (i.e., no reward) when he feels he may have failed.
KMA16 Ethereum-specific mistakes The problem causes some bugs.
LDH16 Transaction-ordering dependence If the transaction verification order is different, the execution result is different.
LDH16 Timestamp dependence Miners can attempt different timestamps in advance to calculate the winning value, to award the prize to the winners they desire.
LDH16 Mishandled exceptions If there is an error during the call, it will return to the pre-contract state.
LDH16 Reentrancy vulnerability The new chain is broadcast to the old chain, and the transaction is still successful, resulting in confusion.
LJR15 Resource exhaustion attack by problem givers The miners were unable to mine the next block, causing damage to the miners.
LJR15 Incorrect transaction attack by provers The user not only wastes his or her reward but also does not receive a correct answer.
KMS16 Data feed An attacker could gain valuable information by analyzing the transaction history.
Table 3: Smart Contract Vulnerability Summary

Smart contracts maximize open source and solve the trust issues of traditional services. Developers can validate the code’s original code through compilation to prove the code’s usability. Therefore, smart contracts are applied in various fields such as housing leasing, savings insurance, financial lending, and probation.

However, smart contracts solve the contradiction between the openness and security of the code, currently, there remain other security privacy issues. A smart contract vulnerability summary is shown in Table 3 and Figure 8.

Figure 8: Data controllability attacks.

In the aspect of the programming of smart contracts KMA16 , if the contract itself has a logic trap, the execution result of the smart contract can be changed through certain trigger conditions to generate the result that is beneficial to the developer. Semantic misunderstandings LDH16 may occur during the execution of a smart contract deployed at Ethereum, inconsistent with the notion of a smart contract written by the original developer, causing the result to deviate from the expected performance. Incentives designed for smart contracts LJR15 may create a verifier’s dilemma where honest miners choose to continue verifying or mining to get rewarded when faced with the more difficult task of verifying transactions. For the data privacy protection of smart contracts, the privacy protection of data KMS16 and an authenticated data feed ZCC16 are elaborated. We will detail each threat and its corresponding security method in a later section. After detailing each of the attacks in Table 3, we develop a solution (except for privacy reasons, because they have no vulnerabilities to attack).

3.4.1 Logic Problems of Smart Contracts

Delmolino et al. KMA16 gathered smart contracts written by students, and there are many security issues in the design process. The security of smart contracts is very important in the process of programming them. Even if some malicious miners exist, they will not increase their own profits. They search bugs of contracts, and there will be security pitfalls, although the design and implementation of the contract is very simple. This contract mainly consists of two parts, one for each player to input his or her own results and the other for the contract to determine the winner and send him or her the award.

  • Errors in Encoding State Machines: During the game between the two players, the contract may contain some mistakes. If there is a third player to send coins to in the contract, no one’s coins will be returned. Even a cautious player cannot avoid this situation. Since developers do not fully consider the status of the execution of each step of the contract or clearly define the clear conversion between the states in the programming of smart contracts, these problems arise.

  • Plaintext transmission: Players send their inputs in plaintext in smart contracts is a serious problem. Because the transactions are transmitted through plaintext, malicious players only need to intercept other people’s inputs first and adjust their input results according to other players’ inputs to maximize their profits.

  • Misaligned Incentives: Once a player believes that he or she will lose the game, the player may choose not to continue to send any further messages, thus refusing to pay the winner’s rewards and protecting his or her own interests.

  • Ethereum-specific Mistakes

    • Call-stack Bug: In EVM, there are three locations for data storage, the stack, temporary memory, and permanent memory. Among them, the stack is the only free data storage area; other areas must pay for gas. However, there are some issues that may arise when using the stack. When the stack depth exceeds a certain limit (Ethereum specifies a stack limit of 1024), a stack overflow will occur, and the caller of the contract will have a loss of property.

    • Blockhash Bug: In Ethereum, block.prevhash instruction is used only to calculate the hash value of the 256 recent blocks.

    • Incentive Bugs: There are some incentive bugs in Ethereum, for example, selecting the winner of the election by using a hash of the block as a random beacon. However, miners can selectively withhold blocks to deviate from this value to gain an unfair advantage. If miners mine a new block, they can check whether they win. If they do not win, the miners will keep this block until next block is generated; then, they will receive a second chance to see if they win the game.

    • Other Bugs: One of the important issues that must be considered when designing a smart contract is scalability, as contractual upgrades are inevitable. In EVM, code is completely unmodifiable and it is impossible to load and execute code in memory. The code and data are completely separated. Currently, the upgrade can only be achieved by deploying a new contract, which may require copying all the code in the original contract and redirecting the old contract to the new contract address. Patching the contract or partially upgrading the contract code in EVM is completely impossible.

3.4.2 Semantic Misunderstandings of Smart Contracts

Luu et al. LDH16 documented several several vulnerability in Ethernet smart contracts. These defects refer to differences between the author’s design and actual semantics. We introduce the following four types of security issues and countermeasures:

  • Transaction-Ordering Dependence: The vulnerability is that the order of transaction validation affects the execution result of intelligent contracts. If the transaction verification order is different, the execution result is different. The attacker provided a smart contract with a prize wager and promised generous rewards when the user determined the correct solution. When the user submits the answer and the transaction has not been verified, the attacker will initiate another transaction, making the transaction’s reward value infinitely close to zero. At this point, two unverified transactions appear in the pool. When the miners verify the transactions, the user’s transaction that answers the question after verifying the attacker’s transaction has the user’s rewards significantly reduced; the attacker seldom pays any bonuses to obtain the right answer. In addition, attackers can make miners prioritize their transactions by increasing transaction fees.

  • Timestamp Dependence: The Ethereum states that when the timestamp of a new block generated by the miners is greater than that of the last block and the time difference between the two is less than 900 seconds, the new block is considered valid and its timestamp is legal. Timestamp dependency refers to the implementation of smart contracts that depend on the current timestamp; the results of the execution timestamps vary. If there is a lottery contract, the winning value is calculated from the current timestamp and other variables that are known in advance, and the same code as the lucky number will be awarded. At this point, in the process of mining, miners can attempt different timestamps in advance to calculate the winning value, to award the prize to the winner they desire.

  • Mishandled Exceptions: Ethereum use the send tool to call a contract or call the contract function directly. If there is an error during the call, it will return to the pre-contract state. King of the Ether Throne (KoET) is an Ethereum contract that will make you a king or queen, might grant you riches, and will immortalize your name. A user can become the new king by paying a certain amount of ether; part of the ether will be used to pay the previous king’s remuneration. In the transfer process of the ether, the smart contract did not check the payment results of the transaction, and once the contract call exception occurs, the incumbent kings may also lose their throne and compensation.

  • Reentrancy Vulnerability: Traditional reentrancy attacks refer to the situations in which an attacker sends a packet that has been received by the destination host to achieve deception. While a reentrancy attack on the blockchain is a transaction that has been verified on a chain reappearing on another chain for verification, this attack usually occurs when the blockchains are permanently divergent. The famous TheDao hack, because of the inaccuracy of the intelligent contract code, led to a large vulnerability in the transaction funds. Although permanent divergence is used during a later period, there will be reentrancy attacks. The new chain is broadcast to the old chain, and the transaction is still successful, resulting in confusion.

3.4.3 Design Problems of Smart Contracts

Luu et al. LJR15 presented the verifier’s dilemma, which states that verifiers would make a choice between mining or transaction verification. When the transactions are expensive, miners will decide to bypass their verification and mine to ensure their own profits. As a result, miners are vulnerable to resource depletion or incorrect transaction attacks.

  • Resource Exhaustion Attacks by Problem Givers: Honest miners verify new transactions in accordance with the protocols. Therefore, attackers can broadcast a very large number of transactions, causing other miners to waste a significant amount of calculation power to verify the correctness of the transaction. To prevent this, Ethereum establishes a gas (consumption) mechanism. Each transaction requires a gas limit and a gas price. Gas limit is the maximum amount of Gas consumption allowed by this transaction. Gas price is a tip. If the user does not have sufficient Ether to pay the maximum cost of his or her own settings, the transaction is considered invalid, the previously changed state will be restored, and the consumed gas will not be returned to the user. However, the gas mechanism cannot prevent this scenario. The new block is mined by the attacker. Then, the attacker broadcasts their expensive transactions. Even if the attacker pays considerable transaction fees for the deal, because the fees will be given to the miners who mine a new block regardless of the number of transaction fees, the transaction fees will be returned to attacker’s account.

  • Incorrect Transaction Attack by Provers: When a user asks for a solution to a difficult problem, malicious respondents may provide an incorrect solution, because the transaction verification requires a significant amount of calculation power; therefore, the majority of miners will selectively bypass verification of this transaction, believe it to be correct, and then broadcast it directly to the network, so that the user not only wastes his or her reward but also does not receive the correct answer.

Through these two attacks, it is found that if the malicious miners mine a new block, they can attack without considering the reward. When users create a scale of transactions such as block size, Bitcoin can be repaired through pre-defined standard transactions, but there is no such restriction in Ethereum. They presented a safety model that ensures that the miners who did not perform the agreement received minor rewards, and the honest miners who verified the transaction were not affected by the malicious miners.

3.4.4 Privacy-Preserving Smart Contracts

The global ledger that stores transaction information is public. An attacker could gain valuable information by analyzing the transaction history, including the specific account balance of funds, transaction details, and the flow of specific funds.

4 Blockchain Data Security Protection

4.1 Data Privacy Protection

To ensure the reliability, non-falsification and distributed consistency of the transaction, a special data structure and consensus mechanism are designed. These mechanisms ensure the maintenance of a uniform, high public trust account in distributed untrusted network nodes; however, these mechanisms also lead to privacy risks. The full ledger not only leaks data privacy but also leaks the relation between the traders who are behind the data and the identity privacy RH12 ; LZD+16 ; RS13 ; AKR+13 ; M15 . Therefore, the focus of data privacy protection is to hide the data and the information behind it as much as possible.

We classify different protection mechanisms according to the database privacy protection classification methods, as the following:

4.1.1 Data Distortion

Because the blockchain ledger is public, the attacker can find the relationship of the transaction data; the attacker can then infer the transaction and identity privacy. To prevent this attack, we can adopt a method called Chaum1981 without changing the transaction results; however, this method adds confusion, as shown in Figure 9. Assuming that Alice, Bob, and Mike have transaction addresses , , and , respectively. In the process of mixing coins, first to generate new addresses , , and for them, then to send the coins that need to be traded to them, mix the coins by the mixed addresses , , and and output them to these new addresses , , and , so that others can’t grasp the source of these coins.

Figure 9: Bitcoin mixing service diagram.

The mechanism is classified as follows.

  • The Mixed Coin Scheme based on a Central Node:

    This scheme utilizes third-party nodes for mixing coins, and the process of mixing coins is done at a third-party node. These methods can improve the security of Bitcoin and other digital currencies without additional technology bitlaunder ; bitcoinfog ; blockchain . However, Its defects include:

    • Additional Charge and Mixed Coin with a Slower Speed: A mixed coin service node usually charges a fee. As the mixes increase, the cost rises sharply. The usual delay time is 48 hours, and the transaction costs are between one and three percent.

    • Risk of Theft: In this scheme, the third-party node may not perform the agreement after receiving the user’s coins and steal the user’s coins. The users do not have effective countermeasures.

    • The Mixing Process is leaked by Intermediate Nodes: The third-party node in this scheme understands the entire mixed coin process, and the users cannot guarantee that the third-party node will not leak the mixed coin process information.

    In response to these defects, many improvements have been made. Bonneau et al. BNM+14 proposed an improved decentralized mixed coin that can be audited. Valenta and Rowan VR15 designed a blindcoin scheme that can prevent a third party from divulging the process information. Qing et al. SQY15 presented a blind signature scheme that use the elliptic curve to improve privacy. In 2015, Dash Dash18 , an anonymous digital coin, launched operation. From an economic point of view, Dash solves the threat posed by centralized mixed coin.

  • The Mixed Coin Scheme based on Decentralization:

    The program does not depend on third-party nodes. CoinJoin G13CoinJoin is the original plan. CoinJoin merge multiple transactions into one transaction in which the relationship of the transaction inputs and outputs can be hidden. For a multi-input and multi-output transaction, a potential attacker cannot effectively distinguish the relation between inputs and outputs by analyzing the transaction information. The idea of CoinJoin is used in many anonymous Bitcoin transactions, for example, Dark Wallet G14 , CoinShuffle KyleTorpey18 and JoinMarket BitcoinTalk18 .

    The CoinJoin mechanism enhances the privacy protection capabilities of all users. In a digital currency system, if only a fraction of the nodes uses the CoinJoin agreement, the remainder of the users do not use this protocol, nor do they use the original method.

    The CoinJoin mechanism has many defects, as the following:

    • As other users participate, it also faces threats from the other node.

    • The information of each node participating in the mixed coin will be exposed to the other.

    • If some nodes violate the rules, the mixed coin may fail.

    • The parties involved in the mixed coin transaction will be recorded in the ledger.

Many scholars have proposed solutions. Ruffing et al. RMK14 propose a completely decentralized CoinShuffle. Based on CoinJoin, the CoinShuffle scheme designs an output address shuffling mechanism. This mechanism can complete the mixing process without a third party, and it can also ensure that the mixed coin participant does not know the relationship. However, the scheme is easy to trigger denial-of-service attacks. Bissias et al. BOL+14 designed Xim that adopts a multi-wheel and two-square mixed coin agreement. CoinParty ZGH+15 adopts a secure multiparty computation protocol to implement an improved scheme that can guarantee the effectiveness of the mixed coin process in the case of malicious operation or failure of some hybrid nodes. Monero Monero18 is a new digital coin with a main characteristic of privacy protection. It adopts the ring signature mechanism to realize the mixing process. Compared with other schemes, the process of mixed coin in Monero does not require the participation of users; any user can implement the mixed currency independently. Monero can effectively eliminate the denial-of-service attack on the decentralized coin scheme and assist with the problem of users’ mixed coin leakage.

Mixed coin is widely used in the blockchain digital coin. There are many improvement schemes. We compare and analyze the schemes, as shown in Table 4.

Reference Protocol Reliance on third parties Risk of theft Mixed coins cost Resistance to DoS Peculiarity
Chaum1981 Mix Strong The method is easy to use and is the most widely used.
BNM+14 Mixcoin Strong The proof can be raised to reduce the risk of theft.
VR15 BlindCoin Strong The blind signature mechanism is adopted to avoid leakage.
Dash18 Dash Strong The node that provides a mixed coin increases the cost of a violation by paying a deposit.
G13CoinJoin CoinJoin N/A N/A N/A Weak No third parties involved, so there is no risk of theft.
RMK14 CoinShuffle N/A N/A N/A Weak The participants of the mixed coin do not know the details of the currency.
BOL+14 Xim N/A N/A Strong The method increases the difficulty of DoS attacks using a fee.
ZGH+15 CoinParty N/A N/A N/A Strong The mixing process can still function normally even if some participants violate the rules using the secure multi-party computation.
Monero18 Monero N/A N/A N/A Strong There is no need for multilateral negotiation using the ring signature mechanism.
Table 4: Comparison of mix mechanisms in blockchain

4.1.2 Data Encryption

An encryption mechanism is a common scheme in the field of privacy protection. By encrypting sensitive data, users who hold secret keys can read the data, and others cannot decrypt it, even if they have access to it. Encryption ensures data privacy. In traditional blockchain, application data is stored in plaintext, and any node can access the data. Therefore, using encryption technology to protect privacy in blockchain must ensure that nodes can complete transaction verification tasks on encrypted data. In addition, since blockchain transactions must be jointly verified by all nodes, the impact of encryption mechanisms on validation efficiency must be reduced.

In blockchain, specific transaction information must be encrypted. In digital currency, there have been some protection schemes based on encryption.

  • Monroe Monero18 is an encrypted digital currency. In traditional digital currency, the content of the transaction output address is the receiver’s public key and address information, and the observer can directly determine the coins’ destination. In Monroe, the output address is the new address information obtained by the receiver’s public key and the random parameter generated by the sender. Since the random parameter is only mastered by the sender, the observer cannot determine the relation between the new address information and the receiver. By generating different random parameters, it can be ensured that the output addresses of each transaction are different and there is no correlation between them. There are two key technologies in the Monroe coin, the stealth address and the ring signature. The stealth address is to address the problem of the relevance of the input/output address. A stealth address, while ensuring that the recipient’s address changes every time, makes it impossible for an external attacker to see an address connection, but it does not guarantee anonymity between the sender and the receiver. Therefore, the Monroe coin developed a ring signature scheme. As shown in Figure 10, whenever a sender has to establish a transaction, he or she uses his or her private key and a certain number of public keys selected from other users’ public key. to sign the transaction. When a signature is validated, the user must also use the other person’s public key and parameters in his or her signature. At the same time, the sender must provide the key image to provide identity identification. Both the private and key images are once dense to ensure they cannot be traced.

    Figure 10: Ring signature diagram.
  • Zcash SCG+14 is a new digital currency, formerly known as the Zerocoin MGG+13 project. It is an improvement on Zerocoin. Zcash uses the promise function to encapsulate the source of each transaction and the amount of several parameters, while using zk-SNARKs BCG+13 to prove the transaction. The proof process does not need to reveal relevant information; thus, it can hide the value of the sender and even the inputs and outputs of the transaction. Zcash is the best digital currency for privacy protection at present, but its adoption of the zk-SNARKs algorithm is very slow; it usually takes a minute to generate new proof and there is a bottleneck in efficiency. As shown in Figure 11, the underlying implementation is similar to the structure of Bitcoin, but Zcash is constructed using zk-SNARKs’ decentralized mixed coin pool, and with the mint and pour operations it can perform in complete anonymity . Mint is the process by which a user writes a commitment to a list for a certain amount of cash. The promise must be a one-off serial number, and the user’s private key is calculated and not reversible.

    Figure 11: Zcash schematic diagram.

    Similar to Bitcoin, the increase in the number of Zcash coin (ZEC) is based on mining. The ZEC obtained by a miner can be tracked and recorded, and its use also requires the signature of a private key. Therefore, if you use the ZEC directly, it is similar to Bitcoin, and you can directly complete the transfer between each address; however, it is currently not anonymous. The commitment made by the ZEC operation is not on the surface of the user address but depends on the public key and one one-time random number. When a user wants to spend (i.e., transfer) the ZEC, the user must provide the serial number and a commitment in the commitment list. In this way, the user can spend the ZEC without being completely exposed. The user can also use the redemption operation to extract the ZEC in the pool, the so-called redemption operation. The redemption is a commitment to return to a ZEC similar to the previous one, and the miner does not know which commitment was redeemed for the ZEC. Thus, you do not have to transfer ZEC to anyone, merely place a ZEC in the pool and redeem it; its source is untraceable.

4.1.3 Restricted Release

The restriction release plan is to remove data that are directly related to privacy from the public database. Compared with the previous introduction of the mixed coin and encryption mechanisms, this type of method is completely guaranteed to ensure the security of privacy data. However, this approach has additional restrictions on business scenarios and requires additional modifications to the underlying protocol. Common solutions include the following:

  • Lightning Network and Raiden Network: The lightning network PD15 enables secure out-of-chain transactions. In the lightning network, the majority of the transaction details between users are implemented offline. Only the first and last transactions must be recorded on the blockchain ledger, so it can effectively protect transaction privacy. The Raiden network TH16 is a micropayment channel solution proposed by Ethernet. The Raiden network is directly based on the lightning network and has been developed. Because there are no specific field restrictions on the message format of the Ethernet smart contract, Raiden can introduce a single increment number for the channel balance snapshot, which solves the problem of identification and invalidation of the old version snapshot.

  • Consortium Blockchain and Private Blockchain: Traditional blockchain applications are mostly public blockchain, such as BTC and ETH. In the public blockchain application, anyone is free to be a member of the blockchain network. The maintenance of the transaction data makes the public blockchain application highly credible, but it also brings the threat of identity and data privacy. To better protect privacy, blockchain technology produces a branch of consortium blockchain and private blockchain. Read and write permissions are open to nodes that join the alliance in the consortium blockchain. Read and write permissions are open to one node in the private blockchain.

4.2 Data Availability Protection

4.2.1 Network Traceability Attacks Protection

The blockchain runs on a network with privacy protection so that its topology can be hidden, thereby preventing exposure of identity privacy information. Onion network (Tor) KPD+14 ; BAD+14 is one of the choices. Onion network is an anonymous communication technology, which protects the privacy of message sender and receiver and hides the route of data message passing through the network. Another is Monroe Monero18 . In traditional digital currency, the content of the transaction output address is the receiver’s public key and address information, and the observer can directly determine the coins’ destination. In Monroe, the output address is the new address information obtained by the receiver’s public key and the random parameter generated by the sender.

4.2.2 Eclipse Attacks Protection

Some researchers proposed several ways to solve the eclipse attack attack as follows.

  • Restricting Access: The network node needs to be authenticated. This method can effectively prevent the incoming and outgoing links of the node, so that the malicious node cannot access the blockchain node BAI15 ; AJA+15 ; EAA+15 ; DRN+14 . However,the approach will change the operational architecture of the blockchain.

  • Detecting and Blocking Malicious Nodes: The blockchain uses a malicious node detection mechanism. Dillon et al. DJB14 proposesd an effective scheme for detecting malicious nodes and finds that malicious nodes add them to the blacklist, thereby limiting its further damage.

4.3 Data Integrity Protection

4.3.1 Double-Spending Attack Protection

Karame et al. GOE12 analyzed that the current detection mode uses a “listening period”, which refers to the receiver detecting a collection of transactions after this period to determine whether double-spending exists. The problem with this approach is the attacker may delay the transmission of because the neighbor node will not broadcast detected double-spending. Thus, cannot detect double-spending attacks even after the listening period. The fewer the number of neighbor nodes of the receiving node, the higher the success rate of this attack. Another method is to insert observers into the network, which immediately notify the receiver that double-spending has been detected. Only three observers can effectively detect double-spending attacks, but it requires additional costs. This paper proposed a mechanism to improve transactions’ forwarding function, which is to forward to the neighbor node when a double-spending attack is detected. The detection rate of this mechanism is 100%, with a false negative rate of 0%.

Ruffing et al. TA15 designed a smart contract that allows payees to receive payments asynchronously and impose penalties on double-spending attackers. Eleftherios et al. proposed a new Byzantine consensus mechanism that shortend trading time by 15 to 20 seconds and used collective signatures to make transactions irreversible. George et al. GS15 proposed a new decentralized cryptocurrency RSCoin, the central bank maintains complete control over the coin supply to prevent double spending.

4.3.2 Mining Attack Protection

Miners attack each other during mining to reduce the other party s or overall benefits. Yang et al. YMC17 proposed to establish a game model between two miners to improve the profit of miners through game strategies. When a loyal miner employs a pinning strategy, it can unilaterally set the payoff of a selfish miner within the range of zero to ( is the computing power and is the expansion of profit), regardless of the selfish miner’s strategy. The selfish miner’s payoff is proportional to r but inversely proportional to . The loyal miner cannot control his or her own payoff even with any subclass of the zero-determinant strategy.

Miller et al. AAJ+15 proposed the mining alliance mechanism, in which the members of the mining pool themselves did not trust each other, but submitted a password certificate to demonstrate the work they contributed. Shi S16 changed the consensus mechanism of Bitcoin, in which the value of N is established according to certain rules to ensure the continuous output rate of Bitcoin. The mechanism can improve dispersion and reduce the risk of 51% attack. Gervais et al. AGV+16 analyzed the various parameters of PoW consensus mechanism. They designed the best countermeasures for double spending and selfish mining.

4.4 Data Controllability Protection

4.4.1 Logic Problems of Smart Contracts

  • Errors in Encoding State Machines: The contract stipulates that in the absence of a winning player, the coins should be returned to their respective accounts. In Ethereum or Bitcoin, when multiple parties send input to a smart contract simultaneously, the order of transactions in this case depends on the miner mining the new block.

  • Failing to Use Cryptography: Cryptography is the first line of defense for security protection. Application of cryptography is primarily to ensure binding and hiding. These two major attributes not only ensure that the transaction input is not tampered with but also ensure that the input information is not leaked. Before a message is committed, system need to compute a number that called , and message hashed. The hash value is then sent as input to the contract.

  • Misaligned Incentives: To ensure the correct behavior of all players, some incentives must be offered to ensure that players continue, regardless of winning or losing in accordance with the contract. In this scenario, a time limit can be established for the second player, and if the player submits the input before the time limit, another player will be rewarded. In addition, the game can also require both parties to pay a deposit in advance; if a player performs malicious behavior, the deposit is forfeited, bringing a loss to the player.

  • Ethereum-specific Mistakes: For the Call-stack bug, developers are advised to minimize the use of variables so that functions are as small as possible. For the Blockhash bug, Luu et al. LDH16 solves the blockhash bugs allowing smart contract access to more than 256 blocks For Incentive bugs.

4.4.2 Semantic Misunderstandings of Smart Contracts

Luu et al. LDH16 proposed to modify the operation semantics of Ethernet workshops to solve the above attack vulnerabilities, for example, guarded transactions (for TOD), deterministic timestamp and improved exception handling. However, in practical applications, all Ethernet clients must be upgraded. Then, a system called for detecting smart contracts is proposed, which can be used to verify the problems in an intelligent contract.

4.4.3 Design Problems of Smart Contracts

Luu et al. LJR15 proposed a consensus-based computation protocol to solve the verifier’s dilemma. They want to motivate miners to validate each transaction in each new block. If the miners did not verify the transaction in accordance with the stipulated protocol, they would receive few profits, and the honest miners who verified all the transactions would receive rewards that are unaffected by malicious miners.

4.4.4 Privacy-Preserving Smart Contracts

  • Privacy Preseration: Blockchain is a completely open database; everyone can learn about each account asset and transaction record. Hawk KMS16 is a decentralized smart contract system, and to avoid the transaction plaintext details exposed in blockchain, Hawk programmers write smart private contracts without the implementation of cryptography. The compiler uses an encryption protocol (such as zero knowledge proof) to make the parties interact with the blockchain.

  • Data Feed: Zhang et al. ZCC16 proposed a trusted link between non-blockchain applications and smart contracts,which called Town Crier (TC). It is a trusted link between smart contracts and non-blockchain applications. TC can help CSC deal with real world crimes (such as property crimes) AAE16 .

5 Future Research Directions

The data security issues of blockchain are crucial to the future development of blockchain. Through the understanding and thinking of the research results of many scholars, we propose several future research directions.

5.1 Data Privacy Protection Mechanism based on a Cryptology Algorithm

An effective privacy protection scheme is to prevent an attacker from performing data analysis on the blockchain. However, this kind of scheme will change the underlying architecture of the blockchain, which is not conducive to use in the application. Therefore, it is necessary to design a scheme with high versatility. The solution should consider the computing and storage capabilities of the blockchain nodes.

5.2 Data Availability Promotion Scheme based on Demand

The existing anonymous attacks are of low accuracy and high cost; they do not have the conditions for large-scale implementation, but the security threats of the data availability are universal in the blockchain, which uses P2P as the underlying protocol of the blockchain application, causing the hidden problems. In the future, we will focus on the appropriate access control policies to limit node access and malicious node detection mechanisms to prevent information leakage.

5.3 Defenses Against PoW Attacks and New Consensus Mechanism

Bitcoin’s PoW consensus mechanism requires very strong computing power that have made mining by “normal users” impractical. The collusion of miners or mines is very aggressive. An important research topic is methods to prevent the collusion of miners or mines.

In addition, proof of stake (PoS) KN12 , proof of personhood FJ08 , memory intensive ABF+14 and consensus alliance YGK+10 have been valued by many scholars.

5.4 Verification of Smart Contracts

Smart contracts often have problems with mismatch between expected and actual behavior. But the language of the verification tool limits its possibilities. Non-Turing complete and human-readable languages need further research, which is a future research direction. This is mentioned in AC14 FN16 BCG+16 .

6 Summary

With the development of blockchain, its application is increasingly extensive, but the security of blockchain itself is gradually revealed. These problems pose a serious threat to blockchain and its application. In this survey, we created a comprehensive classification and summary of the security of blockchain. First, we present classification of blockchain attacks. Subsequently, we present the attacks and defenses of blockchain data in terms of the privacy, availability, integrity and controllability. Data privacy attacks present the threats of transaction and identity privacy. Data availability attacks present the threats brought by network traceability and eclipse attacks. Data integrity attacks present the threats brought by double-spending, selfish mining, and block withholding attacks. Data controllability attacks present the vulnerabilities of smart contracts. Finally, we provided several open research issues and provided some suggestions for the improvement of blockchain security.

References

References

  • (1) S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2008, (https://bitcoin.org/bitcoin.pdf).
  • (2) A. M. Antonopoulos, Mastering Bitcoin: Unlocking Digital CryptoCurrencies, O’Reilly Media, Inc., Tim M, 2014.
  • (3) M. Pilkington, Blockchain technology: Principles and applications, Social Science Electronic Publishing, (2015), 1-39.
  • (4) D. Patel, J. Bothra, V. Patel, Blockchain exhumed, In: Proc. of Asia Security and Privacy, 2017, pp. 1-12.
  • (5) C. Burniske, A. White, Bitcoin: Ringing the bell for a new asset class, 2017, (https://research.ark-invest.com/hubfs/1 Download Files ARK-Invest/White Papers/Bitcoin-Ringing-The-Bell-For-A-New-Asset-Class. pdf).
  • (6) Gartner, Top 10 strategic technology trends for 2017, (http://www.gartner.com/technology/topics/trends.jsp), accessed on Dec. 10, 2017.
  • (7) P. Bylica, L. Glen, P. Janiuk, A. Skrzypczak, A. Zawlocki, A probabilistic nanopayment scheme for golem, 2017, (http://golemproject.net/doc/GolemNanopayments.pdf).
  • (8) H. Zhao, X. F. Li, L. K. Zhan, Data integrity protection method for microorganism sampling robots based on blockchain technology, Journal of Huazhong University of Science and Technology, 43.s1(2015):216-219.
  • (9) G. White, K. Brown, Future applications of blockchain: toward a value-based society, In: Proc. of INCITE, 2016, pp. 290-301.
  • (10) F. Reid, M. Harrigan, An analysis of anonymity in the bitcoin system, In: Proc. of IEEE Third International Conference on Privacy, Security, Risk and Trust, 2012, pp. 1318-1326.
  • (11) P. Koshy, D. Koshy, P. McDaniel, An analysis of anonymity in bitcoin using p2p network traffic. In Proc. of Financial Cryptography and Data Security, 2014, pp. 469-485.
  • (12) A. Biryukov, D. Khovratovich, I. Pustogarov, Deanonymisation of clients in bitcoin p2p network. In: Proc. of Computer and Communications Security, 2014, pp. 15-29.
  • (13) L. Bahack, Theoretical bitcoin attacks with less than half of the computational power, Computer Science, 2013, doi: http://arxiv.org/abs/1312.7013v1.
  • (14) S. Bag, S. Ruj, K. Sakurai, Bitcoin block withholding attack: Analysis and mitigation, IEEE Transactions on Information Forensics & Security, 12(8) (2017):1967-1978.
  • (15) I. Eyal and E. G. Sirer, Majority is not enough: Bitcoin mining is vulnerable, In: Proc. of International conference on financial cryptography and data security, 2014, pp. 436-454.
  • (16) L. Luu D.H. Chu H. Olickel P. Saxena A. Hobor, Making smart contracts smarter, In: Proc. of Conference on Computer and Communications Security, 2016, pp. 254-269.
  • (17) M. Rosenfeld, Analysis of bitcoin pooled mining reward systems, Computer Science, 1112.4980 (2011) 1-50.
  • (18) A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdorf , S. Capkun, On the security and performance of proof of work blockchains. In: Proc. of Conference on Computer and Communications Security, 2016, pp. 3-16.
  • (19) N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on ethereum smart contracts (sok), In: Proc. of International Conference on Principles of Security and Trust, 2017, pp. 164-186.
  • (20) X. Q. Li, P. Jiang, T. Chen, X. P. Luo, Q. Y. Wen, A survey on the security of blockchain systems, Future Generation Computer Systems, 2017, doi: 10.1016/j.future.2017.08.020.
  • (21) K. Liao, Z. Zhao, A. Doupe, G. Joon Ahn, Behind closed doors: Measurement and analysis of cryptolocker ransoms in bitcoin, In: Proc. of Electronic Crime Research, 2016, pp. 1-13.
  • (22) D. Ron, A. Shamir, Quantitative analysis of the full bitcoin transaction graph, In: Proc. of International Conference on Financial Cryptography and Data Security, 2013, pp. 6-24.
  • (23) E. Androulaki, G. O. Karame, M. Roeschlin, T. Scherer, S. Capkun, Evaluating user privacy in bitcoin, In: Proc. of International Conference on Financial Cryptography and Data Security, 2013, pp. 34-51.
  • (24) V. Monaco, Identifying bitcoin users by transaction behavior, In: Proc. of Biometric and Surveillance Technology for Human and Activity Identification XII, 9457(2015):945704.
  • (25) Bitcoin Community, Coinbase - bitcoin wiki, (https://en.bitcoin.it/wiki/Coinbase), accessed on Jan. 25, 2018.
  • (26) 8BTC, Change, (http://8btc.com/article-2027-1.html), accessed on Jan. 25, 2018.
  • (27) S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoyy, G. M. Voelker, S. Savage, A fistful of bitcoins: Characterizing payments among men with no names, In: Proc. of Conference on Internet Measurement Conference, 2013, pp. 127-140.
  • (28) C. Zhao, Graph-based forensic investigation of bitcoin transactions, Master’s thesis, Iowa State University, 2014, doi: https://doi.org/10.31274/etd-180810-3797.
  • (29) A. Biryukov, I. Pustogarov, Bitcoin over tor isn’t a good idea, In: Proc. of Security and Privacy, 2015, pp. 122-134.
  • (30) A. Miller, J. Litton, A. Pachulski, N. Gupta, D. Levin, N. Spring, B. Bhattacharjee, Discovering Bitcoin’s public Topology and influential Nodes, (http://cs.umd.edu/projects/coinscope/coinscope.pdf), accessed on Jan. 27, 2018.
  • (31) J. Garay, A. Kiayias, N. Leonardos. The bitcoin backbone protocol with chains of variable difficulty, In: Proc. of Annual International Cryptology Conference, 2017, pp. 291-323.
  • (32) J. Bonneau, A. Miller, J. Clark, A. Narayanan, Sok: Research perspectives and challenges for bitcoin and cryptocurrencies, In: Proc. of Security and Privacy, 2015, pp. 104-121.
  • (33) A. Zohar, Bitcoin: under the hood, Communications of the ACM, 58(9) (2015) 104-113.
  • (34) E. Heilman, A. Kendler, A. Zohar, S. Goldberg, Eclipse attacks on Bitcoin’s peer-to-peer network, In: Proc. of Usenix Conference on Security Symposium, 2015, pp. 129-144.
  • (35) A. Singh, T. W. Ngan, P. Druschel, D. S. Wallach, Eclipse attacks on overlay networks: Threats and defenses, In: Proc. of IEEE International Conference on Computer Communications. Proceedings, 2006, pp. 1-12.
  • (36) King, Bitcoin Hit by ’massive’ DDoS Attack as Tensions Rise, (http://www.forbes.com/sites/leoking/2014/02/12/bitcoin-hit-by-massive-ddos-attack-as-tensions-rise/), accessed on Jan. 25, 2018.
  • (37) M. Vasek, M. Thornton, T. Moore, Empirical analysis of denial-of-service attacks in the bitcoin ecosystem, In: Proc. of International Conference on Financial Cryptography and Data Security, 2014, pp. 57-71.
  • (38) Bitcoin Forum, Bug bounty requested: 10 BTC for huge dos bug in all current bitcoin clients, (https://bitcointalk.org/index.php?topic=944369.msg10376763#msg10376763), accessed on Jan. 26, 2018.
  • (39) CVE, CVE-2013-5700: Remote P2P Crash via Bloom Filters, (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures), accessed on Jan. 26, 2018.
  • (40) N. Asokan, P. A. Janson, M. Steiner, M. Waidner, The state of the art in electronic payment systems, Advances in Computers, 30(9) (2000) 28-35.
  • (41) P. Everaere, I. Simplotryl, I. Traor, Double spending protection for e-cash based on risk management, 2010, In: Proc. of Information Security-International Conference, pp. 394-408.
  • (42) Bitcoin Community, The finney attack, (https://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack), accessed on Jan. 26, 2018.
  • (43) G. O. Karame, E. Androulaki, S. Capkun, Double-spending fast payments in bitcoin, In: Proc. of the 2012 ACM Conference on Computer and Communications Security, CCS’12, 2012, pp. 906-917.
  • (44) C. Pinzon, C. Rocha, Double-spend attack models with time advantange for bitcoin, Electronic Notes in Theoretical Computer Science, 329 (2016) 79-103.
  • (45) N. Courtois, L. Bahack, On subversive miner strategies and block withholding attack in bitcoin digital currency, CoRR, 2014, doi: abs/1402.1718.
  • (46) A. Sapirshtein, Y. Sompolinsky, A. Zohar, Optimal selfish mining strategies in bitcoin, In: Proc. of International Conference on Financial Cryptography and Data Security, 2016, pp. 515-532.
  • (47) K. Nayak, S. Kumar, A. Miller, E. Shi, Stubborn mining: Generalizing selfish mining and combining with an eclipse attack, In: Proc. of Security and Privacy (S&P), 2016, pp. 305-320.
  • (48) M. Carlsten, H. Kalodner, M. S. Weinberg, A. Narayanan, On the instability of bitcoin without the block reward, In: Proc. of ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 154-167.
  • (49) I. Eyal, The miner’s dilemma, In: Proc of 2015 IEEE Symposium on Security and Privacy, 2015, pages 89-103.
  • (50) Y. Kwon, D. Kim, Y. Son, E. Vasserman, Y. Kim, Be selfish and avoid dilemmas: Fork after withholding (faw) attacks on bitcoin, In: Proc. of ACM Sigsac Conference, 2017, pp. 195-209.
  • (51) K. Delmolino, M. Arnett, A. Kosba, A. Miller, E. Shi, Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab, In: Proc. of International Conference on Financial Cryptography and Data Security, 2016, pp. 79-94.
  • (52) L. Luu, J. Teutsch, R. Kulkarni, P. Saxena, Demystifying incentives in the consensus computer, In: Proc. of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, pp. 706-719.
  • (53) A. Kosba, A. Miller, E. Shi, Z. Wen, C. Papamanthou, Hawk: The blockchain model of cryptography and privacy-preserving smart contracts, In: Proc. of Security and Privacy (S&P), 2016, pp. 839-858.
  • (54) F. Zhang, E. Cecchetti, K. Croman, A. Juels, E. Shi, Town crier: An authenticated data feed for smart contracts, In: Proc. of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 270-282.
  • (55) J. Bonneau, A. Narayanan, A. Miller, J. Clark, A. J. Kroll, W. E. Felten, Mixcoin: Anonymity for bitcoin with accountable mixes, In: Proc. of International Conference on Financial Cryptography and Data Security, 2014, pp. 486-504.
  • (56) L. Valenta, B. Rowan, Blindcoin: Blinded, accountable mixes for bitcoin, In: Proc. of International Conference on Financial Cryptography and Data Security, 2015, pp. 112-126.
  • (57) Q. C. Shentu, J. P. Yu, A blind-mixing scheme for bitcoin based on an elliptic curve cryptography blind digital signature algorithm, Computer Science, 2015, doi: http://arxiv.org/abs/1510.05833v1.
  • (58) Dash, (https://www.dash.org/), accessed on Jan. 20, 2018.
  • (59) G. Maxwell, Coinjoin: Bitcoin privacy for the real world, In: Proc. of Post on Bitcoin forum, 2013, (https://bitcointalk.org/index.php?topic=279249).
  • (60) A. Greenberg, ‘dark wallet’ is about to make bitcoin money laundering easier than ever, (https://www.wired.com/2014/04/dark-wallet/), accessed on Jan. 20, 2018.
  • (61) K. Torpey, Coinshuffle aims to improve privacy in bitcoin, (http://insidebitcoins.com/), accessed on Jan. 20, 2018.
  • (62) T. Ruffing, P. M. Sanchez, A. Kate, Coinshuffle: Practical decentralized coin mixing for bitcoin, In: Proc. of European Symposium on Research in Computer Security, 2014, pp. 345-364.
  • (63) Monero, Monero-secure, private, untraceable, (https://getmonero.org/), accessed on Jan. 21, 2018.
  • (64) E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, M. Virza, Zerocash: Decentralized anonymous payments from bitcoin, In: Proc. of Security and Privacy, 2014, pp. 459-474.
  • (65) J. Poon, T. Dryja, The bitcoin lightning network: Scalable off-chain instant payments, 2016, (https://lightning.network/lightning-network-paper.pdf).
  • (66) J. Tremback, Z. Hess, Universal payment channels, 2015, (https://altheamesh.com/documents/universal-payment-channels.pdf).
  • (67) D. L. Chaum, Untraceable electronic mail, return addresses, and digital pseudonyms, Communications of the Acm, 24(2) (1981) 84-88.
  • (68) Bitlaunder, (https://bitlaunder.com/), accessed on Jan. 19, 2018.
  • (69) Bitcoinfog, (http://bitcoinfog.info/), accessed on Jan. 19, 2018.
  • (70) Blockchain, (https://blockchain.info/), accessed on Jan. 19, 2018.
  • (71) Bitcoin Talk, Joinmarket - coinjoin that people will actually use, (https://bitcointalk.org), accessed on Jan. 20, 2018.
  • (72) G. Bissias, A. P. Ozisik, B. N. Levine, M. Liberatore, Sybil-resistant mixing for bitcoin, In: Proc. of The Workshop on Privacy in the Electronic Society, 2014, pp. 149-158.
  • (73) J. H. Ziegeldorf, F. Grossmann, M. Henze, N. Inden, K. Wehrle, Coinparty: Secure multi-party mixing of bitcoins, In: Proc. of ACM Conference on Data and Application Security and Privacy, 2015, pp. 75-86.
  • (74) I. Miers, C. Garman, M. Green, A. D. Rubin, Zerocoin: Anonymous distributed e-cash from bitcoin, In: Proc. of Security and Privacy, 2013, pp. 397-411.
  • (75) E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, M. Virza, Snarks for c: Verifying program executions succinctly and in zero knowledge, In: Proc. of Advances in Cryptology, 2013, pp. 90-108.
  • (76) E. Heilman, A. Kendler, A. Zohar, S. Goldberg, Eclipse attacks on bitcoin’s peer-to-peer network, In: Proc. of Usenix Conference on Security Symposium, 2015, pp. 129-144.
  • (77) R. Dingledine, N. Hopper, G. Kadianakis, N. Mathewson, One fast guard for life (or 9 months), In: Proc of 7th Workshop on Hot Topics in Privacy Enhancing Technologies, 2014, pp. 1-11.
  • (78) J. Dillon, Bitcoin-Development Mailinglist: Protecting Bitcoin against Network-wide DoS Attack, (http://sourceforge.net/p/bitcoin/mailman/message/31168096/), accessed on Jan. 28, 2018.
  • (79) T. Ruffing, A. Kate, D. Schroder, Liar, liar, coins on fire: Penalizing equivocation by loss of bitcoins, In: Proc. of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, pp. 219-230.
  • (80) E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, B. Ford, Enhancing bitcoin security and performance with strong consistency via collective signing, Applied Mathematical Modelling, 37(8) (2016) 5723-5742.
  • (81) G. Danezis, S. Meiklejohn, Centrally banked cryptocurrencies, 2016, (http://www0.cs.ucl.ac.uk/staff/S.Meiklejohn/files/ndss16slides.pdf).
  • (82) Y. Zhen, M. Yue, C. Y. Zhong, T. B. Chang, C. Xin, Zero-determinant strategy for the algorithm optimize of blockchain pow consensus, In: Proc. of Control Conference (CCC), 2017, pp. 1441-1446.
  • (83) A. Miller, A. Kosba, J. Katz, E. Shi, Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions, In: Proc. of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, pp. 680-691.
  • (84) N. Shi, A new proof-of-work mechanism for bitcoin, Financial Innovation, 2(1) (2016) 31.
  • (85) A. Juels, A. Kosba, E. Shi, The ring of gyges: Investigating the future of criminal smart contracts, In: Proc. of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 283-295.
  • (86) S. King, S. Nadal, Ppcoin: Peer-to-peer crypto-currency with proof-of-stake, 2012, (https://peercoin.net/assets/paper/peercoin-paper-nl.pdf).
  • (87) B. Ford, J. Strauss, An offine foundation for online accountable pseudonyms, In: Proc. of the 1st workshop on Social network systems, 2008, pp. 31-36.
  • (88) G. Ateniese, I. Bonacina, A. Faonio, N. Galesi, Proofs of space: When space is of the essence, In: Proc. of International Conference on Security and Cryptography for Networks, 2014, pp. 538-557.
  • (89) H. F. Yu, P. B. Gibbons, M. Kaminsky, F. Xiao, Sybillimit: A near-optimal social network defense against sybil attacks, IEEE/ACM Transactions on Networking, 18(3) (2010) 885-898.
  • (90) A. Churyumov, Byteball: A decentralized system for storage and transfer of value, 2014, (https://bravenewcoin.com/assets/Whitepapers/Byteball.pdf).
  • (91) C. K. Frantz, M. Nowostawski, From institutions to code: Towards automated generation of smart contracts, In: Proc. of Foundations and Applications of Self* Systems, 2016, pp. 210-215.
  • (92) R. G. Brown, Corda: An introduction, 2016, (https://docs.corda.net/releases/release-M7.0/_static/corda-introductory-whitepaper.pdf).