Research on the Security of Blockchain Data: A Survey

Liehuang Zhua, Baokun Zhenga,b, Meng Shena,∗, Feng Gaoa, Hongyu Lia,Kexin Shia

aSchool of Computer Science & Technology, Beijing Institute of Technology, Beijing, China.bSchool of Information Management for Law, China University of Political Science and

Law, Beijing, China.

Abstract

With the more and more extensive application of blockchain, blockchain secu-

rity 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 clas-

sification 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 incor-

rect access to blockchain data. Data integrity attacks present blockchain data

being tampered. Data controllability attacks present blockchain data acciden-

tally manipulated by smart contract vulnerability. Finally, we present several

important open research directions to identify follow-up studies in this area.

Keywords: Security; Privacy; Blockchain; Consensus; Smart Contract

1. Introduction

Blockchain [1] technology combines multiple computer technologies such as

encryption, distributed storage, consensus, Peer to Peer (P2P) network, and

smart contracts [2]. These key technologies make blockchain open, secure, trust

∗Corresponding authorEmail address: shenmeng@bit.edu.cn (Meng Shen)

Preprint submitted to Journal of LATEX Templates December 10, 2018

arX

iv:1

812.

0200

9v2

[cs

.CR

] 7

Dec

201

8

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 con-

tracts, point-to-point ledger, or digital encryption without any central trust

[3]. Thereby blockchain has attracted extensive research attention from various

industries [4, 5, 6, 7, 8, 9].

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 [10]. (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) ad-

dress; therefore, Attackers can track the correspondence among addresses, users

and real identity [11, 12]. (3) Blockchain data will be tampered if an attacker

passes an attack on the blockchain consensus mechanism. Blockchain is also vul-

nerable to selfish mining attacks [13, 14, 15]. These undermine the integrity of

blockchain data. (4) Smart contract vulnerabilities can cause serious problems

by making blockchain data not controlled by users [16]. In addition to these

enumerated problems, there are many other security threats in blockchain, such

as mining pool attacks [13] and miner attacks [17]. 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. [18]

surveyed security and adversarial strategies of proof of work (PoW). Atzei et

al. [19] and Luu et al. [16] investigated the vulnerabilities of smart contracts.

However, these surveys focused on the security and privacy of a certain aspect of

blockchain. Li et al. [20] summarized some cases of attacks against blockchain

2

1.0 and 2.0. However, their article lacks systematic description and categoriza-

tion 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, avail-

ability, 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 with-

holding 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 coun-

termeasures.

• We discuss research hotspots and present several future research direc-

tions.

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.

3

Table 1: Classification of Blockchain Attacks

Data privacy attacks

Transaction privacy attacks Identity privacy attacks

[10, 21, 22] [10, 21, 22, 23, 24, 27, 28]

Data availability attacks

Network traceability attacks Eclipse attacks

[31, 32, 33, 11, 12] [34, 35, 12, 36, 37, 38, 39]

Data integrity attacks

Double-spending attacks Selfish mining attacksBlock withhold-

ing attacks

[40, 41, 25, 37, 43, 44] [15, 45, 46, 47, 48][17, 15, 45, 49,

50]

Data controllability attacks

Logic problemsSemantic misunderstand-

ings

Design prob-

lems verifier’s

dilemma

Privacy

preservation

[51] [16] [52] [53, 54]

2. 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.

4

TXA

TXB

TXC

3.0BTC

2.0BTC

2.5BTC

0.5BTC(change)

2.0BTC

4.0BTC

0.5BTC

(change)

InputOutput/

InputOutput

Figure 1: Bitcoin transactions schematic diagram.

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 trans-

action 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.

As shown in Figure 1, an example illustrates the simple transaction process,

assuming that Alice launched transaction A, Bob launched transaction B, and

Mike launched transaction C. 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.

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

5

Data Privacy Attacks

Address Relations [10]

Special Transactions

[21]

Transaction Rules [22]

Change Address

[26]

Transaction Characteristics

[23]

Transaction Rules [24]

Coinbase Transactions

[25]

Multi-input Transactions

[10,21,22]

Transaction Privacy Threats

Identity Privacy Threats

Figure 2: Data privacy attacks.

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 de-

tails 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 [10] analyzed the accounts published by WikiLeaks

and tallied the balances , Bitcoin sources and flows of the Bitcoin ad-

dresses 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 informa-

tion of special transactions involving large or suspected malicious acts such

as theft, and further trace the flow of Bitcoins through continuous obser-

vation. Liao et al. [21] 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

6

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 [22] 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 saving accounts, 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 [10, 21, 22].

• Multiple Output Addresses in the same Coinbase [25] 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 [26]. 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.

7

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. [27] 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. [28] 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 [23]. 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

[24] 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

8

...

Victim node Neighbor node

Probe node

①

①

②

②

③

Monitored link

First forwarding

Second forwarding

Third forwarding

Server

Connected path

②

②

①

Transaction propagation path

Neighbor node

Figure 3: Transaction traceability mechanism diagram.

through the P2P network, and the connection relationship between these nodes

can be analyzed. [29, 30].

Transaction traceability is to estimate the transaction propagation path ac-

cording 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 n−th neighboring nodes arrive at the probe will increase with distance.

In the actual environment, the time order of different nodes’ transmitted trans-

actions 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.

Network traceability technology uses the collection of Bitcoin network trans-

missions 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 net-

9

work 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 cre-

ating Bitcoin transactions with other users on servers anywhere in the world

[31, 32, 33]. Since the transaction does not require the participation of third

parties, and the addresses used by both parties in the transaction are anony-

mous, 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. [11] 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. [12] 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.

10

3.2.2. Eclipse Attacks

Heilman et al. [34] 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 [34]

[35]. 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:

• Populating Tried and New Tables: The blockchain node is capable of re-

ceiving the addresses of the unsolicited incoming connections and the un-

solicited 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

11

Control multiple attack addresses

Create incoming connections periodically

Send ADDR message to victim nodes

Restart victim nodes

Reselect the outgoing node

Successful attack

Monopolize the eclipsed victim

Figure 4: Eclipse attack flow diagram.

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 [12, 36, 37, 38, 39].

• 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.

12

Table 2: Some other Attacks that may be caused by an Eclipse Attack

Reference Attacks Description

[40, 41, 25, 43, 37, 44]Double-spending

threat

Using the same cryptocurrency in mul-

tiple transactions by a sender

[15, 45, 46, 47, 48] Selfish mining attackHiding the excavated blocks to cause

the chain to fork

[15, 45, 17, 49, 50]Block withholding at-

tackThe attacker never submits any blocks

• 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.

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 mul-

tiple transactions by a sender. Bitcoins use the PoW system, which has approxi-

mately 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 transac-

13

Bitcoin Network

Attacker

Attacker

Vendor

Bitcoin Mining Pools

Figure 5: Double-spending attack model.

tion being recorded in the legal blockchain, the attacker achieves the goal

of double spending or even multiple spending [37, 40, 41, 42, 43]. Although

in the multiple transactions launched by the attacker, only one transac-

tion 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 at-

tacker used the same Bitcoin to trade both transaction A and transaction

B with two users. If the transactions A is confirmed to be recorded in the

blockchain, transaction A is completed. Because the attacker has a pow-

erful computing power, he records transaction B in the private blockchain

and mines a longer chain than the legal one, prompting transaction B to

be confirmed and completing transaction B [44].

Ghassan et al. [43] analyzed the double-spending threat of Bitcoin in the

fast payment scenario. Figure 5 illustrates the attack model. We assume that

the attacker A must pay BTCs to a vendor V , and A creates the transaction

TXv to V . Simultaneously, to realize double-spending, A creates another trans-

action TXa that has the same BTCs as those involved in TXv’s inputs. The

successful implementation of a double-spending attack must meet the following

three requirements:

• TRv is added to V ’s wallet.

14

• TRa is confirmed in the blockchain.

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

In fact, because of the PoW mechanism, it usually takes ten minutes to pre-

vent 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 [15] 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. [15] 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. [45] conducted experimental simulation and theoretical anal-

ysis of selfish mining. The results show that the computational waste of Bitcoin

is minimal, and it is even decreasing over time. Sapirshtein et al. [46] studied the

optimal strategy of the selfish-mining underlying model. Nayak et al. [47] shows

when this attack is combined with an eclipse attack, these strategies sometimes

15

Bitcoin Network

Miners α Miners α Miners α' Miners α' Miners β Miners β

Pool #1 Pool #2

Figure 6: Block withholding attack diagram.

result in a gain of 30% depending on the different parameters. Carlsten et al.

[48] 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 [17] 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 [15]. Block withholding attack diagram

is shown in Figure 6.

Courtois et al. [45] 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 [49] analyzed the game of miners’ dilemmas, and there

16

Smart ContractValue|State

Transactions Sending Value to the Contract

EventsSending information to the contract

Transactions Sending Value from the Contract

EventsSending information from the contract

Replicated, shared ledger

Figure 7: Smart contract schematic diagram.

is a balance between competing mining pools, which makes miners repeatedly

choose whether to attack. Kwon et al. [50] extended the BWH attack [49] 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 [51] 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.

The input to a smart contract includes transactions and events. The transac-

17

tions 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 con-

ditions to be properly executed according to the wishes of the participants, as

shown in Figure 7.

Table 3: Smart Contract Vulnerability Summary

Reference Classification Description

[51]Errors in encoding state ma-

chinesCoins may not be returned.

[51] Failing to use cryptographyAttackers can adjust their input ac-

cording to the user’s input.

[51] Misaligned incentives

The second user will no longer have any

action (i.e., no reward) when he feels he

may have failed.

[51] Ethereum-specific mistakes The problem causes some bugs.

[16]Transaction-ordering depen-

dence

If the transaction verification order is

different, the execution result is differ-

ent.

[16] Timestamp dependence

Miners can attempt different times-

tamps in advance to calculate the win-

ning value, to award the prize to the

winners they desire.

[16] Mishandled exceptionsIf there is an error during the call, it

will return to the pre-contract state.

[16] Reentrancy vulnerability

The new chain is broadcast to the old

chain, and the transaction is still suc-

cessful, resulting in confusion.

[52]Resource exhaustion attack

by problem givers

The miners were unable to mine the

next block, causing damage to the min-

ers.

[52]Incorrect transaction attack

by provers

The user not only wastes his or her re-

ward but also does not receive a correct

answer.

[53] Data feed

An attacker could gain valuable infor-

mation by analyzing the transaction

history.

18

Data Controllabili-ty Attacks

Failing to Use Cryptography [51]

Misaligned Incentives

[51]

Timestamp Dependence

[16]

Mishandled Exceptions

[16]

Data Feed [53]

Resource ExhaustionAttack [52]

Incorrect TransactionAttack [52]

Errors in EncodingState Machines [51]

Transaction-Ordering

Dependence [16]

Ethereum-Specific Mistakes [51]

Reentrancy Vulnerability

[16]

Privacy Preservation

Logic Problems

Semantic Misunderstandings

Design Problems

Figure 8: Data controllability attacks.

Smart contracts maximize open source and solve the trust issues of tradi-

tional SAAS 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.

In the aspect of the programming of smart contracts [51], 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 [16] 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 [52] 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

19

protection of data [53] and an authenticated data feed [54] 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. [51] 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.

20

• Ethereum-specific Mistakes

– Call-stack Bug: In EVM, there are three locations for data stor-

age, 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 ex-

ample, 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 min-

ers 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 up-

grades 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 upgrad-

ing the contract code in EVM is completely impossible.

3.4.2. Semantic Misunderstandings of Smart Contracts

Luu et al. [16] documented several several vulnerability in Ethernet smart

contracts. These defects refer to differences between the author’s design and

21

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 dif-

ferent. The attacker provided a smart contract with a prize wager and

promised generous rewards when the user determined the correct solu-

tion. When the user submits the answer and the transaction has not been

verified, the attacker will initiate another transaction, making the trans-

action’s reward value infinitely close to zero. At this point, two unverified

transactions appear in the pool. When the miners verify the transac-

tions, 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 addi-

tion, 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

22

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 sit-

uations 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 reap-

pearing 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. [52] 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

23

of the transaction. To prevent this, Ethereum establishes a gas (consump-

tion) 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 mecha-

nism 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 num-

ber 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 so-

lution, 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 broad-

cast 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.

24

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 ac-

count 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 pri-

vacy [10, 21, 22, 23, 24]. 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 pri-

vacy 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 mixed coin [67]

without changing the transaction results; however, this method adds confusion,

as shown in Figure 9. Assuming that Alice, Bob, and Mike have transaction

addresses Alice1, Bob1, and Mike1, respectively. In the process of mixing coins,

first to generate new addresses Alice2, Bob2, and Mike2 for them, then to send

the coins that need to be traded to them, mix the coins by the mixed addresses

Mix1, Mix2, and Mix3 and output them to these new addresses Alice2, Bob2,

and Mike2, so that others can’t grasp the source of these coins.

The mixed coin mechanism is classified as follows.

25

Alice1

Bob1

Mike1

Alice2

Bob2

Mike2

Alice2

Bob2

Mike2

1BTC

1BTC

1BTC

1BTC

1BTC

1BTC

Figure 9: Bitcoin mixing service diagram.

• 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 [68, 69, 70]. 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. Bon-

neau et al. [55] proposed an improved decentralized mixed coin that can

be audited. Valenta and Rowan [56] designed a blindcoin scheme that

can prevent a third party from divulging the process information. Qing et

26

al. [57] presented a blind signature scheme that use the elliptic curve to

improve privacy. In 2015, Dash [58], 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 [59] 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 at-

tacker cannot effectively distinguish the relation between inputs and out-

puts by analyzing the transaction information. The idea of CoinJoin is

used in many anonymous Bitcoin transactions, for example, Dark Wallet

[60], CoinShuffle [61] and JoinMarket [71].

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. [62] propose a com-

pletely 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

27

coin participant does not know the relationship. However, the scheme is easy

to trigger denial-of-service attacks. Bissias et al. [72] designed Xim that adopts

a multi-wheel and two-square mixed coin agreement. CoinParty [73] 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 [63] is a new digital coin with

a main characteristic of privacy protection. It adopts the ring signature mecha-

nism 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.

4.1.2. Data Encryption

An encryption mechanism is a common scheme in the field of privacy protec-

tion. 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 [63] is an encrypted digital currency. In traditional digital cur-

rency, the content of the transaction output address is the receiver’s public

key and address information, and the observer can directly determine the

28

Table 4: Comparison of mix mechanisms in blockchain

Reference Protocol

Reliance

on third

parties

Risk of

theft

Mixed

coins

cost

Resistance

to DoSPeculiarity

[67] Mix√ √ √

Strong

The method is easy to

use and is the most

widely used.

[55] Mixcoin√ √ √

Strong

The proof can be raised

to reduce the risk of

theft.

[56] BlindCoin√ √ √

Strong

The blind signature

mechanism is adopted to

avoid leakage.

[58] Dash√ √ √

Strong

The node that provides

a mixed coin increases

the cost of a violation by

paying a deposit.

[59] CoinJoin N/A N/A N/A Weak

No third parties in-

volved, so there is no

risk of theft.

[62] CoinShuffle N/A N/A N/A Weak

The participants of the

mixed coin do not know

the details of the cur-

rency.

[72] Xim N/A N/A√

Strong

The method increases

the difficulty of DoS at-

tacks using a fee.

[73] 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.

[63] Monero N/A N/A N/A Strong

There is no need for mul-

tilateral negotiation us-

ing the ring signature

mechanism.

coins’ destination. In Monroe, the output address is the new address in-

formation obtained by the receiver’s public key and the random parameter

29

Public Key

Private Key

Data

Encrypted Data

Figure 10: Ring signature diagram.

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 pa-

rameters, 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 signa-

ture. The stealth address is to address the problem of the relevance of

the input/output address. A stealth address, while ensuring that the re-

cipient’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 devel-

oped 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.

30

ZEC TXmint

ZEC

Normal TX

Zcash block 2

ZEC TXmint

ZEC

Normal TX

Zcash block 2

ZEC ZEC

ZEC

Zcash block 1

ZEC ZEC

ZEC

Zcash block 1

ZEC TXpour

ZEC

Zcash block 4

ZEC TXpour

ZEC

Zcash block 4

ZEC TXmint

ZEC

Zcash block 3

ZEC TXmint

ZEC

Zcash block 3

CM1

CM2

CM3

CM4

CM5

CM6

CM7

CM8

Pour

CM1

CM2

CM3

CM4

CM5

CM6

CM7

CM8

Pour

Mixed coins pool based on zk-SNARKs (untraceability)

CM=commitment

ZEC=Zcash coins

Figure 11: Zcash schematic diagram.

• Zcash [64] is a new digital currency, formerly known as the Zerocoin [74]

project. It is an improvement on Zerocoin. Zcash uses the promise func-

tion to encapsulate the source of each transaction and the amount of

several parameters, while using zk-SNARKs [75] 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.

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

31

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 modifica-

tions to the underlying protocol. Common solutions include the following:

• Lightning Network and Raiden Network: The lightning network [65] en-

ables secure out-of-chain transactions. In the lightning network, the ma-

jority 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 net-

work [66] 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 incre-

ment number for the channel balance snapshot, which solves the problem

of identification and invalidation of the old version snapshot.

32

• 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 technol-

ogy 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 topol-

ogy can be hidden, thereby preventing exposure of identity privacy information.

Onion network (Tor) [11, 12] is one of the choices. Onion network is an anony-

mous 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 [63]. In traditional digital currency, the content of the trans-

action output address is the receiver’s public key and address information, and

the observer can directly determine the coins’ destination. In Monroe, the out-

put 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 [29,

33

30, 34, 77]. 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. [78] 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. [43] 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 TRa because the

neighbor node will not broadcast detected double-spending. Thus, V 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. [79] 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 short-

end trading time by 15 to 20 seconds and used collective signatures to make

transactions irreversible. George et al. [81] proposed a new decentralized cryp-

tocurrency RSCoin, the central bank maintains complete control over the coin

supply to prevent double spending.

34

4.3.2. Mining Attack Protection

Miners attack each other during mining to reduce the other partys or overall

benefits. Yang et al. [82] 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 r/2 − c (c is the computing power and r 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 c. The loyal

miner cannot control his or her own payoff even with any subclass of the zero-

determinant strategy.

Miller et al. [83] 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 [84] 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. [18] 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 respec-

tive 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

35

information is not leaked. Before a message M is committed, system need

to compute a number that called nonce, nonce and message M 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. [16] 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. [16] proposed to modify the operation semantics of Ethernet

workshops to solve the above attack vulnerabilities, for example, guarded trans-

actions (for TOD), deterministic timestamp and improved exception handling.

However, in practical applications, all Ethernet clients must be upgraded. Then,

a system called OY ENTE 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. [52] 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.

36

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 [53] is a

decentralized smart contract system, and to avoid the transaction plain-

text 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. [54] 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 applica-

tions. TC can help CSC deal with real world crimes (such as property

crimes) [85].

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 per-

forming 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

37

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) [86], proof of personhood [87], memory

intensive [88] and consensus alliance [89] 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 possibili-

ties. Non-Turing complete and human-readable languages need further research,

which is a future research direction. This is mentioned in [90] [91] [92].

6. Summary

With the development of blockchain, its application is increasingly exten-

sive, but the security of blockchain itself is gradually revealed. These problems

pose a serious threat to blockchain and its application. In this survey, we cre-

ated 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 transac-

tion and identity privacy. Data availability attacks present the threats brought

by network traceability and eclipse attacks. Data integrity attacks present the

38

threats brought by double-spending, selfish mining, and block withholding at-

tacks. 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 CryptoCurren-

cies, 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. Za-

wlocki, 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 microor-

ganism sampling robots based on blockchain technology, Journal of Huazhong

University of Science and Technology, 43.s1(2015):216-219.

39

[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 vulnera-

ble, In: Proc. of International conference on financial cryptography and data

security, 2014, pp. 436-454.

[16] L. LuuD.H. ChuH. OlickelP. SaxenaA. Hobor, Making smart contracts

smarter, In: Proc. of Conference on Computer and Communications Secu-

rity, 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.

40

[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: Measure-

ment 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, Eval-

uating user privacy in bitcoin, In: Proc. of International Conference on Fi-

nancial 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.

41

[28] C. Zhao, Graph-based forensic investigation of bitcoin transactions, Mas-

ter’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.

42

[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), ac-

cessed 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 Commu-

nications 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 with-

holding attack in bitcoin digital currency, CoRR, 2014, doi: abs/1402.1718.

43

[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 instabil-

ity 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 Secu-

rity 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.

44

[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 Inter-

national 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 ellip-

tic 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.

45

[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 dis-

tributed 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.

46

[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: Pro-

tecting 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 equiv-

ocation 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 col-

lective 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.

47

[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 auto-

mated generation of smart contracts, In: Proc. of Foundations and Applica-

tions 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).

48