💻 computer science

Identifying and Characterizing Semantic Clones of Solidity Functions

This paper presents a scalable methodology for identifying semantic clones in Solidity smart contracts by analyzing code and comments, achieving high precision and recall while exploring structural design alternatives and leveraging Large Language Models to bridge documentation gaps in uncommented code.

Original authors: Ermanno Francesco Sannini, Francesco Salzano, Simone Scalabrino, Rocco Oliveto, Remo Pareschi, Corrado Aaron Visaggio, Andrea Di Sorbo

Published 2026-04-30

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Ermanno Francesco Sannini, Francesco Salzano, Simone Scalabrino, Rocco Oliveto, Remo Pareschi, Corrado Aaron Visaggio, Andrea Di Sorbo

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of Smart Contracts (the digital agreements that run on blockchains like Ethereum) as a massive, public library. Once a book (a contract) is written and put on the shelf, it can never be erased or changed. Because the books are public, writers often copy-paste sections from other books to save time. This is called "cloning."

Most of the time, copying is easy to spot. If you copy a paragraph word-for-word, it's obvious. But what if someone rewrites a paragraph using completely different words, changes the sentence structure, and swaps out a few synonyms, but the meaning stays exactly the same? In the world of coding, this is called a Semantic Clone (or a Type-4 clone).

This paper is about building a better "librarian" to find these hidden, reworded copies in Solidity (the language used to write these contracts), because copying bad logic can spread security holes just as easily as copying good logic.

Here is a breakdown of their work using simple analogies:

1. The Problem: The "Rewritten Recipe" Trap

Imagine two chefs writing recipes for "Chocolate Cake."

Chef A writes: "Mix flour, sugar, and eggs. Bake at 350°F."
Chef B writes: "Combine dry ingredients with wet ones. Place in oven at 175°C."

To a computer looking for exact matches, these look totally different. But to a human, they are the same recipe. In the blockchain world, if Chef A's recipe has a hidden flaw (like forgetting to check if the oven is hot), and Chef B copies the idea without noticing the flaw, the whole kitchen is in danger.

The authors found that existing tools are like robots that only look for exact word matches. They miss these "rewritten recipes."

2. The Solution: Reading the "Chef's Notes"

The researchers realized that while the code (the ingredients and steps) might look different, the comments (the notes the chef wrote above the recipe) often explain the intent in very similar ways.

The Analogy: Think of the code as the actions and the comments as the voiceover explaining what the actions are doing.
The Method: They built a system that compares two things:
1. The Code: They check if the code is different (low similarity).
2. The Comments: They check if the written descriptions are very similar (high similarity).

If the code looks different but the voiceover sounds the same, they flag it as a "Semantic Clone."

3. The Results: A Highly Accurate Detective

They tested this method on a massive dataset of nearly 300,000 modern smart contracts.

The Success Rate: When they manually checked a sample of 1,155 pairs, their method was right 59% of the time overall.
The "Same Name" Bonus: If the functions had the same name (like both being called transfer), the accuracy jumped to 84%.
The Safety Net: They also checked to see if they missed any. They found they only missed about 3% of the real clones (a 97% "recall" rate).

They discovered that these "rewritten recipes" aren't just accidents; they are often design choices. Developers rewrite them to make the code more secure, to save "gas" (the fee paid to run the contract), or to organize the code better.

4. The Challenge: The "Silent" Library

A major problem they found is that 75% of these functions have no comments at all. It's like having a library where three-quarters of the books have no titles or summaries. Without comments, their "voiceover" method can't work.

5. The Fix: The "AI Scribe" (LLMs)

To solve the "silent library" problem, they used Large Language Models (AI) to act as a scribe.

The Analogy: If a book has no summary, they asked the AI to read the code and write a summary for it.
The Experiment: They fed the AI the code, asked it to write a description, and then used their system to compare the AI-written descriptions.
The Result: Even without human-written notes, the AI-generated summaries allowed them to find 75% of the hidden clones correctly.

They also tested different "prompts" (instructions to the AI). They found that asking the AI for a simple, direct summary worked better than asking for a complex, structured report. The complex reports added too much "fluff" that confused the system, while simple summaries kept the focus on the core meaning.

6. Why This Matters

The authors conclude that this isn't just about finding duplicates; it's about finding alternatives.

If you are a developer building a secure contract, you don't just want one way to do something. You want to see all the different ways other people have solved the same problem.
By finding these semantic clones, developers can compare different "rewritten recipes" to see which one is safer, cheaper, or more efficient before they build their own.

In short: The paper presents a new way to find "hidden twins" in code by comparing the intent (comments) rather than just the syntax (code). When comments are missing, they use AI to write them, successfully uncovering hidden design alternatives that could help make blockchain contracts safer and more efficient.

1. Problem Statement

Smart contracts (SCs) on blockchains like Ethereum are immutable and public, leading to high rates of code reuse. While syntactic code clones (Type-1 to Type-3) are well-studied, Type-4 clones (semantic clones)—functions that perform the same logical task but differ significantly in syntax and structure—remain a major challenge.

The Risk: Indiscriminate cloning of semantic clones can propagate hidden vulnerabilities (e.g., reentrancy, missing return value checks) across the ecosystem.
The Gap: Existing tools (like EClone) suffer from low precision, high overhead, and incompatibility with modern Solidity versions (0.8+). Furthermore, there is a lack of up-to-date, curated datasets for evaluating these techniques.
The Documentation Challenge: Approximately 75.57% of Solidity functions lack developer-written comments, making semantic analysis via natural language difficult.

2. Methodology

The authors propose a scalable, lightweight methodology that combines code analysis with natural language processing (NLP) of comments to detect Type-4 clones.

A. Dataset Construction

Source: Retrieved from the Ethereum blockchain via Google BigQuery and Etherscan.
Scale: ~300,000 active smart contracts (82.07% compliant with Solidity 0.8+).
Filtering: Extracted 2.7 million functions, filtering for public/external visibility and removing functions with trivial or missing comments.
Final Dataset: 216,429 high-quality function pairs with both code and meaningful comments.

B. Detection Strategy

The core hypothesis is that functions with low code similarity but high comment similarity are likely semantic clones.

Embedding Generation:
- Code: Used SmartEmbed (AST + FastText) to generate vector representations of the source code.
- Comments: Used SBERT (all-MiniLM-L6-v2) to generate semantic embeddings of developer comments.
Similarity Calculation:
- Calculated normalized Euclidean distance for code and cosine similarity for comments.
- Candidate Selection: Selected pairs where Code Similarity ( $cd\_s$ ) $\le 0.8$ AND Comment Similarity ( $cm\_s$ ) $> 0.8$ .
Validation:
- Conducted a manual validation on a statistically significant sample of 1,155 function pairs (stratified across baseline, candidate, and supplementary sets).
- Two domain experts (Ph.D. students with 5+ years of experience) independently labeled pairs, achieving a Cohen's Kappa of 0.83.

C. Addressing the Documentation Gap (RQ3)

For the 75% of functions without comments, the authors integrated Large Language Models (LLMs):

Strategy: Used ChatGPT-4o to generate summaries for uncommented functions.
Prompt Engineering: Compared a "Base Prompt" (direct summary) against a "Structured Template" (requiring specific sections like parameters and return values).
Evaluation: Tested if LLM-generated summaries could substitute real comments when combined with embedding models (SBERT, BERT-base, CodeBERT-base).

3. Key Contributions

Novel Methodology: A scalable approach for detecting Type-4 clones in Solidity by leveraging the correlation between code dissimilarity and comment similarity.
Modern Dataset: Creation of a curated dataset of ~300,000 active Ethereum contracts, predominantly using Solidity 0.8, addressing the lack of up-to-date resources in the field.
LLM Integration: A demonstration of using LLMs as "documentation engines" to bridge the gap in poorly documented code, enabling semantic clone detection in uncommented functions.
Characterization of Clones: A qualitative analysis revealing that semantic clones often represent design alternatives focused on security, modularity, and gas optimization rather than simple redundancy.

4. Key Results

Performance Metrics (RQ1)

Precision: 59% overall for the candidate set.
- 84% precision when focusing on homonymous functions (functions with the same name).
Recall: 97% (indicating the method misses very few true semantic clones).
F1-Score: 74%.
Baseline Comparison: A baseline approach using only code similarity (ignoring comments) yielded a validation rate of <1%, proving the critical value of comment analysis.

Characterization of Clones (RQ2)

Manual analysis of validated clones revealed common structural patterns:

call_internal (22%): Decomposition of logic into internal helper functions for modularity.
diff_algo (16%): Different algorithms achieving the same result (e.g., different order of operations in transferFrom).
add_check (10%): Addition of validation logic (e.g., extra require statements) without changing core state.
safemath & modifier: Variations in arithmetic protection and access control.
Insight: Semantic clones are often intentional design choices to improve security or gas efficiency, not just accidental duplicates.

LLM Effectiveness (RQ3)

Direct Classification: LLMs failed as direct clone detectors (11% precision).
Summarization Approach: Using LLMs to generate comments, then applying SBERT:
- BERT-base achieved 85% True Positives on LLM-generated comments.
- Uncommented Functions: Applied to 153 pairs of homonymous, uncommented functions; 75% were confirmed as semantic clones using LLM-generated summaries.
- Prompt Engineering: "Base Prompts" outperformed "Structured Templates." Structured templates caused similarity saturation (too much boilerplate text), reducing detection accuracy.

5. Significance and Implications

Security & Risk Mitigation: The methodology allows developers to identify functionally equivalent implementations. If one implementation is found to be vulnerable, developers can search for and audit all semantic clones to prevent ecosystem-wide exploits.
Design Alternatives: It provides a "catalog" of design patterns, helping developers choose implementations that offer better gas optimization or security (e.g., choosing a version with explicit require checks over one without).
Benchmarking: Establishes a new, modern benchmark for Solidity clone detection, moving beyond outdated tools like EClone which rely on deprecated bytecode analysis.
Documentation Gap: Demonstrates that LLMs can effectively act as a proxy for missing documentation, making semantic analysis feasible even in legacy or poorly documented codebases.

Conclusion

The paper successfully validates that combining code embeddings with natural language analysis (both human-written and LLM-generated) is a highly effective strategy for detecting semantic clones in Solidity. While not a perfect solution, it provides a robust foundation for automated discovery of secure and efficient code alternatives in the blockchain ecosystem.