Securing the Ethereum from Smart Ponzi Schemes: Identification Using Static Features

In recent years, blockchain technology has received extensive attention from the industry and academia [28, 37]. Simply, a blockchain is a continuously growing chain of blocks (i.e., a ledger) maintained in a distributed network (i.e., peer-to-peer network), where each peer contains a complete copy of the chain [43]. Each block in the ledger contains a certain number of transactions and a corresponding timestamp, and is linked to its previous block by including a hash of it. This decentralized maintenance and hash connection make the blockchain almost immutable because modifying any one block requires simultaneously generating new hash values for all subsequent blocks and getting the approval of more than 50% of the peers.

Due to its immutability nature, blockchain technology has become the cornerstone of many new forms of applications. Bitcoin, and cryptocurrencies like it, are an important class of applications based on it. With the deepening of the research and discussion on the blockchain technology, various blockchain-empowered applications have been emerging. Due to the decentralized nature of blockchain, these new types of applications are called decentralized applications (DApps) [10, 49]. Composed of smart contracts [53, 59], which are executable programs written into the blocks, DApps have many properties different from traditional software (i.e., centralized or distributed software system [49]), such as open-source licensing, internal cryptocurrency support, decentralized consensus, and no central point of failure [10]. According to the statistical results of dapp.review, about 5,000 DApps are running on the blockchain platforms currently, with applications ranging from gambling and lottery to social and financial fields, involving 12,750 smart contracts and more than 250,000 active users. These facts show that decentralized applications have become a new software system that cannot be ignored.

Running on an immutable blockchain, DApps provide users with a sense of trustworthiness. Yet this feature has also been exploited by criminals to create a new type of scam application. These applications themselves do not create any value, operators mainly rely on constantly attracting new users to participate in them to obtain fees and other income. Early players may be able to reap some of the benefits. However, this mechanism of wealth redistribution will inevitably cause irreversible losses to most users and hinder the development of blockchain ecology. These applications are called Smart Ponzi Scheme [2, 17].

Ponzi schemes are a classic type of scams whose core mechanism is to use the investment of new investors to compensate for the previous. Operators maintain the survival of the scam by continuously attracting new investors (and charging fees) through promising high profits. A Ponzi scheme will eventually collapse because it is hard to keep attracting new investors. By building on blockchain and smart contracts, smart Ponzi schemes exhibit many new characteristics. On the one hand, the proceeds of the fraud are some kind of cryptocurrency, and the anonymous and immutable nature of the blockchain makes many investors’ investment irreparable. On the other hand, a large number of ordinary investors are vulnerable to fraud under the veil of the emerging technology. For example, Fomo3D,¹ a game known as a Ponzi Scheme, soon surpassed Cryptokitties² and became one of the most popular games on the Ethereum platform at the time. It is reported that, by the end of the first round of the game, the final winner was awarded more than $3 million, while most ordinary users lost their investment [45].

The existence of smart Ponzi schemes will result in the loss of cryptocurrency (and money) to a large number of relevant participants, which is not conducive to the development of blockchain technology ecology. Thus, just as it is extremely important to detect malicious apps in the Android markets [65], smart Ponzi scheme detection is also an important measure to maintain the DApp ecosystem. Note that “DApp” is more of a user-oriented concept. A DApp is commonly composed of basic smart contracts to run the application and a web client for the user to interact with. Since smart contracts are the building blocks of DApp, the identification of smart Ponzi scheme is mainly aimed at individual smart contracts that apply the logic of Ponzi schemes. Therefore, when Ponzi logic is detected in a specific smart contract, the result is inferred that only this specific part of the DApp is adopting the Ponzi scheme. The detection method can provide a warning message to participants if and only if their transactions interact with this specific address. In this way, it can protect users from involving in Ponzi schemes while minimizing the impact on other benign functionalities of the DApp.

While many of the participants in the previous example (i.e., Fomo3D) may be aware of the potential risks, there are many other smart Ponzi schemes that lure ordinary investors in the guise of an investment plan with high profits (see [17] for an example). In addition, some smart Ponzi schemes that do not provide source code (i.e., hidden smart Ponzi schemes in [17]), in this case, even professionals can not judge whether it is a smart Ponzi scheme. Considering the rapid development of blockchain technology, the majority of users involved lack professional knowledge, and the relatively weak supervision, it is very urgent to study the identification method of smart Ponzi scheme.

Fortunately, there have been studies on the problem of smart Ponzi schemes. Bartoletti et al. discusses the classification of smart Ponzi scheme and its influence [1, 2]. They collected samples of smart Ponzi schemes in two ways: (1) read the source code and collect some samples; (2) a small number of samples of hidden smart Ponzi schemes were obtained by evaluating the bytecode similarity of contracts. Furthermore, Chen et al. constructed the identification of smart Ponzi schemes as a classification problem, and achieved automatic recognition by adopting a machine learning method based on extracted bytecode and account behavior features [17, 18]. For a decentralized ecology, it makes more sense to establish automatic identification of smart Ponzi schemes. However, the current approaches have four main limitations as follows:

Insufficient samples: To build an automatic identification model, sufficient samples are the key. In the previous study (i.e., [2, 17, 18]), the sample size of smart Ponzi scheme is less than 200, and the sample size of non-Ponzi scheme is also not much. This is a complete mismatch with the current number of smart contracts. (Currently, there are millions of smart contracts on the Ethereum platform, including more than 100,000 open-source contracts.)

Reliance on transaction records: The feature extracted from the transaction records of contracts has made a main contribution to the accuracy in existing methods. However, when investigating the Ponzi schemes on Ethereum, we noticed that most of our collected Ponzi schemes have a short lifetime. The median of their lifetime is only about 2.5 days for those contracts with non-zero transactions. The short lifetime of Ponzi schemes leads to weakness of these transaction-based methods. The time for collecting sufficient transactions is enough for most of the Ponzi contracts to complete their lifecycle (in this paper, we use the terms “Ponzi contract” and “smart Ponzi scheme” interchangeably).

Flawed model evaluation method: In study [17] and [18], the model is trained and tested mainly by randomly dividing sample sets. However, as the technology for developing smart contracts iterates over time [66], the later smart Ponzi schemes are often more complex in their technical approach and logic. The method of randomly dividing training sets may lead to the use of newer contract information in model training and the prediction of earlier contracts, thus providing an inflated model effect. And when models are applied to future judgments, they may perform worse than expected.

Low accuracy: For machine learning based detectors, single feature construction method and simple models used in [17, 18] are insufficient to distinguish smart Ponzi schemes. At the same time, the defective evaluation method exaggerates the real effect of the model. In addition, smart Ponzi schemes are always in the minority in a large number of applications, but the sample imbalance problem was not considered in the previous study. On the other hand, detectors based on symbolic execution [15] rely on expert rules to recognize Ponzi schemes. However, with the explosive growth in the number of smart contracts, it is hard for experts to traverse emerging Ponzi schemes and keep updating detection rules for evolving attack strategies. The scalability of detailed rules is potentially limited due to the proliferation of smart contracts, while general rules may lead to high False Positive Rate and high False Negative Rate in practice [31].

To tackle these challenges, we collected more samples and propose a Multi-view Cascade Ensemble method named MulCas for automatic smart Ponzi scheme identification with the following salient features:

High accuracy: To achieve high accuracy of smart Ponzi scheme detection, we extracted multiple layers of rich features from the bytecode of the contract, including bytecode features and semantic features. Similar to [17, 18], we do not use any source code information from the contract, but only the bytecode deployed on the blockchain. In addition, we extract the developer features by parsing the contract creation records on the blockchain. Based on these features, we obtain a better detection effect by using the proposed multi-view cascade ensemble method.

Identification at creation time: Our model uses only the information that must be provided when the contract is created (i.e., bytecode and a deployment transaction record), rather than relying on the interaction information after the contract is created. Thus, the model can make a decision on whether it is a smart Ponzi scheme at its creation time.

Better robustness: By combining the discriminant results from different perspectives, our model has better robustness. Compared with the Baseline model, on the one hand, the effectiveness of the model declined less as the class imbalance increased; On the other hand, the prediction effect of the model is relatively stable over time.

Figure 1 shows the framework of our study, which consists of four steps. Firstly, after collecting and verifying more samples, we convert the bytecode of each contract into opcodes, which is an important source of subsequent features. In addition, by parsing the blockchain data, we extracted all the contract creation transactions to form the creation graph, which is another source of our features. Secondly, through the above two sources, we extract three types of features, namely bytecode features, semantic features, and developer features. Next, we train identification models (i.e., viewers) based on different features. Finally, we present the Multi-view Cascade Ensemble method. The final result of the model includes two parts. The first part is the result with enough confidence in the two kinds of samples (i.e., smart Ponzi scheme and non-Ponzi scheme contract) by cascading different viewers. The other part is the voting result of all viewers for the unconfident samples.

By applying MulCas to the constructed dataset, we find that it exhibits an impressive performance of smart Ponzi scheme detection. In summary, our major contributions include:

The rest of this paper is organized as follows. After provides some background in Section 2, we introduce the dataset construction method and problem definition in Section 3. Section 4 details the proposed method and Section 5 reports the experimental results. After introducing the related work in Section 7, we conclude the paper in Section 8.

One of the main contributions of our work is to manually check the source codes to determine whether a smart contract deploys Ponzi scheme logic. Recall that the key of Ponzi scheme logic is to use the investment of new investors to compensate for the previous investments. Hence, the source code of Ponzi contracts must reflect the same logic. In practice, Ponzi scheme logic can be adopted through various approaches, such as array-based schemes and tree-based schemes introduced in [1].

The following example illustrates how we recognize Ponzi contracts, in other words, how we determine if a smart contract is a Ponzi contract from source code. The example contract, named Daily12, is a verified Ponzi smart contract with source code available on etherscan.io (one of the most famous Ethereum explorer).

We introduce some interesting characteristics of Daily12. As shown in Figure 3, Daily12 is swift: the lifecycle of the contract is only 10 days. The balance of Daily12 rapidly increased to about 146.59 ETH in 3 days but drops to 0 in the following 7 days. We then download all the transactions of the contract to take an insight into this Ponzi contract. According to our statistics, 171.04 ETH had been involved in Daily12 (now about $219,782.98), which is a considerable amount of money. These characteristics encounter our motivation to identify the Ponzi contract at the creation time. To the best of our knowledge, the key component of the existing method is the transaction record of a contract. However, the time for collecting sufficient records may be long enough for a swift Ponzi contract like Daily12 to complete its lifecycle. Therefore, the detection result based on transactions is not that much meaningful as it seems.

The contract has made a seductive claim to attract participants. It promotes itself by claiming that the participants would gain 12% of their investments every day and they could withdraw the profits at any time:

However, the propaganda does not reflect the nature of Daily12. The contract has made its source code available on the etherscan.io to win the trust of the participants. In this sense, we reveal how the Ponzi logic is implemented by Daily12 source code shown in Figure 4.

The source code of Daily12 is brief and concise. Like most traditional Ponzi schemes, the contract would record the investments of participants (line 2). The mapping variable in line 3 records the time that the participants last retrieved their profits. Next, the function in line 4–11 reflects the critical logic of the Ponzi contract. Once the contract receives a transaction, it computes the 12% of the sender’s investment scaled by the time interval (line 6), and transfer the profit back to the sender (line 7), where the so-called profit comes from the investment of the participants.

It could be seen that the payback window size is about 8.3 days, since 100%/12% = 8.33. A participant was able to earn the investment back after 8.33 days, as long as the contract had enough balance. If there is even remaining balance, i.e., there are latter investment, an investor can earn from these investment.

Winning or losing in the Ponzi contract depends on whether there are latter investors. The key is to continuously attract new investors. Daily12 adopted the “12%” trick. In the first 8.33 days, Daily12 uses 12% of the participant’s investment to pay back to him/her, causing an illusion that the payback is stable and continuous. Due to this seeming long life cycle, the contract even received about 0.11 ETH on the last day. However, it could be interpreted that the contract had to use the investment of latter participants to compensate for the profit after running out of the investment of the previous.

This mechanism leads to the fact that only the earlier participants could win in the Ponzi contract. Figure 5 shows the ether flow of the smart contract. The ether flow graph is introduced to visualize the transactions involved in a smart contract. Three types of transactions are encoded in the graph: investment, payback, and profit. These types of transactions are denoted by blue circles, green squares and orange triangles, respectively. Only those who earned from the contract chould receive profit transactions (i.e., orange triangles in the graph). The amount of ether involved in these transactions are reflected by the size of the circles. The x-axis represents the time line, while the y-axis represents individual participants. There are also two lines in the figure. The solid line is the regression line of investments and the dotted line is the regression line of first profit transaction for each investor. Several insights come with the two lines: (1) The dotted line roughly splits the payback area (green) and profit area (orange). Investors can only get profit from the orange area below the dotted line. A number of investors have no transactions below the dotted line, meaning that they are victims of the Ponzi contract; (2) The two lines are parallel, indicating the payback window of 8.33 days. And the left margin of orange area have composed another parallel line of payback. Notably, most of the earned participants had made their first investment in the early stage of the contract. The fact is that only those investments before block height 6547454 (the contract lifetime minus the payback window size) have a chance to earn from the contract. Unfortunately, some early investors still lost their money. They reinvested the contract several times after their first investment. Apparently, they did not understand the degenerating nature behind the seemingly high and stable profit.

The Daily12 example shows that a Ponzi contract can be swift but may involve a considerable amount of money. Detection methods based on transaction records have weak constraints on these contracts, since the contracts may have completed their life cycle before sufficient transaction records are collected. Therefore, it is significant to develop a detection method independent of transaction records.

As is presented in Figure 6, the dataset is built in the following steps:

We make several notes for our dataset collecting procedure:

After collecting and checking the smart contracts with open source code, we obtain 6,498 smart contracts, among which there are 314 smart Ponzi schemes (i.e., Ponzi contracts). These smart contracts range from height 0 to height 7,500,000. The statistical features of the lifetime of these Ponzi contracts are shown in Table 1. It is not surprising that the Ponzi contracts usually have a short life since they do not create any value. As explained in Section 3.1, this phenomenon meets our motivation to identify the Ponzi contract at its creation time. Ponzi contracts usually do not last a long time, so transaction-based methods are not able to alleviate the damage caused by Ponzi contracts on Ethereum.

Since smart contracts are the building blocks of DApps, the identification of smart Ponzi schemes is essentially the identification of whether any contracts it contains are Ponzi schemes or not. Let \(C = \lbrace c_1, c_2 \ldots ,c_n\rbrace\) be a set of smart contracts with labels \(L = \lbrace l_1, l_2,\ldots , l_n\rbrace\) , where n is the number of contracts. The contracts labeled with \(-\) 1 (i.e., negative) are non-Ponzi contracts, while contracts labeled with 1 (i.e., positive) are Ponzi contracts. Let \(D = \lbrace d_1, d_2,\ldots , d_n\rbrace\) be the set of developer information of the corresponding contracts, where the developer information of a certain contract is composed of its creator address and the height of the creation block. Let \(B = \lbrace b_1, b_2, \ldots , b_n\rbrace\) be the bytecode of the corresponding contracts. The task of our work is to construct a high-performance classification model to classify given contracts into non-Ponzi contracts or Ponzi contracts, where only bytecode B and developer information D are used for classification.

With Dataset built in Section 3.2, we have the following information: (1) labeled bytecodes of contracts; (2) contract creation records. In this stage, bytecodes are converted to opcodes and the developer features are constructed.

For bytecode, Ethereum yellow paper [59] has provided a complete table to convert binary instruction to mnemonic forms, i.e., opcodes. Therefore, the conversion is done in the following steps: (1) tokenize bytecode into tokens; (2) convert these tokens into opcodes according to the instruction set. A disassembler⁵ can be used to convert bytecode to operation code. The operation code is composed of two parts: opcodes and operands. For example, the mnemonic form “PUSH1” is an opcode and the hexadecimal number “0x80” following this opcode is an operand. In our preprocessing stage, the operands are discarded for the reason that the operands are pure hexadecimal numbers which are highly dependent on individual smart contracts, and the introduction of these numbers should increase the model complexity dramatically. Insight into these operands remains for future research.

For contract creation records, we construct a creator vector as the developer feature. The detailed construction method will be introduced in Section 4.2.

In this stage, we will use the opcodes and contract developer information as inputs to extract features from different views. Note that the opcodes are series of tokenized mnemonic words, so they can be viewed as documents containing tokenized opcodes as words. Thus, feature extraction methods in the scope of natural language processing can be fit into the opcode data.

To investigate which features could be leveraged to build an effective model, statistical analysis are firstly conducted before we select which features to use. Consequently, several feature extraction methods are conducted from different views. First, term frequency count and TF-IDF value are calculated based on the Bag-of-Words model [47]. The two methods view the documents as an unordered set of words. Besides, N-grams and TF-IDF for N-grams are calculated from the view of considering locality of words in contiguous sequences. Moreover, the word2vec [36, 40] algorithm is performed to embed opcodes into vectors from a semantic view. Furthermore, we present a novel feature extracted from developer information called creator vector and prove the effectiveness of this feature.

In this stage we have an input of 5 types features concatenated with developer feature, each providing a distinctive view of the dataset. This stage mainly aims to train models based on each of the features. Here, the term “viewer” is used to refer to the machine learning model fited with those features from different views.

There have been a number of classification models proved to be useful in many fields, including liner models such as SVM [52] and ridge regression [34], tree-based models such as random forest classifier [38] and XGBoost [13]. The five features retrieved in the previous stage are fitted to the above models and the performances of these models are grouped by their training features. We selected the models with the best performance on the testset for each kind of features. At last, five final models are kept, each of which comprehends the data from distinctive views concerning the features fitted to the model. These models include XGBoost trained with term count feature, N-gram count feature, N-gram TF-IDF feature, and ridge regression trained with TF-IDF feature.

To achieve a comprehensive view of the data, model ensemble techniques are effective to merge the models trained in the previous stage. Given the models with distinctive views of the dataset, we propose a Cascade Multi-view Ensemble algorithm to achieve a comprehensive model. The pseudocode is shown in Algorithm 2.

The ensemble is achieved by two main steps: a cascade ensemble in the training step and a vote-based ensemble in predicting step.

Algorithm 2 takes in the input of a collection of viewers V, two threshold values \(\theta\) and \(\lambda\) , complexity control parameter N, trainset and testset. Among the inputs, the complexity control parameter N is used to restrict the maximum iterations in cascade ensemble step. The \(\theta\) denotes the confidence threshold of predictions. In other words, if the predicted probability is larger than \(1-\theta\) or smaller than \(\theta\) , the model is considered to be confident in this prediction. The other parameter \(\lambda\) serves for the voting mechanism, where a sample receiving votes more than \(\lambda\) is considered to be positive.

At the beginning of Algorithm 2, a cascade ensemble in training step is performed (lines 3–10). Specifically, the trainset and testset is fitted to the first viewer and the viewer then makes predictions on both of the two sets. According to the prediction results, the trainset and testset are split into a confidently-predicted subset, if the probability prediction is larger than \(1 - \theta\) , and an unconfidently-predicted subset, if the probability prediction is smaller than \(\theta\) . The threshold is commonly chosen as 0.05, a commonly used significant level in the fields of statistics. This threshold can be set to other values for certain purposes as well. For example, the threshold measuring confident positive predictions could be set to 0.51 so as to trade precision score for recall score, where the precision score and recall score are two commonly used metrics in classification. The trade is reasonable under the consideration that it is more of a problem if we missed a Ponzi contract than misclassified a normal contract. Secondly, the unconfident trainset and unconfident testset are passed to the second viewer and a similar procedure is carried out for \(N-1\) times.

In the end, the testset is now split into two subsets: confidently-predicted subset and unconfidently-predicted subset. Predictions of the confidently-predicted subset are set to predictions made by the cascade-ensemble predictors. For the unconfidently-predicted set, a voting mechanism is introduced to make predictions (lines 12–25).

The voting mechanism synthesizes all the viewers as voters. In this step, the viewers are trained with all data in trainset for the reason that the remaining unconfidently-predicted trainset is relatively small and the information may be inadequate to be used for predicting the remaining testset.

From the above steps, we have built a Ponzi scheme detection model based on smart contract bytecode and developer information. Since the detection procedure does not need any human intervention, the model could be integrated into a local platform or local client to monitor the creation of smart Ponzi schemes. The detection pipeline could be divided into two modules: data collection and detection. For the data collection task, the same procedure in Section 3.2 could be leveraged, i.e., use Ethereum client such as OpenEthereum⁶ to collect smart contract bytecode and extract developer information from historical transactions. Once a new smart contract is deployed, the corresponding bytecode and developer information could be passed to the detection module. In the detection module, the features in 4.2 could be automatically extracted for MulCas to classify the target smart contract. Once a smart contract is detected to be a Ponzi contract, the monitor client could label the contract address and update the developer information. In this way, the client could provide a warning message to users if any of their transactions will be involved in a smart Ponzi scheme.

Our results face common validity threats due to the biased distribution of the dataset. The dataset in Section 3.2 is built from open-source smart contracts under two main concerns: feasibility and reliability. Since Ponzi logic represents a high-level semantic behind the direct control flow or data flow of a contract, manually recognizing Ponzi logic from bytecode is neither feasible nor reliable. Decompilation tools [25] can be leveraged to mitigate the difficulty, but the error introduced by these tools and the error introduced by recognizing Ponzi logic from the decompiled code can still add imprecision to our dataset. Thus, while we exhibit our detection model from the bytecode level to ensure our model to be capable of analyzing all smart contracts deployed on Ethereum, our evaluation phase is purely based on those smart contracts with available source code. The distribution of open-source smart contracts may differ from the distribution of the entire smart contract family on Ethereum. Thus, our results are best interpreted with respect to the benchmarks we analyzed.

From the practical view, however, building an automatical detection tool for Ponzi scheme is necessary for two reasons: (1) Blockchain users may not be sophisticated in programming and smart contracts. Their interaction with some DApps may be done through a Web interface. Thus, users may not be experienced enough to tell whether a smart contract deploys Ponzi logic by reading the contract code. (2) As described in the Introduction section, one of the main motivations of the proposed work is to detect latent Ponzi contracts based only on bytecode. It may be unrealistic to identify these latent Ponzi contracts based on reading the bytecode or opcode. Our methods can provide a warning guide for users before they interact with bytecode-only contracts. Considering that plenty of latent Ponzi contracts are running on Etherum (as can be found in the previous studies by Bartoletti et al. [1], Chen et al. [17] and SadPonzi [15]), our methods can necessarily benefit the Ponzi scheme detection procedure on the whole Ethereum ecosystem. Therefore, the ML methods indeed have their weakness such as bias to the dataset, but using ML methods in Ponzi scheme detection task has its practical value.

While the experiments have studied the robustness of Ponzi contract detection methods, we essentially assumed adversarial attacks as orthogonal problems. However, the sustainability against adversarial attacks still falls into practical concerns. Since the main efforts of our method rely on treating the bytecode as natural language tokens, adversaries may cheat the model by purposed code injections. Most of our captured features (i.e., word frequency, TF-IDF, N-gram) focus on the quantitative information of opcode tokens. One possible adversarial attack may inject dead code to cheat on the quantitative information. However, junk code injection in the context of Ethereum introduces overhead costs of extra gas. Gas is a specific mechanism introduced by Ethereum to measure the consumption of computational expenses on the Ethereum network. A smart contract costs gas in two phases: (1) the contract deployment; (2) the contract call. Generally speaking, the longer a smart contract is, the more gas it costs [12, 26]. Therefore, this economical concern may hinder an effective junk code injection process.

On the other hand, we note that the Ponzi scheme detection problem on Ethereum is still in the early stage. Because: (1) most recently reported Ponzi contracts⁹ still have not adapted any schemes to evade existing detection methods, such as those proposed in [12]; (2) to the best of our knowledge, there are no platforms that integrate existing Ponzi contract detection tools, while plenty of smart contract auction platforms have adopted the tools developed in the field of smart contract vulnerability detection [6, 54]. Therefore, developing a Ponzi scheme detector with robustness against adversarial attacks is left for our future work.

An additional limitation of MulCas comes with the rapid evolution of Solidity compilers. As a newly emerging program language, Solidity compiler has gone through several important compiler optimizations to fix vulnerabilities and introduce compile options such as dead code elimination. Due to the rapid change of Solidity compiler, a smart contract may be compiled to two slightly different pieces of bytecode under different compiler version. A more detailed study of the difference introduced by compiler version can be found in the work of Huang et al. [29]. Along with Solidity compiler evolution, the unpredictable contract evolution maybe another challenge for our code-based detector. For example, as the DAO brought reentrancy vulnerability into the public concern, developers has now adapted various approaches to exclude the reentrancy vulnerability in their smart contracts. The continuous and unpredictable contract evolution may be another trigger of retraining the MulCas detector.

The proposed detection method is oriented at individual smart contract. The model ignores the interaction between multiple smart contracts even when they are in the same DApp. Therefore, the detection model may miss Ponzi schemes deployed in multiple smart contracts where they collaborate toward malicious behaviors. Smart contracts deployed on Ethereum does not necessarily provide the information that which DApp it belongs to. There has been researches for modeling inter-contract interactions by performing a backward data-flow analysis to recover the contract invocation relationship [5]. Through contract invocation recovery, multiple smart contracts could be manually incorporated into an integrated smart contract for analysis.

Smart contracts are a key component of blockchain 2.0 and the building block of DApps. Since smart contracts are essentially a collection of bytecode running on Ethereum, vulnerability concerns also exist in the programming of smart contracts. The vulnerability has been extensively studied in traditional software. Combinatorial testing [24] and a combination of dynamic and static features [35] are used for fault localization. Niu et al. [42] further studied Minimal Failure-Causing Schema with respect to multiple faults. However, when it comes to smart contracts, the decentralized nature has brought new vulnerability concerns. To ensure the security of the contract, various vulnerability identification tools are proposed [4, 33, 39]. Yu et al. [62] proposed a general-purpose approach to search and repair the bugs in smart contracts. Besides, the security properties have been studied as reachability properties based on the abstraction of EVM bytecode [51]. To understand the potential impact of the vulnerability of smart contracts, Sayeed et al. [50] analyzed the 7 most important attack techniques and reveal that even adopting the 10 most widely used tools to detect smart contract vulnerabilities, there still exist known vulnerabilities. This fact makes the development of secure smart contracts from a software engineering perspective an important research direction [20, 58].

There have been plenty of studies concerning the malware detection problem in the scenario of traditional software. Part of these studies leverages machine learning technologies to build classification models. Cai et al. [9] used a diverse set of dynamic features for Android app classification. Di Xue et al. [61] deployed convolutional neural networks to analyze static features and variable n-grams for dynamic features. Other works studied the sustainability of these learning-based detectors and proposed classification systems based on a new behavioral profile for Android apps [8]. Besides, Java Bytecode has also been verified to detect Android malware families [11]. On the other hand, malicious scams are also popular in the blockchain ecology due to the lack of regulation and decentralized nature. For example, money laundering [22, 41, 55], Ponzi Scheme [3, 56] and market manipulation [16, 23]. A summary of this problem can be found in [57]. To identify these scams, identification models based on machine learning and data mining are widely used. In view of Ponzi schemes in the bitcoin ecology, Bartoletti et al. built a model based on machine learning by extracting transaction records and constructing features [3]. As for smart Ponzi schemes in Ethereum, Chen et al. [17, 18] first proposed the identification framework based on machine learning, which is also the baseline of this study. Ibba et al. [30] and Fan et al. [21] have explored the Ponzi scheme detection problem by using other machine learning models such as Decision Tree, Support Vector Machine and gradient boosting algorithms. Apart from machine learning based methods, static problem analysis method such as Symbolic execution has also been leveraged to detect Ponzi schemes on Ethereum [15]. In terms of phishing scam identification, graph-based methods are widely used in recent studies [14, 60].