This paper proposes a decentralized software version control system leveraging blockchain technology. Traditional version control systems suffer from central points of failure, lack of transparency, and limited traceability. This system addresses these shortcomings by utilizing a blockchain to immutably record and manage software version information. The core mechanism involves hashing software versions and storing these hashes on a blockchain, ensuring data integrity and providing a transparent, auditable trail. This approach enhances security, improves transparency, and offers enhanced traceability compared to centralized solutions. The system utilizes a distributed consensus mechanism to maintain blockchain integrity, mitigating the risks associated with a single point of failure. This research explores the feasibility and potential benefits of applying blockchain technology to software version control, representing a novel approach to managing software evolution.
This paper proposes a novel system for program code version control leveraging the principles of blockchain technology. Traditional version control systems are vulnerable to manipulation and security breaches, necessitating a more robust and transparent solution. Our system utilizes blockchain's inherent properties – immutability and distributed consensus – to provide a highly secure and auditable record of code changes. The core mechanism involves hashing each code version and storing the hash on a blockchain, ensuring that any alteration to the code will be immediately detectable. This approach significantly enhances the integrity of the codebase and promotes trust among developers and stakeholders. The system is designed for flexibility and scalability, adaptable to various programming languages and development workflows. This paper outlines the architecture, key features, and theoretical underpinnings of the proposed system, emphasizing its advantages over existing methods.
Abstract Mutation testing is widely used to assess the adequacy of test suite; however, its practical adoption is constrained by the persistent problem of equivalent mutants, i.e., mutants whose observable behavior is indistinguishable from the original program and therefore cannot be killed by any test case. Prior studies report that identifying equivalent mutants often requires substantial manual effort. Meanwhile, fuzzing is increasingly used in real-world systems, especially security-critical software. However, conventional fuzzing oracles typically detect only crash-like failures, thereby missing many behavioral changes introduced by mutants. In this paper, we investigate differential fuzzing as a practical, language-agnostic approach to support mutant classification, focusing on identifying (and confirming) equivalent mutants. We conduct a multi-project study across Bitcoin Core (C++), OpenSSL (C), LND (Go), and Arrow (Python), mutating six real functions with 1,090 valid mutants generated by the universalmutator. We compare unit/functional testing, seed-corpus-only fuzzing, time-bounded fuzzing, and two differential fuzzing configurations (seed-corpus-only and time-bounded). Our results show that conventional fuzzing yields the lowest mutation scores, while time-bounded differential fuzzing (5 minutes per mutant) achieves 98–100\% mutation score in five of six targets, and exposes cases where seed corpora contain valuable test inputs not covered by unit/functional suites. We further analyze runtime variability and observe log-normal behavior in difficult cases, providing practical guidance on stopping criteria (time/execution budgets), as well as evidence that dictionaries and parallel fuzzing can significantly improve effectiveness. Overall, our findings indicate that differential fuzzing is simple to implement and can classify mutants efficiently in practice, while also producing actionable artifacts (seed corpus inputs) to strengthen traditional test suites.
With the increasing development of Solidity contracts on Ethereum , more developers are reusing them on other compatible blockchains. However, developers may overlook the differences between the designs of the blockchain system, such as the Gas Mechanism and Consensus Protocol , leading to the same contracts on different blockchains not being able to achieve consistent execution as on Ethereum . This inconsistency reveals design flaws in reused contracts, exposing code smells that hinder code reusability, and we define this inconsistency as EVM-Inequivalent Code Smells . In this paper, we conducted an empirical study to reveal the causes and characteristics of EVM-Inequivalent Code Smells . To ensure the identified smells reflect real developer concerns, we analyzed 1,379 security audit reports, 823 bug bounty reports, and 326 Stack Overflow posts related to reused contracts on EVM-compatible blockchains, such as Binance Smart Chain (BSC) and Polygon . Using the Open Card Sorting method, we defined nine types of EVM-Inequivalent Code Smells . To enable efficient detection, we developed EquivSage , a tool that leverages the contextual understanding capabilities of large language models (LLMs) to guide slicing and static taint analysis via task-specific prompts. Symbolic execution is integrated to improve detection reliability. An analysis of 1,263,683 contracts across six EVM-compatible blockchains using EquivSage reveals that, on average, 15.45% contain at least one EVM-Inequivalent Code Smell , underscoring its widespread prevalence. Since 2024, code smells in reused contracts on Ethereum , Polygon , and Optimism have increased significantly. While not all instances lead to financial loss, high frequency and asset exposure highlight the risks inherent in contract reuse. Developers are encouraged to avoid copy-and-paste practices and to detect such smells proactively before reuse.
Abstract Software requirement documents—natural-language specifications that define a system’s entities, rules, processes, and interfaces—remain the core knowledge artifact in enterprise software development. Yet they remain inaccessible to automated tooling: downstream tasks like test generation, code scaffolding, compliance checking, and AI-assisted development cannot directly process unstructured prose. We present DKSE (Domain Knowledge Structuring Engine), a tool that automatically converts requirement documents into machine-readable structured ontologies organized around six core asset types: entities, relations, rules, processes, APIs, and dictionaries. DKSE uses an LLM-guided extraction pipeline that accepts multi-format inputs (DOCX, PDF, HTML), outputs YAML-encoded ontologies with full provenance tracing back to source sections, and includes built-in quality assurance tooling for validation, version diffing, and probe generation. In a case study across four banking sub-domains, we ran DKSE on six requirement documents totaling roughly 800,000 Chinese characters. It extracted 3,439 structured assets: 215 entities, 1,227 rules, 739 relations, 182 processes, 482 dictionaries, and 594 APIs. Expert review confirmed full functional-module coverage, with 96% of a stratified sample rated fully accurate and zero hallucinated assets. We validate DKSE’s practical value through three downstream use cases: automated benchmark generation (1,214 machine-graded probes), domain-specific LLM training corpus construction, and knowledge graph ingestion for retrieval-augmented generation. DKSE is built in Rust (~8,000 lines of code) and shipped as a CLI tool with an accompanying web interface. We position this work as a proof-of-concept within a single industry (Chinese banking), not a general-purpose validation. Quantitative evaluation across additional domains, languages, and against baseline extraction methods is left for future work.