A block data structure of an editable blockchain and a tamper-proof verification method

Abstract

This invention discloses an editable blockchain block data structure and a tamper-proof verification method. The block header of the block data structure includes: a previous block hash field, a timestamp field, a Merkle root field, a pre-edit block hash field, a post-edit block hash field, and an edit verification field. The previous block hash field stores the hash value of the previous block; the timestamp field stores the block generation time; the Merkle root field stores the Merkle root of the block body; the pre-edit block hash field stores the hash value of the block before editing; the post-edit block hash field stores the hash value of the block after editing; and the edit verification field stores the verification node's agreement to edit response. This invention supports blockchain editability while preventing malicious nodes from maliciously tampering with the blockchain using its editability feature.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to an editable blockchain block data structure and a tamper-proof verification method. Background Technology

[0002] Blockchain technology has been applied in various fields, including digital finance, the Internet of Things, smart manufacturing, supply chain management, and digital asset trading. Major countries around the world are accelerating the development of blockchain technology. As a new decentralized infrastructure and distributed computing paradigm, blockchain features data immutability, traceability, and ledger sharing, and can play an important role in promoting data sharing, optimizing business processes, reducing operating costs, improving collaborative efficiency, and building a trustworthy system.

[0003] While the "immutable" nature of blockchain enhances its trustworthiness, it also brings certain inconveniences and negative impacts. Users may wish to delete data already written to the blockchain for reasons such as privacy protection and data security. Simultaneously, illegal or non-compliant information may be maliciously written to the blockchain by users. Therefore, editable and deleteable blockchain technology is needed to enable the editing of specific data stored in the blockchain, including modification and deletion, without compromising its trustworthiness. Modification operations can be completed by deleting the original record and generating a new one.

[0004] In response to the aforementioned technical problems, those skilled in the art have conducted some relevant research.

[0005] Chinese patent application CN115914263A discloses an information management method, apparatus, and editable blockchain management system. Based on a dual-chain structure and privileged nodes, the editable blockchain management system includes an editable first blockchain and a non-editable second blockchain. Editing of the first blockchain is based on a chameleon trapdoor, and the second blockchain is configured with smart contracts that are configured to record update operations occurring on the first blockchain.

[0006] Chinese patent application CN115422600A discloses a method, system, and apparatus for processing elderly care service data. It realizes the editability of blockchain based on the chameleon hash function, which can edit the current elderly care service data stored in the editable blockchain into target elderly care service data. In this method, when the trapdoor verification message sent by the privileged node meets the pass condition, the arbitration coefficient is modified to a second preset value, which increases the weight of the privileged node and improves the fairness of content editing.

[0007] Chinese patent application CN115348274A discloses an offshore data distributed storage system based on mutable blockchain technology. It consists of a distributed storage layer, a distributed network layer, a blockchain service layer, and an application layer. Employing mutable blockchain storage technology, it can correct and delete inappropriate or illegal information, meeting the security supervision and handling requirements of offshore big data. Key-holding nodes are responsible for storing the private keys of the chameleon hash, computing nodes are responsible for calculating new blocks, and consensus nodes are responsible for voting on edit requests and results. When erroneous, harmful, or expired information is detected, a node issues its first blockchain edit request and broadcasts it to the entire network. All nodes in the system verify the request and check its rationality. The request is approved when a predetermined number of nodes agree; otherwise, it is rejected. The system selects a node to edit the blockchain according to a predetermined strategy. The node with modification rights edits the block information according to the request and broadcasts it to the entire network. The remaining nodes verify the operation results and update their own ledgers upon successful verification.

[0008] Chinese patent application CN114840545A discloses a fine-grained editing method for blockchain that supports rapid state updates. This method allows for quick and energy-efficient updates of the state data held by blockchain nodes after editing operations have been performed on the editable blockchain, thereby improving the performance and availability of the editable blockchain.

[0009] Chinese patent application CN115174037A discloses a method and apparatus for constructing a chameleon hash function based on SM9 signature. Users can calculate hash values ​​using the constructed chameleon hash function: knowing the user's private key, a new message pair (m″,R″) can be forged such that Hash(ID,m″,R″) = Hash(ID,m,R), i.e., a hash collision is found.

[0010] Chinese patent application CN113868262A discloses a method, apparatus, readable medium, and computer device for editing a blockchain. Each block in this blockchain includes a parent block hash value module, a modification hash value module, and a block hash value module. When an edit request for data in the current block is received, a network-wide vote is initiated, and the decision on whether to allow the data editing is made based on the voting results. If allowed, a new block storing the edit request is generated, and the hash value of the previous block of the new block is stored in the parent block hash value module of the new block, the current hash value of the current block is stored in the modification hash value module of the new block, and the hash value of the new block is stored in the block hash value module of the current block.

[0011] However, patents such as CN115914263A, CN115422600A, CN115348274A, and CN115174037A employ specific chameleon hash functions to enable the editing of on-chain data. Users with the key can use the trapdoor of the chameleon hash to find a collision in existing data, thereby modifying historical block data without altering the integrity of the hash chain between blocks. When verifying the chain relationship of the blockchain, since the block hash remains unchanged, the verification method does not need to be adjusted. However, practical blockchain systems typically use collision-resistant hash functions, thus significantly limiting the applicability of this scheme. Furthermore, the chameleon hash function may have a threshold key exposure problem, posing a security risk.

[0012] CN115623080A and similar solutions employ a dual-chain model to enable on-chain data editability. Modified data is stored on a separate "modified chain," ensuring that the modified "original chain" still meets integrity verification logic. Verification mechanisms maintain both the "original chain" and the "modified chain." When a modified block is encountered on the "original chain," the system switches to the "modified chain" to retrieve the corresponding block data. However, this approach also fails to truly remove illegal content from the blocks. Even after synchronizing block data, users can still access illegal information on the chain, making it difficult to meet regulatory requirements such as on-chain content deletion.

[0013] Furthermore, CN113868262A and others employ a triple hash method, simultaneously setting the parent block hash, modification hash, and block hash in a single block header. This scheme is suitable for modifications at the block level, but lacks specific design for modifications at the transaction level.

[0014] Finally, CN114840545A is used to quickly and energy-efficiently update the state data held by blockchain nodes after the editable blockchain has completed the editing operation, in order to improve update performance, but it does not involve the editable block data structure. Summary of the Invention

[0015] To address the aforementioned issues, this invention proposes an editable blockchain block data structure and a tamper-proof verification method. This method not only supports the modification and editing of block data by constructing a new block data structure without altering the hash function used by the existing blockchain, while maintaining the chain structure of the entire blockchain, but also prevents malicious nodes from exploiting the editable nature of the blockchain to tamper with it. When verifying historical blockchain data, blockchain nodes can identify edited blocks and verify that the modification is legitimate and not malicious.

[0016] The technical solution of the present invention includes the following:

[0017] An editable blockchain block data structure, wherein the block header of the block data structure includes: a previous block hash field, a timestamp field, a Merkle root field, a pre-edit block hash field, a post-edit block hash field, and an edit verification field;

[0018] The previous block hash field is used to store the hash value of the previous block;

[0019] The timestamp field is used to store the block generation time;

[0020] The Merkle root field is used to store the Merkle root of the block body;

[0021] The pre-edit block hash field is used to store the hash value of the pre-edit block;

[0022] The edited block hash field is used to store the hash value of the edited block;

[0023] The edit verification field is used to store the verification node's consent to edit response.

[0024] Furthermore, the process of any node editing a block based on the block data structure includes:

[0025] Any node can initiate an edit request for a transaction in a block within the blockchain network;

[0026] After the edit request is verified by the verification node, the verification node sends an approval response to the blockchain network.

[0027] Consensus nodes collect consent edit responses from verification nodes in the blockchain network, and if the consent edit responses meet the specified requirements, they confirm the deletion of the specified transaction in the specified blockchain;

[0028] The consensus node calculates the hash value of the block before editing and puts it into the hash field of the block before editing;

[0029] The consensus node deletes the specified transaction from the block body;

[0030] The consensus node calculates the current Merkle root and puts it into the Merkle root field; the consensus node puts the collected agree edit responses into the edit verification field;

[0031] The consensus node calculates the hash value of the edited block and puts it into the hash field of the edited block.

[0032] Furthermore, the edit request includes: the block height of the transaction to be deleted, the transaction ID of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the user's digital signature.

[0033] Furthermore, the edit request is verified by the verification node, including:

[0034] The verification node performs a legality verification on the edit request; wherein, the legality verification includes: whether the editor's identity ID has the authority to edit, whether the user's digital signature is consistent with the editor's ID, and whether the format of the edit request is legal;

[0035] If the edit request is valid, the verification node determines whether to approve the edit request.

[0036] If the validator node agrees to the edit request, it generates a response message agreeing to the edit request, and sends the response message to the blockchain network after digitally signing it; the fields of the digital signature include the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block where the transaction to be deleted is located;

[0037] If the verification node does not agree to the edit request, it will not send a message, or it will generate a response message that disagrees with the edit request, digitally sign the response message, and send it to the blockchain network.

[0038] Furthermore, the process by which any node verifies the legality of a block based on the block data structure during block synchronization includes:

[0039] Attempt to fetch the next block of the block;

[0040] If the next block is not found, the current block is considered the latest block and no edit operation is required.

[0041] If the next block of a block is obtained, the hash value of that block is calculated and compared with the hash value of the previous block stored in the next block of that block;

[0042] If the hash value of the block is the same as the hash value of the previous block stored in the next block, then the block is considered to have not been edited.

[0043] If the hash value of the block is inconsistent with the hash value of the previous block stored in the next block of the block, then the hash value of the block before editing is compared with the hash value of the previous block stored in the next block of the block; wherein the hash value of the block before editing is stored in the hash field of the block before editing.

[0044] If the hash value of the block before editing is inconsistent with the hash value of the previous block stored in the next block of this block, then the block is determined to be invalid.

[0045] If the hash value of the block before editing is the same as the hash value of the previous block stored in the next block of the block, then the hash value of the block before editing is compared with the hash value of the block after editing; wherein, the hash value of the block before editing is not included in the hash field of the block after editing, and the hash value of the block after editing is stored in the hash field of the block after editing.

[0046] If the hash value of the block is inconsistent with the hash value of the edited block, the block is deemed invalid.

[0047] If the hash value of the block matches the hash value of the edited block, then verify that there are enough agreed edit responses in the edit verification field;

[0048] If there are not enough agreed-upon edit responses in the edit validation field, the block is determined to be illegally tampered with;

[0049] If there are enough agreeing edit responses in the edit verification field, the hash of the deleted transaction stored in the edit verification field is retrieved, and the Merkle root is calculated together with the undeleted transaction. The Merkle root is then compared with the Merkle root stored in the edit verification field. If they match, the block is considered a legitimate edit; otherwise, it is considered an illegal tampering.

[0050] A method for tamper-proof verification of an editable blockchain, wherein the block header of the editable blockchain's block data structure includes: a previous block hash field, a timestamp field, a Merkle root field, a pre-edit block hash field, a post-edit block hash field, and an edit verification field, the method comprising:

[0051] During the block editing phase, the verification nodes verify any editing request initiated by any node, and the consensus nodes update the block header and block body of the target block based on the agreed editing response generated by the verification nodes.

[0052] During the block validity verification phase, any node verifies the validity of the target block based on the hash value of the current block, the block header of the current block, the block body of the current block, and the block header of the next block of the target block.

[0053] Furthermore, the edit request includes: the block height of the transaction to be deleted, the transaction ID of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the user's digital signature.

[0054] Furthermore, the edit request is verified by the verification node, including:

[0055] The verification node performs a legality verification on the edit request; wherein, the legality verification includes: whether the editor's identity ID has the authority to edit, whether the user's digital signature is consistent with the editor's ID, and whether the format of the edit request is legal;

[0056] If the edit request is valid, the verification node determines whether to approve the edit request.

[0057] If the validator node agrees to the edit request, it generates a response message agreeing to the edit request, and sends the response message to the blockchain network after digitally signing it; the fields of the digital signature include the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block where the transaction to be deleted is located;

[0058] If the validator node disagrees with the edit request, it will not send a message, or it will generate a response message disagreeing with the edit request, digitally sign the response message, and send it to the blockchain network. The fields of the digital signature include the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block where the transaction to be deleted is located.

[0059] Furthermore, based on the agreement edit response generated by the validator nodes, the consensus nodes update the block header and block body of the target block, including:

[0060] Collect consent edit responses from validating nodes in the blockchain network, and confirm the deletion of the specified transaction in the specified blockchain if the consent edit responses meet the specified requirements;

[0061] Calculate the hash value of the block before editing and put it into the hash field of the block before editing;

[0062] Delete the specified transaction from the block body;

[0063] Calculate the current Merkle root and put it into the Merkle root field;

[0064] Place the collected consent edit responses into the edit verification field;

[0065] Calculate the hash value of the edited block and put it into the hash field of the edited block;

[0066] Furthermore, any node verifies the legitimacy of the target block based on the hash value of the current block, the block header of the current block, the block body of the current block, and the block header of the next block of the target block, including:

[0067] Attempt to retrieve the next block of the target block;

[0068] If the next block of the target block is not found, the target block is determined to be the latest block, and no edit operation is required.

[0069] If the next block of the target block is obtained, the hash value of the target block is calculated and compared with the hash value of the previous block stored in the next block of the target block.

[0070] If the hash value of the target block is consistent with the hash value of the previous block stored in the next block of the target block, then the target block is considered valid.

[0071] If the hash value of the target block is inconsistent with the hash value of the previous block stored in the next block of the target block, then the hash value of the block before editing is compared with the hash value of the previous block stored in the next block of the target block; wherein, the hash value of the block before editing is stored in the hash field of the block before editing of the target block.

[0072] If the hash value of the block before editing is inconsistent with the hash value of the previous block stored in the next block of the target block, then the target block is determined to be invalid.

[0073] If the hash value of the block before editing is consistent with the hash value of the previous block stored in the next block of the target block, then the hash value of the target block is compared with the hash value of the block after editing; wherein, the hash value of the target block is not included in the hash field of the block after editing, and the hash value of the block after editing is stored in the hash field of the block after editing of the target block;

[0074] If the hash value of the target block is inconsistent with the hash value of the edited block, the target block is determined to be invalid.

[0075] If the hash value of the target block matches the hash value of the edited block, then verify that there are enough agree edit responses in the edit verification field;

[0076] If there are not enough agreed-upon edit responses in the edit verification field, the target block is determined to be illegally tampered with;

[0077] If there are enough agreeing edit responses in the edit verification field, the hash of the deleted transaction stored in the edit verification field is retrieved, and the Merkle root is calculated together with the undeleted transaction. The Merkle root is then compared with the Merkle root stored in the edit verification field. If they match, the target block is determined to be a legitimate edit; otherwise, it is considered an illegal tampering.

[0078] Compared with existing technologies, this invention provides an editable blockchain technology solution that supports the deletion of transactions and information in the blockchain without compromising the trustworthiness of the blockchain. This satisfies the needs of users who may delete data already written to the blockchain for reasons such as privacy protection and data security, or delete illegal or non-compliant information stored in the blockchain for security supervision. Attached Figure Description

[0079] Figure 1 This is a common block data structure.

[0080] Figure 2 This invention relates to the block data structure of an editable blockchain.

[0081] Figure 3 This is a flowchart of the anti-tampering verification method of the present invention. Detailed Implementation

[0082] To make the objectives, contents, and advantages of this invention clearer and more apparent, and to enable those skilled in the art to understand this invention, the invention will now be described in further detail with reference to the accompanying drawings.

[0083] This invention provides an editable blockchain data structure and a tamper-proof verification method, wherein modification operations can be completed by deleting the original record and generating a new record. The data structure adds three fields: "block hash before edit," "block hash after edit," and "edit verification." During normal execution, each block calculates its own hash and writes it to the "block hash before edit" field. When transaction data within a block is deleted, nodes that agree to the deletion digitally sign the deletion operation, store it in the edit verification field, and recalculate the hash of the new block, writing it to the "block hash after edit." When a node synchronizes with the block data and verifies its legality, it first calculates the hash of the block. If it matches the hash of the previous block stored in the next block, the block has not been edited; otherwise, the block has been edited or is an invalid block. To further verify, first check if the "block hash before editing" matches the hash of the previous block stored in the next block. If they don't match, it's an invalid block. If they match, further calculate the block's hash and compare it with the "block hash after editing" field. If they don't match, it's an invalid block. If they match, it means the block has been edited, and further verify the "edit verification" to confirm the legality of the edit, rather than illegal tampering. Within the same blockchain, multiple transactions may be edited; the operation and verification process are the same as above.

[0084] The steps are as follows:

[0085] 1. Editable block structure

[0086] (1) Block header and block body

[0087] Common block data structures, such as Figure 1As shown, a block consists of two parts: a block header and a block body. The block header stores a summary of the block, typically including the hash of the previous block, a timestamp, and the Merkle root of the transactions. The block body stores the specific transactions in the blockchain, each with a unique hash as its ID. The hash of the previous block in the block header is obtained by calculating the hash of the previous block (including the block header and block body); the Merkle root of each transaction is obtained by calculating the Merkle tree of all transactions within the block body.

[0088] In the block structure designed in this invention, such as Figure 2 As shown, three fields are added to the block header: "block hash before edit", "block hash after edit", and "edit verification".

[0089] • Block hash before edit: The block hash before edit is the original hash of the block, representing the hash of the block without any editing. This field is empty when the transaction data in the block is not edited; if the transaction data in the block needs to be edited, the block hash before edit is first calculated and filled into this field.

[0090] • Edited block hash: When a block is edited, the hash of the resulting block is calculated (this field is not included in the calculation) and then placed into this field.

[0091] • Edit Verification: This field stores the agreed-upon edit response message, used to verify whether the edit operation has been approved by the blockchain network and is a legitimate edit operation, preventing malicious tampering with the block.

[0092] 2. Block Editing

[0093] (1) Initiating an edit request: Nodes in the blockchain network can initiate a request to edit a block. After digitally signing, the request is sent to the blockchain network. The request includes the block height of the transaction to be deleted, the ID of the transaction to be deleted, the editor's identity ID, the time of initiating the request, and the user's digital signature.

[0094] (2) Verify the edit request: When a verification node in the blockchain network receives an edit request, it verifies the legality of the request. The information to be verified includes whether the editor's identity ID has the right to edit (setting the permission set), whether the user's digital signature is consistent with the editor's ID, and whether the format of the edit request is legal.

[0095] If the edit request is valid and the validator node agrees to the edit request, a response message agreeing to the edit request is sent, and the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block in which the transaction to be deleted is located are digitally signed and sent to the blockchain network;

[0096] If the edit request is invalid, or the verification node does not agree to the edit request, it will send a message disagreeing with the edit response request, or it will not send any message.

[0097] (3) Collect verification messages: Consensus nodes collect the consent edit responses issued by verification nodes in the blockchain network. According to the consensus protocol for blockchain data editing, if the consent edit response meets the consensus requirements of the system, the specified transaction is confirmed to be deleted.

[0098] (4) Build the edited block: Perform the following steps.

[0099] Calculate the hash value of the block before editing and put it into the hash field of the block before editing;

[0100] Delete the specified transaction from the block body;

[0101] Calculate the current Merkle root and put it into the Merkle root field;

[0102] Place the collected consent edit responses into the edit verification field;

[0103] Calculate the hash value of the edited block and put it into the hash field of the edited block;

[0104] 3. Blockchain legitimacy verification

[0105] Any node can verify the validity of a block during synchronization, such as... Figure 3 As shown, the specific steps are as follows.

[0106] (1) Calculate the hash of the block and compare it with the "previous block hash" stored in the next block; if there is no next block, it indicates that the blockchain is a newly generated latest block and there is no edit operation.

[0107] (2) If the hash of the previous block stored in the next block is consistent with the hash of the previous block, it means that the block has not been edited and regular verification is performed; if they are inconsistent, it means that the block has been edited or is an illegal block and further verification is required.

[0108] (3) For further verification, first compare the "previous block hash" with the "previous block hash" stored in the next block. If they do not match, the block is invalid and is discarded. If they match, further calculate the hash of the block (excluding the "post-edited block hash" field) and compare it with the "post-edited block hash" field. If they do not match, the block is invalid. If they match, it means the block has been edited. Then, further verify whether the "edit verification" field meets the consensus protocol of blockchain editing to verify the legality of the edit, rather than illegal tampering. If the consensus protocol of blockchain editing is met, further extract the hash of the deleted transaction stored in the edit verification field, calculate the Merkle root together with the undeleted transaction, and compare it with the Merkle root stored in the edit verification field. If they match, it is a legal edit. Otherwise, it is an illegal tampering.

[0109] In summary, this invention, without altering the hash function used by existing blockchains, constructs a new block data structure to support the modification and editing of block data while maintaining the chain structure of the entire blockchain. Furthermore, while supporting blockchain editability, this invention also prevents malicious nodes from exploiting the editability of the blockchain to tamper with it. When verifying historical blockchains, blockchain nodes can identify edited blocks and verify that the modification is legitimate and not malicious.

[0110] Although specific embodiments of the invention have been disclosed for illustrative purposes to aid in understanding and implementing the invention, those skilled in the art will understand that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the invention and the appended claims. Therefore, the invention should not be limited to the content disclosed in the preferred embodiments, and the scope of protection claimed by the invention is defined by the claims.

Claims

1. A block data structure device for an editable blockchain, characterized in that, The block header of the block data structure includes: the previous block hash field, the timestamp field, the Merkle root field, the block hash field before editing, the block hash field after editing, and the edit verification field; The previous block hash field is used to store the hash value of the previous block; The timestamp field is used to store the block generation time; The Merkle root field is used to store the Merkle root of the block body; The pre-edit block hash field is used to store the hash value of the pre-edit block; The edited block hash field is used to store the hash value of the edited block; The edit verification field is used to store the verification node's consent to edit response; The process of any node editing a block based on the block data structure includes: Any node can initiate an edit request for a transaction in a block within the blockchain network; After the edit request is verified by the verification node, the verification node sends an approval response to the blockchain network. Consensus nodes collect consent edit responses from verification nodes in the blockchain network, and if the consent edit responses meet the specified requirements, they confirm the deletion of the specified transaction in the specified blockchain; The consensus node calculates the hash value of the block before editing and puts it into the hash field of the block before editing; The consensus node deletes the specified transaction from the block body; The consensus node calculates the current Merkle root and puts it into the Merkle root field; The consensus node places the collected consent edit responses into the edit verification field; The consensus node calculates the hash value of the edited block and puts it into the hash field of the edited block; The process by which any node verifies the legality of a block based on the block data structure during block synchronization includes: Attempt to fetch the next block of the block; If the next block is not found, the current block is considered the latest block and no edit operation is required. If the next block of a block is obtained, the hash value of that block is calculated and compared with the hash value of the previous block stored in the next block of that block; If the hash value of the block is the same as the hash value of the previous block stored in the next block, then the block is considered to have not been edited. If the hash value of the block is inconsistent with the hash value of the previous block stored in the next block of the block, then the hash value of the block before editing is compared with the hash value of the previous block stored in the next block of the block; wherein the hash value of the block before editing is stored in the hash field of the block before editing. If the hash value of the block before editing is inconsistent with the hash value of the previous block stored in the next block of this block, then the block is determined to be invalid. If the hash value of the block before editing is the same as the hash value of the previous block stored in the next block of the block, then the hash value of the block before editing is compared with the hash value of the block after editing; wherein, the hash value of the block before editing is not included in the hash field of the block after editing, and the hash value of the block after editing is stored in the hash field of the block after editing. If the hash value of the block is inconsistent with the hash value of the edited block, the block is deemed invalid. If the hash value of the block matches the hash value of the edited block, then verify that there are enough agreed edit responses in the edit verification field; If there are not enough agreed-upon edit responses in the edit validation field, the block is determined to be illegally tampered with; If there are enough agreeing edit responses in the edit verification field, the hash of the deleted transaction stored in the edit verification field is retrieved, and the Merkle root is calculated together with the undeleted transaction. The Merkle root is then compared with the Merkle root stored in the edit verification field. If they match, the block is considered a legitimate edit; otherwise, it is considered an illegal tampering.

2. The block data structure apparatus as described in claim 1, characterized in that, The edit request includes: the block height of the transaction to be deleted, the transaction ID of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the user's digital signature.

3. The block data structure apparatus as described in claim 2, characterized in that, The edit request is verified by the verification node, including: The verification node performs a legality verification on the edit request; wherein, the legality verification includes: whether the editor's identity ID has the authority to edit, whether the user's digital signature is consistent with the editor's ID, and whether the format of the edit request is legal; If the edit request is valid, the verification node determines whether to approve the edit request. If the validator node agrees to the edit request, it generates a response message agreeing to the edit request, and sends the response message to the blockchain network after digitally signing it; the fields of the digital signature include the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block where the transaction to be deleted is located; If the validator does not agree to the edit request, it either does not send a message, or it generates a response message that disagrees with the edit request, digitally signs the response message, and sends it to the blockchain network.

4. A tamper-proof verification method for an editable blockchain, characterized in that, The block header of the editable blockchain's block data structure includes: a previous block hash field, a timestamp field, a Merkle root field, a pre-edit block hash field, a post-edit block hash field, and an edit verification field. The method includes: During the block editing phase, the verification nodes verify any editing request initiated by any node, and the consensus nodes update the block header and block body of the target block based on the agreed editing response generated by the verification nodes. During the block validity verification phase, any node verifies the validity of the target block based on the hash value of the current block, the block header of the current block, the block body of the current block, and the block header of the next block of the target block. Specifically, the consensus node updates the block header of the target block based on the agreed-upon edit response generated by the verification node, including: Collect consent edit responses from validating nodes in the blockchain network, and confirm the deletion of the specified transaction in the specified blockchain if the consent edit request meets the specified requirements; Calculate the hash value of the block before editing and put it into the hash field of the block before editing; Delete the specified transaction from the block body; Calculate the current Merkle root and put it into the Merkle root field; Place the collected consent edit responses into the edit verification field; Calculate the hash value of the edited block and put it into the hash field of the edited block; Each node verifies the validity of the target block based on the hash value of the current block, the block header of the current block, the block body of the current block, and the block header of the next block of the target block, including: Attempt to retrieve the next block of the target block; If the next block of the target block is not found, the target block is determined to be the latest block, and no edit operation is required. If the next block of the target block is obtained, the hash value of the target block is calculated and compared with the hash value of the previous block stored in the next block of the target block. If the hash value of the target block is consistent with the hash value of the previous block stored in the next block of the target block, then the target block is considered valid. If the hash value of the target block is inconsistent with the hash value of the previous block stored in the next block of the target block, then the hash value of the block before editing is compared with the hash value of the previous block stored in the next block of the target block; wherein, the hash value of the block before editing is stored in the hash field of the block before editing of the target block. If the hash value of the block before editing is inconsistent with the hash value of the previous block stored in the next block of the target block, then the target block is determined to be invalid. If the hash value of the block before editing is consistent with the hash value of the previous block stored in the next block of the target block, then the hash value of the target block is compared with the hash value of the block after editing; wherein, the hash value of the target block is not included in the hash field of the block after editing, and the hash value of the block after editing is stored in the hash field of the block after editing of the target block; If the hash value of the target block is inconsistent with the hash value of the edited block, the target block is determined to be invalid. If the hash value of the target block matches the hash value of the edited block, then verify that there are enough agree edit responses in the edit verification field; If there are not enough agreed-upon edit responses in the edit verification field, the target block is determined to be illegally tampered with; If there are enough agreeing edit responses in the edit verification field, the hash of the deleted transaction stored in the edit verification field is retrieved, and the Merkle root is calculated together with the undeleted transaction. The Merkle root is then compared with the Merkle root stored in the edit verification field. If they match, the target block is determined to be a legitimate edit; otherwise, it is considered an illegal tampering.

5. The method as described in claim 4, characterized in that, The edit request includes: the block height of the transaction to be deleted, the transaction ID of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the user's digital signature.

6. The method as described in claim 5, characterized in that, The edit request is verified by the verification node, including: The verification node performs a legality verification on the edit request; wherein, the legality verification includes: whether the editor's identity ID has the authority to edit, whether the user's digital signature is consistent with the editor's ID, and whether the format of the edit request is legal; If the edit request is valid, the verification node determines whether to approve the edit request. If the validator node agrees to the edit request, it generates a response message agreeing to the edit request, and sends the response message to the blockchain network after digitally signing it; the fields of the digital signature include the hash of the transaction to be deleted, the editor's identity ID, the timestamp of the edit request, and the original Merkle root of the block where the transaction to be deleted is located; If the validator does not agree to the edit request, it either does not send a message, or it generates a response message that disagrees with the edit request, digitally signs the response message, and sends it to the blockchain network.

Images