Physical block chain inventory management method and system based on physical state hash and node bookkeeping mechanism

Abstract

The invention relates to the technical field of Internet of Things and warehouse management, in particular to a physical block chain inventory management method and system based on physical state hash and a multi-node collaborative bookkeeping mechanism. The system is composed of a plurality of intelligent nodes with sensing and computing capabilities, and each terminal can be bound with a specific real object and sense the state (including posture, temperature, position, binding state and the like) of the specific real object. A set of distributed and chained physical state change log mechanism is constructed by periodically generating physical state hash abstracts and synchronizing with a cloud end through a local area network in the same area. By combining an intelligent contract binding function, dynamic mapping and expiration management and control of a real object and management authority are realized, a Byzantine fault-tolerant characteristic is realized, and credibility and traceability of a storage state can still be guaranteed under the condition of node missing, dismantling or abnormity. The system can be widely applied to logistics, storage, asset supervision, pledge finance and other scenes, and provides hardware-level basic support for constructing a credible inventory management system.

Description

Technical Field

[0001] The present invention relates to the field of the integration of the Internet of Things, edge computing and blockchain technology, and in particular to a physical blockchain inventory management system and method based on physical state hashing and node collaborative accounting. Background Art

[0002] Currently, mainstream inventory management systems rely on static identification methods such as manual code scanning, QR code / RFID recognition, etc., which have the following problems: The accounts do not match the actual situation, and real-time inventory cannot be taken; There is a lack of recording and verification mechanisms for changes in physical status; The inbound and outbound activities are difficult to trace, and there is a risk of human intervention; There is a lack of consistency and verifiability in cross-regional and cross-organizational management.

[0003] Although blockchain technology provides the characteristics of "decentralization" and "verifiability", most of its applications are limited to digital assets or process records and lack a direct mapping with the physical state of the real world. Summary of the Invention

[0004] This paper proposes a physical blockchain inventory management method and system based on physical state hashing and node accounting mechanism, aiming to solve key problems in traditional inventory management such as discrepancies between accounts and actuals, unverifiable status, difficult data traceability, and high risk of node failure, and to build a trusted inventory ledger system with self-perception, self-recording, and self-collaboration capabilities.

[0005] The technical solution of the present invention includes the following key components and technical processes:

[0006] 1. Technical Goals

[0007] The present invention aims to achieve the following core objectives: 1. Use physical status perception and encryption summary mechanism to ensure the consistency of inventory status and ledger data; 2. Introducing a chain log structure and multi-node coordination mechanism to prevent data forgery and single point failure; 3. Integrate intelligent binding and lifecycle contract management to achieve physical-level permission control and auditable management; 4. Real-time monitoring of inventory status and decision support can be achieved with the help of cloud aggregation and graph visualization.

[0008] 2. Overall Technical Plan

[0009] The system consists of multiple intelligent nodes. After being physically bound to physical objects, these intelligent nodes periodically collect multi-dimensional state information about the objects. Each state point generates a cryptographic hash digest and links it to the previous state, forming a complete state trajectory. Multiple intelligent nodes in the same network domain form a local collaborative network, supporting event broadcasting and fault-tolerant witnessing. All log data is synchronized to a cloud platform for verification, account table generation, and graphical display.

[0010] 3. Implementation of each sub-module and key mechanism

[0011] (1) Intelligent node structure and module composition

[0012] Smart nodes have multiple sensing and processing functions, and their structure includes: State perception module: used to collect temperature, posture, spatial position, and binding status; Hash calculation module: implements hash algorithm processing such as SHA-256; Communication module: supports Bluetooth Mesh, Wi-Fi, LoRa and other methods for local broadcasting and data synchronization; Storage module: used to locally save state trajectory chain and binding information; Anti-dismantle module: supports illegal dismantling monitoring; Power supply module: supports low power consumption operation.

[0013] (2) State collection and hash generation mechanism

[0014] During each time period, the intelligent node encapsulates the collected status data (such as temperature, posture, location, etc.) and timestamps into a standard format and inputs it into a hash algorithm to generate a status summary value. This hash summary, combined with the previous status hash, forms a chain relationship, ensuring that the data cannot be tampered with and is traceable.

[0015] The state hash structure is as follows: Current hash = SHA256(state content + timestamp + previous hash).

[0016] (3) State trajectory chain and event log structure

[0017] The smart node locally builds a "state track chain" and generates a state block for each state change. The record includes: Current status summary; Previous status summary; Event type and timestamp; Node numbering and consensus labeling; Bind contract reference information.

[0018] The chain structure has strong consistency and tamper-resistant features, and supports cloud and neighborhood node verification.

[0019] (4) Multi-node fault tolerance and Byzantine witness mechanism

[0020] When a smart node fails or is removed, causing the state chain to be interrupted, the system automatically starts the fault-tolerant synchronization process: Neighboring nodes capture the last broadcast information and mark it as “joint witness”; Cross-validation of missing events from multiple node logs; After reaching a majority consensus (e.g. 2 out of 3), the chain segment is allowed to be completed; The cloud can replay neighborhood logs to repair events.

[0021] This mechanism simulates the physical layer Byzantine fault tolerance to prevent state loss caused by single point failure.

[0022] (5) Smart binding contract and permission control mechanism

[0023] Each resident smart node establishes a management relationship with the supervised physical object through a binding contract. The contract includes: Binding object unique ID; Binding time and validity period; Permission information (manager, purpose, etc.); Remove alarm and unbinding recording logic.

[0024] The contract supports renewal reminders, forced demolition alarms, automatic unbinding and log archiving to ensure the authenticity and traceability of the binding relationship.

[0025] (6) Cloud coordination platform and account table map generation

[0026] The cloud platform has the following functions: Aggregate state chains and contract data uploaded by multiple nodes; Verify the continuity and integrity of the hash chain; Automatically generate inventory ledgers (debit / credit, in / out); Build a state map to support map visualization and historical trajectory backtracking; Execute automatic contracts, such as exception handling, permission changes, etc.

[0027] The cloud platform supports docking with ERP, WMS, and risk control systems, realizing the coordinated integration of traditional systems and the system of the present invention.

[0028] IV. Technical Advantages and Significant Improvements

[0029] Compared with the prior art, the present invention has the following significant technical advancements: 1. High consistency between accounts and actuals: Real-time status perception + chain structure to ensure data authenticity; 2. Strong anti-tampering and traceability capabilities: Hash encryption + front-end chain structure ensures that the status track cannot be forged; 3. Sound physical fault tolerance mechanism: Neighborhood witness + majority consensus reconstruction to improve system robustness; 4. Intelligent binding contract: support permission control, unbinding verification, and forced demolition alarm; 5. The system is highly versatile: applicable to various scenarios such as logistics warehousing, pledge finance, and industrial supervision; 6. Comprehensive cloud support: integrated status aggregation, report export, graph backtracking, and early warning management. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Attachment Figure 1 : Schematic diagram of the overall system architecture.

[0031] Attachment Figure 2 : Intelligent node module composition diagram.

[0032] Attachment Figure 3 : Schematic diagram of state hash chain generation.

[0033] Attachment Figure 4 : Schematic diagram of physical Byzantine fault tolerance.

[0034] Attachment Figure 5 : Generate logical diagram of cloud-based trusted inventory account table. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solution and beneficial effects of the present invention clearer and more specific, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. The present invention is not limited to the following specific embodiments, and any equivalent replacement or improvement under the spirit and principle of the present invention should be included in the scope of protection of the present invention.

[0036] Example 1: Chain recording of goods status in the warehouse

[0037] In a certain warehouse area A, three smart nodes R1, R2, and R3 are deployed, each bound to three pallets of cargo P1, P2, and P3, respectively. Every 10 minutes, each smart node collects physical state data of the currently bound object, including temperature, posture, spatial position, and binding status.

[0038] Taking the data collected by R1 as an example, its status structure is as follows: { "Item ID": "P1", "Temperature": 22.5, "Posture": "Normal", "Position": [12.3, 7.8, 0.6], "Binding Status": "Valid", "Timestamp": "2025-07-01T10:10:00", "Previous Status Hash": "f23a...9f0e" }

[0039] This data is hashed using the SHA-256 function to generate the current state fingerprint: Current state hash = SHA256(state content + previous state hash).

[0040] The hash is then linked to the previous state to form a chain structure. R1 saves the chain segment locally and uploads it to the cloud periodically.

[0041] If cargo P1 shows abnormal posture (such as overturning) at 10:15, R1 will collect the abnormal event and broadcast it: Event: P1 abnormal posture (rollover) Node: R1 Time:2025-07-01T10:15:00

[0042] Neighboring nodes R2 and R3 capture the event, generate a “joint witness” tag, and participate in fault-tolerant recording.

[0043] Example 2: Smart binding contract and anti-tampering reminder mechanism

[0044] During system initialization, R2 is bound to the physical object P2, generating the following binding contract: The system will automatically push a "renewal reminder" 7 days before the expiration of the binding period. If the responsible person does not handle it, the contract will automatically expire and trigger an "unbinding event": P2 unbinding event, the responsible person did not renew, recorded on 2025-07-31 23:59.

[0045] If P2 is forcibly dismantled during the binding validity period (for example, by physically disconnecting the latch or opening the seal), the Hall effect sensor inside the smart node R2 will identify the "anti-dismantling event" and immediately issue an alarm broadcast, triggering the following actions: 1. R2's local marking status is "forced demolition"; 2. R1 and R3 witness the event and co-sign the record; 3. A "security alert" is generated on the cloud, and the contract status is updated to "abnormal unbinding".

[0046] Example 3: Cloud-based trusted inventory account table generation

[0047] The cloud platform aggregates the status trace chains and event logs uploaded by all smart nodes daily to generate a trusted inventory summary table. Taking the data from the past 24 hours as an example, the following structure table is generated: Item ID Current Status Recent Events Last updated State Hash P1 normal No abnormalities 2025-07-01 10:10 a9c3fe... P2 Fall alarm Abnormal posture 2025-07-01 10:15 8bc9d3... P3 normal No abnormalities 2025-07-01 10:10 bcb4e8... The system supports exporting the account table in multiple modes, such as: Debit and credit inventory account (listed by inventory in / out records); Inbound and outbound accounts and tables (including status changes and responsibility nodes); Graphical trajectory display (backtracking by location and time nodes).

[0048] In addition, the cloud also generates status maps and heat maps, showing information such as the abnormal density of each item, risk index, node failure history, etc.

[0049] Example 4: Event reconstruction under a fault-tolerant mechanism.

[0050] In actual use, suppose that the intelligent node R3 loses power unexpectedly, resulting in the loss of part of its recorded state trajectory chain. After the system detects the chain segment break, it immediately initiates the following fault tolerance process: 1. Call the logs of neighboring nodes (such as R1 and R2); 2. Check if there is a "joint witness" entry for R3's most recent event; 3. If the logs of two or more nodes are consistent, the cloud system generates a "cooperative chain filling" block to fill the chain segment; 4. If the node logs are inconsistent, they will be forwarded for manual approval and marked with a "low credibility" prompt.

[0051] This process is based on the principles of neighborhood consensus and log cross-validation to ensure that chain state records are recoverable even in node failure scenarios.

[0052] Example 5: Cross-regional multi-warehouse joint management

[0053] The system supports the simultaneous deployment of intelligent nodes in warehouses across multiple locations, all managed centrally through the cloud. Each intelligent node in each area forms an independent local area network, with status data first collaboratively verified locally before being uploaded to the cloud in batches.

[0054] The cloud system can manage assets according to the following dimensions: Warehouse / area division; Item type; Management authority; Binding contract status; Abnormal alarm priority.

[0055] In addition, the cloud platform has an API interface that supports connection to third-party ERP, WMS or financial regulatory platforms to generate reliable inventory reports in a standard format, providing compliance data support for bank pledge supervision, judicial sealing, corporate asset management, etc.

Claims

1. A physical blockchain inventory management method and system based on physical state hashing and node accounting mechanism, characterized by: include: At least one intelligent node with edge perception and communication capabilities, The smart node includes: A state perception module is used to collect physical state data of the bound object in real time, wherein the state data includes at least temperature, posture, spatial position, and binding relationship; A hash generation module, used to generate a state hash summary for the collected state data; Communication module, used for data synchronization and event broadcasting with other smart nodes and the cloud through the local area network; A blockchain-style log module that records state changes as event logs and constructs a state track chain through timestamps and hash links. Smart binding module, used to configure and manage the binding relationship between smart nodes and target objects and the binding validity period; The fault-tolerant mechanism module is used to restore status records and behavior proofs based on event data witnessed by surrounding nodes when a single node fails or is removed.

2. The method and system according to claim 1, wherein the state hash digest is generated using at least a SHA-256-type cryptographic hash function and is combined with a timestamp to form a unique state fingerprint.

3. The method and system according to claim 1, wherein the smart nodes establish a local area Internet network through Bluetooth Mesh, Wi-Fi, or ultra-low power wireless network to achieve event broadcasting and mutual verification.

4. The method and system according to claim 1, wherein the intelligent binding module supports setting the unique ID, validity period, responsible person, and usage information of the bound physical object, and has overdue reminder and unbinding log recording functions.

5. The method and system according to claim 1, wherein the fault tolerance mechanism module supports multi-party signatures or event joint witness logs based on neighboring nodes to form a physical Byzantine fault tolerance mechanism.

6. The method and system according to claim 1 also includes a cloud-based coordination and management platform with event aggregation, log verification, state map generation and cross-warehouse area smart contract execution functions.

Images