Code version control method and device based on alliance chain, equipment and medium

Abstract

The invention discloses a code version control method and device based on an alliance chain, equipment and a medium, and relates to the technical field of code version control, and the method comprises the steps: uploading a corresponding new code file version to a preset distributed code storage system after a target code submission request is received, enabling the distributed code storage system to submit a hash value for the content generation code; generating a code review task based on the code submission hash value, and performing review through an alliance chain network; whether submission is approved or not is judged according to the review result, and after submission is judged to be approved, packaging is carried out based on the review result and the code submission hash value, so that a newly-added candidate block is generated; proposing the newly added candidate block to other nodes based on a consensus protocol, so that the other nodes can perform verification; and judging whether verification is passed or not according to a verification result, linking the newly-added candidate block to the alliance chain network after judging that the verification is passed, and performing code submission recording for the target code submission request.

Description

Technical Field

[0001] This invention relates to the field of code version control technology, and in particular to a code version control method, apparatus, device and medium based on consortium blockchain. Background Technology

[0002] As software projects continue to develop, the corresponding code versions will be continuously iterated and updated. Therefore, traditional code version control systems are usually required for code version auditing and management. However, because code version control systems centralize code review and submission permissions, they are vulnerable to single points of attack or malicious internal operations, which may lead to unauthorized code merging or malicious code injection. Furthermore, the storage and management of code submission and approval history relies on centralized servers, posing risks of data loss, tampering, or difficulties in audit tracing. In other words, existing code version control systems have limitations in terms of security, transparency, and auditability.

[0003] In conclusion, how to solve the security and audit transparency issues of code version control caused by the limitations of current traditional code version control systems is a pressing technical problem that needs to be addressed. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a code version control method, apparatus, device, and medium based on a consortium blockchain, which can solve the security and audit transparency problems of code version control caused by the limitations of current traditional code version control systems. The specific solution is as follows:

[0005] Firstly, this application provides a code version control method based on a consortium blockchain, applied to the master node of a consortium blockchain network, wherein the master node is any one of several review nodes in the consortium blockchain network; wherein the method includes:

[0006] Upon receiving a target code submission request, the newly added code file version corresponding to the target code submission request is uploaded to a preset distributed code storage system, so that the distributed code storage system generates a corresponding code submission hash value for the content of the newly added code file version and sends the code submission hash value to the master node;

[0007] Based on the obtained code submission hash value, a corresponding code review task is generated, and the code review task is reviewed through the consortium blockchain network to obtain the corresponding review result;

[0008] Based on the review results, it is determined whether the new code file version is approved for submission. After approval is determined, the code file is packaged based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0009] Based on the consensus protocol of the consortium blockchain network, the newly added candidate block is proposed to other nodes among the several review nodes, excluding the master node, so that the other nodes can verify the newly added candidate block and feed back the verification result to the master node;

[0010] The received verification result is used to determine whether the newly added candidate block has passed verification. After it is determined that the verification has passed, the newly added candidate blockchain is connected to the consortium blockchain network, and the corresponding code submission record is made for the target code submission request.

[0011] Optionally, before uploading the new code file version corresponding to the target code submission request to the preset distributed code storage system, the method further includes:

[0012] Determine whether there are any other code submission requests besides the target code submission request, and obtain the corresponding determination result;

[0013] If the determination result indicates that there are other code submission requests, then the code to be submitted corresponding to the target code submission request is determined, and it is determined whether there are conflicting code submission requests among the other code submission requests whose code is consistent with the code to be submitted;

[0014] If it is determined that there is a conflicting code submission request among the other code submission requests, then a preset version control tool is used to merge the conflicting code submission request and the target code submission request to obtain the merged target code submission request.

[0015] Optionally, uploading the new code file version corresponding to the target code submission request to a preset distributed code storage system, so that the distributed code storage system generates a corresponding code submission hash value for the content of the new code file version, and sends the code submission hash value to the master node, includes:

[0016] The newly added code file version corresponding to the target code submission request is uploaded to the review area of ​​the preset distributed code storage system, so that the distributed code storage system marks the version status of the newly added code file version in the review area as a status indicating a review pending status, generates a corresponding code submission hash value for the content of the newly added code file version, and sends the code submission hash value to the master node;

[0017] Accordingly, after verifying the newly added candidate blockchain and connecting it to the consortium blockchain network, the process further includes:

[0018] A message notification indicating that the newly added code file version has been confirmed and submitted is sent to the distributed code storage system, so that the distributed code storage system transfers the newly added code file version from the pending review area to the target storage area of ​​the distributed code storage system, and marks the version status as a confirmed status.

[0019] Optionally, each of the several review nodes holds a threshold signature private key share, which is a private key share obtained by dividing the threshold signature private key generated based on the threshold signature technology.

[0020] Accordingly, the code review task is generated based on the obtained code submission hash value, and the code review task is reviewed through the consortium blockchain network to obtain the corresponding review results, including:

[0021] Obtain the code submission hash value and generate a code review task containing the code submission hash value;

[0022] The code review task is broadcast to the target review node through the consortium blockchain network. The target review node reviews the newly added code file version based on preset review criteria. Upon passing the review, it uses its threshold signature private key share to digitally sign the code submission hash value, generating a partial signature. The review result, including the partial signature, is then fed back to the master node. The target review node is the node among the plurality of review nodes that is related to the newly added code file version.

[0023] Obtain several review results fed back by several target review nodes.

[0024] Optionally, the step of determining whether the new code file version is approved for submission based on the review result, and after determining that the submission is approved, packaging based on the review result and the code submission hash value to generate a new candidate block corresponding to the new code file version, includes:

[0025] Count the number of partial signatures in several of the aforementioned review results;

[0026] The number of partial signatures is compared with a preset threshold value to obtain the corresponding comparison result;

[0027] If the comparison result indicates that the number of partial signatures is higher than the preset threshold, then the new code file version is approved for submission, and the threshold signature technology is used to aggregate several partial signatures into a target threshold signature.

[0028] The target threshold signature and the code submission hash are packaged together to generate a new candidate block corresponding to the new code file version.

[0029] Optionally, the step of using the received verification result to determine whether the newly added candidate block passes verification, and after determining that the verification has passed, connecting the newly added candidate blockchain to the consortium blockchain network, and recording the corresponding code submission for the current target code submission request, includes:

[0030] Receive several verification results fed back by the other nodes, and determine the first number of the other nodes;

[0031] Statistical analysis is performed on several of the aforementioned verification results to determine the number of second nodes among the other nodes, where each verification result represents a node that has passed verification.

[0032] The proportion of nodes that pass the characterization verification is determined based on the number of the second node and the number of the first node, and the proportion of nodes is compared with a preset node proportion threshold.

[0033] If the node ratio is higher than the preset node ratio threshold, the newly added candidate block is determined to have passed verification, and the newly added candidate blockchain is connected to the end of the consortium blockchain network, and a corresponding code submission record is made for the target code submission request.

[0034] Optionally, the code version control method based on consortium blockchain further includes:

[0035] Upon receiving a target code version query request, the corresponding code to be queried is determined based on the target code version query request;

[0036] The code query task containing the code to be queried is broadcast to the other nodes, so that the other nodes can determine the code version hash value of the target code file version based on the code to be queried in the code query task, and feed back the code version hash value to the master node; the target code file version is the latest version that has been approved and submitted among several historical code file versions corresponding to the current code to be queried;

[0037] The system receives several code version hash values ​​fed back by several other nodes, and summarizes the occurrence counts of several code version hash values ​​to determine whether a target code version hash value exists among the several code version hash values ​​based on the occurrence counts; the target code version hash value is the code version hash value whose occurrence count exceeds a preset hash value count threshold among the several code version hash values.

[0038] If the target code version hash value is determined to exist, a response is given based on the target code version hash value in response to the target code version query request.

[0039] Secondly, this application provides a code version control device based on a consortium blockchain, applied to the master node of a consortium blockchain network, wherein the master node is any one of a plurality of review nodes in the consortium blockchain network; wherein the device includes:

[0040] The version upload module is used to upload the new code file version corresponding to the target code submission request to a preset distributed code storage system after receiving the target code submission request. The distributed code storage system generates a corresponding code submission hash value for the content of the new code file version and sends the code submission hash value to the master node.

[0041] The task review module is used to generate corresponding code review tasks based on the obtained code submission hash value, and to review the code review tasks through the consortium blockchain network to obtain corresponding review results.

[0042] The result packaging module is used to determine whether the new code file version is approved for submission based on the review results, and after determining that the submission is approved, to package the code file based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0043] The block proposal module is used to propose the new candidate block to other nodes among the several review nodes, excluding the master node, based on the consensus protocol of the consortium blockchain network, so that the other nodes can verify the new candidate block and feed back the verification result to the master node.

[0044] The submission record module is used to determine whether the newly added candidate block has passed verification based on the received verification result, and after determining that the verification has passed, to connect the newly added candidate blockchain to the consortium blockchain network, and to make corresponding code submission records for the target code submission request.

[0045] Thirdly, this application provides an electronic device, comprising:

[0046] Memory, used to store computer programs;

[0047] A processor is used to execute the computer program to implement the aforementioned code version control method based on consortium blockchain.

[0048] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned code version control method based on a consortium blockchain.

[0049] In this application, upon receiving a target code submission request, the new code file version corresponding to the target code submission request is uploaded to a preset distributed code storage system. The distributed code storage system generates a corresponding code submission hash value for the content of the new code file version and sends the code submission hash value to the master node. Based on the obtained code submission hash value, a corresponding code review task is generated, and the code review task is reviewed through the consortium blockchain network to obtain a corresponding review result. Based on the review result, it is determined whether the new code file version is approved for submission. If approval is granted, the code file version is packaged based on the review result and the code submission hash value to generate a new candidate block corresponding to the new code file version. Based on the consensus protocol of the consortium blockchain network, the new candidate block is proposed to other nodes among the several review nodes besides the master node, so that the other nodes can verify the new candidate block and feed back the verification result to the master node. Using the received verification result, it is determined whether the new candidate block passes verification. If verification passes, the new candidate block is connected to the consortium blockchain network, and a corresponding code submission record is made for the current target code submission request. As can be seen from the above, after receiving the target code submission request, the master node of the consortium blockchain network in this application first uploads the corresponding new code file version to the distributed code storage system. The distributed code storage system generates the corresponding code submission hash value and feeds it back to the master node. The master node generates a code review task based on this hash value and reviews the code review task through the consortium blockchain network to obtain the corresponding review result. Then, based on the review result, it determines whether the new code file version can be submitted. If so, it packages the review result and the code submission hash value to generate a new candidate block. Then, it proposes the new candidate block to other review nodes for verification through the consensus protocol of the consortium blockchain network. Based on the verification result, it determines whether the new candidate block passes the verification. If so, it connects the new candidate blockchain to the consortium blockchain network and records this code submission. In this way, through the process described above in this application, the security and integrity of code storage are ensured by leveraging a distributed storage system; the review and consensus mechanism of the consortium blockchain network is used to achieve decentralized review of code submissions, avoiding the risks brought about by single-node decision-making, ensuring the standardization, reliability and traceability of code submissions, improving the transparency and security of code management, and thus solving the security and audit transparency problems of code version control caused by the limitations of current traditional code version control systems. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0051] Figure 1 This application discloses a flowchart of a code version control method based on a consortium blockchain.

[0052] Figure 2 This is a schematic diagram of the process framework of a code version control method based on consortium blockchain disclosed in this application;

[0053] Figure 3 This is a schematic diagram of a code version control device based on a consortium blockchain disclosed in this application.

[0054] Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] As software projects continue to develop, the corresponding code versions will be continuously iterated and updated. Therefore, traditional code version control systems are usually required for code version auditing and management. However, because code version control systems centralize code review and submission permissions, they are vulnerable to single points of attack or malicious internal operations, which may lead to unauthorized code merging or malicious code injection. Furthermore, the storage and management of code submission and approval history relies on centralized servers, posing risks of data loss, tampering, or difficulties in audit tracing. In other words, existing code version control systems have limitations in terms of security, transparency, and auditability.

[0057] To overcome the aforementioned technical problems, this application provides a code version control method based on consortium blockchain to address the security and audit transparency issues caused by the limitations of current traditional code version control systems.

[0058] See Figure 1As shown in the figure, this invention discloses a code version control method based on a consortium blockchain, applied to the master node of a consortium blockchain network, wherein the master node is any one of several review nodes in the consortium blockchain network; wherein, the method includes:

[0059] Step S11: After receiving the target code submission request, upload the new code file version corresponding to the target code submission request to the preset distributed code storage system, so that the distributed code storage system generates a corresponding code submission hash value for the content of the new code file version, and sends the code submission hash value to the master node.

[0060] In this embodiment, after receiving a target code submission request, the master node of the consortium blockchain network determines the new code file version corresponding to the target code submission request and uploads the new code file version to a preset distributed code storage system. The distributed code storage system then generates a corresponding code submission hash value for the content of the new code file version and sends the code submission hash value to the master node. The master node is any one of several review nodes in the consortium blockchain network, dynamically elected from among the review nodes by the consortium blockchain network's consensus mechanism, such as Raft (a consensus algorithm) or PBFT (Practical Byzantine Fault Tolerance), algorithms suitable for consortium blockchain scenarios. The target code submission request is a request initiated by a code developer through a target client connected to the consortium blockchain network. The code submission hash value can be a Merkle root hash value.

[0061] Specifically, the newly added code file version corresponding to the target code submission request is uploaded to the review area of ​​a preset distributed code storage system. The distributed code storage system then marks the version status of the newly added code file version in the review area as indicating a review pending state, generates a corresponding code submission hash value for the content of the newly added code file version, and sends the code submission hash value to the master node. That is, after receiving the target code submission request, the master node uploads its corresponding newly added code file version to the review area of ​​the preset distributed code storage system. The distributed code storage system then marks the version status of the newly added code file version in the review area as indicating a review pending state, calculates the code submission hash value for the content of the newly added code file version, and sends it to the master node.

[0062] It should be noted that the review nodes described in this application represent entities with code review authority. Each review node is operated by one or a group of authorized code reviewers, and their number and identities can be dynamically adjusted according to organizational needs, but typically at least three are required to ensure the effective operation of the consensus algorithm. Each block of the consortium blockchain network contains one or more verified code commit records. The distributed code storage system is responsible for the actual storage, versioning management, and efficient retrieval of code files, including an indexing system and a file storage system. The indexing system maintains the mapping between code commits and their containing files. It stores the global hash of each successful commit, its corresponding list of file hashes, and a Merkle tree structure. It can utilize a high-performance distributed key-value store, such as TiKV (a distributed transactional key-value database), etcd (a distributed unique key-value store), or a database optimized for content addressing. The file storage system stores the actual code files for all versions. Files are typically stored using their content hashes as unique identifiers, i.e., content-addressable storage (CAS). This naturally supports data deduplication and ensures file integrity. It can be built upon mature distributed file systems, such as IPFS (a hypermedia storage and transmission protocol), Ceph (a distributed storage system), or object storage services. Furthermore, to ensure data persistence and resilience against single points of failure, the distributed code storage system (including indexes and files) should be deployed in a distributed cluster, with redundant backups and synchronization implemented across geographically dispersed nodes. Since indexing and retrieval are primarily performed through content hashes, data consistency management is relatively simplified, but an effective synchronization mechanism is still required, such as asynchronous replication combined with eventual consistency checks to ensure the updates of each replica. The master node is responsible for coordinating transactions within a specific period, such as code commit hashing and reviewing signatures, packaging new blocks, and proposing them to other nodes to reach consensus. Understandably, the role of the master node should be rotated periodically to enhance decentralization and system robustness.

[0063] It should be noted that, since multiple people may modify the same code segment in parallel, text merge conflicts may occur, leading to code storage anomalies. Therefore, upon receiving the target code commit request, it is necessary to resolve code merge conflicts. The processing flow is as follows: determine whether there are other code commit requests besides the target code commit request, and obtain the corresponding judgment result; if the judgment result indicates that other code commit requests exist, determine the code to be committed corresponding to the target code commit request, and determine whether there are conflicting code commit requests among the other code commit requests whose code is consistent with the code to be committed; if it is determined that there is a conflicting code commit request among the other code commit requests, then use a preset version control tool to merge the conflicting code commit request and the target code commit request to obtain the merged target code commit request. That is, first determine whether there are other code submission requests besides the target code submission request. If so, it is necessary to determine whether there is a code conflict, determine the code to be submitted corresponding to the target code submission request, and determine whether there are conflicting code submission requests among the other code submission requests corresponding to the code to be submitted. If so, the merge and conflict resolution functions provided by the target client's preset version control tool, such as Git (a version control system), are used to merge the requests to obtain the merged and conflict-resolved target code submission request, which is then treated as a brand new submission for review and on-chain process. In this way, this embodiment improves data security by storing code using a unique hash value of the content and supports data deduplication to ensure file integrity. It employs a distributed cluster deployment of a distributed code storage system, achieving data redundancy backup and synchronization among geographically dispersed nodes, ensuring data persistence and resistance to single points of failure. Regularly rotating the role of the master node enhances decentralization and system robustness. Utilizing all nodes in the consortium blockchain network to jointly record and maintain key information on all code submissions and reviews ensures the integrity and immutability of historical records; the loss or corruption of data on a single or a few nodes will not affect the integrity and availability of the overall historical record. Considering the possibility of text merging conflicts when multiple users modify the same code segment concurrently, a pre-set version control tool is used to resolve conflicts, preventing code storage anomalies.

[0064] Step S12: Generate a corresponding code review task based on the obtained code submission hash value, and review the code review task through the consortium blockchain network to obtain the corresponding review result.

[0065] In this embodiment, the master node obtains the code submission hash value sent by the distributed code storage system and generates a corresponding code review task based on the code submission hash value. The newly added code file version is then reviewed through the consortium blockchain network based on the code review task to obtain the corresponding review result. The code review task includes the code submission hash value, submitter information, submission description, and code access path (pointing to its location in the distributed code storage system).

[0066] It should be noted that, to avoid single points of control and enhance the security of code version control, this embodiment can distribute the approval authority for code merging through a threshold signature mechanism. That is, each of the several review nodes holds a threshold signature private key share, which is a private key share obtained by dividing the threshold signature private key generated based on threshold signature technology. Correspondingly, the process of generating a code review task and reviewing it through the consortium blockchain network is as follows: Obtain the code submission hash value and generate a code review task containing the code submission hash value; broadcast the code review task to the target review node through the consortium blockchain network, so that the target review node reviews the newly added code file version based on preset review criteria, and after determining that the review is passed, digitally signs the code submission hash value using the held threshold signature private key share to generate a corresponding partial signature, and feeds back the review result containing the partial signature to the master node; the target review node is the node among the several review nodes related to the newly added code file version; obtain several review results fed back by the several target review nodes. The preset review criteria include, but are not limited to, code quality, functionality, security, and compliance. That is, each review node securely holds a share of a private key generated using threshold signature technology. After obtaining the code submission hash, the master node generates a code review task containing it and broadcasts it through the consortium blockchain network to target review nodes associated with the new code file version. The target review nodes then review the new code file version based on the preset review criteria and, upon determining that the review is passed, digitally sign the code submission hash using their held threshold signature private key share to generate a partial signature. This partial signature is then packaged into a review result and fed back to the master node, allowing the master node to obtain several review results from the target review nodes.

[0067] It should be further noted that this embodiment needs to ensure that the number of active review nodes always meets the minimum requirements of the threshold signature technology, that is, it is not less than the preset threshold value. When the set of review nodes, which includes the aforementioned review nodes, changes, especially when the total number of signers or the preset threshold value needs to be adjusted, it is necessary to regenerate and securely distribute new threshold signature key shares. Specifically, this needs to be executed through consensus among all (or the vast majority of) existing nodes on the consortium blockchain to ensure a smooth and secure transition of the key system without affecting the historical data already recorded on the consortium blockchain. In this way, this embodiment, by distributing the approval authority for code merging through the threshold signature mechanism, can avoid single points of control, enhance the security of code version control, and greatly improve the defense capabilities against internal malicious behavior such as administrator abuse of power, reviewers acting alone, and external targeted attacks. When the set of review nodes changes, regenerating and distributing new threshold signature key shares can ensure a smooth and secure transition of the key system without affecting the historical data already recorded on the consortium blockchain.

[0068] Step S13: Determine whether the new code file version is approved for submission based on the review results, and after determining that the submission is approved, package the code file based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0069] In this embodiment, after obtaining the review result, the master node determines whether the new code file version has been commented and submitted based on the review result, and after confirming approval, packages the review result and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0070] Specifically, the number of partial signatures in several review results is counted; the number of partial signatures is compared with a preset threshold to obtain a comparison result; if the comparison result indicates that the number of partial signatures is higher than the preset threshold, the new code file version is determined to be approved for submission; the threshold signature technology is used to aggregate several partial signatures into a target threshold signature; the target threshold signature and the code submission hash value are packaged to generate a new candidate block corresponding to the new code file version. That is, the number of partial signatures in the obtained review results is counted to obtain the corresponding number of partial signatures. This number is then compared with a preset threshold. If it exceeds the preset threshold, the new code file version is deemed approved for submission. The threshold signature technology is used to aggregate the partial signatures into a single, complete, and valid target threshold signature, serving as collective authorization proof for the code submission hash value. The target threshold signature, which proves that the code submission has received sufficient review approval, and the code submission hash value are packaged into a code submission record to generate a new candidate block corresponding to the new code file version, containing the code submission record. It should be noted that the code submission record may also include metadata such as timestamps, submitter information, and review node information to improve the transparency of the code review process, providing a complete, reliable, and non-repudiable chain of evidence for code auditing, and greatly simplifying compliance checks and post-event tracking analysis.

[0071] It should be noted that if the number of partial signatures is not higher than the preset threshold, meaning that a sufficient number of approved partial signatures are not collected within the specified time, the submission is considered to have failed the review and will not be included in the block. The submitter must modify the code according to the review feedback and resubmit. In this way, this embodiment enforces the core code submission approval process through a cryptographic protocol, namely threshold signature technology, rather than relying solely on human operation or configuration strategies, resulting in higher reliability. Storing code submission records in newly added candidate blocks improves the transparency of the code review process, provides a complete, reliable, and non-repudiable chain of evidence for code auditing, and greatly simplifies compliance checks and post-event tracking analysis.

[0072] Step S14: Based on the consensus protocol of the consortium blockchain network, the newly added candidate block is proposed to other nodes among the several review nodes, excluding the master node, so that the other nodes can verify the newly added candidate block and feed back the verification result to the master node.

[0073] In this embodiment, the master node proposes the new candidate block to other nodes among the several review nodes (excluding the master node) through the consensus protocol of the consortium blockchain network, such as Raft's log replication or PBFT's prepare-confirm process. Upon receiving the new candidate block, these other nodes independently verify it, obtain the corresponding verification results, and then feed those results back to the master node. The verification includes, but is not limited to, the legality of the block structure, the validity of transactions within the block (such as the correctness of the threshold signature, verified using the consortium's shared threshold signature public key), and whether the code submission hash value is consistent with the previously distributed review task.

[0074] Step S15: Use the received verification result to determine whether the newly added candidate block has passed verification, and after determining that it has passed verification, connect the newly added candidate blockchain to the consortium blockchain network, and make corresponding code submission records for the target code submission request.

[0075] In this embodiment, the master node receives the verification results sent by the other nodes, determines whether the newly added candidate block passes verification based on the verification results, and links it to the consortium blockchain network after verification. Simultaneously, it records the corresponding code submission for the target code submission request. It is understood that the immutability of the blockchain means that records already on the chain cannot be directly deleted or modified. If a serious defect is found in a code version already on the chain, a rollback can be logically achieved by submitting a "rollback version," that is, restoring the content of a known stable version before the problematic version, or by applying a patch. The submission of this "rollback version" also requires a complete review and threshold signature process to ensure the compliance and traceability of the operation.

[0076] Specifically, the system receives several verification results from other nodes and determines the first number of these other nodes; it then statistically analyzes the verification results to determine the second number of nodes among the other nodes whose verification results represent nodes that have passed verification; based on the second number of nodes and the first number of nodes, it determines the proportion of nodes that have passed verification and compares this proportion with a preset node proportion threshold; if the node proportion is higher than the preset node proportion threshold, the newly added candidate block is deemed to have passed verification, and the newly added candidate blockchain is connected to the end of the consortium blockchain network, along with corresponding code submission records for the current target code submission request. The preset node proportion threshold is determined according to the consensus protocol. That is, several verification results fed back by several other nodes are obtained, and the corresponding number of first nodes is determined. Then, the verification results are statistically analyzed to determine the number of second nodes among the other nodes that have passed verification. The proportion of nodes that have passed verification is determined based on the number of nodes. If the proportion of nodes is higher than a preset node proportion threshold, such as more than two-thirds, it indicates that consensus has been reached. The newly added candidate block is determined to have passed verification, the block is accepted, the newly added candidate blockchain is connected to the end of the consortium blockchain network, and the corresponding code submission record is made for the target code submission request. Understandably, after the newly added candidate block is successfully uploaded to the blockchain, it signifies that the code submission has been finally confirmed. Code developers and other relevant parties can confirm that their submitted code version, identified by the code submission hash value, has been successfully recorded by querying the consortium blockchain network status or subscribing to notifications. They can then send relevant message notifications to the distributed code storage system to achieve information synchronization. The processing flow is as follows: A message notification indicating that the newly added code file version has been confirmed is sent to the distributed code storage system, so that the distributed code storage system transfers the newly added code file version from the pending review area to the target storage area of ​​the distributed code storage system and marks the version status as a confirmed state. In other words, a message is synchronously sent to the distributed code storage system so that it transfers the newly added code file version from the pending review area to the target storage area of ​​the distributed code storage system and marks the version status as a stable state indicating confirmation.

[0077] It should be noted that code developers can initiate code query requests to the consortium blockchain network at any time according to their own needs through the target client for code development. The processing flow is as follows: After receiving the target code version query request, the corresponding code to be queried is determined based on the target code version query request; the code query task containing the code to be queried is broadcast to the other nodes, so that the other nodes determine the code version hash value of the target code file version based on the code to be queried in the code query task, and feed back the code version hash value to the master node; the target code file version is the latest version that has been approved and submitted among several historical code file versions corresponding to the current code to be queried; several code version hash values ​​fed back by several other nodes are received, and the occurrence number of several code version hash values ​​is summarized to determine whether the target code version hash value exists among the several code version hash values ​​based on the occurrence number; the target code version hash value is the code version hash value whose occurrence number exceeds a preset hash value number threshold among the several code version hash values; if the target code version hash value is determined to exist, the target code version query request is fed back based on the target code version hash value. That is, after receiving a target code version query request initiated by a code developer, the corresponding code to be queried is determined based on the target code version query request, and the code query task containing it is broadcast to the other nodes, so that the other nodes can determine the latest and confirmed code version hash value of the current branch based on the code to be queried, and feed it back to the master node. The master node receives several code version hash values ​​fed back by several other nodes, and summarizes the occurrence number of several code version hash values, so as to determine whether there is a target code version hash value among the several code version hash values ​​whose occurrence number exceeds a preset hash value number threshold. If so, the master node feeds back the target code version query request based on the target code version hash value, so that the code developer can make local code modifications, add functions or fix defects based on the obtained code version. In this way, after the master node proposes a new candidate block to other nodes, the other nodes need to verify it to ensure the legality, validity and accuracy of the block structure and avoid the possibility of the block being maliciously tampered with during transmission. The chain structure, hash pointer and consensus mechanism of the blockchain ensure that once the code version change record is written, it cannot be retroactively tampered with or deleted, thus improving the security of the data.

[0078] As can be seen from the above, after receiving the target code submission request, the master node of the consortium blockchain network in this embodiment first uploads the corresponding new code file version to the distributed code storage system. The distributed code storage system generates the corresponding code submission hash value and feeds it back to the master node. The master node generates a code review task based on this hash value and reviews the code review task through the consortium blockchain network to obtain the corresponding review result. Then, based on the review result, it determines whether the new code file version can be submitted. If so, it packages the review result and the code submission hash value to generate a new candidate block. Then, it proposes the new candidate block to other review nodes for verification through the consensus protocol of the consortium blockchain network. Based on the obtained verification result, it determines whether the new candidate block passes the verification. If so, it connects the new candidate blockchain to the consortium blockchain network and records this code submission.In this way, through the above-described process of the embodiments of this application, on the one hand, the storage of code using the unique hash value of the content improves data security and supports data deduplication to ensure file integrity; on the other hand, the deployment of a distributed code storage system using a distributed cluster and the implementation of data redundancy backup and synchronization among geographically dispersed nodes ensure data persistence and resistance to single points of failure; on the other hand, the regular rotation of the role of the master node enhances the degree of decentralization and system robustness; on the other hand, the use of all nodes in the consortium blockchain network to jointly record and maintain all key information of code submissions and reviews ensures the integrity and immutability of the historical record, and the loss or damage of data from a single or a few nodes will not affect the integrity and availability of the overall historical record; on the other hand, considering the text merging conflict situation where multiple people modify the same code segment in parallel, conflict resolution is carried out through preset version control tools, which can avoid code storage anomalies; on the other hand, the approval authority for code merging is distributed through a threshold signature mechanism, which can avoid single points of control, enhance the security of code version control, and greatly improve the defense capabilities against internal malicious behavior such as administrator abuse of power, reviewers acting alone, and external targeted attacks. When the set of review nodes changes, a new threshold signature key share is regenerated and distributed, ensuring a smooth and secure transition of the key system without affecting the historical data already recorded on the consortium blockchain. Furthermore, the core code submission approval process is enforced by a cryptographic protocol, namely threshold signature technology, rather than relying solely on human operation or configuration strategies, resulting in higher reliability. Storing code submission records in newly added candidate blocks improves the transparency of the code review process, providing a complete, reliable, and irrefutable chain of evidence for code auditing, greatly simplifying compliance checks and post-event tracking analysis. After the master node proposes a new candidate block to other nodes, these nodes must verify it to ensure the legality, validity, and accuracy of the block structure, preventing malicious tampering during transmission. Finally, the blockchain's chain structure, hash pointers, and consensus mechanism ensure that once a code version change record is written, it cannot be retroactively altered or deleted, improving data security and thus solving the security and audit transparency issues of code version control caused by the limitations of current traditional code version control systems.

[0079] As can be seen from the previous embodiment, this application discloses a code version control method based on a consortium blockchain, which can solve the security and audit transparency problems of code version control caused by the limitations of current traditional code version control systems. Next, regarding... Figure 2 The code version control method based on consortium blockchain is explained in detail.

[0080] First, the code developer queries the consortium blockchain network for the latest, confirmed code version hash of the current branch. The target client sends requests to multiple review nodes or dedicated query nodes and collects responses. When a consistent hash result is received from a predetermined number of review nodes, such as more than 2 / 3, the hash is confirmed as the current trusted latest version. The developer uses the obtained latest code version hash to request the download of the complete set of code files from the distributed code storage system. The code storage system parses the version hash using an indexing system, locates the corresponding Merkle tree and the hashes of all constituent files, and then retrieves and transfers these files from the file storage system to the developer's local environment so that the developer can modify the code, add features, or fix defects locally.

[0081] After code development is completed, developers prepare to initiate a new code commit, which typically includes packaging the modified code and writing a commit message. The developers then send a merge request to any review node (or a designated entry node) in the consortium blockchain network through the target client. The node receiving the request (or its delegated preprocessing service) uploads the newly submitted code file to a temporary or pending review area of ​​the code storage system. The code storage system calculates the overall hash of the new code content, which is the new code commit hash. The node processing the request (or the current master node, if the request has been forwarded to the master node) broadcasts the review task containing the new code commit hash to all relevant review nodes through the consortium blockchain network.

[0082] Subsequently, each review node receiving the review task has its corresponding reviewers independently access and review the newly submitted code. If a reviewer approves the submission, their review node uses its share of the threshold signature private key to digitally sign the hash of the new code submission, generating a partial signature. This partial signature is then securely sent to the current master node. The master node is responsible for collecting partial signatures from different review nodes for the same new code submission hash. When the number of valid partial signatures collected by the master node reaches or exceeds the threshold value preset by the threshold signature scheme, it indicates that the code submission has been approved by a sufficient number of independent reviewers. The master node uses the threshold signature algorithm to aggregate these valid partial signatures into a single, complete, and valid threshold signature. It then packages the new code submission hash, the aggregated complete threshold signature, the timestamp, and other relevant transaction metadata into a new candidate block. Based on the consensus protocol of the consortium blockchain (such as Raft's log replication or PBFT's prepare-confirm process), this candidate block is proposed to other nodes in the network (especially other review nodes).

[0083] Finally, after receiving the candidate block, other nodes in the consortium blockchain network independently verify it. If a majority of nodes (according to the consensus algorithm, such as more than 2 / 3) verify and accept the block, consensus is reached. This block is then officially linked to the end of the consortium blockchain, becoming part of the immutable historical record. Once the block is successfully uploaded to the blockchain, the code submission is finally confirmed. Code developers and other relevant parties can confirm that their submitted code version has been successfully recorded by querying the consortium blockchain status or subscribing to notifications. The corresponding code version in the distributed code storage system also changes from a "pending review" status to a "confirmed" stable version.

[0084] Accordingly, see Figure 3 As shown in the embodiment of this application, a code version control device based on a consortium blockchain is also provided, applied to the master node of a consortium blockchain network, wherein the master node is any one of a plurality of review nodes in the consortium blockchain network; wherein, the device includes:

[0085] Version upload module 11 is used to upload the new code file version corresponding to the target code submission request to a preset distributed code storage system after receiving the target code submission request, so that the distributed code storage system generates a corresponding code submission hash value for the content of the new code file version and sends the code submission hash value to the master node;

[0086] The task review module 12 is used to generate corresponding code review tasks based on the obtained code submission hash value, and to review the code review tasks through the consortium blockchain network to obtain corresponding review results.

[0087] The result packaging module 13 is used to determine whether the new code file version is approved for submission based on the review result, and after determining that the submission is approved, to package the code file based on the review result and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0088] The block proposal module 14 is used to propose the new candidate block to other nodes among the plurality of review nodes, excluding the master node, based on the consensus protocol of the consortium blockchain network, so that the other nodes can verify the new candidate block and feed back the verification result to the master node.

[0089] The submission record module 15 is used to determine whether the newly added candidate block has passed the verification based on the received verification result, and after determining that the verification has passed, to connect the newly added candidate blockchain to the consortium blockchain network, and to make corresponding code submission records for the target code submission request.

[0090] As can be seen from the above, after receiving the target code submission request, the master node of the consortium blockchain network in this embodiment first uploads the corresponding new code file version to the distributed code storage system. The distributed code storage system generates the corresponding code submission hash value and feeds it back to the master node. The master node generates a code review task based on this hash value and reviews the code review task through the consortium blockchain network to obtain the corresponding review result. Then, based on the review result, it determines whether the new code file version can be submitted. If so, it packages the review result and the code submission hash value to generate a new candidate block. Then, it proposes the new candidate block to other review nodes for verification through the consensus protocol of the consortium blockchain network. Based on the obtained verification result, it determines whether the new candidate block passes the verification. If so, it connects the new candidate blockchain to the consortium blockchain network and records this code submission. In this way, through the above process of the embodiments of this application, the security and integrity of code storage are ensured by means of a distributed storage system; the review and consensus mechanism of the consortium blockchain network is used to realize decentralized review of code submission, avoid the risks brought about by single node decision-making, ensure the standardization, reliability and traceability of code submission, improve the transparency and security of code management, and thus solve the security and audit transparency problems of code version control caused by the limitations of the current traditional code version control system.

[0091] In some specific embodiments, the code version control device based on the consortium blockchain may further include:

[0092] The first condition judgment unit is used to determine whether there are any other code submission requests besides the target code submission request, so as to obtain the corresponding judgment result;

[0093] The second condition judgment unit is used to determine the code to be submitted corresponding to the target code submission request if the judgment result indicates that there are other code submission requests, and to determine whether there are conflicting code submission requests in the other code submission requests whose corresponding code is consistent with the code to be submitted.

[0094] The request merge unit is used to merge the conflicting code submission request and the target code submission request using a preset version control tool if it is determined that there is a conflicting code submission request among the other code submission requests, so as to obtain the merged target code submission request.

[0095] In some specific embodiments, the version upload module 11 includes:

[0096] The version upload unit is used to upload the new code file version corresponding to the target code submission request to the review area of ​​the preset distributed code storage system, so that the distributed code storage system marks the version status of the new code file version in the review area as a status indicating a review pending status, generates a corresponding code submission hash value for the content of the new code file version, and sends the code submission hash value to the master node;

[0097] Accordingly, the submission record module 15 may further include:

[0098] The notification sending unit is used to send a message notification indicating that the new code file version has been confirmed and submitted to the distributed code storage system, so that the distributed code storage system will transfer the new code file version from the pending review area to the target storage area of ​​the distributed code storage system and mark the version status as indicating a confirmed status.

[0099] In some specific implementations, each of the plurality of review nodes holds a threshold signature private key share, which is a private key share obtained by dividing the threshold signature private key generated based on the threshold signature technology.

[0100] Accordingly, the task review module 12 may specifically include:

[0101] The task generation unit is used to obtain the code submission hash value and generate a code review task containing the code submission hash value;

[0102] The first task broadcasting unit is used to broadcast the code review task to the target review node through the consortium blockchain network, so that the target review node reviews the new code file version based on the received code review task according to the preset review criteria, and after determining that the review is passed, uses the threshold signature private key share it holds to digitally sign the code submission hash value to generate a corresponding partial signature, and feeds back the review result containing the partial signature to the master node; the target review node is the node related to the new code file version among the plurality of review nodes;

[0103] The result acquisition unit is used to acquire several review results fed back by several target review nodes.

[0104] In some specific embodiments, the result packaging module 13 may specifically include:

[0105] A quantity counting unit is used to count the number of partial signatures in several of the aforementioned review results.

[0106] The quantity comparison unit is used to compare the number of partial signatures with a preset threshold value to obtain the corresponding comparison result;

[0107] A signature aggregation unit is used to determine that the new code file version is approved for submission if the comparison result indicates that the number of partial signatures is higher than the preset threshold value, and to aggregate several partial signatures into a target threshold signature using the threshold signature technology.

[0108] The hash value packaging unit is used to package the target threshold signature and the code submission hash value to generate a new candidate block corresponding to the new code file version.

[0109] In some specific embodiments, the submission record module 15 may specifically include:

[0110] A quantity determination unit is used to receive several verification results fed back by the other nodes and determine the first number of the other nodes;

[0111] The result statistics unit is used to perform statistics on several of the verification results to determine the number of second nodes in the other nodes, where the verification results represent the number of nodes that have passed the verification.

[0112] The ratio comparison unit is used to determine the ratio of nodes that have passed the characterization verification based on the number of the second nodes and the number of the first nodes, and compare the ratio of nodes with a preset node ratio threshold.

[0113] The blockchain connection unit is used to determine that the newly added candidate block has passed verification if the node ratio is higher than the preset node ratio threshold, and to connect the newly added candidate blockchain to the end of the consortium blockchain network, and to make corresponding code submission records for the target code submission request.

[0114] In some specific embodiments, the code version control device based on the consortium blockchain may further include:

[0115] The code determination unit is used to determine the corresponding code to be queried based on the target code version query request after receiving the target code version query request;

[0116] The second task broadcasting unit is used to broadcast a code query task containing the code to be queried to the other nodes, so that the other nodes can determine the code version hash value of the target code file version based on the code to be queried in the code query task, and feed back the code version hash value to the master node; the target code file version is the latest version that has been approved and submitted among several historical code file versions corresponding to the current code to be queried.

[0117] The quantity aggregation unit is used to receive several code version hash values ​​fed back by several other nodes, and to aggregate the occurrence counts of several code version hash values, so as to determine whether there is a target code version hash value among the several code version hash values ​​based on the occurrence counts; the target code version hash value is the code version hash value whose occurrence count exceeds a preset hash value quantity threshold among the several code version hash values.

[0118] The request feedback unit is used to provide feedback on the target code version query request based on the target code version hash value if it is determined that the target code version hash value exists.

[0119] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the code version control method based on a consortium blockchain disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0120] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0121] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0122] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the blockchain-based code version control method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0123] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed code version control method based on a consortium blockchain. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0124] The various embodiments in this specification are described 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. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0125] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0126] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0127] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0128] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A code version control method based on a consortium blockchain, characterized in that, The method is applied to a master node in a consortium blockchain network, wherein the master node is any one of several review nodes in the consortium blockchain network; wherein the method includes: Upon receiving a target code submission request, the newly added code file version corresponding to the target code submission request is uploaded to a preset distributed code storage system, so that the distributed code storage system generates a corresponding code submission hash value for the content of the newly added code file version and sends the code submission hash value to the master node; Based on the obtained code submission hash value, a corresponding code review task is generated, and the code review task is reviewed through the consortium blockchain network to obtain the corresponding review result; Based on the review results, it is determined whether the new code file version is approved for submission. After approval is determined, the code file is packaged based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version. Based on the consensus protocol of the consortium blockchain network, the newly added candidate block is proposed to other nodes among the several review nodes, excluding the master node, so that the other nodes can verify the newly added candidate block and feed back the verification result to the master node; The received verification result is used to determine whether the newly added candidate block has passed verification. After it is determined that the verification has passed, the newly added candidate blockchain is connected to the consortium blockchain network, and the corresponding code submission record is made for the target code submission request.

2. The code version control method based on consortium blockchain according to claim 1, characterized in that, Before uploading the new code file version corresponding to the target code submission request to the preset distributed code storage system, the method further includes: Determine whether there are any other code submission requests besides the target code submission request, and obtain the corresponding determination result; If the determination result indicates that there are other code submission requests, then the code to be submitted corresponding to the target code submission request is determined, and it is determined whether there are conflicting code submission requests among the other code submission requests whose code is consistent with the code to be submitted; If it is determined that there is a conflicting code submission request among the other code submission requests, then a preset version control tool is used to merge the conflicting code submission request and the target code submission request to obtain the merged target code submission request.

3. The code version control method based on consortium blockchain according to claim 1, characterized in that, The step of uploading the new code file version corresponding to the target code submission request to a preset distributed code storage system, so that the distributed code storage system generates a corresponding code submission hash value for the content of the new code file version, and sends the code submission hash value to the master node, includes: The newly added code file version corresponding to the target code submission request is uploaded to the review area of ​​the preset distributed code storage system, so that the distributed code storage system marks the version status of the newly added code file version in the review area as a status indicating a review pending status, generates a corresponding code submission hash value for the content of the newly added code file version, and sends the code submission hash value to the master node; Accordingly, after verifying the newly added candidate blockchain and connecting it to the consortium blockchain network, the process further includes: A message notification indicating that the newly added code file version has been confirmed and submitted is sent to the distributed code storage system, so that the distributed code storage system transfers the newly added code file version from the pending review area to the target storage area of ​​the distributed code storage system, and marks the version status as a confirmed status.

4. The code version control method based on consortium blockchain according to claim 1, characterized in that, Each of the review nodes holds a threshold signature private key share, which is a private key share obtained by dividing the threshold signature private key generated based on the threshold signature technology. Accordingly, the code review task is generated based on the obtained code submission hash value, and the code review task is reviewed through the consortium blockchain network to obtain the corresponding review results, including: Obtain the code submission hash value and generate a code review task containing the code submission hash value; The code review task is broadcast to the target review node through the consortium blockchain network. The target review node reviews the newly added code file version based on preset review criteria. Upon passing the review, it uses its threshold signature private key share to digitally sign the code submission hash value, generating a partial signature. The review result, including the partial signature, is then fed back to the master node. The target review node is the node among the plurality of review nodes that is related to the newly added code file version. Obtain several review results fed back by several target review nodes.

5. The code version control method based on consortium blockchain according to claim 4, characterized in that, The step of determining whether the new code file version is approved for submission based on the review results, and after determining that the submission is approved, packaging based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version, includes: Count the number of partial signatures in several of the aforementioned review results; The number of partial signatures is compared with a preset threshold value to obtain the corresponding comparison result; If the comparison result indicates that the number of partial signatures is higher than the preset threshold, then the new code file version is approved for submission, and the threshold signature technology is used to aggregate several partial signatures into a target threshold signature. The target threshold signature and the code submission hash are packaged together to generate a new candidate block corresponding to the new code file version.

6. The code version control method based on consortium blockchain according to claim 1, characterized in that, The process of determining whether the newly added candidate block passes verification using the received verification result, and connecting the newly added candidate blockchain to the consortium blockchain network after verification, and recording the corresponding code submission for the target code submission request, includes: Receive several verification results fed back by the other nodes, and determine the first number of the other nodes; Statistical analysis is performed on several of the aforementioned verification results to determine the number of second nodes among the other nodes, where each verification result represents a node that has passed verification. The proportion of nodes that pass the characterization verification is determined based on the number of the second node and the number of the first node, and the proportion of nodes is compared with a preset node proportion threshold. If the node ratio is higher than the preset node ratio threshold, the newly added candidate block is determined to have passed verification, and the newly added candidate blockchain is connected to the end of the consortium blockchain network, and a corresponding code submission record is made for the target code submission request.

7. The code version control method based on consortium blockchain according to any one of claims 1 to 6, characterized in that, Also includes: Upon receiving a target code version query request, the corresponding code to be queried is determined based on the target code version query request; The code query task containing the code to be queried is broadcast to the other nodes, so that the other nodes can determine the code version hash value of the target code file version based on the code to be queried in the code query task, and feed the code version hash value back to the master node; The target code file version is the latest version among several historical code file versions corresponding to the code to be queried, and the version that has been approved and submitted. The system receives several code version hash values ​​fed back by several other nodes, and summarizes the occurrence counts of several code version hash values ​​to determine whether a target code version hash value exists among the several code version hash values ​​based on the occurrence counts; the target code version hash value is the code version hash value whose occurrence count exceeds a preset hash value count threshold among the several code version hash values. If the target code version hash value is determined to exist, a response is given based on the target code version hash value in response to the target code version query request.

8. A code version control device based on a consortium blockchain, characterized in that, A master node applied to a consortium blockchain network, wherein the master node is any one of several review nodes in the consortium blockchain network; wherein the device includes: The version upload module is used to upload the new code file version corresponding to the target code submission request to a preset distributed code storage system after receiving the target code submission request. The distributed code storage system generates a corresponding code submission hash value for the content of the new code file version and sends the code submission hash value to the master node. The task review module is used to generate corresponding code review tasks based on the obtained code submission hash value, and to review the code review tasks through the consortium blockchain network to obtain corresponding review results. The result packaging module is used to determine whether the new code file version is approved for submission based on the review results, and after determining that the submission is approved, to package the code file based on the review results and the code submission hash value to generate a new candidate block corresponding to the new code file version. The block proposal module is used to propose the new candidate block to other nodes among the several review nodes, excluding the master node, based on the consensus protocol of the consortium blockchain network, so that the other nodes can verify the new candidate block and feed back the verification result to the master node. The submission record module is used to determine whether the newly added candidate block has passed verification based on the received verification result, and after determining that the verification has passed, to connect the newly added candidate blockchain to the consortium blockchain network, and to make corresponding code submission records for the target code submission request.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the code version control method based on a consortium blockchain as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the code version control method based on a consortium blockchain as described in any one of claims 1 to 7.

Images