Practical consensus algorithm for file resource sharing

Abstract

The invention relates to a practical consensus algorithm for file resource sharing, which comprises reputation-driven task allocation: according to reputation values calculated in real time, nodes with high reputation values are preferentially selected by the algorithm to form a core consensus group to execute the most critical consensus task, and the number of nodes participating in core communication is remarkably reduced. And protocol flow optimization: fundamentally reducing the communication complexity to O (n) level by limiting the scale of the core consensus group and reconstructing a message transmission path. And node state dynamic autonomy: the algorithm has real-time evaluation and dynamic adjustment capabilities on node types. The reputation model continuously monitors node behaviors, can automatically perform degradation processing on low-reputation or fault nodes, and can timely discover and safely isolate or delete bad nodes through a specific mechanism without restarting the system. Through test verification, the reliability, safety, higher throughput and lower delay of the consensus algorithm are verified.

Description

Technical Field

[0001] This invention relates to the field of consensus algorithm technology, and specifically to a practical consensus algorithm for sharing archive resources. Background Technology

[0002] Archives refer to primary source documents generated, held, and preserved by organizations and individuals in the course of handling related business. Furthermore, archival information resources constitute the most reliable portion of information resources. Currently, a provincial-level archives (bureaus) alliance blockchain has been established, with each archives bureau (repository) holding an authorized node. Each authorized node can achieve point-to-point information exchange, and the alliance blockchain is jointly maintained through consensus mechanisms and smart contract mechanisms.

[0003] The archival information resource sharing protocol architecture based on consortium blockchain is as follows: Figure 1 As shown. The entire protocol process can be summarized as follows: First, each factory needs to register with the Trusted Authorization Center. Each factory acts as an attribute agency, setting corresponding attributes for each user and binding the user identifier with the attribute private key assigned by different attribute centers for easy management.

[0004] The access structure is then defined by the attribute organization. Only users who meet the access structure requirements can obtain the key and the encrypted file address to access the archive data. Each factory is responsible for performing searchable encryption on the archive data, attaching a tamper-evident digital signature to its private key, and broadcasting the storage request to the entire network.

[0005] After receiving a storage request, all authorized nodes on the network use the PBFT consensus mechanism to put the hash value, address, corresponding key and other relevant information of the encrypted file data into the data block and add a timestamp, and store it in the consortium blockchain. The corresponding file is then placed in the distributed cloud server.

[0006] When a user requests to search for a file, the smart contract first verifies the user's identity. Only after successful verification can the search for the relevant electronic file proceed. The smart contract sends the user's public key and the reason for the request to the file owner. The file owner then uses their own public and private keys to generate a re-encrypted key with the user's public key and sends it to the smart contract.

[0007] The smart contract then sends the key and the address of the target file to the cloud server. The cloud server re-encrypts the file and returns the new file address to the smart contract. The smart contract then sends the new address to the queryer, who uses their private key to decrypt the downloaded encrypted file data and obtain the file content.

[0008] In the aforementioned protocol, an innovative improved algorithm is proposed to address the shortcomings of the Practical Byzantine Fault-Tolerant (PBFT) algorithm in archival resource sharing scenarios, such as high communication complexity, arbitrary master node selection, and rigid node management. This algorithm significantly improves efficiency, security, and scalability by introducing a dynamic reputation value model, a master node election mechanism based on a verifiable random function (ECVRF), and a unique hierarchical consensus architecture. Its core operational logic can be systematically described below.

[0009] Consensus algorithms are the core of blockchain technology, aiming to solve the consistency problem in distributed systems and improve the decentralized nature of blockchains. Early research on consensus algorithms mainly focused on non-Byzantine distributed consensus problems, such as the classic Paxos algorithm and the later Raft algorithm. It wasn't until Miguel Castro and Barbara Liskov proposed the PBFT algorithm that the inefficiency of previous BFT algorithms was effectively overcome. It reduced the algorithm complexity from exponential to polynomial, making Byzantine fault-tolerant algorithms applicable to practical systems. However, each slave node in the PBFT algorithm needs to perform P2P consensus synchronization with other nodes, resulting in high communication complexity. Therefore, as the number of nodes increases, the performance of this algorithm deteriorates sharply.

[0010] With in-depth research into the PBFT algorithm, the algorithm has been continuously optimized. Existing scalable multi-layer PBFT consensus mechanisms are optimal two-layer PBFT mechanisms, distributing nodes across two layers, thus reducing single-layer traffic. While this solves the problems of high communication complexity and poor scalability of the original PBFT algorithm, it neglects the selection of the master node. Optimization of the master node consensus mechanism is then implemented. An external server is used as the master node to ensure its trustworthiness and optimize the consensus process. However, the communication complexity remains at the O(n²) level.

[0011] In existing technologies, common consensus schemes are relatively simple and difficult to adapt to the requirements of fine-grained node state management in archival resource sharing scenarios. In particular, in this scenario, three key shortcomings are prevalent: First, the consensus process failed to optimize for the characteristics of archival resources, and there is still a lot of redundant broadcast communication between nodes, which keeps the communication complexity at the O(n²) level, affecting the efficiency of resource retrieval and sharing.

[0012] Secondly, there is a lack of automated monitoring and processing mechanisms for nodes that are offline for a long time, have slow response, or have abnormal storage. Relying on manual investigation and recovery makes it difficult to ensure the continuous availability of resources.

[0013] Third, the selection process for master nodes is highly random, and nodes with insufficient storage capacity or unstable networks may become master nodes, affecting the reliability of resource synchronization and consensus.

[0014] These shortcomings will become even more apparent in the scenario of sharing archive resources; as the number of participating nodes and storage resources increases, the system's consensus efficiency will decrease significantly, restricting overall scalability and service responsiveness. Summary of the Invention

[0015] Based on the scenario of archival resource sharing, this invention proposes a practical consensus algorithm to address the problems existing in consensus algorithms during archival resource sharing, including: the problem of excessively high communication complexity: all nodes need to communicate in multiple rounds during the consensus process, and the communication complexity skyrockets (O(n²)) as the number of nodes increases; the problem of excessively random master node selection: during the consensus process, a unique master node needs to be configured to receive requests and distribute them to other nodes, which is the core node of the consensus network, causing a sharp drop in consensus efficiency and excessive system latency; and the problem of the inability to dynamically adjust nodes: unreliable nodes still exist in the consensus network, posing a risk of tampering with archives and making it difficult to meet the high concurrency and high security requirements of cross-institutional archival collaboration.

[0016] To address the aforementioned technical problems, one objective of this invention is to provide a practical consensus algorithm for archival blockchains, with the specific steps as follows: S1: Node reputation assessment and stratification, based on a continuously running reputation value model, which evaluates the behavior and classifies the roles of nodes in the network; S2: Node election mechanism, based on an election scheme with verifiable elliptic curve random functions, to ensure the randomness, fairness and verifiability of the election process; S3: Consensus execution process. After completing node layering and master node election, the optimized consensus protocol is executed. Its core is to restrict global consensus communication to the internal nodes of the UNL layer. S4: Dynamic node adjustment. After the consensus execution process is completed, the system enters the dynamic adjustment phase, forming a closed-loop self-optimizing system.

[0017] Furthermore, the S1 node reputation assessment and stratification are specifically as follows: S11: Reputation value quantification model, the reputation value of each node i in the j-th round of consensus. It is a dynamically changing quantitative indicator, derived from the formula. Calculations show that and These are the weights assigned to the degree of consensus participation and the degree of enthusiasm for reaching a consensus, respectively. S12: Node hierarchy and responsibility allocation. Based on the real-time calculated reputation value, nodes are divided into four levels, forming a pyramid-shaped management structure.

[0018] Furthermore, the level of consensus participation in S11 ( The calculation is based on the node type and the degree of work completion, and can be expressed as: ; in, This indicates the level of participation of node i. Whether the consensus-building work has been completed is a matter of debate. This indicates whether the submission has been completed. This indicates whether the timeout has occurred; rewards are given for completion and completion without timeout; otherwise, the value is 0. , and Represents the weight of different jobs; Degree of consensus (positive) The consensus completion rate and historical reputation score of each node are jointly determined, and are expressed as follows: ; in, This indicates the level of activity of node i in the j-th round of consensus. This represents the cumulative number of consensuses reached. This represents the reputation value of node i in round j-1 of consensus. and That is the corresponding weight.

[0019] Furthermore, the division of the S12 node into four layers specifically includes the following: UNL layer ( > 80: This layer comprises nodes with the highest reputation scores (5%-30% of all nodes) and is responsible for executing the complete core consensus protocol. Master nodes all originate from this layer. Candidate layer (40 < ≤ 80): As a backup for the UNL layer, it only participates in the final stage of consensus commit (Reply) to ensure the robustness of the system when there are insufficient UNL nodes; Fault layer (20 < ≤ 40): Nodes with lower reputation are placed in a "waiting" state and do not participate in consensus. They need to improve their reputation through good behavior. Malicious layer ( ≤ 20): Nodes with extremely low reputation are considered malicious or seriously faulty and will be marked by the system and a deletion process will be initiated.

[0020] Furthermore, S2 specifically refers to: Election eligibility: When a node's reputation value Above a certain threshold Only when the node is in a certain condition is it eligible to be a candidate, thus ensuring the basic reliability of the master node from the source. Random lottery: Based on VRF, a verifiable random function (ECVRF) was designed based on the Montgomery curve Curve25519. The results confirm that the election is not completely equal. The node's reputation value Ci is converted into "vote weight." The system determines the "number" (j value) of each candidate node being selected based on the total reputation value weight and a preset threshold, using random numbers generated by ECVRF. Assume the sum of the reputation values ​​of all nodes is W = In other words, there are a total of W small units. A threshold τ is set, which is the number of small units to be selected. Then the probability of each small unit being selected is... For a certain reputation value The probability of selecting a node and its k smaller units is... Following a binomial distribution, the interval [0,1] is divided into w+1 smaller intervals, represented as: ; ; Then, a random number is generated using ECVRF. The system determines the value j that makes e fall within a specific interval X by accumulating the probabilities of successes ranging from 0 to a certain value j. The length of the j-th interval corresponds to the probability that the corresponding node is selected j times. If the random number generated by ECVRF falls into the j-th interval, it means that node i was selected j times in this lottery. When j is 0, it means that node i failed to be selected; when j is greater than 0, it means that the lottery was successful. When multiple nodes are selected successfully, the node with the largest j-value becomes the master node. When there are nodes with the same j-value, the node with the smallest j-value becomes the master node. After the master node is successfully selected, it broadcasts the ecvrf_proof to other nodes. After receiving the broadcast, the nodes will use the node's public key, timestamp, and ecvrf_proof to verify and record the verifiable random number. This mechanism introduces randomness to prevent prediction and ensures the rationality and security of the election through reputation weighting and cryptographic verification.

[0021] Furthermore, the verifiable random function includes a key generation function, a proof generation function, and a proof verification function. Key generation function ECVRF_GetKey() → ( This algorithm generates a key pair (public key) based on the Montgomery curve Curve 25519. private key Let the elliptic curve lie on a finite field, have a prime order n, and have a base point G on the elliptic curve; The proof generator function ECVRF_Prove( (e.g., message) → (ecvrf_hash, proof): Given the private key `ski` and the original message `message`, `ECVRF_Prove` derives the key `x` from `ski` and calculates the VRF public key `Y`. Through calculations using functions such as `ECVRF_hash_to_curve`, `ECVRF_nonce_generation`, and `ECVRF_hash_points`, it concatenates these into a random number proof `ecvrf_proof` and the hash value `ecvrf_hash`. Here, `ecvrf_hash` is a pseudo-random string of a hash length uniquely determined by `ski` and `message`, while `ecvrf_proof` can be used by the user... Verification; Proof verification function ECVRF_Verify( (ecvrf_proof, message) → (result): The algorithm's inputs are the original input message, the verifiable proof ecvrf_proof, and the public key. By remapping on the elliptic curve, point H is obtained, then the integer c' is re-encoded and calculated. Finally, c and c' are compared to see if they are consistent and the verification result result is output.

[0022] Furthermore, the specific steps of S3 are as follows: In the S31 request phase, client C first signs the request and then sends it.<REQUEST,o,t,c> σi is sent to the master node, where o represents the operation, i.e., the specific task that the client wants the network to perform; t represents the timestamp, used to distinguish the order of these commands; c is the client number, used to identify the specific client that issued the request; and σi represents the digital signature of client i on this information to ensure the authenticity of its identity and the legitimacy of the request. During the S32 preparation phase, the master node signs the request and sends <<PRE-PREPARE,v,n,d> When m>σp reaches the UNL node, the consensus protocol is executed. When the UNL node receives the Pre-Prepare message, it performs a series of verification steps to ensure the validity and security of the message. If all the above conditions are met, the UNL node will accept the pre-prepare message and enter the preparation phase. During the S33 preparation phase, the UNL node signs the message and responds.<PREPARE,v,n,d,i> When the message reaches the master node, and the master node receives the preparation message from other nodes, it performs a series of verifications: The view number in the confirmation message is the same as the view number of the node itself; Check if the serial number n is within the specified range [h, H]; Verify that message digest d is the same as the message digest received during the pre-preparation phase; If all the above verifications pass, the node will insert this preparation message into its local log. When a node receives all the same preparation messages, and these messages have the same m, v, and n as the previously received preparation messages, it will consider prepare to be true and insert this state into its local log. Subsequently, the node will enter the Commit phase. During the S34 confirmation phase, after receiving the preparation message, the master node sends...<COMMIT,v,n,d,i> Upon reaching the UNL node, the UNL node begins executing the request and replies to the master node. After receiving the confirmation message from the UNL node, the master node sends a COMMIT message to the candidate nodes for confirmation. Other replica nodes, upon receiving the commit message, verify the digital signature, attempt sequence number, and sequence number, and insert this commit message into their local logs. Next, the node checks whether the following two conditions are met to determine whether to make the judgment that committed-local(m, n, v, i) is true: The prepare(m, n, v, i) property of node i is true; Node i received all consistent commit messages, and the m, v, and n fields in these messages were exactly the same as the corresponding fields in the local Pre-prepare message. The node will only proceed with the subsequent commit operation when both of these conditions are met. During the S35 submission phase, after receiving the confirmation message, the candidate node sends...<REPLY,v,t,c,i,r> Upon receiving a reply message, the client uses the timestamp t to determine which request's execution result it represents. The client only needs to receive f+1 reply messages with the same execution result (i.e., the same r and t) to consider the execution result reliable.

[0023] Furthermore, the verification steps performed in the pre-preparation phase include: Check if the digital signature of the request is correct; The accuracy of the master node's proof is verified using the ECVRF_Verify function. Verify that the View sequence number in the message matches the current replica node; Verify whether the sequence number (n) assigned in the message is unique in the current view; Check if the serial number (n) is within the specified range [h, H].

[0024] Furthermore, S4 specifically includes: Reputation value updates: When a node participates in the consensus process, the system first calculates its reputation value based on the node's historical behavior and current performance. If the performance is good, the reputation increases, and if the performance is bad, the reputation decreases. Then, based on the changes in reputation value, the system adjusts the node's level and state to ensure that the system can respond quickly to changes in node behavior. Node promotion and demotion: Changes in reputation value will trigger the dynamic promotion and demotion of nodes between different levels. This mechanism ensures that the consensus group is always composed of the most reliable nodes. Malicious node deletion occurs when the master node detects that the node's reputation value has fallen into the malicious layer. When the threshold is ≤ 20, a deletion vote will be initiated. UNL layer nodes will mutually confirm their selections, and if more than half agree, the node will be removed from the network, thus ensuring the scalability and security of this algorithm.

[0025] The above-described one or more technical solutions of the present invention have at least one or more of the following technical effects: In the process of sharing archival information, the optimized algorithm has significant advantages: 1. Improved reliability of sharing: By establishing a reputation value model linked to sharing behavior, it is ensured that only nodes with good and stable historical sharing records participate in consensus, thus guaranteeing the reliability of the transmission and synchronization process of archival resources from a mechanism perspective.

[0026] 2. Enhanced security of shared resources: The master node selection mechanism has been optimized, and the verification of the stability and reliability of candidate nodes has been increased. This has reduced the randomness of the selection and prevented unstable nodes from dominating the consensus, thereby enhancing the security foundation of the entire resource sharing system.

[0027] 3. Sharing and consensus efficiency optimization: By optimizing the node selection and consensus execution process, and forming a fixed set of trusted nodes (UNL) to participate in key consensus, the system communication complexity is significantly reduced from O(n²) to O(n), greatly improving the efficiency of large-scale archive resource retrieval, synchronization and verification.

[0028] 4. System Adaptability and Expansion: It has the ability to dynamically adjust node roles and network layers, enhancing the overall scalability of the solution. Attached Figure Description

[0029] Figure 1 : Architecture diagram of an archive sharing protocol based on consortium blockchain; Figure 2 PC-PBFT consensus protocol flowchart. Detailed Implementation

[0030] This invention presents a practical consensus algorithm for sharing archival resources, including a reputation value model that sets reputation values, classifies behaviors and categories, evaluates reputation values, and establishes a reputation value update mechanism. It also outlines the design process for master node selection and verification, the optimized design of the proportion of consensus nodes, the five-stage consensus protocol and its complexity design, and a dynamic node promotion / demotion protocol within the consensus algorithm.

[0031] To fundamentally address efficiency bottlenecks and dynamic management challenges, an improved consensus algorithm based on a reputation value model is proposed. The core of this algorithm lies in constructing a refined dynamic reputation value model and using it as a basis for deep optimization of the consensus protocol execution process. Through this mechanism, the efficiency, security, and network topology adaptability of the consensus process are ensured to meet the demands of large-scale, highly dynamic blockchain application scenarios.

[0032] Reputation-driven task allocation: Based on the real-time calculated reputation value, the algorithm prioritizes nodes with high reputation values ​​to form core consensus groups (such as the UNL layer) to perform the most critical consensus tasks (such as the pre-preparation and preparation phases), significantly reducing the number of nodes participating in core communication.

[0033] Protocol process optimization: By limiting the size of the core consensus group and refactoring the message passing path (for example, nodes only need to reply to the master node during the preparation phase, instead of broadcasting to the entire network), the communication complexity is fundamentally reduced to the O(n) level.

[0034] Dynamic autonomy of node status: The algorithm has the ability to evaluate and dynamically adjust node types in real time. The reputation model continuously monitors node behavior, automatically downgrades low-reputation or faulty nodes, and can promptly detect and safely isolate or delete malicious nodes through specific mechanisms (such as voting) without requiring a system restart.

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

[0036] This paper addresses the shortcomings of the Practical Byzantine Fault-Tolerant (PBFT) algorithm in consortium blockchain scenarios with potentially large node scales for shared archive resources. These shortcomings include high communication complexity, arbitrary master node selection, and rigid node management. An innovative improved algorithm is proposed. This algorithm significantly enhances efficiency, security, and scalability by introducing a dynamic reputation value model, a master node election mechanism based on a verifiable random function (ECVRF), and a unique hierarchical node consensus architecture. Its core operational logic is systematically explained below.

[0037] I. Node Reputation Assessment and Layering The cornerstone of this algorithm is a continuously running reputation value model, which evaluates the behavior and assigns roles to nodes in the network, laying the foundation for the subsequent consensus process.

[0038] 1. Reputation Value Quantification Model The reputation value of each node i in the j-th round of consensus. It is a dynamically changing quantitative indicator, derived from the formula. ;; Calculations show that and These are the weights of consensus participation and consensus enthusiasm, respectively. Consensus participation level ( The calculation is based on the node type and the degree of work completion, and can be expressed as: ; in, This indicates the level of participation of node i. Whether the consensus-building work has been completed is a matter of debate. This indicates whether the submission has been completed. This indicates whether the timeout has occurred. A reward is given if the timeout is completed or not; otherwise, it is 0. , and This represents the weight assigned to different jobs.

[0039] Degree of consensus (positive) The consensus completion rate and historical reputation score are jointly determined by the nodes, and can be expressed as: ; in, This indicates the level of activity of node i in the j-th round of consensus. This indicates the cumulative number of consensuses reached. This represents the reputation value of node i in round j-1 of consensus. and That is the corresponding weight.

[0040] 2. Node Hierarchy and Responsibility Allocation

[0041] Based on real-time calculated reputation scores, nodes are divided into four tiers, forming a pyramid-shaped management structure: UNL layer ( > 80: This layer comprises nodes with the highest reputation scores (5%-30% of all nodes) and is responsible for executing the complete core consensus protocol. Master nodes are all generated from this layer.

[0042] Candidate layer (40 < ≤ 80): As a backup for the UNL layer, it only participates in the final stage of consensus commit (Reply) to ensure the robustness of the system when there are insufficient UNL nodes.

[0043] Fault layer (20 < ≤ 40): Nodes with lower reputation are placed in a "waiting" state and do not participate in consensus. They need to improve their reputation through good behavior.

[0044] Malicious layer ( ≤ 20): Nodes with extremely low reputation are considered malicious or seriously faulty and will be marked by the system and a deletion process will be initiated.

[0045] This hierarchical mechanism enables refined management of nodes, delegating core consensus tasks to high-reputation nodes, thereby significantly reducing communication overhead while ensuring security.

[0046] II. Master Node Election Mechanism

[0047] To address the issue of arbitrary election in PBFT master node election, this algorithm designs an election scheme based on Elliptic Curve Verifiable Random Function (ECVRF) to ensure the randomness, fairness, and verifiability of the election process.

[0048] 1. Eligibility for election Not all nodes can participate in master node election. Only nodes with a certain reputation value can participate. Above a certain threshold Only when a node is selected is it eligible to be a candidate, thus ensuring the basic reliability of the master node from the source.

[0049] 2. Random draw This paper designs a verifiable random function (ECVRF) based on the Montgomery curve Curve 25519, building upon the VRF model. This mainly includes a key generation function, a proof generation function, and a proof verification function, as detailed below.

[0050] Key generation function ECVRF_GetKey() → ( This algorithm generates a key pair (public key) based on the Montgomery curve Curve 25519. private key Let the elliptic curve lie on a finite field, have a prime order of n, and a base point G on the elliptic curve. The detailed process is shown in Algorithm 4.1:

[0051] The proof generator function ECVRF_Prove( (e.g., message) → (ecvrf_hash, proof): Given the private key `ski` and the original message `message`, `ECVRF_Prove` derives the key `x` from `ski` and calculates the VRF public key `Y`. Through calculations using functions such as `ECVRF_hash_to_curve`, `ECVRF_nonce_generation`, and `ECVRF_hash_points`, it concatenates these into a random number proof `ecvrf_proof` and the hash value `ecvrf_hash`. Here, `ecvrf_hash` is a pseudo-random string of a hash length uniquely determined by `ski` and `message`, while `ecvrf_proof` can be used by the user... The verification process is detailed in Algorithm 4.2:

[0052]

[0053] (3) Prove the verification function ECVRF_Verify( (ecvrf_proof, message) → (result): The algorithm's inputs are the original input message, the verifiable proof ecvrf_proof, and the public key. The algorithm remaps the point H onto the elliptic curve, then re-encodes and calculates the integer c'. Finally, it compares c and c' to determine if they are consistent and outputs the verification result, result. The detailed algorithm flow is shown in Figure 4.3.

[0054] 3. Result Confirmation The election is not entirely equal. A node's reputation value C_i is converted into a "vote weight." The system determines the "number" (j value) of each candidate node selected using random numbers generated by ECVRF, based on the total reputation weight and a preset threshold. Assume the sum of all nodes' reputation values ​​is W = There are a total of W small units. A threshold τ is set, which is the number of small units to be selected. Then the probability of each small unit being selected is... For a given reputation value The probability of selecting a node and its k smaller units is... The interval [0,1] follows a binomial distribution. Dividing the interval [0,1] into w+1 smaller intervals, we can represent it as follows: ; ; Then, a random number is generated using ECVRF. The system determines the value j that makes e fall within a specific interval X by accumulating the probabilities of successes ranging from 0 to a certain value j. The length of the j-th interval corresponds to the probability that the corresponding node is selected j times, i.e. If the random number generated by ECVRF falls into the j-th interval, it means that node i was selected j times in this lottery. When j is 0, it means that node i failed to be selected; when j is greater than 0, it means that the lottery was successful.

[0055] When multiple nodes successfully draw lots, the node with the largest j-value becomes the master node. If nodes have the same j-value, the node with the smallest j-value becomes the master node. After successful master node selection, it broadcasts the ecvrf_proof to other nodes. Upon receiving the broadcast, each node uses its public key, timestamp, and ecvrf_proof to verify and record the verifiable random number. This mechanism introduces randomness to prevent prediction and ensures the rationality and security of the election through reputation weighting and cryptographic verification.

[0056] III. Consensus Execution Process After completing node layering and master node election, this algorithm executes an optimized consensus protocol, the core of which is to restrict global consensus communication to the UNL layer nodes. The PC-PBFT consensus protocol flowchart is as follows: Figure 1 As shown.

[0057] (1) Request phase: Client C first signs the request, then sends it. To the master node. Here, 'o' represents the operation, i.e., the specific task the client wants the network to perform; 't' represents the timestamp, used to distinguish the order of these commands; 'c' is the client's ID, used to identify the specific client that issued the request; and 'σi' represents the digital signature of this information by client i to ensure the authenticity of its identity and the legitimacy of the request.

[0058] Pre-prepare phase: The master node signs the request and sends it. Upon reaching the UNL node, the consensus protocol begins execution. When the UNL node receives the Pre-Prepare message, it performs a series of verification steps to ensure the message's validity and security: Check if the digital signature of the request is correct; The accuracy of the master node's proof is verified using the ECVRF_Verify function. Verify that the View sequence number in the message matches the current replica node; Verify whether the sequence number (n) assigned in the message is unique in the current view; Check if the serial number (n) is within the specified range [h, H]; If all the above conditions are met, the UNL node will accept this pre-preparation message and enter the preparation phase.

[0059] (3) Preparation stage: UNL nodes sign and reply to messages. The message reaches the master node. When the master node receives a preparation message from other nodes, it performs a series of verifications: The view number in the confirmation message is the same as the view number of the node itself; Check if the serial number n is within the specified range [h, H]; Verify that message digest d is the same as the message digest received during the pre-preparation phase; If all the above verifications pass, the node will insert this prepare message into its local log. When a node receives all identical prepare messages, and these messages have the same m, v, and n as the previously received prepare messages, it will consider prepare true and insert this status into its local log. Subsequently, the node will enter the commit phase.

[0060] (4) Commit Phase: After receiving the preparation message, the master node sends... Upon reaching the UNL node, the UNL node begins executing the request and replies to the master node. After receiving the confirmation message from the UNL node, the master node sends a COMMIT message to the candidate nodes for confirmation. Other replica nodes, upon receiving the commit message, verify the digital signature, attempt sequence number, sequence number, etc., and insert this commit message into their local logs. Next, the node checks whether the following two conditions are met to determine whether committed-local(m, n, v, i) is true: The prepare(m, n, v, i) property of node i is true; Node i received all consistent commit messages, and the m, v, and n fields in these messages were exactly the same as the corresponding fields in the local Pre-prepare message.

[0061] The node will only proceed with the subsequent commit operation when both of these conditions are met.

[0062] (5) Submission Phase (Reply): After receiving the confirmation message, the candidate node sends... The message is then forwarded to the client. Upon receiving a reply message, the client uses the timestamp 't' to determine which request's execution result it represents. The client only needs to receive f+1 reply messages with the same execution result (i.e., the same 'r' and 't') to consider the execution result reliable.

[0063] IV. Dynamic Adjustment of Nodes After the consensus process is completed, the system enters a dynamic adjustment phase, forming a closed-loop self-optimizing system.

[0064] 1. Reputation value update When nodes participate in the consensus process, the system first calculates their reputation score based on their historical behavior and current performance. Good performance increases their reputation score, while poor performance decreases it. Then, based on the changes in reputation score, the system dynamically adjusts the node's hierarchy and state according to Algorithm 4.4. This ensures the system can respond quickly to changes in node behavior, maintaining system stability and security. By introducing real-time updates and dynamic adjustment mechanisms, this algorithm provides an efficient, stable, and secure consensus solution for archive resource sharing. This algorithm design improves system performance and scalability.

[0065]

[0066] 2. Node upgrade / downgrade Changes in reputation value trigger dynamic promotion and demotion of nodes across different tiers. For example, a candidate node whose reputation value exceeds the UNL threshold and has a vacancy can be promoted to an UNL node; conversely, an UNL node whose reputation value drops is demoted. This mechanism ensures that the consensus group is always composed of the most reliable nodes.

[0067] 3. Deletion of malicious nodes When the master node discovers that the node's reputation value has fallen into the malicious layer ( When the threshold is ≤ 20, a deletion vote will be initiated. UNL layer nodes will mutually confirm their selections, and if more than half agree, the node will be removed from the network, thus ensuring the scalability and security of this algorithm.

[0068] Obviously, those skilled in the art can make various modifications and variations to the embodiments of the present invention without departing from the spirit and scope of the embodiments of the present invention. Thus, if these modifications and variations to the embodiments of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention also intends to include these modifications and variations.

[0069] This invention presents a practical consensus algorithm for sharing archival resources. Through testing, the reliability, security, higher throughput, and lower latency of the consensus algorithm have been verified.

Claims

1. A utility consensus algorithm for archival blockchains, characterized in that, The specific steps are as follows: S1: node reputation evaluation and stratification, based on a continuously running reputation value model, which evaluates the behavior of nodes in the network and divides the roles; S2: node election mechanism, based on an election scheme of an elliptic curve verifiable random function, to ensure the randomness, fairness and verifiability of the election process; S3: consensus execution process, after completing node stratification and master node election, an optimized consensus protocol is executed, the core of which is to limit global consensus communication within the UNL layer nodes; S4: dynamic adjustment of nodes, after the consensus execution process is completed, the system enters the dynamic adjustment stage, forming a closed-loop self-optimizing system.

2. The utility consensus algorithm for archival blockchains of claim 1, wherein: The S1 node reputation evaluation and stratification is specifically: S11: a reputation value quantification model, the reputation value of each node i in the jth round of consensus is a dynamic quantitative index calculated by the formula , and are the weights of consensus participation degree and consensus initiative degree, respectively; S12: node stratification and responsibility allocation, according to the real-time calculated reputation value, the nodes are divided into four levels, forming a pyramid management structure.

3. The utility consensus algorithm for archival blockchains of claim 2, wherein: The consensus participation degree (S11) in the S11 : According to the type of node and the work completion degree, which can be expressed as: ； wherein, represents the participation degree of node i, represents whether the consensus work is completed, represents whether the submission work is completed, represents whether it is overtime, and the completion and non-overtime obtain a reward, otherwise 0, and , and represent the weights of different works; Degree of consensus (positive) The consensus completion rate and historical reputation score of each node are jointly determined, and are expressed as follows: ； wherein, represents the degree of activity of node i in the jth round of consensus, represents the number of consensus completed cumulatively, represents the reputation value of node i in the j-1th round of consensus, and is the corresponding weight.

4. The utility consensus algorithm for archival blockchains of claim 2, wherein, The S12 node is divided into four layers, specifically including the following: UNL layer ( > 80): composed of nodes with the highest reputation value (5%-30% of the total nodes), responsible for executing the complete core consensus protocol. Master nodes are generated from this layer; candidate layer (40 ≤ 80): as a backup of UNL layer, only participate in the last stage of consensus (Reply) to ensure the robustness of the system when there are not enough UNL nodes; Fault layer (20 ≤ 40): low reputation nodes, put in "wait" state, not involved in consensus, need to improve reputation through good behavior; Malicious tier ( ≤ 20): Nodes with very low reputation, considered malicious or severely malfunctioning, will be flagged by the system and a deletion process will be initiated.

5. The utility consensus algorithm for archival blockchains of claim 1, wherein: The S2 is specifically: Election eligibility: when a node's reputation value is above a certain threshold , it is eligible to be a candidate, ensuring the basic reliability of the master node from the source; Random draw: based on the VRF, a verifiable random function (ECVRF) is designed based on the Montgomery curve Curve25519; Result confirmation: the election is not completely equal, the reputation value Ci of the node is converted into "voting weight", the system determines the "number of times" (j value) of each candidate node being selected according to the total reputation value weight and the preset threshold value through the random number generated by ECVRF, assuming that the sum of the reputation values of all nodes is W , that is, there are W small units in total, a threshold τ is set, that is, the number of small units to be selected, and the probability of each small unit being selected is , for a node with a reputation value of , the probability of selecting the k small units owned by it is , which is subject to a binomial distribution, and the [0, 1] interval is divided into w+1 small intervals, denoted as: ； ； Then a random number is generated by ECVRF The system determines the j value that makes e fall into a certain interval X by accumulating the success probability from 0 to a certain j value, the length of the jth interval corresponds to the probability of the corresponding node being selected j times, that is If the random number generated by ECVRF falls into the jth interval, it means that the node i is drawn j times in this draw, when j is 0, it means that the node i fails to draw, and greater than 0 means that the draw is successful, when multiple nodes draw successfully, the node with the largest j value becomes the master node, when the draw values are the same, the node with the smallest number becomes the master node, after the master node is selected successfully, it broadcasts the proof ecvrf_proof to other nodes, after receiving the broadcast, the nodes will use the public key and timestamp of the node and ecvrf_proof to verify and record the verifiable random number, this mechanism introduces randomness to prevent prediction, and through reputation value weighting and cryptographic verification, ensures the rationality and security of the election.

6. The utility consensus algorithm for archival blockchains of claim 5, wherein: The verifiable random function includes a key generation function, a proof generation function and a proof verification function, Key generation function ECVRF_GetKey() -> (public key , private key ): This algorithm generates a key pair (public key , private key ) based on Montgomery curve Curve25519. Let the elliptic curve be over a finite field, with prime number n as the order, and base point G on the elliptic curve; The proof generator function ECVRF_Prove( (e.g., message) → (ecvrf_hash, proof): Given the private key `ski` and the original message `message`, `ECVRF_Prove` derives the key `x` from `ski` and calculates the VRF public key `Y`. Through calculations using functions such as `ECVRF_hash_to_curve`, `ECVRF_nonce_generation`, and `ECVRF_hash_points`, it concatenates these into a random number proof `ecvrf_proof` and a hash value `ecvrf_hash`. `ecvrf_hash` is a pseudo-random string of a hash length uniquely determined by `ski` and `message`, while `ecvrf_proof` can be used by the user... Verification; Proof verification function ECVRF_Verify( , ecvrf_proof, message) → (result): The inputs to the algorithm are the original input message message, a verifiable proof ecvrf_proof, a public key , and a hash function H. The algorithm works by remapping the point H on the elliptic curve, then re-encoding the integer c' and finally comparing c and c' to output the verification result result.​ 7. The utility consensus algorithm for archival blockchains of claim 1, wherein: The S3 specific steps are: S31 request phase, the client C first signs the request, and then sends to the master node, where o represents the operation, i.e., the specific task that the client wants the network to perform; t indicates the timestamp, used to distinguish the order of these commands; c is the number of the client, used to identify the specific client that sends the request; and σi indicates that the client i digitally signs this information to ensure the authenticity of its identity and the legality of the request; S32 pre-preparation stage, the master node signs the request and sends to the UNL node, starting to execute the consistency protocol, when the UNL node receives the Pre-Prepare message, it will perform a series of verification steps to ensure the validity and security of the message, if all the above conditions are met, the UNL node will accept this pre-preparation message and enter the preparation stage; S33 Preparation phase, the UNL node signs the message and replies The message to the master node, when the master node receives the preparation message from other nodes, it will carry out a series of verifications: Confirm that the view sequence number in the message is the same as the view sequence number of the node itself; Check if the sequence number n is within the specified range [h, H]; Verify that the message digest d is the same as the message digest received in the pre-preparation stage; If all the above verifications pass, the node will insert the preparation message into its local log, when a node receives all identical preparation messages, and these messages are the same as the m, v, n of the previously received pre-preparation message, it will consider prepare to be true, and insert this state into its local log, then the node will enter the commit phase; S34 confirmation phase, the master node receives the prepare message, sends to the UNL node, the UNL node starts to execute the request and replies to the master node, the master node receives the UNL node confirmation message, sends the COMMIT message to the backup node, performs confirmation, and other copy nodes verify the digital signature, try sequence number and sequence number after receiving the submission message, and insert the submission message into the local log. Next, the node will check whether the following two conditions are met to determine whether to make the committed-local(m, n, v, i) true judgment: Node i's prepare(m, n, v, i) is true; Node i receives all consistent commit messages, and the m, v, n in these messages are completely the same as the corresponding fields in the local Pre-prepare message, Only when both conditions are met, the node will perform the subsequent commit operation; S35 submission phase, after receiving the confirmation message, the candidate node sends to the client. After receiving the reply message, the client uses the timestamp t to determine which request execution result is, and the client only needs to receive f+1 reply messages with the same execution result (i.e. the same r and t) to consider the execution result to be trusted.

8. The utility consensus algorithm for archival blockchains of claim 7, wherein, The verification steps performed in the pre-preparation stage include: Check if the digital signature of the request is correct; Verify the accuracy of the master node's proof through the proof verification function ECVRF_Verify; Check if the View sequence number in the message is consistent with the current replica node; Verify that the sequence number (n) assigned in the message is unique under the current view; Check if the sequence number (n) is within the specified range [h, H].

9. The utility consensus algorithm for archival blockchains of claim 1, wherein: The S4 is specifically: Reputation value update, when the node participates in the consensus process, the system first calculates the reputation value of the node according to its historical behavior and immediate performance, and the reputation value is improved if the performance is good, otherwise it is decreased, then the system adjusts the level and state of the node, ensuring that the system can quickly respond when facing changes in node behavior; Node promotion and demotion, changes in reputation value will trigger dynamic promotion and demotion of nodes among levels, this mechanism ensures that the consensus group is always composed of the most reliable nodes; Malicious node deletion occurs when the master node detects that the node's reputation value has fallen into the malicious layer. When the threshold is ≤ 20, a deletion vote will be initiated. UNL layer nodes will mutually confirm their selections, and if more than half agree, the node will be removed from the network, thus ensuring the scalability and security of this algorithm.

Images