CN110766411A

CN110766411A - Method for detecting inconsistent behavior in Ethengfang token transactions

Info

Publication number: CN110766411A
Application number: CN201911034560.8A
Authority: CN
Inventors: 陈厅; 张愉菲; 李子豪; 罗夏朴; 王挺; 曹蓉; 肖修卓; 张小松; 牛伟纳
Original assignee: University of Electronic Science and Technology of China
Current assignee: University of Electronic Science and Technology of China
Priority date: 2019-10-29
Filing date: 2019-10-29
Publication date: 2020-02-07

Abstract

The invention relates to a method for detecting inconsistent behaviors in Ether house token transactions, which comprises the following steps: capturing an execution track when the client is fully synchronized; B. extracting each transaction standard method set; C. extracting a standard event set, and recording the modification of a data structure of transaction to an Ether house database; D. comparing each transaction with the modified data set, identifying a core data structure and an Etherhouse token contract, and recording a mapping relationship; E. scanning all transaction information again, and extracting the modification of the core data structure and the Ether house database when the identified Ether house token contract is found; F. and comparing the standard method set and the standard event set called by each transaction with the modified data set, and judging that the transaction behaviors are inconsistent if any two are different. The invention can identify whether a single or a plurality of linked token contracts are Ether house token contracts and automatically identify whether the realization of the Ether house token transactions meets the transaction behavior standard.

Description

Method for detecting inconsistent behavior in Ethengfang token transactions

Technical Field

The invention relates to a detection method for computer data security, in particular to a detection method for inconsistent behaviors in Ethengfang token transactions.

Background

The success of bitcoin has spurred the birth of many cryptocurrencies, most of which are deployed and run on etherhouses in the form of smart contracts. An intelligent contract is a program that represents the nature of a contract running on an ethernet house virtual machine (a program module of an ethernet house client). While intelligent contracts have a wide range of applications, their specific contract content may relate to tokens, gambling or other uses. The token contract is a specific contract form of the intelligent contract and is specially used for token transaction. Some scrip contracts implement specifications and standards for the interaction of scrip with users and third party instruments (e.g., blockchain wallets, blockchain exchange markets, etc.), such as etherhouse scrip standards including numerous standards such as ERC20, ERC223, ERC667, ERC777, ERC 995. In each standard, a plurality of standard methods (functions) and standard events are defined. A user may invoke a certain standard method (function) in a token contract by sending a string of numbers to the account address of the token contract. These tokens involve a large amount of funds and actions inconsistent with the standard may result in misunderstanding of the true status of the funds by the user and even loss of property. Therefore, analysis of tokens is crucial.

In the document detection Token Systems on Ethereum,

two methods for identifying token contracts by analyzing bytecodes of an Etherhouse Virtual Machine (EVM) were proposed: (1) identified by the method code of the standard interface; (2) token transaction behavior is detected using symbol execution and taint analysis techniques. These methods have the following disadvantages: (1) the approach of method code identification is prone to false positives, for example, if a certain constant in the smart contract code is equal to the code of the standard interface. (3) Neither approach is able to detect token transaction behavior that collaborates across contracts. (4) The focus of both methods is simply to identify whether a certain intelligent contract is a token contract, and not to identify whether the implementation of a token contract meets the criteria.

In the document "Network Analysis of ERC20 token Trading on ethereum blockchain", Somin et al identify the transaction behavior of Tokens by analyzing the Transfer event to perform a transaction Network Analysis, the following problems exist with this method: transfer events do not necessarily reflect the actual token behaviour and contract code implementation that does not meet the standards may result in Transfer events being distinct from the actual token transaction behaviour, and Somin et al do not concern whether the implementation of Transfer events is inconsistent with the definition of the standards.

In the document Smart check, statistical Analysis of Ethereum Smart controls, Sergei Tikhomirov et al converts the source code of an intelligent contract written by solid into an intermediate representation form based on XML, and checks according to an XPath mode to detect 21 bugs in the source code. It cannot be easily extended to detect inconsistencies in Ethernet Virtual Machine (EVM) bytecodes because (1) it requires the source code of the intelligent contract; (2) detection of inconsistencies requires knowledge of the semantics of the program, but pattern search does not support such semantics.

Disclosure of Invention

The invention provides a method for detecting inconsistent behaviors in Ether house token transactions, which can identify whether a single or a plurality of linked intelligent contracts are Ether house token contracts or not, detect the inconsistent behaviors of the occurred Ether house token transactions and automatically identify whether the realization of the Ether house token transactions meets transaction behavior standards or not.

The invention discloses a method for detecting inconsistent behaviors in Ether house token transactions, which comprises the following steps:

the first stage is as follows: extracting core data structures and identifying etherhouse token contracts:

A. acquiring an execution track: when the client is in full synchronization, all transactions which are executed historically and are replayed on the client are captured through the client, transaction information of each transaction is captured through the client at the moment, the transaction information comprises an operation instruction and information of an intelligent contract, and the set of the transaction information of all transactions is used as an execution track;

B. extracting a standard method called by each transaction according to the detected standard of the Ethenhouse token from each transaction information in the execution track to form a standard method set;

for example, token transactions need to be detected according to the etherhouse token ERC20 standard, six standard methods and two standard events are defined in the ERC20 standard, of which only the two standard methods transfer and transfer from are related to token transactions. Thus, when a transaction is analyzed, it is determined whether the method called in the transaction is transfer or transfer from. If the method is transfer or transfer from, it is judged that the method calls the standard method of ERC20 and extracts the standard method in the transaction. If all the called methods in the transaction are irrelevant to the standard methods in the ERC20 standard, the transaction is not the transaction required by the detection, the transaction is skipped, and the next transaction in the execution track is judged.

C. Analyzing an operation instruction and an operand of each transaction in an execution track, extracting a standard event called by each transaction according to the detected standard of the Ethernet shop token to form a standard event set, and recording the modification of a data structure of each transaction to an Ethernet shop database;

D. comparing the data set of each transaction after the modification of the Ether house database according to the data structure with the standard method set or the standard event set of the transaction invoked by the intelligent contract one by one, if the data set and the standard event set are completely consistent, the data structure is regarded as the core data structure of the transaction, the intelligent contract invoked by the transaction is regarded as the Ether house token contract, and the mapping relation of the Ether house contract address-core data structure of the transaction is recorded. Because there are many data structures in the intelligent contract, it is necessary to record the modification of the ethernet database by each data structure in step C, and then compare the modified data set with the standard method set or standard event set called by the transaction one by one, and when finding the consistent data structure, it is the core data structure that meets the detected ethernet token standard.

The core data structure represents the mapping relation of (account address-balance), the data set modified by the Ethernet workshop database through the core data structure is the variable quantity of the balance after the transaction, the standard method set comes from the calling of the user to the transaction initiated message and represents the number of the tokens to be traded, and the standard event set comes from the instruction of the Ethernet workshop client and represents the operation of the Ethernet workshop client according to the transaction requirement of the user. Thus, in a correct transaction, the modified data set (amount of balance change) of the etherhouse database, the standard method set (amount of tokens that the user requires for the transaction), and the standard event set (instructions for the etherhouse client) should be consistent.

And a second stage: detecting consistency of the transaction behavior of the Ether house token according to the mapping relation:

E. scanning the replayed transaction information of all the transactions again, extracting a corresponding core data structure according to the contract address of the Ethernet house token through the mapping relation corresponding to the Ethernet house token contract when a transaction receiver in certain transaction information is found to be the Ethernet house token contract identified in the step D, searching whether the modification of the Ethernet house database by the core data structure is involved in the transaction, and recording if the modification is involved in the transaction;

F. and E, comparing the standard method set and the standard event set which are respectively called by the Ethenhouse token contract of each transaction according to the transaction recorded in the step E with the contents of the data set modified by the Ethenhouse database according to the core data structure, if any two of the standard method set and the standard event set are different, judging that the realization of the Ethenhouse token contract of the transaction is inconsistent with the Ethenhouse token standard, and outputting information of inconsistent transaction behaviors.

When the consistency of the Etherhouse token transaction behaviors is detected, the standard transaction behaviors must be determined, so that all historical transactions (which may be thousands or tens of thousands) need to be scanned for the first time to gather an execution track, extract its core structure from the execution track, determine which transaction-invoked intelligent contracts are Etherhouse token contracts, and record the < Etherhouse token contract address-core data structure > mapping relations of the transactions. And then scanning all historical transactions for the second time, and judging whether the transactions meet the Etherhouse token standard or not according to the core data structure of each transaction. Because different methods (functions) are implemented in the token contract called for each transaction, some methods are compliant with the standard methods defined in the EtherFang token Standard, some methods are custom methods, and some methods are not compliant with the standard methods. It is therefore desirable to find the standard transaction behavior from all transactions, extract the core data structure from all transactions, re-scan all transactions, and check each transaction for compliance with the etherhouse token standard based on the standard transaction behavior.

Further, in step a, after the instrumented client is started in the full synchronization mode by instrumenting the source program of the client, the client may start to play back all the transaction records from the founding block of the block chain in the full synchronization process, that is, download the received block information from the nodes of other running etherhouse clients on the network to the local, and then play back the received block information locally.

Further, in step F, according to the core data structure in the mapping relationship, if any one of the standard method, the standard event of a certain transaction or the data set modified from the ethernet vault database according to the core data structure is found to relate to the address 0, the address of the ethernet vault contract itself or the address of the creator of the ethernet vault token, the comparison is performed after deleting the part related to these addresses. For example, the creator of the etherhouse token has an etherhouse token reissue to all users, and the sender address of the transaction is the etherhouse token contract address itself, which is a special transaction. When a similar special transaction is found at the time of verification, the transaction is considered to be compliant with the etherhouse token standard.

Further, in step if found, if the method called by the etherhouse token contract in the transaction is found not to belong to the standard method defined in the etherhouse token standard, the standard method set of the transaction is set to null, and only the standard event set related to the transaction and the data set modified to the etherhouse database are compared to see if the contents are the same. For example, invoked in a transaction is a method customized in the tori token contract rather than the standard method defined in the etherhouse token standard.

On the basis, in step F, the information of the inconsistent transaction behavior comprises the contract address of the Ethernet bay token which does not conform to the standard of the Ethernet bay token and the transaction data set of the inconsistent behavior.

The method for detecting inconsistent behaviors in the token transaction of the ether house has the advantages that:

1. the coverage rate of the intelligent contract is high, and the inconsistent transaction behaviors can be detected without providing the source code of the intelligent contract as long as the execution track of the real transaction exists after the intelligent contract is deployed.

2. The method can identify the cross-contract transaction behaviors, collects all execution tracks in each transaction, records the multi-contract linkage behaviors, and can analyze the cross-contract token transaction behaviors.

3. Whether the intelligent contract called by the transaction is an Ether house token contract or not can be efficiently identified, the core of the identification lies in whether the transaction behavior of the Ether house token is really realized or not, and corresponding standard event notification or standard method calling needs to be carried out, so that the misinformation that the effective information of static analysis byte codes is insufficient is avoided.

4. The method can identify whether the behaviors of the standard method, the standard event and the core data structure are consistent or not and whether the behaviors accord with the standard of the token or not, and fills the gap of industrial research.

The present invention will be described in further detail with reference to the following examples. This should not be understood as limiting the scope of the above-described subject matter of the present invention to the following examples. Various substitutions and alterations according to the general knowledge and conventional practice in the art are intended to be included within the scope of the present invention without departing from the technical spirit of the present invention as described above.

Drawings

FIG. 1 is a flow chart of a method of detecting inconsistent behavior in Etherhouse token transactions in accordance with the present invention.

Fig. 2 is a mapping structure diagram of embodiment 1.

Fig. 3 is a mapping structure diagram of embodiment 2.

Fig. 4 is a mapping structure diagram of embodiment 3.

Fig. 5 is a mapping structure diagram of embodiment 4.

Detailed Description

The Etherhouse token standard includes numerous standards such as ERC20, ERC223, ERC667, ERC777, ERC995, etc., and this embodiment is described in terms of the ERC20 standard for Etherhouse tokens. The 6 standard methods and 2 standard events for etherhouse token transactions are defined in the ERC20 standard. The embodiment judges whether the realization of the contract of the token meets the ERC20 standard by comparing the parameters of the standard method, the content of the standard event and the mapping content change representing the holder and the holding amount of the token and searching whether the transaction behaviors of the token are inconsistent.

The method for detecting inconsistent behavior in an ether house token transaction of the present invention as shown in figure 1 comprises:

A. acquiring an execution track: and starting the instrumented client in a full synchronous mode by performing instrumentation on a source program of the client. When the client is in full synchronization, downloading the received block information to the local from the nodes of other running EtherFan clients on the network, and playing back all transactions which are executed historically on the client, wherein the transaction information of each transaction is captured by the client at the moment, the transaction information comprises an operation instruction called when each transaction is executed and information of a called intelligent contract, and the set of the transaction information of all transactions is used as an execution track;

D. comparing the data set of each transaction after modifying the Ether house database according to the data structure with the standard method set or the standard event set of the transaction invoked by the intelligent contract one by one, if the data set and the standard event set are completely consistent, considering the data structure as the core data structure of the transaction, and the intelligent contract invoked by the transaction is about the Ether house token contract, and recording the mapping relation of the < Ether house contract address-core data structure > of the transaction;

F. comparing the contents of the standard method set, the standard event set and the data set modified by the Etherhouse token contract for each transaction respectively called by the Etherhouse token contract for the transactions recorded in step E, and if any one of the standard method, the standard event or the data set modified by the Etherhouse database for a certain transaction is found to relate to the address 0, the Etherhouse token contract address itself or the creator address of the Etherhouse token, deleting the part related to these addresses. If any two of the trade marks are different after comparison, judging that the realization of the Ether house token contract by the trade is inconsistent with the Ether house token standard; if the method called by the Ether house token contract for the transaction does not belong to the standard method defined in the Ether house token standard, setting the standard method set of the transaction as null, only comparing whether the contents of the standard event set related to the transaction and the data set modified by the Ether house database are the same or not, and if not, judging that the implementation of the transaction to the Ether house token contract is inconsistent with the Ether house token standard.

Each account has a 20 byte combined numeric and alphabetical (hexadecimal) account address, the 0 address is that the 20 bytes are all 0, and the 0 address is very common in blockchain transactions as a special address.

In making a determination on a transaction involving a special address such as the 0 address, the Etherhouse token contract address itself, or the Etherhouse token creator address, for example:

set of standard methods: and (4) empty collection.

Set of standard events: (A, -100), (B, +100), i.e., the A address is shifted to the B address by 100 Etherhouse tokens.

Data set after modification of EtherFang database: (A, -100), indicating that the A address withholds 100 EtherFang tokens.

The set of standard methods in this transaction is an empty set and therefore does not participate in the comparison.

And step one, judging whether the comparison standard event set is consistent with the data set modified by the Ethengfang database, and finding inconsistency.

Second, identify whether both addresses A and B are creators, Etherhouse token contract Address itself, or 0 Address, and if at this point B address is found to be the Etherhouse token contract Address itself, then all data in the standard event set related to B Address in the database-modified data set is deleted, and then (B, +100) is deleted in the standard event set.

And thirdly, comparing and deleting the data after being related to the B address, wherein only (A, -100) is left in the standard event set and is completely consistent with the content of the data set after the database is modified. Then the transaction is deemed to be in compliance with the etherhouse token standard.

For another example, if the transaction is:

set of standard methods: and (4) empty collection.

Set of standard events: (A, -50), (B, +50)

Data set after modification of EtherFang database: (A, -100)

At this time, if B is a special address, the (B, +50) standard event in the standard event set is deleted, and (a, -50) remains in the standard event set, which is not the same as the database modified data set (a, -100), then the transaction is considered to be not compliant with the ethernet token standard, and is inconsistent transaction behavior.

Finally, the information of the inconsistent transaction behaviors is output, and the information comprises the information of the contract address of the Ethernet house token which does not conform to the standard of the Ethernet house token, the transaction data set of the inconsistent behaviors, and the like.

Example 1:

the vast majority of ERC20 tokens at etherhouses use an < account address-account balance > mapping structure to store token holders and holding balances. This structure establishes a one-to-one mapping of an account's address to the balance of tokens it holds. As shown in fig. 2, it is illustrated how the balance of an account address is read from the database using the corresponding mapping code. There is also a corresponding solid source code (i.e., "assets" addr ") and a corresponding EVM instruction (etherhouse virtual machine instruction). The structure firstly carries out hash operation on the account address and the mapping code through an instruction SHA3 of the EVM to obtain a new address value. Then, through the command SLOAD of the EVM, the content stored in the location is read from the ethernet database according to the obtained new address value, which is the balance of the account address. Similarly, if a new balance is to be written, a new address is calculated from the account address and the mapping code using the SHA3 instruction, and then written using the SSTORE instruction.

Assuming that the token mintToken belongs to such a mapping structure, the address is:

0xcccccccccccccccccccccccccccccccccccccccc；

the inconsistent behavior detection process for token transactions is as follows:

the first stage is as follows: extracting core data structures and identifying etherhouse tokens:

1. first, assume that there are currently two external transaction accounts:

account address A: 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; the number of mintTokens is 100;

b, account address: 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, the number of mintToken held is 0.

2. When the account A needs to transfer to the account B, the transfer needs to be realized through mintToken. And sending a message to the mintToken by the account A, triggering the execution of an intelligent contract of the mintToken, and completing the transfer from the account A to the account B through the execution of the intelligent contract of the mintToken.

Therefore, when the account A transfers to the account B, a transaction is initiated on the client, the receiver of the transaction is mintToken, and the carried information of the transaction is as follows:

0xa9059cbb000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb0000000000000000000000000000000000000000000000000000000000000006。

3. the execution track records the following information:

external transaction initiator address: 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;

external transaction recipient address: 0 xccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc;

external transaction carrying information:

0xa9059cbb000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb0000000000000000000000000000000000000000000000000000000000000006；

and a series of EVM (ethernet virtual machine) operations generated during execution of mintToken.

4. And analyzing the execution track information. First, the first five bytes in the external transaction carrying information are extracted: 0xa9059cbb, which was found to be the same as the hash value of the method transfer defined in the ERC20 standard, so the dataset for this standard method invocation was recorded as:

according to the definition of method transfer in the ERC20 standard, the sender of mintToken is the initiator of the external transaction, namely:

0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver of mintToken is the first parameter in the carried information, i.e. after the first 5 bytes are removed from the carried information, the 1 st 32 bytes of data, i.e.:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the last 20 bytes are extracted and added with 0x to be the address of the corresponding receiver:

0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the transaction amount of mintToken is the second parameter in the method, and after the first 5 bytes are removed from the carried information, the 2 nd 32 bytes of data are:

0000000000000000000000000000000000000000000000000000000000000006；

taking the effective part which is not 0 and adding 0x to obtain the transaction amount, namely 0x 6;

the resulting standard method data set was:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

5. the calling of the intelligent contract can execute the EVM instruction, and all the EVM instructions can be recorded as an execution track.

6. Key instructions in the execution trace are fetched. First, the LOG3 command is called in the transaction, which represents the event notification, and the contents of the event notification are recorded as follows:

ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb0000000000000000000000000000000000000000000000000000000000000006；

extracting the data of the first 32 bytes, comparing the data with the events defined by the ERC20 standard to obtain that ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef is matched with the standard event Transfer, and then recording the standard event set as follows:

according to the definition of the standard event Transfer, the contents recorded in the standard event set are as follows in sequence: a sender of mintToken, a receiver of mintToken, and a transaction amount of mintToken. Starting with the 2 nd 32 bytes of LOG3 data, every 32 bytes, these data are represented in turn. Namely:

the sender:

000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

transaction amount:

0000000000000000000000000000000000000000000000000000000000000006；

wherein, the data representing the address takes 20 bytes later, and 0x is added in front; taking a part of which the data representing the transaction amount is not 0, and adding 0x in front of the part; and finally, obtaining a standard event set:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6)，

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

7. then, the mapping structure will be fetched according to the other EVM instructions:

① SHA3 command, which can obtain two parts of data from SHA3 command, value involved in calculation and result of calculation, wherein the value involved in calculation is (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 1), and the result of calculation is a hash value, which is replaced by the variable name keccak _ a;

② SSTORE instruction, which is a data write instruction that records the address written, the value before the local address modification, and the new value after the write, where the address captured for the write is keccak _ a, the value before the operation is 100, and the value after the operation is 94;

③, according to the same value keccak _ a, the SHA3 and SSTORE data are related, they belong to the mapping structure of < account address-account balance > shown in fig. 2 (i.e., core data structure), the address of the operation is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, the mapping code is 1, the written balance is changed from 100 to 94, and it can be seen that the change amount is-0 x6. results in the first modification of the mapping of code 1 in the present transaction (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, -0x 6);

④ SHA3 command, two parts of data can be obtained from the SHA3 command, the value involved in the calculation and the result of the calculation, wherein the value involved in the calculation is:

(0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, 1), the result of the calculation is a hash value, which is replaced with the variable name keccak _ b;

⑤ SSTORE instruction, which records the operation address, the local address before operation value, and the operation value, wherein, the operation address is keccak _ b, the operation value before 0, the operation value after 6;

⑥ the SHA3 and SSTORE data can be related according to the same value keccak _ b, they belong to the mapping structure (i.e. core data structure) of < account address-account balance > shown in FIG. 2, the address of the operation is 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, the mapping is 1, the written value is changed from 0 to 6, the variable quantity is 0 x6., and the mapping second modification content (0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, 0x6) of the coding 1 is obtained.

8. Finally, the modified dataset of the mapping to etherhouse database coded as 1 is:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

9. comparing the modified data set of the Ethernet shop database with the standard event set according to the mapping coded as 1, and finding the complete agreement, so that the contract mintToken is considered to be an Ethernet shop token, wherein the special data structure representing the relationship between the holder and the holding amount is the mapping coded as 1 (namely: a core data structure), and the information is used as the token contract implementation standard of the client during the Ethernet shop transaction.

10. the account A initiates a transaction again through the client, the receiver of the transaction is mintToken, and the carried data is as follows:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005。

11. the execution track records the following information:

external transaction carrying information:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005；

and a series of EVM operations generated during mintToken execution.

12. And analyzing the executed track information. First, the first five bytes in the external transaction carrying information are extracted: 0xa0712d68, which does not belong to the hash value of the standard method defined in the ERC20 standard, so no special record is made and the set of standard methods is empty.

13. And searching a log instruction in the EVM, finding that the transaction has no log instruction, and setting the transaction as an empty set.

14. Capture, according to other EVM instructions, whether there is token transaction activity:

② where the SHA3 command has a mapping code of 1, indicating that a token transaction is being conducted, the transaction account is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, and the new address code for the account balance is keccak _ a;

③ SSTORE, this instruction records the address of the operation, the value before the local address operation, and the value after the operation, where the address of the operation is keccak _ a, the value before the operation is 94, and the value after the operation is 99.

According to the key ccak _ a, the real transaction account corresponding to the operation is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, and the balance change amount of the account is 0x 5.

15. Since there is no other operation, the data set of this mapping is output (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 0x 5).

16. Comparing the standard method set, the standard event set and the data set modified by the Taifang database according to the mapped data set, omitting the standard method set (the standard method set is empty) because the method calling is nonstandard, and only comparing the standard method set and the standard event set. It can be seen that, since the standard event set is an empty set, and the mapping set is not empty, the transaction behavior of the token is inconsistent, and does not meet the standard of ERC20, the reason for the inconsistency is: when the money transaction behavior occurs, the notification is not carried out by the standard event, and the standard event set is empty.

17. And finally, outputting the address of the inconsistent token at this time and the data content of the standard method set, the standard event set and the mapping set.

Example 2:

the partial ERC20 token on the etherhouse uses an < account address-structure > mapping structure to store token holders and holding balances. The mapping structure establishes a one-to-one correspondence between the account address and a structure containing the token holding amount of the account and some other information. Fig. 3 shows how the balance of an account address, and its corresponding solid source code (i.e., "account" equals balance addr. account ") and the corresponding EVM command are read from the database using such mapping codes. The method comprises the steps of firstly carrying out hash operation on an account address and a mapping code to obtain a value of a new address, wherein a corresponding EVM instruction is SHA 3. Then, an offset is obtained according to the relative position of a variable representing the balance of the token in the structure, and the new address is added with the offset through an instruction ADD of the EVM, so that the address value of the balance is obtained. And finally, reading the value of the balance from the database according to the calculated address of the balance, wherein the corresponding EVM instruction is SLAAD. Similarly, if a new balance is to be written, the address of the balance is calculated and then written by using the SSTORE instruction.

Assume that the token mintToken2 belongs to such a mapping structure with an address:

0xcccccccccccccccccccccccccccccccccccccccc；

1. assume that there are currently two external transaction accounts

Account address A: 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; holding mintToken2 as 100;

b, account address: 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, the number of minToken 2 held is 0.

2, the account A initiates a transaction on the EtherFang, the receiver of the transaction is mintToken2, and the carried information of the transaction is as follows:

3. the execution track records the following information:

external transaction carrying information:

and mintToken2 performs a series of EVM operations that are generated in the process.

according to the definition of method transfer in the ERC20 standard, the sender of mintToken2 is the initiator of the external transaction, namely:

0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver of mintToken2 is the first parameter in the carried information, i.e. the 1 st 32 bytes of data after the first 5 bytes are removed from the carried information, i.e.:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the transaction amount of mintToken2 is the second parameter in the method, and after the first 5 bytes are removed from the carried information, the 2 nd 32 bytes of data are:

0000000000000000000000000000000000000000000000000000000000000006；

the resulting standard method data set was:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

5. the calling of the contract executes the EVM instruction, and all the EVM instructions are recorded.

6. The key instruction is fetched. First, this transaction calls, captures the LOG3 command, represents the event notification, and records the event notification as:

ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb0000000000000000000000000000000000000000000000000000000000000006。

extracting the first 32 bytes of data, comparing with the event defined by ERC20 standard, finding that ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef is matched with the standard event Transfer, and recording the standard event set as follows:

according to the definition of the standard event Transfer, the contents recorded in sequence are as follows: the sender of mintToken2, the receiver of mintToken2, the transaction amount of mintToken 2. Starting with the 2 nd 32 bytes of LOG3 data, every 32 bytes, these data are represented in turn. Namely:

the sender:

000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

transaction amount:

0000000000000000000000000000000000000000000000000000000000000006；

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

7. according to other EVM instructions, the mapping structure is extracted:

② SSTORE instruction, which records the address of the operation, the value of the local address before the operation, and the value after the operation, wherein the address of the operation is (keccak _ a +5), the value before the operation is 100, and the value after the operation is 94;

③ since SSTORE has only a single bit difference from SHA3 in hash value, the data of SHA3 and SSTORE can be associated with the address of the operation:

0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the written value changed from 100 to 94, with a change of-0 x 6; the mapping for code 1 was obtained at offset 5 with data modification (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, -0x 6);

⑤ SSTORE instruction, which records the address of the operation, the value of the local address before the operation, and the value after the operation, wherein the address of the operation is (keccak _ b +5), the value before the operation is 0, and the value after the operation is 6;

⑥ since SSTORE has only a single bit difference from SHA3 in hash value, the data of SHA3 and SSTORE can be associated with the address of the operation:

0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the written value changed from 0 to 6, and the amount of change was seen to be 6; the mapping for code 1 is obtained at an offset of 5 and the second datum is (0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, 0x 6).

8. Finally, the mapping with code 1 has a set of modifications to the etherhouse database at offset 5 as:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

9. comparing the data set mapped to the offset 5, coded as 1, with the standard event set, and finding a perfect match, then consider the contract mintToken2 to be an etherhouse token, where the special data structure representing the relationship between the holder and the holding amount is: the offset 5 position in the map coded as 1 (i.e., the core data structure).

10. the account a initiates a transaction again through the client, the recipient of the transaction is the token mintToken2, and the carried data is:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005。

11. the execution track records the following information:

external transaction carrying information:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005；

12. And analyzing the execution track information. First, the first five bytes in the external transaction carrying information are extracted: 0xa0712d68, which does not belong to the hash value of the standard method defined in the ERC20 standard, so no special record is made and the set of standard methods is empty.

13. Through a log instruction in the EVM, the transaction triggers a standard Transfer log, and the data set comprises:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,0x5),

(0x0000000000000000000000000000000000000000,-0x5)。

14. then according to other EVM instructions, whether there is token transaction action is captured:

① SHA3 command, which can obtain two parts of data from SHA3 command, value involved in calculation and result of calculation, wherein the value involved in calculation is (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 1), and the result of calculation is a hash value, which is replaced by the variable name keccak _ a 2;

② the SHA3 command has a mapping code of 1, indicating that a token transaction is being conducted, the transaction account is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, and the new address for the account balance is keccak _ a 2.

③ SSTORE, this instruction records the address of the operation, the value before the local address operation, and the value after the operation, where the address of the operation is keccak _ a3, the value before the operation is 94, and the value after the operation is 99.

From (keccak _ a3 ═ keccak _ a2+5), it can be seen that the SSTORE command is associated with a map coded as 1, an offset of 5 indicates that a token transaction operation is in progress, the actual transaction account for the corresponding operation is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, and the amount of change in the balance of the account is 0x 5.

15. Since there is no other operation, this set of mapping data (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 0x5) is finally output.

16. And comparing the standard method set, the standard event set and the data set modified by the Etherhouse database according to the mapping data set, wherein the standard method set is null because the method calling is nonstandard, the standard method set is omitted, and only the standard method set and the data set are compared. It can be seen that there are one more standard event than mapping sets:

(0x0000000000000000000000000000000000000000,-0x5)

since the 0 address belongs to a special address and otherwise the data is the same, the interference of the 0 address is eliminated, which is considered a normal token issuance behavior and is in accordance with the ERC20 standard.

17. And finally, no output is made after the detection is finished because the abnormality is not detected in the transaction.

Example 3:

the portion of the ERC20 token on the ether house uses a mapping structure of < account address-structure array > to store token holders and holding balances. The structure establishes a corresponding relation between an account address and a structure array, the structure array records all historical balances of the account, each element of the array comprises the balance of the account at a certain time node, and the last record of the array comprises the current latest token holding amount of the account. Fig. 4 shows how to use such mapping codes to read the balance of an account address from the database, and its corresponding solid source code (i.e., "account ═ balance [ addr ] [ balance [ addr ]. length-1]. account;) and its corresponding EVM instruction. The method comprises the steps of carrying out hash operation on an account address and a mapping code to obtain an address code of a structure array, wherein a corresponding EVM instruction is SHA 3. And secondly, reading the current length of the structure array from the position of the address coding identifier of the structure array by using an SLAAD instruction, then subtracting the length value by using a SUB instruction, multiplying the value by the size of a single structure, and obtaining an offset corresponding to the MUL instruction. Thirdly, the address coding of the structure array is subjected to SHA3 operation again, and then the address coding is added with the offset obtained in the second step, so that the address coding of the last item of the structure array corresponding to the ADD instruction is obtained. Thirdly, adding the offset of the variable representing the balance of the token in the structure body and the address code of the last item of the structure body array to obtain the code of the address of the current balance of the account, and reading the code by using the SLAAD. Similarly, writes may be made using SSTORE instructions.

Assuming that the token mintToken3 belongs to this class, the address is:

0xcccccccccccccccccccccccccccccccccccccccc；

1. assume that there are currently two external transaction accounts

Account address A: 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; holding mintToken3 as 100;

b, account address: 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, the number of minToken 3 held is 0.

Initiating a transaction on the client by the account A, wherein the receiver of the transaction is mintToken3, and the carried information of the transaction is as follows:

0xa9059cbb000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb0000000000000000000000000000000000000000000000000000000000000006

3. the execution track records the following information:

external transaction carrying information:

and mintToken3 performs a series of EVM operations that are generated in the process.

4. And analyzing the execution track information. Extracting the first five bytes in the external transaction carrying information: 0xa9059cbb, which was found to be identical to the hash value of the method transfer defined in the ERC20 standard, so the dataset for this standard method invocation was recorded:

according to the definition of method transfer in the ERC20 standard, the sender of mintToken3 is the initiator of the external transaction, namely:

0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver of mintToken3 is the first parameter in the carried information, i.e. the 1 st 32 bytes of data after the first 5 bytes are removed from the carried information, i.e.:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the transaction amount of mintToken3 is the second parameter in the method, and after the first 5 bytes are removed from the carried information, the 2 nd 32 bytes of data are:

0000000000000000000000000000000000000000000000000000000000000006；

the resulting standard method data set was:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)

5. the contract call executes the EVM instruction, and all EVM instructions are recorded.

extracting the first 32 bytes of data, comparing with the event defined by ERC20 standard, finding that ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef is matched with the standard event Transfer, and recording the standard event data set as follows:

according to the definition of the standard event Transfer, the contents recorded in sequence are as follows: a sender of mintToken3, a receiver of mintToken3, a transaction amount of mintToken 3. Starting with the 2 nd 32 bytes of LOG3 data, every 32 bytes, these data are represented in turn. Namely:

the sender:

000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

transaction amount:

0000000000000000000000000000000000000000000000000000000000000006；

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

7. according to other EVM instructions, the mapping structure is extracted:

① SHA3, calculates the value of (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 1) and gives a result of keccak _ a;

② SSTRORE instruction, which stores a value, labeled len, at location keccak _ a;

③ SHA3 indicates that the value involved in the calculation is keccak _ a, and the result is keccak _ a 2;

④ SSTRORE instruction, stores the value at location (keeccak _ a2+ len-1):

0000000000000000000000000000011700000000000000000000000000000064；

the length of the value is 32 bytes, the length of the structure is 1, but the number of elements in the structure is at least 2, so the 32 bytes are split into two values:

0x00000000000000000000000000000117,

0x00000000000000000000000000000064；

⑤ because of the type of the structure array, a key value pair is maintained during the recognition process, the key is composed of the address of minToken 3, the code of the mapping is 1, and the address is 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, the value is an array, new elements are added at the end of the array continuously, the element is the value stored in the position (keeccak _ a2+ len-1) of the SSTORE, by this method, the last element of the array is taken each time, the data of the last transaction can be obtained, here, the content of the last mapping is taken according to the key value pair:

000000000000000000000000000001060000000000000000000000000000005e；

the same is split into two values: 0x 0000000000000000000000000116 and 0x0000000000000000000000000000005 e; the difference from the current transaction is 0x1 and-0 x6, respectively;

finally, a mapping with a code of 1 can be obtained, for an address:

there are two data sets for 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, the first 16 bytes of data being (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 0x1) and the last 16 bytes of data being (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, -0x 6).

⑥, when the same instruction structure appears again, a mapping with an encoding of 1 is captured, there are two data sets for the address 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, 0x1), and the data of the first 16 bytes is (0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.

8. Finally, there are two sets of data for the modification of the ether house database by the mapping encoded as 1:

the first 16 bytes:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,0x1),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x1)；

the last 16 bytes:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

9. comparing the modified data set of the ether house database with the standard event set according to the mapping coded as 1, and finding that the last 16 bytes of the mapping 1 are completely consistent with the standard event content, at this time, the contract mintToken3 is considered as a token, and the special data structure representing the holder and the holding amount in the token is as follows: the last 16 byte positions in the stored data (i.e., the core data structure) in the map encoded as 1.

10. account a initiates a transaction again through the ethernet client, the recipient of the transaction is mintToken3, and the carried data is:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005。

11. the execution track records the following information:

external transaction carrying information:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005；

13. By searching a log instruction in the EVM, the transaction triggers a standard Transfer log, and the data set comprises:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,0x0),

(0x0000000000000000000000000000000000000000,0x0)。

② SSTRORE instruction, having a value len stored at location keccak _ a;

③ SHA3, the calculated value is keccak _ a, the result is keccak _ a 2;

④ SSTRORE instruction, stores the value at location (keeccak _ a2+ len-1):

0000000000000000000000000000011800000000000000000000000000000000；

the last 16 bytes from which the value stored in the previous transaction was taken is 0x5e, and this time is directly set to 0, indicating that the modified value is (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, -0x5 e).

15. And comparing the modified data set of the Ether database with the standard method set, the standard event set and the mapping data set, and omitting the standard method set only after comparison because the method calling is nonstandard and the standard method set is empty. It can be seen that the standard method does not match the contents of the standard event, even if the data associated with the address of the special address 0 is removed, the remaining amount of change is still different for the address 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa. The implementation of tokens is not in compliance with the standard.

16. And finally, outputting the address of the inconsistent token at this time and the data content of the standard method set, the standard event set and the mapping set.

Example 4:

the portion of the ERC20 token on the ether house uses a double mapping structure to store token holders and holding balances. Some token contracts have very complex mappings requiring more than one encoding to be used. Fig. 5 shows how to use the mapping code to read the account balance of a certain token under the mapping relationship, and the corresponding solidity source code ("asset. wallets [ hardindendex [ addr ] ]. amout;) and EVM instruction of the structure. The first step is to use SHA3 command to perform hash calculation on the account balance and a mapping code to obtain an address code, and use SLAAD command to read out a special code corresponding to the account balance from the address code, which is called index value. And secondly, performing hash calculation on the index value and the mapping second code by using an SHA3 instruction to obtain a code of a structure body address, calculating the offset of a token balance variable in the structure body, and adding the offset to the structure body address to read the balance of the current account by using an SLAAD instruction.

Assuming that the token mintToken4 belongs to this class, the address is:

0xcccccccccccccccccccccccccccccccccccccccc；

1. assume that there are currently two external transaction accounts:

account address A: 0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; holding mintToken4 as 100;

b, account address: 0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, the number of minToken 4 held is 0.

Initiating a transaction on the client by the account A, wherein the receiver of the transaction is mintToken4, and the carried information of the transaction is as follows:

3. the execution track records the following information:

external transaction carrying information:

and mintToken4 performs a series of EVM operations that are generated in the process.

4. And analyzing the execution track information. First, the first five bytes in the external transaction carrying information are extracted: 0xa9059cbb, which was found to be identical to the hash value of the method transfer defined in the ERC20 standard, so the dataset for this standard method invocation was recorded:

according to the definition of method transfer in the ERC20 standard, the sender of mintToken4 is the initiator of the external transaction, namely:

0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver of mintToken4 is the first parameter in the carried information, i.e. the 1 st 32 bytes of data after the first 5 bytes are removed from the carried information, i.e.:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

the transaction amount of mintToken4 is the second parameter in the method, and after the first 5 bytes are removed from the carried information, the 2 nd 32 bytes of data are:

0000000000000000000000000000000000000000000000000000000000000006；

the resulting standard method data set was:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)

extracting the first 32 bytes of data, comparing with the event defined by ERC20 standard, finding that ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef is matched with the standard event Transfer, recording the standard event data set:

according to the definition of the standard event Transfer, the contents recorded in sequence are as follows: a sender of mintToken4, a receiver of mintToken4, a transaction amount of mintToken 4. Starting with the 2 nd 32 bytes of LOG3 data, every 32 bytes, these data are represented in turn. Namely:

the sender:

000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa；

the receiver:

000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb；

transaction amount:

0000000000000000000000000000000000000000000000000000000000000006；

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)。

7. according to other EVM instructions, the mapping structure is extracted:

① SHA3 instruction with an operand of (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 1) resulting in a value of keccak _ id;

② SLOAD instruction, which takes out a value from the address keccak _ id, and represents it with the symbol address ID;

③ SHA3 instruction has the operands:

(0x000000000000000000000000000000000000000c,2), resulting in a value of keccak _ assets;

④ SHA3 instruction, operand is (addressID, keccak _ assets +1), the resulting value is keccak _ assets _ balance;

⑤ SSTORE stores data at the location keccak _ assets _ balance, the value written changes from 100 to 94, it can be seen that the amount of change is-0 x6. since keccak _ assets _ balance comes from address ID, related to mapping 1, and also from keccak _ assets, related to mapping 2. finally the mapping with code 1, and the mapping with code 2 at the offset 1, together form a complex mapping structure of minToken 4, and the transaction data set is (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, -0x 6).

⑥ SHA3 instruction has the operands:

(0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb), the value obtained is keccak _ id 2;

⑦ SLOAD instruction, fetching a value address ID2 from the address keccak _ id 2;

⑧ SHA3 instruction has the operands:

⑨ SHA3, the operand is (addressID2, keccak _ assets +1), the resulting value is keccak _ assets _ balance 2;

⑩ SSTORE command, data is stored in the position keccak _ assets _ balance2, the written value is changed from 0 to 6, the visible variation is 0 x6., the mapping of code 1 is obtained, and the mapping of code 2 is at the position with the offset of 1, which together form a complex mapping structure (i.e. core data structure) of minToken 4, and the transaction data set is (0 xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb, 0x 6).

8. Finally, the modification set of the double mapping structure to the Ether house database is as follows:

(0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa，-0x6),

(0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,0x6)

9. comparing the modified data set of the Etherhouse database according to the mapping coded as 1 with the standard event set, and finding the complete agreement, at this time, the contract mintToken4 is considered as a token, and the special data structure representing the holder and holding amount in the token is: the map coded as 1 and the map coded as 2 are at the location of offset 1 (i.e., the core data structure).

10. the account a initiates a transaction again through the client, the recipient of the transaction is the token mintToken4, and the carried data is:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005。

11. the execution track records the following information:

external transaction carrying information:

0xa0712d680000000000000000000000000000000000000000000000000000000000000005；

13. And searching a log instruction in the EVM, and finding that the transaction has no event notification.

① SHA3 instruction has the operands:

(0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 1) to obtain a value of keccak _ id;

② SLOAD instruction, taking out a value address ID from the address keccak _ id;

③ SHA3 instruction has the operands:

⑤ SSTORE directive, stores data at location keccak _ associations _ balance, writes the value from 94 to 99, and transacts the data set as (0 xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 0x 5).

16. And comparing the modified data set of the Ether database with the standard method set, the standard event set and the mapping data set, and omitting the standard method set only after comparison because the method calling is nonstandard and the standard method set is empty. It can be seen that, since the standard event set is an empty set, and the mapping set is not empty, the transaction behavior of the token is inconsistent, and does not meet the standard of ERC20, the reason for the inconsistency is: when the money transaction behavior occurs, the notification is not carried out by the standard event, and the standard event set is empty.

Claims

1. A method for detecting inconsistent behavior in an ether house token transaction, comprising:

2. The method of detecting inconsistent behavior in ethernet token transactions of claim 1, wherein: in the step a, by performing instrumentation on the source program of the client, after the instrumented client is started in the full synchronization mode, the client may start to replay all the transaction records from the created block of the block chain in the full synchronization process.

3. The method of detecting inconsistent behavior in ethernet token transactions of claim 1, wherein: in step F, if any of the standard methods, standard events of a certain transaction or the modified data set of the ethernet vault database according to the core data structure is found to relate to the 0 address, the ethernet vault contract address itself or the creator address of the ethernet vault token, the comparison is performed after the sections related to these addresses are deleted.

4. The method of detecting inconsistent behavior in ethernet token transactions of claim 1, wherein: in step F, if the method called by the ethernet house token contract in the transaction is found not to belong to the standard method defined in the ethernet house token standard, the standard method set of the transaction is set to null, and only the standard event set involved in the transaction and the data set modified for the ethernet house database are compared for the same content.

5. Method of detection of inconsistent behaviour in ether house token transactions according to one of claims 1 to 4, characterised by: in step F, the information of the inconsistent transaction behavior includes an ethernet house token contract address that does not comply with the ethernet house token standard and a transaction data set in which the inconsistent behavior occurs.