A Byzantine Fault-Tolerant Consortium Chain Data Efficient Editing Method

Abstract

The present invention discloses a Byzantine fault-tolerant method for efficient on-chain data editing in a consortium chain, which includes a data editing protocol and a request consensus protocol. First, the data editing protocol utilizes chameleon hashing technology and optimizes the underlying block replacement strategy to achieve efficient modification of block content and rapid updating of on-chain data, thereby improving the efficiency of data editing. Secondly, the request consensus protocol designs a consensus mechanism for block editing requests that is unaffected by malicious nodes. Through multiple rounds of voting and edit verification, it ensures that all honest nodes execute the same block editing operation, thereby maintaining data consistency between nodes in a Byzantine environment. Furthermore, the present invention introduces an optimization strategy for multi-node concurrent consensus, which significantly improves the response speed and throughput performance of the consortium chain system.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular to a method for efficiently editing data on a consortium chain. Background Art

[0002] Since its introduction, blockchain technology, as a decentralized ledger, has garnered significant attention for its high degree of data tamper-resistance. On public blockchains, this property prevents illicit transactions and historical record tampering. Compared to public blockchains, consortium blockchains feature a robust access control mechanism, enhancing network security and privacy. Furthermore, because participants are relatively trustworthy, consortium chains can employ more efficient consensus algorithms, significantly improving transaction processing speed and network performance. Currently, the core purpose of consortium blockchains is to facilitate data sharing and data access across multiple organizations. Consequently, consortium blockchain systems are widely used in multi-party collaborative applications, such as supply chain management, medical record sharing, and financial transactions.

[0003] However, while blockchain's immutability provides a guarantee for data security, it also presents certain challenges to the oversight and management of consortium chains. Once sensitive content is recorded on-chain, it becomes extremely difficult to modify or delete. For example, if personal privacy, copyright, or misleading content is not promptly updated after being uploaded to the chain, it could be exploited by criminals, damaging the reputation of individuals or institutions. To address these challenges, consortium chain technology is currently developing towards more flexible data management. Currently, some new research is exploring editable blockchain technology to enable dynamic management of on-chain data, adding a degree of flexibility without sacrificing security. While this technology is theoretically feasible, it still faces challenges in practice.

[0004] First, existing solutions face the challenge of inefficient consortium chain content editing on a single node. In today's rapidly evolving social landscape, consortium chain systems must not only ensure data security but also enable rapid review and modification of sensitive content when necessary. However, existing solutions are too slow to execute modification operations, failing to meet the high-performance response and processing requirements for consortium chains in this scenario.

[0005] Secondly, while existing solutions achieve a certain degree of decentralization, most rely on single-round voting mechanisms, which cannot guarantee data consistency across nodes in Byzantine environments. While consortium chains have certain access mechanisms, they still cannot completely prevent malicious nodes from sabotaging the system. This limitation poses a significant challenge to the security of consortium chain systems. Therefore, ensuring that all honest nodes can correctly execute modification requests is crucial to maintain the overall security of the system. These challenges have, to a certain extent, constrained the further development and wider application of consortium chain technology. Summary of the Invention

[0006] The purpose of this invention is to design a consortium chain data editing method suitable for Byzantine fault tolerance to improve the efficiency of on-chain data modification. This method combines chameleon hashing technology with block replacement optimization strategies to not only speed up data modification but also improve the efficiency of on-chain updates. In addition, the designed request consensus protocol ensures that all honest nodes can perform the same block editing operations in a Byzantine environment through multiple rounds of voting and edit verification mechanisms, thereby ensuring data consistency. It also introduces parallel consensus and batch request processing strategies, significantly enhancing the stability and efficiency of the system. Through this invention, the performance of on-chain data editing can be significantly optimized while ensuring system security, and it provides a new solution and effective technical support for sensitive information processing and public opinion supervision in consortium chain environments.

[0007] The specific technical solution for achieving the purpose of the present invention is:

[0008] A Byzantine fault-tolerant consortium chain data efficient editing method, including: a data editing protocol and a request consensus protocol; wherein,

[0009] The data editing protocol is that each node uses Chameleon hashing and optimizes the underlying block replacement strategy to achieve efficient modification of block content and rapid update of on-chain data;

[0010] The request consensus protocol is a consensus mechanism for block editing requests that is not affected by malicious nodes. Nodes use multiple rounds of voting and edit verification to ensure data consistency in a Byzantine environment. At the same time, it introduces an optimization strategy for multi-node concurrent consensus, significantly improving the response speed and throughput performance of the consortium chain system to modification requests.

[0011] The formation of the data editing agreement specifically includes:

[0012] Step A1: Apply the Chameleon hash function during the block generation process, input the public key PK, serialized block header information and auxiliary random parameter r to generate the block hash to ensure the feasibility of subsequent verification and modification of the block;

[0013] Step A2: When a transaction in a block needs to be modified, a new auxiliary random parameter r' is regenerated using Chameleon Hash to adapt to the change of the Merkle root and ensure that the updated block header has the same block hash value as the original block;

[0014] Step A3: Implement an efficient block replacement strategy to ensure the queryability of new blocks while maintaining the security of on-chain data;

[0015] The formation of the request consensus agreement specifically includes:

[0016] Step B1: Since there is no single master node in the system, trusted clients will concurrently submit structured requests to the consensus node network, which will be processed by a consensus node. Each request includes the height of the block to be modified, the transaction hash to be modified, and its digital signature.

[0017] Step B2: After verifying the validity of the request, the consensus node generates a proposal containing the block height and transaction hash to be modified and broadcasts it to other consensus nodes. The nodes then verify and categorize the proposal.

[0018] Step B3: Consensus nodes vote through a multi-round consensus mechanism using the PBFT algorithm. Voting information from each stage is encapsulated using a voting structure until consensus is reached. This ensures that all honest nodes correctly handle modification requests in a Byzantine environment.

[0019] Furthermore, the step A3 specifically includes:

[0020] Step A31: Append the modified new block to the end of the block storage file instead of replacing the physical location to avoid overwriting subsequent blocks and data pollution, thus maintaining the structural integrity and data security of the blockchain.

[0021] Step A32: The system maps the new block height to the new index and offset of the file by updating the hash table to achieve fast retrieval and maintain data integrity; this process includes serializing the new block to determine the new offset, writing the new block data to the file in sequence, and updating the hash table to ensure fast access to the block and data security.

[0022] Furthermore, the step B2 specifically includes:

[0023] Step B21: Each node pre-establishes a proposal pool locally to store all proposals received from the network;

[0024] Step B22: The system creates an independent voting set for each proposal to facilitate the management and classification of voting information at each stage;

[0025] Step B23: The node verifies the received proposals. Proposals that fail verification will be discarded. Proposals that pass verification will be classified into the corresponding proposal chain based on the identity information of the proposal initiator.

[0026] Furthermore, the node-local proposal pool is independently maintained by each consensus node and is used to store all proposals received from the network. The structure of the proposal pool includes multiple proposal chains, and each consensus node corresponds to a proposal chain. When a node receives a new proposal, it will classify the proposal according to the identity information of the proposal initiator and add it to the corresponding proposal chain. This structure enables each node to effectively manage the proposals it receives, facilitating subsequent consensus operations. At the same time, the node will also establish an independent voting set for each proposal, which will be classified and stored according to the consensus information contained in the vote.

[0027] Furthermore, the step B3 specifically includes:

[0028] Step B31: During the initialization phase, the master node constructs a request proposal containing the block height and transaction to be modified and broadcasts it to other consensus nodes.

[0029] Step B32: In the pre-voting phase, each consensus node verifies the proposal, constructs a voting message with its own signature, and broadcasts it. After collecting more than two-thirds of the votes in favor, it enters the pre-submission phase.

[0030] Step B33: In the pre-commit phase, the node broadcasts a pre-commit support vote with its own signature. If more than two-thirds of the support votes are collected, the proposal is considered to have reached consensus in the network and is ready to enter the submission phase.

[0031] Step B34: In the commit phase, the node records the pre-written log, retrieves the block height and transaction information in the request, obtains and verifies the target block; after successful confirmation, the node generates a new edited block and replaces the old block, thereby updating the blockchain data;

[0032] Step B35: After completing the block modification, the node constructs a receipt and sends it to the client, confirming that the modification operation of the block on the chain has been completed and ensuring the availability and consistency of the data.

[0033] The beneficial effects of the present invention include:

[0034] The present invention aims to address the efficiency and security issues of on-chain data editing in consortium chain systems, focusing on developing an efficient data editing method for consortium chains. Its purpose is to enable on-chain data editing operations to improve system response speed and the efficiency of processing editing requests while ensuring system security. Specifically, the present invention uses chameleon hashing to implement block content editing and optimizes the underlying block replacement strategy, aiming to address the low efficiency of existing methods when processing single block modifications. At the same time, to ensure data consistency between nodes, the present invention designs a Byzantine fault-tolerant consensus mechanism for block editing requests, which ensures that all honest nodes have performed the same editing operation through multiple rounds of voting and edit verification. Building on this consensus mechanism, the present invention further introduces an optimization strategy for multi-node concurrent consensus, significantly improving system throughput performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a flow chart of the overall architecture of the present invention;

[0036] Figure 2 It is a schematic diagram of the execution sequence of the local proposal proposed by the present invention;

[0037] Figure 3 This is a schematic diagram of the Chameleon Hash Modification Block proposed by the present invention;

[0038] Figure 4 This is a performance comparison chart of the present invention and the other two strategies. DETAILED DESCRIPTION

[0039] The present invention is further described in detail with reference to the following specific examples and accompanying drawings. The processes, conditions, experimental methods, etc. for implementing the present invention, except for those specifically mentioned below, are common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0040] This paper discloses an efficient Byzantine fault-tolerant consortium blockchain data editing method, designed to improve the efficiency and consistency of on-chain data processing. This method's protocol architecture comprises two core protocols: the first, a data editing protocol, which utilizes chameleon hashing technology and an optimized underlying block replacement strategy to enable efficient modification and rapid updates of on-chain data, addressing the demands of real-time data processing. Existing solutions, by contrast, execute modification operations too slowly, failing to meet the high-performance response and processing requirements of consortium chains for large-scale modifications to blockchain data.

[0041] Secondly, the request consensus protocol designs a consensus mechanism that is immune to malicious nodes. Through multiple rounds of voting and a rigorous edit verification process, it ensures that all honest nodes consistently execute the same block edit operation, thus safeguarding data integrity and consistency in complex Byzantine environments. Furthermore, this invention introduces a concurrent consensus mechanism. These optimizations enable the concurrent processing of multiple edit requests, significantly improving the system's processing speed and overall throughput. Through this comprehensive protocol system, the present invention significantly improves the performance, reliability, and responsiveness of consortium blockchain systems under high-pressure environments. In contrast, existing solutions achieve a certain degree of decentralization, but most rely on a single-round voting mechanism and cannot guarantee data consistency between nodes in Byzantine environments. While consortium blockchains have certain access mechanisms, they cannot completely prevent malicious nodes from sabotaging the system, a limitation that poses a significant challenge to ensuring the security of consortium blockchain systems.

[0042] Figure 1 This figure shows the overall architecture flow chart of the proposed Byzantine fault-tolerant consortium blockchain method for efficient data editing, depicting the construction, broadcast, and processing of modification requests within the system. Steps 1 and 2 represent the steps involved in the request consensus protocol, while step 3 represents the steps involved in the data editing protocol.

[0043] The specific modification process is as follows: Figure 1 As shown in step 1, the client sends a modification request containing the block height and transaction hash to be modified, along with a trusted signature, to a consensus node. After receiving the modification request from the client, the responsible node constructs a "request block" and the corresponding modification proposal and broadcasts it to the entire network. To efficiently manage these proposals, each node establishes a local proposal pool, which stores all proposals received from the network and maintains a separate proposal chain for each consensus node. When a node receives a proposal from the network, it categorizes it and assigns it to the corresponding chain based on its source and content. Furthermore, the system establishes a separate voting set for each proposal, which categorizes and stores votes based on the consensus information it contains. When the number of votes in any voting set reaches or exceeds a majority, the system enters the next consensus phase.

[0044] Figure 1 As shown in step ②, each node performs parallel consensus processing on the received proposals. The consensus process algorithm is shown in Algorithm 1 below:

[0045] During the initialization phase, the master node constructs a request proposal containing the block height and transactions to be modified and broadcasts it to other consensus nodes (Algorithm 1, lines 1-9).

[0046] In the pre-voting phase, after each consensus node verifies the proposal, it constructs and broadcasts voting information with its own signature. After collecting more than two-thirds of the support votes, it enters the pre-commitment phase (Algorithm 1, lines 11-21).

[0047] In the pre-commit phase, a node broadcasts a pre-commit support vote with its own signature. If more than two-thirds of the votes are in favor, the proposal is considered to have reached consensus in the network and is ready to enter the commit phase (Algorithm 1, lines 23-33).

[0048] During the commit phase, the node records the pre-write log, retrieves the block height and transaction hash in the request, obtains and verifies the target block. After successful confirmation, the node generates a new edited block and replaces the old block, thus updating the blockchain data. (Algorithm 1, lines 35-40)

[0049]

[0050] like Figure 1 As shown in step 3, different nodes may receive modification proposals in different orders and modify the block locally. Therefore, at some point, data between nodes may become inconsistent. However, once all modification requests pass consensus, all nodes will eventually reach a consensus, ensuring data consistency and integrity.

[0051] The specific block replacement process is shown in Algorithm 2. In this system, a mapping table from block height to file index and offset is maintained to facilitate fast retrieval based on block height. When querying a block, the index and offset are first obtained based on the height, and then the file data is read and deserialized into a block structure. When performing a block replacement operation, the system first serializes the new block to determine the offset of the new block (Algorithm 2, lines 1-2). After that, the system writes the new block data to the file in sequence to obtain the exact location of the new block on the storage file. After completing this process, the system immediately updates the hash table, using the corresponding block height as an index and mapping it to the offset of the new block (Algorithm 2, lines 3-7).

[0052] The entire process fully utilizes the network bandwidth of each node, and improves the system's processing speed and efficiency for block modification requests while ensuring the security of the alliance chain system.

[0053]

[0054] Figure 2This demonstrates the order in which modification requests are processed. In a blockchain, block generation, consensus verification, and storage must be performed strictly in block height order to maintain sequential consistency and data integrity across nodes. Violations of this order can lead to inconsistent states across nodes. However, processing block modification requests does not require strict ordering; eventual consistency is only required.

[0055] Four modification proposals are broadcast simultaneously across the network. Each node receives these proposals based on network conditions. Due to factors such as network latency, different nodes may receive these modification proposals in different orders. For example, if proposals 1-4 are being broadcast across the network, at time T0, node 0 receives proposal 1 and locally modifies block 0, while node 1 receives proposal 3 and modifies block 1. At time T1, node 0 receives proposal 4 and locally modifies block 2, while node 1 receives proposal 2 and modifies block 3, and so on. The final results show that despite the different reception orders, after consensus on all proposals is reached, each node will perform the same modification and replacement operations. This mechanism ensures that all nodes ultimately achieve data consistency.

[0056] Figure 3 Shows the block content editing technology. Figure 3 As shown in (a), each block consists of a block header and a block body. The block body contains transaction data and read / write sets. The data integrity of the block is verified by the Merkle tree root hash in the block header. In addition, the block header also includes the hash value of the previous block to ensure the link between blocks. During the block generation process, the chameleon hash function is required to generate the hash value. This requires the input of the public key PK, the identity tag L, the serialized block header information m, and the auxiliary random parameter r to generate the hash value h, that is:

[0057] Hash: (PK,L,m,r) → h

[0058] Figure 3 (b) shows how to modify the contents of a block. When a transaction within a block is modified, the Merkle root changes. The modifier then uses a variable parameter forging function to generate a new auxiliary random parameter r′. The newly generated r′ ensures that the updated block header has the same block hash as the original block, namely:

[0059] Hash(PK,L,m,r) = Hash(PK,L,m',r')

[0060] This maintains the integrity of the chain structure and enables modifications at the transaction granularity level.

[0061] Figure 4The performance of the proposed Byzantine fault-tolerant consortium chain data efficient editing method is compared with two other consensus strategies, namely the single-node parallel block modification strategy and the single-node serial block modification strategy, and the tests are carried out in multiple 4, 7, 10, and 13 node environments respectively. The experimental results are as follows: Figure 4 As shown in the figure, as the number of transactions in the block increases, the number of transactions that can be processed per unit time under the three strategies shows an increasing trend, and the differences between the strategies become more and more obvious. As the number of consensus nodes in the system increases, the communication overhead continues to increase, and the performance of all strategies has declined significantly. When the block size is set to 500 transactions per block and the number of nodes is only 4, it is observed that the method proposed in the present invention can process up to 3714 requests per second, which significantly surpasses the other two strategies. Even when the number of nodes increases to 13, the method proposed in the present invention can still process 1370 requests per second. This data effectively proves that the concurrent consensus strategy proposed in the present invention has a significant effect in improving the overall throughput performance of the system.

[0062] The protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the appended claims.

Claims

1. A Byzantine fault-tolerant consortium chain data efficient editing method, characterized by: include: Data editing protocol and request consensus protocol; among them, The data editing protocol is that each node uses Chameleon hashing and optimizes the underlying block replacement strategy to achieve efficient modification of block content and rapid update of on-chain data; The request consensus protocol is a consensus mechanism for block edit requests that is not affected by malicious nodes. Nodes use multiple rounds of voting and edit verification to ensure data consistency in a Byzantine environment. It also introduces an optimization strategy for multi-node concurrent consensus, significantly improving the consortium chain system's response speed and throughput performance to modification requests. The formation of the data editing agreement specifically includes: Step A1: Apply the Chameleon hash function during the block generation process, input the public key PK, serialized block header information and auxiliary random parameter r to generate the block hash to ensure the feasibility of subsequent verification and modification of the block; Step A2: When a transaction in a block needs to be modified, a new auxiliary random parameter r' is regenerated using Chameleon Hash to adapt to the change of the Merkle root and ensure that the updated block header has the same block hash value as the original block; Step A3: Implement an efficient block replacement strategy to ensure the queryability of new blocks while maintaining the security of on-chain data; The formation of the request consensus protocol includes the following steps: Step B1: Since there is no single master node in the system, trusted clients will concurrently submit structured requests to the consensus node network, which will be processed by a consensus node. Each request includes the height of the block to be modified, the transaction hash to be modified, and its digital signature. Step B2: After verifying the validity of the request, the consensus node generates a proposal containing the block height and transaction hash to be modified and broadcasts it to other consensus nodes. The nodes then verify and categorize the proposal. Step B3: Consensus nodes vote through a multi-round consensus mechanism using the PBFT algorithm. Voting information from each stage is encapsulated using a voting structure until consensus is reached. This ensures that all honest nodes correctly handle modification requests in a Byzantine environment.

2. The Byzantine fault-tolerant consortium chain data efficient editing method according to claim 1 is characterized in that: The step A3 specifically includes: Step A31: Append the modified new block to the end of the block storage file instead of replacing the physical location to avoid overwriting subsequent blocks and data pollution, thus maintaining the structural integrity and data security of the blockchain. Step A32: The system maps the new block height to the new index and offset of the file by updating the hash table to achieve fast retrieval and maintain data integrity; this process includes serializing the new block to determine the new offset, writing the new block data to the file in sequence, and updating the hash table to ensure fast access to the block and data security.

3. The Byzantine fault-tolerant consortium chain data efficient editing method according to claim 1 is characterized in that: The step B2 specifically includes: Step B21: Each node pre-establishes a proposal pool locally to store all proposals received from the network; Step B22: The system creates an independent voting set for each proposal to facilitate the management and classification of voting information at each stage; Step B23: The node verifies the received proposals. Proposals that fail verification will be discarded. Proposals that pass verification will be classified into the corresponding proposal chain based on the identity information of the proposal initiator.

4. The Byzantine fault-tolerant consortium chain data efficient editing method according to claim 3 is characterized in that: The node-local proposal pool is independently maintained by each consensus node and is used to store all proposals received from the network. The proposal pool structure includes multiple proposal chains, one for each consensus node. When a node receives a new proposal, it will classify the proposal according to the identity information of the proposal initiator and add it to the corresponding proposal chain. This structure enables each node to effectively manage the proposals it receives, facilitating subsequent consensus operations. At the same time, the node will also establish an independent voting set for each proposal, which will be classified and stored according to the consensus information contained in the vote.

5. The Byzantine fault-tolerant consortium chain data efficient editing method according to claim 1 is characterized in that: The step B3 specifically includes: Step B31: During the initialization phase, the master node constructs a request proposal containing the block height and transaction to be modified and broadcasts it to other consensus nodes. Step B32: In the pre-voting phase, each consensus node verifies the proposal, constructs a voting message with its own signature, and broadcasts it. After collecting more than two-thirds of the votes in favor, it enters the pre-submission phase. Step B33: In the pre-commit phase, the node broadcasts a pre-commit support vote with its own signature. If more than two-thirds of the support votes are collected, the proposal is considered to have reached consensus in the network and is ready to enter the submission phase. Step B34: In the commit phase, the node records the pre-written log, retrieves the block height and transaction information in the request, obtains and verifies the target block; after successful confirmation, the node generates a new edited block and replaces the old block, thereby updating the blockchain data; Step B35: After completing the block modification, the node constructs a receipt and sends it to the client, confirming that the modification operation of the block on the chain has been completed and ensuring the availability and consistency of the data.

Images