Blockchain data provenance protection and contribution calculation system

Abstract

The application belongs to the technical field of military research data management, and discloses a data right protection and contribution calculation system of a block chain, which comprises: an application layer, which is used for providing trusted military research data based on a block chain core layer to realize data evidence, whole-process operation tracing, multi-dimensional contribution calculation and auditing functions for a collaborative research and development scene; an enhanced component layer, which is used for providing management services, data scheduling, user access and security enhancement support for the application layer; a block chain core layer, which is used for providing block chain basic capabilities supporting multi-chain collaboration, high-throughput consensus, automatic execution of intelligent contracts, national secret level security protection and trusted node management; and an infrastructure layer, which provides computing, storage and network resources for the application layer, the enhanced component layer and the block chain core layer. The application realizes data right protection and contribution calculation by adopting block chain encryption algorithms, consensus mechanisms, distributed ledgers and intelligent contracts and other technologies.

Description

Technical Field

[0001] This invention relates to the field of military research data management technology, and in particular to a blockchain-based data ownership protection and contribution calculation system. Background Technology

[0002] With the rapid development of information technology, data has become one of the key factors determining the outcome of wars. However, due to the extremely sensitive nature of military research data, issues such as its security, sharing, and ownership are becoming increasingly prominent. Especially in the digital age, the ease with which data can be copied and disseminated makes data security and ownership issues even more complex. Therefore, research on blockchain data ownership confirmation and contribution calculation is of great significance for ensuring the security of military research data, promoting data sharing, and clarifying data ownership relationships.

[0003] Military research data often involves national secrets and strategic security, and its leakage could cause enormous losses to the country. Traditional data security protection methods are no longer sufficient to meet the needs of modern military research. Blockchain technology, with its decentralized and tamper-proof characteristics, provides a new solution for the secure protection of military research data. By using blockchain technology to establish data ownership, the authenticity and integrity of the data can be ensured, reducing the risk of data leakage.

[0004] In the field of military research, data sharing is crucial for promoting the exchange and collaboration of research findings. However, the potential for uncontrolled risks after data sharing, such as misuse or abuse, reduces the willingness of data providers to share. Blockchain technology can achieve data traceability and transparency, ensuring controllability and traceability during the sharing process, thereby enhancing data providers' trust in data sharing.

[0005] In the field of military research, data is often generated and contributed by multiple parties. However, due to unclear data ownership, the rights of data contributors may not be guaranteed, affecting the enthusiasm for data sharing and the depth of scientific research cooperation. Blockchain technology, through smart contracts and other technical means, can calculate and allocate data contributions, ensuring that the rights of data contributors are reasonably protected.

[0006] In conclusion, the blockchain-based data ownership verification and contribution calculation system is of great significance in the field of military research. By using blockchain technology to verify data ownership, the security and controllability of military research data can be guaranteed; by using smart contracts and other technologies to calculate and distribute data contributions, the rights and interests of data contributors can be reasonably protected; furthermore, blockchain technology can promote the sharing and collaboration of military research data, and drive the transformation and application of scientific research results.

[0007] Therefore, how to provide a blockchain-based data ownership protection and contribution calculation system is an urgent problem to be solved. Summary of the Invention

[0008] This invention provides a blockchain-based data ownership protection and contribution calculation system to address the problems in the prior art.

[0009] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or to describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0010] According to embodiments of the present invention, a blockchain-based data ownership protection and contribution calculation system is provided.

[0011] In one embodiment, a blockchain-based data ownership protection and contribution calculation system includes: an application layer, an enhancement component layer, a blockchain core layer, and an infrastructure layer; wherein...

[0012] The application layer is used to provide trusted military research data based on the core blockchain layer, so as to realize data storage, full-process operation traceability, multi-dimensional contribution calculation and auditing functions for collaborative research and development scenarios.

[0013] The enhancement component layer connects to both the application layer and the blockchain core layer, and is used to provide management services, data scheduling, user access, and security enhancement support for the application layer.

[0014] The core layer of the blockchain runs on top of the resources provided by the infrastructure layer, and is used to provide basic blockchain capabilities such as supporting multi-chain collaboration, high-throughput consensus, automatic execution of smart contracts, national cryptographic-level security protection, and trusted node management.

[0015] The infrastructure layer provides computing, storage, and network resources for the application layer, enhancement component layer, and blockchain core layer to adapt to the needs of different deployment environments.

[0016] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0017] This invention employs blockchain encryption algorithms, consensus mechanisms, distributed ledgers, and smart contracts to achieve data ownership protection and contribution calculation. Regarding data ownership verification, cryptographic algorithms ensure data security, integrity, and authenticity, while blockchain networks and smart contracts provide protection for data ownership. For contribution calculation, consensus mechanisms and distributed ledgers ensure the fairness and objectivity of node evaluations of contributions, and smart contracts enable automated calculation. This contributes to building a secure, reliable, and fair data sharing environment, maximizing data value.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0020] Figure 1 This is an overall architecture diagram of a blockchain data ownership protection and contribution calculation system, illustrated according to an exemplary embodiment. Detailed Implementation

[0021] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0022] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0023] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0024] Figure 1 An embodiment of the blockchain data ownership protection and contribution calculation system of the present invention is shown.

[0025] In this optional embodiment, the blockchain data ownership protection and contribution calculation system includes: an application layer, an enhancement component layer, a blockchain core layer, and an infrastructure layer; wherein,

[0026] The application layer is used to provide trusted military research data based on the blockchain core layer, so as to realize data storage, full-process operation traceability, multi-dimensional contribution calculation and auditing functions for collaborative research and development scenarios.

[0027] It should be explained that the application layer is the functional entry point for business scenarios. The application layer consists of the direct business function modules provided by the system to the outside world, focusing on the core needs of military research data collaboration scenarios. All functions are implemented based on the support of lower-level components. Specific units include: a data storage unit that can store the hash value and ownership information of military research data (files, operation records, etc.) on the blockchain to achieve traceability of data source and verification of integrity; a process traceability unit that can record the entire lifecycle of data operations (providing, importing, sharing, and using), and supports querying the process trajectory by time / participant / data type; a contribution calculation unit that can call the lower-level smart contract to automatically collect data on the amount provided, frequency of use, and multi-party evaluations to generate quantitative contribution results; and a data auditing unit that can realize compliance review of data operations and traceability of permission violations based on the immutable records on the blockchain.

[0028] In this optional embodiment, the application layer includes a data storage unit, a process traceability unit, a contribution calculation unit, and a data auditing unit.

[0029] In this optional embodiment, the smart contract unit of the blockchain core layer is invoked to calculate the military research data based on multi-dimensional quantitative indicators, and the output quantitative contribution results include:

[0030] Collect and verify the original data of all parties involved in military research data that are stored on the blockchain to obtain valid data; standardize the valid data according to the data provision, workload, data usage frequency and multi-party evaluation dimensions to generate indicator values ​​for each dimension; perform weighted calculation on the indicator values ​​of each dimension based on preset weights to generate the final contribution value; use smart contracts to write the final contribution value and calculation process data as proof of contribution into the blockchain.

[0031] It's important to explain that blockchain provides trusted on-chain data support for contribution calculation. Due to the transparency and immutability of blockchain, the flow and changes of data can be recorded and traced, providing a foundation for fair and transparent contribution calculation. By analyzing data activity on the blockchain, the contribution level of each participant can be assessed relatively accurately, avoiding the influence of subjective factors and information asymmetry. Simultaneously, the automatic execution function of smart contracts also ensures the fairness and credibility of contribution calculation.

[0032] Data records on a blockchain are immutable, meaning that once data is written to the blockchain, it cannot be changed or deleted. This characteristic enables blockchain to have a reliable mechanism for on-chain data storage and verification, used to record key events and data changes during collaborative research and development tasks.

[0033] Blockchain smart contracts allow for the definition of data ownership and usage rights. When data is created, modified, or transferred within a sandbox collaborative environment, these operations are recorded on the blockchain, thus confirming the data's owner and usage rights.

[0034] Contribution calculation requires summarizing and calculating the amount of data provided by the data provider during the data product development process, the frequency of data usage by the R&D unit (import, sharing, viewing, and downloading operations during the R&D process), and combining the data usage evaluation of the R&D unit and the data usage evaluation of the data product users to calculate the contribution and provide proof of contribution.

[0035] In collaborative R&D, proof-of-work can be used to calculate each participant's contribution. For example, it can record each participant's workload in task deployment, sandbox construction, data import, and the overall R&D process, as well as the quality and efficiency of their task completion.

[0036] The contribution of participants is automatically calculated through blockchain smart contracts. The smart contract automatically calculates contributions based on data acquisition standards and data usage frequency standards defined during the collaborative R&D process. When the task is completed, the smart contract automatically calculates the contribution of each data provider to the R&D task according to the model and records the results on the blockchain.

[0037] Contribution calculation is based on data value, workload, and multi-party evaluation. It relies on immutable data on the blockchain and is automatically completed by smart contracts, with the entire calculation process and results uploaded to the blockchain. The specific process is as follows:

[0038] 1) The calculation premises include the data source and the statistical scope.

[0039] All computational data originates from the immutable records of the blockchain distributed ledger, ensuring authenticity and traceability: the data provider dimension is the amount of valid data provided on-chain (including data file size, data type, and uniqueness verification results); the R&D participant dimension is the on-chain logs of workload-related operations (task release, sandbox construction, data import, R&D process operations) and data usage frequency logs (number of import, sharing, viewing, and download operations); the evaluation dimension includes on-chain signed evaluations of data usage by R&D units and evaluations from data product users (both are immutable structured scores).

[0040] The statistical scope includes all relevant operations, data and evaluation records of all participants (data providers, core participants of R&D units) within a single collaborative R&D task cycle (from task initiation to task acceptance / data product delivery), and the statistical period is completely synchronized with the task cycle.

[0041] 2) The core computational steps are the entire process of automatic execution by smart contracts.

[0042] Step 1: Basic data collection and validity verification.

[0043] The smart contract automatically extracts the original data from each participant on the blockchain and performs validity checks, removing invalid data.

[0044] Data provision verification uses data hash values ​​to remove duplicates, only counting non-duplicate and formatted valid data (invalid and duplicate data are not counted); workload operation verification only counts valid operations confirmed by the task administrator node, and erroneous and invalid operations are removed; evaluation data verification only counts evaluations submitted by R&D units and product users who have passed on-chain identity authentication, and evaluations that are unsigned or exceed the scoring range are invalid.

[0045] Step 2: Quantification and standardization of multi-dimensional indicators.

[0046] For the verified valid data, the indicators are broken down into four dimensions: data provision, workload, data usage frequency, and multi-party evaluation. They are then standardized into a [0,1] value range to eliminate differences in units and ensure that weighted calculations are possible.

[0047] Dimension 1: Data Provision Quantity Indicators ).

[0048] The total size of valid data submitted by the data provider in the original data is denoted as D (unit: GB, the total original size of the files stored on the chain).

[0049] The standardized formula is: ;in, This represents the maximum effective data provision amount from all data providers involved in the research and development task; if the task has only one data provider, , .

[0050] Dimension 2: Workload Indicators ).

[0051] Based on the proof-of-work mechanism, the effective workload of R&D participants in the entire collaborative R&D process is statistically analyzed, taking into account both the weight of operation type and the quality of completion.

[0052] The on-chain records the number of valid operations and their quality scores. The number of operations includes the number of task releases. ), number of times the sandbox is built ( ), number of data imports ( ), Number of core operations in the R&D process ( (e.g., data processing, model training, and related operations); quality scoring includes the R&D unit's score for the completion quality of each operation (Q, 1-5 points, confirmed by on-chain signature);

[0053] The operation weight settings include task release (W_A1=0.1), sandbox construction (W_A2=0.3), data import (W_A3=0.2), and R&D process operations (W_A4=0.4).

[0054] The formula for weighted calculation of workload is: The quality correction formula is: A_correction = A × (Q / 5) (standardizing the quality score to [0,1] and correcting the workload weight); the standardization formula is: ; where A_correction This is the maximum workload adjustment value for all R&D participants in this R&D task.

[0055] Dimension 3: Data usage frequency index ( ).

[0056] The raw data represents the number of effective operations performed by the R&D unit on the data provided by the data provider, denoted as: Import Count ( ), number of times shared ( ), number of views ( ), number of downloads ( );

[0057] In the operation weight settings (based on data circulation value), the weights are: Import (W_B1=0.3), Download (W_B2=0.3), Share (W_B3=0.2), and View (W_B4=0.2).

[0058] The frequency-weighted calculation formula is as follows: The standardized formula is: ;in, The sum of the maximum usage frequency of data from all data providers in this research and development task.

[0059] Dimension 4: Multi-faceted evaluation indicators ( ).

[0060] The raw data is the average score of two types of on-chain signature evaluations, specifically including: evaluation of data usage by R&D units ( ): A 1-5 point scale reflects data quality and usability; user evaluation of data products ( (A 1-5 point scale is used to reflect the value and practicality of the data application; the weighted average score is calculated as follows:) (Both evaluation categories have equal weight, which can be adjusted via smart contracts.) The standardized formula is: (Convert the 5-point average score to the range of [0,1].)

[0061] Step 3: Calculate the final contribution using multi-dimensional weighted calculation.

[0062] The dimensional weighting is set in conjunction with the technical disclosure document to protect the rights and interests of contributors and promote data sharing and R&D collaboration. The total weight of each dimension is set (which can be dynamically adjusted through the smart contract governance mechanism).

[0063] Data provision weights ( ): 0.3 (emphasizing the fundamental value of data); workload weight ( ): 0.25 (emphasizing contribution to the R&D process); data usage frequency weight ( ): 0.2 (emphasizing the value of data circulation); Multi-party evaluation weight (W4): 0.25 (emphasizing data quality and application value).

[0064] The weight constraint formula is: The core formula for contribution is: final contribution. The result is rounded to two decimal places, with a range of [0,1]. A larger value indicates a higher overall contribution.

[0065] Step 4: The smart contract is executed automatically and the results are recorded on the blockchain.

[0066] The trigger condition is that after the collaborative R&D task is completed (confirmed by the on-chain task acceptance node), the smart contract automatically triggers the contribution calculation process. The smart contract calls the original data stored on the chain and preset weight parameters according to the above steps, and automatically completes the entire process of data verification, indicator quantification, standardization and weighted calculation without manual intervention. It generates an independent contribution proof for each participant (data provider and R&D participant), and the proof content includes the original data hash, indicator values ​​of each dimension, calculation process and final contribution.

[0067] On-chain evidence storage ensures that contribution proofs and calculation results are written into the immutable blockchain ledger, and all nodes verify the consistency of the results through a consensus mechanism to ensure no tampering; traceability ensures that participants can query their personal contribution and calculation basis with their own private keys, meeting the requirements of transparency and verifiability.

[0068] 3) Key supplementary explanations.

[0069] The rules for handling abnormal data are as follows: Duplicate operations: Only one valid count is given for the same type of operation performed by the same participant within 24 hours; Zero data processing: If a participant does not generate data for a certain type of indicator (e.g., not participating in sandbox construction), the indicator value is counted as 0, which does not affect the calculation of other dimensions; Missing evaluation processing: If a participant does not receive a certain type of evaluation, that evaluation dimension is calculated with a default score of 3. ).

[0070] The weight adjustment mechanism is as follows: total dimension weight ( ) and operator weights ( The weight parameters can be adjusted through node consensus voting. The adjustment process involves any validator node submitting an adjustment proposal → confirmation by more than 2 / 3 of the main chain validator nodes → automatic update of the weight parameters by the smart contract. The new parameters only apply to subsequent tasks.

[0071] Workload efficiency correction is as follows: The efficiency correction factor (T) can be increased using the following formula: Where T represents the actual time taken for the participating party to complete this type of work. This serves as the standard reference time for this type of work (preset on-chain). The higher the efficiency (the shorter the T), the larger the correction coefficient, and the more accurately it reflects the value of the workload.

[0072] The enhancement component layer connects to both the application layer and the blockchain core layer, providing management services, data scheduling, user access, and enhanced security support for the application layer.

[0073] It should be explained that the enhancement component layer is the adaptation support between business and blockchain. The enhancement component layer is an intermediate adaptation layer between application layer business and blockchain underlying capabilities. It reduces the coupling between business and underlying layer by encapsulating general components and supporting functions. Specifically, it includes general components and supporting functions.

[0074] The general components include management services, data management, user access, and privacy protection. Management services are used for basic management functions such as global system configuration management, node status monitoring, and log auditing. Data management is used for scheduling and control of data sharding, archiving, and synchronization. User access is used for multi-terminal (Web, API) user authentication and permission allocation. Privacy protection is used for privacy and security enhancement functions based on proxy re-encryption and data anonymization.

[0075] Supporting functions include interface, storage, management, and security functions; interface functions include API / SDK (interfaces for third-party systems) and WEB access (user interaction entry point on the web); storage functions include partitioned storage (data partitioned by security level / business type), storage synchronization (consistent synchronization of on-chain and off-chain data), data archiving (long-term storage of historical data), and data sharding (split and encrypt large files); management functions include member management (maintaining the identity and permissions of participants) and configuration management (dynamic adjustment of system parameters); and security functions include privacy transactions (encrypted transactions based on proxy re-encryption).

[0076] In this optional embodiment, the enhancement component layer includes a management service unit, a data management unit, a user access unit, and a privacy protection unit.

[0077] In this optional embodiment, enhancing the privacy and security of military research data through proxy re-encryption technology includes:

[0078] The shared military research data is symmetrically encrypted, and the encrypted military research data and encryption key information are stored in the cloud and on the blockchain, respectively. When it is necessary to authorize other participants to access the data, the sender uses a proxy re-encryption algorithm to generate a re-encryption key. During the decryption and access process of the receiver, dynamic verification is performed based on the preset permission conditions on the blockchain, and the military research data is allowed to be decrypted and used when the triple dynamic permission constraints are met.

[0079] In this optional embodiment, the triple dynamic permission constraints include time-dimensional dynamic permissions, event-dimensional dynamic permissions, and attribute-dimensional dynamic permissions.

[0080] It needs to be explained that, given the high level of data confidentiality and the requirement to fully protect data privacy and security, this system innovatively utilizes the characteristics of blockchain technology to record key actions and data operation records (including key information such as the data owner's name, data name, data ID, and data characteristic values) during collaborative R&D, as well as the entire process of data import, transfer, use, and destruction, all on the blockchain, forming a complete data record. Every important operation or interaction is written into the chain as a block, clearly recording the initial source of the data, the transfer process, and the destruction operation, establishing the data ownership relationship. While ensuring high-density data privacy and security, data ownership is confirmed on the blockchain through data R&D business environment users independently uploading data characteristic information. This completes data ownership confirmation while guaranteeing data privacy and security.

[0081] Proxy re-encryption enables efficient and private data sharing. Blockchain stores large files (such as contracts, notarized documents, and various large record files) in the cloud using AES symmetric encryption. The file's hash and AES key are then encrypted and stored on the blockchain network using the sender's public key. If the sender wants to authorize the recipient to view the original file, they can multiply the recipient's public key with their own private key to obtain a re-encryption key, and then re-encrypt it. The recipient can then decrypt the file using their own private key to retrieve the original file content. Proxy re-encryption technology can improve the privacy and security of data transmission and on-chain data storage.

[0082] The proxy re-encryption technology uses a combination of symmetric encryption, asymmetric encryption, and blockchain notarization to achieve efficient and private sharing of large files, ensuring both data storage and transmission security, and guaranteeing that the authorization process is traceable and tamper-proof.

[0083] The core logic of the entire process of proxy re-encryption technology is that large files are encrypted using AES symmetric encryption, the AES key is encrypted using asymmetric encryption, the authorization process is implemented through re-encryption, and key information is stored on the blockchain for evidence. Specifically, it is divided into 4 stages:

[0084] Phase 1: Large file encryption and uploading of core information to the blockchain (executed by the sender).

[0085] The goal is to encrypt large files and store them in the cloud, while simultaneously uploading key verification information to the blockchain to ensure file immutability and key security. The sender obtains the original large file (denoted as F, e.g., a 10GB military research dataset); generates an AES symmetric key (denoted as K, using the AES-256 algorithm, 256 bits in length); encrypts the original file F using the AES key K: F is encrypted using the AES algorithm (ECB / CBC / GCM mode, GCM mode is preferred in this case, balancing encryption and integrity verification), resulting in the encrypted large file (denoted as F_ciphertext); F_ciphertext is uploaded to the cloud for storage; and the hash value of the original file F is calculated (denoted as Hash_F, using SHA256 / SM3 algorithm). Method: Hash_F = SHA256(F), used for subsequent verification of file integrity; AES key K is asymmetrically encrypted using the sender's own public key (denoted as Pk_fa), resulting in the encrypted AES key (denoted as K_ciphertext); Formula: K_ciphertext = Asymmetric encryption algorithm(K, Pk_fa); Package "Hash_F (file hash) + K_ciphertext (encrypted AES key) + sender's public key (Pk_fa) + cloud F_ciphertext storage address" to generate a blockchain transaction, which is then written into the distributed ledger (immutable, for subsequent traceability and verification).

[0086] Phase 2: Authorization Re-encryption.

[0087] The goal is for the sender to authorize the receiver to access ciphertext F without transmitting their private key. The blockchain only performs re-encryption operations and does not touch the original data. The sender initiates an authorization request, submitting authorization instructions to the blockchain, including the following information: the receiver's public key (Pk_receive), their own private key (Sk_send, used only to generate the re-encryption key and not disclosed to the blockchain), the K_ciphertext uploaded to the chain, and Hash_F. A re-encryption key (denoted as Rk) is generated by the sender using their private key Sk_send and the receiver's public key Pk_receive, through a proxy re-encryption algorithm. The core logic is Rk = proxy re-encryption algorithm (Sk_send, Pk_receive). Only the sender can generate Sk_send, and Rk can only be accessed by the sender. The process of "sending encrypted K_ ciphertext using Pk_" is transformed into "receiving encrypted K_ ciphertext using Pk_". Blockchain re-encryption occurs when a blockchain node receives Rk and K_ ciphertext, and without decrypting K_ ciphertext, directly uses Rk to perform a re-encryption operation on K_ ciphertext, obtaining the re-encrypted AES key, denoted as K_ re-ciphertext. The formula is: K_ re-ciphertext = re-encryption operation (K_ ciphertext, Rk). Uploading the re-encryption result to the blockchain involves the blockchain writing "K_ re-ciphertext + recipient's public key Pk_receive + authorization timestamp" into the ledger, completing the authorization record (immutable and traceable).

[0088] Phase 3: The receiver decrypts the AES key (executed by the receiver).

[0089] The goal is for the recipient to decrypt the K-fold ciphertext using their own private key to obtain the AES key K, which can only be decrypted by the recipient. The recipient queries the blockchain using their public key Pk_receive to find the corresponding K-fold ciphertext, Hash_F, and the cloud storage address for the F-fold ciphertext. The recipient then decrypts the K-fold ciphertext using their private key (Sk_receive). Since the K-fold ciphertext is generated based on Pk_receive, only Sk_receive can decrypt it, yielding the original AES key K. The formula is: K = Asymmetric decryption algorithm (K-fold ciphertext, Sk_receive). The recipient then downloads the F-fold ciphertext (the encrypted large file) from the cloud.

[0090] Phase 4: Verify file integrity and decrypt the original file.

[0091] The goal is to ensure that the downloaded ciphertext F has not been tampered with, and to ultimately decrypt it to obtain the original file F. The receiver decrypts the ciphertext F using the AES key K: using the same AES algorithm (GCM mode) as the encryption phase, the receiver decrypts the ciphertext F to obtain the decrypted file (denoted as F_decrypted); to verify file integrity, the receiver calculates the hash value of F_decrypted, denoted as Hash_F'=SHA256(F_decrypted), and compares it with the Hash_F stored on the blockchain; if Hash_F'=Hash_F: it proves the file has not been tampered with, and F_decrypted is the original file F; if Hash_F'≠Hash_F: it means the file has been tampered with during cloud storage or transmission, and the file is rejected; the receiver obtains the complete, untampered original file F, completing the private sharing.

[0092] The triple dynamic permission constraints include time-dimensional dynamic permissions, event-dimensional dynamic permissions, and attribute-dimensional dynamic permissions. Time-dimensional dynamic permissions are based on timestamp validity management; authorized permissions are only valid within a preset time window and automatically expire afterward, preventing long-term data exposure. When the sender initiates an authorization request, the permission validity period is clearly defined in the smart contract: setting the authorization start time (T_start) and authorization expiration time (T_end), forming a time window [T_start, T_end]. When the blockchain node generates the re-encryption key (Rk), the time constraint is written into the key attribute: Rk is only valid when the timestamp satisfies T_start ≤ current blockchain time ≤ T_end. When the receiver decrypts, the smart contract automatically verifies the current time: if it exceeds the time window, the decryption operation is directly rejected, and the permission is returned as expired; if it is within the time window, the AES key (K) is allowed to be decrypted using the private key (Sk_receive). The time change mechanism allows the sender to initiate permission renewal / early termination proposals through the smart contract. After verification by node consensus, T_start / T_end is automatically updated without re-executing the re-encryption process. This invention is adapted to the phased needs of military research and development missions, such as ensuring that certain data can only be shared during the mission's research and development cycle, thus preventing data from being illegally accessed after the mission ends.

[0093] Event-based dynamic permissions are triggered by on-chain events. The effectiveness of authorized permissions depends on the occurrence of a specific on-chain event; without a corresponding event trigger, decryption is impossible even with the re-encryption key. The sender presets authorization trigger events in the smart contract: the event type is an objective operation traceable on the blockchain, such as a research and development task reaching a milestone (on-chain node signature confirmation), the recipient completing data security training (on-chain evidence of training records), or the task administrator node approving access (on-chain transaction approval). In the proxy re-encryption process, the re-encryption key (Rk) is bound to the trigger event; Rk is initially inactive, and the smart contract automatically activates Rk only when a preset trigger event occurs on the chain. When the recipient initiates a decryption request, the smart contract verifies the on-chain event record: if the trigger event has occurred and is valid (e.g., the milestone confirmation transaction has been uploaded to the chain), decryption is allowed; if it has not been triggered or the event is invalid (e.g., approval failed), decryption is refused. Multiple event conditions can be combined, supporting flexible configurations such as milestone achievement and approval, or any single event fulfillment, adapting to complex research and development scenarios. This invention ensures that data is accessed only at compliant process nodes (such as confidential data that requires multi-level approval before it can be shared), preventing data from being misused at non-compliant stages.

[0094] Dynamic permission control based on attribute dimensions is implemented for identity management. Authorization is only effective for recipients with specific attributes; if attributes do not match, decryption is impossible, achieving precise identity authorization. Blockchain nodes pre-store on-chain attribute credentials for all participants. Attributes are uploaded to the blockchain after being certified by a CA certificate, including unit type (data provider / R&D unit / management unit), personnel confidentiality level (top secret / confidential / secret), and task participation permission (whether the recipient is a member of the current R&D task). When the sender initiates authorization, the recipient attribute conditions are specified in the smart contract, such as "Unit type = R&D unit; Confidentiality level ≥ confidential; Task participation permission = yes". When generating the re-encryption key (Rk), the attribute conditions are embedded in the smart contract logic: When the recipient requests decryption, they must submit their own on-chain attribute credentials; the smart contract automatically verifies the attribute matching degree by verifying the authenticity of the attribute credentials through hash comparison. If all preset conditions are met, decryption is allowed; if any attribute does not match (e.g., insufficient confidentiality level), decryption is refused, and abnormal access behavior is recorded and uploaded to the blockchain for traceability. This invention is adapted to the hierarchical classification and control requirements of military data, ensuring that high-secret data is only accessible to personnel / units with corresponding permissions, and preventing unauthorized access.

[0095] The dynamic access control system is integrated with the existing proxy re-encryption process. The optimized proxy re-encryption process is as follows:

[0096] Phase 1: Large file encryption and core information uploading to the blockchain (adding permission condition configuration).

[0097] After the sender completes AES encryption and hash calculation, the sender adds time / event / attribute permission conditions to the smart contract and stores them on the blockchain along with "Hash_F+K_ciphertext+Pk_send+cloud storage address".

[0098] Phase 2: Authorization Re-encryption (embedded new permission conditions).

[0099] When the sender initiates authorization, the smart contract binds the preset permission conditions with the receiver's public key (Pk_receive) and the sender's private key (Sk_send) to generate a re-encryption key with conditional constraints (Rk_dynamic), instead of the original static key; the validity of Rk_dynamic is verified by the smart contract in real time.

[0100] Phase 3: The receiver decrypts the AES key (additional permission condition verification).

[0101] After the receiver finds the K_ encrypted message, the smart contract first verifies whether the receiver meets the preset conditions (time is within the window, event has been triggered, attributes match). Only if all conditions are met is it allowed to decrypt K through Sk_; if any condition is not met, decryption is directly blocked.

[0102] Phase 4: Dynamic adjustment and traceability of permissions.

[0103] Permission changes mean that the sender can modify permission conditions (such as extending the validity period or adding triggering events) through a smart contract, and the modification record is recorded on the blockchain and cannot be tampered with; behavior traceability ensures that all permission verification results (pass / reject) and the receiver's decryption operation are recorded by blockchain timestamps, which can be traced throughout the process and facilitates auditing.

[0104] The core layer of the blockchain runs on top of the resources provided by the infrastructure layer, and is used to provide basic blockchain capabilities such as supporting multi-chain collaboration, high-throughput consensus, automatic execution of smart contracts, national cryptographic-level security protection, and trusted node management.

[0105] It's important to clarify that the blockchain core layer is the core engine for system security and consensus. The blockchain core layer forms the system's technological foundation, providing fundamental blockchain capabilities such as distributed ledgers, consensus mechanisms, and encryption to ensure the security, trustworthiness, and consistency of data and transactions. Specifically, it includes: distributed ledgers, smart contract engines, consensus algorithms, encryption algorithms, data storage, network protocols, and permissioned access.

[0106] The distributed ledger is a decentralized database used to store all transactions, blocks, and account information on the blockchain (this invention adopts the Orbits multi-chain ledger architecture); the distributed ledger includes accounts, assets, blocks, transactions, node roles, operations, and upgrades; accounts / assets are used for the on-chain identity (account) of participants and the digital assets corresponding to data ownership; blocks / transactions are used for the basic storage unit (block) of on-chain data and the basic recording unit (transaction) of operational behavior; node roles / operations / upgrades are used for the functional classification of nodes (verifying nodes / delegating nodes), node operation specifications, and on-chain system upgrade mechanisms.

[0107] The essence of blockchain is a distributed ledger technology that allows multiple nodes to jointly maintain a reliable database. Cryptographic algorithms ensure the security of data transmission and access, while preventing data tampering or forgery. The characteristics of distributed ledger technology guarantee data traceability, immutability, and transparency, thus providing a foundation for data ownership verification.

[0108] The smart contract engine supports a dual-engine architecture of WASM (high-performance complex contracts) and V8 (flexible lightweight contracts), executing automated logic such as contribution calculation and access control. The consensus algorithm employs a two-layer Firework algorithm, using DPOS to elect and verify nodes and improved BFT to generate blocks, balancing efficiency and security. Encryption algorithms support Chinese national cryptographic standards (SM2 / SM3 / SM4) and international algorithms (ED25519, SHA256, AES) to ensure data and transaction privacy. Data is stored on-chain using LevelDB / RocksDB (efficient key-value stores) and off-chain using MySQL / Oracle (structured data stores). Network protocols are based on TCP / WebSocket (node ​​communication) and Protocol Buffer (data serialization) to achieve efficient communication between nodes. Permissioned access is achieved through CA certificates and license credentials for node authentication, ensuring only authorized nodes can participate in consensus and data interaction.

[0109] A smart contract is an automatically executing computer program that can run on a blockchain to achieve automated data management and control. Through smart contracts, automatic data verification, authorization, and management can be achieved, thereby ensuring data security and reliability. Smart contracts can be used to implement various complex business logics, making data ownership confirmation more flexible and diverse.

[0110] Consensus algorithms are the foundation and core of blockchain technology. They determine how cluster nodes reach consensus on the authentication order and accurate content of interactions, ensuring the consistency of node ledger data. Consensus algorithms make on-chain data transparent, tamper-proof, and impossible to forge. The application of blockchain consensus mechanisms not only reduces information asymmetry throughout the system but also significantly enhances the overall trust level, achieving co-governance, increasing governance transparency, creating a trustworthy environment, and ultimately promoting improved governance. Consensus mechanisms guarantee the consistency of block additions across the entire network, preventing blockchain forks while ensuring the authenticity and integrity of on-chain information.

[0111] Blockchain employs various cryptographic algorithms to ensure data security and integrity. For example, hash algorithms can map data of arbitrary length to a fixed-length hash value, making data tampering detectable; asymmetric encryption algorithms can encrypt and decrypt data, allowing only those with the corresponding keys to access it. The value of introducing cryptographic technology lies in significantly improving the robustness of the blockchain system. In broader digital information systems and more complex business systems, blockchain systems, through a series of cryptographic security technologies and consistent redundant data storage, achieve decentralized operation and collective maintenance of information and business systems. The introduction of multiple encryption technologies greatly enhances the system's security and reliability.

[0112] In this optional embodiment, the blockchain core layer includes a distributed ledger unit, a consensus mechanism unit, a smart contract unit, a cryptographic algorithm unit, a data storage unit, a network protocol unit, and a permissioned access unit.

[0113] The distributed ledger unit utilizes the Orbits multi-chain ledger structure to achieve inter-chain isolation and auditable storage of different business data. Specifically, by storing and transmitting data feature values ​​on the blockchain without storing the original data information, and simultaneously preserving key business behavior information on the chain, decentralized data storage and exchange are achieved, reducing the risk of data leakage, tampering, or unauthorized access. Data on the blockchain is stored in block form and encrypted using hash functions to ensure data integrity and immutability, thereby enhancing data privacy protection. The Orbits ledger structure design incorporates the following elements: inter-chain ledger isolation, unified accounts to prevent replay attacks, and auditability of data between chains. These elements are crucial for adapting to complex business scenarios. Ensuring resource and business isolation between different chains avoids the problem of resource contention among different businesses, as seen in single-chain structures.

[0114] In this optional embodiment, the Firework two-layer consensus algorithm is used to elect verification nodes based on the DPOS mechanism and generate blocks by combining the improved BFT algorithm, including:

[0115] Initialize consensus parameters, which include the maximum number of validator nodes, voting weight threshold, Byzantine fault tolerance threshold, and upper limit on the number of subchains;

[0116] In Firework's DPOS layer, a set of main chain validator nodes is elected based on consensus parameters and the voting weights of delegated nodes, and the election results are stored on the chain.

[0117] The improved BFT layer in Firework selects master nodes and backup nodes from the main chain verification node set, and completes block proposal, verification and adjustment through three rounds of interaction: pre-preparation, preparation and submission.

[0118] In this optional embodiment, the Firework two-layer consensus algorithm further includes a time and space consensus decoupling mechanism, a node hierarchical governance and dynamic fault tolerance mechanism, and a consensus result pre-submission and batch verification mechanism; wherein,

[0119] The time and space consensus decoupling mechanism is used to decouple the consensus responsibilities of the improved BFT layer into time consensus and space consensus; wherein, the time consensus layer adds temporary timestamps to transactions to provide an instantly available state, and the space consensus layer asynchronously performs cross-chain data verification to generate a final deterministic block;

[0120] The node hierarchical governance and dynamic fault tolerance mechanism is used to divide nodes into different levels according to their confidentiality level or trustworthiness, configure differentiated Byzantine fault tolerance thresholds for each level, and realize dynamic adjustment of the level based on node behavior monitoring.

[0121] The consensus result pre-submission and batch verification mechanism is used to package multiple transactions within a preset time window into a transaction group. The time consensus layer pre-submits the transaction group as a whole and generates a temporary timestamp, and then the spatial consensus layer performs batch integrity verification of the transaction group.

[0122] It's important to clarify that consensus algorithms are the core of blockchain technology, determining the overall performance, security, and even application prospects of a blockchain system. With the continuous emergence of new blockchain applications, the surge in the number of blockchain users, and the increasing diversity of operation types, the reliability, security, and performance requirements for consensus algorithms are also rising. Existing typical single-chain consensus algorithms can no longer meet these demands, specifically as follows:

[0123] The Proof-of-Work (PoW) algorithm produces blocks through hash calculations, with unified accounting and verification across the entire network. Its advantages include high decentralization and security, but it suffers from drawbacks such as high energy consumption, high transaction latency, and low throughput. The Delegated Proof-of-Stake (DPoS) algorithm has a relatively fast block production speed, but its security remains to be tested. The PBFT algorithm is a traditional message-passing-based distributed consensus algorithm with low latency and high throughput. However, because it cannot dynamically update validator nodes, and the leader node cannot be dynamically changed based on rules, its consensus efficiency decreases as the number of nodes increases.

[0124] Orbits employs an innovative two-layer, multi-chain consensus algorithm called Firework. It generates a set of main chain validator nodes through voting using the DPOS protocol, and then the selected validator nodes generate blocks using an improved BFT algorithm, thereby achieving high transaction throughput, scalability, and security.

[0125] Orbits Ledger's core innovation lies in its Firework two-layer multi-chain consensus algorithm. This algorithm uses a layered architecture—DPOS voting to elect verification nodes and an improved BFT algorithm to generate blocks—to address the pain points of traditional single-chain consensus algorithms (PoW's high energy consumption, PBFT's poor scalability, and DPOS's insufficient security). It is well-suited to the high throughput, strong security, and scalability requirements of collaborative R&D scenarios in military research data. Table 1 shows the detailed algorithm process, core formulas, and parameters.

[0126] Table 1: Detailed Explanation of Algorithm Flow, Core Formulas, and Parameters

[0127] English terminology Chinese explanation core role Orbits Blockchain underlying ledger architecture Supports parallel operation of multiple chains, data isolation and auditability between chains, and is adaptable to various business scenarios involving collaborative development by multiple participants (data providers, R&D units). Firework Orbits Ledger's two-layer multi-chain consensus algorithm name It is divided into a "verifier election layer" and a "block generation consensus layer", balancing efficiency and security. DPOS Delegated Proof of Stake By electing validators through node voting, the high energy consumption of Proof-of-Work (PoW) is avoided, and consensus efficiency is improved. BFT Byzantine Fault Tolerance Algorithm Tolerating malicious behavior by some nodes (such as data tampering and transaction forgery) to ensure the consistency of consensus results. Improved BFT (iBFT) The optimized Byzantine fault-tolerant algorithm in this case Supports dynamic verification node sets and optimizes consensus rounds, addressing the efficiency degradation issue that arises with increasing node numbers in traditional PBFT. Main chain The core chain in the Orbits multi-chain architecture Stores verification node information, cross-chain transaction records, and consensus parameter configurations to ensure multi-chain collaboration and consistency. subchain Business chains running parallel to the main chain Each collaborative R&D task corresponds to a sub-chain, which stores the transaction and data operation records of that task, thus achieving business isolation. ValidatorNode The node selected by DPOS voting is responsible for block generation and consensus verification. It must have identity authentication (CA certificate), sufficient computing power, and no criminal record to meet the "trusted node" requirements for military data. DelegatorNode Ordinary nodes participating in DPOS voting Although they lack block generation permissions, they can influence the election of validator nodes through voting, thereby improving the degree of decentralization in consensus. Transaction throughput (TPS) The number of valid transactions processed by the blockchain network per unit time Collaborative research and development of military data requires high-frequency operation records (such as data import and sharing), necessitating high TPS support. Consensus Round Complete the full cycle of block generation and verification Improved BFT reduces consensus latency by optimizing rounds.

[0128] The core logic of the Firework algorithm is that the upper layer elects trusted verification nodes, and the lower layer efficiently generates blocks. It also supports parallel consensus between the main chain and multiple sub-chains, and is divided into three stages:

[0129] Phase 1: Initialization configuration (executed when the system starts).

[0130] When the Orbits ledger starts, it presets core parameters. The maximum number of validator nodes (N_max) is 21 by default (which can be adjusted through the main chain governance contract to adapt to the needs of a small number of trusted nodes in military scenarios); the voting weight threshold (V_th) is the minimum stake weight that delegated nodes must meet when voting (such as holding a certain number of on-chain tokens to ensure the trustworthiness of the voting nodes); the Byzantine fault tolerance threshold (f) is the maximum proportion of malicious validator nodes allowed, which satisfies the formula f<(n-1) / 3 (where n is the number of validator nodes), and the default value of this invention is f=1 / 3; the maximum number of subchains (S_max) supports 10 subchains running in parallel by default, and can be dynamically expanded according to the number of R&D tasks.

[0131] Phase 2: Validator Node Election (DPOS layer, executed on the main chain, period T=24 hours).

[0132] The goal is to elect a trusted set of validators through DPOS voting, providing the foundation for block generation. All delegated nodes initiate voting on the main chain, targeting candidate validators; each delegated node's voting weight (W) is... i ) and node credibility (C i Based on historical behavior scoring and stake i The number of on-chain tokens is positively correlated with the number of tokens on the blockchain, as shown in the following formula:

[0133] ;

[0134] Among them, W i is the voting weight of the i-th delegated node (value range [0,1]); α is the credibility weight coefficient (in this case, α=0.6 is preset to prioritize the credibility of the voting node, suitable for military scenarios); C i This is the credibility score of the i-th delegate node (value range [0,1], automatically calculated by the main chain smart contract based on historical behavior; 1.0 for no bad records); Stake i is the holding interest of the i-th delegated node (the number of on-chain certificates, used only as an auxiliary weight to avoid concentration of interests); M is the total number of delegated nodes participating in the vote; It represents the total stake of all delegated voting nodes.

[0135] Calculate the total vote weight of all candidate nodes ( Among them, Vote i,k The voting flags of the i-th delegate node for the k-th candidate node (1 = support, 0 = do not support) are sorted in descending order according to the total vote weight, and the top N_max candidate nodes are taken as the main chain verification node set (V_set); the results are put on the chain, that is, the verification node set (V_set) and its qualification information and voting results are written into the main chain block, generating an immutable verification node list for the entire network to query and verify.

[0136] Phase 3: Block generation and consensus (improved BFT layer, main chain + sub-chain executed in parallel).

[0137] The goal is to enable the validator node set to quickly generate main chain / sub-chain blocks by improving the BFT algorithm, ensuring the immutability and consistency of transaction records. Node division of labor involves randomly electing one leader node and n-1 backup nodes from the validator node set (V_set), where n is the actual number of validator nodes (n≤N_max). The leader node is responsible for proposing blocks, and the backup nodes are responsible for verification. Block proposal involves the leader node collecting transactions within the current consensus round (such as data on-chain records and usage logs), packaging them to generate candidate blocks (Block_candidate), which include a transaction list, block hash, previous block hash, timestamp, and other information.

[0138] The improved BFT consensus process (3 rounds of interaction, reduced latency) is as follows:

[0139] Round 1 (Pre-prepare): The master node broadcasts the candidate block (Block_candidate) and its own signature (generated using the master node's private key) to all backup nodes. Round 2 (Prepare): Backup nodes verify the legality of the candidate block (transaction signature, data integrity, and compliance with consensus rules). After successful verification, they broadcast a preparation confirmation message to the entire network. When the master node receives preparation confirmation messages from more than 2f+1 backup nodes (f is the fault tolerance threshold), it enters the next round. Round 3 (Commit): The master node broadcasts a commit instruction to the entire network. All validator nodes write the candidate block to their local ledger and broadcast a commit confirmation message. When the entire network receives commit confirmation messages from more than 2f+1 validator nodes, the block officially becomes effective, generating Block_valid.

[0140] Multi-chain sub-chain consensus means that the block generation process of each sub-chain is consistent with that of the main chain, but the verification nodes are allocated from V_set (each sub-chain corresponds to a dedicated subset of verification nodes to avoid resource contention). The sub-chain block hash is synchronized to the main chain for storage to ensure cross-chain sub-chain data consistency. Master node rotation means that after every K blocks are generated (K=10 in this case), a new master node is randomly elected to avoid the risk of a single master node being attacked.

[0141] Phase 4: Consensus Result Optimization and Dynamic Adjustment.

[0142] Throughput optimization requires multi-chain parallel consensus. The total throughput (TPS_total) is the sum of the throughput of each chain, as shown in the following formula:

[0143] ;

[0144] Among them, TPS main S is the main chain throughput (default ≥ 1000 TPS); S is the number of currently running child chains (S ≤ S_max); TPS sub,sIt is the throughput of the s-th subchain (each subchain defaults to ≥500 TPS).

[0145] The verification nodes are dynamically updated. If a verification node engages in malicious behavior (such as forging blocks or failing to participate in consensus), the delegated node initiates a removal proposal. After being confirmed by more than 2 / 3 of the V_set nodes, the node is removed from the verification node set, and a new node is selected from the candidate nodes.

[0146] Consensus parameter adjustment refers to the automatic adjustment of the consensus round timeout (T_timeout) by the main chain smart contract when the network load changes (such as an increase in the number of subchains or an increase in transaction frequency). The formula is as follows:

[0147] ;

[0148] Among them, T timeout This is the adjusted consensus round timeout (default T_0=500ms); TPS current This refers to the current actual network throughput; TPS target This is the target throughput (preset to 2000 TPS).

[0149] In the traditional Fireworks algorithm, the main chain validator nodes are responsible for both the time-dimensional block sequence confirmation (time consensus) and the spatial-dimensional multi-chain data consistency verification (spatial consensus). This dual responsibility leads to node resource contention and increased transaction confirmation latency under high concurrency. The optimized solution splits the consensus process into a time consensus layer and a spatial consensus layer. The two layers operate independently with resource isolation, and each performs its own function after decoupling.

[0150] The time consensus layer is only responsible for the time stamping of main chain / sub-chain blocks and the confirmation of transaction order, ensuring the uniqueness of the block time dimension. Nodes need to be selected as core verification nodes with strong computing power and low network latency, and a simplified improved BFT algorithm is adopted (only 2f+1 nodes are needed to confirm to generate a temporary timestamp). The core logic is that time consensus is completed first when a transaction is uploaded to the chain, generating a block to be confirmed with a temporary timestamp, and the transaction status can be provided to the outside world immediately without waiting for spatial consensus to be completed.

[0151] The spatial consensus layer is responsible for cross-chain sub-chain data consistency verification and final block legality confirmation, ensuring data uniformity across multiple chains in the spatial dimension. Nodes need to select verification nodes with high credibility and strong storage capacity, and use a fully improved BFT algorithm to complete the final consensus. The core logic is to asynchronously execute spatial consensus after the time consensus is completed, perform final legality verification on the timestamped blocks, and generate the final deterministic block after the verification is passed and write it into the distributed ledger.

[0152] In traditional algorithms, transactions can only be provided to the public (instant availability) after the final consensus of the block is completed (finality). In military scenarios, urgent data operations (such as adjustments to permissions for classified data) require real-time responses, and waiting for final consensus would lead to business interruptions. This optimized design is based on a time-space decoupling architecture, employing a two-layer confirmation mechanism to separate finality from instant availability. In the instant availability phase, after a transaction is confirmed by the time consensus layer and given a temporary timestamp, the smart contract immediately provides temporary available services (such as data permission adjustments and contribution calculations), and the business side can obtain the transaction results in real time. The transaction is marked as pending final confirmation on the chain, and the hash value of the temporary state is recorded to ensure traceability. In the finality phase, after the space consensus layer completes cross-chain consistency verification, it marks the transaction pending final confirmation as final confirmation and updates the block state. If the space consensus detects a transaction anomaly, such as cross-chain data inconsistency, it automatically rolls back the temporary state and triggers an anomaly alarm, notifying the verification node to audit. The rollback record is recorded on the chain and cannot be tampered with.

[0153] The traditional Firework algorithm uses a single-level verification node with consistent permissions across all nodes. However, high-secret data transactions in military scenarios require nodes with higher credibility to participate in consensus, and a single level cannot meet the needs of hierarchical management.

[0154] Hierarchical governance of nodes requires dividing verification nodes into three levels, classified according to confidentiality level / trustworthiness:

[0155] Layer L1 (Core Nodes): Military-certified trusted nodes (20%), participating only in spatial consensus for high-secret data (Top Secret / Confidential), possessing final veto power; Layer L2 (Regular Nodes): compliant and registered R&D unit nodes (50%), participating in the full-process consensus for secret-level data and the time consensus for high-secret data; Layer L3 (Alternate Nodes): Backup verification nodes (30%), automatically filling in when a node fails, ensuring consensus continuity. The permissions and consensus participation scope of nodes at different levels are solidified through smart contracts; cross-level operations require L1 node signature authorization.

[0156] The dynamic fault tolerance mechanism requires adjusting the Byzantine fault tolerance threshold (f) based on the node level. Specifically, for L1 layer node consensus: f < 1 / 4 (only tolerating ≤25% malicious nodes, suitable for high-density data); for L2 layer node consensus: f < 1 / 3 (maintaining the original fault tolerance threshold, suitable for ordinary data); real-time monitoring of node behavior, if a node fails three consecutive verifications, it will automatically downgrade (e.g., L1 → L2) and trigger CA certificate re-authentication.

[0157] Traditional algorithms verify each transaction individually. In military scenarios, where large amounts of data are uploaded to the blockchain, such as multiple R&D records being stored simultaneously, verifying each transaction individually leads to inefficiency. The optimized design is as follows: Transactions are batch-packaged, meaning transactions from the same business scenario are grouped into transaction groups based on time windows (e.g., 50ms), with each group containing ≤100 transactions; consensus results are pre-committed, meaning the time consensus layer generates a temporary timestamp for the entire transaction group, directly pre-committing the temporary state without requiring individual confirmation; batch verification logic, meaning the spatial consensus layer performs batch hash verification on the transaction groups, only needing to verify the Merkle root of transactions within the group to confirm the integrity of all transactions, eliminating the need for individual verification.

[0158] The infrastructure layer provides computing, storage, and network resources for the application layer, enhancement component layer, and blockchain core layer to adapt to the needs of different deployment environments.

[0159] It needs to be explained that the infrastructure layer is the hardware and resource support for the system's operation. The infrastructure layer is the physical / virtual resource foundation of the system, providing computing, storage, and network resources to adapt to the needs of different deployment environments. Specifically, it includes basic support and resource management. Basic support is used for resource carriers such as public cloud, private cloud, container cloud, and virtualization, and supports elastic scaling. Resource management is used for virtual management (virtual machine / container scheduling), load balancing (resource allocation on demand), and resource control (resource usage monitoring and quotas).

[0160] In this optional embodiment, the infrastructure layer includes a basic support unit and a resource management unit.

[0161] It needs to be explained that, for example Figure 1 As shown, the overall architecture of the system is divided into four layers: application layer, enhancement component layer, blockchain core layer, and infrastructure layer. Each layer independently encapsulates functions and collaborates through standardized interfaces, which not only ensures the realization of business needs such as data ownership confirmation and notarization, but also takes into account the security, scalability, and infrastructure compatibility of the blockchain.

[0162] The trust-enhancing capabilities of blockchain technology are crucial in data ownership verification and contribution calculation scenarios. In traditional centralized data management systems, data ownership verification and protection typically rely on centralized management institutions or third-party organizations. This approach carries the risk of single points of failure and requires trust in these institutions. Blockchain technology, through its decentralized nature and distributed consensus mechanism, can provide more reliable data ownership verification and protection.

[0163] By leveraging blockchain technology, data ownership and usage rights can be programmed through smart contracts, forming an immutable data ownership chain. Each data owner can obtain a unique identity on the blockchain and sign and encrypt the data using a private key. This ensures the authenticity and integrity of the data, preventing anyone from tampering with it or impersonating another person.

[0164] Furthermore, blockchain technology can provide a more flexible and secure mechanism for data access control. Through smart contracts, rules and permissions for data usage can be defined, allowing only users who meet specific conditions to access and use the data. This effectively protects data privacy and security, preventing unauthorized access and misuse.

[0165] In many scenarios, it is necessary to evaluate and calculate the contributions of participants. Traditional contribution calculation methods often rely on the subjective judgment of centralized evaluation institutions or individuals, which leads to unfairness and unreliability. Blockchain technology, however, can achieve fair, transparent, and trustworthy contribution calculation through smart contracts and decentralized consensus mechanisms.

[0166] On a blockchain, a smart contract can be established to define the rules for calculating contributions and the reward mechanism for participants. A participant's contribution can be recorded and verified through transactions and actions on the blockchain, such as code submissions, problem solving, and task completion. These contributions can be written into the blockchain's immutable ledger, ensuring the authenticity and credibility of the data. Through smart contracts and consensus mechanisms, rewards can be automatically calculated and distributed, avoiding interference and unfair practices by centralized institutions or individuals. Participants can prove their contributions through data on the blockchain and receive corresponding rewards, thereby incentivizing more people to participate in projects or tasks. The trust-enhancing capabilities of blockchain technology can provide a more secure, reliable, and fair solution in data ownership protection and contribution calculation scenarios. Through mechanisms such as decentralization, distributed consensus, and smart contracts, it protects the authenticity and integrity of data while achieving fair contribution calculation and reward distribution.

[0167] Blockchain's traceability provides a complete record of actions and data operations throughout the contribution proof process. Through blockchain, the source and destination of each contribution record can be traced, enabling comprehensive tracking of the entire contribution process. This traceability enhances the credibility of contribution proofs. Blockchain technology achieves traceability of key actions and data in collaborative R&D tasks through a distributed ledger mechanism. By recording every transaction and information flow, blockchain technology establishes a transparent and immutable distributed ledger. All participants can share and view transaction records, thus solving the problem of information asymmetry and improving information credibility. Simultaneously, the timestamp function ensures the order and time of transaction records; each transaction record is assigned a unique timestamp, proving the exact time the transaction occurred. The immutability of timestamps guarantees the authenticity and credibility of transaction records, giving blockchain data strong traceability capabilities. Furthermore, blockchain's traceability also benefits from its decentralized nature. Traditional centralized systems are susceptible to single points of failure; if the central node fails, the entire system's data may be lost or tampered with. The decentralized nature of blockchain allows data to be stored across multiple nodes, each with a complete copy of the ledger. This approach avoids the risk of single points of failure, ensuring data reliability and security.

[0168] To enhance the traceability of blockchain, hash algorithms can be introduced to transform raw data into unique fingerprints, which can verify the integrity and authenticity of the data. Automating transactions and data management using smart contracts can reduce human intervention and errors. Encryption technology can protect data privacy and security, preventing unauthorized access and tampering. Table 2 shows a comparison of the implementation effects of this solution with other methods.

[0169] Table 2: Comparison of the Implementation Effects of the Invention with Other Methods

[0170] Comparison Dimensions This solution (blockchain + smart contracts + multi-dimensional quantification) Traditional centralized data management methods Single blockchain ownership confirmation method (without contribution calculation) Traditional manual / semi-automated contribution assessment methods Data security (tamper protection) Blockchain is immutable and encrypted using national cryptographic algorithms; access is limited to authorized nodes; there are no records of data leakage. Centralized storage is vulnerable to attacks, carries a high risk of data tampering, and has a history of frequent data breaches. While data ownership verification and notarization are implemented, there is a lack of granular access control, leading to security vulnerabilities during the sharing process. Data storage is scattered, manual records are easily tampered with, and access control is chaotic. Data ownership clarity Smart contracts define ownership / usage rights, and the entire operation process is traceable on the blockchain, eliminating any ownership disputes. Ownership relies on manual registration, records are easily lost, and ownership becomes ambiguous when multiple parties collaborate. Only the initial ownership is clearly defined; the ownership of usage rights after data transfer remains unclear. Relying on subjective judgments, without objective evidence for tracing back to the source. Fairness in contribution calculation Multi-dimensional quantitative indicators + automatic execution of smart contracts, no subjective intervention, and results verified by network-wide consensus. Without a standardized contribution calculation mechanism, relying solely on manual evaluation, fairness cannot be guaranteed. Focusing solely on rights confirmation without designing a contribution calculation module makes it impossible to quantify the value of participating parties. The combination of single-dimensional assessment and subjective human scoring leads to significant biases and frequent disputes over fairness. Increase in willingness to share data Controllable sharing and protection of contribution rights have significantly increased the willingness of data providers to actively share data. Shared data is prone to misuse, providers lack trust, and the willingness to share is low. Solving ownership issues without guaranteeing contributor rights limits the willingness to share. Without a mechanism to protect rights and interests, providers worry about data misuse, resulting in low enthusiasm for sharing. Transaction / operation throughput (TPS) ≥1500TPS (Firework two-layer consensus algorithm + multi-chain parallelism, adapted to high-frequency data operations) ≤300TPS (Centralized architecture bottleneck, response latency during high-frequency operations) ≤800TPS (single-chain consensus mechanism, throughput is limited, congestion occurs when multiple tasks are concurrent) ≤100TPS (Manual intervention is cumbersome and has extremely low operational efficiency) Contribution calculation time <100ms / task, smart contracts execute automatically without manual intervention. Manual statistics and review are time-consuming. Without a computation module, contribution quantification cannot be completed. Multiple manual interventions at each stage, resulting in a lengthy process. Traceability Timestamps + distributed ledger ensure that the operation trajectory cannot be tampered with. Relying on central node logs, which are prone to loss or tampering. Only ownership changes are recorded; operational details are not fully traceable. Manual records are scattered and lack a unified traceability mechanism, making it impossible to reconstruct the complete process. System scalability Supports 10 parallel subchains, can dynamically expand with the number of R&D tasks, and node expansion has no performance loss. Centralized architectures have high expansion costs, require system reconstruction for new business applications, and have poor scalability. Single-chain architecture supports node scaling, but suffers from poor business isolation and performance degradation under multi-task concurrency. The manual workflow is fixed, and new business requires redesigning the evaluation rules, resulting in poor adaptability. abnormal data processing efficiency Smart contracts automatically identify and remove abnormal data in real time, without requiring manual intervention. Manually checking for abnormal data is inefficient and prone to omissions. Abnormal data requires manual verification, and the processing procedure is cumbersome. Manually checking data one by one results in low accuracy in anomaly detection and long processing time. Military scenario adaptability It supports national cryptographic algorithms, high-security data isolation storage, and trusted node authentication, fully complying with military data security requirements. Without a classified information adaptation mechanism, data security cannot meet the needs of military scenarios. It only supports basic security protection and does not have a dedicated solution for high-security data. Without security protection and classified information control, it does not meet the sensitive characteristics of military data.

[0171] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A blockchain-based data ownership protection and contribution calculation system, characterized in that, The system comprises: an application layer, an enhancement component layer, a blockchain core layer, and an infrastructure layer; among which, The application layer is used to provide trusted military research data based on the core blockchain layer, so as to realize data storage, full-process operation traceability, multi-dimensional contribution calculation and auditing functions for collaborative research and development scenarios. The enhancement component layer connects to both the application layer and the blockchain core layer, and is used to provide management services, data scheduling, user access, and security enhancement support for the application layer. The core layer of the blockchain runs on top of the resources provided by the infrastructure layer, and is used to provide basic blockchain capabilities such as supporting multi-chain collaboration, high-throughput consensus, automatic execution of smart contracts, national cryptographic-level security protection, and trusted node management. The infrastructure layer provides computing, storage, and network resources for the application layer, enhancement component layer, and blockchain core layer to adapt to the needs of different deployment environments.

2. The blockchain data ownership protection and contribution calculation system according to claim 1, characterized in that, The application layer includes a data storage unit, a process traceability unit, a contribution calculation unit, and a data auditing unit; wherein... The data storage unit is used to store the hash value and ownership information of military research data on the blockchain. The process traceability unit is used to record and display the various operational trajectories of military research data throughout its entire lifecycle; The contribution calculation unit is used to call the smart contract unit of the blockchain core layer to calculate the military research data based on multi-dimensional quantitative indicators and output the quantitative contribution result. The data auditing unit is used to conduct compliance reviews and trace the use of military research data based on immutable on-chain operation records.

3. The blockchain data ownership protection and contribution calculation system according to claim 2, characterized in that, The smart contract unit that invokes the core layer of the blockchain calculates military research data based on multi-dimensional quantitative indicators, and outputs quantitative contribution results including: Collect and verify the original data of all parties involved in the military research data stored on the blockchain to obtain valid data; The effective data is standardized according to the data provision, workload, data usage frequency, and multi-party evaluation dimensions to generate indicator values ​​for each dimension. The contribution value is generated by weighting the values ​​of each dimension indicator based on preset weights. By using smart contracts, the final contribution value and calculation process data are written into the blockchain as proof of contribution.

4. The blockchain data ownership protection and contribution calculation system according to claim 1, characterized in that, The enhanced component layer includes a management service unit, a data management unit, a user access unit, and a privacy protection unit; wherein... The management service unit provides system configuration management, node status monitoring, and log auditing functions. The data management unit is used for segmented storage, archiving, and synchronous scheduling of military research data; The user access unit is used to perform multi-terminal user authentication and to allocate permissions based on the authentication results. The privacy protection unit is used to enhance the privacy and security of military research data through proxy re-encryption technology.

5. The blockchain data ownership protection and contribution calculation system according to claim 4, characterized in that, The privacy and security enhancement processing of military research data through proxy re-encryption technology includes: Symmetric encryption is applied to the shared military research data, and the encrypted military research data and encryption key information are stored in the cloud and on the blockchain, respectively. When it is necessary to authorize other participants to access the device, the sender uses the proxy re-encryption algorithm to generate a re-encryption key. During the decryption and access process by the recipient, dynamic verification is performed based on preset permission conditions on the blockchain, and military research data decryption and use are allowed when the triple dynamic permission constraints are met.

6. The blockchain data ownership protection and contribution calculation system according to claim 5, characterized in that, The triple dynamic permission constraints include time-based dynamic permissions, event-based dynamic permissions, and attribute-based dynamic permissions; among which... Time-based dynamic permissions are used to control the validity period of data access based on a preset time window; Event-based dynamic permissions are used to bind data access permissions to on-chain events; Attribute-based dynamic permissions are used to verify the recipient's on-chain identity attributes.

7. The blockchain data ownership protection and contribution calculation system according to claim 1, characterized in that, The core layer of the blockchain includes a distributed ledger unit, a consensus mechanism unit, a smart contract unit, a cryptographic algorithm unit, a data storage unit, a network protocol unit, and a permitted access unit; among which, Distributed ledger unit, used to utilize the Orbits multi-chain ledger structure to achieve inter-chain isolation and auditable storage of different business data; The consensus mechanism unit is used to elect verification nodes based on the Firework two-layer consensus algorithm and generate blocks by combining the DPOS mechanism with the improved BFT algorithm to support high throughput and multi-chain parallel consensus. Smart contract units are used to execute data ownership rules and calculate contributions based on trusted on-chain records; The encryption algorithm unit supports Chinese national cryptographic algorithms and international cryptographic algorithms to ensure the security of data transmission and storage; The data storage unit is used to achieve efficient persistence of structured business data and on-chain transaction records by utilizing a hybrid storage architecture that combines on-chain key-value databases and off-chain associated databases. The network protocol unit is used to realize inter-node communication based on node communication protocols and to ensure the efficiency and reliability of network transmission by using data serialization format. The licensed access unit is used to authenticate and control the access of network participating nodes through CA certificates and license credentials.

8. The blockchain data ownership protection and contribution calculation system according to claim 7, characterized in that, The method of using the Firework two-layer consensus algorithm, electing verification nodes based on the DPOS mechanism, and generating blocks by combining the improved BFT algorithm includes: Initialize consensus parameters, which include the maximum number of validator nodes, voting weight threshold, Byzantine fault tolerance threshold, and upper limit on the number of subchains; In Firework's DPOS layer, a set of main chain validator nodes is elected based on consensus parameters and the voting weights of delegated nodes, and the election results are stored on the chain. The improved BFT layer in Firework selects master nodes and backup nodes from the main chain verification node set, and completes block proposal, verification and adjustment through three rounds of interaction: pre-preparation, preparation and submission.

9. The blockchain data ownership protection and contribution calculation system according to claim 8, characterized in that, The Firework two-layer consensus algorithm also includes a time and space consensus decoupling mechanism, a node hierarchical governance and dynamic fault tolerance mechanism, and a consensus result pre-submission and batch verification mechanism; among which... The time and space consensus decoupling mechanism is used to decouple the consensus responsibilities of the improved BFT layer into time consensus and space consensus; wherein, the time consensus layer adds temporary timestamps to transactions to provide an instantly available state, and the space consensus layer asynchronously performs cross-chain data verification to generate a final deterministic block; The node hierarchical governance and dynamic fault tolerance mechanism is used to divide nodes into different levels according to their confidentiality level or trustworthiness, configure differentiated Byzantine fault tolerance thresholds for each level, and realize dynamic adjustment of the level based on node behavior monitoring. The consensus result pre-submission and batch verification mechanism is used to package multiple transactions within a preset time window into a transaction group. The time consensus layer pre-submits the transaction group as a whole and generates a temporary timestamp, and then the spatial consensus layer performs batch integrity verification of the transaction group.

10. The blockchain data ownership protection and contribution calculation system according to claim 1, characterized in that, The infrastructure layer includes basic support units and resource management units; wherein... Basic support units are used to provide underlying operating resources for public cloud, private cloud, container cloud and virtualization environments; The resource management unit is used for virtualization management, load balancing, and resource control of underlying operating resources to support the deployment and dynamic scheduling of military research data-related services.

Images