Hashgraph consensus improvement method and system based on sharding technology

Abstract

The application provides a Hashgraph consensus improvement method and system based on a sharding technology, and comprises the following steps: calculating a CREV by referring to a node's credit, token holding situation, geographical position, network condition and computer resource; assigning a shard to each node according to the node's CREV, and keeping the total sum of the CREVs of the nodes in the shard flat; electing a leader node to participate in consensus according to the CREV, and then re-electing the leader node at the beginning of each time slice; the common nodes are responsible for the consensus of the events in the shard, and the leader node is responsible for pulling the events of other shards and leading the consensus process in the shard; in the shard, an improved Hashgraph consensus algorithm is adopted based on the leader mechanism, and the improved Hashgraph consensus algorithm comprises an improved strong visibility rule of events and a final sequencing method. By using the sharding technology, the application divides the communication of the nodes into a smaller range, improves the event propagation rate and reduces the communication cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a Hashgraph consensus improvement method and system based on sharding technology. BACKGROUND

[0002] Unlike traditional single-chain structures, a DAG (Directed Acyclic Graph) structure-based blockchain is a novel chain structure design, which has the characteristics of high throughput, high scalability and low latency. Hashgraph, as one of the most popular DAG-based consensus algorithms, has good consensus efficiency and is expected to break through the throughput bottleneck of blockchain technology. However, there are problems such as multiple steps, complex process, poor stability, and repeated transaction packaging in the consensus process.

[0003] In order to further improve the consensus efficiency and scalability of Hashgraph, domestic and foreign scholars have proposed a variety of different consensus schemes. Nguyen et al. proposed StakeDAG, which uses PoS+DAG to cross-verify and post-check to achieve the integrity and sustainability of the entire network. Fu et al. added a fixed leader node in Jointgraph to lead the consensus process, simplifying the consensus steps and speeding up the consensus efficiency. Zhou et al. proposed a reputation-based Hashgraph algorithm to solve the problem of over-reliance on centralized nodes in Jointgraph. In order to improve the event propagation rate and scalability of Hashgraph, Gong et al. proposed a mobile ad hoc network blockchain model based on Hashgraph, which divides nodes into clusters of different sizes according to their geographical location and network status. The cluster head improves the consensus efficiency within the cluster, and the routing node improves the event propagation efficiency between clusters. Gao et al. proposed a sharded Hashgraph algorithm based on the sharding idea, introduced a comprehensive evaluation mechanism based on node status, and dynamically sharded a large number of nodes. Each shard uses an improved strong visibility rule to speed up the consensus process and improve scalability.

[0004] Therefore, a new technical scheme needs to be proposed. SUMMARY

[0005] In view of the defects in the prior art, the purpose of the present application is to provide a Hashgraph consensus improvement method and system based on sharding technology.

[0006] According to the Hashgraph consensus improvement method based on sharding technology provided by the present application, the method comprises the following steps:

[0007] Step S1: Calculate the CREV of the node itself by referring to the reputation, token holding, geographical location, network status and computer resources;

[0008] Step S2: Assign a shard to each node according to the CREV of the node, and the total CREV of the nodes in each shard is flat;

[0009] Step S3: In the shard, the nodes elect a leader node according to the CREV to participate in consensus, and then the leader node needs to be re-elected at the beginning of each time slice. The ordinary nodes are responsible for the consensus of intra-shard events, and the leader node is responsible for pulling events from other shards and leading the intra-shard consensus process;

[0010] Step S4: In the shard, an improved Hashgraph consensus algorithm is used based on the leader mechanism, including an improved strong visibility rule of events and a final ordering method.

[0011] Preferably, the step S1 comprises the following steps:

[0012] Step S1.1: Calculate the CREV of the node:

[0013]

[0014] wherein, represents the comprehensive reputation evaluation value of node i in the rth round, represents the ability value of node i in the rth round, represents the average ability value of all nodes in the rth round;

[0015] Step S1.2: The calculation formula is:

[0016]

[0017] wherein, α+τ+β+λ+γ=1, which is dynamically adjusted according to the running state of the system; Gp is determined by the virtual center node generated by the distance clustering algorithm, Ns is obtained according to the average delay of communication with other nodes, T represents the percentage of the node in the system, and Cr refers to the system performance of the node; These are basic attributes of the node, which are directly obtained by the system;

[0018] Step S1.3: The reputation value is determined by the historical performance of the node, and the calculation formula is:

[0019] C i =ε·Ph+θ·Ef+μ·Er

[0020] wherein, ε+θ+μ=α, Ph represents the height of the parallel chain maintained by node i, Ef represents the frequency of event creation of node i, and Er represents the error rate of node i.

[0021] Preferably, the step S3 comprises the following steps:

[0022] Step S3.1: the node performs VRF operation according to the current round and its own private key, the nodes in the slice are sorted according to the public key value and the Hash interval is divided by combining CREV, if the VRF result finally obtained falls within the range divided by itself, the node is elected as the leader node;

[0023] Step S3.2: the leader node can only manage a slice for a period of time, if the leader makes a mistake during the term or the term ends, step S3.1 is re-executed;

[0024] Step S3.3: during the term, the leader node is responsible for pulling the events generated or stored by other slices and participating in the consensus in the slice.

[0025] Preferably, the step S4 comprises the following steps:

[0026] Step S4.1: improved strong visibility rule, each node has CREV, which is used as weight, if event A2 strongly visible event B1, the total sum of CREV held by nodes in the visible path of A2 exceeds 2 / 3 of the total sum in the slice;

[0027] Step S4.2: improved event sequencing rule, the events in the slice are visible to more than 2 / 3 of the nodes in the slice by the leader node; the total sum of CREV of the nodes in the visible path of the event visible to the leader node exceeds 2 / 3 of the total sum in the slice, one of the above two conditions is met, then the event reaches consensus in the slice;

[0028] Step S4.3: between slices, the event is confirmed to be final if it is visible to more than 2 / 3 of the system nodes.

[0029] Preferably, the more than 2 / 3 of the nodes in the slice in step S4.2 includes the leader node.

[0030] The application also provides a Hashgraph consensus improvement system based on the slicing technology, the system comprises the following modules:

[0031] Module M1: the CREV of the node is calculated by referring to the credit, token holding, geographical location, network condition and computer resource of the node;

[0032] Module M2: each node is allocated a slice according to the CREV of the node, and the total sum of the CREV of the nodes in each slice is flat;

[0033] Module M3: in the slice, a leader node is elected according to the CREV of the node to participate in the consensus, then the leader node needs to be re-elected at the beginning of each time slice, the ordinary node is responsible for the consensus of the events in the slice, and the leader node is responsible for pulling the events of other slices and leading the consensus process in the slice;

[0034] Module M4: Within the shard, an improved Hashgraph consensus algorithm is adopted based on the leader mechanism, including improved event strong visibility rules and final ordering system.

[0035] Preferably, the module M1 includes the following modules:

[0036] Module M1.1: CREV of the computing node:

[0037]

[0038] wherein, represents the comprehensive reputation evaluation value of node i in the rth round, represents the capability value of node i in the rth round, represents the average capability value of all nodes in the rth round;

[0039] Module M1.2: The calculation formula is:

[0040]

[0041] wherein, α + τ + β + λ + γ = 1, dynamically adjusted according to the running state of the system; Gp is determined by the virtual center node generated by the distance clustering algorithm, Ns is obtained according to the average delay of communication with other nodes, T represents the percentage of the node in the system, and Cr refers to the system performance of the node; these are basic attributes of the node, obtained directly by the system;

[0042] Module M1.3: The reputation value is determined by the historical performance of the node, and the calculation formula is:

[0043] C i = ε·Ph + θ·Ef + μ·Er

[0044] wherein, ε + θ + μ = α, Ph represents the parallel chain height maintained by node i, Ef represents the frequency of event creation by node i, and Er represents the error rate of node i.

[0045] Preferably, the module M3 includes the following modules:

[0046] Module M3.1: The node performs VRF operation according to the current round and its own private key, and the nodes in the shard are sorted according to the public key value and divided into Hash intervals combined with CREV, if the finally derived VRF result falls within the range divided by itself, then it is elected as the leader node;

[0047] Module M3.2: The leader node can only manage a certain period of shards, if the leader makes a mistake during the term or the term ends, then the module M3.1 is re-executed;

[0048] Module M3.3: During the term, the leader node is responsible for pulling the events generated or stored by other shards and participating in intra-shard consensus.

[0049] Preferably, the module M4 includes the following modules:

[0050] Module M4.1: Improved strong visibility rule, each node has a CREV, which is used as a weight, if event A2 strongly visible event B1, then the sum of the CREV held by the nodes in its visible path exceeds 2 / 3 of the total sum within the shard;

[0051] Module M4.2: Improved event sequencing rule, events within the shard are visible to more than 2 / 3 of the intra-shard nodes by the leader node; the leader node can see the CREV sum of the nodes in the visible path of the event, which exceeds 2 / 3 of the total sum within the shard, one of the above two conditions is met, then the event reaches consensus within the shard;

[0052] Module M4.3: Between shards, the event is confirmed final if it is visible to more than 2 / 3 of the system nodes.

[0053] Preferably, the module M4.2 includes the leader node in the intra-shard event visible to more than 2 / 3 of the intra-shard nodes.

[0054] Compared with the prior art, the present application has the following beneficial effects:

[0055] 1. The present application divides the communication of nodes into a smaller range by using the shard technology, improves the event propagation rate, and reduces the communication overhead;

[0056] 2. The present application improves the system throughput and reduces the time delay by using the leader mechanism in the shard to participate in the consensus process;

[0057] 3. The present application more effectively reflects the ability value and credibility of the node and predicts the probability of node error by designing the CREV formula;

[0058] 4. The present application more fairly and reasonably elects the leader node by referring to the CREV of the node and using VRF, reduces the possibility of Byzantine behavior, and improves the system stability. BRIEF DESCRIPTION OF DRAWINGS

[0059] Other features, objects and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments, read in conjunction with the accompanying drawings:

[0060] Figure 1 Figure 1 is a node gossip communication model diagram of the present application;

[0061] Figure 2Figure for leader election algorithm of the present application;

[0062] Figure 3 Figure for leader node operation algorithm of the present application;

[0063] Figure 4 Figure for event sequencing of the present application. DETAILED DESCRIPTION

[0064] The present application will be described in detail below with specific embodiments. The following embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any form. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present application. These are within the scope of the present application.

[0065] Example 1:

[0066] According to the Hashgraph consensus improvement method based on the sharding technology provided by the present application, the method comprises the following steps:

[0067] Step S1: Calculate the CREV of itself by the reference reputation degree, token holding condition, geographical position, network condition and computer resource of the node;

[0068] Step S1.1: Calculate the CREV of the node:

[0069]

[0070] wherein, represents the comprehensive reputation evaluation value of the node i in the rth round, represents the ability value of the node i in the rth round, represents the average ability value of all nodes in the rth round;

[0071] Step S1.2: The calculation formula of is:

[0072]

[0073] wherein, α+τ+β+λ+γ=1, which is dynamically adjusted according to the running state of the system; Gp is determined by the virtual center node generated by the distance clustering algorithm, Ns is obtained according to the average delay of communication with other nodes, T represents the percentage of the node in all systems, and Cr refers to the system performance of the reference node; these are the basic attributes of the node, which are directly obtained by the system;

[0074] Step S1.3: The reputation value is determined by the historical performance of the node, and the calculation formula is:

[0075] C i= ε · Ph + θ · Ef + μ · Er

[0076] Wherein, ε + θ + μ = α, Ph represents the parallel chain height maintained by node i, Ef represents the frequency of event created by node i, and Er represents the error rate of node i.

[0077] Step S2: Assign a shard to each node according to the CREV of the node, and the CREV of the nodes in each shard is equal in total;

[0078] Step S3: In the shard, the node elects a leader node to participate in consensus according to the CREV, and then needs to re-elect the leader node at the beginning of each time slice, and the ordinary node is responsible for the consensus of the events in the slice, and the leader node is responsible for pulling the events of other shards and leading the consensus process in the slice;

[0079] Step S3.1: The node performs VRF operation according to the current round and its own private key, and the nodes in the shard are sorted according to the public key value and divided into Hash intervals according to the CREV, if the VRF result finally obtained falls within the range divided by itself, then the leader node is elected;

[0080] Step S3.2: The leader node can only manage a shard for a period of time, if the leader has an error during the term or the term ends, then step S3.1 is re-executed;

[0081] Step S3.3: During the term, the leader node is responsible for pulling the events generated or stored by other shards that have not been learned and participating in the consensus in the slice.

[0082] Step S4: In the shard, an improved Hashgraph consensus algorithm is used based on the leader mechanism, including an improved strong visibility rule of event and a final ordering method;

[0083] Step S4.1: Improved strong visibility rule, each node has CREV, which is used as weight, if event A2 strongly visible event B1, then the CREV held by the nodes in the visible path of A2 exceeds 2 / 3 of the total sum in the shard;

[0084] Step S4.2: Improved event ordering rule, the events in the shard are visible to more than 2 / 3 of the nodes in the shard (including the leader node) by the leader node; the leader node can see the CREV of the nodes in the visible path of the event, which exceeds 2 / 3 of the total sum in the shard, and one of the above two conditions is met, then the event reaches consensus in the shard;

[0085] Step S4.3: Between shards, the event is visible to more than 2 / 3 of the system nodes to confirm finality.

[0086] The application also provides a Hashgraph consensus improvement system based on a sharding technology, which can be implemented by performing the process steps of the Hashgraph consensus improvement method based on the sharding technology, that is, the Hashgraph consensus improvement method based on the sharding technology can be understood by those skilled in the art as a preferred embodiment of the Hashgraph consensus improvement system based on the sharding technology.

[0087] Example 2:

[0088] The application also provides a Hashgraph consensus improvement system based on a sharding technology, which comprises the following modules:

[0089] Module M1: calculate the CREV of itself by the reference reputation, token holding, geographical location, network condition and computer resource of the node;

[0090] Module M1.1: calculate the CREV of the node:

[0091]

[0092] wherein, represents the comprehensive reputation evaluation value of the node i in the rth round, represents the capability value of the node i in the rth round, represents the average capability value of all nodes in the rth round;

[0093] Module M1.2: The calculation formula of is:

[0094]

[0095] wherein, alpha + tau + beta + lambda + gamma = 1, which is dynamically adjusted according to the running state of the system; Gp is determined by the virtual center node generated by the distance clustering algorithm, Ns is obtained according to the average delay of communication with other nodes, T represents the percentage of the node in the system, and Cr refers to the system performance of the reference node; these are the basic attributes of the node, which are directly obtained by the system;

[0096] Module M1.3: the reputation value is determined by the historical performance of the node, and the calculation formula is:

[0097] C i = epsilon * Ph + theta * Ef + mu * Er

[0098] wherein, epsilon + theta + mu = alpha, Ph represents the height of the parallel chain maintained by the node i, Ef represents the frequency of the event created by the node i, and Er represents the error rate of the node i.

[0099] Module M2: Each node is assigned a shard according to its CREV, and the sum of the CREVs of the nodes in each shard is flat;

[0100] Module M3: Within a shard, nodes elect a leader node to participate in consensus according to the CREV, and then need to re-elect a leader node at the beginning of each time slice. Ordinary nodes are responsible for the consensus of intra-shard events, and leader nodes are responsible for pulling events from other shards and leading the intra-shard consensus process;

[0101] Module M3.1: Nodes perform VRF operations according to the current round and their own private keys. Nodes within a shard are sorted according to the public key value and divided into Hash intervals according to the CREV. If the final VRF result falls within the range divided by itself, it is elected as a leader node;

[0102] Module M3.2: A leader node can only manage a shard for a period of time. If the leader makes a mistake during the term or the term ends, module M3.1 is re-executed;

[0103] Module M3.3: During the term, the leader node is responsible for pulling events generated or stored by other shards that have not been learned and participating in intra-shard consensus.

[0104] Module M4: Within a shard, an improved Hashgraph consensus algorithm is used based on the leader mechanism, including an improved strong visibility rule for events and a final ordering system;

[0105] Module M4.1: Improved strong visibility rule. Each node has a CREV, which is used as a weight. If event A2 strongly visible event B1, then the sum of the CREVs held by the nodes in its visible path exceeds 2 / 3 of the total sum within the shard;

[0106] Module M4.2: Improved event ordering rule. Events within a shard are visible to more than 2 / 3 of the nodes within the shard (including leader nodes) by the leader node. The leader node can see the CREV sum of the nodes in the visible path of the event, which exceeds 2 / 3 of the total sum within the shard. If one of the above two conditions is met, the event reaches consensus within the shard;

[0107] Module M4.3: Between shards, an event is confirmed to be final if it is visible to more than 2 / 3 of the system nodes.

[0108] Example 3:

[0109] In the alliance chain, the improved Hashgraph consensus layer model is used to improve the throughput, scalability and consensus delay of the system. First, the nodes of the whole system are divided into several sub-networks according to their comprehensive reputation evaluation value (CREV), the number of neighbor nodes of the node communication is reduced, and the event propagation rate is improved. Then a leader node is selected in each shard by using a verifiable random function (VRF) to speed up the consensus efficiency in the shard, thereby improving the overall performance of the system, including the following steps:

[0110] Step 1: The node calculates its own CREV by referring to the reputation, token holding, geographic location, network status and computer resources.

[0111] Step 2: The system assigns a shard to each node according to the CREV of the node, and ensures that the total CREV of the nodes in each shard is basically flat.

[0112] Step 3: In the shard, a leader node is randomly and fairly elected according to the CREV to participate in the consensus, and then a leader node needs to be re-elected at the beginning of each time slice. The ordinary node is responsible for the consensus of the intra-shard event, and the leader is responsible for pulling the events of other shards and leading the intra-shard consensus process.

[0113] Step 4: In the shard, an improved Hashgraph consensus algorithm is used based on the leader mechanism, including the improved strong visibility rule of the event and the final sequencing method.

[0114] The step 1 includes the following steps:

[0115] Step 1.1: Calculate the CREV of the node, wherein, represents the comprehensive reputation evaluation value of the node i in the rth round, represents the ability value of the node i in the rth round, represents the average ability value of all nodes in the rth round.

[0116] Step 1.2: The calculation formula of is wherein, α+τ+β+λ+γ=1, which can be dynamically adjusted according to the running state of the system. Gp is determined by the virtual center node generated by the distance clustering algorithm, NS is obtained according to the average delay of communication with other nodes, T represents the percentage of the node in the system, and Cr refers to the system performance of the node. These are the basic attributes of the node, which can be directly obtained by the system.

[0117] Step 1.3: The reputation value is determined by the historical performance of the node, and the calculation formula is C i= ε*Ph + θ*Ef + μ*Er. Wherein, ε + θ + μ = α, Ph represents the parallel chain height maintained by the node i, Ef represents the frequency of event created by the node i, and Er represents the error rate of the node i.

[0118] The step 3 comprises the following steps:

[0119] Step 3.1: The node performs VRF operation according to the current round and the private key of the node itself, the nodes in the shard are sorted according to the public key value and the Hash interval is divided in combination with CREV, and if the finally derived VRF result falls within the range divided by the node itself, the node is elected as the leader node. The leader election algorithm is as follows:

[0120]

[0121] Step 3.2: The leader node can only manage a certain period of time of the shard, if the leader makes a mistake during the term or the term ends, then step 3.1 is re-executed.

[0122] Step 3.3: During the term, the leader is responsible for pulling the events generated or stored by other shards that have not been learned and participating in intra-shard consensus. The leader node runs the algorithm as follows:

[0123]

[0124] The step 4 comprises the following steps:

[0125] Step 4.1: Improved strong visibility rule: each node has a CREV, which is used as a weight, if event A2 strongly visible event B1, then the total sum of CREV held by the nodes in the visible path exceeds 2 / 3 of the total sum in the shard.

[0126] Step 4.2: Improved event sequencing rule: 1. The events in the shard are visible to more than 2 / 3 of the nodes in the shard (including the leader node) by the leader node. The leader can see the total sum of CREV of the nodes in the visible path of the event, which exceeds 2 / 3 of the total sum in the shard. One of the above two conditions is met, then the event reaches consensus in the shard.

[0127] Step 4.3: Between shards, the event is visible to more than 2 / 3 of the system nodes to confirm finality.

[0128] Those skilled in the art can understand the present embodiment as a more specific description of embodiment 1 and embodiment 2.

[0129] Those skilled in the art know that, in addition to implementing the system provided by the present application and each device, module and unit thereof in the form of pure computer readable program code, the system provided by the present application and each device, module and unit thereof can also be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. by logically programming the method steps to achieve the same functions. Therefore, the system provided by the present application and each device, module and unit thereof can be considered as a hardware component, and the devices, modules and units included therein for achieving various functions can also be considered as structures within the hardware component; the devices, modules and units for achieving various functions can also be considered as both software modules implementing methods and structures within hardware components.

[0130] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other in any manner without conflict.

Claims

1. A Hashgraph consensus improvement method based on sharding technology, characterized in that: The method comprises the following steps: Step S1: Calculate the node's CREV by referring to its reputation, token holdings, geographical location, network status, and computer resources. The CREV represents the comprehensive reputation evaluation value. Step S2: Allocate a shard to each node based on its CREV, and keep the sum of the CREVs of the nodes in each shard equal. Step S3: Within the shard, nodes elect a leader node based on CREV to participate in the consensus. The leader node needs to be re-elected at the beginning of each time slice. Ordinary nodes are responsible for the consensus of events within the shard, and the leader node is responsible for pulling events from other shards and leading the consensus process within the shard. Step S4: Within the shard, an improved Hashgraph consensus algorithm is adopted based on the leader mechanism, including improved event visibility rules and final ordering methods; The step S4 comprises the following steps: Step S4.1: Improved strong visibility rule: each node has a CREV, which is used as a weight. If event A2 strongly sees event B1, the sum of the CREVs held by the nodes in its visible path exceeds 2 / 3 of the total in the shard. Step S4.2: Improved event sequencing rules: An event within a shard is visible to the leader node through more than 2 / 3 of the nodes within the shard; the sum of the CREVs of the nodes in the leader node's visible path to the event exceeds 2 / 3 of the total within the shard. If either of the above two conditions is met, the event reaches consensus within the shard; Step S4.3: Finality is confirmed when the event is visible to more than 2 / 3 of the system nodes across the shards.

2. The Hashgraph consensus improvement method based on sharding technology according to claim 1 is characterized in that: The step S1 comprises the following steps: Step S1.1: Calculate the CREV of the node: in, represents the comprehensive reputation evaluation value of node i in the rth round, represents the capability value of node i in the rth round, represents the average capability value of all nodes in round r; Step S1.2: The calculation formula is: Where α + T + β + λ + γ = 1, which is dynamically adjusted based on the system's operating status. Gp is ​​determined by the virtual central node generated by the distance clustering algorithm, Ns is obtained based on the average communication delay with other nodes, T represents the percentage of nodes in the system, and Cr refers to the system performance of the reference node. These are basic node attributes and are directly obtained by the system. Step S1.3: The reputation value is determined by the node's historical performance and is calculated as follows: C i =ε·Ph+θ·Ef+μ·Er Among them, ε+θ+μ=α, Ph represents the height of the parallel chain maintained by node i, Ef represents the frequency of events created by node i, and Er represents the error rate of node i.

3. The Hashgraph consensus improvement method based on sharding technology according to claim 1 is characterized in that: The step S3 comprises the following steps: Step S3.1: The node performs a VRF calculation based on the current round and its own private key. The nodes in the shard are sorted by the size of the public key value and the hash interval is divided by CREV. If the final VRF result falls within the range of its own division, it is elected as the leader node; Step S3.2: The leader node can only manage shards for a period of time. If an error occurs during the leader's term or the term ends, step S3.1 is executed again. Step S3.3: During its term, the leader node is responsible for pulling unlearned events generated or stored by other shards and participating in the intra-shard consensus.

4. The Hashgraph consensus improvement method based on sharding technology according to claim 1 is characterized in that: In step S4.2, the events within the shard pass through more than 2 / 3 of the nodes within the shard, including the leader node.

5. A Hashgraph consensus improvement system based on sharding technology, characterized by: The system includes the following modules: Module M1: Calculates the node's CREV by considering its reputation, token holdings, geographic location, network status, and computer resources. CREV represents the comprehensive reputation evaluation value. Module M2: Assign a shard to each node based on its CREV, ensuring that the sum of the CREVs of the nodes in each shard is the same; Module M3: Within a shard, nodes elect a leader node based on CREV to participate in consensus. A new leader node is then required at the beginning of each time slice. Ordinary nodes are responsible for consensus on events within the shard, while the leader node is responsible for pulling events from other shards and leading the consensus process within the shard. Module M4: Within the shard, an improved Hashgraph consensus algorithm is adopted based on the leader mechanism, including improved event visibility rules and final ordering system; The module M4 includes the following modules: Module M4.1: Improved strong visibility rule. Each node has a CREV, which is used as a weight. If event A2 strongly sees event B1, the sum of the CREVs held by the nodes in its visible path exceeds 2 / 3 of the total in the shard. Module M4.2: Improved event sequencing rules: Events within a shard are visible to the leader node through more than 2 / 3 of the nodes within the shard; the sum of the CREVs of the nodes in the visible path that the leader node can see the event exceeds 2 / 3 of the total within the shard. If either of the above two conditions is met, the event reaches consensus within the shard; Module M4.3: Across shards, an event is considered final if it is visible to more than 2 / 3 of the system nodes.

6. The Hashgraph consensus improvement system based on sharding technology according to claim 5 is characterized in that: The module M1 includes the following modules: Module M1.1: CREV of computing nodes: in, represents the comprehensive reputation evaluation value of node i in the rth round, represents the capability value of node i in the rth round, represents the average capability value of all nodes in round r; Module M1.2: The calculation formula is: Where α + T + β + λ + γ = 1, which is dynamically adjusted based on the system's operating status. Gp is ​​determined by the virtual central node generated by the distance clustering algorithm, Ns is obtained based on the average communication delay with other nodes, T represents the percentage of nodes in the system, and Cr refers to the system performance of the reference node. These are basic node attributes and are directly obtained by the system. Module M1.3: The reputation value is determined by the node's historical performance, and the calculation formula is: C i =ε·Ph+θ·Ef+μ·Er Among them, ε+θ+μ=α, Ph represents the height of the parallel chain maintained by node i, Ef represents the frequency of events created by node i, and Er represents the error rate of node i.

7. The Hashgraph consensus improvement system based on sharding technology according to claim 5 is characterized in that: The module M3 includes the following modules: Module M3.1: The node performs VRF calculation based on the current round and its own private key. The nodes in the shard are sorted according to the size of the public key value and the hash interval is divided by CREV. If the final VRF result falls within the range of the self-divided range, it is elected as the leader node; Module M3.2: The leader node can only manage shards for a period of time. If an error occurs during the leader's term or the term ends, module M3.1 will be re-executed. Module M3.3: During its term, the leader node is responsible for pulling unlearned events generated or stored by other shards and participating in the intra-shard consensus.

8. The Hashgraph consensus improvement system based on sharding technology according to claim 5 is characterized in that: In the module M4.2, events within the shard pass through more than 2 / 3 of the nodes within the shard, including the leader node.

Images