# A Survey on EOSIO Systems Security: Vulnerability, Attack, and Mitigation

Ningyu He  Peking UniversityBeijingChina<EMAIL_ADDRESS>,  Haoyu Wang
Huazhong University of Science and TechnologyHubeiChina<EMAIL_ADDRESS>,  Lei Wu  Zhejiang UniversityZhejiangChina<EMAIL_ADDRESS>,  Xiapu Luo
The Hong Kong Polytechnic UniversityHong KongChina<EMAIL_ADDRESS>,
Yao Guo  Peking UniversityBeijingChina<EMAIL_ADDRESS>and  Xiangqun Chen
Peking UniversityBeijingChina<EMAIL_ADDRESS>
###### Abstract.

EOSIO, as one of the most representative blockchain 3.0 platforms, involves
lots of new features, e.g., delegated proof of stake consensus algorithm and
updatable smart contracts, enabling a much higher transaction per second and
the prosperous decentralized applications (DApps) ecosystem. According to the
statistics, it has reached nearly 18 billion USD, taking the third place of
the whole cryptocurrency market, following Bitcoin and Ethereum. Loopholes,
however, are hiding in the shadows. EOSBet, a famous gambling DApp, was
attacked twice within a month and lost more than 1 million USD. No existing
work has surveyed the EOSIO from a security researcher’s perspective. To fill
this gap, in this paper, we collected all occurred attack events against
EOSIO, and systematically studied their root causes, i.e., vulnerabilities
lurked in all relying components for EOSIO, as well as the corresponding
attacks and mitigations. We also summarized some best practices for DApp
developers, EOSIO official team, and security researchers for future
directions.

EOSIO, Blockchain, Smart Contract

††ccs: Security and privacy Distributed systems security††ccs: General and
reference Surveys and overviews

##  1\. Introduction

When Satoshi Nakamoto released the whitepaper of Bitcoin in 2008 (Nakamoto,
2019), cryptocurrency has become one of the most popular topics in the area of
computer science and finance. By the time of writing, Bitcoin is still the
leading one, far beyond the second place, of numerous kind of
cryptocurrencies, with the market capitalization of more than 134 Billion USD
(bit, 2020a). As the Bitcoin’s follower, Ethereum, who takes the second place,
brings in the concept of smart contract, in which the programmer are allowed
to interact with the data stored in blockchain by the means of programmable
script.

However, these early-staged implementation has a fatal limitation: a poor
scalability. The Bitcoin can only theoretically support 27 transactions per
second (TPS) at most (bit, 2020b); while Ethereum can achieve approximately 50
TPS (coindesk, 2019). Moreover, the Ethereum is still in ongoing development,
the frequently adding and deleting of features in its programming language
lead to developers’ unfamiliarity and unexpected behaviors. Lots of works and
technical blogs (Atzei et al., 2017; PeckShield Inc., 2020; SlowMist Zone,
2020) have indicated kinds of vulnerabilities existed in Ethereum smart
contract and its virtual machine. At the meanwhile, several works (Wang et
al., 2020b; Gao et al., 2019; Grech et al., 2018; Torres et al., 2018) focused
on the vulnerabilities’ detection in a variety of ways. Therefore, lots of
competitors emerged, one of the most influential products is EOSIO (EOSIO,
2019).

EOSIO launched its initial coin offering (FRANKENFIELD, 2019) (ICO) in 2017,
and raised more than 4 billion USD which is the largest one ever (Rooney,
2018). Its main purpose is to be Ethereum alternative, thus EOSIO improves
upon intrinsic shortcomings of Ethereum, e.g., scalability and speed.
According to a EOSIO network monitor (eos, 2020a), it have reached around
4,000 TPS in history, which is tenfolds higher than Ethereum’s and Bitcoin’s.
Except for its high TPS, EOSIO choose C++ as its smart contract language, and
WebAssembly (web, 2019) (Wasm) as its target language executed in EOS Virtual
Machine (EOS VM). Though Wasm is relatively younger than C++, it is endorsed
by several influential technical companies. Additionally, Wasm aims to execute
at native speed by taking advantage of common hardware capabilities.
Therefore, the high TPS and efficiency of EOSIO smart contract bring EOSIO a
huge success. For example, EOSIO has successfully surpassed Ethereum in
decentralized applications (DApp) transactions just three months after its
launch in June 2018 (CRAIG RUSSO, 2018), and further increased dozens of times
after another several months.

However, due to developer’s unfamiliarity of developing EOSIO smart contract,
kinds of vulnerabilities has been introduced. For example, EOSBet (Aurora Tech
N.V., 2020), one of the most famous gambling DApp in EOSIO, have been attacked
twice in just one month (EOS, 2018; PeckShield Inc., 2018a) due to the lack of
verification of two different key arguments in transaction respectively. In
these two attacks, EOSBet has lost nearly 190 thousand of EOS, which was more
than 1 million USD according to the exchange rate then. According to several
blockchain security companies’ blogs, forums and official announcements, we
have counted 113 attacks against several kinds of vulnerabilities just within
one year after EOSIO launched.

Except for vulnerabilities imported in smart contract by developers, EOS VM,
the stack-based machine used to execute smart contract, also has some inherent
flaws that are used by some attackers (Chen, 2018; PeckShield Inc., 2018b).
Additionally, EOSIO utilizes an energy-saved and efficient consensus
algorithm, delegated proof-of-stake (dpo, 2020) (DPoS), as its consensus
algorithm instead of widely-used proof-of-work (PoW). Lots of novel
characteristics are introduced by DPoS and EOSIO new transaction model, e.g.,
block producer, action and transaction. Some of them can result in unexpected
behaviors which are not considered by the official.

This paper makes the following contributions:

  1. (1)

We present the first systematic exposition of the vulnerabilities in EOSIO
ecosystem, ranging from smart contracts to the consensus algorithm. The
hierarchical presentation of vulnerabilities clearly illustrates the direct
causes of these loopholes which can be referenced by DApp developers and
security researchers;

  2. (2)

We comprehensively survey all existing attack events against all
vulnerabilities, as well as their direct consequence, attack tactics and
corresponding countermeasures;

  3. (3)

We well study all existing mitigations on identifying vulnerabilities or
happened attack events, including program analysis and transaction analysis.
Moreover, we propose a set of best practices for developers to avoid financial
losses as much as possible.

The whole paper is organized as follows: §2 depicts the whole picture of EOSIO
blockchain platform and performs a comparison between Ethereum smart contract
and EOSIO’s on bytecode level. Then, §3 and §4 introduce the underlying
principles of vulnerabilities and attacks, which are collected from several
well-known sources, like (PeckShield Inc., 2020; SlowMist Zone, 2020; Michel,
2021a), respectively. Moreover, §5 summarizes best practices and current
existing work whose targets are all against security issues of EOSIO smart
contracts. Finally, we propose some best practices in §6 to DApp developers,
EOSIO official team and security researchers according to the observation from
the previous three sections, and §7 summarizes existing related work from
several perspectives.

##  2\. Background

In this section, we will briefly introduce the key concepts related to the
EOSIO platform to facilitate the understanding of this work. As shown in Fig
1, according to their dependency, we divide the components of EOSIO into five
categories: application layer, data layer, consensus layer, network layer and
environment. In application layer, EOS Virtual Machine (EOS VM) runs on each
nodes in EOSIO, responsible for executing smart contracts that are invoked by
other accounts. All these interactions between accounts are achieved by
transactions (and actions) and notifications with their carrying permission,
which are all packaged and stored at data layer. Moreover, as we mentioned in
§1, EOSIO significantly outperforms Bitcoin and Ethereum in terms of
Transactions Per Second (TPS) and prospers in DApp ecosystem. This is mainly
due to its adopted consensus algorithm and resource system, which will be
introduced in consensus layer. As an auxiliary component, environment offers
several key technology to serve the above three layers, e.g., a user-friendly
front-end interface and a trustworthy back-end serve can support the
application layer. Last, blocks, as the basic unit that will be propagated
across all nodes, are created and relayed in the network layer, played as
infrastructure for all these stuff. For full details, readers can refer to the
official documents (e.g., (EOSIO, 2018)) for a systematic illustration.

Figure 1. The architecture of EOSIO.

###  2.1. Application Layer

####  2.1.1. Account

Instead of the unreadable and random-like address adopted by Ethereum and
Bitcoin to identify accounts, the account name of EOSIO is composed of at most
12 characters. And EOSIO requires the uniqueness of all accounts’ name to
avoid identity impersonation. Moreover, unlike the distinction between
External Owned Account (EOA) and smart contract in Ethereum (Coinbase, 2019),
there is only one type of account in EOSIO, which can be regarded as a normal
account and a smart contract simultaneously.

####  2.1.2. Smart Contract

As we mentioned in §2.1.1, an account can be seen as a smart contract
sometimes. To be specific, if a piece of compiled smart contract bytecode is
stored in one’s account, the account performs pre-defined logic written in the
contract once it is invoked. Similar to one’s balance, EOSIO smart contract is
updatable. The mutability of smart contract not only allows the developers to
patch loopholes, but also introduces users’ concern that the unexpected
behaviors may happen if they are not aware of the update. EOSIO smart
contracts are written in C++, and compiled to WebAssembly (Wasm) (web, 2019),
a well-structured assembly-like language.

####  2.1.3. EOS VM

As with Ethereum, EOSIO adopts a virtual machine to execute the smart
contracts, named as EOSIO Virtual Machine (EOS VM), embedded in each nodes of
EOSIO. EOS VM is a stack-based machine, i.e., all the operands and operators
are pushed into the popped from a stack. Moreover, EOSIO supports another two
sections: local and global, to share data within a function or across
functions, respectively. Furthermore, EOS VM provides a random-accessible
linear array called memory to store the unbounded and non-permanent data,
e.g., a string that will be printed out.

###  2.2. Data Layer

Block is the basic unit that will be appended to EOSIO blockchain, the
decentralized ledger. A block consists of two key components: block header and
block body. The former one contains some meta data, e.g., block height,
timestamp; the latter one is composed of transactions. In EOSIO, a transaction
can be further divided into actions, in which it carried the invoker’s
permission to authorize behaviors. Moreover, EOSIO introduces a notification
mechanism that enables message delivering between accounts.

####  2.2.1. Transaction & Action

Each transaction in EOSIO is packed as a transaction instance. Moreover, each
transaction is composed of two components: transaction header and a list of
action instances. To be specific, the former one contains meta data, like
transaction ID and its belonged block ID prefix; the latter one is a string of
linked action instances. Each action instance corresponds to an atomic
behavior in EOSIO, consisting of four components: account name, action name,
action data, and authorization list. The first three respectively represent
the invoked account name, function name and concrete data to invoke the
function; while the last one is the invoker’s authorization to the current
action instance (detailed in §2.2.3).

Moreover, actions can be created explicitly to invoke a smart contract, or
generated implicitly as the side effect alongside other actions. Thus, actions
are divided into two categories: explicit action and implicit (inline) action.
Explicit action is represented as an outermost and isolated action instance,
like the action #1 and the action #n in Fig. 2; and implicit action shares the
same context to which its parent action belongs. For example, the inline
action action #n.1 is the side effect when executing action #n, thus these two
actions share an action instance. Note that both explicit and implicit actions
are executed in synchronous mechanism, it is necessary, however, for EOSIO to
support the asynchronous execution because a single transaction has to be
finished within 30 ms (Michel, 2018) to avoid the congestion. Therefore, EOSIO
allows an action to invoke a deferred action as the action #n.2 in Fig. 2. The
deferred action will be embedded in a future transaction after the delay
period set by its initiator.

Similar to the Ethereum’s rollback mechanism, any failure within a transaction
will lead to its reversion, but it will not affect other already on-chained
transactions. For example, if action #n.1 failed, the whole transaction #1
will be reverted; if action #n.2 in transaction #m fails, the transaction #m
will be reverted but the transaction #1 will keep everything intact.

Figure 2. The model of transaction and action in EOSIO.

Figure 3. The process of transferring EOS from user to dapp.

####  2.2.2. Notification

EOSIO imports the notification mechanism to enable message delivering between
accounts. Specifically, a smart contract can initiate a notification by
require_recipient( ) within a function. For example, the native token, dubbed
EOS, is issued by an official account: eosio.token, in which it maintains a
balance table for all holders. Therefore, as depicted in Fig. 3, if the user
intends to transfer EOS to the dapp, he has to request the transfer function
in eosio.token firstly to update the corresponding rows of balance table. Once
the update finished, eosio.token will notify both of the payer and payee that
the following logic can be performed continously (step 2 and 3). Received
notification is handled by a fixed entry-point function: apply, which must be
implemented by each smart contract and will be detailed in §2.2.4.

Figure 4. The hierarchical permissions of alice, and the corresponding
authority table of permission transfer.

####  2.2.3. Permission System

In EOSIO, each account is associated with a permission system. An concrete
example, the permission system of alice, is shown in Fig. 4 Specifically, the
permission system follows hierarchical structure, and there are always two
default permissions: owner and active. Specifically, owner sits at the root of
the permission hierarchy and correspond to one’s highest permission; and
active permission can do anything except changing the key associated with
current account (controlled by the owner). Following the hierarchical
structure, accounts are allowed to create new permissions, like the transfer
under the active permission. Moreover, each permission is linked to an
authority table, in which it specifies the threshold that should be satisfied
at least to perform the action which requires the permission, and the others’
permission with their weights. Within each action instance (see §2.2.1), the
initiator has to designate the carrying permission and signed the action by
the corresponding key of the permission. For example, if a function requires
transfer@alice, the action with either transfer@bob or active@charlie could
satisfy the requirement, as both of them are authorized by transfer@alice.

Table 1. The meaning of arguments in apply under two circumstances. | Direct Invocation | Notification
---|---|---
receiver | The callee | The notified account
code | Current account | The account initiating the notification
action | The invoked function’s name | In which function the notification is initiated

####  2.2.4. Dispatcher – An Example

In EOSIO, there is a dispatcher, named apply, responsible for handling the
received action invocations and notifications. Moreover, its name and
signature is fixed as shown in Listing 1. apply takes three arguments as
input: receiver, code, and action. The receiver is the recipient; the action
is the function’s name; and the code indicates in which the code is actually
executed. The concrete meanings of these three arguments under two
circumstances: direct invocation or notification are shown in Table 1.
Therefore, if Listing 1 is the apply instance of dapp in Fig. 3, it only
accepts the notification from official account eosio.token (where code is
eosio.token111The N() in L2 is the native string encoding function implemented
by EOSIO, which will not be explained in the following.) or a direct
invocation (where code is itself).

⬇

1void apply(uint64_t receiver, uint64_t code, uint64_t action) {

2 if(code == _self || code == N(eosio.token)) {

3 switch(action) {

4 // dispatches to corresponding funciton

5 }

6 }

7}

Listing 1: An example of apply in EOSIO smart contract. Note that this is
vulnerable to the fake EOS vulnerability.

###  2.3. Consensus Layer

####  2.3.1. DPoS & Block Producer

The correctness of blockchain is essential for user’s financial security, thus
how to guarantee the data consistency across such a distributed system is the
overriding issue for cryptocurrency. Unlike Bitcoin and Ethereum, who utilizes
traditional energy-consumed PoW consensus algorithm, EOSIO adopts delegated
proof of stake (DPoS), a more efficient and environment-friendly one.
Specifically, all the accounts in EOSIO network are entitled to delegate their
rights to someone whom they entirely believe in, and only the top 21 trusted
accounts are called block producer (BP). These 21 BPs are responsible for
constructing blocks in turn. Once a BP is on duty, it is responsible for
verifying the correctness of the signature and executing actions in the
transaction. After all the actions are executed without any failure, the
transaction will be appended to a new block’s body, which will then be
broadcasted and validated by other nodes. While the block is validated by a
supermajority of BPs ($>2/3$), the block, including the transactions inside,
will be irreversible. Note that the order of producing blocks is negotiated in
advance among those BPs, thus competitive mining process is unnecessary and
deprecated in DPoS.

####  2.3.2. Resource Model

Similarly to other blockchain platforms, executing transactions and
constructing blocks charges fee from initiators to prevent denial of service
attack. However, EOSIO does not calculate fee by length of data (e.g.,
Bitcoin) (Greg Walker, 2016) or executed opcode (e.g., Ethereum) (Emanuel
Coen, 2020), it introduces three key concepts to represent resources: NET, CPU
and RAM. Specifically, all these three types of resources are provided by BPs,
i.e., transaction validators and block constructors. NET is used to measure
the amount of data that can be sent within a transaction, and CPU limits the
maximum execution time of a transaction. These two are jointly called
bandwidth. RAM limits the maximum space that can be occupied to store
permanent data222The data is stored in the BPs’ RAM to accelerate the
retrieving process.. An account can exchange NET and CPU by mortgaging EOS,
but has to buy RAM due to its scarcity. Users are free to use the bandwidth
resources as long as there are available ones, i.e., not be mortgaged by any
other accounts. However, the price of mortgaging bandwidth resources
fluctuates, depending on how much EOS are staked in total.

###  2.4. Network Layer

EOSIO also adopts P2P network to broadcast messages among the nodes
distributed across the world. In this work, however, we mainly focus on the
vulnerabilities existed in its above layers: application, data and consensus
layers. Therefore, the network layer is a black box for us in this work. For
more details about EOSIO network layer, e.g., block and transaction
propagation and P2P protocol, please refer to the official documentation
(EOSIO, 2018).

###  2.5. Environment

For all these layers mentioned above, it is necessary for them to be supported
by some infrastructures. To be specific, for DApp developers on the
application layer, they need to provide user-friendly front-end interfaces and
back-end servers to perform the corresponding functionalities, e.g., random
number generation. For items stored in the data layer, they have to be indexed
in a multi-indexed database to conduct an efficient CRUD333Create, Read,
Update, and Delete operations. Last, the underlying cryptography plays an
important role for the consensus layer, like validating transactions and
blocks. The reason of we separate the environment from the EOSIO’s
architecture is attacks against components of environment can be easily
addressed out of the EOSIO’s scope, which consequently leading to a modular
and clear abstraction for EOSIO.

###  2.6. Comparison between EOSIO smart contract and Ethereum’s

Table 2. Comparison between EOSIO smart contract and Ethereum’s | Ethereum smart contract | EOSIO smart contract
---|---|---
Source Language | Solidity | C++
Target Language | EVM Bytecode / EWasm (future) | WebAssembly
Amount of Instructions | 154 | 172
Type of Instructions | - |  | Float number related instructions;
---
Typecast related instructions;
br_table instruction;
Control Flow Complexity | Simple | Complicated
Running Environment | Ethereum VM | EOS VM
Data Structure in VM | stack, memory, storage | stack, local, global, memory, table

Table 2 depicts the comparison between EOSIO smart contract and Ethereum’s. As
we can see, though they are written in different programming languages
(Solidity and C++), they both store the bytecode in the blockchain.
Interestingly, Ethereum also plans to support EWasm (ewasm, 2020), a variant
of WebAssembly, in the future upgrade. Compared with Ethereum smart contract,
EOSIO’s is more complicated in both quantity and variety of bytecode
instructions. Specifically, Ethereum contains 32 PUSH, 16 DUP and SWAP to
handle different length of data. EOSIO, however, pre-defines four types of
data, i.e., i32, i64, f32 and f64, to abstract all data structure, including
string and struct. Moreover, EOSIO supports float number related instructions
and type conversion between above four data types, which are not supported in
Ethereum. And br_table, which enables multi forks simultaneously like swtich-
case, plays an important role in the control flow of EOSIO smart contract.
According to (He et al., 2021), the authors claimed that: generally, EOSIO
smart contracts is more complicated than Ethereum’s in terms of control flow.

Except for the distinction located in smart contracts, their running
environments, i.e., virtual machines, also exist some differences. In
Ethereum, both operands and operators are pushed into and popped from the
stack. The memory and storage, which adopt simple key-value structure, are
used to store temporary and permanent data, respectively. In EOSIO, the stack
plays an identical role. Whether the data is stored in the local or global
depends on whether the data can be shared between functions. The memory and
table structures are totally different with the Ethereum VM. Specifically, the
former one can be randomly accessible, which is implemented by store and load
instructions with pointers; the latter one is used to CRUD permanent data,
which is achieved by a multi-index database integrated into the EOSIO (see
§2.5). Consequently, EOSIO is more complicated than Ethereum in both smart
contract and running environment level.

##  3\. Vulnerability

To cover as many types of vulnerabilities related to EOSIO smart contract as
possible, we did a comprehensive investigation from different sources, like
blogs from security companies (PeckShield Inc., 2020; SlowMist Zone, 2020),
forums (bit, 2020c; eos, 2020b) and official announcements related to attack
events. After collecting all these information, we manually audit the source
code or reverse engineering the WebAssembly bytecode (if the source code is
not available) of the corresponding smart contracts. Consequently, in this
section, we discussed all the observed vulnerabilities in the wild, as well as
the root cause and the status, i.e., it has already eliminated by official or
still open and can be avoided by best practice. To ease the reference, we
adopt notation $\mathcal{V}_{i}$ to refer to each vulnerabilities (as shown in
Fig. 5). In the following, we discuss the vulnerabilities according to its
belonged layers.

Figure 5. The vulnerabilities in EOSIO, and their corresponding locations and
causes.

###  3.1. Vulnerabilities in Application Layer

####  3.1.1. asset Overflow ($\mathcal{V}_{1}$)

This type of vulnerability is first observed in (BCSEC, 2018). Specifically,
EOSIO adopts a user-defined struct, named asset, to encapsulate a certain
amount of token. With the uniform definition of asset and its overloaded
operators, developers can easily present a piece of money (token) and
implement arithmetic operations on the token with the same symbol. The source
code of official implementation of multiplication on asset is shown in Listing
2

⬇

1asset& operator*=(int64_t a) {

2 eosio_assert(a == 0 || (amount * a) / a == amount, "multiplication overflow
or underflow");

3 eosio_assert(-max_amount <= amount, "multiplication underflow");

4 eosio_assert(amount <= max_amount, "multiplication overflow");

5 amount *= a;

6 return *this;

7}

Listing 2: The source code of implementation of multiplication on asset.

As we can see from L2, it performs a standard implementation of
overflow/underflow verification. Then, it returns the result after
guaranteeing it ranges from the minimum and maximum limit. However, any source
code, including the library functions, will be compiled to Wasm bytecode
format (see §2.1.2) to execute on EOS VM. Listing 3 shows the corresponding
Wasm bytecode of L2.

⬇

1(call $eosio_assert

2 (i32.const 1) // always true

3 (i32.const 224) // "multiplication overflow or underflow")

4)

Listing 3: The compiled (with -O3 optimization) Wasm bytecode corresponding to
L2 in Listing 2.

We can see that the first argument of assertion is always true, which
invalidates the overflow/underflow check. The reason behind is when both
operands are signed integers, the result of overflowed multiplication is
undefined (Regehr, 2010). Coincidently, some compilers with high-level
optimization (like -O3 in EOSIO) will generate unexpected behaviors
encountering undefined result. The overflow of asset could result in the
unexpected consumption of any type of tokens. As this vulnerability is
imported by the mis-implementation of official library contract, it is patched
timely (ass, 2018).

####  3.1.2. Insufficient code verification ($\mathcal{V}_{2}$)

Fake EOS is the most representative vulnerability in EOSIO, as it is
introduced by the mis-implemented apply function (see §2.2.4). Hence, lots of
contracts were attacked against this vulnerability (EOS, 2018; Quan et al.,
2019; Huang et al., 2020a). Specifically, its appearance is due to the neglect
or improper verification of argument code in apply function, which can be
further divided into two circumstances:

  1. (1)

No validation on the code field. Suppose an account (e.g., eosio.token1) also
issued a token called EOS by duplicating the official contract in eosio.token.
The malicious user could request the transfer in eosio.token1 to transfer the
fake EOS to a victim, like the process depicted in Fig. 3. If the victim’s
apply happens not to check if the value in code is eosio.token, the official
one, the victim would be deceived by a worthless and faked EOS token.

  2. (2)

Even if developers update the apply as Listing 1, which only accepts the
direct invocation or a notification from eosio.token, it is still vulnerable.
The malicious user could call the transfer function directly, in which way the
balance for both of them will not be updated. The invocation will then be
forwarded to the transfer function to perform the following logic.

Therefore, the vulnerability can only be prevented by a thorough verification
on the code. Specifically, if a contract intends to accept EOS token, both of
action == transfer and code == eosio.token have to be guaranteed
simultaneously or it will be affected by such a vulnerability.

####  3.1.3. Relayable notification ($\mathcal{V}_{3}$)

As we mentioned in §2.2.2, EOSIO innovatively introduces the notification
mechanism. However, the unfamiliarity of contract developers with the new
mechanism may introduce a vulnerability that is named as fake receipt
vulnerability, which is observed in (PeckShield Inc., 2018a). In order to
enhance the flexibility of notification mechanism, EOSIO enables the
rebroadcast of notifications. But to avoid the way like man-in-the-middle
attack (mit, 2021), EOSIO forbids the modifications of rebroadcasted
notification. To this end, if two malicious accounts coordinate and transfer
EOS token to each other, once the payee received the notification from
eosio.token, he can immediately relay the notification to the victim. As both
the code and action are valid, the victim may mistakenly believe that he is
the beneficiary of the transfer. As with the Fake EOS vulnerability, this one
can also be prevented by a careful arguments’ validation, i.e., examining the
to field of the transfer notification to distinguish the actual beneficiary.

####  3.1.4. Predictable Random Number ($\mathcal{V}_{4}$)

Gambling DApps plays an important role in EOSIO’s ecosystem (Huang et al.,
2020b). They heavily depend on pseudo-random number generation (PRNG), which
can be used to determine which player wins the final jackpot. However, current
types of pure on-chained PRNG are all flawed, and are attacked several times
(SlowMist, 2019; PeckShield, 2018; Le, 2018). Specifically, EOSIO’s PRNG
relies on some blockchain state as seeds, e.g., current_time, transaction_id,
and tapos_block_num. The variables like the first two, however, are either
accessible to everyone or deterministic, which leads to the predictable result
of PRNG. As for the tapos_block_num, it refers to the height of the reference
block (typically the previous block). Taking advantage of the deferred
transaction, a future block’s reference block seems unpredictable and is
properly used as a seed of PRNG. It turns out, however, that the variable is
predictable regardless of how many times the delay transactions invoked
(detailed in §4.1.4). To mitigate this vulnerability, on the one hand,
developers can follow a more secure PRNG prototype proposed by Daniel Larimer
(Larimer, 2019); on the other hand, they can utilize (de)centralized oracles
(EOS Titan, 2020; LiquidHarmony, 2020; eos, 2021) or even its back-end server
to generate random number.

####  3.1.5. Re-entrancy ($\mathcal{V}_{5}$)

Re-entrancy is a well-studied vulnerability in Ethereum smart contracts
(Chinen et al., 2020; Rodler et al., 2018), attacks against this vulnerability
are firstly observed in (Michel, 2021b). As with Ethereum, this vulnerability
is because the order between checking key variable and performing sensitive
operations (like function call) is reversed. Taking transferring tokens as an
example, as shown in Fig. 3, after both of the participants are notified by
the token issuer (step 2 and 3), they can perform following logics within
their transfer function (if they have). Intuitively, the order of above
operations is: the payer is notified and the notification is handled by the
transfer, then the same processes performed in payee’s contract. However,
EOSIO processes all the notifications in advance, which brings in a vacuum
period for the payer whose money is spent but the response is not conducted in
transfer. So once the malicious payee receives notifications, he could
immediately inlined invoke the function again and repeat the above process. To
mitigate this vulnerability, developers should always guarantee updating
status before performing operations.

####  3.1.6. Inadequate Permission Verification ($\mathcal{V}_{6}$)

As we mentioned in §2.2.3, every account has its related permission
hierarchical structure, and each action instance would carry an authority
list. Therefore, once the function in which it performs sensitive operations,
e.g., transferring money and updating permanent data, but not conduct a
permission validation, it may be abused by malicious users without
authorization. To be specific, there are three authority validating library
functions in EOSIO:

  * •

require_auth(usr): it validates if the action carries the permission that is
equivalent to usr’s active permission;

  * •

require_auth2(usr, permission): it is more flexible and checks the designated
permission, like the transfer permission in Fig. 4;

  * •

has_auth(usr): different from the above two functions that raise exceptions,
it returns a boolean value indicating whether the usr has authority or not
instead of reverting the transaction immediately if the authentication fails.

Therefore, to prevent such a vulnerability, the developer is required to
utilize one of these three functions to perform strict authorization
validation, especially before any sensitive operations.

###  3.2. Vulnerabilities in Data Layer

####  3.2.1. Freely invoked inlined action ($\mathcal{V}_{7}$)

Since EOSIO smart contracts are updatable and developers have no obligation to
inform users that the contract is updated. Therefore, if an updated contract
performs malicious behavior, it may result in financial losses for its users.
As we explained in §2.2.1, the inlined action inherits the context of its
parent action instance, including the carrying permission. For a malicious
contract, it is possible to initiate another inlined action after being
invoked by an action with other’s active permission. In this way, the newly
invoked inlined action inherits the victim’s permission to perform operations,
e.g., transferring EOS, on behalf of the victim. The immediate reason behind
this vulnerability is that no additional authorizations are required to invoke
inlined actions on behalf of others. Hence, EOSIO officially introduces a
preserved permission: eosio.code, which should be granted in advance to
indicate that the someone completely believes one’s code, even if it can be
arbitrarily updated.

####  3.2.2. Uncheck status ($\mathcal{V}_{8}$)

Similar to the status field in Ethereum’s and Bitcoin’s transaction, which
indicates if the transaction executes successfully, in EOSIO transaction there
is also a status field whose possible values include: executed, soft_fail,
hard_fail, delayed and expired. Note that only the ‘executed’ status indicates
the validity and irreversibility of a transaction, which can then be
considered as a mandatory prerequisite for service providing. If the service
provider, like centralized exchanges, does not strictly verify the status
field, there may be financial losses for them, like the attack event
(SlowMist, 2019a). The mitigation is obvious, i.e., only accept the
transactions with the ‘executed’ status before providing services.

####  3.2.3. Arbitrary Rollback ($\mathcal{V}_{9}$)

As we mentioned in §2.2.1, an action’s failure would result in its located
transaction’s rollback. Some gambling DApps adopt improper bet-reveal strategy
which results in malicious reversion from attackers, like the way in
(SlowMist, 2019a, b). Generally speaking, a round of game playing in gambling
DApp consists of: receiving the bet from players, calculating a random number,
and returning the jackpot to the winner. However, if the above three steps are
all done within a single transaction, a malicious user could append an
implicit action to examine changes on his balance to determine if he is the
winner. If he is not, he can deliberately revert the whole transaction by a
simple failed assertion. Such a rollback will lead to return of the money
previously placed to the attacker’s account. The mitigation for DApp
developers is to split bet and reveal logic into separate transactions.

###  3.3. Vulnerabilities in Consensus Layer

####  3.3.1. Exploitation on Blacklist ($\mathcal{V}_{10}$)

EOSIO adopts DPoS as its consensus algorithm, which depends on 21 BPs to
validate transactions and construct blocks. To improve the stability of the
network, BP can configure a blacklist consisting of users who are considered
malicious. Transactions invoked from any of the blacklisted users will be
dropped and reverted unconditionally. Some attackers have maliciously
exploited this mechanism, leading to financial losses for some gambling DApps
(SlowMist, 2019a). For example, the blacklisted players can brute-forcely
attack a gambling DApp by trying all possible results with initiating
transactions, which would be dropped and reverted by the BP. Thus, as long as
they can somehow learn which result is collided with the correct answer, they
can initiate another transaction immediately with the answer by another non-
blacklisted account. To mitigate this vulnerability, the gambling DApps should
adopt a more secure mechanism, e.g., making the results imperceptible or
changing randomly in each round.

####  3.3.2. Top-priority deferred transaction ($\mathcal{V}_{11}$)

As explained in §2.2.1, EOSIO introduces deferred transaction to allow
transactions whose executing time longer than 30ms exist for some reasons. To
guarantee deferred transactions can be executed on time, EOSIO endows them
with highest priority. Therefore, some malicious accounts deliberately invoked
deferred transactions in which they looped endlessly, or even schedule another
deferred transaction to make it syncing across BPs. According to (PeckShield
Inc., 2019e), paralyzing more than 100 blocks would only take 0.4 EOS as
mortgaging for resources. During the attack period, most of the blocks can
only contain no more than 2 transactions. As this vulnerability is due to the
implementation of EOSIO, the official has patched it by dividing normal
transactions and deferred transactions into two pools to guarantee a
percentage of normal transactions can at least be executed in each round.

####  3.3.3. Deficient Resource System ($\mathcal{V}_{12}$)

In most cases, EOSIO’s resource system allows users to freely use or exchange
resources by mortgaging EOS with a relative low price. But under extreme
resource-shortage situations, like after the online of EIDOS (eid, 2020), a
spam DApp that exhausts existing resources, current resource system has
revealed its flaws. In EOSIO, there are two mainstream ways to obtain
resources: 1) mortgage from the official accounts with a fluctuated price
(depending on the total staked amount of EOS); and 2) renting a huge amount of
but time-limited (typically 30 days) resources by a relative small amount of
EOS (depending on the total amount of not being lent resources) from REX, a
lending platform (rex, 2020) which allows accounts to deposit his/her idle EOS
and resources to earn interests. However, the EIDOS project was so popular
that has almost drained out all the loanable resources in both official
contracts and REX with a reasonable price. According to statistics (Perez et
al., 2020), the transactions related to EIDOS project has accounted for more
than 99%, and the resource price went exaggeratedly high. EOSIO official did
not make any changes to the resource model. Fortunately, EIDOS project only
lasted for 15 months and automatically ended in January 2021, which eventually
led to a return to normal resource prices.

####  3.3.4. Assignable resource payer ($\mathcal{V}_{13}$)

Executing a transaction costs CPU and storing permanent data requires RAM (see
§2.3.2). Both of these resources need to be staked or purchased in advance by
transaction initiators. However, EOSIO officially allows one account to pay
for the cost of spending resources on behalf of the other one. In some cases,
this can lead to resource hijacking attacks (PeckShield Inc., 2019a;
Sotnichek, 2018), resulting in senseless waste or malicious exploitation for
profit.

For CPU resource, EOSIO introduced a new feature (cpu, 2018) that allows the
first account who authorizes the transaction pays for all the consumed CPU.
Some DApps, thus, attract players to participate by paying CPU for accounts.
However, malicious accounts could embed inlined actions into the transaction
to perform unexpected behaviors without costs. As for RAM resource, EOSIO
allows accounts to designate the RAM payer when executing the table-related
library functions, like put, whose second argument indicates the payer of used
RAM. Malicious accounts could drain all RAM belonging to the victim by
embedding lots of put functions into a transaction with the victim’s active
permission. To mitigate the these two vulnerabilities: 1) disable features
introduced in (cpu, 2018) to pay CPU for others; and 2) use a proxy contract,
who has limited RAM resources, to perform actions.

###  3.4. Vulnerabilities in Environment

####  3.4.1. Abnormal parser ($\mathcal{V}_{14}$)

This vulnerability is first observed in the attack against DApp eosblue.one
(PeckShield Inc., 2019d). To be specific, there is a memo field in each
transaction, which is typically used to carry additional information, such as
the dice number when player places a bet. Some back-end server of gambling
DApps utilize this mechanism to parse the player’s betting options. However,
if the processing logic of memo parser is vulnerable, it would be attacked by
carefully constructed content, e.g., the SQL injection.

####  3.4.2. Private key compromising ($\mathcal{V}_{15}$)

This type of vulnerability is firstly observed in the attack (EOSIO.SG, 2018),
and similar cases also reported in (SlowMist Zone, 2020). After compromising
the private key, attacker could perform arbitrary actions, e.g., transferring
tokens and initiating transactions, on behalf of the victim without
authorization. This will result in both of the reputational loss and financial
loss for the victims or even other accounts and platforms.

###  3.5. Discussion

As we can see from Fig. 5, there are 4 root causes for all these 15
vulnerabilities, including: EOSIO Toolchain, Smart Contract Programming, EOSIO
Design, and Human Factors.

####  3.5.1. EOSIO Toolchain

There is only 1 vulnerability related to this cause, that is asset overflow
($\mathcal{V}_{1}$). Specifically, as EOSIO smart contract is written in C++,
then compiled to Wasm bytecode, and finally executed on EOS VM. EOSIO has to
introduce a not mature-enough toolchain to complete the pipeline. So far, only
one bug was introduced by it, i.e., compiling stage when the optimization
level is set to -O3. Fortunately, after the vulnerability is committed to the
official them, it has been patched timely (ass, 2018).

Insight 1: EOSIO’s toolchain is well implemented. Only one bug is directly
related to it but immediately patched by the official team.

####  3.5.2. Smart Contract Programming

Smart contract programming is the most common root cause for vulnerabilities,
relating to 9 vulnerabilities. Specifically, only re-entrancy
($\mathcal{V}_{5}$) and uncheck status ($\mathcal{V}_{8}$) have emerged in
Ethereum, all the others are not even appeared in the traditional software
programming and introduced by EOSIO firstly. These vulnerabilities are due to
either developers’ improper validation on arguments and permissions or a
flawed implementation on its business logic. Therefore, we urge EOSIO smart
contracts developers to adopt best practices in programming contracts,
especially in handling the innovative mechanisms like notification and
inlined/deferred actions carefully.

Insight 2: Smart contract programming is the most common root cause for EOSIO
vulnerabilities. However, all of them can be eliminated by best practices,
thus we urge the developers to be careful in introducing and using these
innovative mechanisms.

####  3.5.3. EOSIO Design

EOSIO’s design results in three vulnerabilities: top-priority deferred
transaction ($\mathcal{V}_{11}$), deficient resource system
($\mathcal{V}_{12}$) and assignable resource payer ($\mathcal{V}_{13}$).
Specifically, the first one has been patched by the official in an update by
splitting the transaction pool of deferred transactions and normal ones, while
the latter two cannot be easily mitigated. The problem would emerge again when
encountering a killer DApp.

Insight 3: EOSIO imports and adopts some new mechanisms, e.g., DPoS consensus,
most of which are recognized as excellent solutions. However, the resource
system that was intended to allow low-cost interactions among accounts is
proven flawed under extreme situations. We call for a new robust solution.

####  3.5.4. Human Factors

Human factors, e.g., social engineering (soc, 2021), are also observed in the
traditional vulnerabilities. In EOSIO, because some operations are still
cannot be achieved purely on-chain (like random number generation), the
security of back-end server, as well as the front-end interface of DApps,
still should not be underestimated. Indeed, some existing attacks were against
the vulnerabilities located in the end-server of DApps, like abnormal parser
($\mathcal{V}_{14}$) and private key compromising ($\mathcal{V}_{15}$), thus
we also stress on the security issues of off-chained components for DApp
developers.

Insight 4: Except for the on-chain security issues, the components located in
environment should also be attached importance by contracts’ developers, or
the human factors would also result in severe financial losses.

##  4\. Attack

In this section, we would present all the attacks related to the
vulnerabilities shown in §3. Specifically, we will group the attacks, referred
as $\mathcal{A}_{1}$ to $\mathcal{A}_{19}$, according to positions of the
corresponding vulnerabilities. For each attack, we detail its victim’s
background, direct impact, and the attack tactic. As for the perspicuous
relationships between vulnerability, attack and the corresponding impact, we
depict them in Fig. 6. Note that we omit the attack against vulnerabilities in
environment layer, i.e., $\mathcal{V}_{14}$ and $\mathcal{V}_{15}$, because
both of them are closely related to human factors that are beyond the scope of
this paper.

Figure 6. The attacks in EOSIO, and their corresponding vulnerabilities and
consequences.

###  4.1. Attacks in Application Layer

####  4.1.1. Integer overflow attack ($\mathcal{A}_{1}$)

eosfo.io is a Fomo3D-like gambling game deployed on EOSIO in account
zyixjmpxrrpr. Specifically, it has a 6-hours countdown, once an arbitrary
player purchases a gem, the token used in the game, the deadline will be
delayed for 30 seconds. All the EOS tokens that are used to purchase the gems
will be accumulated in a prize pool. If the countdown has successfully
decreased as 0, except for the last gem buyer who will get half of the pool,
the remaining tokens will be divided proportionally according to the owned
gems. Therefore, once the countdown approaches to 0, a rational player would
buy a gem to make him as the final beneficiary. However, such a behavior would
also postpone the termination of the game, which will in turn attract other
players.

Recall the vulnerability $\mathcal{V}_{1}$, which may result in integer
overflow encountering multiplication of asset struct. In July 2018, an
attacker successfully exchanged more than $9\times 10^{18}$ gems with $3\times
10^{-4}$
EOS444https://www.bloks.io/transaction/09f3fa6668eb4bc3431a7f6df731a9d80856a1f773564489130b7ae043438ab7?tab=traces
by a well-constructed exploitation on $\mathcal{V}_{1}$. After the attack
transaction, the internal state of the game is messed up, all the following
transactions could exchange numerous gems with an extreme low price (bloks.io,
2021). Moreover, the countdown time has underflowed to a meaningless negative
number. Though the official team of eosfo.io announced that the loophole is
patched and redeployed the game in account eosfoiowolfs, it was attacked by
the same means and suffered more than 60K EOS financial loss (IMEOS, 2018).

####  4.1.2. Fake EOS attack ($\mathcal{A}_{2}$ and $\mathcal{A}_{3}$)

Different from directly transferring tokens between payer and payee, a
centralized official account, eosio.token, takes the responsibility of
updating the balance table of the whole network. Correspondingly, all accounts
can deal with the token transferring request by implementing a simple and
fixed apply entry function. However, improper code validation in apply
($\mathcal{V}_{2}$) would result in two types of fake EOS attack. According to
(He et al., 2021; Quan et al., 2019), these two attacks are prevalent in
EOSIO’s ecosystem and have already result in extreme financial loss for lots
of DApp developers and individual users.

Attack #1 ($\mathcal{A}_{2}$) The first type of fake EOS attack is due to the
lack of verification on code field in victim’s apply function. For example,
the attacker could deploy an account, e.g., issuer, to issue a token that is
also named EOS, as EOSIO does not require the uniqueness of token symbol. Then
the attacker would call the transfer of issuer who would notify the victim
like step 3 in Fig. 3. If the victim’s apply does not examine the
notification’s initiator (also the issuer of the received token), i.e., the
code field, it will be fooled and its transfer function will be invoked
unexpectedly.

⬇

1void apply(uint64_t receiver, uint64_t code, uint64_t action) {

2 auto self = receiver;

3 if(action == N(onerror)) {

4 eosio_assert(code == N(eosio), "onerror action’s are only valid from
eosio");

5 }

6 if(code == self || code == N(eosio.token) || action == N(onerror)) {

7 ... // switch to one action

8 }

9}

Listing 4: The vulnerable dispatcher of EOSBet.

Attack #2 ($\mathcal{A}_{3}$) EOSBet (Aurora Tech N.V., 2020) is a famous
gambling DApp deployed on EOSIO, whose dispatcher is shown in Listing 4. From
ling 6, we can observe that it performed a defensive measure against
$\mathcal{A}_{2}$, i.e., narrowing down the range of acceptable code.
Specifically, the dispatcher only accepts that:

  1. (1)

EOSBet is invoked directly (code == self);

  2. (2)

the notification comes from eosio.token (code == N(eosio.token));

  3. (3)

the notification comes from eosio with the onerror action, indicating an
exception should be caught and handled (code == N(eosio) and action ==
N(onerror))

However, the above three conditions are concatenated by an OR operator that is
limited by short-circuit evaluation (sho, 2020). Thus, an attacker can
directly invoke the transfer function, which will pass the verification on L6
and into the transfer function, as with the notification is received from
eosio.token. In fact, the attacker aabbccddeefg did perform exactly such a
behavior with the manufactured bet in the memo field, thus defrauding the
victim555Bet transaction:
https://www.bloks.io/transaction/58ed3541139bba3f91c11c4981052b2d00bfe7ec6cf20208d357c75cc9f943fc,666Revealing
transaction:
https://www.bloks.io/transaction/a630274390fa17e396f6e87b1cdd4a39fff5178992c296d958565b721ccdd3dc.
Within 15 minutes, the attacker gained more than 44K EOS.

Figure 7. The procedure of fake receipt attack.

####  4.1.3. Fake receipt attack ($\mathcal{A}_{4}$)

After the attack against fake EOS vulnerability, EOSBet, who we mentioned in
$\mathcal{A}_{3}$, was attacked again in October 2018, and suffered more than
142K EOS’s financial loss another time (PeckShield Inc., 2018a). Although the
victim’s dispatcher was patched timely and immune to the vulnerability
$\mathcal{V}_{2}$, this time the attack exploited $\mathcal{V}_{3}$ that is in
the transfer function, as shown in Listing 5

⬇

1void transfer(uint64_t sender, uint64_t receiver) {

2 auto transfer_data = unpack_action_data<st_transfer>();

3 if (transfer_data.from == _self || transfer_data.from == N(eosbetcasino)) {

4 return;

5 }

6 // the following operations to deal with the received EOS tokens

7}

Listing 5: The problematic transfer function of EOSBet.

From §2.2.2, we know the transfer notification initiated from eosio.token will
be dispatched to EOSBet’s transfer. Within the transfer, EOSBet unpacks the
notification and deliberately reverts the notification that is initiated from
itself or its official team’s contract (L3 to L5). Then the following
operations are performed, like generating a random number once receiving bets.
Note that it only restricts the from, not the to, i.e., the real beneficiary
of this transfer.

Taking advantage of $\mathcal{V}_{3}$, the attacker could perform the attack
as shown in Fig. 7. Specifically, the attacker transfers EOS to his accomplice
through eosio.token. Once the accomplice receives the notification, he will
relay the notification immediately to the victim, i.e., dapp, without any
change. As the relayed notification was initiated from the official, it will
pass the fake EOS check (including verifying the code and action). However,
the to field in step 4, indicating the final beneficiary, is not checked by
the EOSBet’s transfer. Thus the fake receipt attack ($\mathcal{A}_{4}$) can
trick the victim into providing services to the attacker by transferring
tokens between two accounts who are both controlled by a single entity.

####  4.1.4. Random number prediction attack ($\mathcal{A}_{5}$,
$\mathcal{A}_{6}$ and $\mathcal{A}_{7}$)

As we introduced in §3.1.4, EOSIO’s PRNG relies on some blockchain states as
seeds and tries to make it unpredictable by utilizing some states generated by
deferred transactions, like tapos_block_num. For gambling DApps, according to
its deferred times between the betting and revealing transactions, we divide
the bet-reveal mechanism into three categories, as depicted in Fig. 8

Figure 8. The strategies in revealing random number.

  * •

Synchronous revealing. As the name implies, the bet and reveal procedures are
located in a single transaction and perform synchronously. However, due to the
rollback rule, players can invoke an inlined action (see §2.2) after the
revealing process to maliciously revert both the revealing and betting
processes to avoid losing money (depicted in $\mathcal{A}_{13}$, see §4.2.4).
Therefore, with the adoption of tapos_block_num, once deferring and multiple
deferring mechanisms are proposed.

  * •

Once deferring. As a special mechanism supported by EOSIO, deferred
transaction can be used in revealing jackpot. As depicted in Fig. 8(a), once
the DApp received the bet from players, it will generate a random number and
reveal the jackpot in a future block (e.g., Block#n) by triggering a deferred
transaction. Intuitively, tapos_block_num in Block#n is unpredictable as it
will point to the latest irreversible block, i.e., the Block#n-1. However,
according to the source code of EOSIO (EOSIO, 2021b), the reference block will
be Block#0, whose metadata can even be retrieved before the bet begins.

  * •

Multiple deferring. As the reference block is deterministic when adopting once
deferring strategy, the multiple deferring is proposed by some developers.
Specifically, as shown in Fig. 8(b), an additional deferred action, reveal1,
is inserted before the reveal function. To this end, the reference block is
Block#1, whose metadata is undeterminated when the betting is performed.

Because the synchronous revealing strategy could be deliberately rollbacked by
attackers, most of the gambling DApps adopt once deferring or multiple
deferring to complete the bet-reveal process. Among these DApps, the most
well-known one is EOSDice, whose daily volume has reached up to 527K USD in
November 2018 (DApp Radar, 2018). Its huge trading volume and open-sourced
seemingly secure strategy attract malicious players. Unfortunately, EOSDice
was attacked twice ($\mathcal{A}_{5}$ and $\mathcal{A}_{6}$) when it adopted
once deferring and multiple deferring strategies, respectively (Le, 2018).

⬇

1uint8_t random(name name, uint64_t game_id) {

2 asset pool_eos = eosio::token(N(eosio.token)).get_balance(_self,
symbol_type(S(4, EOS)).name());

3 // seeds

4 auto mixd = tapos_block_prefix() * tapos_block_num() + name + game_id -
current_time() + pool_eos.amount;

5 // generate a number after some bitwise and arithmetic manipulation

6 ...

7}

Listing 6: The vulnerable random number generating algorithm for EOSDice
before the first attack.

Attack #1 ($\mathcal{A}_{5}$) Listing 6 illustrates the vulnerable code
snippet before the first attack, when it adopted once deferring strategy to
calculate random number. Specifically, in the reveal process, the random is
invoked to decide the result of dice. As we can see at L4, the seed mixd is
obtained by arithmetic calculation of several parameters. Among these 6
arguments: name, game_id and pool_eos (EOS balance of EOSDice) are already
determined and can be easily retrieved; current_time can be calculated by
adding the deferred transaction’s delay time on the timestamp of the betting
transaction; and tapos_block_prefix and tapos_block_num are the metadata of
the block which locates before the betting transaction (see Fig. 8(a)).
Consequently, the mixd can be calculated and predicted by malicious players,
which has resulted in more than 2.5K EOS loss for
EOSDice777https://bloks.io/transaction/a5ce881f87adaa16140183364520c3be251c083fdaededb2295d009aa7b5d94a.

⬇

1auto eos_token = eosio::token(N(eosio.token));

2auto symbol = symbol_type(S(4, EOS)).name();

3asset pool_eos = eos_token.get_balance(_self , symbol);

4asset ram_eos = eos_token.get_balance(N(eosio.ram) , symbol);

5asset betdiceadmin_eos = eos_token.get_balance(N(betdiceadmin), symbol);

6asset newdexpocket_eos = eos_token.get_balance(N(newdexpocket), symbol);

7asset chintailease_eos = eos_token.get_balance(N(chintailease), symbol);

8asset eosbiggame44_eos = eos_token.get_balance(N(eosbiggame44), symbol);

9asset total_eos = asset(0, S(4, EOS));

10total_eos = pool_eos + ram_eos + betdiceadmin_eos + newdexpocket_eos +
chintailease_eos + eosbiggame44_eos;

Listing 7: The vulnerable random number generating algorithm for EOSDice
before the second attack. (This is a simplified version for better display)

Attack #2 ($\mathcal{A}_{6}$) After the first attack, EOSDice inserts an extra
deferring like the way shown in Fig. 8(b). In this way, the reference block is
not determined at the time of betting. However, EOSDice also updated the
process of seed generation, i.e., replacing the pool_eos by total_eos, whose
calculating process is also detailed in Listing 7. The total_eos is the sum of
EOS balance of some designated accounts, including official accounts,
decentralized exchange accounts and other gambling DApps accounts. Therefore,
unlike the simplicity of querying pool_eos, the total_eos requires the
attacker to predict the balance of these six active accounts, which is
impossible.

To achieve the attack, the attacker firstly transfers some EOS tokens to
participate the game. Once he is notified by eosio.token, he would immediately
imitate the revealing process, i.e., launching a twice deferred transaction
with the same delay of EOSDice. Therefore, at the time of random number
calculating, the only parameter can be manipulated is the total_eos because
other metadata of reference block is determined already. The attacker
repeatedly transfers $1\times 10^{-4}$ EOS (the minimum allowed transferring
amount) to any of those accounts till the final result successfully collide
with his betting.

Attack #3 ($\mathcal{A}_{7}$) Except for the above twice attacks against
EOSDice, there still exist some attack instances against flawed random number
($\mathcal{V}_{4}$). For example, EOSPlay generates a random number whose
seeds are calculated from metadata of a future block and cannot be manipulated
directly (Michel, 2019). To carry out the attack, the attacker staked a large
amount of CPU resources at a very low price beforehand, and subsequently
initiated a huge number of transactions. When these transactions flood into
EOSIO network, the decrease of available time in BP results in an abnormally
high CPU price. The deviated resource price hampers the desire and increases
the difficulty of initiating transactions. The block’s body is fully occupied
by the attacker’s transactions. Therefore, the metadata of a future block can
be predicted to some extent. This attack had lead to more than 30K EOS loss
for EOSPlay (PeckShield Inc., 2019c).

####  4.1.5. Re-entrancy attack ($\mathcal{A}_{8}$)

Vaults.sx (vau, 2021) is a decentralized financial DApp on EOSIO, where users
can deposit EOS or USDT (a cross-platform token anchoring on USD with enough
liquidity) to earn the interest by SXEOS or SXUSDT. The deposited tokens can
further be used in flashloans (AAVE, 2021), i.e., users could loan a large
amount of money with a little interest but can only spent within a single
transaction. In May 2021, more than 1.1M EOS and 462K USDT were stolen due to
an attack against re-entrancy vulnerability ($\mathcal{V}_{5}$) (Michel,
2021c).

⬇

1[[eosio::on_notify("*::transfer")]]

2void sx::vaults::on_transfer(name from, name to, asset quantity, string memo)
{

3 const extended_asset out = calculate_retire(id, quantity);

4

5 // update internal deposit & supply

6 _vault_by_supply.modify(supply_itr, _self, [&](auto& row) {

7 row.deposit -= out;

8 row.supply.quantity -= quantity;

9 row.last_updated = current_time_point();

10 });

11

12 // send underlying assets to sender

13 transfer(_self, from, out, _self.to_string());

14}

Listing 8: Part of the transfer function in vault.sx.

⬇

1[[eosio::action]] void sx::vaults::update(const symbol_code id) {

2 // get balance from account

3 const asset balance = eosio::token(N(eosio.token)).get_balance(account,
sym.code());

4

5 // update balance

6 _vault.modify(vault, _self, [&](auto& row) {

7 row.deposit.quantity = balance + staked;

8 row.staked.quantity = staked;

9 row.last_updated = current_time_point();

10 });

11}

Listing 9: Part of the update function in vault.sx.

Specifically, the attack process is as follows:

  * Step 1:

The attacker transfers $2x$ EOS tokens to vaults.sx, who returns $2y$ SXEOS
tokens back;

  * Step 2:

The attacker transfers half of received SXEOS, i.e., $y$ SXEOS, to vault.sx to
redeem $x$ EOS;

  * Step 3:

The transfer in step 2 would notify the payer (attacker) and the payee
(vault.sx) in order.

    1. Step 3.1:

Once the attacker received the notification, his transfer will immediately
initiate another two inlined actions: 1) calling update function in vault.sx;
and 2) redeeming another half of deposited EOS;

    2. Step 3.2:

Once the vault.sx received the notification, its transfer (shown in Listing 8)
will updates the balance of deposited token (L7) before invoking another
inlined action to return the EOS (L13).

  * Step 4:

Following the step 3.1, the update function, listed in Listing 9, will
retrieve the balance first (L3). Because the EOS is not returned yet (followed
by the step 3.2), the deposit at L8 will be unexpectedly inflated. To this
end, the actual payout the attacker received by redeem is greater than his
pro-rata share, i.e., greater than $x$ EOS.

Note that, in practice, the process of triggering the update function in step
3.1 is more complex, which requires the attacker to initiate a flashloan. The
above process only depicts the attack with EOS token, it is identical to
attack with
USDT888https://www.bloks.io/transaction/3e9f27e101adc4488b5d9256c3682e31ec0da8d4df71d9eba0b7ae546eea3888.
Consequently, the attacker repeatedly performed the attack till draining out
the balance within vault.sx.

####  4.1.6. Permission-less injection attack ($\mathcal{A}_{9}$)

As illustrated in §3.1.6 and Fig. 4, EOSIO has a complex permission system.
Therefore, inadequate permission verification ($\mathcal{V}_{6}$) may result
in permission-less injection attack, like the DEOS Game attack event (per,
2021). Specifically, the attacker invokes the transfer of thedeosgames, the
official contract of DEOS Game. As the contract neither comprehensively
verifies the code in apply ($\mathcal{V}_{2}$), nor checks the carrying
permission with the incoming action in transfer ($\mathcal{V}_{6}$), the
attacker could repeatedly construct transfer requests where the payer and
payee are real tokens holder and the attacker himself, respectively. In other
words, as the lack of permission verification, the attacker transfers assets
out on behalf of others. According to our statistics, the attacker has
received around 4.5K DEOS tokens within just one minute. In addition, N. He et
al. (He et al., 2021) pointed out that there were 183 permission-less
injection attacks against more than 140 contracts through analyzing all the
on-chain transactions by heuristic strategy.

###  4.2. Attacks in Data Layer

####  4.2.1. Inline reflex attack ($\mathcal{A}_{10}$)

In December 2018, gambling DApp FastWin was attacked and lost nearly 2K EOS
(PeckShield Inc., 2018b). This attack exploits the vulnerability
$\mathcal{V}_{2}$ and $\mathcal{V}_{7}$, and Peckshield Inc. claimed it is a
critical infrastructure flaw residing in authorization verifying module that
was timely patched by EOSIO official (inl, 2018).

Figure 9. The way of achieving the attack against inline reflex vulnerability.

According to the attack
transaction999https://eos.eosq.eosnation.io/tx/bc072156b74025ecfdfe9413f7e6d605129bada090aaf2aea4a414b545431e58,
the attack process is illustrated in Fig. 9. Specifically, the attacker
firstly initiates a transaction by pushck (step 1), in which he invokes his
check by an inlined action (step 2). Two things are worth noting: 1) the
victim has a function also named check to decide if a bet wins the jackpot;
and 2) the carrying permission is altered to fastwin’s active without
authorization in advance. Then, the attacker actively notifies the victim from
the check (step 3). Because the code field happens not to be verified by
fastwin’s apply, it dispatches the notification to its own check (step 4).
Before that, EOSIO allows an account impersonate others arbitrarily, so the
attacker finally wins jackpots without cost.

####  4.2.2. eosio.code permission misuse attack ($\mathcal{A}_{11}$)

This type of attack also exploits the vulnerability $\mathcal{V}_{7}$. Y.
Huang et al. (Huang et al., 2020b) has systematically studied the eosio.code
permission misuse behaviors in EOSIO ecosystem, and identified more than 13K
related transactions involving around 5.5K accounts. Generally speaking, if an
account actively link someone’s eosio.code permission to his active or even
owner permission, it means he totally believes in the other’s contract, even
it can be updated arbitrarily.

Thus, to perform this attack, the attacker needs to lure the victim to link
<EMAIL_ADDRESS>to the victim@owner or victim@active, which is often
achieved by adopting social engineering methodologies. For example, the
eosfo.io, the victim in $\mathcal{A}_{1}$, has deceived its players to link
its eosio.code permission to the players’ both owner and active permissions
for a better availability of the game (eos, 2018). However, if eosfo.io
updates the transfer function, e.g., transferring remained EOS to a designated
account on behalf of the participated players, the players would suffer a huge
financial loss without any warnings.

####  4.2.3. Fake deposit attack ($\mathcal{A}_{12}$)

Fake deposit attack has been well studied across several blockchain platforms,
like Ethereum (CHINABTCNEWS, 2018) and Ripple (YUSUFF, 2019). In EOSIO, this
attack exploits the vulnerability $\mathcal{V}_{8}$. As with other platforms,
to perform this attack, the attacker needs to deliberately keep failed
transactions on-chain. Once a service provider does not verify if on-chain
transactions failed or not, it will be deceived by such a fake deposit.

In EOSIO, except for the successfully executed transactions, hard_fail ones
are recorded on-chain also. Those hard_fail transactions only correspond to
the failed deferred transactions (SlowMist, 2019a, b), as they actually take
the storage space of BPs before executing. Additionally, the status indicates
both the transaction and the error handler are objectively failed, i.e., error
handler does not handle the thrown exception properly. The error handler is
often implemented in contract’s dispatcher, like L3 to L5 in Listing 4.

Take a malicious hard_fail
transaction101010https://eos.eosq.eosnation.io/tx/358286315c70ebee853ace3023909f3ce843c7bbb50803e76be144f566934742
as an example, it is a deferred transaction and initiated by setting delay
time through client node manually by the attacker. But he deliberately
transfers unaffordable amount of EOS tokens to the victim. According to the
implementation of the official transfer function (see Listing 10), the victim
would be notified (L6) prior to the balance verification and update (L10 and
L11). Thus, after notifications to both payer and payee, the attacker’s
transfer will throw an exception due to insufficient balance. The exception,
however, cannot be caught by attacker’s client node, which has no smart
contract, resulting in a transaction with hard_fail status. The victim will be
fooled if he only considers the notification from eosio.token but not the
transaction’s status before providing services.

⬇

1[[eosio::action]] void token::transfer( /* args */ ) {

2 // initialization and authority check

3 ...

4 // notify payer and payee

5 require_recipient(from);

6 require_recipient(to);

7 // check token’s validity

8 ...

9 // check balance and update balance table

10 sub_balance(from, quantity);

11 add_balance(to, quantity, payer);

12}

Listing 10: The implementation of the transfer function in eosio.token.

####  4.2.4. Malicious rollback attack ($\mathcal{A}_{13}$)

This type of attack exploits the vulnerability $\mathcal{V}_{9}$. The attacker
could intentionally revert a transaction that is unprofitable for him. Thus,
it is often observed in gambling DApps, like (rol, 2019). Take a gambling DApp
that adopts the synchronous bet-reveal strategy (see §4.1.4) as an instance.
For harmless players, they will transfer money to the gambling DApp, and pray
for a jackpot that is calculated by the revealing function. For malicious
players, however, after the revealing action, they are able to initiate an
inlined action to the DApp or the token’s issuer (e.g., eosio.token) to query
if they won the prize. According to the results, like the change in balance,
they will choose either continue the game or intentionally revert it by a
failed assertion. Eventually, the attacker looks like a super lucky guy who
wins prizes in each rounds.

Figure 10. The flowcharts of performing attacks against rollback and replay
vulnerabilities in favor of blacklist mechanism in Block Producer.

###  4.3. Attacks in Consensus Layer

####  4.3.1. Blacklisted rollback attack ($\mathcal{A}_{14}$ and
$\mathcal{A}_{15}$)

As we discussed in §4.2.4, the synchronous revealing strategy would lead to
attack $\mathcal{A}_{13}$. Thus, some gambling DApps decide to separate the
betting and revealing processes into individual transactions. Such a seemingly
safe strategy not only suffers the random number prediction attack
($\mathcal{A}_{5}$ to $\mathcal{A}_{7}$), but also be vulnerable to
$\mathcal{V}_{10}$, which takes advantage of the blacklist mechanism.

Attack #1 ($\mathcal{A}_{14}$) We illustrate the first type of blacklisted
rollback attack in Fig. 10(a), which requires the isolation of betting and
revealing transactions. Suppose the proxy is created by the malicious attacker
who is already blacklisted. The proxy participates in the game through an
inlined action (step 2) after receiving the request from the attacker (step
1). If the bet hits the jackpot, the victim will initiate a new transaction to
return the prize to the proxy (step 3), i.e., the actual initiator of the last
step’s transfer. According to the consensus algorithm, both of them should be
broadcasted to and verified by a BP. However, the former one will be dropped
unconditionally due to the blacklisted initiator, attacker, while only the
prize-returning transaction initiated by the dapp is recorded on-chain. The
proxy can keep playing the game with little cost.

Attack #2 ($\mathcal{A}_{15}$) The $\mathcal{A}_{14}$ takes advantage of the
independence between the betting transaction and the revealing one, which in
turn urged developers to bind them together. In other words, either
transaction’s failure will result in the rollback of the both. However, such a
reasonable-sounding strategy is still flawed to $\mathcal{A}_{15}$, whose
exploitation is illustrated in Fig. 10(b).

Specifically, the first three steps are identical to $\mathcal{A}_{14}$’s. The
loophole hides in step 3 that the proxy can determine if he wins or not by the
received notification. If he does, the proxy would immediately initiates a
transaction with the same set of arguments (step 4). Because some gambling
DApps use the same set of seed to generate random numbers in such a short
period of time, the transaction initiated by a non-blacklisted proxy will 100%
win the jackpot. Actually, in December 2018, a gambling DApp LuckyMe was
attacked by $\mathcal{A}_{15}$’s strategy, and the attacker gained more than
3K EOS with no cost (SlowMist Zone, 2020).

####  4.3.2. Transaction congestion attack ($\mathcal{A}_{16}$)

This exploitation uses characteristics introduced in $\mathcal{V}_{11}$, i.e.,
deferred transactions are prioritized over the user-signed normal
transactions. According to Peckshield Inc.’s experiment (tx-, 2020), they have
nearly paralyzed the whole EOSIO network for more than 2 minutes at a cost of
only 0.4 EOS. Specifically, each deferred transaction needs to be stored till
the scheduled time. Once the time is reached, BP will prioritize them to
ensure a timely execution and release its storage space. However, BP will not
verify deferred transactions’ behavior in advance for efficiency reasons.

To achieve the attack, take the malicious code snippet in Listing 11 as an
example, whose only purpose is to perform a dead loop in a deferred
transaction (L2). To this end, the available time slot for a BP would be
exhausted if several such malicious transactions are initiated, leading to a
denial-of-service situation. Furthermore, a deferred transaction could invoke
other deferred transactions, which may be synced to other BPs. Consequently,
this may result in a prolonged and widespread denial-of-service attack at an
extremely low cost.

⬇

1[[eosio::action]] void deferred(name from, const string message) {

2 while(true) {}

3}

4

5[[eosio::action]] void send(name from, const string message, uint64_t delay)
{

6 eosio::transaction t{};

7

8 t.actions.emplace_back(

9 permission_level(from, N(active)),

10 _self,

11 N(deferred),

12 std::make_tuple(from, message));

13

14 // set delay in seconds

15 t.delay_sec = delay;

16 t.send(now(), from);

17}

Listing 11: The way of implementing a malicious deferred transaction by
triggering the send function.

####  4.3.3. Resource competition based DoS attack ($\mathcal{A}_{17}$)

EOSIO adopts an innovative set of resource model (see §2.3.2), which
significantly reduces the cost to initiate transactions. However, the mortgage
price of resources fluctuates significantly under extreme situations (see
$\mathcal{V}_{12}$). Normal DApps may suffer DoS attacks due to such a
resource competition. The notorious EIDOS project, who did lead to the above
situation, has paralyzed the whole network for up to 15 months and resulted in
enormous financial losses (Hatze, 2021).

Figure 11. The mechanism of EIDOS project.

Specifically, EIDOS launched in November 2019 and planned to run for 15
months. Its mechanism is shown in Fig. 11. It accepts EOS transfer from
investors (step 1 to 3), and returns it back immediately (step 4 to 6). Then,
it issues some EIDOS token and transfers 0.01% of accumulated EIDOS tokens to
the investor. In other word, the EIDOS project returns a fixed percent of
EIDOS tokens back no matter how many EOS tokens are transferred from an
investor. Hence, the most rational behavior is to transfer $1\times 10^{-4}$
EOS to EIDOS project as quickly as possible. The transfer behavior, however,
consumes CPU, a limited resource. Combined with the tradable EIDOS token in
the secondary market (CoinGecko, 2021), the price of exchanging CPU has
skyrocketed. According to Titan Labs (Titan Labs, 2021), 1 EOS can only
exchange 0.08 unit of CPU in December 2019, whose price is 2,000 times than
half of the year before. Such a distorted price of a mandatory resource
negatively impacts normal transactions in EOSIO ecosystem. For example, only
one day after its launch, the active users of DApps has dropped 75% and the
transaction volume decreased more than 95% (PeckShield Inc., 2019b).

####  4.3.4. RAM hijack attack ($\mathcal{A}_{18}$)

RAM is a type of resource that is charged when storing permanent data. For
example, eosio.token issues EOS tokens and maintains a balance table for
holders. Once a new account claimed some EOS tokens, some RAM will be charged
from eosio.token. According to (ram, 2018), in August 2018, an account’s RAM
was maliciously occupied by a chunk of garbage data, which exploits the
vulnerability $\mathcal{V}_{13}$. An instance of the malicious contract is
shown in Listing 12.

⬇

1class dataStorage : public eosio::contract {

2 [[eosio::action]] void transfer(name from, name to, asset quantity,
std::string memo) {

3 // instantiate a multi_index table

4 _ttab ttabs(_self,_self);

5

6 for (int i = 0; i < 1000; i++) {

7 // The first parameter specifies the account that would pay for any used RAM

8 ttabs.emplace(from, [&](auto& data){

9 // places junk data into the table

10 data.id = i;

11 });

12 }

13 }

14};

15

16EOSIO_API(dataStorage, (transfer)) //Handles the transfer function

Listing 12: An instance of a malicious contract that inserts garbage data.

Specifically, to perform RAM hijacking, the attacker should lure the victim to
transfer some EOS tokens to him. In the attacker’s transfer, he will
instantiate a table, and repeatedly insert meaningless rows by a native
emplace (L8). As the emplace function could designate the payer of the to be
used RAM resources, the attacker designates it as from, i.e., the victim who
initiated the EOS transfer, his RAM would be occupied suddenly. According to a
experiment (Sotnichek, 2018), such a 1,000 rows of data would take 100KB of
RAM, equivalent to 50 USD. Occupied RAM cannot be released, nor sold to
others, the victim therefore needs to wait for the attacker to actively clear
the table and free up RAM resources.

####  4.3.5. CPU hijack attack ($\mathcal{A}_{19}$)

As we introduced in $\mathcal{V}_{13}$, EOSIO allows the first account who
authorizes the transaction to pay for the CPU resources for the following
actions (MrToph, 2019). Such a behavior would attract players who have no CPU
resources to participate in the game, especially during the period with high
CPU price. However, the emergence of EIDOS project, who leads to a significant
CPU shortage, has led malicious users into exploiting this feature for profit.

On November 6th, 2019, due to the shortage of CPU resources, the gambling DApp
BigGame announced that it would pay the CPU on behalf of
players111111https://twitter.com/eosbiggame?lang=en to attract them. Thus,
some malicious players could pretend to play the game and embed an inlined
action in which initiating a transfer to the EIDOS project. As the CPU
resources are payed by the BigGame and EIDOS returns all its received EOS,
these players could obtain EIDOS tokens with no cost.

Except for the gambling DApps, the CPU resources in official account eosio can
also be hijacked. Specifically, the function bidname allows accounts to bid a
shorter name (less than 12 characters) by transferring EOS tokens. Once
someone is overbidden, his bid would be returned by an EOS transfer via
eosio.token. As the refund process is initiated by eosio, who owns unlimited
CPU resources, the malicious account could intentionally be overbidden and
embed an inlined action to gain profit from EIDOS
project121212https://bloks.io/transaction/0792f37ca3861cede65db056e809f77389057a2a420d5139fa6858e07fd4d505?tab=traces.

###  4.4. Discussion

As we can see from Fig. 6, the consequences of all these attacks are divided
into three main categories: Unauthorized Code Execution, Illegal Profit, and
Denial of Service. We will discuss them in this section.

####  4.4.1. Unauthorized Code Execution

Unauthorized code execution is a common consequence for attacks in EOSIO
ecosystem, e.g., fake EOS attack ($\mathcal{A}_{2}$ and $\mathcal{A}_{3}$) and
inline reflex attack ($\mathcal{A}_{10}$). Further, we could divide attacks
into two groups: missing key arguments verification ($\mathcal{A}_{2}$,
$\mathcal{A}_{3}$ and $\mathcal{A}_{4}$) and missing carrying permission
validation ($\mathcal{A}_{9}$, $\mathcal{A}_{10}$ and $\mathcal{A}_{11}$).
According to (He et al., 2021), both types of attacks are prevalent on EOSIO
and cause significant financial losses, e.g., EOSBet Dice suffered from two
attacks, $\mathcal{A}_{3}$ and $\mathcal{A}_{4}$, which lead to financial
losses of 44K and 138K EOS tokens, respectively, around 1M USD (EOS, 2018;
PeckShield Inc., 2018a).

Insight 5: Missing key arguments verification and carrying permission
validation are common on EOSIO platform, which would result in unauthorized
code execution and huge amount of financial loss for victim contracts. We urge
developers to strictly limit the possible combinations of input arguments,
like requiring code == eosio.token and action == transfer simultaneously.
Moreover, prior to sensitive operations (like invoking other contracts),
explicitly validating the carrying permissions is preferable.

####  4.4.2. Illegal Profit

Several attacks could lead to illegal profit consequence, e.g., predicting
random number ($\mathcal{A}_{5}$ to $\mathcal{A}_{7}$) and blacklisted
rollback attacks ($\mathcal{A}_{14}$ and $\mathcal{A}_{15}$). Among all these
related attacks, 6 of them are related to the PRNG process of gambling DApps,
the most prevalent category of DApps on EOSIO (EOS GO, 2019). Except for CPU
hijack attack ($\mathcal{A}_{19}$), which was first reported in attacks
against blockchain platforms, while the other two, re-entrancy attack
($\mathcal{A}_{8}$) and fake deposit attack ($\mathcal{A}_{12}$), have emerged
on other platforms (Staff, 2021; CHINABTCNEWS, 2018; YUSUFF, 2019). However,
to achieve successful exploitations, both of them need to take advantage of
the introduced by EOSIO, like notification and deferred transaction.

Insight 6: Illegal profit would directly import financial loss for DApps’
developers. Current attack events have proven the risk of adopting PRNG that
purely relies on on-chain seeds. Moreover, some exploitations utilize the new
mechanism introduced by EOSIO, like notification and deferred transaction,
which should be carefully considered and mastered by developers.

####  4.4.3. Denial of Service

Denial of service, the consequence of some attacks, is fatal for such a
distributed system. All these attacks are related to vulnerabilities that are
caused by EOSIO’s toolchain ($\mathcal{A}_{1}$) or EOSIO’s design
($\mathcal{A}_{16}$, $\mathcal{A}_{17}$ and $\mathcal{A}_{18}$). Some of them
have been officially patched timely ($\mathcal{A}_{1}$ and $\mathcal{A}_{16}$)
or can be mitigated by best practice ($\mathcal{A}_{18}$). Unfortunately,
there does not exist an effective methodology to mitigate $\mathcal{A}_{17}$,
which can be easily reproduced by another spam DApp.

Insight 7: EOSIO’s toolchain and design have led to several vulnerabilities,
against which can be exloited, resulting in denial of service consequence.
EOSIO officially has tried its best to mitigate such a fatal result. Its
resource system, especially the fluctuated resources’ price calculated by
supply and demand relationship, however, is defective under extreme
situations. We counsel EOSIO official to bring forward more efficient and
effective solutions.

##  5\. Mitigation

In this section, we would present some mitigations on how to address or avoid
vulnerabilities introduced in §3 and denote them as $\mathcal{M}_{i}$.
Specifically, there exist two mainstream methodologies to automatically
identify existing vulnerabilities or attack behaviors: smart contract analysis
(see §5.1) and transaction analysis (see §5.2). The former one adopts
traditional program analysis methods to identify vulnerabilities embedded in
EOSIO smart contracts, while the latter one is often used to identify on-chain
attack transactions. Both of them can urge developers to examine if their
applications are impacted by corresponding vulnerabilities or attacks.
Besides, DApp developers could adopt best practices in programming to actively
reduce the possibility of being exploited (see §5.3).

###  5.1. Smart Contract Analysis

As an emerging blockchain platform, EOSIO has not been widely noticed by
security researchers. However, several work (He et al., 2021; Wang et al.,
2020a; Huang et al., 2020a; Quan et al., 2019; Lee et al., 2019; Yan et al.,
2020) appeared aiming to identify the vulnerabilities in EOSIO smart contracts
to facilitate security development for developers. There are two mainstream
smart contract analysis methodologies: static analysis (He et al., 2021; Wang
et al., 2020a; Quan et al., 2019; Lee et al., 2019; Yan et al., 2020) and
dynamic analysis (Huang et al., 2020a).

####  5.1.1. Static analysis

Static analysis is the most prevalent methodology to analyze the EOSIO smart
contracts. Specifically, we can divide it into four aspects: symbolic
execution, pattern matching, formal verification, and code audit.

##### Symbolic execution

N. He et al. (He et al., 2021) ($\mathcal{M}_{1}$) and D. Wang et al. (Wang et
al., 2020a) ($\mathcal{M}_{2}$) respectively analyzing EOSIO smart contracts
by implementing their self-implemented symbolic execution engine.
Specifically, both of the engine extract the control flow graph (CFG) from the
Wasm bytecode firstly. Then, engines will traverse all possible paths from the
entry function, apply, to obtain semantic information. With the collected
constraints along each path, according to the feasibility returned by back-end
SMT solvers, researchers can determine if the contract is vulnerable to
certain loopholes. The main advantage of symbolic execution is its
theoretically zero false positive under enough computing resources. To
accelerate the analysis, both of them prune infeasible paths in advance with
the help of z3, and (He et al., 2021) also adopts some heuristic methodologies
to locate suspicious functions. As for their concerned vulnerabilities, both
of them focus on insufficient code verification ($\mathcal{V}_{2}$) and
relayable notification ($\mathcal{V}_{3}$). The engine proposed by (He et al.,
2021) can also identify inadequate permission verification ($\mathcal{V}_{6}$)
and arbitrary rollback ($\mathcal{V}_{9}$), while the (Wang et al., 2020a)’s
focuses on a simple version of predictable random number ($\mathcal{V}_{4}$).

##### Pattern matching

L. Quan et al. (Quan et al., 2019) ($\mathcal{M}_{3}$) adopts pattern matching
to identify insufficient code verification ($\mathcal{V}_{2}$) and relayable
notification ($\mathcal{V}_{3}$). Specifically, the tool, EVulHunter,
interprets and simulates instructions in each basic block (apply’s and
transfer’s) as a simple virtual machine, and simultaneously maintains two
vital data structures: stack and memory. During the simulation, it focuses on
some parameters, e.g., _self, from, and to. Comparing these parameters’
logical relationship and pre-defined patterns, EVulHunter is able to identify
whether the candidate contract is vulnerable to $\mathcal{V}_{2}$ and
$\mathcal{V}_{3}$. However, as the pattern matching heavily relies on the pre-
defined patterns, which lack of semantic information and be prone to
overfitting problem, the tool may produce false negative cases.

##### Formal verification

Z. Yan et al. (Yan et al., 2020) ($\mathcal{M}_{4}$) proposed a tool, TFFV,
which is able to transform the source code of EOSIO smart contract into
functional equivalent formal verification language. The above process is
implemented by a pipeline consisting of: lexical analyzer, parser, and code
generator. The authors claim that the translation process can be implemented
with 100% accuracy. Based on the translated formal languages, theoretically,
developers are able to prove that the smart contract behaviors exactly as the
specification. However, the authors did not perform experiments on how to
verify if a contract is vulnerable to any of the $\mathcal{V}_{i}$.

##### Code audit

S. Lee et al. (Lee et al., 2019) ($\mathcal{M}_{5}$) performed the security
analysis by reviewing the source code of EOSIO. Specifically, they mainly
focused on the resource system (CPU and RAM resources) and consensus algorithm
(block producer’s implementation) of EOSIO. Through a comprehensive code
audit, they have successfully identified assignable resource payer
($\mathcal{V}_{13}$) and top-priority deferred transaction
($\mathcal{V}_{11}$). Except for the vulnerability identification, they also
conducted an experiment to perform related attacks ($\mathcal{A}_{16}$,
$\mathcal{A}_{18}$, $\mathcal{A}_{19}$) on testnet to prove EOSIO’s inherent
loopholes.

####  5.1.2. Dynamic analysis

Except for the mainstream static analysis, dynamic analysis is also adopted by
researchers to detect vulnerabilities in EOSIO smart contracts. Currently,
however, there exists only one work (Huang et al., 2020a) that utilizes
fuzzing testing to analyze EOSIO smart contracts.

##### Fuzzing testing

Fuzzing testing is prevalent in Ethereum smart contract analysis, like (Ashraf
et al., 2020; Jiang et al., 2018). In EOSIO, the whole process is similar. Y.
Huang et al. (Huang et al., 2020a) presented EOSFuzzer ($\mathcal{M}_{6}$), a
fuzzing framework, to dynamically analyze EOSIO smart contracts. EOSFuzzer
firstly takes both the EOSIO smart contract’s bytecode and its corresponding
ABI file as inputs, and statically analyzes them to generate a set of input by
its pre-defined seeds. Then, the tool will imitate a malicious agent and
initiate transactions according to the randomly generated input. According to
execution logs of targets, it can be easily verified if the target is
vulnerable to $\mathcal{V}_{2}$, $\mathcal{V}_{3}$ and $\mathcal{V}_{4}$.

Insight 8: All mitigations related to smart contract analysis
($\mathcal{M}_{1}$ to $\mathcal{M}_{6}$) and their targeted vulnerabilities
are shown in table 3. As we can see, none of them focused on the
$\mathcal{V}_{1}$, which can be patched by EOSIO’s update. Most of the tools
aim at vulnerabilities resulted from smart contract programming, like
$\mathcal{V}_{2}$ and $\mathcal{V}_{3}$, which relates to the most prevalent
and wide-spread attack events. However, $\mathcal{V}_{5}$, $\mathcal{V}_{7}$,
$\mathcal{V}_{8}$ and $\mathcal{V}_{10}$ are not covered by any of projects.
Among these four vulnerabilities, $\mathcal{V}_{7}$, $\mathcal{V}_{8}$ and
$\mathcal{V}_{10}$ are partly addressed by EOSIO official or need to be
carefully verified by the service providers. Therefore, we urge security
researchers to propose a proper way to handle re-entrancy vulnerability
($\mathcal{V}_{5}$) and its corresponding attack ($\mathcal{A}_{8}$).

Table 3. Smart contract analysis mitigations with their corresponding vulnerabilities. | EOSIO Toolchain | Smart Contract Programming | EOSIO Design |
---|---|---|---|---
| $\mathcal{V}_{1}$ | $\mathcal{V}_{2}$ | $\mathcal{V}_{3}$ | $\mathcal{V}_{4}$ | $\mathcal{V}_{5}$ | $\mathcal{V}_{6}$ | $\mathcal{V}_{7}$ | $\mathcal{V}_{8}$ | $\mathcal{V}_{9}$ | $\mathcal{V}_{10}$ | $\mathcal{V}_{11}$ | $\mathcal{V}_{12}$ | $\mathcal{V}_{13}$ | total
$\mathcal{M}_{1}$ |  | $\checkmark$ | $\checkmark$ |  |  | $\checkmark$ |  |  | $\checkmark$ |  |  |  |  | 4
$\mathcal{M}_{2}$ |  | $\checkmark$ | $\checkmark$ | $\checkmark$ |  |  |  |  |  |  |  |  |  | 3
$\mathcal{M}_{3}$ |  | $\checkmark$ | $\checkmark$ |  |  |  |  |  |  |  |  |  |  | 2
$\mathcal{M}_{4}$ |  |  |  |  |  |  |  |  |  |  |  |  |  | 0
$\mathcal{M}_{5}$ |  |  |  |  |  |  |  |  |  |  | $\checkmark$ |  | $\checkmark$ | 2
$\mathcal{M}_{6}$ |  | $\checkmark$ | $\checkmark$ | $\checkmark$ |  |  |  |  |  |  |  |  |  | 3
total | 0 | 4 | 4 | 2 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |

###  5.2. Transaction Analysis

EOSIO, who adopts DPoS as consensus algorithm, would generate transactions
thousands of times than Bitcoin and Ethereum within a given period. Therefore,
conducting an efficient transaction analysis is challenging and several work
(Huang et al., 2020b; He et al., 2021; Zhao et al., 2020; Zheng et al., 2020)
has implemented it with different purposes. For example, with the help of
collected transactions, (Huang et al., 2020b; He et al., 2021) detected
existing attack events and misbehaviors, while (Zhao et al., 2020; Zheng et
al., 2020) performed a statistical analysis.

####  5.2.1. Transaction-based misbehavior detection

Executed transactions are recorded on-chain permanently. According to the data
stored in transactions (like initiator and carrying permission) and
statistical characteristics of transactions (like frequency and trading
volume), some work successfully identifies misbehaviors.

To be specific, (Huang et al., 2020b) firstly builds several graphs according
to relationships between contracts and accounts in terms of certain types of
behavior, like token transferring. Based on these graphs, they calculate a set
of statistical metrics via graph analysis. Then, they propose a clustering
algorithm to distinguish bot accounts from normal accounts on community level
and account level. They find that these bot accounts are mainly used on bonus
hunter and click fraud, and are controlled by DApp teams with different
intentions. Moreover, they propose a heuristic methodology to identify
transactions related to attacks $\mathcal{A}_{2}$ to $\mathcal{A}_{5}$,
$\mathcal{A}_{11}$, $\mathcal{A}_{13}$ and $\mathcal{A}_{16}$, and measure the
financial impacts resulted from them.

Except for identifying vulnerabilities through symbolic execution, (He et al.,
2021) also proposes a set of heuristic methodology to filter out suspicious
attack transactions. They mainly focus on $\mathcal{A}_{2}$ to
$\mathcal{A}_{4}$, $\mathcal{A}_{9}$, and $\mathcal{A}_{13}$. After the
filtering process, they further report these attack transactions to the victim
DApps to recheck the identifying precision and evaluate the real financial
impact.

####  5.2.2. Transaction statistics

(Huang et al., 2020b; Zhao et al., 2020; Zheng et al., 2020) perform basic
data statistics and analysis on EOSIO’s transactions. For example, both (Huang
et al., 2020b) and (Zhao et al., 2020) build graphs based on the relationships
among a certain type of transactions, like account voting and account
creation. Based on graphs, they calculate statistical metrics, e.g., degree
distribution, to obtain some macroscopical features from EOSIO network.
Moreover, W. Zheng et al. (Zheng et al., 2020) collect transactions from the
first 9 million blocks, and divide them by certain behaviors, like
transferring and account creation. For each transaction group, they conduct a
basic data statistics work and release them as a public database.

Insight 9: The main goal of smart contract analysis is to identify the
potential victims, while the analysis based on existing transactions, however,
is to filter out the happened but not public-known attack events and
misbehaviors, urging self-examination for DApp developers. Current
methodologies heavily rely on heuristic strategies and do not cover all of the
attacks we mentioned in §4. Therefore, a more systematic and comprehensive
framework is necessary which is able to put forward more meaningful and
interesting insights based on transaction analysis.

###  5.3. Smart Contract Programming

Figure 12. The best practices and behind principles against vulnerabilities in
EOSIO.

Except for adopting existing analysis tool to identify vulnerabilities by
programming analysis methodologies (see §5.1) or extract attack transactions
and misbehaviors by transaction analysis (see §5.2), DApp developers can
proactively make a defense to these vulnerabilities. Fig. 12 illustrates the
best practices and their behind principles against vulnerabilities we
mentioned in §3 (except for $\mathcal{V}_{14}$ and $\mathcal{V}_{15}$ which is
out of EOSIO’s scope). For $\mathcal{V}_{2}$, $\mathcal{V}_{3}$ and
$\mathcal{V}_{8}$, whose behind principle is data control, DApp developers
could eliminate the possibility of being attacked by strictly verifying values
within transactions, like arguments and transaction status. Similarly,
$\mathcal{V}_{6}$, $\mathcal{V}_{7}$ and $\mathcal{V}_{13}$ can also be
eliminated, whenever accounts and developers carefully hand over or examine
carrying permissions. Additionally, $\mathcal{V}_{4}$, $\mathcal{V}_{9}$ and
$\mathcal{V}_{10}$ are all related to gambling DApps. These problems can be
addressed by introducing extra information, e.g., a price oracle, however,
which often means the trade-off between decentralization and reliability for
its users. Remaining ones are all related to EOSIO’s mechanism and toolchain.
In other words, upgrading to the latest version could partially reduce the
harm. However, $\mathcal{V}_{12}$ is still opened and prone to be exploited by
another EIDOS-like project.

##  6\. Discussion

In this section, we discuss the future of EOSIO and give some recommendations,
which are all summarized from this work, to developers, official team and
security researchers.

For DApp Developers EOSIO is a suitable blockchain platform for DApp
developers, as it adopts DPoS consensus algorithm that enables thousand times
of TPS than Ethereum, which is currently a mainstream blockchain platform
supporting DApp development. However, EOSIO imports some innovative mechanisms
(comparing to Bitcoin and Ethereum), e.g., notification mechanism and resource
system. From §3 and §4, we could easily conclude that only if DApp developers
is knowledgeable about these mechanisms or their projects may suffer huge
financial losses. Therefore, there are some recommendations for DApp
developers:

  * •

Keep an eye on the release of latest version of EOSIO, especially the official
fix of vulnerabilities and the introduction of new mechanism;

  * •

Be familiar with the newly imported mechanism, as well as its relationship
between the existing ones. For example, the introduction of resource exchange
(REX) has affected the resource system to a certain extent (EOS Cafe Block,
2018). Thus, try to postpone the adoption of new mechanism till it is
necessary and inevitable;

  * •

As for the existing vulnerabilities (see §3), most of them (especially the
ones caused by smart contract programming (see Fig. 5)) could be mitigated by
best practices. For example, $\mathcal{V}_{2}$ and $\mathcal{V}_{3}$ can be
mitigated by strictly arguments verification;

  * •

Mind the emerging attack events, especially the ones whose functionality and
purpose are similar/identical to your DApp. With the updatable capability of
EOSIO smart contracts, developers should patch their DApps timely or even
withdraw them till the immunity of loopholes is ensured by code audit.

For Official Team EOSIO official team is trying to communicate with the
community positively, like the bug bounty program (EOSIO, 2021a). However,
some vulnerabilities locating in EOSIO system are not discovered by security
researchers, but by actual attacks from malicious accounts (like
$\mathcal{A}_{1}$ results from $\mathcal{V}_{1}$). Thus, it requires the
official team to patch it timely to minimize the harm to both EOSIO and DApp
developers. Consequently, some recommendations for EOSIO official team are as
follows:

  * •

Do not upgrade the system frequently unless it is necessary and urgent.
Moreover, strictly audit the code in the new release, it can be performed by
specialized third-party blockchain security companies;

  * •

According to Occam’s razor principle, if it is not necessary, do not import
new mechanism. Otherwise, the newly imported one should be decoupled as much
as possible with the existing mechanisms, and the instances and best practices
of how to use it should be given by the official team;

  * •

The official team should consider the update of current resource system, or
just eliminate the possibility of emergence of another EIDOS-like project. Its
appearance will significantly and negatively impact on platforms’s trading
volume, users’ activity and DApp developers’ initiative.

For Security Researchers For security researchers, EOSIO smart contracts,
i.e., WebAssembly bytecode, is worthy of being studied. Based on the current
work, which discusses the WebAssembly files security (Lehmann et al., 2020;
Hilbig et al., 2021; Stiévenart and De Roover, 2020), EOSIO smart contracts
analysis (Wang et al., 2020a; He et al., 2021; Quan et al., 2019; Huang et
al., 2020a), and whether the vulnerable smart contracts are worth being
exploited (Perez and Livshits, 2021), we propose several recommendations for
security researchers:

  * •

Apply program analysis methodology (like fuzzing and symbolic execution) on
EOSIO smart contracts to explore zero-day vulnerabilities. Then, extract the
pattern of the newly discovered loopholes and integrate it into existing
analysis tools;

  * •

Pay attention to the security of EOSIO platform itself, or its security issue
would negatively influence on all deployed smart contracts in terms of
security or service availability;

  * •

The prosperity of DeFi DApps in Ethereum is likely to be duplicated in EOSIO
platform. The attack events against to DeFi DApps, however, heavily depend on
victims’ flawed business logic, which is hard to be identified and extracted
as a generic pattern. Thus, the security analysis towards DeFi DApps need to
be covered by future work.

##  7\. Related Work

Survey on Blockchain. Actually, there are lots of surveys towards kinds of
blockchain platforms (Atzei et al., 2017; Praitheeshan et al., 2019; Chen et
al., 2019; Li et al., 2017; Wahab and Mehmood, 2018). Among them, most of
which are related to Ethereum. For example, N. Atzei et al. (Atzei et al.,
2017) first finished a survey of vulnerability on Ethereum smart contract.
Additionally, they also showed a series of attacks which could exploit these
vulnerabilities. Except for Ethereum, X. Li et al. (Li et al., 2017) taken a
more macro perspective and did an exhaustive survey of attacks and solutions
against the whole blockchain. As one of the most crucial roles in blockchain,
consensus algorithm, has also been fully studied by A. Wahab et al. (Wahab and
Mehmood, 2018).

EOSIO Security and Ecosystem. Because EOSIO is a relatively new blockchain
platform, it has not received as much attention as Bitcoin or Ethereum. But
there is still some work that analyzes the security and ecosystem of EOSIO (He
et al., 2021; Quan et al., 2019; Huang et al., 2020b; Zheng et al., 2020; Zhao
et al., 2020; Lee and Lee, 2019; Lee et al., 2019). For instance, N. He et al.
(He et al., 2021) has implemented a vulnerability detector which is able to
detect four types of loopholes which are included in this survey, and the tool
–EOSafe reached a high precision on detection. Some others also focused on the
behavior of account in EOSIO. Y. Huang et al. (Huang et al., 2020b) achieved a
large-scale study to identify the bot accounts with fraudulent activities in
EOSIO. From a higher level, S. Lee et al. has found a threat (that is
confirmed by EOSIO official) which could partially freeze the execution of a
target smart contract or maliciously consume all the resources of a target
user with crafted requests in (Lee et al., 2019). Of course, they also
discussed possible mitigations against the proposed attacks.

##  8\. Conclusion

In this paper, we detail all the vulnerabilities related to EOSIO that have
appeared in history. These vulnerabilities cover the three levels of EOSIO,
which are smart contracts, EOS VM, and blockchain itself. In addition to this,
we demonstrate the attack techniques for most of the vulnerabilities, as well
as the mitigations (and the best practices in programming) for those that
cannot be officially fixed. For DApp developers, EOSIO official team and
security researchers, we summarize some recommendations to indicate the
direction ahead. As far as we know, this is the first survey against EOSIO.
Although there have been many surveys against Ethereum’s vulnerabilities and
attacks, the mechanism of EOSIO and Ethereum is very different. Therefore, our
work can be of great help to EOSIO smart contract developers and researchers.

## References

  * (1)
  * cpu (2018) 2018\.  Consensus upgrade against CPU resources.  https://github.com/EOSIO/eos/issues/6332
  * eos (2018) 2018\.  eosfo.io requires players’ eosio.code permission.  https://bihu.com/article/986206
  * ass (2018) 2018\.  Official patch for asset overflow vulnerability.  https://github.com/EOSIO/eos/commit/b7b34e5b794e323cdc306ca2764973e1ee0d168f
  * inl (2018) 2018\.  Official patch for inline reflex.  https://github.com/EOSIO/eos/releases/tag/v1.5.1
  * ram (2018) 2018\.  RAM hijacking attack is reported by official.  https://bitcoinexchangeguide.com/breaking-eos-potential-eosio-ram-exploit-hack-vulnerability-solution-issued-but-large-exchanges-still-at-risk/
  * rol (2019) 2019\.  Mailicious rollback attack example in EOSIO.  https://www.anquanke.com/post/id/185251
  * web (2019) 2019\.  WebAssembly Official Site.  https://webassembly.org/
  * bit (2020a) 2020a.  Bitcoin’s market cap.  https://coinmarketcap.com/currencies/bitcoin/
  * bit (2020b) 2020b.  Bitcoin’s tps.  https://en.bitcoin.it/wiki/Scalability
  * eid (2020) 2020\.  EIDOS official site.  https://enumivo.org/
  * eos (2020a) 2020a.  EOSIO network monitor.  https://eosnetworkmonitor.io/
  * tx- (2020) 2020\.  Example of transaction congestion.  https://eosq.app/block/02344b09116e94221737ae411c4ecd37f9da2778e0612a6d5f956edba9a12061
  * bit (2020c) 2020c.  Forum: Bitcoin Gambling.  https://forum.bitcoingambling.io/
  * eos (2020b) 2020b.  Forum: Reddit EOS section.  https://www.reddit.com/r/eos/
  * rex (2020) 2020\.  REX official site.  https://eosauthority.com/rex
  * sho (2020) 2020\.  Short-circuit mechanism.  https://en.wikipedia.org/wiki/Short-circuit_evaluation
  * dpo (2020) 2020\.  The DPoS consensus.  https://en.bitcoinwiki.org/wiki/DPoS
  * eos (2021) 2021\.  AlgoTrader, an oracle, in EOSIO.  https://eosio.algotrader.com/home
  * soc (2021) 2021\.  Definition of social engineering.  https://www.webroot.com/us/en/resources/tips-articles/what-is-social-engineering
  * mit (2021) 2021\.  Man-in-the-middle attack.  https://en.wikipedia.org/wiki/Man-in-the-middle_attack
  * vau (2021) 2021\.  Official site of Vaults.sx.  https://www.eosx.io/defi/vaults
  * per (2021) 2021\.  Transaction instance of permission-less injection attack.  https://eos.eosq.eosnation.io/tx/ad143e3da45f7661eb4540b51d23dc6bfaa64b1de6989297f3b4e2170e17ff08
  * z3 (2021) 2021\.  Z3, a well-known SMT solver.  https://github.com/Z3Prover/z3
  * AAVE (2021) AAVE. 2021.  Defination of flash loan.  https://aave.com/flash-loans/
  * Ashraf et al. (2020) Imran Ashraf, Xiaoxue Ma, Bo Jiang, and Wing Kwong Chan. 2020\.  GasFuzzer: Fuzzing Ethereum Smart Contract Binaries to Expose Gas-Oriented Exception Security Vulnerabilities.  _IEEE Access_ 8 (2020), 99552–99564.
  * Atzei et al. (2017) Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017\.  A survey of attacks on ethereum smart contracts (sok). In _International conference on principles of security and trust_. Springer, 164–186.
  * Aurora Tech N.V. (2020) Aurora Tech N.V. 2020\.  EOSBet Official Site.  https://eosbet.io/
  * BCSEC (2018) BCSEC. 2018.  EOSIO asset overflow attack against eosfo.io.  https://bcsec.org/index/detail/id/218/tag/0
  * bloks.io (2021) bloks.io. 2021.  The victim of the asset overflow attack.  zyixjmpxrrpr
  * Chen et al. (2019) Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. 2019.  A survey on ethereum systems security: Vulnerabilities, attacks and defenses.  _arXiv preprint arXiv:1908.04507_ (2019).
  * Chen (2018) Yuki Chen. 2018\.  Flaw in EOS VM.  https://blogs.360.cn/post/eos-asset-multiplication-integer-overflow-vulnerability.html
  * CHINABTCNEWS (2018) CHINABTCNEWS. 2018\.  Fake deposit in Ethereum.  https://news.8btc.com/slowmist-3619-eth-based-tokens-are-affected-by-fake-deposit-vulnerability
  * Chinen et al. (2020) Yuchiro Chinen, Naoto Yanai, Jason Paul Cruz, and Shingo Okamura. 2020.  RA: Hunting for Re-Entrancy Attacks in Ethereum Smart Contracts via Static Analysis. In _2020 IEEE International Conference on Blockchain (Blockchain)_. IEEE, 327–336.
  * Coinbase (2019) Coinbase. 2019.  Distinction between EOA and Smart Contract.  https://blog.coinbase.com/intro-to-smart-contracts-f436b1ac2bb8
  * coindesk (2019) coindesk. 2019.  Ethereu’s tps.  https://www.coindesk.com/learn/ethereum-101/will-ethereum-scale
  * CoinGecko (2021) CoinGecko. 2021\.  Tradable EIDOS token in exchanges.  https://www.coingecko.com/en/coins/eidos
  * CRAIG RUSSO (2018) CRAIG RUSSO. 2018\.  EOSIO surpasses Ethereum in transaction volume.  https://sludgefeed.com/eos-surpasses-ethereum-in-daily-dapp-users-and-transaction-volume/
  * DApp Radar (2018) DApp Radar. 2018\.  Daily volume of gambling DApp EOSDice.  https://dappradar.com/eos/gambling/eosdice
  * Emanuel Coen (2020) Emanuel Coen. 2020\.  Transaction fee of Ethereum.  https://cryptotesters.com/blog/ethereum-gas
  * EOS (2018) EOS. 2018.  EOSBet was attacked by Fake EOS vulnerability.  https://www.reddit.com/r/eos/comments/9fpcik/how_eosbet_attacked_by_aabbccddeefg/
  * EOS Cafe Block (2018) EOS Cafe Block. 2018\.  Potential impact of REX on EOSIO’s resource system.  https://medium.com/@eoscafeblock/what-rex-means-for-token-holders-238375dea397
  * EOS GO (2019) EOS GO. 2019.  Gambling DApps are extremely popular in EOSIO.  https://www.eosgo.io/blog/eos-shift-from-gambling-to-gaming-dapps
  * EOS Titan (2020) EOS Titan. 2020\.  DelphiOracle in EOSIO.  https://github.com/eostitan/delphioracle
  * EOSIO (2018) EOSIO. 2018.  EOSIO whitepaper.  GitHub repository.  https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#free-usage
  * EOSIO (2019) EOSIO. 2019.  EOSIO official site.  https://eos.io/
  * EOSIO (2021a) EOSIO. 2021a.  Bug bounty program of EOSIO.  https://eos.io/security-vulnerabilities/
  * EOSIO (2021b) EOSIO. 2021b.  Source code of reference block.  https://github.com/EOSIO/eos/blob/26a4d285d0be1052d962149e431eb81500782991/programs/cleos/main.cpp#L409
  * EOSIO.SG (2018) EOSIO.SG. 2018\.  Private key compormising in EOSIO.  https://medium.com/@eosiosg/announcement-regarding-recent-exploit-event-efe8a1ad5d90
  * ewasm (2020) ewasm. 2020.  Official site of ewasm.  https://github.com/ewasm/design
  * FRANKENFIELD (2019) JAKE FRANKENFIELD. 2019\.  Definition of ICO.  https://www.investopedia.com/terms/i/initial-coin-offering-ico.asp
  * Gao et al. (2019) Jianbo Gao, Han Liu, Chao Liu, Qingshan Li, Zhi Guan, and Zhong Chen. 2019\.  Easyflow: Keep ethereum away from overflow. In _2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)_. IEEE, 23–26.
  * Grech et al. (2018) Neville Grech, Michael Kong, Anton Jurisevic, Lexi Brent, Bernhard Scholz, and Yannis Smaragdakis. 2018.  Madmax: Surviving out-of-gas conditions in ethereum smart contracts.  _Proceedings of the ACM on Programming Languages_ 2, OOPSLA (2018), 1–27.
  * Greg Walker (2016) Greg Walker. 2016\.  Transaction fee of Bitcoin.  https://learnmeabitcoin.com/technical/transaction-fee
  * Hatze (2021) Vlad Hatze. 2021\.  The severe result caused by EIDOS project.  https://dailycoin.com/2021-is-not-the-year-for-eos/
  * He et al. (2021) Ningyu He, Ruiyi Zhang, Haoyu Wang, Lei Wu, Xiapu Luo, Yao Guo, Ting Yu, and Xuxian Jiang. 2021.  $\\{$EOSAFE$\\}$: Security Analysis of $\\{$EOSIO$\\}$ Smart Contracts. In _30th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 21)_.
  * Hilbig et al. (2021) Aaron Hilbig, Daniel Lehmann, and Michael Pradel. 2021\.  An Empirical Study of Real-World WebAssembly Binaries: Security, Languages, Use Cases. In _Proceedings of the Web Conference 2021_. 2696–2708.
  * Huang et al. (2020a) Yuhe Huang, Bo Jiang, and Wing Kwong Chan. 2020a.  EOSFuzzer: Fuzzing EOSIO Smart Contracts for Vulnerability Detection.  _arXiv preprint arXiv:2007.14903_ (2020).
  * Huang et al. (2020b) Yuheng Huang, Haoyu Wang, Lei Wu, Gareth Tyson, Xiapu Luo, Run Zhang, Xuanzhe Liu, Gang Huang, and Xuxian Jiang. 2020b.  Understanding (mis) behavior on the eosio blockchain.  _Proceedings of the ACM on Measurement and Analysis of Computing Systems_ 4, 2 (2020), 1–28.
  * IMEOS (2018) IMEOS. 2018.  Financial loss of the asset overflow attack against eosfo.io in EOSIO.  https://www.chainnews.com/articles/776607864103.htm
  * Jiang et al. (2018) Bo Jiang, Ye Liu, and WK Chan. 2018.  Contractfuzzer: Fuzzing smart contracts for vulnerability detection. In _2018 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE)_. IEEE, 259–269.
  * Larimer (2019) Daniel Larimer. 2019\.  An ideal PRNG prototype in EOSIO.  https://eosio.stackexchange.com/questions/41/how-can-i-generate-random-numbers-inside-a-smart-contract#answer-215
  * Le (2018) Quoc Le. 2018.  EOSDice attacked due to random number.  https://medium.com/leclevietnam/hacking-in-eos-contracts-and-how-to-prevent-it-b8663c8bffa6
  * Lee and Lee (2019) Dongsoo Lee and Dong Hoon Lee. 2019.  Push and Pull: Manipulating a Production Schedule and Maximizing Rewards on the EOSIO Blockchain. In _Proceedings of the Third ACM Workshop on Blockchains, Cryptocurrencies and Contracts_. 11–21.
  * Lee et al. (2019) Sangsup Lee, Daejun Kim, Dongkwan Kim, Sooel Son, and Yongdae Kim. 2019.  Who spent my $\\{$EOS$\\}$? on the (in) security of resource management of eos. io. In _13th $\\{$USENIX$\\}$ Workshop on Offensive Technologies ($\\{$WOOT$\\}$ 19)_.
  * Lehmann et al. (2020) Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020\.  Everything old is new again: Binary security of webassembly. In _29th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 20)_. 217–234.
  * Li et al. (2017) Xiaoqi Li, Peng Jiang, Ting Chen, Xiapu Luo, and Qiaoyan Wen. 2017.  A survey on the security of blockchain systems.  _Future Generation Computer Systems_ (2017).
  * LiquidHarmony (2020) LiquidHarmony. 2020\.  LiquidOracles in EOSIO.  https://medium.com/the-liquidapps-blog/using-liquidoracles-on-eos-wax-telos-liquidapps-dapp-network-developer-walkthroughs-e810087e58e2
  * Michel (2018) Christoph Michel. 2018\.  Limitation of time of executing transaction.  https://cmichel.io/deferred-transactions-on-eos/
  * Michel (2019) Christoph Michel. 2019\.  Attack against EOSPlay.  https://cmichel.io/what-really-happened-with-the-eos-play-hack/
  * Michel (2021a) Christoph Michel. 2021a.  Blog site of EOSIO technology.  https://cmichel.io/categories/EOS
  * Michel (2021b) Christoph Michel. 2021b.  EOSIO re-entrancy attack.  https://cmichel.io/eos-vault-sx-hack/
  * Michel (2021c) Christoph Michel. 2021c.  The re-entrancy attack against Vaults.sx.  https://cmichel.io/eos-vault-sx-hack/
  * MrToph (2019) MrToph. 2019.  Example of paying for user’s CPU.  https://github.com/MrToph/eos-pay-for-user-cpu-example
  * Nakamoto (2019) Satoshi Nakamoto. 2019\.  Bitcoin: a peer-to-peer decentralized cryptocurrency system.  https://bitcoin.org/en/
  * PeckShield (2018) PeckShield. 2018\.  Random number vulnerability.  https://medium.com/@peckshield/defeating-eos-gambling-games-the-tech-behind-random-number-loophole-cf701c616dc0
  * PeckShield Inc. (2018a) PeckShield Inc. 2018a.  EOSBet was attacked by Fake Recipt.  https://blog.peckshield.com/2018/10/26/eos/
  * PeckShield Inc. (2018b) PeckShield Inc. 2018b.  Inline reflex.  https://blog.peckshield.com/2018/12/18/inlineReflex/
  * PeckShield Inc. (2019a) PeckShield Inc. 2019a.  CPU hijacking attack in EOSIO.  https://peckshield.medium.com/eidos-airdrop-stifles-the-liveness-of-eosio-network-acbb8fb5ebb4
  * PeckShield Inc. (2019b) PeckShield Inc. 2019b.  Decrease of daily user resulted from EIDOS project.  https://blog.peckshield.com/2019/11/08/eidos/
  * PeckShield Inc. (2019c) PeckShield Inc. 2019c.  Financial loss of the random number attack against EOSPlay.  https://blog.peckshield.com/2019/09/16/EOSPlay/
  * PeckShield Inc. (2019d) PeckShield Inc. 2019d.  memo attack in EOSIO.  https://bcsec.org/index/detail/tag/1/id/553
  * PeckShield Inc. (2019e) PeckShield Inc. 2019e.  Transaction congestion attack in EOSIO.  https://blog.peckshield.com/2019/01/15/eos_CVE-2019-6199/
  * PeckShield Inc. (2020) PeckShield Inc. 2020\.  Blogs about blockchain security events.  https://blog.peckshield.com/blog.html
  * Perez and Livshits (2021) Daniel Perez and Ben Livshits. 2021.  Smart contract vulnerabilities: Vulnerable does not imply exploited. In _30th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 21)_.
  * Perez et al. (2020) Daniel Perez, Jiahua Xu, and Benjamin Livshits. 2020.  Revisiting Transactional Statistics of High-scalability Blockchains. In _Proceedings of the ACM Internet Measurement Conference_. 535–550.
  * Praitheeshan et al. (2019) Purathani Praitheeshan, Lei Pan, Jiangshan Yu, Joseph Liu, and Robin Doss. 2019\.  Security analysis methods on Ethereum smart contract vulnerabilities: a survey.  _arXiv preprint arXiv:1908.08605_ (2019).
  * Quan et al. (2019) Lijin Quan, Lei Wu, and Haoyu Wang. 2019.  EVulHunter: Detecting Fake Transfer Vulnerabilities for EOSIO’s Smart Contracts at Webassembly-level.  _arXiv preprint arXiv:1906.10362_ (2019).
  * Regehr (2010) John Regehr. 2010\.  Signed multiplication is undefined in C++.  https://blog.regehr.org/archives/213
  * Rodler et al. (2018) Michael Rodler, Wenting Li, Ghassan O Karame, and Lucas Davi. 2018\.  Sereum: Protecting existing smart contracts against re-entrancy attacks.  _arXiv preprint arXiv:1812.05934_ (2018).
  * Rooney (2018) Kate Rooney. 2018\.  ICO of EOSIO has raised up to 4 billion USD.  https://www.cnbc.com/2018/05/31/a-blockchain-start-up-just-raised-4-billion-without-a-live-product.html
  * SlowMist (2019a) SlowMist. 2019a.  Fake deposit attack in EOSIO.  https://slowmist.medium.com/hard-fail-status-attack-for-eos-7cfa73ae7d4b
  * SlowMist (2019b) SlowMist. 2019b.  Fake deposit attack in EOSIO.  https://slowmist.medium.com/details-and-solutions-for-false-top-up-attack-hard-fail-status-attack-on-eos-676b899d27b6
  * SlowMist (2019) SlowMist. 2019.  Random number vulnerability.  https://medium.com/@slowmist/details-of-a-new-type-random-number-attack-on-eos-ede0211d9cc2
  * SlowMist (2019a) SlowMist. 2019a.  Roll Back Attack about blacklist in EOSIO.  https://medium.com/@slowmist/roll-back-attack-about-blacklist-in-eos-adf53edd8d69
  * SlowMist (2019b) SlowMist. 2019b.  Rollback attack for betdiceadmin.  https://github.com/slowmist/eos-smart-contract-security-best-practices/blob/master/README_EN.md#random-number-practice
  * SlowMist Zone (2020) SlowMist Zone. 2020\.  Blockchain security events.  https://hacked.slowmist.io/en/
  * Sotnichek (2018) Mihail Sotnichek. 2018\.  RAM hijacking attack in EOSIO.  https://www.apriorit.com/dev-blog/576-eos-ram-exploit
  * Staff (2021) Cryptopedia Staff. 2021\.  Re-entrancy attack in Ethereum targeting at TheDAO.  https://www.gemini.com/cryptopedia/the-dao-hack-makerdao
  * Stiévenart and De Roover (2020) Quentin Stiévenart and Coen De Roover. 2020.  Compositional Information Flow Analysis for WebAssembly Programs. In _2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM)_. IEEE, 13–24.
  * Titan Labs (2021) Titan Labs. 2021\.  Historical price of CPU resource.  https://labs.eostitan.com/#/cpu-quota/?period=2019&mode=linear
  * Torres et al. (2018) Christof Ferreira Torres, Julian Schütte, and Radu State. 2018\.  Osiris: Hunting for integer bugs in ethereum smart contracts. In _Proceedings of the 34th Annual Computer Security Applications Conference_. 664–676.
  * Wahab and Mehmood (2018) Abdul Wahab and Waqas Mehmood. 2018.  Survey of consensus protocols.  _arXiv preprint arXiv:1810.03357_ (2018).
  * Wang et al. (2020a) Dong Wang, Bo Jiang, and WK Chan. 2020a.  WANA: Symbolic Execution of Wasm Bytecode for Cross-Platform Smart Contract Vulnerability Detection.  _arXiv preprint arXiv:2007.15510_ (2020).
  * Wang et al. (2020b) Wei Wang, Jingjing Song, Guangquan Xu, Yidong Li, Hao Wang, and Chunhua Su. 2020b.  ContractWard: Automated Vulnerability Detection Models for Ethereum Smart Contracts.  _IEEE Transactions on Network Science and Engineering_ (2020).
  * Yan et al. (2020) ZeHui Yan, Weizhong Qian, Zheng Yang, Weiru Zeng, Xi Yang, and Ang Li. 2020\.  TFFV: Translator from EOS Smart Contracts to Formal Verification Language. In _International Conference on Artificial Intelligence and Security_. Springer, 652–663.
  * YUSUFF (2019) OLAYODE YUSUFF. 2019\.  Fake deposit in Ripple.  https://newslogical.com/remitano-halts-bitcoin-ethereum-trading-indefinitely-over-fake-ripples-xrp-deposits/
  * Zhao et al. (2020) Yijing Zhao, Jieli Liu, Qing Han, Weilin Zheng, and Jiajing Wu. 2020.  Exploring EOSIO via Graph Characterization.  _arXiv preprint arXiv:2004.10017_ (2020).
  * Zheng et al. (2020) Weilin Zheng, Zibin Zheng, Hong-Ning Dai, Xu Chen, and Peilin Zheng. 2020.  XBlock-EOS: Extracting and Exploring Blockchain Data From EOSIO.  _arXiv preprint arXiv:2003.11967_ (2020).