Distributed data consistency management system and method based on block chain

Abstract

The invention discloses a distributed data consistency management system and method based on a block chain, and relates to the field of block chain distributed data management, the system comprises a client layer, a block chain layer and a storage layer, the client layer comprises a user interface and a data request, the user interface is used for a user and an application to submit a data read-write request, and the block chain layer is used for storing the data request; the data request is used for formatting the request and signing. The data states of all nodes are ensured to be consistent through a block chain consensus mechanism, an intelligent contract automatically executes a consistency rule, human errors are reduced, content addressing ensures that stored data cannot be tampered, a decentralized architecture has no single-point fault, data multi-copy storage improves the fault-tolerant capability, the block chain cannot be tampered, and the data credibility is enhanced. The interstellar file system stores large files, reduces block chain storage pressure, a database efficiently manages metadata and supports complex query, local cache improves hotspot data access speed, and digital signature ensures identity authentication and non-repudiation.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain distributed data management, and specifically to a distributed data consistency management system and method based on blockchain. Background Art

[0002] The distributed data of blockchain is a way to store and manage data using blockchain technology. The distributed data storage of blockchain disperses data storage across multiple nodes, which can be different computers or servers connected to each other through a network. A consistency management system is a software system or mechanism used to ensure that data in a distributed system remains in a consistent state among multiple nodes.

[0003] For example, in the "Access Control Method and System Based on Blockchain Technology" with the publication number CN108123936B, this method combines blockchain technology with attribute-based access control, including: entering object attributes into the blockchain, and binding the determination process of attributes and policies to all blockchain nodes based on policies. It changes access authorization from centralized to distributed, and uses the consensus mechanism of blockchain to achieve consistency verification of the determination results across the network, and permanently records the authorized operations of access record transactions on the blockchain.

[0004] However, traditional centralized systems still have significant drawbacks: 1. Lack of consistency guarantee mechanism: relying on single-point control by a central authority, manual execution of rules is vulnerable to subjective errors or malicious operations, and lacks automated verification capabilities; 2. Risk of data reliability: Administrators can modify or delete data at will, without a content-addressing verification mechanism, and users can only passively trust centralized storage; 3. Insufficient architecture security: The centralized architecture has a single-point failure risk. The collapse of the central server or hardware failure may cause permanent loss of data, and historical records can be tampered with. The credibility depends on third-party audits. Summary of the Invention

[0005] The purpose of the present invention is to provide a distributed data consistency management system and method based on blockchain to solve the problems proposed in the above background art, that is, in a centralized system, there is no need for nodes to reach a consensus, data consistency completely depends on the unilateral control of a central authority, rules are manually executed, the process is vulnerable to subjective errors or malicious operations, lacks automated guarantee, the stored data can be modified or deleted at will by the administrator, there is no content-addressing verification mechanism, users can only passively trust the reliability of centralized storage, and the system adopts a centralized architecture with a single-point failure risk.

[0006] To achieve the above object, the present invention provides the following technical solutions: A distributed data consistency management system based on blockchain, specifically as follows: The system consists of a client layer, a blockchain layer, a storage layer and an external interface: 1. Client layer: It includes a user interface and a data request module. The user interface supports the submission of data read and write requests, and the data request module is responsible for formatting requests, digital signature and transmitting data to the blockchain layer.

[0007] 2. Blockchain layer: (1) Smart contract: Self-executing code deployed on the blockchain, presetting data consistency rules, automatically verifying data accuracy and handling conflicts to ensure consistent outputs for the same inputs; (2) Consensus mechanism: Integrating algorithms such as Proof of Work (PoW), Proof of Stake (PoS), Practical Byzantine Fault Tolerance (PBFT), etc., generating and verifying candidate blocks through distributed voting, and being chained after more than half of the nodes reach a consensus; (3) Peer-to-peer network nodes: Building a decentralized communication network based on the Kademlia Distributed Hash Table (DHT), maintaining the node topology, and achieving efficient broadcasting of transactions and blocks.

[0008] 3. Storage layer: (1) InterPlanetary File System (IPFS): Adopting content-addressing technology, storing files in chunks and generating unique hash values, retrieving block positions through DHT, and supporting decentralized storage and parallel transmission of large files; )) Off-chain database: Managing metadata (such as file hashes, file names, user permissions), and optimizing the access efficiency of hot data in combination with local caching.

[0009] 4. External interface: Obtaining external data sources through an oracle and an Application Programming Interface (API), verifying them and providing them to the smart contract to achieve data interaction inside and outside the chain.

[0010] Preferably, the process of the distributed data consistency management system is specifically the following steps: S1. Client node: Sending a data read and write request from the user interface of the client to the blockchain layer through a data request; S2. Signed transaction: Using a private key to digitally sign the request for data authentication; S3. Peer node 1 / Peer node 2: The peer-to-peer network nodes broadcast transactions / blocks through the distributed coordinator protocol, and at the same time maintain the network topology using the Kademlia distributed hash table; S4. Complete network: The consensus mechanism uses Proof of Work / Proof of Stake / Practical Byzantine Fault Tolerance to package transactions to generate candidate blocks, and other nodes verify the validity of the candidate blocks, and upload them to the blockchain after more than half of the nodes agree. S5. The smart contract checks the data format and signature validity, then calculates the winner based on the timestamp and executes the contract logic to update the on-chain status.

[0011] Preferably, in step S3, Kademlia is an implementation protocol of a distributed hash table for decentralized peer-to-peer network nodes. It organizes the nodes in the network into a structured overlay network through the binary encoding of the node ID and the data key.

[0012] Preferably, in step S4, proof of work finds a random number that meets the conditions through brute force calculation, making the block hash value less than the target difficulty. Proof of stake selects validators through a pseudo-random algorithm. Practical Byzantine Fault Tolerance is used to maintain the consistency and normal operation of a distributed system in the presence of faulty and malicious nodes. Proof of work + proof of stake votes to reject bad blocks.

[0013] Preferably, the smart contract is a self-executing protocol, which is code deployed on the blockchain. It automatically executes operations when the preset conditions are met without the intervention of a third party. The same input always produces the same output, and the execution results of all nodes are consistent. It automatically executes corresponding operations based on predefined rules and conditions. When specific trigger conditions are met, the smart contract will automatically execute the pre-written code logic without manual intervention.

[0014] Preferably, the peer-to-peer network node is a decentralized network architecture. The nodes refer to each device participating in the network. Each node can act as a client to request resources and also as a server to provide resources and services for other nodes. The node shares its own resources, such as files, data, computing power, storage capacity, etc., with other nodes. When a node requests to obtain a certain resource, it will establish a connection with the node that has the resource and transmit data through the peer-to-peer network protocol. Each node maintains certain network topology information and helps other nodes find the node where the target resource is located through a distributed routing algorithm.

[0015] Preferably, the InterPlanetary File System (IPFS) uses content addressing instead of location addressing. It decomposes the file into smaller chunks and generates a hash value for each chunk. The IPFS nodes store the file chunks locally and use a distributed hash table to store and retrieve the location information of these chunks. When a user needs to retrieve a file, the IPFS sends requests to the nodes in the network and downloads the file chunks from multiple nodes.

[0016] Preferably, the InterPlanetary File System (IPFS) uses content addressing instead of location addressing. It decomposes files into smaller chunks, generates hash values for each chunk, stores the file chunks locally by IPFS nodes, and stores and retrieves the location information of these chunks through a distributed hash table. When a user needs to retrieve a file, IPFS sends requests to nodes in the network and downloads file chunks from multiple nodes.

[0017] 8. A distributed data consistency management system based on blockchain according to claim 1, characterized in that: the off-chain database refers to a database running outside the blockchain network, providing data support for smart contracts and applications on the blockchain; An application programming interface is a set of definitions, protocols, and tools for enabling interaction and communication between different software applications. External data is obtained through software programs and interfaces, and data is obtained from data sources on the Internet by calling various API interfaces. An oracle is a mechanism or service that can provide external data and information for blockchain smart contracts.

[0018] A management method for distributed data consistency based on blockchain includes the following steps: [[ID=eleven]] H1. Consistency model selection: Select a consistency model according to business requirements; H2. Core algorithms: Paxos: A classic distributed consensus algorithm suitable for CP systems; Raft: A more understandable consensus algorithm widely used in systems such as etcd; Atomic broadcast: The atomic broadcast protocol of a distributed coordinator; H3. Data replication: Copy data to nodes close to users (edge computing). Read requests can be distributed to multiple replicas to relieve the pressure on the main node, and different replicas can serve different requests simultaneously; H4. Conflict resolution: Used to handle the situation where modifications occur on multiple nodes, ensuring that the system finally reaches a consistent state.

[0019] Preferably, in step H4, conflict resolution includes the following methods: Q1: Each data modification is attached with a timestamp. When a conflict occurs, the system selects the latest write as the final value and discards the old value; Q2: Let the client decide how to resolve the conflict; Q3: Each replica maintains a version vector to record the modification order of different nodes. By comparing the version vectors, it is judged whether the operations are concurrent or have a causal relationship; Q4: When multiple people edit a document or collaborate on code simultaneously, convert the conflicting operations so that they can be correctly merged.

[0020] Compared with the prior art, the beneficial effects of the present invention are: 1. In the present invention, the blockchain consensus mechanism is used to ensure the consistency of data status among all nodes. The smart contract automatically executes the consistency rules, reducing human errors. Content addressing (InterPlanetary File System) ensures the immutability of stored data. The decentralized architecture has no single point of failure. Storing data in multiple copies improves fault tolerance. The immutable property of the blockchain enhances the credibility of data. The InterPlanetary File System stores large files, reducing the storage pressure on the blockchain. The database efficiently manages metadata and supports complex queries. The local cache improves the access speed of hot data. Digital signatures ensure identity authentication and non-repudiation. Blockchain encryption guarantees the security of data transmission. Permission management by smart contracts controls data access.

[0021] 2. In the present invention, the digital signature mechanism: ensures identity authentication and non-repudiation of data requests through private key signatures, preventing forged requests. Mixing Proof of Work / Proof of Stake / Practical Byzantine Fault Tolerance provides multi-level security protection. The Proof of Work + Proof of Stake voting mechanism can effectively identify and veto bad blocks. All nodes in the network jointly verify transactions and blocks, eliminating the single point of trust risk. The coded rules ensure the transparency and immutability of the execution process. Using the Kademlia distributed hash table enables efficient node discovery and routing. Combining the advantages of Proof of Work / Proof of Stake / Practical Byzantine Fault Tolerance balances the security and performance requirements. The peer-to-peer network architecture supports multi-node parallel verification and data processing. The peer-to-peer network architecture has no single point of failure, and nodes can freely join and leave.

[0022] 3. In the present invention, the content identifier generated from the file content ensures the uniqueness of data. The same content always generates the same hash, and the same content is stored only once, significantly saving storage space. When the content changes, a new content identifier is automatically generated. After the file is divided into blocks, it can be obtained simultaneously from multiple nodes, improving the transmission speed. The DHT network automatically discovers the nearest resource nodes, reducing network latency. Accessed content is cached on the local node, accelerating subsequent accesses. The file blocks are distributed and stored on multiple nodes in the network. A single point of failure does not affect data availability. The data availability is regularly verified through the DHT, and lost data blocks are automatically reconstructed. There is no centralized storage point, making it difficult to be reviewed or deleted by a single entity. Large files are stored in the InterPlanetary File System, and the blockchain only stores the content identifier metadata. By comparing the content identifiers, it can be verified whether the content in the InterPlanetary File System has been tampered with. Compared with uploading all data to the blockchain, the cost is significantly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic structural diagram of a blockchain-based distributed data consistency management system of the present invention; Figure 2 It is a schematic diagram of the process of a blockchain-based distributed data consistency management system of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0024] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without making creative efforts shall fall within the protection scope of the present invention.

[0025] Embodiment 1: Refer to Figure 1 and Figure 2 As shown, the usage process of the solution of the present application is carried out around the collaborative work of the client layer, the blockchain layer, and the storage layer, covering core links such as the initiation, processing, storage, and conflict resolution of data read and write requests. The specific process is as follows: I. Client layer: Initiation of data read and write requests 1. The user submits data read and write requests (such as uploading files, querying data, etc.) through the user interface of the client layer. The request types cover data writing (such as storing large files, updating metadata) and data reading (such as obtaining file content, querying permission information).

[0026] 2. Formatting and signing of requests The data request module formats the original request and converts it into structured data (such as JSON format) that conforms to the blockchain interaction specification.

[0027] The request is digitally signed using the user's private key to ensure the identity authentication of the request (verifying the identity of the sender) and non-repudiation (preventing the request from being tampered with or forged).

[0028] The signed request is sent to the peer network nodes at the blockchain layer.

[0029] II. Blockchain layer: Consensus processing and rule execution (1) Peer-to-peer network communication and transaction broadcasting Decentralized network architecture: Based on the Kademlia distributed hash table (DHT), the network topology is maintained. Each node forms a structured overlay network through the binary encoding of the node ID and the data key, realizing efficient node discovery and routing.

[0030] Transaction / block broadcasting: Peer network nodes broadcast the signed transaction to all nodes in the network through the distributed coordinator protocol. Write requests need to be broadcast to all nodes participating in the consensus, and read requests can be quickly responded to according to the metadata cache (if the local cache misses, a full network query is triggered).

[0031] (2) Consensus mechanism to generate and verify candidate blocks 1. Packing transactions and generating candidate blocks Consensus nodes (e.g., using the Proof of Work (PoW), Proof of Stake (PoS), or Practical Byzantine Fault Tolerance (PBFT) algorithms) collect transactions to be processed and package them into candidate blocks in chronological order.

[0032] PoW: Find a random number (Nonce) that satisfies the hash value being less than the target difficulty through brute-force calculation to ensure the proof of work for block generation.

[0033] PoS: Select validators through a pseudo-random algorithm based on the stake held by nodes (e.g., the number of tokens), reducing the computing power consumption.

[0034] PBFT: In scenarios with faulty or malicious nodes, reach a consensus through three phases: pre-prepare, prepare, and commit, ensuring fault tolerance (allowing a maximum of f malicious nodes, requiring the support of 2f + 1 honest nodes).

[0035] 1. Block Verification and Consensus Reaching Other nodes verify the validity of the candidate block (e.g., the legality of transaction signatures, the compliance of smart contract logic).

[0036] After more than half of the nodes (e.g., the proof of work weight in PoW, the stake weight in PoS, the quorum in PBFT) agree, the candidate block is uploaded to the blockchain, forming an immutable historical record.

[0037] (3) Smart Contract Execution Consistency Rules Automatic Verification and Conflict Resolution: Smart contracts deployed on the blockchain receive transactions that have passed verification and execute data consistency rules: a. Format and Signature Verification: Check whether the data format conforms to the preset standard (e.g., JSONSchema), and verify the digital signature to confirm user permissions (e.g., whether there is permission to modify a certain file).

[0038] b. Timestamp and Version Control: Judge data conflicts based on the transaction timestamp or version vector (e.g., Q3 in step H4), and select the latest write or resolve conflicts according to the preset strategy (e.g., determined by the client, business rules take precedence).

[0039] c. State Update: Update the on-chain state according to the contract logic (e.g., record the file hash value, user permission changes, etc.), ensuring that the execution results of all nodes are consistent (the same input produces the same output).

[0040] III. Storage Hierarchy: Data Storage and Efficient Access (1) InterPlanetary File System (IPFS) Stores Data Content Addressing and Chunked Storage: For large files (such as videos and documents), the smart contract triggers the IPFS node to decompose the file into small data blocks, generates a unique content identifier (hash value) for each block, and ensures data uniqueness and immutability by addressing through content rather than location.

[0041] The IPFS node stores and retrieves the block location information through the DHT. When the user retrieves the file, the file blocks are downloaded in parallel from multiple nodes to improve the transmission speed.

[0042] Decentralized storage and redundant backup: The file blocks are scattered and stored in multiple nodes in the network. A single point of failure does not affect data availability; the DHT periodically verifies data availability and automatically reconstructs the lost blocks.

[0043] Files with the same content are stored only once, saving storage space (for example, duplicate files are referenced by the same hash value).

[0044] (2) Off-chain database manages metadata Metadata storage: The database (such as relational databases, NoSQL) stores metadata such as file hash values, file names, user permissions, and storage locations (IPFS hashes), supporting complex queries (such as searching by file name and filtering by permissions).

[0045] Local cache optimization: Cache hot data that is frequently accessed (such as metadata and content blocks of commonly used files), reducing repeated on-chain queries and improving response speed.

[0046] (3) Specific processes for data reading and writing Writing process: d. The user submits a write request, and the client formats and signs it and then broadcasts it to the peer network.

[0047] e. The smart contract verifies the legitimacy of the request (permissions, format), uploads the large file to IPFS, and returns the content hash.

[0048] f. The metadata (including the IPFS hash) is packaged with the transaction, written to the blockchain after being confirmed by the consensus mechanism, and the off-chain database is updated.

[0049] Reading process: g. The user submits a read request, and the system first checks the local cache. If a hit occurs, the data is directly returned.

[0050] h. When there is a miss, the blockchain is queried to obtain the metadata (such as the IPFS hash), the file blocks are downloaded from multiple nodes through IPFS, the hash value is verified to ensure data integrity, and the data is returned and the cache is updated.

[0051] IV. External data acquisition: Oracle and API integration External data access: Obtain off-chain data (such as real-time weather, market prices, etc.) through oracles and application programming interfaces (APIs): i. The oracle obtains data from external data sources (such as web services, sensors) through APIs, performs format conversion and authenticity verification.

[0052] ii. The verified data is provided to the smart contract as a trigger condition (for example, automatically execute the contract logic when specific weather conditions are met).

[0053] Off-chain database interaction: The off-chain database stores non-critical or frequently updated data (such as user details). The smart contract queries the database through APIs to avoid the storage pressure of the blockchain and improve data read and write efficiency.

[0054] V. Conflict resolution: Ensure eventual data consistency When multiple nodes concurrently modify data, the smart contract resolves conflicts according to the preset strategy: 1. Timestamp priority (Q1): Select the latest written version as the final value and discard the old value (applicable to log data).

[0055] 2. Client decision (Q2): Return the conflicting data to the client, and the user manually selects the version to retain (applicable to collaborative editing scenarios).

[0056] 3. Version vector (Q3): Each replica maintains a version vector to record the modification order of each node. By comparing the vectors, it is determined whether the operations are concurrent or have a causal relationship, and valid modifications are merged.

[0057] 4. Operation transformation (Q4): For example, when multiple people collaborate to edit a document, transform conflicting operations (such as insertions, deletions) into a mergeable form to ensure the final state is consistent.

[0058] Embodiment of the core advantages of this application in the process: 1. Decentralization and fault tolerance: The peer-to-peer network and multi-copy storage (IPFS) eliminate single points of failure, and Kademlia DHT ensures efficient node discovery.

[0059] 2. Immutability and security: Blockchain consensus (PoW / PoS / PBFT) ensures that transaction records cannot be tampered with, and digital signatures and smart contract rules prevent malicious operations.

[0060] 3. Efficiency and cost optimization: IPFS block storage and local caching accelerate data access, and the off-chain database reduces the storage pressure of the blockchain and lowers the cost of going on-chain.

[0061] 4. Automation and transparency: Smart contracts automatically execute consistency rules, and all network nodes jointly verify, making the process transparent and traceable.

[0062] Through the above process, the system realizes the full - link distributed management from data request initiation, consensus processing, storage to conflict resolution, ensuring the consistency, security and efficiency of data under the decentralized architecture.

[0063] Example 2: According to Figure 1 and Figure 2 As shown, this embodiment focuses on the core processing flow of the system, presenting the execution logic of the technical solution completely from the client's request initiation to the blockchain layer's consensus achievement, smart contract execution and data status update.

[0064] The system realizes data consistency management through five core steps: client request initiation → transaction signature and broadcast → consensus mechanism to generate candidate blocks → network - wide verification and block on - chain → smart contract execution rules and status update. Each link is closely connected, combined with the decentralized network architecture and cryptographic algorithms, to ensure the reliable synchronization of data among distributed nodes.

[0065] Specific step analysis: S1. Client node: Initiate data read - write requests (1) User interaction: Users or applications submit data read - write requests (such as file upload, data query, etc.) through the user interface of the client layer. The request types cover data writing (requiring consensus verification) and reading (which can rely on caching for quick response).

[0066] (2) Request encapsulation: The data request module of the client formats the original request into a standard data structure (such as a JSON object containing operation type, data content, target address), preparing for subsequent blockchain interactions.

[0067] S2. Signed transaction: Identity authentication and request confirmation (1) Digital signature mechanism: The data request module uses the user's private key to digitally sign the formatted request, generating a unique signature value and attaching it to the request.

[0068] (2) Core functions: Verify the authenticity of the request sender's identity (prevent forgery), ensure that the request content cannot be tampered with (the signature is bound to the content), and achieve non - repudiation (the sender cannot deny the request).

[0069] (3) Request forwarding: The signed request is sent to the peer - to - peer network nodes of the blockchain layer through a secure channel, entering the distributed communication link.

[0070] S3. Peer node: Decentralized communication and network topology maintenance (1) Distributed network architecture: Peer-to-peer nodes build a structured overlay network based on the Kademlia Distributed Hash Table (DHT), organize node relationships through the binary encoding of node IDs and data keys (such as SHA-256 hash values), and achieve efficient resource location and routing.

[0071] Each node has both client and server functions, can initiate requests or provide data services, and maintains local network topology information (such as a list of adjacent nodes) to accelerate routing.

[0072] (2) Transaction / block broadcasting: The peer node receiving the request broadcasts the transaction to all network nodes through a distributed coordinator protocol (such as the gossip protocol) to ensure that the write request is received by all consensus nodes.

[0073] During the broadcasting process, the Kademlia DHT dynamically optimizes the transmission path, reduces network latency, and improves the broadcasting efficiency.

[0074] S4. Complete network: The consensus mechanism generates and validates candidate blocks (1) Transaction packaging and candidate block generation: Consensus nodes (such as PoS validators and PBFT master nodes according to different algorithm roles) collect transactions within a certain period of time, package them into candidate blocks in chronological order, which contain information such as a list of transactions, the hash of the previous block, and a timestamp.

[0075] Algorithm details: Proof of Work (PoW): Nodes find a random number (Nonce) that meets the conditions through brute-force calculation, making the block hash value less than the target difficulty, consuming computing power to prove their own workload, and ensuring the fairness and security of block generation.

[0076] Proof of Stake (PoS): Select validators through a pseudo-random algorithm based on the stake held by nodes (such as the number of tokens), without high computing power consumption, reducing energy costs and improving efficiency.

[0077] Practical Byzantine Fault Tolerance (PBFT): Pre-prepare phase: The master node receives the client request, assigns a unique sequence number, and sends a pre-prepare message containing the request content, sequence number, and signature to all slave nodes.

[0078] Prepare phase: After verifying the message legitimacy, the slave nodes broadcast the prepare message to the whole network. When a node receives 2f + 1 valid prepare messages (f is the number of allowed malicious nodes), it enters the prepare state.

[0079] Commit phase: Nodes broadcast commit messages. After receiving 2f + 1 valid commit messages, the request is applied to the local state machine to ensure consensus is reached.

[0080] (2)Block Verification and Chain Insertion: All network nodes independently verify the validity of candidate blocks (such as whether transaction signatures are correct, whether smart contract logic complies with regulations, and whether PoW / PoS parameters meet the standards).

[0081] After more than half of the nodes (depending on the algorithm, such as the computing power ratio in PoW, the stake weight in PoS, and the legal number of nodes in PBFT) verify and pass, the candidate block is appended to the blockchain to form an immutable transaction record.

[0082] Rejection of Bad Blocks: Through the PoW+PoS voting mechanism, blocks containing malicious transactions or illegal operations are rejected across the network to ensure the legality of the data on the chain.

[0083] S5. Smart Contract: Automatically Execute Consistency Rules and State Updates (1)Contract Trigger Condition: When the candidate block is inserted into the chain, the smart contract deployed at the blockchain layer automatically obtains the transaction data in the block and triggers the preset logic.

[0084] (2)Execution Process: a. Data Verification: Check whether the data format complies with the specifications (such as fields and type constraints defined by JSONSchema).

[0085] Verify digital signatures and user permissions (such as whether the user has read and write permissions for the target data), and reject illegal requests.

[0086] b. Conflict Resolution: Based on the transaction timestamp or version vector (metadata recording the modification order of each node), determine whether there are concurrent modification conflicts.

[0087] Resolve conflicts according to the preset strategy (such as preferentially selecting the latest version based on the timestamp, manual adjudication by the client, operation transformation and merging, etc.) to ensure the ultimate consistency of the data.

[0088] c. State Update: Update the state on the chain according to the contract logic (such as recording the file hash value to the blockchain and updating the user permission mapping table).

[0089] Since the smart contract code is open-source and immutable, the execution results of the same input are consistent on all nodes, ensuring the synchronization of the distributed system state.

[0090] Kademlia DHT collaborates with peer network nodes to achieve efficient data transmission and node discovery without a central node, eliminating the risk of single-point failures. The PoW / PoS / PBFT algorithms are combined as needed to balance security, performance, and fault tolerance (e.g., PBFT is suitable for permissioned blockchains, while PoW / PoS are suitable for public blockchains). Smart contracts replace manual intervention and automatically handle data conflicts based on mechanisms such as timestamps and version control, reducing the impact of subjective errors and malicious operations.

[0091] In the second embodiment, through a standardized five-layer process, user requests are transformed into consistent operations in a distributed system. By combining cryptographic signatures, consensus algorithms, and smart contracts, the following are achieved: (1) Reliable identity authentication: Digital signatures ensure the credibility of the request source; (2) Flexible consensus mechanism: Supports multiple algorithms to adapt to different scenarios; (3) Automated data processing: Smart contracts drive rule execution, reducing labor costs; (4) Strong system fault tolerance: Algorithms such as PBFT allow the system to remain consistent even when some nodes fail or act maliciously.

[0092] This process is the core processing logic of the system. Subsequent data storage (such as the collaboration between IPFS and off-chain databases) and external data access (oracle + API) can be extended based on this process to form a complete distributed data consistency management system.

[0093] The working principle of this system: Users initiate data read / write requests through the data request at the user interface of the client layer. The data request formats the request and uses the private key for digital signature to ensure identity authentication, and then transmits the data to the blockchain layer.

[0094] At the blockchain layer, peer network nodes broadcast transactions or blocks through the distributed coordinator protocol. At the same time, they use the Kademlia distributed hash table (an implementation protocol of distributed hash table) to maintain the network topology, constructing the nodes in the network into a structured overlay network to achieve decentralized communication. In this network, each node has both the functions of a client and a server, can request resources, provide resources and services for other nodes, and maintains certain network topology information to assist routing.

[0095] After that, the consensus mechanism comes into play. It adopts the proof-of-work algorithm to find the Nonce value that meets the conditions through brute-force calculation, making the block hash value less than the target difficulty; the proof-of-stake algorithm, which selects validators with the help of a pseudo-random algorithm; and the practical Byzantine fault tolerance algorithm, which can maintain the consistency and normal operation of the system in the presence of faulty and malicious nodes. These algorithms are used to package transactions and generate candidate blocks. Other nodes will verify the validity of the candidate blocks. When more than half of the nodes approve, the block will be uploaded to the blockchain. Moreover, the proof-of-work and proof-of-stake algorithms can vote against bad blocks.

[0096] Immediately afterwards, the smart contract deployed on the blockchain starts to execute the logic. It checks the data format and the validity of the signature, calculates the winner based on the timestamp, and automatically executes corresponding operations when the preset conditions are met according to the predetermined rules and conditions, thereby updating the on-chain state. At the same time, it ensures that the same input always produces the same output, guaranteeing the consistency of the execution results of all nodes.

[0097] In terms of data storage, the storage layer adopts the InterPlanetary File System (IPFS) database. The InterPlanetary File System is a distributed file storage and sharing protocol based on content addressing. It splits files into smaller chunks and generates hash values for each chunk. Nodes store these file chunks locally and then store and retrieve the location information of the chunks through a distributed hash table, which is suitable for storing large files. The database is used to organize, store, and manage data, mainly managing metadata such as file hash values, file names, and user permission metadata. At the same time, the system caches hot data locally to achieve fast response.

[0098] In addition, the system can also obtain external data through the external system application programming interface / oracle. The application programming interface, as an interface between applications, enables the interaction and communication between different software applications. The oracle obtains data from external data sources through the application programming interface, and after verification, provides it to the smart contract, thus providing external data support for the blockchain smart contract and applications. Additionally, the off-chain database runs outside the blockchain network and can also provide data support for the smart contracts and applications on the blockchain.

[0099] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A distributed data consistency management system based on blockchain, characterized in that: It includes a client layer, a blockchain layer, and a storage layer; The client layer includes a user interface and a data request. The user interface is used for users and applications to submit data read and write requests. The data request is used to format the request and sign it, and at the same time send the data to the blockchain layer; The blockchain layer includes smart contracts, a consensus mechanism, and peer - to - peer network nodes. Smart contracts are used to execute data consistency rules, including verifying data accuracy and resolving conflicts. The consensus mechanism is used to achieve data state consistency through a consensus algorithm. Peer - to - peer network nodes are used for decentralized communication; The storage layer includes an IPFS database and an off - chain database. IPFS is a content - addressed distributed file storage and sharing protocol that realizes decentralized data storage and transmission through peer - to - peer network nodes. A database is a system for organizing, storing, and managing data, used for querying, updating, and managing data. When in use, IPFS stores data, and the database manages metadata. Large files are stored in IPFS, and the database stores the hash value of the file, the file name, and user permission metadata. The local cache responds to hot data. The distributed data consistency management system is also assisted with an external system application programming interface / oracle. The oracle obtains data from external data sources through the application programming interface and provides it to the smart contract after verification.

2. The distributed data consistency management system based on blockchain according to claim 1, characterized in that: The process of the distributed data consistency management system is specifically the following steps: S1. Client node: The user interface on the client sends a data read and write request to the blockchain layer through a data request; S2. Signed transaction: The data request uses a private key to digitally sign the request to ensure identity authentication; S3. Peer node 1 / Peer node 2: The peer - to - peer network nodes broadcast transactions / blocks through the distributed coordinator protocol, and at the same time use the Kademlia distributed hash table to maintain the network topology; S4. Complete network: The consensus mechanism uses proof - of - work / proof - of - stake / practical Byzantine fault tolerance to package transactions to generate candidate blocks. Other nodes verify the validity of the candidate blocks. After more than half of the nodes agree, it is uploaded to the blockchain; S5. The smart contract checks the data format and signature validity, then calculates the winner based on the timestamp and executes the contract logic to update the on - chain state.

3. A distributed data consistency management system based on blockchain according to claim 1, characterized in that: In step S3, the Kademlia distributed hash table is an implementation protocol of a distributed hash table for decentralized peer - to - peer network nodes. It organizes the nodes in the network into a structured overlay network through the binary encoding of the node ID and the data key.

4. A distributed data consistency management system based on blockchain according to claim 2, characterized in that: In step S4, proof - of - work finds a random number that meets the conditions through brute - force calculation so that the block hash value is less than the target difficulty. Proof - of - stake selects validators through a pseudo - random algorithm. Practical Byzantine fault tolerance is used for a distributed system to maintain consistency and normal operation in the presence of faulty and malicious nodes. Proof - of - work + proof - of - stake votes to reject bad blocks.

5. A distributed data consistency management system based on blockchain according to claim 4, characterized in that: A smart contract is a self-executing agreement, which is code deployed on a blockchain. It automatically executes operations when preset conditions are met, without the intervention of a third party. The same input always produces the same output, and the execution results of all nodes are consistent. It automatically performs corresponding operations based on predefined rules and conditions. When specific triggering conditions are met, the smart contract will automatically execute the pre-written code logic without manual intervention.

6. A distributed data consistency management system based on blockchain according to claim 1, characterized in that: A peer-to-peer network node is a decentralized network architecture, where nodes refer to various devices participating in the network. Each node can act as a client to request resources or as a server to provide resources and services to other nodes. Nodes share their own resources, such as files, data, computing power, storage capacity, etc., with other nodes. When a node requests to obtain a certain resource, it will establish a connection with the node that has the resource and transfer data through the peer-to-peer network protocol. Each node maintains certain network topology information and helps other nodes find the node where the target resource is located through a distributed routing algorithm.

7. A distributed data consistency management system based on blockchain according to claim 1, characterized in that: The InterPlanetary File System (IPFS) uses content addressing instead of location addressing. It decomposes files into smaller chunks and generates a hash value for each chunk. IPFS nodes store the file chunks locally and use a distributed hash table to store and retrieve the location information of these chunks.

8. A distributed data consistency management system based on blockchain according to claim 1, characterized in that: An off-chain database refers to a database that runs outside the blockchain network and provides data support for smart contracts and applications on the blockchain; An application programming interface (API) is a set of definitions, protocols, and tools used to enable interaction and communication between different software applications. External data can be obtained through software programs and interfaces, and data can be retrieved from data sources on the Internet by calling various API interfaces; An oracle is a mechanism or service that can provide external data and information for blockchain smart contracts.

9. A management method for distributed data consistency based on blockchain, characterized in that: It includes the following steps: H1. Consistency model selection: Select a consistency model according to business requirements; H2. Core algorithms: Paxos: A classic distributed consensus algorithm applicable to CP systems; Raft algorithm: A more understandable consensus algorithm widely used in the etcd system; Atomic broadcast: The atomic broadcast protocol of a distributed coordinator; H3. Data replication: Copy data to nodes close to users (edge computing). Read requests can be distributed to multiple replicas to relieve the pressure on the main node, and different replicas can serve different requests simultaneously; H4. Conflict resolution: Used to handle the situation where data is modified on multiple nodes to ensure that the system finally reaches a consistent state.

10. A management method for distributed data consistency based on blockchain according to claim 9, characterized in that: In step H4, conflict resolution includes the following methods: Q1: Each data modification is attached with a timestamp. When a conflict occurs, the system selects the latest write as the final value and discards the old value; Q2: Let the client decide how to resolve the conflict; Q3: Each replica maintains a version vector to record the modification order of different nodes. By comparing the version vectors, it is judged whether the operations are concurrent or have a causal relationship; Q4: When multiple people edit a document or collaborate on code simultaneously, convert the conflicting operations so that they can be correctly merged.

Images