A consortium chain dynamic consensus and permission management method and system

Abstract

The application discloses a kind of alliance chain dynamic consensus and permission management method and system, specifically related to data editing and access control technical field, for solving the problem that the editing permission management in existing alliance chain depends on static allocation and cannot be dynamically adjusted with node consensus behavior;By using the abnormal trigger type consensus member updating mechanism in the consensus group, generate temporary reputation marks based on the consistency of historical consensus interaction snapshot comparison behavior to update the consensus committee, and use the chameleon hash function of lattice cryptography to establish a layered identity and delegate revocable key pair for the nodes of the consensus committee, simulate the editing request in the sandbox state copy by the editing center and calculate the editing disturbance index to dynamically trim the operation range, write the editing transaction into the blockchain after submitting the consensus committee consensus through the main node, revoke the editing permission of the node when it is removed from the consensus committee due to temporary reputation marks, so as to realize the real-time linkage and fine-grained dynamic control of editing permission and node consensus behavior.

Description

Technical Field

[0001] This invention relates to the field of data editing and access control technology, and more specifically, to a method and system for dynamic consensus and permission management in consortium blockchains. Background Technology

[0002] The immutability of blockchain data in consortium blockchains means that erroneous and invalid data cannot be corrected or deleted, accumulating over time and consuming storage resources, increasing the query burden. To address this issue, existing solutions introduce chameleon hash functions to enable block content editing. However, the trapdoor keys are typically held by fixed nodes or distributed through static secret sharing, lacking linkage with the consensus process and failing to dynamically adjust editing permissions based on node behavior during consensus. Furthermore, mainstream consortium blockchains use a fixed set of consensus members, making it difficult to promptly replace malicious or faulty nodes during operation, leading to a decline in consensus security over time. The disconnect between the granting and revocation of editing permissions and the dynamic behavior of nodes makes it difficult to effectively control the risk of permission abuse.

[0003] In existing consortium blockchains, the granting and revocation of editing permissions rely on static allocation or off-chain negotiation, which lacks linkage with the real-time behavior status of nodes reflected by the consensus mechanism. This results in the permission status not being able to adaptively adjust to the dynamic performance of nodes participating in consensus, such as honesty and activity. Consequently, nodes with abnormal behavior can still hold data editing capabilities for a long time, making it difficult to achieve fine-grained dynamic control over editing permissions while maintaining consensus security. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method and system for dynamic consensus and permission management of consortium blockchains to solve the problems mentioned in the background art.

[0005] A method for dynamic consensus and permission management in consortium blockchains includes:

[0006] S1: Cluster the nodes of the consortium blockchain to build a consensus group and determine the editing center;

[0007] S2: Nodes within the consensus group remain silent. When a consensus anomaly is detected, a snapshot of the historical consensus interactions of the involved nodes is obtained. Behavioral consistency is compared to generate a temporary reputation mark to update the consensus committee and determine the master node. The temporary reputation mark is cleared after the anomaly is eliminated.

[0008] S3: Use lattice cryptography to construct a chameleon hash function to generate public parameters and a master key, establish hierarchical identities for consensus committee nodes, and have the parent node delegate key pairs containing trapdoor keys and revocable subordinate keys to the child nodes;

[0009] S4: The editing center will simulate the received editing request in a sandbox state copy, calculate the editing disturbance index, and trim the allowed operation range of this editing request according to the editing disturbance index;

[0010] S5: After the editing center verifies that the editing request is within the scope of operation, it generates an editing transaction and submits it to the consensus committee via the master node;

[0011] S6: The consensus committee writes the consensus on the edited transaction to the blockchain. When a node is removed from the consensus committee due to a temporary reputation mark, the trapdoor key and revocable subordinate key of the node are revoked.

[0012] Furthermore, consensus groups are constructed by clustering consortium blockchain nodes, and an editing center is determined, including:

[0013] Collect the service capability attributes and historical behavior attributes of consortium blockchain nodes, and establish node attribute feature vectors;

[0014] Calculate the distance between node attribute feature vectors and classify nodes whose distances meet preset conditions into the same consensus mechanism;

[0015] Calculate the distance between each consensus mechanism, and form a consensus group by combining the consensus mechanisms that are closest to the central consensus mechanism with the central consensus mechanism; thus obtaining multiple consensus groups.

[0016] The central consensus mechanism was designated as the editing center.

[0017] Furthermore, nodes within the consensus group remain silent. When a consensus anomaly is detected, a snapshot of the historical consensus interactions of the involved nodes is obtained. Behavioral consistency is compared to generate temporary reputation markers to update the consensus committee and determine the master node. After the anomaly is resolved, the temporary reputation markers are cleared, including:

[0018] Nodes within the consensus group remain silent and do not actively calculate reputation values;

[0019] If a view switching timeout or proposal conflict is detected, it is determined to be a consensus anomaly.

[0020] Extract the voting records and message signatures of nodes involved in consensus anomalies within a preset time window to form a snapshot of historical consensus interactions;

[0021] The voting behavior of nodes involved in consensus anomalies in the historical consensus interaction snapshot is compared with the voting behavior of other nodes in the consensus group in the same historical consensus interaction snapshot to generate a temporary reputation tag.

[0022] Nodes whose temporary reputation markers indicate inconsistency are removed from the consensus committee. The master node is determined from the nodes whose temporary reputation markers indicate consistency according to the original order. The consensus committee seats of the removed nodes are filled by nodes within the consensus mechanism that have not been marked.

[0023] Once the consensus anomaly is resolved, all temporary reputation markers are cleared, and the node returns to a silent state.

[0024] Furthermore, a chameleon hash function is constructed using lattice cryptography to generate public parameters and a master key, establishing hierarchical identities for consensus committee nodes. Parent nodes delegate key pairs containing trapdoor keys and revocable subordinate keys to child nodes, including:

[0025] Discrete Gaussian sampling is performed on the lattice, and a chameleon hash function is constructed based on the sampling results to generate common parameters and a master key. The common parameters include matrix parameters and error distribution parameters.

[0026] Hierarchical identities are established according to the hierarchical relationship of nodes in the consensus committee. Nodes at higher levels are designated as parent nodes, and nodes at lower levels are designated as child nodes. The hierarchical identity identifier of a child node is the hierarchical identity identifier of its parent node plus a suffix.

[0027] The parent node runs the slave key algorithm, taking the public parameters and the master key as input, to generate the slave public key and revocable slave key for the child node;

[0028] The parent node uses the child node's subordinate public key, revocable subordinate key, and hierarchical identity identifier to generate a public key and trapdoor key for the child node, and then delegates the trapdoor key and revocable subordinate key as a key pair to the child node.

[0029] Furthermore, the parent node runs the slave key algorithm, taking the public parameters and master key as input, to generate the child node's slave public key and revocable slave key, including:

[0030] The parent node takes the public parameters, master key, and hierarchical identity of the child node as input, and performs discrete Gaussian sampling on the lattice to obtain the subordinate private key;

[0031] The parent node performs matrix operations on the subordinate private key and the matrix parameters in the public parameters to generate the subordinate public key of the child node;

[0032] The parent node performs fragmentation on the subordinate private key to obtain a revocable subordinate key, which contains key fragments and revocation verification tags.

[0033] Furthermore, the editing center simulates the received editing request in a sandbox state copy, calculates the editing perturbation index, and trims the allowed operation range for this editing request according to the editing perturbation index, including:

[0034] The editing center receives editing requests initiated by nodes holding trapdoor keys. The editing request includes the transaction identifier to be edited, the editing type, and the editing content.

[0035] A sandbox state copy is created based on the current blockchain ledger. An edit request is executed in the sandbox state copy. The hash change of the state data in the sandbox state copy before and after the execution is recorded. After the execution, an attempt is made to roll back the sandbox state copy with the reverse operation of the edit request. The hash difference between the state data after the rollback and the state data before the execution is recorded as the reversible residual.

[0036] The hash change and the invertible residual are nonlinearly fused to generate the edit perturbation index;

[0037] In the sandbox state copy, the edit type and edit content of the edit request are adjusted multiple times. The edit disturbance index corresponding to each adjustment is calculated. The combination with the edit disturbance index lower than the preset disturbance threshold and the smallest adjustment range of edit type and edit content is selected to determine the allowed operation range of this edit request.

[0038] Furthermore, the editing center nonlinearly fuses the hash change and the reversibility residual to generate an editing perturbation index, including:

[0039] The editing center normalizes the hash change and the reversibility residual respectively to obtain the normalized hash change and the normalized reversibility residual;

[0040] The editing center nonlinearly fuses the normalized hash change and the normalized invertible residual into the gating function. The marginal impact of the changes in the normalized hash change and the normalized invertible residual in the gating function on the fusion result varies nonlinearly with the value of the other.

[0041] The editing center uses the output value of the gating function as the editing disturbance index.

[0042] Furthermore, after verifying that the edit request is within the operational scope, the edit center generates an edit transaction, which is then submitted to the consensus committee via the master node, including:

[0043] The editing center obtains the scope of operations allowed for this editing request, which includes the allowed editing types and the set of fields that can be modified;

[0044] The editing center compares the editing type in the received editing request with the allowed editing types, and compares the editing content in the editing request with the set of fields that can be modified;

[0045] The editing center determines that the editing request is within the scope of operation when the editing type is an allowed editing type and the editing content belongs to the set of fields that can be modified.

[0046] After the editing center attaches an operation scope summary to the editing request that is determined to be within the operation scope, it generates an editing transaction;

[0047] The editing center sends the editing transaction to the master node, which then encapsulates the editing transaction into a consensus proposal and submits it to the consensus committee.

[0048] Furthermore, after the consensus committee reaches a consensus on the edited transactions, it writes them to the blockchain. When a node is removed from the consensus committee due to a temporary reputation marker, the node's trapdoor key and revocable subordinate key are revoked, including:

[0049] The consensus committee receives consensus proposals containing edit transactions submitted by the master node. Each node in the consensus committee verifies the edit transactions and broadcasts voting messages.

[0050] After collecting a preset number of voting messages, the consensus committee will write the edited transaction to the blockchain;

[0051] After the edited transaction is written to the blockchain, check the nodes that were removed from the consensus committee due to inconsistency indicated by the temporary reputation tag;

[0052] For nodes removed from the consensus committee, the node's parent node runs a key update algorithm to revoke the node's trapdoor key and revocable slave key.

[0053] On the other hand, the present invention provides a consortium blockchain dynamic consensus and permission management system, comprising:

[0054] The group building module is used to cluster consortium blockchain nodes to build consensus groups and determine the editing center;

[0055] The anomaly triggering module is used to silence nodes within the consensus group. When a consensus anomaly is detected, it obtains a snapshot of the historical consensus interactions of the nodes involved, compares the consistency of behavior to generate a temporary reputation mark to update the consensus committee and determine the master node. After the anomaly is eliminated, the temporary reputation mark is cleared.

[0056] The key delegation module is used to construct a chameleon hash function using lattice cryptography to generate public parameters and a master key, establish hierarchical identities for consensus committee nodes, and delegate key pairs containing trapdoor keys and revocable subordinate keys to child nodes from parent nodes.

[0057] The sandbox simulation module is used by the editing center to simulate the received editing requests in a sandbox state copy, calculate the editing disturbance index, and trim the allowed operation range of the current editing request according to the editing disturbance index;

[0058] The verification and submission module is used by the editing center to verify that the editing request is within the scope of operation, generate an editing transaction, and submit it to the consensus committee via the master node.

[0059] The consensus revocation module is used to write the consensus of the edited transaction to the blockchain after the consensus committee has reached a consensus. When a node is removed from the consensus committee due to a temporary reputation mark, the trapdoor key and revocable subordinate key of the node are revoked.

[0060] Compared with the prior art, the present invention has the following beneficial effects:

[0061] 1. By linking the management of editing permissions with the consensus process, and adopting an anomaly-triggered dynamic consensus member update mechanism within the consensus group, the granting and revocation of editing permissions are directly linked to the consistent behavior of nodes in the consensus. When a consensus anomaly occurs, the system transitions from a silent state to an evaluation state, objectively judging node behavior based on historical consensus interaction snapshots rather than relying on continuous reputation scores. This avoids the malicious exploitation of predictable evaluation cycles. The permission status is adjusted synchronously with changes in consensus committee members, and the editing permissions of nodes removed from the committee are immediately invalidated. This achieves an automated closed loop from consensus behavior monitoring to editing permission revocation, solving the problem of permission management lagging behind the dynamic performance of nodes.

[0062] 2. The scope control of editing permissions does not rely on static role pre-assignment. Instead, it uses pre-execution and rollback tests of edits in sandbox state replicas to quantitatively assess the degree of disturbance of editing operations on blockchain state data. Based on the degree of disturbance, the scope of operations allowed for this editing request is dynamically trimmed, ensuring that each editing operation is limited to a controllable boundary of impact on the ledger. The hierarchical identity and key delegation mechanism allocates editing permissions level by level according to the committee nodes. Combined with the sharded structure of revocable subordinate keys, it supports targeted revocation of permissions for specific nodes without rebuilding the entire key system. Without changing the public verification characteristics of consortium blockchain data, it provides fine-grained dynamic permission control capabilities with a quantum computing-resistant security foundation. Attached Figure Description

[0063] Figure 1 This is a flowchart of a method for dynamic consensus and permission management in a consortium blockchain according to the present invention;

[0064] Figure 2 This is a schematic diagram of the structure of a consortium blockchain dynamic consensus and permission management system according to the present invention. Detailed Implementation

[0065] 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.

[0066] Example 1: Figure 1 This invention presents a method for dynamic consensus and permission management in consortium blockchains, comprising:

[0067] S1: Cluster the nodes of the consortium blockchain to build a consensus group and determine the editing center;

[0068] S2: Nodes within the consensus group remain silent. When a consensus anomaly is detected, a snapshot of the historical consensus interactions of the involved nodes is obtained. Behavioral consistency is compared to generate a temporary reputation mark to update the consensus committee and determine the master node. The temporary reputation mark is cleared after the anomaly is eliminated.

[0069] S3: Use lattice cryptography to construct a chameleon hash function to generate public parameters and a master key, establish hierarchical identities for consensus committee nodes, and have the parent node delegate key pairs containing trapdoor keys and revocable subordinate keys to the child nodes;

[0070] S4: The editing center will simulate the received editing request in a sandbox state copy, calculate the editing disturbance index, and trim the allowed operation range of this editing request according to the editing disturbance index;

[0071] S5: After the editing center verifies that the editing request is within the scope of operation, it generates an editing transaction and submits it to the consensus committee via the master node;

[0072] S6: The consensus committee writes the consensus on the edited transaction to the blockchain. When a node is removed from the consensus committee due to a temporary reputation mark, the trapdoor key and revocable subordinate key of the node are revoked.

[0073] In implementing S1, the service capability attributes and historical behavior attributes of each node in the consortium blockchain are collected. Service capability attributes include the node's computing power, storage capacity, and network bandwidth metrics. Historical behavior attributes include the node's consensus voting accuracy, online time percentage, and message response latency within a preset statistical period. A node attribute feature vector is established for each node. The dimensions of the node attribute feature vector correspond to the collected attribute categories, and each component of the node attribute feature vector takes a quantized value corresponding to the attribute category. The quantized values ​​are normalized and mapped to a numerical range of 0 to 1.

[0074] The normalized quantized value of the computing power index is calculated as: ci = Ci / Cmax; where ci represents the quantized value of the computing power index of the i-th node, Ci represents the original value of the computing power index of the i-th node, and Cmax represents the maximum value of the original values ​​of the computing power index of all nodes in the consortium blockchain.

[0075] The normalized quantized value of the storage capacity index is calculated as: si = Si / Smax; where si represents the quantized value of the storage capacity index of the i-th node, Si represents the original value of the storage capacity index of the i-th node, and Smax represents the maximum value of the original values ​​of the storage capacity index of all nodes in the consortium blockchain.

[0076] The normalized quantized value of the network bandwidth indicator is calculated as: bi = Bi / Bmax; where bi represents the quantized value of the network bandwidth indicator of the i-th node, Bi represents the original value of the network bandwidth indicator of the i-th node, and Bmax represents the maximum value of the original values ​​of the network bandwidth indicator of all nodes in the consortium blockchain.

[0077] The consensus voting accuracy rate and online time percentage are retained as the corresponding quantitative values, and the original percentage values ​​are already in the range of 0 to 1.

[0078] The normalized quantized value of message response latency is calculated as: di = (1 / Di) / max(1 / Dj); where di represents the quantized value of message response latency of the i-th node, Di represents the original value of message response latency of the i-th node, max(1 / Dj) represents the maximum value of the reciprocal of message response latency of all nodes in the consortium chain, and j iterates through all nodes in the consortium chain.

[0079] The node attribute feature vector of the i-th node is formed by the above quantization values.

[0080] For all nodes in the consortium blockchain, calculate the distance between the feature vectors of node attributes for each pair of nodes. The distance between node attribute feature vectors is calculated as follows: Where dist(vp,vq) represents the distance between the node attribute feature vectors of the p-th node and the q-th node, vpk represents the k-th component of the node attribute feature vector of the p-th node, vqk represents the k-th component of the node attribute feature vector of the q-th node, and the summation symbol ∑ sums all k dimensions of the node attribute feature vector.

[0081] The calculated distance values ​​are compared with a preset distance threshold. The preset distance threshold is set by calculating the mean of the distances between all pairs of node attribute feature vectors in the consortium blockchain, calculating the standard deviation of the distances between all pairs of node attribute feature vectors, and subtracting the standard deviation from the mean to obtain the preset distance threshold. The preset distance threshold is recalculated each time node clustering is performed, based on the actual distribution of the node attribute feature vectors in the current consortium blockchain. When the distance between the node attribute feature vectors of two nodes is less than the preset distance threshold, the two nodes are considered to have similar attributes and are assigned to the same consensus mechanism. When the distance between a node and at least one node already assigned to a consensus mechanism is less than the preset distance threshold, the node is assigned to that consensus mechanism. When the distance between a node and all nodes in any existing consensus mechanism is not less than the preset distance threshold, the node constitutes a new consensus mechanism independently. This results in multiple consensus mechanisms.

[0082] For the multiple consensus mechanisms obtained from clustering, a representative vector is calculated for each consensus mechanism. The representative vector is calculated as follows: each component of the representative vector is the arithmetic mean of the corresponding components of the node attribute feature vectors of all nodes within the consensus mechanism. The distance between consensus mechanisms is calculated as follows: for any two consensus mechanisms' representative vectors, subtract the corresponding components of the two representative vectors, square the result, sum the squares, and then take the square root to obtain the distance between the consensus mechanisms. For each consensus mechanism, the sum of the distances between this consensus mechanism and all other consensus mechanisms is calculated, and this sum is used as the centrality of this consensus mechanism. The consensus mechanism with the lowest centrality has the shortest total distance to the entire group of all other consensus mechanisms in the attribute space. Among all consensus mechanisms that have not yet been assigned to any consensus group, the consensus mechanism with the lowest centrality is selected as the central consensus mechanism.

[0083] The consensus mechanisms with the smallest distance to the central consensus mechanism, along with the central consensus mechanism itself, are grouped into a consensus group. The number of consensus mechanisms in a consensus group is determined by a preset group size parameter. This preset group size parameter is set by rounding down the ratio of the total number of nodes in the consortium blockchain to the desired number of consensus groups. Consensus mechanisms already grouped are marked as assigned. Among the remaining unassigned consensus mechanisms, the process of selecting a central consensus mechanism and forming consensus groups based on the preset group size parameter is repeated until all consensus mechanisms are marked as assigned, resulting in multiple consensus groups. Among the central consensus mechanisms contained in all constructed consensus groups, the central consensus mechanism with the lowest centrality is selected as the edit center. When multiple central consensus mechanisms with the lowest centrality exist, the central consensus mechanism containing the most nodes is selected as the edit center. The edit center is responsible for receiving and processing subsequent edit requests.

[0084] In the implementation of S2, all nodes in the consensus group built by S1 are in a silent state during normal operation. The silent state means that nodes only perform the operations of receiving, verifying, and forwarding consensus messages; they do not actively calculate reputation values, nor do they generate or broadcast any scoring messages used to evaluate the behavior of other nodes. This silent state prevents nodes from predicting the assessment timing by observing the reputation value update cycle. Compared to continuously calculating reputation values, it is more difficult for attackers to temporarily halt malicious behavior just before a reputation assessment is triggered.

[0085] Consensus anomalies are detected through two types of events. The first type is view switching timeout. A view switching timeout occurs when the current master node fails to generate a new block proposal within a preset master node timeout threshold, causing nodes in the consensus group to initiate a view switching request. The preset master node timeout threshold is set based on the average network round-trip latency between nodes in the consensus group multiplied by a tolerance coefficient. The tolerance coefficient is a positive number greater than 1, ensuring that the preset master node timeout threshold covers temporary delays caused by network jitter while still responding promptly to genuine master node failures. For example, with a tolerance coefficient of 3, the preset master node timeout threshold is 3 times the average network round-trip latency. The second type of event is proposal conflict. A proposal conflict occurs when nodes in the consensus group receive two or more block proposals containing different transaction sets but with the same block height within the same view. When a view switching timeout or a proposal conflict is detected, the consensus group determines that a consensus anomaly has occurred.

[0086] After a consensus anomaly is identified, the voting records and message signatures of the nodes involved in the consensus anomaly within a preset time window are extracted to form a historical consensus interaction snapshot. Nodes involved in the consensus anomaly include the current master node that caused the view switching timeout, and the node that sent conflicting proposals when a proposal conflict occurred. The preset time window is set as follows: starting from the moment the consensus anomaly occurred, it traces back several view periods. The number of view periods is determined based on the number of nodes in the consensus group, taking an integer value positively correlated with the number of nodes in the consensus group, so that the preset time window can cover a sufficient number of consensus rounds to reflect the stable behavior patterns of the nodes. For example, the number of view periods is the product of the number of nodes in the consensus group and a predetermined multiple, rounded up; the predetermined multiple is 2. Voting records contain the votes cast by nodes on block proposals in each view, with votes indicating approval or rejection. Message signatures contain the signature value generated after nodes digitally sign the votes; the signature value is used to verify whether the voting record was genuinely sent by the corresponding node and has not been tampered with. The historical consensus interaction snapshot organizes the voting records and message signatures into structured data according to view number and node identifier.

[0087] For nodes involved in consensus anomalies, a behavioral consistency comparison is performed. The specific method for behavioral consistency comparison is as follows: within the view covered by the historical consensus interaction snapshot, the voting records of each node involved in consensus anomalies are compared one by one with the voting records of all other nodes in the consensus group within the same view. For each view, if the voting value of the node involved in consensus anomalies is the same as the voting values ​​of more than half of the other nodes, this view is marked as a consistent view; if the voting value of the node involved in consensus anomalies is different from the voting values ​​of more than half of the other nodes, this view is marked as an inconsistent view. The proportion of inconsistent views to the total number of views covered by the historical consensus interaction snapshot is calculated as the inconsistency ratio. The inconsistency ratio is calculated as: R = Cdiff / Ctotal; where R represents the inconsistency ratio, Cdiff represents the number of inconsistent views, and Ctotal represents the total number of views covered by the historical consensus interaction snapshot.

[0088] The inconsistency ratio is compared with a preset inconsistency tolerance threshold. The preset inconsistency tolerance threshold is set as follows: it is half of the maximum proportion of Byzantine nodes that the Byzantine fault-tolerant algorithm can tolerate within the consensus group. For example, if the maximum proportion of Byzantine nodes that the Byzantine fault-tolerant algorithm can tolerate within the consensus group is f / N, where f represents the maximum tolerable number of Byzantine nodes and N represents the total number of nodes in the consensus group, then the preset inconsistency tolerance threshold is f / (2N). When the inconsistency ratio is greater than the preset inconsistency tolerance threshold, a temporary reputation tag indicating inconsistency is generated. When the inconsistency ratio is not greater than the preset inconsistency tolerance threshold, a temporary reputation tag indicating consistency is generated.

[0089] Nodes temporarily marked as inconsistent are removed from the consensus committee. From the nodes temporarily marked as consistent, the master node is determined according to the original order. The original order refers to the node's numbering sequence in the current consensus committee, which is predetermined based on the sorting result of the node's public key hash value. The consensus committee seat of the removed node is filled by an unmarked node within its respective consensus mechanism. The replacement method is as follows: from the consensus mechanism where the removed node is located, the unmarked node with the smallest distance between its node attribute feature vector in S1 and the representative vector of the central consensus mechanism is selected and added to the consensus committee. When there are no unmarked nodes within a consensus mechanism, unmarked nodes are selected from other consensus mechanisms belonging to the same consensus group as this consensus mechanism, in order of smallest distance between consensus mechanisms.

[0090] The criteria for eliminating consensus anomalies are as follows: the consensus committee must achieve consensus on a number of consecutive blocks after an update, where the number of consecutively achieved blocks is twice the number of blocks required to complete at least one full view switch as required by the Byzantine Fault Tolerance Algorithm. Once the criteria are met, all temporary reputation markers are cleared, and all nodes in the consensus group return to a silent state. After clearing temporary reputation markers, intermediate data such as the inconsistency ratios corresponding to those markers are also cleared, and no historical records are retained, preventing nodes from inferring the likelihood of being marked based on accumulated metrics.

[0091] By maintaining a silent state, attackers' predictions of the evaluation cycle are avoided. By setting a time window and comparing voting behavior, objective evaluation based on the consistency of historical behavior is achieved. The size stability of the consensus committee is maintained through replacement strategies within and across consensus institutions. Overall, dynamic updates of consensus committee members and reliable determination of master nodes are achieved without the need for continuous calculation of reputation values.

[0092] In the specific implementation of S3, the lattice cryptography chameleon hash function is constructed at the editing center determined in S1. Security parameters n, positive integers q and m are selected, where q is a prime number greater than 2 and m is greater than n. The editing center runs a discrete Gaussian sampling algorithm on an m-dimensional integer lattice to generate an error matrix E. Discrete Gaussian sampling is centered at the origin of the lattice and uses a preset Gaussian parameter s as the standard deviation, outputting a matrix E that satisfies a discrete Gaussian distribution on the lattice. Each element in matrix E is taken from the integer field Zq and follows a discrete Gaussian distribution on the lattice. The random uniformity of matrix E ensures that finding hash collisions without trapdoor information is equivalent to solving a small integer solution problem on the lattice, exhibiting resistance to quantum computing attacks.

[0093] The editing center randomly selects matrix A, which is an n x m uniformly random matrix on Zq. A chameleon hash function is constructed using matrix A and the error matrix E. For the message M to be hashed, the chameleon hash value is calculated as: h = A × r + E T ×cmod q; where h represents the chameleon hash value of message M, A represents the matrix parameter in the common parameters, r represents the random vector sampled from the discrete Gaussian distribution, and E represents the error matrix. T Let E represent the transpose of the error matrix, c represent the hash value of message M after being mapped by the anti-collision hash function, and mod q represent the modulo q operation. c is calculated as c = H(M), where H represents the preset anti-collision hash function. The sampling method for the random vector r is as follows: r is obtained by discrete Gaussian sampling on an m-dimensional integer lattice with preset Gaussian parameters, and r follows a discrete Gaussian distribution. The public parameter PP includes matrix A and error distribution parameters, where the error distribution parameters are the standard deviation s used in the discrete Gaussian sampling. The master key MK is the trapdoor information of matrix A, which is a set of short bases of the lattice Λ⊥(A) or a trapdoor function used for preimage sampling.

[0094] Here, lattice Λ⊥(A) represents a lattice consisting of all integer vectors x satisfying A×x = 0 mod q, where x is an m-dimensional integer vector. The master key MK is the trapdoor information of matrix A, which is a set of short bases of lattice Λ⊥(A) or a trapdoor function used for preimage sampling. The short bases are a set of linearly independent vectors in lattice Λ⊥(A) whose length does not exceed the upper limit of a preset norm.

[0095] The editing center establishes hierarchical identities for consensus committee nodes. The hierarchical division is as follows: the master node determined in S2 is designated as the parent node of layer 0, and its hierarchical identity identifier is set to the preset root identifier. For the remaining nodes in the consensus committee other than the master node, they are assigned as child nodes to the parent node of layer 0 or its subordinate parent nodes, according to the numbering order determined in S2. The hierarchical relationship between parent and child nodes is determined based on the trust chain between committee nodes. The hierarchical identity identifier of a child node is composed of the parent node's hierarchical identity identifier plus a suffix, where the suffix value is the child node's sequence number among the parent node's direct child nodes. For example, if the root identifier is ID0, the hierarchical identity identifiers of the direct child nodes of the parent node of layer 0 are ID0:1 and ID0:2, respectively.

[0096] The parent node runs a slave key algorithm to generate a slave public key and a revocable slave key for the child node. The slave key algorithm takes the public parameter PP, the master key MK, and the hierarchical identity of the child node as input. The parent node uses the trapdoor information of the master key MK to perform discrete Gaussian sampling on the lattice, with the sampling target being a target vector u derived from the hierarchical identity of the child node. The target vector u is calculated by mapping the hierarchical identity of the child node to an n-dimensional space Zq using a collision-resistant hash function. The parent node uses a trapdoor sampling algorithm, taking the matrix A, trapdoor information MK, target vector u, and Gaussian parameters as input, and outputting a short vector esk as the slave private key, satisfying A×esk = u mod q and the length of the short vector esk satisfying a preset short vector norm constraint.

[0097] The parent node performs matrix multiplication between the subordinate private key `esk` and the matrix A in the public parameters to generate the subordinate public key for the child node. The subordinate public key is calculated as: P = A × `esk` mod q. Since the short vector `esk` satisfies A × `esk` = u mod q, the subordinate public key P is equal to the target vector `u`. The subordinate public key of the child node is stored as P.

[0098] The parent node fragments the subordinate private key `esk` to generate a revocable subordinate key. The fragmentation process involves splitting the subordinate private key `esk` into multiple key fragments based on bits or components. The number of fragments, `t`, is set according to security requirements and is an integer greater than 1. A hash value is calculated for each key fragment, and a Merkle tree is constructed using the hash values ​​of all key fragments as leaf nodes. The root node of the Merkle tree is used as the revocation verification tag. The revocable subordinate key consists of a set of key fragments and a revocation verification tag, which verifies the integrity and validity of the key fragments.

[0099] The parent node uses the child node's subordinate public key, revocable subordinate key, and hierarchical identity identifier to generate a public key and a trapdoor key for the child node. The public key is the binding of the child node's hierarchical identity identifier to the subordinate public key, and it is publicly available. The trapdoor key consists of a subordinate private key (esk) and a fragment of the revocable subordinate key. The child node holding the trapdoor key can perform collision calculations on the message chameleon hash value calculated using the public key to gain edit permissions. The parent node securely delegates the trapdoor key and revocable subordinate key to the child node as a key pair. The child node stores the trapdoor key and revocable subordinate key and can delegate key pairs to the next level of child nodes in the same way, achieving hierarchical key delegation for hierarchical identity.

[0100] In the above construction, the chameleon hash function ensures quantum-resistant security based on a lattice problem, unlike existing chameleon hash schemes based on discrete logarithms. Hierarchical key delegation ensures that editing permissions are allocated hierarchically across committee nodes; parent nodes can only generate keys for their direct child nodes and cannot generate keys for nodes below their level, clearly defining permission boundaries. Revocable subordinate keys introduce key sharding and revocation verification tags. When it is necessary to revoke a child node's permissions later, the parent node only needs to publish information updating the key shards to invalidate the trapdoor keys of atomic nodes, without needing to regenerate the entire hierarchical key structure, thus balancing security and delegation efficiency.

[0101] In the implementation of S4, the editing center receives editing requests initiated by nodes holding trapdoor keys. The editing request includes the transaction identifier to be edited, the editing type, and the editing content. The transaction identifier is used to locate the target transaction in the blockchain ledger that needs editing. The editing type indicates the type of editing operation, including inserting a new transaction record, deleting an existing transaction record, and modifying the content of an existing transaction record. The editing content includes the transaction data to be inserted, a list of transaction identifiers to be deleted, or the transaction fields to be modified and their modified values.

[0102] The editing center creates a sandbox state copy based on the current blockchain ledger. The current blockchain ledger is a complete set of state data consisting of confirmed blocks on the blockchain at the time the edit request is initiated. The sandbox state copy is a complete data mirror copy of the current blockchain ledger. The sandbox state copy and the current blockchain ledger are identical in data content, but they are isolated from each other in storage and computation. Any modifications to the sandbox state copy do not affect the current blockchain ledger. The sandbox state copy is created by fully copying the state data tree corresponding to the latest block height of the current blockchain ledger and writing it to the isolated storage area.

[0103] Execute an edit request in the sandbox state copy. Executing an edit request means completing the corresponding data operation in the sandbox state copy according to the transaction identifier, edit type, and edit content to be edited in the edit request. Record the first hash value of the state data in the sandbox state copy before executing the edit request, and record the second hash value of the state data in the sandbox state copy after executing the edit request. State data consists of all key-value pairs stored in the sandbox state copy in the form of world state. The first hash value is calculated as: Hpre = Hash(Spre); where Hpre represents the first hash value, Hash represents the preset state data hash function, and Spre represents the set of state data in the sandbox state copy before executing the edit request. The second hash value is calculated as: Hpost = Hash(Spost); where Hpost represents the second hash value, and Spost represents the set of state data in the sandbox state copy after executing the edit request. The absolute value of the difference between the second hash value and the first hash value is used as the hash change. The hash change is calculated as: ΔH = |Hpost - Hpre|; where ΔH represents the hash change, Hpost represents the second hash value, and Hpre represents the first hash value.

[0104] After executing an edit request, an attempt is made to roll back the sandbox state copy using the reverse operation of the edit request. The reverse operation of the edit request is determined based on the edit type. When the edit type is to insert a new transaction record, the reverse operation is to delete the inserted new transaction record. When the edit type is to delete an existing transaction record, the reverse operation is to re-insert the deleted transaction record. When the edit type is to modify the content of an existing transaction record, the reverse operation is to restore the modified fields to their original values. After executing the reverse operation of the edit request, the hash difference between the rolled-back state data and the state data before execution is recorded as a reversibility residual.

[0105] The reversibility residual is calculated as: ΔR = |Hash(Srollback) − Hpre|; where ΔR represents the reversibility residual, Srollback represents the set of state data in the sandbox state copy after the reverse operation of the edit request, and Hpre represents the first hash value. The reversibility residual reflects the degree to which the edit request causes changes to the state data that cannot be completely rolled back. When the reversibility residual is zero, it means that the operation of the edit request is completely reversible and has no residual effect on the state data; when the reversibility residual is greater than zero, it means that the operation of the edit request has caused residual effects on the state data that cannot be eliminated by a simple reverse operation, and the larger the reversibility residual, the more significant the residual effect.

[0106] The editing center normalizes the hash change ΔH and the reversibility residual ΔR, respectively, to obtain the normalized hash change and the normalized reversibility residual. Normalization maps the hash change ΔH and the reversibility residual ΔR to the interval 0 to 1. The normalized hash change is calculated as: h*norm = ΔH / Hmax; where h*norm represents the normalized hash change, ΔH represents the hash change, Hmax represents the maximum reference value of the hash change, and Hmax is the upper limit of the hash function's output range. The normalized reversibility residual is calculated as: rnorm = ΔR / Rmax; where rnorm represents the normalized reversibility residual, ΔR represents the reversibility residual, Rmax represents the maximum reference value of the reversibility residual, and Rmax is the upper limit of the hash function's output range. Since the hash change and reversibility residual are in the same range as the output value of the hash function, the normalized hash change and normalized reversibility residual after normalization are both in the range of 0 to 1.

[0107] The editing center performs nonlinear fusion of the normalized hash change and the normalized invertible residual input gating function.

[0108] The gating function has the following form: E = hnorm × (e (α×rnorm) / (1+e (α×rnorm)The function is defined as E + β / (1 + hnorm); where E represents the edit perturbation index, hnorm represents the normalized hash change, rnorm represents the normalized reversibility residual, α represents the reversibility residual amplification factor (α is a real number greater than zero), and β represents the basic influence coefficient of the hash change (β is a real number between 0 and 1). α and β are set according to the stability requirements of the consortium blockchain for edit operations. The larger α is, the steeper the influence of the reversibility residual on the edit perturbation index; the larger β is, the more the hash change maintains a basic influence on the edit perturbation index even when the reversibility residual is small. In the gating function, the marginal influence of the change in the normalized hash change hnorm on the edit perturbation index E decreases non-linearly with increasing values ​​of the normalized reversibility residual rnorm, while the marginal influence of the change in the normalized reversibility residual rnorm on the edit perturbation index E increases non-linearly with increasing values ​​of the normalized hash change hnorm. Therefore, the gating function achieves non-linear interactive coupling between the two. The editing center uses the output value E of the gating function as the editing perturbation index.

[0109] The editing center iteratively adjusts within the sandbox state replica. During each adjustment, the editing center modifies the edit type and content according to a preset adjustment strategy. This preset strategy includes reducing the number of fields modified in the edit content, decreasing the scope of the impact of the edit operation, and downgrading deletion types to modification types. For each adjusted edit type and content, the editing center recalculates the edit disturbance index. The editing center records the edit disturbance index and the adjustment magnitude of the edit type and content for each adjustment. The adjustment magnitude of the edit type and content measures the degree of change relative to the original edit request; this degree of change is measured by the proportion of change in the number of data items affected by the edit operation. The editing center selects the combination where the edit disturbance index is below the preset disturbance threshold and the adjustment magnitude of the edit type and content is the smallest to determine the allowed operation range for this edit request. The preset disturbance threshold is set based on the distribution of edit disturbance indices of completed edit transactions in the consortium blockchain. Specifically, it is set by collecting the edit disturbance index values ​​of all successfully executed edit transactions in history and taking the upper quartile of these values ​​as the preset disturbance threshold. The operation range includes the allowed edit types and the set of fields that can be modified.

[0110] By conducting pre-execution and rollback tests on edit requests in sandbox state replicas, objective evaluation metrics are obtained in two dimensions: hash change and reversibility residual. The interaction between these two metrics is simulated through nonlinear fusion of gating functions. Iterative adjustments are made to search for the edit scheme that best approximates the original request while satisfying perturbation constraints. This allows the scope of edit permissions to be dynamically determined based on quantitative predictions of the actual impact of edit operations on blockchain state data, rather than relying on static pre-allocation of node roles. Compared to conventional role-based preset permissions, this mechanism, which combines pre-assessment of edit impact with reverse pruning of permission scope, logically achieves dynamic minimization of permission granting, maximizing the fulfillment of nodes' legitimate edit needs while ensuring data integrity.

[0111] In the specific implementation of S5, the editing center obtains the permitted operation range for this editing request, determined in S4. The operation range is determined in S4 through sandbox state replica simulation, editing perturbation index calculation, and iterative adjustment, selecting the combination where the editing perturbation index is lower than a preset perturbation threshold and the adjustment range of editing type and content is minimized. The operation range includes permitted editing types and the set of fields that can be modified. Permitted editing types are the editing operation types determined after S4 iterative adjustment. Permitted editing types are one or more from the set of editing types, including inserting new transaction records, deleting existing transaction records, and modifying the content of existing transaction records. The set of fields that can be modified is the set of keys in the world state key-value pairs that can be modified by the editing request, determined after S4 iterative adjustment. Each element in the set of fields that can be modified corresponds to the key name of a modifiable data field in the blockchain ledger.

[0112] The editing center compares the edit type in the received edit request with the allowed edit types in the operation scope. The comparison method is as follows: it checks whether the value of the edit type in the edit request is the same as any of the allowed edit types listed. If the value of the edit type in the edit request is the same as any of the allowed edit types listed, the edit type comparison passes. If the value of the edit type in the edit request is not the same as any of the allowed edit types listed, the edit type comparison fails.

[0113] The editing center compares the content of the received editing request with the set of fields allowed to be modified within the scope of the operation. The content to be edited includes the transaction fields to be modified and their modified values, with each transaction field identified by a field key name. The comparison method is as follows: extract the field key names of all transaction fields to be modified from the content to be edited, construct a request field key name set from the extracted field key names, and check one by one whether each field key name in the request field key name set exists in the set of fields allowed to be modified. If every field key name in the request field key name set exists in the set of fields allowed to be modified, the content comparison passes. If at least one field key name in the request field key name set does not exist in the set of fields allowed to be modified, the content comparison fails.

[0114] The editing center determines that an editing request is within the scope of operations if both the editing type and content comparisons pass. If either the editing type or content comparison fails, the editing center determines that the editing request is outside the scope of operations. For editing requests determined to be outside the scope of operations, the editing center returns a rejection message indicating a mismatch in the scope of operations to the node that initiated the request. This rejection message carries a summary of the scope of operations to inform the node that initiated the request of the currently allowed boundaries of operations.

[0115] The editing center appends an operation scope digest to edit requests deemed within the operation scope, generating an edit transaction. The operation scope digest contains a hash digest of the allowed edit types and the set of fields allowed to be modified. The operation scope digest is calculated as: Das = Hash(Types || Fields); where Das represents the operation scope digest, Hash represents a pre-defined collision-resistant hash function, Types represents the string obtained by concatenating the allowed edit types in the order defined in the edit type set, Fields represents the string obtained by concatenating all field keys in the set of allowed fields in lexicographical order, and || represents the string concatenation operation. The operation scope digest is written to the blockchain along with the edit transaction, enabling the consensus committee to confirm that the edit transaction has been pruned within the operation scope and has been verified within that scope when verifying the edit transaction.

[0116] After generating an edit transaction, the editing center sends it to the master node determined in S2. The edit transaction includes the content of the original edit request, a summary of the scope of operations, and the digital signature of the editing center. Upon receiving the edit transaction, the master node encapsulates it into a consensus proposal. The consensus proposal includes the edit transaction data, a proposal number, and the master node's digital signature. The master node then submits the consensus proposal to the consensus committee, initiating the consensus process.

[0117] The editing center performs a dual comparison of editing requests across two dimensions: editing type and editing content. This transforms the operational scope dynamically determined by sandbox simulation and perturbation index calculation in S4 into admission control rules. Editing requests are only allowed to enter the consensus process if both the editing type and content fall within the operational scope. Compared to simply verifying the identity of the editing permission holder, this dual comparison achieves fine-grained control over editing operations. The operational scope summary is written to the blockchain along with the editing transaction, providing non-repudiable evidence of the editing permission boundaries for subsequent audits. This allows consensus committee nodes to directly verify whether an editing transaction was generated within the authorized operational scope upon receipt, without needing to re-execute the sandbox simulation and perturbation index calculation in S4, thus achieving a balance between verification efficiency and security.

[0118] In the implementation of S6, the consensus committee receives consensus proposals submitted by the master node. The consensus committee is the set of nodes determined in S2 after updating the temporary reputation markers. Each node in the consensus committee holds a copy of the blockchain ledger corresponding to the consensus group built in S1. The master node is the node determined in S2 from the nodes indicated as consistent by the temporary reputation markers, in its original order. The consensus proposal is encapsulated and generated by the master node in S5. The consensus proposal includes edited transaction data, a proposal number, and the master node's digital signature.

[0119] Each node in the consensus committee verifies the edit transactions in the received consensus proposal. The verification includes: verifying the master node's digital signature to confirm that the consensus proposal was issued by a legitimate master node; verifying the editing center's digital signature on the edit transaction to confirm that the edit transaction was generated by a legitimate editing center; and verifying the operation scope digest attached to the edit transaction, confirming that the operation scope digest matches the allowed edit types and the set of fields that can be modified in the edit transaction. The operation scope digest verification method is as follows: the consensus committee node extracts the allowed edit types and the set of fields that can be modified from the edit transaction, recalculates the operation scope digest using the same calculation method as in S5, and compares the recalculated operation scope digest with the operation scope digest attached to the edit transaction. If they match, the operation scope digest verification is successful.

[0120] After verification, each node in the consensus committee broadcasts a voting message containing its agreement on the edit transaction and its digital signature. The voting message includes the transaction hash value of the edit transaction, the node's agreement, and the node's digital signature. The transaction hash value is calculated as: TxHash = Hash(TxData); where TxHash represents the transaction hash value, Hash represents a preset collision-resistant hash function, and TxData represents the serialized data of the edit transaction, which is the binary encoding of the edit transaction's fields concatenated in a preset order.

[0121] The consensus committee collects voting messages broadcast by each node. The preset number is determined based on the Byzantine fault-tolerant consensus protocol adopted by the committee. The preset number is an integer obtained by rounding up to the nearest integer, which is 2 / 3 of the total number of nodes on the consensus committee. When the number of voting messages collected by the consensus committee reaches the preset number, the committee determines that the edit transactions have reached consensus. The committee packages the agreed-upon edit transactions into a new block. The new block includes a block header, a list of edit transactions, and a block footer. The block header includes the hash value of the previous block, a timestamp, and a Merkle root. The committee appends the new block to the end of the blockchain ledger, completing the writing of the edit transactions.

[0122] After the edited transaction is written to the blockchain, obtain the member set of the consensus committee before and after the consensus anomaly handling in S2. Nodes that only exist in the member set of the consensus committee before the consensus anomaly handling but not in the member set of the consensus committee after the consensus anomaly handling are identified as nodes to be removed from the consensus committee.

[0123] For nodes identified as being removed from the consensus committee, the parent node of the node being removed runs the key update algorithm. The parent node is the node in S3 that delegates the key pair containing the trapdoor key and the revocable dependent key to the node being removed from the consensus committee. The key update algorithm is executed as follows: the parent node obtains the revocation verification tag from the revocable dependent key of the node being removed from the consensus committee, uses the revocation verification tag to verify the integrity and validity of the key fragments in the revocable dependent key, and generates a new key fragment to replace part of the key fragments in the original revocable dependent key after successful verification. The revocation verification tag is updated to the Merkle root of the corresponding new key fragment. The trapdoor key of the node being removed from the consensus committee becomes invalid because it depends on the replaced original key fragments. The node being removed from the consensus committee no longer holds a valid trapdoor key and revocable dependent key, and its editing privileges are revoked.

[0124] The parent node generates a revocation record transaction upon completion of the revocation and submits it to the consensus committee. The revocation record transaction includes the hierarchical identity identifier of the revoked node, a revocation timestamp, and an updated revocation verification tag. After consensus by the consensus committee, the revocation record transaction is written to the blockchain, forming an irrefutable proof of permission revocation.

[0125] The consensus process for editing transactions adds operation scope digest verification to the regular verification, allowing the consensus committee to verify the permission boundaries of edit requests without re-executing the S4 sandbox simulation. Key revocation is executed immediately after the edit transaction is written. By comparing changes in the committee member set in S2, the node requiring revocation is accurately identified, eliminating reliance on potentially erased temporary reputation marker history, thus ensuring the reliability and consistency of the revocation operation. The revocation operation is executed by the parent node and recorded on-chain, making the permission revoke process traceable. Compared to methods relying on off-chain notifications or periodic rotation, this improves both timeliness and auditability.

[0126] The following is an application scenario of community-based precision elderly care, which serves as a supplementary explanation of the solutions described in the above S1 to S6 embodiments in a specific application scenario.

[0127] When applying this solution to community-based precision elderly care scenarios, the consortium blockchain nodes include nodes from the civil affairs department, community health service centers, elderly care institutions, home care service providers, long-term care insurance agencies, and service quality supervision agencies. In S1, when collecting the service capability attributes and historical behavior attributes of the consortium blockchain nodes, the computing power index in the service capability attributes corresponds to the server configuration level of each elderly care service institution's information system; the storage capacity index corresponds to the disk space available for on-chain data storage in each elderly care service institution; and the network bandwidth index corresponds to the bandwidth rate of the connection between each elderly care service institution and the consortium blockchain network. The consensus voting accuracy rate in the historical behavior attributes corresponds to the proportion of correct votes cast by each node when participating in elderly care data consensus within a historical period; the online time percentage corresponds to the proportion of online running time of each node's information system within the statistical period; and the message response latency corresponds to the response latency of each node to requests for elderly care data storage.

[0128] Following the clustering method in S1, nodes with similar geographical locations or service types are grouped together. For example, community health service center nodes, community day care center nodes, and home care service provider nodes within the same street jurisdiction are grouped into the same consensus institution due to the high degree of overlap in their service areas and the small distance between their node attribute feature vectors. Consensus institutions from multiple adjacent streets are formed into a consensus group because the distance between their representative vectors is small. The consensus institution with the strongest comprehensive service capabilities and the shortest overall distance from the other consensus institutions is determined as the editing center. The editing center is usually a district-level civil affairs department node or a regional elderly care service center node.

[0129] Elderly care service data includes health records for the elderly, care service records, long-term care insurance assessment results, service subsidy disbursement records, and service quality evaluation records. In S3, when consensus committee nodes establish hierarchical identities, district-level civil affairs department nodes act as parent nodes, street-level elderly care service center nodes as child nodes, and community-level care service station nodes as lower-level child nodes. Parent nodes delegate key pairs containing trapdoor keys and revocable subordinate keys to child nodes, ensuring that each level of node's editing permissions for elderly care service data correspond to its level within the consensus committee.

[0130] In elderly care service scenarios, when an elderly person's health condition changes or their care level is adjusted after assessment, their health record or care plan needs to be edited and updated. The community health service center node holding the trapdoor key initiates an edit request. The edit request includes the transaction identifier of the elderly person's health record to be edited, the edit type (e.g., modifying existing transaction record content), and the edit content (e.g., changing the care level from mild to moderate). In S4, the edit center simulates the modification operation on the elderly person's health record in a sandbox state replica, records the hash change of the health record status data, and attempts to roll back the operation in reverse after the simulation, recording the reversibility residual. If the hash change of the care level modification operation is small and the reversibility residual is zero, and the edit perturbation index is below a preset perturbation threshold, the edit center determines that the allowed operation range is modifying existing transaction record content, and the set of allowed modified fields includes the care level field.

[0131] In S5, after the editing center verifies that the editing type and content in the editing request fall within the allowed operation range, it generates an editing transaction, which is then submitted to the consensus committee via the master node. In S6, the consensus committee writes the editing transaction to the blockchain after reaching a consensus, and the updated care level record for the elderly is recorded on the chain, forming an undeniable editing trace.

[0132] When a node in the elderly care consortium blockchain is identified as an inconsistent node and removed from the consensus committee during consensus anomaly handling—for example, if a node from an elderly care institution votes inconsistently with the majority of nodes in multiple consensus processes and is indicated as inconsistent by a temporary reputation tag in S2—its parent node will revoke the node's trapdoor key and revocable subordinate key in S6. This node will lose its editing permissions for elderly care service data, preventing unauthorized modifications to elderly people's health records or care service records by the anomalous node. The removed node's consensus committee seat will be filled by the unmarked node within its own consensus mechanism that has the smallest vector distance to the representative of the central consensus mechanism, maintaining the size and stable operation of the elderly care consortium blockchain's consensus committee.

[0133] The above application examples demonstrate that the abnormally triggered consensus member update mechanism and the time-based reputation tag-based permission revocation mechanism in this solution can promptly revoke editing permissions when node behavior is abnormal in multi-level and multi-institutional collaboration scenarios of elderly care services, reducing the risk of sensitive elderly care service data being maliciously tampered with or leaked, and providing a reliable data governance foundation for community-based precision elderly care.

[0134] Example 2: Figure 2 A schematic diagram of a consortium blockchain dynamic consensus and permission management system is provided. The system includes:

[0135] The group building module is used to cluster consortium blockchain nodes to build consensus groups and determine the editing center;

[0136] The anomaly triggering module is used to silence nodes within the consensus group. When a consensus anomaly is detected, it obtains a snapshot of the historical consensus interactions of the nodes involved, compares the consistency of behavior to generate a temporary reputation mark to update the consensus committee and determine the master node. After the anomaly is eliminated, the temporary reputation mark is cleared.

[0137] The key delegation module is used to construct a chameleon hash function using lattice cryptography to generate public parameters and a master key, establish hierarchical identities for consensus committee nodes, and delegate key pairs containing trapdoor keys and revocable subordinate keys to child nodes from parent nodes.

[0138] The sandbox simulation module is used by the editing center to simulate the received editing requests in a sandbox state copy, calculate the editing disturbance index, and trim the allowed operation range of the current editing request according to the editing disturbance index;

[0139] The verification and submission module is used by the editing center to verify that the editing request is within the scope of operation, generate an editing transaction, and submit it to the consensus committee via the master node.

[0140] The consensus revocation module is used to write the consensus of the edited transaction to the blockchain after the consensus committee has reached a consensus. When a node is removed from the consensus committee due to a temporary reputation mark, the trapdoor key and revocable subordinate key of the node are revoked.

[0141] All calculations involved in the embodiments are performed using dimensionless numerical values, and the preset parameters and thresholds in the calculations can be set by those skilled in the art according to actual conditions.

[0142] This technical solution can be flexibly deployed, for example, as embedded software running on device hardware, or installed on personal computers or other smart terminals with user interfaces, thus adapting to various hardware environments and usage requirements.

[0143] The above solutions can be implemented in software, hardware, firmware, or a combination thereof. When implemented in software, they are presented, in whole or in part, as a computer program product, containing one or more computer instructions or programs. When these instructions or programs are loaded and executed on a computer, results are produced corresponding to the processes or functions of the embodiments of this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one medium to another via wired or wireless means, such as from a website, server, or data center via wired means such as fiber optic cables, twisted-pair cables, or coaxial cables, or wireless means such as infrared or microwaves to another site. A computer-readable storage medium refers to any usable medium that a computer can access or a data storage device such as a server or data center that contains one or more usable media, including magnetic media such as floppy disks, hard disks, and magnetic tapes, optical media such as DVDs, and semiconductor media such as solid-state drives.

[0144] The specific working process of the system, device and module can be found in the method embodiment, and will not be repeated here.

[0145] The disclosed systems, devices, and methods can be implemented in other ways. The device embodiments are for illustrative purposes only, and the module division is only a logical division. In practice, different divisions can be implemented, such as merging or integrating multiple modules or components, or omitting some features. Coupling, direct coupling, or communication connections between the components can be achieved through interfaces, while indirect coupling or communication connections can take electrical, mechanical, or other forms.

[0146] The modules described as separate components may or may not be physically separated. The components shown as modules can be physical hardware or software, and can be deployed centrally or distributed across multiple network nodes. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0147] The functional modules in each embodiment can be integrated into one processing module, or they can exist independently, or two or more modules can be integrated into one.

[0148] If the functionality is implemented as a software module and used as an independent product, it can be stored in a computer-readable storage medium. Under this understanding, the substantial contribution of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and contains instructions to cause a computer device, such as a personal computer, server, or network device, to execute all or part of the steps of the methods in the embodiments of this application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0149] The above are merely specific embodiments of this application, and the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should fall within the scope of protection of this application.

Claims

1. A method for dynamic consensus and permission management in a consortium blockchain, characterized in that, include: S1: Cluster the nodes of the consortium blockchain to build a consensus group and determine the editing center; S2: Nodes within the consensus group remain silent. When a consensus anomaly is detected, a snapshot of the historical consensus interactions of the involved nodes is retrieved, behavioral consistency is compared to generate a temporary reputation marker to update the consensus committee and determine the master node. After the anomaly is resolved, the temporary reputation marker is cleared, including: Nodes within the consensus group remain silent and do not actively calculate reputation values; If a view switching timeout or proposal conflict is detected, it is determined to be a consensus anomaly. Extract the voting records and message signatures of nodes involved in consensus anomalies within a preset time window to form a snapshot of historical consensus interactions; The voting behavior of nodes involved in consensus anomalies in the historical consensus interaction snapshot is compared with the voting behavior of other nodes in the consensus group in the same historical consensus interaction snapshot to generate a temporary reputation tag. Nodes whose temporary reputation markers indicate inconsistency are removed from the consensus committee. The master node is determined from the nodes whose temporary reputation markers indicate consistency according to the original order. The consensus committee seats of the removed nodes are filled by nodes within the consensus mechanism that have not been marked. The original order refers to the node's numbering order in the current consensus committee, which is predetermined based on the sorting result of the node's public key hash value. Once the consensus anomaly is resolved, all temporary reputation markers are cleared, and the nodes return to a silent state. The consensus committee seat of a removed node is filled by an unmarked node within its consensus mechanism; S3: The editing center uses lattice cryptography to construct a chameleon hash function to generate public parameters and a master key, establishes hierarchical identities for consensus committee nodes, takes the master node determined in S2 as the parent node, and takes the other nodes in the consensus committee other than the master node as child nodes in numerical order. The parent node assigns a key pair containing a trapdoor key and a revocable subordinate key to the child nodes. S4: The editing center simulates the received editing request in a sandbox state copy, calculates the editing perturbation index, and trims the allowed operation range for this editing request according to the editing perturbation index, including: The editing center receives editing requests initiated by nodes holding trapdoor keys. The editing request includes the transaction identifier to be edited, the editing type, and the editing content. A sandbox state copy is created based on the current blockchain ledger. An edit request is executed in the sandbox state copy. The hash change of the state data in the sandbox state copy before and after the execution is recorded. After the execution, an attempt is made to roll back the sandbox state copy with the reverse operation of the edit request. The hash difference between the state data after the rollback and the state data before the execution is recorded as the reversible residual. The hash change and the invertible residual are nonlinearly fused to generate the edit perturbation index; In the sandbox state copy, the editing type and editing content of the editing request are adjusted multiple times. The editing disturbance index corresponding to each adjustment is calculated. The combination with the editing disturbance index lower than the preset disturbance threshold and the smallest adjustment range of editing type and editing content is selected to determine the allowed operation range of this editing request. S5: After the editing center verifies that the editing request is within the scope of operation, it generates an editing transaction and submits it to the consensus committee via the master node; S6: After the consensus committee reaches a consensus on edited transactions, it writes the data to the blockchain. When a node is removed from the consensus committee due to a temporary reputation marker, the node's trapdoor key and revocable subordinate key are revoked, including: The consensus committee receives consensus proposals containing edit transactions submitted by the master node. Each node in the consensus committee verifies the edit transactions and broadcasts voting messages. After collecting a preset number of voting messages, the consensus committee will write the edited transaction to the blockchain; After the edited transaction is written to the blockchain, obtain the member set of the consensus committee before this consensus anomaly handling and the member set of the consensus committee after this consensus anomaly handling. Nodes that only exist in the member set of the consensus committee before the consensus anomaly handling but not in the member set of the consensus committee after the consensus anomaly handling are identified as nodes removed from the consensus committee. For nodes removed from the consensus committee, the node's parent node runs the key update algorithm to revoke the node's trapdoor key and revocable slave key; The key update algorithm is executed as follows: the parent node obtains the revocation verification tag from the revocable slave key of the node that has been removed from the consensus committee, uses the revocation verification tag to verify the integrity and validity of the key fragments in the revocable slave key, generates a new key fragment to replace part of the key fragments in the original revocable slave key, and updates the revocation verification tag to the Merkle root of the corresponding new key fragment.

2. The method for dynamic consensus and permission management in a consortium blockchain according to claim 1, characterized in that, Clustering consortium blockchain nodes to construct consensus groups and determining editing centers, including: Collect the service capability attributes and historical behavior attributes of consortium blockchain nodes, and establish node attribute feature vectors; Calculate the distance between node attribute feature vectors and classify nodes whose distances meet preset conditions into the same consensus mechanism; Calculate the distance between each consensus mechanism, and form a consensus group by combining the consensus mechanisms that are closest to the central consensus mechanism with the central consensus mechanism; thus obtaining multiple consensus groups. For each consensus mechanism, calculate the sum of the distances between the consensus mechanism and all other consensus mechanisms, and use the sum as the centrality of this consensus mechanism; select the consensus mechanism with the smallest centrality as the central consensus mechanism. Among all the central consensus institutions in the established consensus groups, the central consensus institution with the lowest centrality is selected as the editing center; when there are multiple central consensus institutions with the lowest centrality, the central consensus institution with the most nodes is selected as the editing center.

3. The method for dynamic consensus and permission management in a consortium blockchain according to claim 1, characterized in that, The editing center uses lattice cryptography to construct a chameleon hash function to generate public parameters and a master key, establishing hierarchical identities for consensus committee nodes. The master node determined in S2 is designated as the parent node, and the remaining nodes in the consensus committee, excluding the master node, are designated as child nodes in numerical order. The parent node delegates key pairs containing a trapdoor key and a revocable subordinate key to the child nodes, including: Discrete Gaussian sampling is performed on the lattice, and a chameleon hash function is constructed based on the sampling results to generate common parameters and a master key. The common parameters include matrix parameters and error distribution parameters. Hierarchical identities are established according to the hierarchical relationship of nodes in the consensus committee. Nodes at higher levels are designated as parent nodes, and nodes at lower levels are designated as child nodes. The hierarchical identity identifier of a child node is the hierarchical identity identifier of its parent node plus a suffix. The parent node runs the slave key algorithm, taking the public parameters and the master key as input, to generate the slave public key and revocable slave key for the child node; The parent node uses the child node's subordinate public key, revocable subordinate key, and hierarchical identity identifier to generate a public key and trapdoor key for the child node, and then delegates the trapdoor key and revocable subordinate key as a key pair to the child node.

4. The method for dynamic consensus and permission management in a consortium blockchain according to claim 3, characterized in that, The parent node runs the slave key algorithm, taking the public parameters and master key as input, to generate the child node's slave public key and revocable slave key, including: The parent node takes the public parameters, master key, and hierarchical identity of the child node as input, and performs discrete Gaussian sampling on the lattice to obtain the subordinate private key; The hierarchical identity identifier of the child node is mapped to the n-dimensional space of Zq through a collision-resistant hash function to obtain the target vector u; the parent node uses the trapdoor sampling algorithm, with input matrix A, trapdoor information MK, target vector u and Gaussian parameters, and outputs a short vector esk as the subordinate private key, satisfying A×esk = u mod q and the length of the short vector esk satisfies the preset short vector norm constraint. The parent node performs matrix operations on the subordinate private key and the matrix parameters in the public parameters to generate the subordinate public key of the child node; The parent node performs fragmentation on the subordinate private key, calculates the hash value for each key fragment, constructs a Merkle tree using the hash values ​​of all key fragments as leaf nodes, and uses the root node of the Merkle tree as the revocation verification tag to obtain the revocable subordinate key. The revocable subordinate key contains the key fragment and the revocation verification tag.

5. The method for dynamic consensus and permission management in a consortium blockchain according to claim 1, characterized in that, The editing center nonlinearly fuses the hash change and the invertibility residual to generate an editing perturbation index, including: The editing center normalizes the hash change and the reversibility residual respectively to obtain the normalized hash change and the normalized reversibility residual; The editing center performs a nonlinear fusion of the normalized hash change and the normalized invertibility residual input gating function; the gating function has the form: E=hnorm×(e (α×rnorm) / (1+e (α×rnorm) )+β / (1+hnorm); where E represents the edit perturbation index, hnorm represents the normalized hash change, rnorm represents the normalized reversibility residual, α represents the reversibility residual amplification factor, α is a real number greater than zero, and β represents the basic influence factor of hash change, β is a real number between 0 and 1. The editing center uses the output value of the gating function as the editing disturbance index.

6. The method for dynamic consensus and permission management in a consortium blockchain according to claim 1, characterized in that, After the editing center verifies that the editing request is within the scope of operation, it generates an editing transaction, which is then submitted to the consensus committee via the master node, including: The editing center obtains the scope of operations allowed for this editing request, which includes the allowed editing types and the set of fields that can be modified; The editing center compares the editing type in the received editing request with the allowed editing types, and compares the editing content in the editing request with the set of fields that can be modified; The editing center determines that the editing request is within the scope of operation when the editing type is an allowed editing type and the editing content belongs to the set of fields that can be modified. After the editing center attaches an operation scope summary to the editing request that is determined to be within the operation scope, it generates an editing transaction; The editing center sends the editing transaction to the master node, which then encapsulates the editing transaction into a consensus proposal and submits it to the consensus committee.

7. A consortium blockchain dynamic consensus and permission management system, used to implement the consortium blockchain dynamic consensus and permission management method according to any one of claims 1-6, characterized in that, include: The group building module is used to cluster consortium blockchain nodes to build consensus groups and determine the editing center; The anomaly triggering module is used to silence nodes within the consensus group. When a consensus anomaly is detected, it obtains a snapshot of the historical consensus interactions of the nodes involved, compares the consistency of behavior to generate a temporary reputation mark to update the consensus committee and determine the master node. After the anomaly is eliminated, the temporary reputation mark is cleared. The key delegation module is used to construct a chameleon hash function using lattice cryptography to generate public parameters and a master key, establish hierarchical identities for consensus committee nodes, and delegate key pairs containing trapdoor keys and revocable subordinate keys to child nodes from parent nodes. The sandbox simulation module is used by the editing center to simulate the received editing requests in a sandbox state copy, calculate the editing disturbance index, and trim the allowed operation range of the current editing request according to the editing disturbance index; The verification and submission module is used by the editing center to verify that the editing request is within the scope of operation, generate an editing transaction, and submit it to the consensus committee via the master node. The consensus revocation module is used to write the consensus of the edited transaction to the blockchain after the consensus committee has reached a consensus. When a node is removed from the consensus committee due to a temporary reputation mark, the trapdoor key and revocable subordinate key of the node are revoked.

Images