# Toward Vulnerability Detection for Ethereum Smart Contracts Using Graph-Matching Network
## 4 Methodology
### Abstract Semantic Graph Generation
#### 4.2.2. ASG from Bytecode  
Recently, many smart contracts have been uploaded to the blockchain in forms of bytecode without publishing the source code. In this case, generating ASG from bytecode is much more challenging [35], but they share the same methodology, targeting to extract syntactic and semantic features to represent the code. Given the bytecode of a smart contract, we set up three steps to generate ASG from the bytecode, including decompilation, CFG construction, and normalization. For the purpose of clarity, we use BASG (Bytecode ASG) to denote ASG from bytecode in this section. Figure 5 illustrates an example of BASG, which is generated based on basic block sequences and enriched by control flow. Bytecode is a string of hexadecimal numbers; in order to extract syntactic information from the bytecode, it should be decompiled the first time. The bytecode deployed on the blockchain, i.e., runtime code, can be divided into three code segments. The first segment contains the opcodes that the EVM executes. The second segment is optional, and usually used to store static data. The last segment contains metadata, such as hashes of the code and compiler version. In Figure 4, an example of bytecode is also provided. According to the yellow paper of Ethereum [36], we can easily obtain opcodes from the bytecode. For instance, the bytecode 0 \(\times\) 6070604001 can be decompiled to (PUSH1, 0 \(\times\) 70, PUSH1, 0 \(\times\) 40, ADD), where opcode 0 \(\times\) 60 indicates PUSH1 with one operand (i.e., 0 \(\times\) 70 and 0 \(\times\) 40) and opcode 0 \(\times\) 01 indicates ADD. Thus, EVM will execute two PUSH1 instructions to push two values, i.e., 0 \(\times\) 70 and 0 \(\times\) 40, to the stack, then consume these two elements  
Figure 5: Bytecode abstract semantic graph generation based on basic block sequences and enriched by control flow. to execute an ADD instruction, leaving their sum 0 \(\times\) B0 as a result. By traversing all of the runtime code, the opcodes of the overall smart contract can be obtained. Although opcodes provide elementary information about the bytecode, they are still not quite analyzable. In order to obtain more semantic information and thus to understand the program behaviors, these opcodes should be analyzed in an organized form. In this case, we construct CFG to further represent the code as follows. First, the opcodes are grouped in basic blocks, which are also utilized as nodes of BASG. Then, opcodes that alter the control flow of the program (e.g., JUMP and RETURN) are resolved to augment control edges to the BASG. A basic block is a sequence of opcodes that are executed consecutively without any instruction that alters the flow of control. In Solidity, opcodes that can alter the control flow are mainly listed as JUMP, JUMPI, STOP, REVERT, RETURN, INVALID, and SELFDESTRUCT, but for jump-like instructions, the destination needs to be resolved from the stack. We employ the symbolic stack execution technique [35] to obtain these control edges. Accurate CFG construction for the bytecode is still an ongoing research topic which is beyond the scope of this paper. Before the current form of BASG is fed to the training model, it is required to perform normalization to mitigate syntax noises, thus improving the semantic expressiveness of the BASG. We consider to normalize both opcodes and operands in this step. On one hand, opcodes with the same functionality, such as PUSH1 and PUSH32, are normalized to a general form, such as PUSHX. Stack operators that manipulate elements internally, such as DUP, POP, and SWAP, can be omitted from the semantic perspective. Table 1 lists all mappings from original opcodes to their normalized forms. On the other hand, in bytecode, operands that follow opcodes are usually hexadecimal numbers, which are determined by the program layout. Directly leveraging them as features will introduce noises in the training model, whereas replacing them with uniform notations has little influence on featuring the code.