Application of Blockchain Technologies in Verification of Software Metrics

Abstract

When creating software, it is important to focus not only on the functionality requested by users but also on ensuring that the software exhibits qualities such as maintainability, testability, comprehensibility, and reusability. To achieve this, developers should consider these qualities from the early stages of development and implementation. In this paper, we propose a novel methodology for the calculation of software metrics to evaluate the aforementioned quality characteristics, as well as their verification on the blockchain. The primary objective is to provide a simple and transparent approach—using smart contracts—for monitoring software metrics throughout the development process. This approach enhances software reliability and facilitates ongoing maintenance.

1. Introduction

Software metrics represent a fundamental approach to the evaluation of software quality and complexity. The term “metrics” refers to a quantitative measure that provides insight into specific characteristics of a system or process. The development and application of metrics are closely related to the need for a more objective assessment of software in all phases of its lifecycle—from planning and design, through implementation and testing, to maintenance. Reliable metrics should provide insight into software quality. However, contemporary trends in software development have significantly altered the perception and approach to the use of software metrics. Traditional metrics, primarily oriented toward quality assessment within clearly defined development phases, often failed to adequately support emerging, more dynamic software development practices. Consequently, industry practice has begun recognizing the need to redefine existing metrics and introduce new ones better aligned with the requirements of modern methodologies such as Agile and DevOps [1].

With the emergence of Agile and DevOps practices, crucial changes have occurred in the understanding and application of metrics. The focus shifted toward rapid delivery, continuous improvement, and close team collaboration, leading to a demand for metrics that can be collected and analyzed in real time [2].

However, although metrics have advanced to more sophisticated forms that offer deeper insights into software quality, they have become susceptible to manipulation [3]. Team members responsible for software quality assessment may intentionally “tweak” metrics to meet predefined goals. Such actions can lead to compromised trust and poor managerial decisions [4].

Keeping in mind all that was previously mentioned, we came up with the idea to develop a methodology for the calculation of software metrics that will be verified through blockchain smart contracts, ensuring immutability and data integrity. Our approach assesses software developed using scripting languages by applying metrics whose relevance for this type of analysis was evaluated and verified.

The rest of the paper is organized as follows. Section 2 discusses related work regarding the verification of software metrics and their usage in the evaluation of software. In Section 3, we present the methodology, which includes blockchain technology and the metrics to be verified, smart contracts, data collection, and system architecture. To test the developed methodology in a real-world case scenario, Section 4 presents a use case study. The paper concludes with Section 5, which provides a summary and outlines future research directions in this area.

2. Related Work

In order to evaluate whether software includes characteristics such as maintainability, testability, comprehensibility, and reusability, software metrics play a key role. Different software metrics evaluate different characteristics, thereby resulting in the necessity for their classification. Singh et al. [5] classify metrics into process metrics (related to the properties of the software development process) and product metrics (related directly to software characteristics). Some of the main challenges in verifying these metrics stem from their reliance on estimates and interpretations, which may vary among developers, as well as on subjective assessments and unauthorized database modifications [6]. Srinivasan and Devi [7] highlight two distinct forms of validation for software metrics: theoretical and empirical. Theoretical validation ensures that measurements do not violate the essential properties of the measured elements, whereas empirical validation confirms the practical consistency of the measured data. Moreover, Tao et al. [8] emphasize that theoretical validation confirms a metric’s conceptual integrity, while empirical validation provides evidence of its practical usefulness.

Furthermore, Verma et al. [9] propose solutions based on blockchain technology, emphasizing the Proof-of-Work and Proof-of-Stake consensus mechanisms. One significant challenge addressed in their paper is the Byzantine Generals Problem, symbolizing the need for consensus and trust in distributed systems. Blockchain technology effectively resolves this challenge by using consensus mechanisms that ensure data integrity and prevent manipulation [10].

The development of software solutions that integrate blockchain technology opens up space for the development of verifiable and autonomous systems in various fields of application. With increasing demands for transparency and non-repudiation in software systems, blockchain technology is increasingly integrated in various domain-specific applications [11].

In the field of justice, blockchain is integrated into digital evidence management software and e-court cases [12]. By integrating blockchain technology with modern software solutions in the judiciary, immutable records of each process step are achieved, thereby ensuring the reliability of digital documentation [12].

Similar to the judiciary, blockchain is also used in financial and accounting software, where it is used for the realization of self-verifying transactions and for the automation of audit processes [13]. This integration reduces the need for manual intervention and increases compliance with regulatory requirements [13].

Kanellopoulos et al. [14] propose a methodology for evaluating source code quality and the static behavior of a software system based on the ISO/IEC 9126 standard [14]. The proposed methodology combines automatically generated source code characteristics with expert knowledge, enabling software engineers to assign weight coefficients to different code attributes. However, this work does not define the validation of metric results, which may lead to potential issues. Similar to Kanellopoulos et al. [14], Atanasijevic [15] focuses on various aspects of software quality and testing but does not address the verification of software metric values.

As previously mentioned, software metrics have been predominantly developed and validated for compiled, statically typed languages due to their structured nature, well-defined syntax, and wide use in industrial applications. In contrast, scripting languages, characterized by dynamic typing, runtime interpretation, and greater flexibility, present significant challenges for the precise definition, measurement, and verification of software metrics. According to recent studies, dynamically typed languages such as JavaScript and Python introduce complexities in software analysis due to their flexible code structures, runtime polymorphism, and dynamic behaviors, often making traditional metrics inadequate or difficult to apply [16]. Consequently, earlier research efforts prioritized languages with stricter syntactical and structural constraints, resulting in a notable gap regarding metric definitions specifically designed for scripting languages [17].

As the reviewed literature shows, there is no study that addresses the issue of ensuring objectivity and integrity in the verification of metrics, especially for scripting languages. Additionally, there is no technical solution capable of resolving this type of problem. Keeping this in mind, we were motivated to conduct the research presented in this paper, aiming to ensure transparency and reliability through the application of blockchain technology and smart contracts in the verification of software metrics for script-based languages.

3. Methodology

In this section, we propose a methodology that enables the automatic calculation, verification, and immutable recording of software metric values using smart contracts on the Ethereum blockchain platform, ensuring a high level of data integrity throughout the evaluation process. This methodology addresses concerns related to subjectivity and unauthorized modification of the results. Additionally, it incorporates the calculation of relevant metrics and their validation on the blockchain through the design and implementation of appropriate smart contracts, as well as the establishment of the underlying system architecture for software used in practical evaluation. This practical evaluation was performed by web application, which enables automatic calculation and verification of software metrics. The methodology is illustrated in Figure 1, and it consists of five key steps. Detailed explanations of each step are provided in the subsequent Section 3.1, Section 3.2, Section 3.3, Section 3.4, Section 3.5 and Section 3.6.

Figure 1 provides an overview of the methodology, which is structured into five key steps. Each step is explained in detail in Section 3.1, Section 3.2, Section 3.3, Section 3.4, Section 3.5 and Section 3.6.

3.1. Software Metric Selection

Software metrics serve as fundamental indicators of software quality. They come in various forms, such as size metrics, object-oriented metrics, service-oriented metrics, and metrics specific to component-based software engineering [18]. This paper focuses on object-oriented metrics, as they offer valuable insights into software quality by facilitating the evaluation of crucial attributes like modularity, maintainability, and extensibility.

The metrics listed in

Table 1. Recommended metric values.

Metric Name	Recommended Values
Lines of Code	/
Number of Children	3–5
Depth of Inheritance Tree	<5
Total Methods Per Class	5–15
Inheritance Coupling	0–2
Cyclomatic Complexity (class)	<50
Cyclomatic Complexity (Method)	1–10
LCOM1	0
LCOM2	0–1
LCOM3	0–2
LCOM4	1
LCOM5	0–1
MIF	0.8
AIF	0.8
Coupling Factor	0.1
Response For Class	100

were not chosen at random; they are the result of an analysis identifying the most relevant indicators for assessing modularity, maintainability, and extensibility in object-oriented code [19,20,21]. In languages like Python, these metrics have shown to be highly effective in the early identification of anomalies—such as deep inheritance hierarchies or tightly coupled classes—that, if left unresolved, may cause significant problems in later stages of system development [22,23]. Python’s flexibility and dynamic typing, while conducive to rapid prototyping and streamlined development, simultaneously heighten the risk of anomalies [24].

Moreover, the selected software metrics provide a valuable identification of the previously mentioned indicators for software written in Python v3.13. Metrics such as Lines of Code (LOC), Cyclomatic Complexity (at both method and class levels), and Total Methods per Class offer insights into code size and structural complexity, which are key indicators of maintainability and potential defect-proneness. Meanwhile, inheritance-related metrics—including Depth of Inheritance Tree (DIT), Number of Children (NOC), Method Inheritance Factor (MIF), and Attribute Inheritance Factor (AIF)—help assess the extent and clarity of class hierarchies, which is particularly relevant in Python, where multiple inheritance and dynamic behaviors can obscure control flow and method resolution.

Coupling and cohesion metrics such as Coupling Factor (CF), Inheritance Coupling, and Lack of Cohesion of Methods (LCOM1–LCOM5) are critical in identifying tightly bound or poorly structured classes that can hinder reuse, testing, and modular design. In dynamically typed languages like Python, these metrics are especially valuable for detecting architectural issues that may not be immediately evident through static analysis alone. Lastly, Response for Class (RFC) measures the breadth of behavior encapsulated by a class and serves as a proxy for interface complexity—helpful in evaluating how predictable and manageable a class is during runtime. Collectively, these metrics enable an effective, quantifiable analysis of code quality, extensibility, and maintainability in Python systems.

As can be observed, the “Lines of Code” metric does not include a recommended value because the method of counting LOC can vary depending on factors such as the programming language, coding practices, and counting standards. Only after selecting the appropriate standards and tools can a programmer accurately count the lines of code in a program, thereby making the metric relevant. Recommended values for other selected metrics are chosen based on literature analysis and are given at the beginning of this section.

3.2. Verification on Blockchain

In order to achieve immutability and data integrity, simply calculating these metrics is insufficient, since this leaves room for manipulation. To address this issue, we utilize blockchain technology. It provides an immutable and transparent ledger (Figure 2), ensuring that the results of software metric calculations are tamper-proof and auditable [25]. By leveraging blockchain, the integrity of the metrics is achieved, preventing unauthorized modifications and enhancing trust in the accuracy of the data. Additionally, blockchain’s decentralized nature enables secure and distributed verification of software metrics, offering a reliable mechanism for validating the quality of code across different stakeholders without relying on a centralized authority [26]. This approach not only improves transparency but also fosters accountability and traceability, which can serve as a basis for assessing long-term software quality.

3.2.1. Blockchain Model Selection

Numerous blockchain networks have been developed in the realm of blockchain technology. Bitcoin was one of the first blockchain platforms, primarily serving as a decentralized payment system with limited programmability [27]. In contrast, Hyperledger Fabric is a permissioned blockchain designed for enterprise applications, emphasizing modularity and private transactions, though it lacks the decentralized openness characteristic of public blockchains [28,29]. Another well-known blockchain is Cardano, which introduces a layered architecture and an alternative consensus mechanism, though it is still in the process of fully implementing smart contract functionality [30].

Ethereum is one of the most well-known and widely used blockchains on the market, supporting smart contracts and decentralized applications (dApps). For the purposes of this research, the Ethereum blockchain was selected. Furthermore, the capabilities of Ethereum smart contracts are utilized for verifying and storing software metric values on the blockchain, ensuring immutability, transparency, and decentralized validation of the computed results.

Each operation of executing smart contracts on the Ethereum network requires a certain number of gas units, which correspond to the computational resources needed to run instructions in the Ethereum Virtual Machine [31]. The price of one gas unit is expressed in Gwei (1 Gwei = ETH), while the total cost of a transaction is obtained by multiplying the gas used by the Gas price:

Total = Gas used × Gas price

The gas fee mechanism ensures that anyone executing code on the network pays for the computational resources they use, thereby fairly compensating resource providers and discouraging unnecessary or wasteful operations [32]. This mechanism is particularly important in the context of software metric verification, as frequent writes and data updates can significantly increase the total cost, especially during periods of network congestion.

3.2.2. Smart Contracts

Traditional verification approaches rely on centralized code analysis systems, where results are generated using tools such as SonarQube, PMD, Checkstyle, and similar static code analysis tools. These systems typically operate in three phases: (1) data collection from the code, (2) computation of software metrics, and (3) storage and verification of results in relational databases or local files. Although these mechanisms are widely adopted, the third phase reduces system reliability, as they depend on centralized databases, leaving the results susceptible to manipulation.

To address this limitation, this paper proposes the use of Ethereum smart contracts for the automatic verification and storage of software metric results. This approach offers several advantages:

• Transparency: In practice, the conditions defined within a smart contract are clearly accessible to all participants in the blockchain network [33]. Once a contract is deployed, modifying it is not easily feasible. Every transaction executed under the contract is tracked and verified by other nodes in the network, enhancing transparency and reducing the risk of fraud [33]. Moreover, fraudulent practices in software metric verification are becoming increasingly common, highlighting the need for more robust and reliable methods;
• Speed: Smart contracts operate independently of human intervention, with their execution monitored and validated by other nodes. Once the predefined conditions are met, the contract executes automatically [33]. This process is typically triggered by specific events, which activate the contract logic when certain criteria are fulfilled [33];
• Security: Leveraging advanced cryptographic methods and the intrinsic properties of blockchain, such as immutability, smart contracts provide a high level of security [33]. The contents of a smart contract cannot be retroactively modified by any party, and execution occurs autonomously and deterministically [33].

As part of this research, a smart contract was created to verify software metrics on the blockchain. The smart contract was created in Solidity version 0.8.0 programming language. This contract is designed to store and verify software testing results in one place. To achieve this, as shown in code below, the smart contract uses a MetricsTest structure that contains the unique number of the test, the name of the software, the time the test was run, and an array containing the numeric values of the metrics. All tests recorded by a user on the blockchain network can be found quickly and efficiently as the smart contract maps the address to its list of tests.

The main storeMetrics function records each new test. It first checks that the software name is not a null value and that the metric array is not empty, then it finds a free test number (if a unique test number value is used, +1 is added) and only then saves the data.

If the recording is successful, the MetricsStored event is broadcasted, which enables external services to immediately see that a new result has arrived.

To display the history of all tests of one user, the functions getMetrics, which returns all the data of one test, and getAllTestIds, which returns a list of all tests of the user, are used.

/ SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

/// @author J. Milutinović

contract SoftwareMetrics {

    struct MetricsTest {

        uint256 id;

        string softwareName;

        uint256 timestamp;

        uint256[] values;

    }

    Struct ZKPSubmission {

        address submitter;

        bytes32 fileID;

        bytes zkProof;

        bytes32 thresholdProfileID;

        uint256 timestamp;

        bool verified;

}

    mapping(address => mapping(uint256 => MetricsTest)) private userTests;

    mapping(address => uint256[]) private testIds;

    mapping(bytes32 => ZKPSubmission) public zkSubmissions;

    event submittedMetrics( . . . );

    event ZKPSubmitted( . . . );

    event ZKPVerified( . . . );

    function getNextTestId(...) internal view returns ( . . . ) { . . . }

    function submitMetrics( . . . ) public { . . . }

    function getMetrics( . . . ) public view returns ( . . . ) { . . . }

    function getAllTestIds( . . . ) public view returns ( . . . ) { . . . }

    function testExists( . . . ) internal view returns ( . . . ) { . . . }

    function submitZKP( . . . ) external { . . . }

    function markVerified( . . . ) external { . . . }

}

3.3. Data Collection for Verification

In order to accurately verify software metric values, it is essential to establish a precise and automated data collection process. This section outlines the methodological approach adopted in the developed software analysis system, which includes the following components:

• methodology for source code analysis and software metric extraction;
• process of data verification using smart contracts;
• approach for retrieving data from the blockchain for result validation.

The developed system utilizes an Abstract Syntax Tree (AST) to analyze Python code, parse program files, and automatically compute software metric values. Each metric has a predefined threshold, as presented in Table 1. If the computed values exceed acceptable limits, the system flags them as potential software design issues.

The verification of software metrics in a blockchain environment involves a smart contract mechanism that ensures a reliable, immutable, and transparent association between analysis results and the user who initiated the analysis. Instead of relying on traditional centralized authentication systems, the blockchain-based approach uses wallet addresses as unique user identifiers—thus achieving decentralized verification and autonomy while eliminating the need for intermediaries.

The data retrieval process in the developed system also functions without intermediaries, identifying users through their wallet addresses (Figure 3). This ensures that only the owner of the analysis results can access their metrics:

• The user logs into the system by connecting their digital wallet;
• The user navigates to the verification section;
• The system sends a query to the smart contract to retrieve the data;
• The smart contract accesses the relevant data structure on the blockchain and associates the stored metrics with the user’s wallet address;
• The results are returned to the user in JSON format, allowing for detailed review.

3.4. System Architecture

As shown in Figure 4, the architecture of the developed system comprises three components: frontend, backend, and blockchain. To access the system, the user must first connect their digital wallet to the tool. The digital wallet is essential, as all actions—such as initiating transactions and viewing verification history—are linked to the user’s wallet address.

The backend component does not include a centralized database, as this would compromise decentralization and introduce the risk of software metric manipulation. In this system, the backend is responsible solely for computing software metrics. To facilitate communication between the frontend and backend, a REST API is used to upload software files on which the metric computation is performed. Once calculated, the metrics are returned to the frontend and displayed to the user.

The third component is the blockchain, which includes a smart contract responsible for permanently storing the computed metric data. After receiving the calculated metrics, the user proceeds to the verification step. To ensure transparency, the user triggers the smart contract, which then executes a transaction. Each transaction submitted to the smart contract is verified by the distributed network of nodes, ensuring data integrity, transparency, and protection against manipulation.

3.5. Validation of the Metrics

Verification will show that our metrics can use smart contracts for monitoring software metrics throughout the development process. In order to fully utilize metrics, we need to validate them and prove that our metrics can actually be used to enhance software reliability.

To ensure the integrity and transparency of software metric evaluation, we introduce a formal model named the Blockchain-Based Metric Validation Scheme (BMVS) [34]. This scheme provides a structured approach to validate code quality metrics using the immutable properties of blockchain technology, specifically through smart contracts on the Ethereum network.

The BMVS can be represented as a 6-tuple:

BMVS = (Σ, M, C, V, B, R)

In this metric value, Σ is a set of source files σ_i written in scripting languages. M represents a set of metric functions for computing specific software metrics: LOC(σ) (Lines of Code), CC(σ) (Cyclomatic Complexity), LCOM(σ) (Lack of Cohesion), and DIT(σ) (Depth of the Inheritance Tree). The verification module, which calculates the cryptographic digest h = H(m(σ)) and interacts with the blockchain for secure validation, is denoted as V. The blockchain environment is represented by B, and R is the result interpretation function that maps the outcomes of the metrics.

Since this is a basic validation process, we aimed to innovate and develop a more robust system for validation. We will use zero-knowledge proofs to demonstrate that a metric lies within acceptable bounds without revealing the actual values. This will be achieved by delivering to the system a zero-knowledge proof whose cyclomatic complexity is lower than 10. This approach enables third-party validators to verify software without accessing the source code or exact metric values.

In order to implement this approach, we define a new Blockchain-Based Metric Validation Scheme (BMVS) with zero-knowledge proofs (ZKPs) as an internal and formal structural component [35].

BMVS = (Σ, M⁺, T⁺, P, V, B, R)

We now examine the modified and newly introduced elements of the validation process. A new element is the extended metric vector, M⁺, defined for each file σ. For every file, we introduce the following metric values: size and complexity, inheritance, coupling, and cohesion.

For size and complexity, we use the following metrics: Lines of Code (LOC), Cyclomatic Complexity at the method level (CCm), Cyclomatic Complexity at the class level (CCc), and Total Methods per Class (TMC).

Inheritance metrics are evaluated using the Depth of Inheritance Tree (DIT), Number of Children (NOC), Method Inheritance Factor (MIF), and Attribute Inheritance Factor (AIF).

Finally, we incorporate metrics for coupling and cohesion, including Coupling Factor (CF), Inheritance Coupling (IC), and Lack of Cohesion of Methods (LCOM_i), where i represents the variant index.

We then define threshold constraints, which are vectors of predefined limits for metric validity, denoted as

T⁺ = {LOC < Θ₁, CC_m ≤ Θ₂, …, LCOM₁ ≤ Θ_k}.

Each defined constraint is a Boolean formula τ_j: m_j(σ) • Θ_j, where • represents a comparison operator such as <, >, ≤, or ≥.

A zero-knowledge proof function provides a cryptographic attestation

P: = M + T⁺ → π,

where π is a non-interactive zero-knowledge proof that satisfies metric validity without revealing the actual metric values.

The blockchain-deployed verification function V outputs a Boolean value: true if π is valid for the declared threshold, and false otherwise.

The blockchain commitment layer, denoted as B, stores the proof of metric compliance, the SHA-256 hash of the source file, the decentralized submitter identity, a timestamp, and a reference to the constraint profile.

Finally, the decision function, denoted as R, maps the verification outcome to a qualitative result. It returns one of two values: valid submission or threshold violation detected.

In our case, we demonstrate the practical application of the enhanced Blockchain-Based Metric Validation Scheme (BMVS) using zero-knowledge proofs (ZKPs), applied to a real-world Python project: TextAdventure.

The goal is to validate whether a submitted source file satisfies predefined software quality thresholds while preserving privacy and ensuring tamper-proof verification via blockchain.

The procedure is presented in the following pseudocode.

function validate_source_file(file_path, threshold_profile):

    # Step 1: Extract metrics from source code

    metrics = extract_metrics(file_path)

    file_id = hash_file(file_path)

 

    # Step 2: Check local constraint satisfaction (optional pre-check)

    if not satisfies_thresholds(metrics, threshold_profile):

        print("Warning: Local validation failed. Proceeding with ZKP anyway.")

 

    # Step 3: Generate ZKP based on metric constraints

    zkp_proof = generate_zkp(metrics, threshold_profile)

 

    # Step 4: Prepare metadata

    submission = {

        fileID: file_id,

        proof: zkp_proof,

        thresholdSetID: hash_threshold_profile(threshold_profile),

        timestamp: current_timestamp(),

        submitterDID: get_submitter_did()

    }

 

    # Step 5: Submit to blockchain smart contract

    tx_hash = submit_to_contract(submission)

    return tx_hash

 

 

function extract_metrics(file_path):

    # OOM Metric Analyzer logic

    return {

        LOC: count_lines(file_path),

        CC_m: cyclomatic_complexity_method_level(file_path),

        CC_c: cyclomatic_complexity_class_level(file_path),

        TMC: count_methods_per_class(file_path),

        DIT: compute_dit(file_path),

        NOC: compute_noc(file_path),

        MIF: method_inheritance_factor(file_path),

        AIF: attribute_inheritance_factor(file_path),

        CF: compute_coupling(file_path),

        IC: inheritance_coupling(file_path),

        LCOM_1: cohesion_variant(file_path, 1),

        LCOM_2: cohesion_variant(file_path, 2),

        ...

    }

 

function satisfies_thresholds(metrics, thresholds):

    for key in thresholds:

        if not evaluate_constraint(metrics[key], thresholds[key]):

            return False

    return True

 

 

function generate_zkp(metrics, thresholds):

    # Use Circom, ZoKrates, or other ZKP toolchain

    # 1. Compile ZKP circuit with constraints

    # 2. Generate witness using metrics

    # 3. Create cryptographic proof

    return zk_snark_proof

 

 

function submit_to_contract(submission):

    # Submit transaction to Ethereum smart contract

    contract = load_contract()

    tx = contract.submitZKP(

        submission["fileID"],

        submission["proof"],

        submission["thresholdSetID"]

    )

    return tx.hash

 

function verify_on_chain(file_id, proof, threshold_profile):

    thresholdSetID = hash_threshold_profile(threshold_profile)

    return contract.verifyZKP(file_id, proof, thresholdSetID)

Here is a Solidity smart contract design for implementing the BMVS-ZKP* validation scheme. This contract allows the submission and verification of software metric compliance using zero-knowledge proofs (ZKPs) while supporting flexible threshold profiles, submission metadata, and on-chain auditability.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

 

/// @title BMVS-ZKP Validator Contract

/// @notice Stores and verifies ZKPs for software metric compliance

contract BMVSZKPValidator {

 

    struct Submission {

        address submitter;

        bytes32 fileID;

        bytes zkProof;

        bytes32 thresholdProfileID;

        uint256 timestamp;

        bool verified;

    }

 

    mapping(bytes32 => Submission) public submissions;

 

    event SubmissionReceived(

        bytes32 indexed fileID,

        address indexed submitter,

        bytes32 thresholdProfileID,

        uint256 timestamp

    );

 

    event VerificationResult(

        bytes32 indexed fileID,

        bool success,

        uint256 timestamp

    );

 

    /// @notice Submit ZKP proof for a source file and metric compliance

    function submitProof(

        bytes32 fileID,

        bytes calldata zkProof,

        bytes32 thresholdProfileID

    ) external {

        require(submissions[fileID].timestamp == 0, "File already submitted");

 

        submissions[fileID] = Submission({

            submitter: msg.sender,

            fileID: fileID,

            zkProof: zkProof,

            thresholdProfileID: thresholdProfileID,

            timestamp: block.timestamp,

            verified: false

        });

 

        emit SubmissionReceived(fileID, msg.sender, thresholdProfileID, block.timestamp);

    }

 

    /// @notice Verify ZKP off-chain result (simulated on-chain hook)

    function markVerified(bytes32 fileID, bool result) external {

        require(submissions[fileID].timestamp != 0, "No such file");

        require(!submissions[fileID].verified, "Already verified");

 

        // In a real implementation, this would call a verifier contract

        // For demo: instructor or validator confirms ZKP validity externally

        if (result) {

            submissions[fileID].verified = true;

        }

 

        emit VerificationResult(fileID, result, block.timestamp);

    }

 

    /// @notice Retrieve proof metadata (for audit)

    function getSubmission(bytes32 fileID)

        public

        view

        returns (

            address submitter,

            bytes memory zkProof,

            bytes32 thresholdProfileID,

            uint256 timestamp,

            bool verified

        )

    {

        Submission memory sub = submissions[fileID];

        return (

            sub.submitter,

            sub.zkProof,

            sub.thresholdProfileID,

            sub.timestamp,

            sub.verified

        );

    }

}

In this way, our validation process will utilize the full metric suite, detect threshold violations prior to submission, and integrate a zero-knowledge proof (ZKP) backend.

3.6. Technologies Used in Software Development

To ensure efficiency, scalability, and security, modern web and blockchain technologies were employed in developing the software metric analysis and verification system. For the user interface, the React library was utilized. React enables a component-based architecture that simplifies both the development and maintenance of the application [36]. One of the key advantages influencing the selection of React is its virtual DOM mechanism, which facilitates efficient rendering and reduces the computational overhead associated with interface re-rendering [37]. To enable efficient state management, Redux was implemented.

For backend development, Node.js was selected due to its support for asynchronous request handling and high-performance data processing. The use of Node.js ensures efficient API request routing and optimizes the interaction between frontend and backend components. In conjunction with Node.js, Python was employed to develop the component responsible for software metric computation. A major factor in selecting Python was its Abstract Syntax Tree (AST) library, which facilitates code parsing and significantly streamlines the software metric calculation process [38].

Finally, for the implementation of the blockchain components, including software metric verification, Solidity was utilized. Solidity is a smart contract programming language for the Ethereum blockchain that enables secure and immutable data storage. This ensures that the verification of results remains tamper-proof, preventing any possibility of manipulation.

4. Use Case Study: OOM Metric Analyzer

To address the issue of subjectivity and unauthorized manipulation of software metric results, the software solution OOM Metric Analyzer v1 was developed. This tool calculates the values of object-oriented metrics for applications written in the Python programming language and verifies them on the Ethereum blockchain. User access is granted only through a previously connected digital wallet, ensuring the security and correctness of the calculated results.

On the user login interface (Figure 5), a button is provided to connect the application to the digital wallet, along with a message informing users that no personal data will be stored in the application. OOM Metric Analyzer uses the MetaMask digital wallet, though other solutions are also supported.

Since verifications are conducted on the Ethereum blockchain, users must possess a certain amount of Ethereum cryptocurrency in their wallets to execute transactions. The transaction cost depends on the gas fee and the complexity of the data-writing operation.

After the user connects their digital wallet, the software metric analysis and verification interface is displayed (Figure 6). Here, the user is provided with the following features:

• Choose Files: Select the software files to be analyzed.
• Analyze: Compute software metrics for the selected software.
• Reset: Clear the calculated metrics and reset the analysis.
• Verify: Verify the computed metrics by submitting them to the blockchain.

In the first step of software metric analysis and verification, the user uploads the software to be analyzed. After the selection is made, a pop-up window appears (Figure 7), prompting the user to enter the name of the software.

The next step in the analysis is initiated by clicking the “Analyze” button. As a result, the calculated metric values are displayed beneath the uploaded files (Figure 8). Metrics within the recommended range are highlighted in green. Metrics with values outside the recommended limits are marked with pulsating red circles to indicate potential issues.

To provide users with insight into which parts of the software may contain potential issues, the system offers the option to view detailed information about specific classes or methods by clicking the ‘i’ button (Figure 9). Upon clicking this button, a table is displayed showing the following: the relevant classes or methods (depending on the specific metric), the recommended value range, and the exceedance value—highlighting where the metric exceeds the defined limits.

Upon obtaining the metric values, the user can verify them on the blockchain. This function is executed by clicking the “Verify” button, which then opens a pop-up window displaying the transaction details (Figure 10).

To verify the results on the blockchain, the user must confirm the transaction. The user can view the history of all transactions and analyses by clicking the ‘History’ button in the side menu.

For each verification (Figure 11), the following details are displayed: the project name, the verification date, a button to view all metrics associated with the verification, and the transaction hash value, which can be clicked to redirect the user to the Ethereum network, where the transaction can be independently verified.

The following

Table 2. Validation results.

Metric Name	Current Value	Threshold	Validation	Required Refactoring Action
Lines of Code (LOC)	600	≤500	Invalid	Decomposes into smaller, functionally cohesive units
Inheritance Coupling (IC)	3–5	≤0.5	Invalid	Reduces dependence on inherited members
Lack of Cohesion (LCOM1)	<5	≤2.5	Invalid	Groups related behaviors and remove unrelated logic
Lack of Cohesion (LCOM4)	5–15	≤1.0	Invalid	Improves internal method interaction
Attribute Inheritance Factor (AIF)	0–2	≥0.5	Invalid	Increases reuse of inherited attributes
All other metrics	Within threshold	/	Valid	/

and accompanying analysis summarize the validation outcome of the provided Python class metrics using the enhanced Blockchain-Based Metric Validation Scheme with zero-knowledge proofs (BMVS-ZKPs*). The evaluation compares current metric values against a predefined threshold profile designed to ensure maintainability, modularity, and structural soundness in Python-based systems.

Analysis of Obtained Results

In this paper, the open-source software TextAdventure v1.0 was selected as a use case, primarily due to its modular architecture, the availability of its source code, and its moderate scale, which allowed for a comprehensive examination of various software metrics and an in-depth analysis of the system’s maintainability, testability, comprehensibility, and reusability.

The results of the software metric analysis contain the average values of various calculated metrics. Upon closer examination, it can be observed that one of the metrics—Cyclomatic Complexity per Method—is highlighted as problematic, even though its value falls within the recommended range, as shown in Table 1. This discrepancy arises because the recommended values in Table 1 refer to individual methods (or, in the case of other metrics, to individual classes).

In addition to Cyclomatic Complexity, the Inheritance Coupling metric indicates that the values of certain classes exceed the recommended limits. This parameter, along with the Depth of Inheritance Tree and Number of Children metrics, suggests that the level of inheritance in the analyzed software is not particularly deep, which can be beneficial for architectural simplicity.

Software metrics related to class cohesion—specifically LCOM1 and LCOM4—are particularly concerning. As shown in Table 1, the recommended value for LCOM1 is 0. Based on this, it can be concluded that some classes contain methods that are not functionally related, which may lead to poor modularity and maintenance difficulties. Another issue identified in the analyzed software is highlighted by the LCOM4 metric, which suggests that certain classes could be split into smaller ones to improve cohesion and maintainability.

The MIF (Method Inheritance Factor) metric, which represents the ratio of inherited methods in a class to the total number of available methods, is moderately elevated, indicating moderate use of inheritance. This may be beneficial in terms of code reuse and structural organization, contributing to maintainability and consistency within the software architecture.

Metrics that indicate class and method coupling are also slightly elevated, suggesting that some classes are overly dependent on others within the system. A high degree of coupling can lead to poor structural isolation and increased sensitivity to modifications, making the system more difficult to maintain and extend.

Despite the majority of software quality metrics falling within acceptable thresholds, five key indicators in our case study—LOC, IC, LCOM1, LCOM4, and AIF—failed validation. These violations signaled architectural and design inefficiencies that could affect long-term maintainability, testability, and modular reuse.

The high LOC count indicates that the class was overly large and likely violated the single-responsibility principle. Splitting the codebase into more focused components improved both maintainability and readability.

The Inheritance Coupling (IC) suggested that the class relied too heavily on inherited structures, which can obscure control flow and reduce understandability—especially in Python, where dynamic method resolution can exacerbate these issues.

The LCOM1 and LCOM4 metrics pointed to poor cohesion, with methods possibly grouped arbitrarily rather than centered around shared data or functionality. Modularization or redistribution of functionality across logical units were advised.

Finally, the low AIF value revealed that attributes inherited from parent classes are being underutilized. This indicates that subclassing was syntactically present but semantically redundant.

To ensure a valid submission under BMVS-ZKP*, the following targeted values should be achieved post-refactoring (

Table 3. Target values for validation.

Metric Name	Target Value	Justification
Lines of Code (LOC)	≤500	Reduces complexity and improves maintainability
Inheritance Coupling (IC)	≤0.50	Ensures minimal tight coupling with base classes
Lack of Cohesion (LCOM1)	≤2.0	Improves class cohesion and functional clarity
Lack of Cohesion (LCOM4)	≤1.0	Ensures meaningful interaction among methods
Attribute Inheritance Factor (AIF)	≥0.5	Promotes effective attribute reuse via inheritance

):

To satisfy the constraints defined in the BMVS-ZKP* validation scheme, the original Python class underwent a targeted refactoring process. The primary goal was to address five specific metrics that failed the predefined thresholds: Lines of Code (LOC), Inheritance Coupling (IC), Lack of Cohesion (LCOM1 and LCOM4), and Attribute Inheritance Factor (AIF). Each of these indicators played a critical role in determining the class’s modularity, reusability, and structural clarity.

The initial LOC of the class exceeded 600, which suggested an overly large and potentially monolithic design. To address this, the class was decomposed into multiple smaller, logically cohesive units. Unrelated methods were extracted into helper classes, and redundant blocks were replaced with utility functions. These changes led to a leaner design, bringing the LOC under the 500-line threshold. This not only improved readability but also enhanced maintainability and reduced testing complexity.

An IC score of 0.69 indicated excessive reliance on inherited methods and attributes. Refactoring strategies focused on replacing deep inheritance with composition, thereby promoting flexibility and modularity. Classes were redesigned to depend on clearly defined interfaces rather than implicit superclass behavior. This shift reduced the IC value below the threshold of 0.5, resulting in a more robust and loosely coupled architecture.

The cohesion metrics revealed fragmentation in the class’s internal logic, with LCOM1 at 5.88 and LCOM4 exceeding the acceptable range. To resolve this, methods were grouped based on their interaction with shared class attributes, and responsibilities were redistributed among new subclasses. This modular restructuring significantly improved cohesion, reducing LCOM1 to below 2.0 and LCOM4 to within the optimal 1.0 range. As a result, the class became more focused in purpose and easier to understand and maintain.

The AIF score of 0.38 suggested that the class was underutilizing attributes defined in its parent classes. The refactoring process emphasized promoting attribute reuse by consolidating common fields in base classes and eliminating redundant variable declarations in subclasses. These efforts elevated the AIF to above 0.5, reinforcing the semantic value of the inheritance hierarchy and ensuring more effective reuse of object state.

After refactoring, all problematic metrics were brought within the required thresholds, confirming that the source code met the structural quality standards through a zero-knowledge proof without disclosing the actual metric values.

All calculated software metric values, including those that exceeded the recommended thresholds, were verified and immutably stored on the Ethereum blockchain using smart contracts. This ensures that the recorded data remain consistent and tamper-proof over time, thereby maintaining a high level of data integrity. By incorporating blockchain technology in the verification phase, the proposed methodology provides a durable foundation for future reviews and analyses, aligning with the core principles of immutability and integrity emphasized throughout this research.

5. Conclusions

In this paper, a novel methodology for the calculation of software metrics and the preservation of result accuracy, based on blockchain technology, is presented. Thanks to the decentralized verification of software metric results through smart contracts, the manipulation of calculated values is prevented, thereby reinforcing trust among developers and stakeholders.

Moreover, the OOM Metric Analyzer tool has been developed as a practical implementation of the proposed methodology. From the automatic calculation of metrics to the transparent recording of results on the Ethereum blockchain, the tool provides developers with immediate and reliable feedback. In this way, it not only facilitates the detection of deviations from desired quality thresholds, but also promotes indicators of maintainability, testability, and reusability by identifying specific parts of the code that require optimization.

In comparison with existing approaches, the proposed methodology introduces several key advantages. Most conventional tools perform metric computation in isolated, centralized environments, often lacking mechanisms for transparent validation. In contrast, our approach integrates automated metric calculation with decentralized verification using blockchain technology.

The novelty of this work lies in the application of blockchain technology specifically tailored for verifying object-oriented metrics in script-based languages such as Python. By developing a system that combines automated measurement and verifiable storage of obtained results, our research offers a practical and extensible tool for improving current practices in software quality evaluation. By implementing this decentralized solution, a key weakness of existing software quality management tools—namely, the lack of trustworthy verification—is effectively addressed. As a result, development teams can more reliably apply strategies for detecting and mitigating potential shortcomings.

Although the proposed methodology addresses a core challenge in software evaluation, certain limitations must be acknowledged. The reliance on blockchain technology, while ensuring transparency and immutability, introduces performance and cost overhead—primarily due to transaction fees associated with public blockchain networks such as Ethereum. Furthermore, the current implementation of the tool supports only a single scripting language—Python—which limits its applicability in environments where other languages, such as JavaScript, are commonly used.

Future work should aim to expand the capabilities of the developed tool by incorporating support for a wider variety of script-based programming languages, such as JavaScript, Ruby, and PHP, thereby enhancing its usefulness across diverse development environments that rely on dynamically typed languages. Another promising avenue for advancement is the integration of artificial intelligence (AI) techniques into the software metric analysis process, enabling automated detection of anomalies, prediction of code quality decline, and generation of recommendations for structural improvements in the software system. Also, AI learning models, trained on historical metric data, could provide predictive insights and suggest targeted refactoring strategies, thereby improving code maintainability and reducing technical debt. Moreover, AI-driven recommendations can help developers prioritize optimization efforts, especially in large and complex codebases where manual inspection is impractical.