An architecture and chained storage method for a dynamically editable blockchain

Abstract

This application discloses an architecture and chain-based storage method for a dynamically editable blockchain, relating to the field of blockchain technology. In this architecture, blockchain nodes are divided into ledger nodes, chain nodes, and dynamically expanding nodes. Ledger nodes store underlying ledger transaction data. Chain nodes, when editing blockchain data, point the ledger node ID pointer to the corresponding dynamically expanding node ID. Dynamically expanding nodes, when editing blockchain data, dynamically create a virtual space corresponding one-to-one with the ledger to store the data ledger that needs to be modified. When editing blockchain data, the node receiving the ledger editing request, after reaching decentralized consensus through a trusted node group, uses the chain node to find the corresponding dynamically expanding node storage location and completes the data update. This application can securely and efficiently complete block editing under decentralized conditions, and the data change process is traceable and tamper-proof.

Description

Technical Field

[0001] Applications generally relate to the field of blockchain technology, and in particular to an architecture and chained storage method for a dynamically editable blockchain. Background Technology

[0002] Blockchain is a decentralized and tamper-proof database that effectively solves trust issues arising from the need for third-party participation, and also provides data traceability and tamper-proof capabilities. While the immutability of traditional blockchains provides better channels for the publication and dissemination of various fake news and harmful information, the limitations of the traditional blockchain's "immutability" in practical applications are addressed. Editable blockchains, on the other hand, can legally correct erroneous data and clean up harmful information, while also leaving a complete record of the modification process. This preserves the trust foundation of blockchains while breaking down the limitations of their application scenarios, allowing blockchains to both carry trusted data and adapt to flexible practical business needs.

[0003] Existing editable blockchain technologies, such as CN118074945 A, disclose a distributed on-chain information editing consensus method and system for editable blockchains. This involves a blockchain user initiating an edit request, which is then verified and agreed upon by editing consensus nodes to generate a transaction record. Regular consensus nodes execute the edit operation within the original chain, while other nodes verify and update the ledger. A threshold is set to tolerate faulty and malicious nodes, ensuring the consistency of the edited content. However, CN118074945 A has the following problems: executing the edit operation within the original chain directly modifies the original data, which can easily lead to a break in the original data traceability chain, making it difficult to trace the historical versions and change trajectories of the data subsequently. Summary of the Invention

[0004] This application / disclosure addresses the shortcomings of the background technology, namely, "CN118074945 A performs editing operations in the original chain, directly modifying the original data, which easily leads to the break of the original data traceability chain, making it difficult to trace the historical versions and change trajectories of the data later," by providing a dynamic editable blockchain architecture and chain storage method.

[0005] This application / disclosure provides an architecture for a dynamically editable blockchain, wherein the blockchain nodes include ledger nodes, chain nodes, and dynamically expanding nodes; Ledger nodes: Used to store underlying ledger transaction data; Chain node: Used to point the ledger node ID pointer to the corresponding dynamically extended node ID when editing blockchain data; Dynamically expandable nodes: When editing blockchain data, a virtual space corresponding one-to-one with the ledger is dynamically created in the dynamic expansion node to store the data ledger that needs to be changed.

[0006] Preferably, the data ledger that needs to be changed is stored in a database, and the data that needs to be changed is saved in memory in the form of key-value pairs.

[0007] Preferably, the key is represented by "block ID + numerical rank".

[0008] Preferably, a chained hash tree is used to structure the data within the block, storing the underlying ledger transaction data in the leaf nodes of the chained hash tree; In a chained hash tree, the sibling nodes of the leaf nodes store the public-key encrypted ID value of the corresponding dynamically expanded node ID.

[0009] Preferably, the parent node of a leaf node is represented by the hash calculation of all leaf nodes.

[0010] Preferably, the chained hash tree is a chained Merkle tree.

[0011] A chained storage method for a dynamically editable blockchain, comprising: Step S1: The blockchain node accepts the client's edit request and verifies the legality of the client's edit request; Step S2: When the legality verification is successful, a fixed virtual space is generated on the dynamically expanding node of the editing request blockchain node to store the edited data; Step S3: The trusted consensus group based on the blockchain determines the trusted nodes of the blockchain node requesting the edit; the trusted consensus group of the blockchain is divided based on the historical consensus results of the blockchain system nodes; Step S4: The editor requests decentralized consensus from all trusted nodes of the blockchain node. When the consensus is passed, the chain node of the editor requests the blockchain node to point the ledger node ID pointer to the corresponding dynamic expansion node ID and update the corresponding virtual space data in the corresponding dynamic expansion node.

[0012] Preferably, verifying the legitimacy of a client's edit request includes: identity verification, permission verification, and data format verification.

[0013] Preferably, in step S3, the affiliation degree between the blockchain node and the trusted consensus group is calculated based on the distance between the blockchain node and the trusted consensus group center point of the blockchain, and the trusted node of the edit request blockchain node is determined based on the affiliation degree between the edit request blockchain node and the trusted consensus group.

[0014] Preferably, in each trusted consensus group, the blockchain node whose absolute affiliation value is closest to that of the blockchain node requesting the edit is selected as the trusted node for the edit request.

[0015] Preferably, based on the historical consensus results of the blockchain system nodes, the trusted consensus groups of the blockchain are divided, including: Obtain the historical consensus results of the blockchain system nodes and determine the historical consensus vector of each node in the blockchain system; The initial set of trusted consensus group centers of the blockchain is determined based on the historical consensus vector of each node in the blockchain system. Calculate the Euclidean distance from each node in the blockchain system to each central point in the initial set of trusted consensus group central points. Then, assign each node in the blockchain system to a trusted consensus group containing the central point with the smallest Euclidean distance, ultimately forming multiple trusted consensus groups.

[0016] Preferably, the initial set of trusted consensus group centers in the blockchain is: ; These are the central points of the trusted consensus groups of the 1st, 2nd, 3rd... Zth blockchains, respectively. This serves as the central vector for all nodes in the blockchain system. For all nodes in the blockchain system, the historical consensus vector is... The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , ...... The node furthest away; The total number of trusted consensus groups that a blockchain is divided into.

[0017] Preferably, the chained hash tree ledger is a chained Merkle tree ledger.

[0018] Compared with the prior art, the beneficial effects of this application are as follows: 1. Achieving coexistence of editability and decentralization in blockchain data: Traditional blockchain technology is characterized by its immutability and uneditability, which becomes a limitation in certain application scenarios (such as data error correction and compliance adjustments). This application solves the core problem of "uneditability of blockchain" in existing technologies by introducing dynamically expanding nodes and a chain-like Merkle tree structure, enabling secure and efficient data updates without destroying the original ledger data.

[0019] 2. Enhance the scalability and flexibility of the blockchain system: By dividing nodes into three categories—ledger nodes, chain nodes, and dynamically expanding nodes—the system architecture becomes clearer, and the functional division is more defined. The introduction of dynamically expanding nodes allows the system to flexibly respond to data change requirements without modifying the original ledger, significantly improving the scalability and adaptability of the blockchain system.

[0020] 3. Ensuring Data Security and Consistency: During the editing process, all changed data is stored in a fixed virtual space of dynamically expanding nodes and mapped to a chained Merkle tree via hash pointers, ensuring that the data change process is traceable and tamper-proof. Simultaneously, the decentralized consensus mechanism of trusted node groups effectively prevents malicious nodes from tampering with data, ensuring the overall security of the system.

[0021] 4. Improve block editing efficiency and consensus efficiency: This application proposes a fuzzy trusted consensus group division method. Based on the historical consensus results of nodes, the node affiliation degree is calculated, and the closest trusted node is selected to participate in the consensus. This avoids the high latency and high energy consumption problems caused by the network-wide broadcast in the traditional consensus mechanism, and significantly improves the consensus efficiency and system response speed.

[0022] In summary, this application, while maintaining the decentralized nature of blockchain, effectively solves the problems of data non-editability, low consensus efficiency, and poor system scalability in existing technologies, and realizes a secure, efficient, and flexible blockchain data editing mechanism. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a dynamically editable blockchain architecture according to this application; Figure 2 This is a flowchart illustrating a chain storage method for a dynamically editable blockchain according to this application. Figure 3 This is a diagram of a chain-like Merkle tree structure. Detailed Implementation

[0024] The present application / disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application / disclosure and are not intended to limit the scope of the present application / disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application / disclosure are shown in the accompanying drawings, not the entire structure.

[0025] This application provides an architecture and chained storage method for a dynamically editable blockchain, based on... Figures 1-3 Scenario describing the technical solutions of the embodiments of this application / disclosure: A dynamically editable blockchain architecture, wherein blockchain nodes include ledger nodes, chain nodes, and dynamically expanding nodes; Ledger nodes: Used to store underlying ledger transaction data; Chain node: Used to point the ledger node ID (specifically the leaf ID of the chained hash tree ledger) pointer to the corresponding dynamically expanding node ID when editing blockchain data; Dynamically expandable nodes: When editing blockchain data, a virtual space corresponding one-to-one with the ledger is dynamically created in the dynamic expansion node to store the data ledger that needs to be changed.

[0026] The data ledger that needs to be changed is stored in the Redis database, and the data to be changed is saved in memory in the form of key-value pairs.

[0027] The key (the unique identifier of the data) is represented by "block ID + numerical rank".

[0028] Specifically, a chained hash tree is used to structure and store the data within the block, with the underlying ledger transaction data stored in the leaf nodes of the chained hash tree; see ledger node for details. Figure 3 The solid line frame portion; this application can also use other structures to associate change data with the correspondence between fixed virtual space.

[0029] In a chained hash tree, the sibling nodes of a leaf node store the public-key encrypted value of the corresponding dynamically expanded node ID. Adding a branch at the end of a leaf node in the original ledger node creates a chain node (e.g., ...). Figure 3 (The area within the dashed box). The chain node stores the corresponding dynamically expanding node ID. For example... Figure 3 In the tree, the sibling nodes of the "value 8" store the public-key encrypted ID value of the dynamically expanded node corresponding to the "value 8". Based on... Figure 3 When an edit block request is initiated, the first step is to locate the ledger data that needs to be modified in the chained Merkle tree, such as... Figure 3 The first step is to use the value 8. Secondly, a trusted node group is used to accept block edit requests (the blockchain nodes that request edits). When half of the nodes in the trusted node group have passed verification, consensus is reached to obtain the corresponding private key. Finally, after decryption using the private key, the location of the editable block in the corresponding dynamically expanded space is found, and data editing is performed. This method allows for a flexible, secure, and efficient implementation of editable blocks.

[0030] The parent node of a leaf node is represented by the hash of all leaf nodes.

[0031] Among them, the chained hash tree is a chained Merkle tree.

[0032] This editable blockchain architecture allows for secure and efficient block editing within a decentralized framework.

[0033] A chained storage method for a dynamically editable blockchain, comprising: Step S1: The blockchain node accepts the client's edit request and verifies the legality of the client's edit request; if the request fails to be verified, the edit request is rejected.

[0034] Step S2: When the legality verification is successful, a fixed virtual space is generated on the dynamically expanding node of the editing request blockchain node to store the edited data; Step S3: The trusted consensus group based on the blockchain determines the trusted nodes of the blockchain node requesting the edit; the trusted consensus group of the blockchain is divided based on the historical consensus results of the blockchain system nodes; Step S4: The editor requests decentralized consensus among all trusted nodes of the blockchain node. When the consensus is passed, the chain node of the blockchain node requests the editor to point the leaf ID pointer of the chain hash tree ledger to the corresponding dynamic expansion node ID and update the corresponding virtual space data in the corresponding dynamic expansion node.

[0035] Verifying the legitimacy of client editing requests includes: identity verification, permission verification, and data format verification.

[0036] Specifically, the affiliation degree of the blockchain node with the trusted consensus group is calculated based on the distance between the blockchain node and the trusted consensus group center point. The trusted node of the blockchain node requesting the edit request is determined based on the affiliation degree of the blockchain node requesting the edit request with the trusted consensus group.

[0037] In each trusted consensus group, find the blockchain node whose absolute affiliation value is closest to that of the blockchain node that made the edit request (the blockchain node that accepted the edit request), and designate it as the trusted node of the blockchain node that made the edit request.

[0038] Among them, based on the historical consensus results of blockchain system nodes, the trusted consensus groups of the blockchain are divided, including: Obtain the historical consensus results of the blockchain system nodes and determine the historical consensus vector of each node in the blockchain system; The initial set of trusted consensus group centers of the blockchain is determined based on the historical consensus vector of each node in the blockchain system. Calculate the Euclidean distance from each node in the blockchain system (specifically, the historical consensus vector of each node) to each central point in the initial set of trusted consensus group central points of the blockchain. Then, assign each node in the blockchain system to a trusted consensus group containing the central point with the smallest Euclidean distance, ultimately forming multiple trusted consensus groups.

[0039] The initial set of trusted consensus group centers in the blockchain is: ; These are the central points of the trusted consensus groups of the 1st, 2nd, 3rd... Zth blockchains, respectively. This serves as the central vector for all nodes in the blockchain system. For all nodes in the blockchain system, the historical consensus vector is... The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , ...... The node furthest away; The total number of trusted consensus groups that a blockchain is divided into.

[0040] Among them, the chained hash tree ledger is a chained Merkle tree ledger.

[0041] Step S3 is explained in detail below: Assuming the blockchain system has Each node, historical consensus The consensus status is shown in Table 1, where "1" indicates that the consensus verification was successful and "0" indicates that the consensus verification was unsuccessful. Table 1 Historical Consensus Status of Nodes

[0042] (1) Assume the first The historical consensus status of each node / historical consensus vector is: ,in, For the first The node The consensus result is 1 for correct and 0 for incorrect.

[0043] (2) Divide all nodes into A trusted consensus group, among which The value can be: Assume the initial set of centroids for each trusted consensus group is... , The selection method is as follows: a. The first / first trusted consensus group selects the center vector of all nodes as the center point. ,in The number of nodes is calculated as shown in Formula 1: ............(Formula 1) b. In all Among the nodes, select the one with The node furthest away serves as the center point of the second trusted consensus group. This selection principle ensures that trusted consensus groups are more dispersed and that inter-group differences are maximized. The distance is calculated as shown in Formula 2: ............(Formula 2); For the first Each node and The distance; ; Let be the s-th dimension value of the historical consensus vector of the i-th node; for The s-th dimension value of the historical consensus vector; c. Similarly, the distance selected for the center point of the third trusted consensus group is... , The farthest point. ...... d. Similarly, the first The distance to the center point of each trusted consensus group The farthest point.

[0045] (3) Calculate the historical consensus vector of each node to the center point. The distance is calculated using the following formula: .......(Formula 3); For the first Each node and The distance; ; Let be the s-th dimension value of the historical consensus vector of the i-th node; for The s-th dimension value of the historical consensus vector; Calculate the distance from each node to the center of the trusted consensus group. Based on the Euclidean distance principle, nodes in the blockchain system are assigned to trusted consensus groups containing the central points with the smallest Euclidean distance, ultimately forming... A trusted consensus group.

[0046] (4) For any node, it does not belong to a fixed trusted consensus group. The degree of affiliation of any node to the trusted consensus group is calculated based on the distance between the node and the center point of the trusted consensus group.

[0047] Assumption For the first The node to the first The degree of affiliation to a trusted consensus group is calculated using Formula 4: ............(Formula 4) For the first Each node and The distance; An implementation example of a chain-based storage method for dynamically editable blockchains is as follows: Case Background: A municipal government service blockchain network consists of 10 nodes (n=10), including the Municipal Civil Affairs Bureau, Finance Bureau, Human Resources and Social Security Bureau, and various district and county sub-district offices, storing records of minimum living allowance payments for all residents of the city. Currently, one block records that resident "Zhang San" receives a minimum living allowance of 800 yuan per month. According to the latest policy of the municipal government, the citywide minimum living allowance standard has been uniformly increased to 900 yuan per month. Therefore, an edit request needs to be initiated for the data in the block containing Zhang San's information.

[0048] 1. The client initiates an edit request: (1) Client: The Civil Affairs Bureau business system, as the authorized client, initiates a data change request. The request content is: change the value of the "Minimum Living Allowance Amount" field of the 5th record (resident Zhang San, ID: 320101...) in BlockID_202310 from "800" to "900".

[0049] (2) Request Verification: A street office node in the blockchain network first receives the request. This node will verify the legitimacy of the request: a. Authentication: Check if the request comes from an authorized Civil Affairs Bureau client (e.g., via a digital signature certificate).

[0050] b. Permission verification: Verify whether the Municipal Civil Affairs Bureau has the authority to modify the minimum living allowance data.

[0051] c. Data format validation: Check whether the data format in the request conforms to the specifications.

[0052] (3) Verification result: The request is verified to be completely legitimate. The street office node accepts the request and triggers the next step: calculating the trusted node group of this node.

[0053] 2. Calculate the trusted nodes of the blockchain: Assume the blockchain network has 10 nodes (Node1 to Node10) and the number of historical consensus iterations (m) is 100. Some historical consensus details are shown in the table below: Table 2 Historical consensus data for example nodes

[0054] (1) Node consensus vector: The historical consensus of each node can be represented as a 100-dimensional vector. For example: Node 1: V1 = (1,1,...,1,1); Node 2: V2 = (1,1,...,1,0); Node 3: V3 = (1,0,...,0,1); (2) Divide into trusted consensus groups (assuming k=3): a. Calculate the centroid C1: According to Formula 1, calculate the centroid vector of all 10 nodes. Each dimension of the centroid vector is the mean of the results of the 10 nodes in this consensus.

[0055] C1 = ( (1+1+1+...+1) / 10, (1+1+0+...+1) / 10, ..., (1+0+1+...+1) / 10 ) Assume the calculation result is C1 ≈ (0.99, 0.98, ..., 0.97) (because most nodes have historically performed well).

[0056] b. Selecting the center point C2: According to Formula 2, calculate the Euclidean distance between all nodes and C1, and select the point with the farthest distance. Assuming that Node3 has the largest difference between its vector and the center point due to multiple consensus errors in history, it is selected as the second center point C2 = V3.

[0057] c. Selecting the center point C3: Calculate the sum of the distances from all nodes to C1 and C2, and select the point with the greatest sum of distances. Assuming Node2 made an error in the most recent consensus and its differences from both C1 and C3 are significant, it is selected as the third center point C3 = V2.

[0058] (3) Preliminary Grouping: According to Formula 3, calculate the Euclidean distance from each node to C1, C2, and C3, and assign them to the group (trusted consensus group) containing the nearest center point. Ultimately, this may result in 3 groups: Trusted Consensus Group 1 (Highly Trusted Group): Includes nodes such as Node1, Node4, Node5, and Node10 that have maintained correct consensus over a long period.

[0059] Trusted Consensus Group 2 (Low Trust Group): Contains nodes with a high number of consensus errors, such as Node3.

[0060] Trusted consensus group 3 (general trusted group): includes nodes such as Node2 that occasionally malfunction.

[0061] (4) Calculate the degree of belonging (fuzzy grouping): The street office node (Node10) that receives the request calculates its degree of belonging to the three trusted consensus groups according to Formula 4. For example, the members of trusted consensus group 1 are (Node1, Node4, Node5, etc.).

[0062] 3. Generate editable block ledger nodes, chain nodes, and dynamically expanding nodes: Suppose the original block structure for recording resident Zhang San's data is as follows: (1) Ledger Nodes: In a linked Merkle tree, leaf nodes store the specific ledger data. For example: Leaf node 5: {Resident ID: "320101...", Name: "Zhang San", Minimum subsistence allowance: "800 yuan", ...} The hash values ​​of these data are calculated layer by layer upwards, eventually forming the root hash of the tree, which is stored in the block header.

[0063] (2) Chain node: When constructing this block, the system has generated a chain node for each data item that may be edited. At the sibling node position of "value 800", a string encrypted with a public key is stored. This string is the ID pointer to the dynamically expanded node.

[0064] (3) Dynamically expanded nodes: At this time, there is no data related to the key "Zhang San" in the space of dynamically expanded nodes (such as Redis database).

[0065] 4. Block editing process: Positioning and Consensus: The system calculates the node closest to the client initiating the edit request (e.g., a neighborhood office) among the three trusted consensus groups mentioned above. For example, node 1 in consensus group 1, node 6 in consensus group 2, and node 7 in consensus group 3. Once nodes 1, 6, and 7 reach consensus, a sibling node is generated on the data tree that needs editing. This sibling node points to the corresponding key in the in-memory database. Afterward, any request to query Zhang San's data will first search for the key in the dynamically expanded nodes. If found, the system returns the latest merged data (the "800 yuan" in the original data is overwritten by the "900 yuan" in the dynamically expanded data); if not found, the original ledger data is returned.

[0066] The beneficial effects of this application are as follows: 1. Achieving coexistence of editability and decentralization in blockchain data: Traditional blockchain technology is characterized by its immutability and uneditability, which becomes a limitation in certain application scenarios (such as data error correction and compliance adjustments). This application solves the core problem of "uneditability of blockchain" in existing technologies by introducing dynamically expanding nodes and a chain-like Merkle tree structure, enabling secure and efficient data updates without destroying the original ledger data.

[0067] 2. Enhance the scalability and flexibility of the blockchain system: By dividing nodes into three categories—ledger nodes, chain nodes, and dynamically expanding nodes—the system architecture becomes clearer, and the functional division is more defined. The introduction of dynamically expanding nodes allows the system to flexibly respond to data change requirements without modifying the original ledger, significantly improving the scalability and adaptability of the blockchain system.

[0068] 3. Ensuring Data Security and Consistency: During the editing process, all changed data is stored in a fixed virtual space of dynamically expanding nodes and mapped to a chained Merkle tree via hash pointers, ensuring that the data change process is traceable and tamper-proof. Simultaneously, the decentralized consensus mechanism of trusted node groups effectively prevents malicious nodes from tampering with data, ensuring the overall security of the system.

[0069] 4. Improve block editing efficiency and consensus efficiency: This application proposes a fuzzy trusted consensus group division method. Based on the historical consensus results of nodes, the node affiliation degree is calculated, and the closest trusted node is selected to participate in the consensus. This avoids the high latency and high energy consumption problems caused by the network-wide broadcast in the traditional consensus mechanism, and significantly improves the consensus efficiency and system response speed.

[0070] In summary, this application, while maintaining the decentralized nature of blockchain, effectively solves the problems of data non-editability, low consensus efficiency, and poor system scalability in existing technologies, and realizes a secure, efficient, and flexible blockchain data editing mechanism.

Claims

1. An architecture for a dynamically editable blockchain, characterized in that, The blockchain nodes in the architecture include ledger nodes, chain nodes, and dynamically expanding nodes. Ledger nodes: Used to store underlying ledger transaction data; Chain node: Used to point the ledger node ID pointer to the corresponding dynamically extended node ID when editing blockchain data; Dynamically expandable nodes: When editing blockchain data, a virtual space corresponding one-to-one with the ledger is dynamically created in the dynamic expansion node to store the data ledger that needs to be changed.

2. The architecture of a dynamically editable blockchain according to claim 1, characterized in that, The data ledger that needs to be changed is stored in the database, and the data that needs to be changed is saved in memory in the form of key-value pairs.

3. The architecture of a dynamically editable blockchain according to claim 2, characterized in that, The key is represented by "block ID + numerical rank".

4. The architecture of a dynamically editable blockchain according to claim 1, characterized in that, A chained hash tree is used to structure and store the data within the block, and the underlying ledger transaction data is stored in the leaf nodes of the chained hash tree; In the chained hash tree, the sibling nodes corresponding to the leaf nodes store the public key encrypted value of the dynamic expansion node ID.

5. The architecture of a dynamically editable blockchain according to claim 4, characterized in that, The parent node of a leaf node is represented by the hash calculation of all leaf nodes.

6. A chain-based storage method for a dynamically editable blockchain, characterized in that, include: Step S1: The blockchain node accepts the client's edit request and verifies the legality of the client's edit request; Step S2: When the legality verification is successful, a fixed virtual space is generated on the dynamically expanding node of the editing request blockchain node to store the edited data; Step S3: The trusted consensus group based on the blockchain determines the trusted nodes of the blockchain node requesting the edit; the trusted consensus group of the blockchain is divided based on the historical consensus results of the blockchain system nodes; Step S4: The blockchain node requesting the editing request reaches a decentralized consensus among all trusted nodes. When the consensus is reached, the chain node of the blockchain node requesting the editing request points the ledger node ID pointer to the corresponding dynamic expansion node ID and updates the corresponding virtual space data in the corresponding dynamic expansion node.

7. The chained storage method for a dynamically editable blockchain according to claim 6, characterized in that, Verifying the legitimacy of a client's edit request includes: identity verification, permission verification, and data format verification.

8. A chained storage method for a dynamically editable blockchain according to claim 6, characterized in that, In step S3, the affiliation degree between the blockchain node and the trusted consensus group is calculated based on the distance between the blockchain node and the trusted consensus group center point of the blockchain. The trusted node of the edit request blockchain node is determined based on the affiliation degree between the edit request blockchain node and the trusted consensus group.

9. A chain-based storage method for a dynamically editable blockchain according to claim 8, characterized in that, In each trusted consensus group, the blockchain node whose absolute affiliation value is closest to that of the blockchain node requesting the edit is identified as the trusted node of the blockchain node requesting the edit.

10. A chained storage method for a dynamically editable blockchain according to claim 6, characterized in that, Based on the historical consensus results of blockchain system nodes, the blockchain is divided into trusted consensus groups, including: Obtain the historical consensus results of the blockchain system nodes and determine the historical consensus vector of each node in the blockchain system; The initial set of trusted consensus group centers of the blockchain is determined based on the historical consensus vector of each node in the blockchain system. Calculate the Euclidean distance from each node in the blockchain system to each central point in the initial set of trusted consensus group central points of the blockchain, and assign each node in the blockchain system to a trusted consensus group containing the central point with the smallest Euclidean distance, thus forming multiple trusted consensus groups.

11. A chain storage method for a dynamically editable blockchain according to claim 10, characterized in that, The initial set of trusted consensus group centers in a blockchain is ; These are the central points of the trusted consensus groups of the 1st, 2nd, 3rd... Zth blockchains, respectively. This serves as the central vector for all nodes in the blockchain system. For all nodes in the blockchain system, the historical consensus vector is... The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , The node furthest away; For all nodes in the blockchain system, the historical consensus vector and , ...... The node furthest away; The total number of trusted consensus groups that a blockchain is divided into.

Images