MultiCFV: Multimodal Deep Learning for Smart Contracts

• MultiCFV is a multimodal deep learning framework that unifies bytecode-derived control flow graphs, AST structures, and comment semantics to detect smart contract vulnerabilities and code clones.
• It addresses shortcomings of unimodal approaches by integrating behavioral, syntactic, and semantic signals to boost detection accuracy and generalization.
• The framework supports dual tasks of vulnerability verification and clone detection, demonstrating competitive performance against traditional static analysis tools.

to=arxiv_search.search 天天彩票app 彩神争霸代理 微信公众号天天中彩票json {"query":"(Peng et al., 2 Aug 2025) MultiCFV smart contracts multimodal deep learning", "max_results": 5} to=arxiv_search.search 彩神争霸app 微信公众号天天中彩票json {"query":"smart contract vulnerability detection clone detection multimodal deep learning control flow graph abstract syntax tree comments", "max_results": 10} MultiCFV is a multimodal deep-learning framework for smart contracts that targets two related tasks: detecting erroneous control flow vulnerabilities and finding code clones. Its central premise is that no single representation of a smart contract is sufficient: bytecode-level control flow captures execution behavior, source-level abstract syntax captures structural and syntactic intent, and comments provide weak but useful semantic hints about what the contract is supposed to do. The framework therefore combines bytecode-derived control flow graphs, abstract syntax trees, and source comments into a unified representation for vulnerability verification and clone retrieval (Peng et al., 2 Aug 2025).

1. Definition and problem scope

MultiCFV is designed specifically for what the paper terms “erroneous control flow vulnerabilities,” a category framed as flaws in the handling of exceptions, external calls, permissions, or behavioral transitions that can cause the contract to execute in unsafe ways. The four vulnerability classes emphasized are reentrancy, impermissible access control, dangerous delegatecall, and unchecked external call. The appendix gives three reasons for focusing on them: they account for a large share of real Ethereum losses, they are prevalent in newer Solidity versions, and they are representative instances of erroneous control flow (Peng et al., 2 Aug 2025).

The framework is positioned against two limitations in prior smart-contract analysis. First, traditional static analyzers often depend on hand-written rules and expert knowledge, which are expensive to build and brittle against new vulnerability variants. Second, many deep-learning approaches remain unimodal, operating only on source code, only on bytecode, or only on graphs, which the authors argue causes loss of semantic information and weakens both accuracy and generalization. MultiCFV is proposed as a response to these limitations and is explicitly claimed to be the first application of multimodal deep learning to this vulnerability setting.

This framing is inseparable from the deployment properties of smart contracts. Since contracts are immutable once deployed, flaws cannot be easily patched after release. Because contracts often control valuable assets, execution errors can directly translate into financial loss. A plausible implication is that the paper treats control-flow-oriented bugs as especially consequential because they sit at the interface between intended logic and actual EVM execution.

2. Multimodal architecture and representation design

The method is organized into four stages: control flow feature extraction, AST feature extraction, comment feature extraction, and fusion for contract verification and clone detection. The output of each modality is a fixed-size vector in $\mathbb{R}^{512}$, later stacked into a contract-level multimodal representation (Peng et al., 2 Aug 2025).

For the control-flow modality, the pipeline begins with source code but deliberately moves to bytecode. The contract source is compiled with a public compiler into EVM bytecode, and the authors’ automated CFG extraction tool, “Graphextractor,” reconstructs a control flow graph from the compiled bytecode. The motivation is that the CFG should reflect actual executable behavior at the EVM level rather than only source-level syntax. In this graph, nodes are bytecode basic blocks and edges are typed control-flow transitions. A basic block is defined as a consecutive sequence of EVM instructions ending at branch-like instructions such as JUMP, JUMPI, or RETURN. Four edge types are distinguished: unconditional jump edges, true-branch conditional edges, false-branch conditional edges, and function-call edges to external functions.

For the syntax modality, the source code is parsed by an “ast-generation” tool into ASTs. Selected structural attributes are then fed to what the paper describes only as “a simple deep learning model” to obtain $F_{ast}\in\mathbb{R}^{512}$. This encoder is one of the framework’s least specified components: the paper does describe the extracted AST attributes and node categories, but it does not fully specify the AST model architecture, loss, or encoding equations.

For the semantic-comment modality, comments are extracted from the contract source, cleaned by removing invalid characters, symbols, and meaningless words, and then processed by “com-extractor,” described as a convolutional neural network with a self-attention mechanism. The model extracts both keywords and a contract-level comment feature vector. The paper states that the number of extracted keywords depends on comment length and that the keywords represent the contract. It also notes that many contracts mention SafeMath and mathematical operations, suggesting that comments may reveal implementation intent or domain-specific semantics.

3. Bytecode CFG modeling and GRU-GCN embedding

The contract’s control-flow information is formalized as

$O_{cfg} = (GP, NF, CN),$

where $GP$ encodes graph structure, $NF$ the node features, and $CN$ the contract name. The graph component is defined as

$GP = \{(u, g, v) \mid u, v \in V, g \in G\},$

where $V$ is the node set and $G$ is the set of edge types. The node-feature matrix is written as

$$NF = \begin{pmatrix} \mathbf{f}_1 & \mathbf{f}_2 & \mathbf{f}_3 & \cdots & \mathbf{f}_N \end{pmatrix}^\top$$

with each node vector $F_{ast}\in\mathbb{R}^{512}$0, i.e.

$F_{ast}\in\mathbb{R}^{512}$1

Node features are created by a vulnerability-specific fine-tuned BERT model over EVM instruction sequences in bytecode blocks. The stated rationale is that EVM instruction sequences and comments exhibit contextual dependencies, and that Transformer-based contextual embeddings can better capture semantics than shallow embeddings. The paper further states that BERT is fine-tuned separately for each vulnerability type before being used for embedding, with the explicit aim of improving feature-extraction precision (Peng et al., 2 Aug 2025).

After obtaining the CFG and node features, the system applies graph embedding through a GCN followed by GRU layers, referred to as GRU-GCN. The graph convolution layer is written as

$F_{ast}\in\mathbb{R}^{512}$2

although the manuscript notes that the notation is malformed and the intended operation is standard GCN-style adjacency propagation followed by a linear transformation and ReLU. The output dimension is set to $F_{ast}\in\mathbb{R}^{512}$3. The GRU stage is then defined by the usual gated recurrences:

$F_{ast}\in\mathbb{R}^{512}$4

$F_{ast}\in\mathbb{R}^{512}$5

$F_{ast}\in\mathbb{R}^{512}$6

$F_{ast}\in\mathbb{R}^{512}$7

The hidden-state matrix

$F_{ast}\in\mathbb{R}^{512}$8

is then passed through fully connected and regression layers to obtain the final graph embedding

$F_{ast}\in\mathbb{R}^{512}$9

The manuscript records several internal inconsistencies. One sentence describes bytecode-block features as “256-dimensional vectors obtained from BERT embeddings,” while the formula and later discussion define node vectors of length $O_{cfg} = (GP, NF, CN),$0. By contrast, the downstream CFG representation is unambiguously stated as $O_{cfg} = (GP, NF, CN),$1. This suggests that the final representation size is stable even if one intermediate dimensionality is inconsistently reported.

4. AST and comment modalities

The AST branch uses directly extracted source-level structure as a complement to bytecode behavior. The extraction focuses on node roles, child roles, number of children, whether variables are present, and whether input or output parameters appear. The appendix lists categories such as ContractDefinition, FunctionDefinition, StateVariableDeclaration, ModifierDefinition, FunctionCall, IfStatement, ForStatement, WhileStatement, BinaryOperation, UnaryOperation, ReturnStatement, ThrowStatement, EmitStatement, VariableDeclarationStatement, Identifier, and literals. The text emphasizes fields such as type and kind, where type denotes the AST node role and kind provides finer categorization such as regular contract, interface, or library. The resulting syntax representation is

$O_{cfg} = (GP, NF, CN),$2

(Peng et al., 2 Aug 2025).

The comment branch is intended to capture weak semantic priors about intended functionality. The comment extractor is described as combining CNNs with self-attention: convolution captures local phrase-level patterns, while self-attention models long-range word relationships and assigns different weights to important comment words. The manuscript states that the comment extraction process is “the same as detailed in Section \ref{sec:bert embedding},” implying that the BERT-based contextualization rationale also applies here. The output is clearly meant to be

$O_{cfg} = (GP, NF, CN),$3

although the paper contains a typographical error and labels it once as $O_{cfg} = (GP, NF, CN),$4.

The modality ablation later makes the relative roles of these signals explicit. CFG is the strongest single source because the targeted vulnerabilities are behavior-driven; AST complements CFG by adding syntax and source-level structure; comments alone are weak, but still provide incremental value when fused with the other modalities. This suggests that the comment modality is not intended as a primary detector but as a regularizing semantic cue.

5. Fusion, training, clone retrieval, and datasets

The three modality vectors are fused by vertical stacking into a comprehensive feature representation matrix for each contract, conceptually

$O_{cfg} = (GP, NF, CN),$5

This fused representation is stored in a contract feature database, also called the database for code inspection. The same representation supports both downstream tasks: vulnerability verification and contract-level clone detection (Peng et al., 2 Aug 2025).

For vulnerability detection, the experimental section describes a classifier that concatenates the modality features, feeds them through a fully connected layer with ReLU activation, and then uses a sigmoid output layer to produce a vulnerability probability. The training objective is binary cross-entropy loss. Optimization uses Adam with learning rate $O_{cfg} = (GP, NF, CN),$6 in the multimodal classifier stage, dropout with probability $O_{cfg} = (GP, NF, CN),$7, and training for $O_{cfg} = (GP, NF, CN),$8 epochs, saving the checkpoint with the lowest loss for evaluation. A contract is declared vulnerable when the predicted probability exceeds $O_{cfg} = (GP, NF, CN),$9.

For clone detection, the mechanism is similarity-based rather than classification-based. Every contract’s fused representation is stored in the database, and query–database similarity is computed by multiplying RBF-kernel similarity by cosine similarity. The appendix explains the rationale: RBF captures nonlinear relationships and is robust to noise and small variations, while cosine similarity is appropriate for high-dimensional sparse vectors. The experiments report thresholds $GP$0 and $GP$1; pairs above the chosen threshold are considered similar and returned with names and contents. The paper explicitly acknowledges that this is coarse-grained contract-level clone detection.

The datasets are assembled from four sources: SmartBugs Curated with 143 annotated contracts and 208 vulnerabilities; SolidiFI-Benchmark with 350 contracts and 9,369 injected vulnerabilities over seven types; MessiQ-Dataset with 12,000 vulnerable smart contracts; and 2,742 clean contracts from SmartBugs Wild / MANDO, drawn from a larger corpus of 47,398 contracts. The data are split 80/20 for vulnerability and clone-detection experiments. Because the vulnerability data are imbalanced, the training set is balanced using SMOTE and data augmentation.

Implementation details are only partially specified. GRU-GCN and com-extractor are implemented in PyTorch. GRU-GCN uses hidden size 512 and consists of a convolutional layer, two dropout layers, three GRU layers, a fully connected layer, and a regression layer, with Adam and learning rate $GP$2. The com-extractor also has hidden size 512 and consists of four convolutional layers. The manuscript appears to distinguish feature-extractor training at $GP$3 from multimodal classifier training at $GP$4.

6. Empirical results, interpretation, and limitations

The ablation study centers on reentrancy. For learning-rate sensitivity, the best reported performance occurs at learning rate $GP$5, with ACC 99.13, RE 98.25, PRE 98.65, and F1 98.45; the ROC curve on this task has AUC 0.9947 (Peng et al., 2 Aug 2025). The modality ablation is more revealing: comments only yield ACC 52.04, RE 36.12, PRE 75.00, F1 48.75; AST only yields ACC 62.33, RE 50.68, PRE 89.38, F1 64.68; CFG only yields ACC 85.74, RE 92.49, PRE 91.77, F1 92.13. Dual-modal combinations improve sharply, and the full multimodal model reaches ACC 99.13, RE 98.25, PRE 98.65, and F1 98.45. The paper interprets this as evidence that structural, syntactic, and semantic-comment cues are complementary.

Against baselines, MultiCFV is compared with Mythril, Slither, and “Slither + Mythril” on reentrancy, access control, external call, and delegatecall. For reentrancy, MultiCFV reports ACC 99.13, RE 98.25, PRE 98.65, and F1 99.12; for access control, ACC 82.89, RE 92.39, PRE 89.77, F1 91.06; for external call, ACC 89.01, RE 98.17, PRE 90.16, F1 93.99; for delegatecall, ACC 80.71, RE 90.06, PRE 81.61, F1 85.63. The tables also note that Slither failed on 66 contracts and Mythril failed on even more, mainly due to Solidity compiler-version limitations. One reported inconsistency should be noted: the reentrancy F1 value in the baseline-comparison table is 99.12, whereas the learning-rate and ablation tables report 98.45 for the same metric configuration.

Generalization is assessed on an unseen vulnerability family, Unprotected Ether Withdrawal, where the method achieves accuracy 82.86%, precision 92.07%, recall 83.34%, and F1 87.49%. For clone detection, MultiCFV is compared with SmartEmbed. Average detection times over five runs are 368.6572 s versus 403.7637 s at threshold 0.95, and 356.8932 s versus 396.9978 s at threshold 1.0, favoring MultiCFV. The paper also claims that SmartEmbed failed to detect clone codes in 26% of contracts, whereas MultiCFV failed in only 17%.

The framework’s strengths are the integration of behavioral, syntactic, and semantic-comment signals into one representation, the dual-purpose design spanning vulnerability detection and clone detection, and encouraging generalization evidence on a new vulnerability class. Its limitations are equally explicit. The AST encoder remains underdescribed; notation and dimensional consistency are uneven; clone detection is only coarse-grained at the contract level; comments may be sparse, absent, or misleading in practice; the vulnerability threshold of $GP$6 likely favors precision; and the evaluation is centered on a fixed family of benchmarks rather than fully unconstrained wild contracts. The stated future direction is finer-grained clone detection, moving beyond whole-contract similarity toward more precise cloned regions or code-reuse patterns.