A cashier data distributed synchronization system and method based on byzantine fault tolerance

Abstract

The application discloses a cashier data distributed synchronization system and method based on Byzantine fault tolerance. The system comprises: a cashier terminal configured with a hash calculation engine and used for splicing current transaction information, a previous data block hash value, a local inventory version number and a local private key signature to calculate a current hash value and generate a data block; a regional collection node used for receiving a plurality of data blocks and compressing a plurality of local private key signatures to generate an aggregated signature by using a bilinear mapping algorithm; and a core consensus node used for performing a consensus process on an aggregated data packet, and when receiving an offline data sequence, if a first-end inventory version number is consistent with a latest global ledger inventory version number and an inner hash verification is passed, the core consensus node skips consensus broadcasting and integrates the offline data sequence into a global state tree. The application can reduce consensus communication complexity, guarantee high-concurrency synchronization and data tamper-proofing safety, and realize rapid conflict self-healing of offline state.

Description

Technical Field

[0001] This application relates to the field of distributed data processing technology, and more specifically, to a distributed synchronization system and method for point-of-sale data based on Byzantine fault tolerance. Background Technology

[0002] In large chain stores, vending machine clusters, or high-concurrency POS environments, POS terminals typically need to synchronize large amounts of transaction data to a central server or underlying data processing network in real time. Traditional centralized databases have significant single-point-of-failure risks, and the risk of internal personnel tampering with the database is high. To improve system security and robustness, existing technologies usually employ decentralized Byzantine fault-tolerant mechanisms, which can ensure global data consistency and tamper-proof characteristics even in the event of partial node failure or the presence of malicious nodes.

[0003] However, traditional consensus algorithms exhibit significant performance bottlenecks in practical engineering applications. Standard Practical Byzantine Fault Tolerance (PBT) algorithms require a preparation and confirmation phase involving network-wide broadcasting between nodes to reach consensus. Their communication complexity is quadratic to the number of participating nodes. When the number of POS terminals in an edge network reaches hundreds or even thousands, high-frequency concurrent synchronization of POS data leads to severe network congestion, a sharp drop in system throughput, and transaction confirmation delays exceeding acceptable levels for commercial scenarios. Furthermore, traditional consensus algorithms mandate that verification nodes remain online in real-time. In cases of weak network conditions or brief network outages at POS terminals, POS data generated during the offline period can easily overlap with already confirmed inventory data in the main network upon network recovery, leading to inventory conflicts. This forces the system to shut down and roll back, or enter a lengthy manual reconciliation process. Therefore, there is an urgent need for a synchronization mechanism that can ensure data consistency and efficiently handle offline data updates while controlling network communication overhead. Summary of the Invention

[0004] This application provides a distributed synchronization system and method for POS data based on Byzantine fault tolerance, which is used to alleviate the communication storm problem caused by high-frequency concurrency of massive terminals in traditional distributed networks, and to solve the state conflict and consensus blocking defects caused during offline data recovery.

[0005] To achieve the above objectives, the first aspect of this application provides a distributed synchronization system for POS data based on Byzantine fault tolerance, including a POS terminal, regional collection nodes, and a core consensus node. The POS terminal is equipped with a hash calculation engine, which generates data blocks by concatenating current transaction information, the hash value of the preceding data block, the local inventory version number, and the local private key signature to calculate the current hash value. The data block carries the current hash value. The regional collection nodes receive multiple data blocks, compress the local private key signatures in the multiple data blocks using a bilinear mapping algorithm to generate an aggregate signature, and send an aggregate data packet containing the aggregate signature to the core consensus node. The core consensus node executes a consensus process on the aggregate data packet. When receiving an offline data sequence, the system extracts the first-end inventory version number of the offline data sequence and compares it with the latest inventory version number of the global ledger. If the first-end inventory version number matches the latest inventory version number and the hash verification within the offline data sequence passes, the consensus broadcast is skipped, and the offline data sequence is incorporated into the global state tree. By constructing a two-layer network architecture consisting of regional collection nodes and core consensus nodes, and compressing local private key signatures into a single aggregate signature, the number of communication nodes participating in consensus can be reduced, thereby effectively eliminating communication storms and improving system concurrency throughput.

[0006] Furthermore, the hash calculation engine is configured to obtain the identifier and quantity changes of the target product, and generate the current transaction information by combining it with the local timestamp; extract the data hash value corresponding to the previous transaction stored locally as the hash value of the preceding data block; read the current inventory version number of the target product in the local inventory database as the local inventory version number; concatenate the current transaction information, the hash value of the preceding data block, and the local inventory version number into a string to be signed, perform asymmetric encryption on the string to be signed using the local private key, and output the current hash value through a secure hash algorithm. By introducing the hash value of the preceding data block and generating a current hash value with concatenation dependency, the transaction data of the local terminal forms a directed acyclic graph structure with temporal causality, thereby blocking the possibility of upstream nodes concealing or maliciously discarding specific intermediate transaction data.

[0007] Furthermore, the POS terminal is also equipped with a version controller, which is configured to update the current inventory version number based on the number of changes after generating the data block to generate a version snapshot; establish a mapping table between the version snapshot and the current hash value; when a network connection is detected to be disconnected, append the data block, the version snapshot, and the corresponding current hash value to a local offline cache queue to form the offline data sequence; wherein, the hash calculation engine is configured to use the serialized current transaction information as the header data, insert the hash value of the preceding data block as a chain pointer field in the middle, append the local inventory version number to the tail, and generate a fixed-length byte stream by padding character alignment to use as the input source for the secure hash algorithm operation. Through formatted concatenation processing and cache queue management, a complete, standardized, and traceable ledger can be established for offline data, improving the integrity of data preservation under abnormal conditions.

[0008] Furthermore, the regional collection node includes a signature aggregator, which is configured to extract the local private key signature from all received data blocks when the number of received data blocks reaches a preset number; call the bilinear mapping algorithm to perform multiplicative homomorphic operations on each local private key signature to generate the aggregated signature; and encapsulate the corresponding current transaction information and the aggregated signature in each data block into the aggregated data packet. By compressing and fusing a large number of discrete asymmetric signatures, the size of the uplink network packets is effectively reduced, further lowering the bandwidth utilization of the underlying consensus network.

[0009] Furthermore, the core consensus node is configured with a state monitor and a tree builder. The state monitor is configured to send a synchronization probe signal to the POS terminal when it detects that the connection status of the POS terminal has switched from offline to online; receive the offline data sequence returned in response to the synchronization probe signal; parse the packet header structure of the offline data sequence, and read the first-end inventory version number corresponding to the first offline transaction at the beginning. Through the issuance of proactive probes and the packet pre-parsing mechanism, reasonable scheduling of data traffic for offline reconnection terminals is achieved, ensuring the stability of the underlying network during instantaneous recovery.

[0010] Furthermore, the tree builder is configured to query the latest leaf node in the locally maintained global state tree, extract the latest inventory version number recorded in the latest leaf node, calculate the version difference between the first-end inventory version number and the latest inventory version number, and if the version difference is zero, determine that there is a conflict-free continuation condition; if the version difference is not zero, determine that there is a conflict, suspend the offline data sequence, send an abnormal status code to the regional collection node, and request the associated POS terminal to initiate an inventory reconciliation request. By calculating accurate version differences and classifying and handling them, isolation barriers can be established in complex distributed environments to prevent parallel double-spending operations or overselling from polluting the global unified ledger.

[0011] Furthermore, when it is determined that the current conditions for conflict-free continuation are met, the tree builder is also configured to initiate hash verification within the offline data sequence, verifying whether the current hash value of the previous data block in the offline data sequence matches the hash value of the preceding data block in the subsequent data block; after confirming the match, a single confirmation proposal is generated; the single confirmation proposal is broadcast globally to the ledger, requiring other core consensus nodes to perform the proposal write action, skipping the broadcast requests in the preparation and confirmation phases, and converting the offline data sequence into a legitimate branch node of the global state tree. By bypassing multi-stage consensus interaction through an optimistic mechanism based on physical isolation boundary verification, the time for historical backlog data to be uploaded to the chain is shortened, avoiding a system shutdown state requiring complete blocking and verification.

[0012] The second aspect of this application provides a distributed synchronization method for POS data based on Byzantine fault tolerance, applied to the system described in the first aspect above. The method includes: generating a data block; concatenating current transaction information, the hash value of the preceding data block, a local inventory version number, and a local private key signature to calculate the current hash value, wherein the data block carries the current hash value; receiving multiple data blocks; compressing the local private key signatures in the multiple data blocks using a bilinear mapping algorithm to generate an aggregate signature; and sending an aggregate data packet containing the aggregate signature to the core consensus node; performing a consensus process on the aggregate data packet; and, upon receiving an offline data sequence, extracting the first-end inventory version number of the offline data sequence and comparing it with the latest inventory version number of the global ledger. If the first-end inventory version number matches the latest inventory version number and the hash verification within the offline data sequence passes, then skipping the consensus broadcast and merging the offline data sequence into the global state tree. This method possesses the same functional logic as the corresponding system, effectively reducing synchronization latency and ensuring system availability under extreme weak network conditions.

[0013] A third aspect of this application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the aforementioned distributed synchronization method for cash register data based on Byzantine fault tolerance.

[0014] The fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described distributed synchronization method for cash register data based on Byzantine fault tolerance. Attached Figure Description

[0015] Figure 1 This is a system architecture diagram of a distributed synchronization system for POS data based on Byzantine fault tolerance, provided in an embodiment of the present invention.

[0016] Figure 2 This is a logical structure block diagram of the regional collection node provided in an embodiment of the present invention.

[0017] Figure 3 This is a logical structure block diagram of the core consensus node provided in the embodiments of the present invention.

[0018] Figure 4 This is a flowchart of the distributed synchronization method for cash register data based on Byzantine fault tolerance provided in an embodiment of the present invention.

[0019] Figure 5 This is a logical structure block diagram of the cash register terminal provided in an embodiment of the present invention.

[0020] Explanation of reference numerals in the attached figures:

[0021] In the diagram: 101-POS terminal, 102-Regional collection node, 103-Core consensus node, 201-Signature aggregator, 202-Homomorphic operation unit, 203-Pre-verification module, 301-State monitor, 302-Tree builder, 501-Hash calculation engine, 502-Version controller, 503-Storage module, 505-Cryptographic chip. Detailed Implementation

[0022] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0023] In large supermarkets or high-density vending machine networks, the front-end hardware environment is complex, and communication links are frequently interfered with. Traditional Byzantine fault-tolerant algorithms require multiple broadcast stages, including pre-preparation, preparation, and confirmation, for each consensus step. When the number of checkout nodes reaches N, the total network communication overhead is proportional to the square of N. This high communication complexity is the root cause of synchronization congestion. To address this technical problem, this application proposes a two-layer network architecture consisting of a collection layer and a consensus layer.

[0024] like Figure 1 As shown, this embodiment provides a distributed synchronization system for POS data based on Byzantine fault tolerance. The synchronization system adopts a layered architecture design in its physical distribution. The system includes several POS terminals 101, multiple regional collection nodes 102, and a set of core consensus nodes 103. To provide the basic platform for system operation, the system is also equipped with a processor for performing consensus and hash operations, high-speed memory for buffering high-concurrency transaction queues, flash memory for offline persistent storage, and a network communication interface module that supports sending and receiving broadcast and transaction data.

[0025] Multiple POS terminals 101 and regional collection nodes 102 form a star network structure. Specifically, several POS terminals 101 are divided into multiple terminal groups according to geographical location or network subnet segments, and each terminal group is configured with a unique regional collection node 102. The regional collection node 102 is only responsible for receiving the original POS data belonging to its own terminal group and does not have direct modification authority on the global state ledger. Multiple regional collection nodes 102 and core consensus nodes 103 form a mesh consensus network structure. Core consensus nodes 103 establish long-lived connection channels to transmit data packets for performing state verification and block on-chain operations based on Byzantine fault tolerance mechanism. Based on this network topology, the main set of nodes participating in the practical Byzantine fault-tolerant consensus has decreased from a huge set including all POS terminals 101 in the entire network to a subset including only a few core consensus nodes 103 and regional collection nodes 102. The number of message exchanges in the communication network has decreased from the quadratic order of the total number of nodes in the entire network to the quadratic order of the total number of nodes participating in the core layer.

[0026] like Figure 5 As shown in the illustration, this embodiment further elaborates on the internal structure of the POS terminal 101. The POS terminal 101 is internally equipped with a hash calculation engine 501. When generating the first and subsequent transaction records, the hash calculation engine 501 is used to locally encapsulate and generate data blocks. The hash calculation engine 501 calculates the current hash value by concatenating the current transaction information, the hash value of the previous data block, the local inventory version number, and the local private key signature. The generated data block carries the current hash value.

[0027] To ensure that data blocks can be traced back to the terminal's unique hardware identity, the POS terminal 101 has an independent non-volatile secure storage medium deployed internally. This secure storage medium is specifically represented by a cryptographic chip 505. The hash calculation engine 501 obtains the identity code of the target product and the quantity changed due to sales, and generates the current transaction information by combining it with the high-precision local timestamp provided by the cryptographic chip 505. Simultaneously, the hash calculation engine 501 extracts the data hash value corresponding to the previously generated transaction from the storage module 503 inside the POS terminal 101, and uses it as the hash value of the preceding data block for this operation. The hash calculation engine 501 reads the current inventory version number of the target product from the local inventory database and uses it as the local inventory version number.

[0028] After collecting the above parameters, the hash calculation engine 501 concatenates the current transaction information, the hash value of the preceding data block, and the local inventory version number in sequence to form a string to be signed. The hash calculation engine 501 calls the protected built-in private key in the cryptographic chip 505, uses the local private key to perform asymmetric encryption on the string to be signed, and then outputs the current hash value through a secure hash algorithm.

[0029] To clarify the hash operation logic mechanism here, specifically, the system performs a hash operation on the current hash value. In this embodiment, the hash calculation engine 501 follows a specific directed acyclic concatenation formula:

[0030]

[0031] Where Hi represents the current hash value corresponding to the i-th transaction; Ti represents the current transaction information containing details of the goods and quantities; and the symbol... This indicates data bit concatenation; This represents the hash value of the preceding data block corresponding to the previous defined data block on the local POS terminal 101; Vinv represents the local inventory version number corresponding to the remaining local inventory of the associated product, for example, the value can be represented as an incrementing integer identifier; Slocal represents the local private key signature generated using the internal secure medium; and the secure hash algorithm represents the hash algorithm model that generates a 256-bit fixed-length hash value. It should be noted that this hash algorithm is only a preferred example, and those skilled in the art can use other secure hash algorithms.

[0032] Through the above algorithmic logic design, because the hash value of the current data block is forcibly nested with the record characteristics of the previous transaction, the historical payment trajectory generated by a single terminal is woven into the current transaction like a chain. This causal binding relationship of the directed acyclic graph gives the local data block strict internal self-consistency, thereby effectively cutting off the possibility of tampering or removing intermediate transactions in the upstream network.

[0033] Furthermore, in an optional implementation, the POS terminal 101 is also equipped with a version controller 502. The version controller 502 is configured to, after generating the data block, incrementally or incrementally update the current inventory version number in the product database based on the change quantity, thereby generating a version snapshot at a specific moment. Subsequently, the version controller 502 establishes a mapping table between the version snapshot and the current hash value, and persistently saves it to the storage module 503.

[0034] When the network communication interface module built into the POS terminal 101 detects a network connection failure with the regional collection node 102, the version controller 502 takes over the data stream during the offline phase. The version controller 502 intercepts the newly generated data block, the corresponding version snapshot, and the associated current hash value, and appends these data sequentially to a locally maintained offline cache queue, thereby forming an offline data sequence with time-series characteristics within the cache.

[0035] To ensure consistency in verification during offline cache reassembly and on-chain processing, the hash calculation engine 501 employs strict alignment principles in the format of the string to be signed. The hash calculation engine 501 serializes the data, for example using a structured data serialization format, and assigns the current transaction information as the header data of the message. It inserts the extracted hash value of the preceding data block as a chain pointer field to maintain the preceding and following relationships into the middle region of the message, and appends the local inventory version number to the tail of the message. Based on this, the hash calculation engine 501 performs bit-length alignment using padding characters, generating a fixed-length byte stream as the input source, which is then input into the hash function to execute the secure hash algorithm. By enforcing format specifications and incorporating snapshot mapping, this mechanism ensures that massive offline transactions generated during periods of weak network connectivity are securely isolated and stored in defined fixed-length units, reducing the risk of memory misalignment or parsing confusion in the offline queue.

[0036] like Figure 2 As shown, the regional collection node 102 is used to handle a massive number of requests from multiple POS terminals 101. Because it controls the aggregation and forwarding rights of data within its group, it poses a single point of risk: selectively dropping orders to conceal specific orders and thus commit malicious acts. The regional collection node 102 includes a signature aggregator 201. The signature aggregator 201 is configured to maintain an event listening loop, initiating a compression and merging process when the number of received data blocks reaches a preset number, such as 1000 records in the cache queue, or a 500-millisecond threshold is elapsed within a time window.

[0037] The signature aggregator 201 extracts the local private key signatures from all received data blocks located in the memory area. Then, the signature aggregator 201 calls the built-in bilinear mapping algorithm to perform multiplicative homomorphic operations on each extracted local private key signature, thereby compressing and merging multiple scattered signatures into a single aggregated signature. Subsequently, the signature aggregator 201 discards redundant original independent signatures and encapsulates the current transaction information corresponding to the core business contained in each data block, along with the merged aggregated signature, into a unified aggregated data packet. The regional collection node 102 then routes the aggregated data packet to the core consensus node 103 via the backbone network.

[0038] The principle behind signature aggregation at this stage is that the system performs a series of multiplication operations on the aggregated signatures, as shown in the following equation model:

[0039]

[0040] Where Sagg represents the unique aggregate signature generated after compression and merging using a bilinear mapping mechanism; k represents the total number of independent POS terminal data blocks participating in this packaging within the same time window, and in this embodiment, the preferred range of k is 50 to 200; Slocal,j represents the j-th extracted local private key signature in the sequence queue; and uppercase multiplication symbol. This represents a continuous multiplication homomorphic operation performed over a cryptographic group field.

[0041] To further explain the pre-verification logic for preventing signature forgery in this aggregation mechanism, the signature aggregator 201 is internally divided into a homomorphic operation unit 202 and a pre-verification module 203. The homomorphic operation unit 202 is configured to define a first cyclic group and a second cyclic group. Mathematically and physically, the first and second cyclic groups are built on specific elliptic curves, have the same prime order, and exist in a standard bilinear pairing operation formula that satisfies the multiplicative homomorphic property. The homomorphic operation unit 202 extracts the input stream and maps the native local private key signature corresponding to each data block to individual group elements in the first cyclic group. Subsequently, the homomorphic operation unit 202 calculates the product of all group elements within the group domain, thereby generating a unique aggregated signature.

[0042] Before packaging and sending the data, the pre-verification module 203 is responsible for local integrity checks. Based on the public key sets of the various POS terminals 101 that issued the data block, the pre-verification module 203 performs corresponding intra-group element accumulation to calculate the aggregated public key. The pre-verification module 203 initiates dual-path cross-verification to verify whether the first and second operation results are equal. The first operation result is the target mapping value calculated by substituting the generated aggregate signature and the specific generator of the elliptic curve into the bilinear pairing operation formula. The second operation result is the theoretical mapping value calculated by substituting the hash product of the transaction information generated by all current independent data blocks and the newly merged aggregated public key into the bilinear pairing operation formula. If the pairing calculation results at both ends are equal, the pre-verification module 203 allows the data to pass and performs the operation of encapsulating and generating the aggregated data packet. If they are not equal, it indicates that tampered data or abnormal signatures have been mixed in. The pre-verification module 203 triggers an anomaly tracing mechanism, backtracking the queue operation to isolate and find the data block that generated the invalid signature. Through this underlying mathematical isomorphic pairing, the regional collection node 102 can significantly reduce the bandwidth redundancy overhead caused by asymmetric signatures within messages without leaking the private key or lowering the verification standard.

[0043] like Figure 3 As shown, the core consensus node 103 is the central hub for maintaining the global distributed ledger and performing Byzantine fault-tolerant determination. The core consensus node 103 is used to execute a standardized, practical Byzantine fault-tolerant consensus process, comprising three phases: pre-preparation, preparation, and confirmation, on the aggregated data packets received normally. Furthermore, upon receiving a reported offline data sequence, the core consensus node 103 performs a specific verification transformation.

[0044] To ensure quick and seamless reconnection for devices that have lost connection due to weak network conditions, the core consensus node 103 is configured with a state monitor 301 and a tree builder 302. The state monitor 301 maintains heartbeat signaling monitoring of the underlying network ports and is configured to send a high-priority synchronization probe signal to a specific POS terminal 101 when its communication connection status changes from a long-term offline state to an online handshake. The state monitor 301 receives the offline data sequence pushed back in batches by the terminal in response to the synchronization probe signal. The state monitor 301 separates the payload content of the messages, parses the header structure of the offline data sequence, and reads the first-end inventory version number recorded in the first offline transaction at the beginning of the header using byte offsets.

[0045] Tree builder 302 undertakes the core data comparison and on-chain continuation tasks. Tree builder 302 retrieves and queries the latest leaf node block corresponding to this batch of target products in the global state tree maintained on the local hard drive. Tree builder 302 extracts the records within the latest leaf node block and obtains the latest inventory version number recognized across the entire network. Tree builder 302 performs a subtraction operation to calculate the version difference between the truncated first-end inventory version number and the latest inventory version number in the main network.

[0046] If the version difference is zero, the tree builder 302 determines that the current mainnet data has not been updated and that the current conditions for conflict-free continuation are met. If the version difference is not zero, it indicates that during the terminal's offline period, other nodes on the network have already performed parallel deductions for the same product, indicating a serious data conflict. The tree builder 302 will immediately suspend and lock the offline data sequence temporarily stored in memory, and send a specific abnormal status code to the associated regional collection node 102 along the original communication path, requesting the associated POS terminal 101 to initiate a forced inventory reconciliation request.

[0047] The verification trigger condition here can be represented by the following version matching physical judgment logic model. Specifically, the system performs an equality judgment operation on the inventory version number:

[0048]

[0049] Where Vinv,start represents the initial inventory version number extracted by the state monitor 301 from the offline header; Vglobal represents the latest inventory version number extracted and read by the tree builder 302 from the latest leaf node block of the global state tree. This variable is represented as an unsigned integer within the system. This matching formula serves as a strict physical boundary separating normal offline record-keeping from malicious double-spending and overselling.

[0050] When the version matches and it is determined that there are no conflict-free continuation conditions, the tree builder 302 is also configured to continue to start internal continuity checks, namely, hash verification within the offline data sequence. The tree builder 302 traverses the cache one by one, verifying whether the current hash value of the previous data block in the offline data sequence completely matches the hash value of the preceding data block in the next data block at the binary level.

[0051] Based on the directed acyclic feature generated internally by the POS terminal 101, after the tree builder 302 confirms that the internal links are fully matched and unbroken, the tree builder 302 directly packages the entire massive offline sequence into a single confirmation proposal. The tree builder 302 broadcasts the single confirmation proposal globally to the ledger, requiring other core consensus nodes 103 in the network to simultaneously execute the action of directly writing the proposal. At this time, the system activates the optimistic confirmation verification path, forcibly skipping the lengthy preparation and confirmation phases of the standard practical Byzantine fault-tolerant process and the multi-point broadcast requests. The tree builder 302 directly appends and merges the offline data sequence, converting it into a legally effective branch node of the global state tree. By combining pre-version locking with optimistic parallel on-chaining, the backbone network consensus blockage caused by massive historical packets during the network disconnection and reconnection phase is eliminated, ensuring that the system's fault self-healing speed is improved without reducing defense standards.

[0052] Based on the aforementioned physical system execution principle, this embodiment also provides a distributed synchronization method for POS data based on Byzantine fault tolerance. The logical carrier upon which this method relies is the distributed synchronization system for POS data based on Byzantine fault tolerance described in the above embodiment. This synchronization method includes the following core business steps during operation:

[0053] Step S401: The POS terminal 101 generates a data block, concatenating the current transaction information, the hash value of the previous data block, the local inventory version number, and the local private key signature to calculate the current hash value. The data block carries the current hash value. This step mainly relies on the hash calculation engine 501 inside the terminal and the base of the cryptographic chip 505 to establish an underlying data structure with tamper-proof causal characteristics.

[0054] Step S402: The regional collection node 102 receives multiple data blocks, uses a bilinear mapping algorithm to compress the local private key signatures in the multiple data blocks to generate an aggregate signature, and sends an aggregate data packet containing the aggregate signature to the core consensus node 103. This step reduces signature redundancy at the regional node level through the signature aggregator 201, reduces the byte pressure transmitted from the network to the upper core layer, and achieves high-density concurrent convergence.

[0055] Step S403: The core consensus node 103 executes the consensus process on the aggregated data packet; upon receiving an offline data sequence, it extracts the first-end inventory version number of the offline data sequence and compares it with the latest inventory version number of the global ledger. If the first-end inventory version number matches the latest inventory version number and the hash verification within the offline data sequence passes, the consensus broadcast is skipped and the offline data sequence is incorporated into the global state tree. This step demonstrates the business cooperation between the state monitor 301 and the tree builder 302. The system ensures eventual consistency and high availability of the system state by intercepting conflicts and establishing optimistic succession paths.

[0056] In summary, the technical solution provided in this application significantly reduces communication storms caused by network-wide broadcasts by building a two-layer network topology that alleviates concurrency pressure. Furthermore, by rigidly locking the hash reference of the previous transaction in the data block, regional nodes are prevented from dropping orders, mitigating the risk of centralized power inherent in a layered architecture. Further, offline inventory version verification and hash chain continuity verification activate an optimistic and fast confirmation path, resolving the issues of idle computing power and mainnet synchronization deadlock caused by traditional consensus algorithms when devices disconnect and reconnect. This entire mechanism establishes a decentralized POS business processing ecosystem foundation.

[0057] It should be noted that the specific component selections and time window thresholds mentioned in the embodiments of this application are merely specific examples provided to facilitate understanding of the technical solutions. Those skilled in the art should understand that, without departing from the core design concept of this application, other similar consensus algorithm variants or equivalent encryption / decryption chip media can be used according to different computing power performance requirements to achieve the corresponding functions and beneficial effects described in this application, and therefore should all be covered within the protection scope of this application.

Claims

1. A distributed synchronization system for POS data based on Byzantine fault tolerance, characterized in that, This includes POS terminals, regional collection nodes, and core consensus nodes; The POS terminal is equipped with a hash calculation engine, which is used to generate data blocks, concatenate the current transaction information, the hash value of the previous data block, the local inventory version number and the local private key signature to calculate the current hash value, and the data block carries the current hash value. The regional collection node is used to receive multiple data blocks, compress the local private key signatures in the multiple data blocks using a bilinear mapping algorithm to generate an aggregate signature, and send an aggregate data packet containing the aggregate signature to the core consensus node. The core consensus node is used to execute the consensus process on the aggregated data packet; When receiving an offline data sequence, the first inventory version number of the offline data sequence is extracted and compared with the latest inventory version number of the global ledger. If the first inventory version number is consistent with the latest inventory version number and the hash verification within the offline data sequence passes, the consensus broadcast is skipped and the offline data sequence is incorporated into the global state tree.

2. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 1, characterized in that, The hash calculation engine is configured to obtain the identifier and changed quantity of the target product, and generate the current transaction information by combining it with the local timestamp; Extract the hash value of the data corresponding to the previous transaction from the local storage as the hash value of the preceding data block; Read the current inventory version number of the target product from the local inventory database as the local inventory version number; The current transaction information, the hash value of the preceding data block, and the local inventory version number are concatenated into a string to be signed. The string to be signed is then subjected to asymmetric encryption using the local private key, and the current hash value is output through a secure hash algorithm.

3. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 2, characterized in that, The POS terminal is also equipped with a version controller, which is configured to update the current inventory version number based on the number of changes after the data block is generated to generate a version snapshot; establish a mapping table between the version snapshot and the current hash value; when a network connection is detected to be disconnected, append the data block, the version snapshot, and the corresponding current hash value to a local offline cache queue to form the offline data sequence; wherein, the hash calculation engine is configured to concatenate the string to be signed in the following format: the serialized current transaction information is used as the header data, the hash value of the preceding data block is inserted as a chain pointer field in the middle, the local inventory version number is appended to the tail, and a fixed-length byte stream is generated by padding characters to be aligned as the input source for the secure hash algorithm operation.

4. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 1, characterized in that, The regional collection node includes a signature aggregator, which is configured to extract the local private key signature from all received data blocks when the number of received data blocks reaches a preset number. The bilinear mapping algorithm is invoked to perform multiplicative homomorphic operations on each of the local private key signatures to generate the aggregate signature; the current transaction information and the aggregate signature corresponding to each of the data blocks are encapsulated into the aggregate data packet.

5. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 1, characterized in that, The core consensus node is configured with a state monitor and a tree builder; the state monitor is configured to send a synchronization probe signal to the POS terminal when it detects that the connection status of the POS terminal has switched from offline to online; receive the offline data sequence returned in response to the synchronization probe signal; parse the packet header structure of the offline data sequence and read the first-end inventory version number corresponding to the first offline transaction at the beginning.

6. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 5, characterized in that, The tree builder is configured to query the latest leaf node in the locally maintained global state tree and extract the latest inventory version number recorded in the latest leaf node; Calculate the version difference between the initial inventory version number and the latest inventory version number; If the version difference is zero, it is determined that the current condition for conflict-free continuation is met; If the version difference is not zero, a conflict is determined, the offline data sequence is suspended, and an abnormal status code is sent to the regional collection node, requesting the associated POS terminal to initiate an inventory reconciliation and recalculation request.

7. The distributed synchronization system for POS data based on Byzantine fault tolerance as described in claim 6, characterized in that, When it is determined that the current conditions for conflict-free continuation are met, the tree builder is further configured to initiate hash verification within the offline data sequence, verifying whether the current hash value of the previous data block in the offline data sequence matches the hash value of the preceding data block in the subsequent data block; after confirming the match, a single confirmation proposal is generated; the single confirmation proposal is broadcast globally to the ledger, requiring other core consensus nodes to perform the proposal write action, skipping the broadcast requests in the preparation and confirmation phases, and converting the offline data sequence into a valid branch node of the global state tree.

8. A distributed synchronization method for POS data based on Byzantine fault tolerance, applied to a distributed synchronization system for POS data based on Byzantine fault tolerance as described in any one of claims 1 to 7, characterized in that, include: Generate a data block by concatenating the current transaction information, the hash value of the previous data block, the local inventory version number, and the local private key signature to calculate the current hash value. The data block carries the current hash value. Receive multiple data blocks, use a bilinear mapping algorithm to compress the local private key signatures in the multiple data blocks to generate an aggregate signature, and send an aggregate data packet containing the aggregate signature to the core consensus node; A consensus process is executed on the aggregated data packets; When receiving an offline data sequence, the first inventory version number of the offline data sequence is extracted and compared with the latest inventory version number of the global ledger. If the first inventory version number is consistent with the latest inventory version number and the hash verification within the offline data sequence passes, the consensus broadcast is skipped and the offline data sequence is incorporated into the global state tree.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the distributed synchronization method for cash register data based on Byzantine fault tolerance as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the distributed synchronization method for POS data based on Byzantine fault tolerance as described in claim 8.

Images