Hierarchical lock and blockchain-based key data binding method and related device

Abstract

This invention discloses a key data binding method and related equipment based on hierarchical locks and blockchain. The invention employs a hierarchical lock mechanism combining serial number segment pre-ownership and dynamic leases. Workstation clients apply for batch serial number segment locks and periodically renew them. After successfully holding a lock, multi-source data is pulled from the upstream system through a unified data adaptation layer. After local pre-verification, the serial number is written, generating the original data packet. The data packet is encrypted and uploaded to IPFS to obtain a hash address. This hash address, along with a unique fingerprint, lock credential, and business context, forms a notarized transaction and is sent to the blockchain. A finite state machine smart contract verifies the lock's validity, field uniqueness, and state transitions. Upon successful verification, the transaction is notarized on the blockchain. Finally, the lock is released, returning the serial number segment. This forms a complete closed loop from lock application, data pre-aggregation, serial number writing, hierarchical notarization, to lock release, establishing an end-to-end trusted production record for the equipment.

Description

Technical Field

[0001] This invention relates to the fields of digital information management and industrial Internet of Things (IoT) technology, specifically to a key data binding method and related equipment based on hierarchical locks and blockchain. Background Technology

[0002] In the mass production of digital multimedia terminals, writing a unique serial number (SN), MAC address, CA certificate, and HDCP key to each device is a core step in establishing its legitimate identity and security attributes. Ensuring the global uniqueness of this data and its strong binding relationship with the hardware is an inviolable quality red line in the production process. Currently, centralized database management models are facing severe challenges: in high-concurrency write scenarios, "dirty reads" caused by network latency or caching are difficult to eliminate, and the risk of data duplication always exists; at the same time, the system lacks an unconditionally trustworthy and tamper-proof operation record, making cross-enterprise tracing and auditing complex and costly in the event of a data dispute; more importantly, centralized administrators possess excessively high privileges, posing a potential security threat of internal data tampering.

[0003] Faced with these challenges, the industry has attempted to introduce distributed locks to control concurrency or utilize blockchain for trusted data storage. However, simply piecing together general technologies and applying them directly to the specific scenario of digital multimedia terminal production encounters new, less obvious obstacles: the high concurrency requests on the production line, operating at the second level, easily make general distributed lock services a performance bottleneck; their fixed timeout mechanisms often misjudge due to fluctuations in production rhythm, leading to premature lock releases and write interruptions; simultaneously, data such as SN, MAC, and CA are asynchronously distributed from different upstream systems, and when a workstation holds a lock, the resulting data packets may already be logically mismatched, while general smart contracts can only verify the existence of single-point data, not the overall business validity of the data packets; furthermore, writing massive numbers of write operations to the blockchain would cause a rapid increase in data volume and a sharp drop in efficiency, while simple hash storage cannot meet the subsequent audit's need for rapid access to the original data. Therefore, the industry urgently needs a new management method that can deeply integrate concurrency control and trusted data storage technologies and provide systematic solutions to the specific obstacles in the aforementioned industrial scenarios. Summary of the Invention

[0004] Based on the problems raised in the background technology above, the purpose of this invention is to provide a key data binding method and related equipment based on hierarchical locks and blockchain. This not only solves the problems of high-concurrency dirty reads, internal tampering and difficulty in tracing existing centralized databases, but also solves the systemic obstacles caused by the introduction of distributed locks and blockchain, such as performance bottlenecks, lock timeout misjudgments, data packet logical mismatches and contradictions between evidence storage efficiency and auditing requirements.

[0005] This invention is achieved through the following technical solution:

[0006] The first aspect of this invention provides a method for binding key data based on hierarchical locks and blockchain, comprising the following steps:

[0007] Initiate a lock request to the distributed lock service. Upon receiving a successful response, establish a dynamic lease mechanism and acquire a sequence number segment lock.

[0008] Based on the serial number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data;

[0009] The multi-source data is written to generate the original data packet;

[0010] The original data packet is encrypted and uploaded to the IPFS cluster to obtain a globally unique IPFS hash address. A notarization transaction containing the IPFS hash address is constructed, and the notarization transaction is sent to the blockchain for verification and notarization.

[0011] After the evidence is stored, a lock release request is sent to the distributed lock service, and the sequence number segment lock is returned.

[0012] In the above technical solution, the workstation client first initiates a lock request to the highly available distributed lock service cluster. This employs a tiered locking mechanism that combines serial number segment pre-reservation with dynamic leases, optimized for industrial scenarios. Instead of requesting a lock for a single serial number, the client requests to lock a batch of serial number segments. The lock service only needs to process the request once to satisfy subsequent multiple write requests, significantly reducing the request pressure on the lock service. Upon receiving a successful response from the lock service, a dynamic lease mechanism is established between the workstation client and the lock service. The workstation needs to periodically renew the lease with the lock service based on the real-time production rhythm. If a workstation malfunctions or the production rhythm is abnormal, causing the lease to fail to renew, the lock service can automatically reclaim the number segment and redistribute it. This avoids business interruptions or lock misjudgments caused by a fixed timeout mechanism while acquiring the lock for that serial number segment. Having successfully acquired the serial number segment lock, the workstation software enters the writing preparation phase. Based on the number segment range protected by the lock, it initiates batch data retrieval requests to various upstream systems such as MES, CA management system, and key management system. Through the workstation-side data pre-aggregation mechanism, it obtains multi-source data such as SN, MAC, CA certificate, and HDCP key to be written from various heterogeneous data sources in parallel. It then uses a unified data adaptation layer to complete protocol conversion, format parsing, and field mapping. Only when all the information constituting the complete data packet arrives and passes the local business rule pre-verification is the data considered ready. Subsequently, the workstation software performs the actual writing operation on the multi-source data, writing the key data to the storage area of ​​the digital multimedia terminal and generating a complete original data packet containing the device chip ID, operation timestamp, workstation ID, and the currently held lock credential.

[0013] The workstation software encrypts and uploads the original data packets to the IPFS cluster, obtains a globally unique IPFS hash address, and then constructs a concise notarization transaction using only this IPFS hash address along with core uniqueness verification fields such as SN hash, MAC hash, lock credentials, and business context. This transaction is then sent to the permissioned blockchain network, where a smart contract designed as a finite state machine automatically verifies the transaction, including checking the validity of the lock, the uniqueness of the fields, and the legality of the state transitions. Once the verification is successful, on-chain notarization is completed. Finally, after the notarization operation is successfully completed, the workstation client proactively initiates a lock release request to the distributed lock service, returning the previously occupied sequence number segment lock so that the segment can be reassigned to other workstations. This forms a complete closed loop from pre-lock application, in-process data pre-aggregation and number writing, post-event hierarchical notarization to lock release, establishing an end-to-end trusted production record for each digital multimedia terminal.

[0014] In one optional embodiment, based on the sequence number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data, including:

[0015] A unified data adaptation layer is constructed, which includes a three-layer architecture of adapter, converter and bus;

[0016] The adapter obtains raw data from the upstream system and transmits the raw data to the converter.

[0017] The converter automatically selects a parser and mapping rules based on the data source identifier, converts the raw data to a standard exchange format, and pushes the data in the standard exchange format onto the bus;

[0018] The data pushed onto the bus in the standard exchange format is verified, and the verified data is used as multi-source data.

[0019] In one alternative embodiment, verifying the data pushed onto the bus in a standard exchange format further includes:

[0020] Obtain the latest local validation rules, and use these rules to validate data in the standard exchange format:

[0021] If the data verification for the standard exchange format fails within the validity period of the serial number segment lock, the serial number segment lock is actively released, and the exception information is encapsulated into a structured log and reported.

[0022] In one optional embodiment, constructing a notarization transaction containing the IPFS hash address includes:

[0023] Extract key fields from the original data packet, calculate the hash value of the key fields, and form a fingerprint set in the form of key-value pairs;

[0024] Extract the lock credentials of the serial number segment lock to form a process credential;

[0025] Use the IPFS hash address as the data pointer for the evidence storage transaction;

[0026] Obtain business information and use the business information to form a business context; wherein, the business information includes device chip ID hash, operation timestamp, and workstation ID;

[0027] The fingerprint set, the process credential, the data pointer, and the business context are used to construct a notarized transaction.

[0028] In one optional embodiment, a key field for global uniqueness verification is extracted from the original data packet, and the hash value of the key field is calculated to form a fingerprint set in key-value pair form, including:

[0029] According to the preset business rule base, the fields that must be globally unique for the current device type are identified from the original data packet as key fields; wherein, the key fields include hardware serial number, network MAC address, chip ID and security chip public key hash;

[0030] A collision-resistant hashing algorithm is used to independently hash the original value of each key field to generate a unique fingerprint;

[0031] The unique fingerprint is incorporated into the transaction data structure in the form of key-value pairs to form a fingerprint set.

[0032] In one optional embodiment, extracting the lock credential of the serial number segment lock includes:

[0033] The lock credentials include: a globally unique lock ID, a lock number range, an grant timestamp, a lease validity period, and a digital signature for the lock service;

[0034] The lock certificate is encapsulated as a process certificate into the evidence storage transaction.

[0035] In one optional embodiment, sending the notarized transaction to the blockchain for verification and notarization includes:

[0036] The digital signature of the lock service is verified using the public key of the lock service.

[0037] The validity of the evidence-based transaction is verified by the lease term;

[0038] Verify the consistency between the locked number segment and the serial number range implied by the unique fingerprint.

[0039] A second aspect of this invention provides a key data binding system based on hierarchical locks and blockchain, comprising:

[0040] The tiered lock application and dynamic lease establishment module is used to initiate lock application requests to the distributed lock service. When a successful response is received, a dynamic lease mechanism is established and a sequence number segment lock is acquired.

[0041] The multi-source data acquisition module is used to initiate batch data retrieval requests to each upstream system based on the serial number segment lock to acquire multi-source data;

[0042] The local writing module is used to perform writing operations on the multi-source data to generate the original data packet;

[0043] The hierarchical evidence storage and on-chain state machine verification module is used to encrypt and upload the original data packet to the IPFS cluster, obtain the globally unique IPFS hash address, construct an evidence storage transaction containing the IPFS hash address, and send the evidence storage transaction to the blockchain for verification and evidence storage.

[0044] The lock release module is used to initiate a lock release request to the distributed lock service after the evidence is stored, and to return the sequence number segment lock.

[0045] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a key data binding method based on hierarchical locking and blockchain.

[0046] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a key data binding method based on hierarchical locks and blockchain.

[0047] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0048] 1. By using a tiered locking mechanism, the performance bottleneck of general distributed locks in high-concurrency scenarios is overcome, achieving pre-event concurrency control and in-event risk prevention;

[0049] 2. By combining workstation-side pre-aggregation with on-chain state machines, the possibility of multi-source data mismatch is eliminated from the source, and data consistency assurance is elevated from the recording level to the business logic level.

[0050] 3. By employing a tiered notarization and dual-indexing strategy, the system effectively controls the data scale of the blockchain main chain while ensuring the immutability and traceability of core data, thus guaranteeing the long-term stability and economic efficiency of the system.

[0051] 4. This method seamlessly integrates technology management with business processes, creating an indisputable "digital birth certificate" for each digital multimedia terminal that leaves the factory and spans its entire lifecycle, thus building an end-to-end trusted production system. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0053] Figure 1 This is a flowchart illustrating the key data binding method based on hierarchical locks and blockchain provided in Embodiment 1 of the present invention.

[0054] Figure 2 This is a flowchart illustrating the three-level evidence preservation process provided in Embodiment 1 of the present invention;

[0055] Figure 3 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0057] Example 1

[0058] Embodiment 1 of this invention provides a method for binding key data based on hierarchical locks and blockchain, such as... Figure 1 As shown, the key data binding method based on hierarchical locks and blockchain includes the following steps:

[0059] Initiate a lock request to the distributed lock service. Upon receiving a successful response, establish a dynamic lease mechanism and acquire a sequence number segment lock.

[0060] Based on the serial number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data;

[0061] The multi-source data is written to generate the original data packet;

[0062] The original data packet is encrypted and uploaded to the IPFS cluster to obtain a globally unique IPFS hash address. A notarization transaction containing the IPFS hash address is constructed, and the notarization transaction is sent to the blockchain for verification and notarization.

[0063] After the evidence is stored, a lock release request is sent to the distributed lock service, and the sequence number segment lock is returned.

[0064] It should be noted that, firstly, the workstation client initiates a lock request to the highly available distributed lock service cluster. This employs a tiered locking mechanism that combines serial number segment pre-reservation with dynamic leases, optimized for industrial scenarios: the client does not request a lock for a single serial number, but rather requests to lock a batch of serial number segments. The lock service only needs to process the request once to meet the subsequent multiple write requests, thus significantly reducing the request pressure on the lock service. Upon receiving a successful response from the lock service, a dynamic lease mechanism is established between the workstation client and the lock service. The workstation needs to periodically renew the lease with the lock service according to the real-time production rhythm. If a workstation malfunctions or the rhythm is abnormal, causing the lease to fail to renew, the lock service can automatically reclaim the number segment and redistribute it. This avoids business interruption or lock misjudgment caused by a fixed timeout mechanism while acquiring the lock for the serial number segment. Having successfully acquired the serial number segment lock, the workstation software enters the writing preparation phase. Based on the number segment range protected by the lock, it initiates batch data retrieval requests to various upstream systems such as MES, CA management system, and key management system. Through the workstation-side data pre-aggregation mechanism, it obtains multi-source data such as SN, MAC, CA certificate, and HDCP key to be written from various heterogeneous data sources in parallel. It then uses a unified data adaptation layer to complete protocol conversion, format parsing, and field mapping. Only when all the information constituting the complete data packet arrives and passes the local business rule pre-verification is the data considered ready. Subsequently, the workstation software performs the actual writing operation on the multi-source data, writing the key data to the storage area of ​​the digital multimedia terminal and generating a complete original data packet containing the device chip ID, operation timestamp, workstation ID, and the currently held lock credential.

[0065] The workstation software encrypts and uploads the original data packets to the IPFS cluster, obtains a globally unique IPFS hash address, and then constructs a concise notarization transaction using only this IPFS hash address along with core uniqueness verification fields such as SN hash, MAC hash, lock credentials, and business context. This transaction is then sent to the permissioned blockchain network, where a smart contract designed as a finite state machine automatically verifies the transaction, including checking the validity of the lock, the uniqueness of the fields, and the legality of the state transitions. Once the verification is successful, on-chain notarization is completed. Finally, after the notarization operation is successfully completed, the workstation client proactively initiates a lock release request to the distributed lock service, returning the previously occupied sequence number segment lock so that the segment can be reassigned to other workstations. This forms a complete closed loop from pre-lock application, in-process data pre-aggregation and number writing, post-event hierarchical notarization to lock release, establishing an end-to-end trusted production record for each digital multimedia terminal.

[0066] The architecture of this embodiment consists of three parts: write client software deployed at each production workstation, a distributed lock cluster providing hierarchical lock services (which can be built and expanded based on Redis or Zookeeper), and a permissioned blockchain network (e.g., built on Hyperledger Fabric) jointly maintained by key business parties such as manufacturers, solution providers, and operators. The blockchain network deploys smart contracts implemented as finite state machines (called chaincode in Fabric) for performing uniqueness verification and business logic validation. In addition, the system includes an InterPlanetary File System (IPFS) cluster for storing complete raw data, and an off-chain index database that can be periodically snapshotted for evidence storage.

[0067] The workflow begins with a digital multimedia terminal to be written to being placed at the production station. The station software triggers the writing process by scanning the device's chip ID or other inherent identifier.

[0068] First, the workstation software initiates a lock request to the distributed lock service. To overcome the performance bottleneck of general distributed locks in high-concurrency scenarios, this embodiment adopts a sequence number segment pre-occupancy strategy: the workstation software does not request a lock for a single sequence number, but requests to lock a batch of sequence number segments (e.g., 100 consecutive SNs).

[0069] Upon receiving a request, the distributed lock service checks if the specified number segment is already locked by another workstation. If not, it immediately grants the lock to the segment and returns a success response, while simultaneously establishing a dynamic lease mechanism. Workstation software needs to periodically renew the lease with the lock service based on real-time production rhythm; the renewal period is dynamically adjusted by the system based on the workstation's historical production data. If a workstation malfunctions or an abnormal production rhythm prevents lease renewal, the lock service will automatically reclaim the number segment to prevent resource deadlock. If the number segment is already locked, the service rejects the current request, the workstation software receives a failure notification, and the operator is prompted to check the serial number resource or wait for the segment to be released.

[0070] In one optional embodiment, based on the sequence number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data, including:

[0071] A unified data adaptation layer is constructed, which includes a three-layer architecture of adapter, converter and bus;

[0072] The adapter obtains raw data from the upstream system and transmits the raw data to the converter.

[0073] The converter automatically selects a parser and mapping rules based on the data source identifier, converts the raw data to a standard exchange format, and pushes the data in the standard exchange format onto the bus;

[0074] The data pushed onto the bus in the standard exchange format is verified, and the verified data is used as multi-source data.

[0075] It is important to note that after successfully acquiring the serial number segment lock, the workstation software immediately enters the data preparation phase. The core challenge at this stage lies in the fact that critical information constituting the complete serial number writing data packet, such as the SN, MAC, CA, and HDCP Key, is often generated independently and asynchronously by different upstream systems—the Production Management System (MES) is responsible for allocating the serial number segment, the CA management system is responsible for issuing certificates, and the key management system is responsible for issuing HDCP keys—the arrival time, order, and format of this data at the workstation are all uncertain. In existing technical solutions, the workstation typically adopts a "serial single-point acquisition" method, that is, requesting data from each upstream system one by one in real time during the writing process; if any data fails to arrive, the entire process is blocked. This passive waiting mode is highly susceptible to workstation idleness due to data arrival delays. More seriously, due to the lack of cross-system logical verification, data mismatches (such as incorrect MAC address and SN mappings, or CA certificates not matching equipment models) are often only discovered through random checks after production is completed, resulting in batches of defective products.

[0076] To address the aforementioned shortcomings, this embodiment designs a workstation-side data pre-aggregation mechanism, transforming data acquisition and verification from post-event discovery to pre-event prevention. That is, when a workstation obtains a serial number segment lock, the workstation software does not passively wait for data to be pushed, but actively initiates batch data retrieval requests for that segment to each upstream system according to a preset data source collection strategy. This batch data retrieval request makes full use of the lock's validity window to complete the collection and processing of multi-source data in parallel, compressing the data waiting time from serial accumulation to parallel coverage.

[0077] However, batch fetching only solves the efficiency problem of data acquisition. The deeper technical obstacle lies in the heterogeneity and asynchronous arrival of multi-source data. Each upstream system may use different communication protocols (HTTP, MQ, FTP), data formats (JSON, XML, custom binary), and delivery mechanisms (real-time push, batch distribution). The time order of data arrival is uncontrollable, and there may be delay differences on the order of minutes.

[0078] To address the aforementioned shortcomings, this embodiment constructs a unified data adaptation layer, developing a dedicated adapter for each data source to shield against underlying protocol and format differences.

[0079] The protocol adapter set comprises independent adapter instances developed for each upstream data source, such as MES systems, CA management systems, and key management systems. Each adapter adheres to a unified interface specification and independently handles underlying communication details, including protocol differences, authentication methods, network timeouts, and retry policies, thereby unifying heterogeneous communication mechanisms into internal data retrieval requests. After obtaining raw data from the upstream system through these adapters, the raw data is transmitted to a data conversion engine. This conversion engine internally maintains parsers for different data formats, such as XML parsers, JSON parsers, and custom binary parsers, as well as a set of field mapping rules. The conversion engine automatically selects the corresponding parser and mapping rules based on the data source identifier, mapping the original field names in the raw data to unified field names within the system and performing data type conversion. This converts the raw data into an internally defined standard data exchange format, and then encapsulates the converted standard format data into a predefined JSON format. The schema data packet is pushed onto the standardized data bus. This standard format includes key fields such as data type identifier, source system identifier, sequence number range, data load, timestamp, and preliminary data processing status. The upper-layer data pre-aggregation module listens to the standardized data bus and verifies the data in the standard exchange format pushed onto the bus, including the validity of single data format, cross-field business rules, and context consistency. Only data that passes the verification is used as multi-source data for subsequent write operations.

[0080] Compared to existing technologies, its improvements are as follows:

[0081] First, it decouples the protocol from the logic. The core pre-aggregation logic no longer needs to write numerous if-else branches to handle different data sources. All heterogeneity is encapsulated within the adapter, allowing the core logic to focus on business rule validation, greatly improving code maintainability and scalability. When a new data source is introduced, only a new adapter needs to be developed and the corresponding mapping rules configured, without modifying any core code.

[0082] Secondly, the adapter's built-in intelligent error handling and compensation mechanism enhances the system's robustness. Each adapter independently monitors the communication status of its corresponding data source. When a temporary fault is detected (such as network interruption or service unavailability), the adapter will automatically retry according to a preset strategy (such as exponential backoff) and report the fault information to the monitoring center. Only after consecutive retry failures will the exception be passed to the upper layer, avoiding the blockage of the entire workstation process due to fluctuations in individual data sources.

[0083] Furthermore, the adapter layer supports batch fetching and caching optimization. For sources that distribute data in batches (such as key files synchronized daily by an FTP server), the adapter can prefetch data during off-peak hours and cache it locally at the workstation. When the writing process requires it, it can directly read from the cache, significantly reducing the latency of real-time interaction.

[0084] Through the above design, the unified data adaptation layer transforms the originally chaotic multi-source data acquisition process into an orderly, reliable, and efficient standardized input stream, laying a solid foundation for subsequent accurate data pre-aggregation and verification.

[0085] Furthermore, this embodiment introduces a timestamp-based state machine to maintain a data arrival status table for each sequence number and automatically triggers the verification process when data arrives through an asynchronous event-driven mechanism. Data returned by each system enters a temporary buffer at the workstation. The system maintains a data arrival status table for each sequence number and sets a maximum waiting time window linked to the lock lease period to avoid invalid lock resource occupation or data misjudgment due to improper waiting time settings.

[0086] Within this time window, whenever a new data item arrives, the system automatically triggers combined verification logic. Unlike existing technologies that only perform single-field format checks, the verification in this invention is divided into three levels: First, it verifies the format validity and timeliness of a single data item; then, it performs cross-field business rule verification—for example, confirming whether the MAC address belongs to the address pool range associated with the SN segment, whether the CA certificate issuance object matches the current device model, and whether the HDCP key version is consistent with the production batch; finally, it performs context consistency verification to verify whether the current data is consistent with the state of the upstream system (e.g., confirming that the SN has not yet been marked as "produced" in the MES). Only when all data items corresponding to a certain serial number have arrived and all have passed the above three-level verification is the serial number marked as "data ready".

[0087] In one alternative embodiment, verifying the data pushed onto the bus in a standard exchange format further includes:

[0088] Obtain the latest local validation rules, and use these rules to validate data in the standard exchange format:

[0089] If the data verification for the standard exchange format fails within the validity period of the serial number segment lock, the serial number segment lock is actively released, and the exception information is encapsulated into a structured log and reported.

[0090] It is important to note the consistency and real-time synchronization of business rules across systems. Business rules such as SN and MAC mapping rules and CA certificate allocation strategies may be dynamically adjusted according to production plans and need to be consistent across all workstations. If rule synchronization is not timely, it may lead to inconsistent verification results for the same data packet at different workstations.

[0091] To address the aforementioned shortcomings, this embodiment decentralizes the business rule engine to the local workstation. The rules themselves are versioned and synchronized in real time via blockchain or a centralized configuration center. Each time a workstation starts or acquires a lock, the system verifies whether the local rule version is up-to-date, and pulls updates from a trusted source if necessary, thereby ensuring that all workstations perform verifications under the same rule set. During the verification process, the workstation software obtains the latest local verification rules and uses these rules to sequentially perform single-data format validity checks, cross-field business rule checks, and context consistency checks on data in the standard exchange format. If, within the validity period of the serial number segment lock, the data corresponding to a certain serial number cannot reach the data ready state due to incompleteness or failure of any level of verification, the workstation software proactively releases the entire serial number segment lock it currently holds and records the anomaly of that serial number. The information, including missing data items, rules for failed verification, and original data content, is encapsulated into a structured log and reported to the production monitoring system in real time, thereby achieving atomic operations for lock release, anomaly reporting, and workstation status reset. Conversely, if all data items arrive and pass verification, the serial number is marked as data ready. Subsequently, the workstation software performs a substantive writing operation, writing data such as SN, MAC, CA certificate, and HDCP key to the storage area of ​​the digital multimedia terminal via the local bus or a dedicated programming tool. After the writing is completed, a complete original data packet for this operation is generated. This data packet not only contains all the key data written to the device, but also the device chip ID, operation timestamp, workstation ID, and the currently held number segment lock certificate, preparing complete original materials for the subsequent blockchain evidence storage process.

[0092] In one optional embodiment, constructing a notarization transaction containing the IPFS hash address includes:

[0093] Extract key fields from the original data packet, calculate the hash value of the key fields, and form a fingerprint set in the form of key-value pairs;

[0094] Extract the lock credentials of the serial number segment lock to form a process credential;

[0095] Use the IPFS hash address as the data pointer for the evidence storage transaction;

[0096] Obtain business information and use the business information to form a business context; wherein, the business information includes device chip ID hash, operation timestamp, and workstation ID;

[0097] The fingerprint set, the process credential, the data pointer, and the business context are used to construct a notarized transaction.

[0098] It's important to note that after the serial number is written, the system enters the blockchain notarization phase. The core challenge here is that digital multimedia terminal production is a long-cycle, high-volume industrial process. If the complete data packet for each serial number writing operation (potentially containing KB-level certificate information) is written to the blockchain as is, it will cause a rapid expansion of on-chain data, severely slowing down node synchronization speed and transaction processing efficiency, and significantly increasing operating costs. While existing technologies have proposed the concept of "tiered notarization," such as hashing the original data and storing it on-chain while storing the original text off-chain, its application scenarios are mostly concentrated on copyright notarization of static files or judicial evidence preservation. The core purpose is to save storage space and achieve ownership confirmation by replacing the original text with hash values. In this type of solution, the on-chain and off-chain data have a "static mapping" relationship, meaning one hash value corresponds to one original text, and notarization is complete; subsequent use is only for passive verification.

[0099] However, the production and evidence storage scenario of digital multimedia terminals has distinct dynamism and process correlation: evidence storage is not the end point, but a key link in the closed loop of the production process. It needs to be logically linked with pre-concurrency control (distributed lock) and in-process data verification (pre-aggregation), and support the subsequent full life cycle status traceability.

[0100] Existing static hierarchical evidence storage solutions cannot meet this requirement.

[0101] To address the aforementioned shortcomings, this embodiment proposes a dynamic evidence storage mechanism using an on-chain state machine, upgrading evidence storage from passive data archiving to proactive process anchoring. The specific process is as follows: Figure 2 As shown:

[0102] Level 1: Raw Data Layer – IPFS Distributed Storage (see...) Figure 2 (Local software for mid-level workstations)

[0103] After the write operation is completed, key fields responsible for global uniqueness verification are extracted from the generated complete original data packet. These fields include the device serial number (SN), network MAC address, and chip ID. Each key field's hash value is independently calculated using a collision-resistant hash algorithm, forming a unique fingerprint set in key-value pair form. Simultaneously, the lock credential corresponding to the serial number segment lock obtained during the lock application phase is extracted. This credential contains at least the lock ID, the locked serial number segment, the grant timestamp, the lease validity period, and the digital signature of the lock service, serving as the process credential. The globally unique IPFS hash address obtained after encrypting and uploading the original data packet to the IPFS cluster is extracted and used as a data pointer to the first-level original data layer in the evidence storage transaction. Additionally, business information related to this write operation is obtained, including the device chip ID hash, the operation timestamp, and the workstation ID, forming a business context. Finally, the four elements—the unique fingerprint set, the process credential, the data pointer, and the business context—are collectively encapsulated to construct an evidence storage transaction, which is then sent to the blockchain network for verification and evidence storage by a smart contract.

[0104] Level Two: Core Evidence Storage Layer – Blockchain Mainnet (see...) Figure 2 (Middle Blockchain Network)

[0105] In one optional embodiment, a key field for global uniqueness verification is extracted from the original data packet, and the hash value of the key field is calculated to form a fingerprint set in key-value pair form, including:

[0106] According to the preset business rule base, the fields that must be globally unique for the current device type are identified from the original data packet as key fields; wherein, the key fields include hardware serial number, network MAC address, chip ID and security chip public key hash;

[0107] A collision-resistant hashing algorithm is used to independently hash the original value of each key field to generate a unique fingerprint;

[0108] The unique fingerprint is incorporated into the transaction data structure in the form of key-value pairs to form a fingerprint set.

[0109] When calculating the hash values ​​of key fields to form a fingerprint set in key-value pair format, the system first identifies fields from the generated complete raw data packets that must be globally unique for the current device type, based on a pre-defined business rule base. These key fields include the hardware serial number (SN), network MAC address, chip ID, and the public key hash of the security chip. Then, collision-resistant hashing algorithms such as SHA-256 are used to independently hash the original value of each key field. For example, the hash value of the string-formatted serial number is calculated separately, generating unique fingerprints such as hash_sn and hash_mac. Finally, these independently calculated unique fingerprints are incorporated into the transaction data structure in key-value pair format, for example, in the format sn_hash:0x3f2a... and mac_hash:0x8c7b..., thus forming a fingerprint set that can be used by smart contracts for global deduplication verification by field. This achieves a design leap from "file ownership confirmation" to "global deduplication of key fields," fundamentally solving the granularity mismatch problem of traditional "overall hash notarization" in industrial deduplication scenarios. In existing technologies, if the entire data packet (including variable information such as CA certificates and HDCP keys) is hashed and uploaded to the blockchain, the overall hash value will differ even if the SN and MAC are exactly the same, because the serial number or validity period of the CA certificate may change with each batch. This prevents smart contracts from detecting duplicate SNs or MACs by comparing the overall hash. This patent addresses this by decomposing the unique field into an independent fingerprint, enabling smart contracts to accurately perform global deduplication checks by field, thus completely eliminating the last loophole for data duplication at the evidence storage stage.

[0110] In one optional embodiment, extracting the lock credential of the serial number segment lock includes:

[0111] The lock credentials include: a globally unique lock ID, a lock number range, an grant timestamp, a lease validity period, and a digital signature for the lock service;

[0112] The lock certificate is encapsulated as a process certificate into the evidence storage transaction.

[0113] Specifically, when constructing the process credential, the distributed lock service first returns a cryptographically signed lock credential when the workstation software successfully acquires the sequence number range lock. This credential is a structured data packet that includes at least a globally unique lock ID, the locked sequence number range such as SN10001 to SN10100, the grant timestamp, the lease validity period, and the digital signature of the lock service. Subsequently, when the workstation software constructs the evidence storage transaction, the complete lock credential is encapsulated intact into the process credential field of the transaction body for subsequent smart contract verification and status checking.

[0114] When constructing the data pointer, the workstation software first performs symmetric encryption on the complete original data packet containing all key data, certificates, and keys. The encryption key can be derived from the workstation ID and chip ID. Then, the encrypted data packet is uploaded to the IPFS network, and IPFS returns a globally unique hash address based on content addressing. Subsequently, the workstation software uses this IPFS hash address as the data pointer field and encapsulates it together with the unique fingerprint, process credential, etc., into an on-chain transaction. Only the pointer is stored on the chain, not the original data. This achieves the authenticity of the core fingerprint on the chain and the quantity of the original data off the chain, while compressing the on-chain storage cost by more than two orders of magnitude. Moreover, during auditing, the encrypted data packet can be obtained from IPFS through this pointer and decrypted for traceability.

[0115] When constructing evidence storage transactions, business context is further embedded as a metadata layer to make the evidence storage records searchable and business readable: First, the device chip ID is obtained and its hash value is calculated as a physical, non-clonable identifier for the device, used to associate subsequent lifecycle events such as activation, maintenance, and scrapping with the current production event; at the same time, a trusted time source, such as an NTP server, is used to synchronously and accurately record the writing completion time as an operation timestamp, used to verify the timeliness of process vouchers and construct the event sequence; and the specific production line workstation ID that performed the writing operation is identified, facilitating the tracing of quality issues back to the specific production unit; in addition, optional batch information such as production order number or batch number can be extended to facilitate statistical analysis by batch; by embedding the chip ID hash, cross-event association with the device as the primary key is realized, so that no matter which stage of the device generates a new event, a trusted link can be established with the current production evidence storage through the chip ID hash, ultimately forming a complete and tamper-proof device lifecycle chain on the chain. At the same time, the addition of workstation ID and timestamp allows managers to directly perform multi-dimensional penetrating queries on the chain, thereby upgrading evidence storage data from isolated data points to an effective tool supporting full lifecycle traceability and auditing.

[0116] In one optional embodiment, sending the notarized transaction to the blockchain for verification and notarization includes:

[0117] The digital signature of the lock service is verified using the public key of the lock service.

[0118] The validity of the evidence-based transaction is verified by the lease term;

[0119] Verify the consistency between the locked number segment and the serial number range implied by the unique fingerprint.

[0120] In the on-chain signature verification and status verification process, after receiving the notarized transaction, the smart contract first uses the public key of the lock service to verify the digital signature in the process certificate, confirming that the certificate has not been tampered with and was issued by the trusted lock service. Subsequently, the contract parses the certificate content, verifies whether the current on-chain time is still within the lease validity period, and checks whether the serial number range declared in the certificate is consistent with the serial number range implied by the unique fingerprint in the transaction. This mechanism solves the problem of the separation between behavior and record that is common in existing blockchain notarization schemes. In theory, anyone can construct a transaction with a valid SN and write it to the blockchain without a process certificate, resulting in a chaotic record where the data is genuine but the process is illegal. By putting the lock certificate on the chain, the causal relationship is solidified, and the on-chain record can prove that the data was written under the premise of holding a specific lock and authorized by concurrency control. At the same time, double-blind anti-counterfeiting is achieved. Even if an attacker steals the data, if they cannot obtain the signature certificate of the corresponding lock service at the same time, the transaction they construct cannot pass the smart contract verification, thus preventing illegal data injection from the source.

[0121] Level 3: Fast Index Layer – Off-chain Index Database (see...) Figure 2 (Middle-chain index database)

[0122] Furthermore, to address the issue of retrieval efficiency based on blockchain under massive data, this embodiment constructs an independent off-chain index database that can be periodically snapshotted for evidence storage. This database establishes a two-level mapping relationship from device chip ID to on-chain transaction ID, and records the current production status of the device, such as written number, activated, or returned for repair. When auditing is required, the on-chain transaction ID can be located in the off-chain database in milliseconds through the chip ID, and then the IPFS address can be obtained from the blockchain through the transaction ID to finally retrieve the original data, thus achieving a balance between auditing efficiency and on-chain storage pressure.

[0123] In the aforementioned three-tier architecture, the blockchain in the core evidence storage layer does not passively receive data. Instead, it dynamically interacts with the production process through finite state machine smart contracts. Each contract maintains a specific state machine for each sequence number, such as idle, locked, written, and activated. Its verification logic is tightly coupled with state transitions: When the contract is triggered, it first verifies the legitimacy of the workstation submitting the transaction, then checks the validity of the lock certificate to confirm that the workstation does indeed hold the lock for the sequence number segment to be operated on. This anchors the on-chain evidence storage and off-chain locking services at the logical level, ensuring that only production behaviors that have undergone concurrency control can be recorded. Next, the contract queries the on-chain history records, comparing the core fields such as SN hash and MAC hash in the data packets to see if they already exist on the chain, performing a final uniqueness check in a decentralized environment. Finally, it verifies the validity of the IPFS hash address format in the transaction. Only after passing all the above checks will the smart contract update the state of the corresponding sequence number on the chain from locked to written, and package this transaction into a new block for consensus in the entire blockchain network. Thus, a complete write operation is permanently recorded, forming an immutable digital birth certificate.

[0124] Through the above mechanism, the method provided in this embodiment minimizes the storage pressure on the main chain while ensuring that the core verification logic is immutable and traceable. At the same time, it achieves deep coupling between evidence storage records and production processes, building an indisputable and trustworthy digital archive for each digital multimedia terminal that leaves the factory, spanning the entire life cycle.

[0125] Furthermore, after successful notarization, the workstation software proactively sends a lock release request to the distributed lock service, returning the currently held serial number segment so that it can be used by other workstations. Simultaneously, the system writes the mapping relationship between the chip ID and the on-chain transaction ID of this operation into the off-chain index database, facilitating rapid auditing and location later. This completes the closed-loop process for writing serial numbers to a digital multimedia terminal. When subsequent auditing is required, auditors can quickly locate the corresponding on-chain transaction ID in the off-chain index database using the device chip ID, obtain the IPFS hash address from the blockchain using the transaction ID, and finally retrieve the complete original data packet from the IPFS network for verification. This mechanism ensures the core verification logic is secure. The immutability of the system minimizes the storage pressure on the main chain, achieving a balance between security and efficiency. To further enhance the robustness of the system, more complex logic can be introduced into the smart contract, such as integrating multi-signatures from different business parties to ensure the authority of the evidence, or establishing a dynamic blacklist mechanism to automatically intercept evidence requests from abnormal workstations. The entire system controls the entry point of concurrency through hierarchical locking, ensures the accuracy of business logic through data pre-aggregation, controls the unique exit of data through state machine smart contracts, and leaves an indelible mark on the blockchain through hierarchical evidence storage. Thus, the system ensures the global uniqueness and strong binding relationship of key data of digital multimedia terminals from the beginning of production through a four-in-one approach.

[0126] Example 2

[0127] Embodiment 2 of the present invention provides a key data binding system based on hierarchical locks and blockchain, comprising:

[0128] The tiered lock application and dynamic lease establishment module is used to initiate lock application requests to the distributed lock service. When a successful response is received, a dynamic lease mechanism is established and a sequence number segment lock is acquired.

[0129] The multi-source data acquisition module is used to initiate batch data retrieval requests to each upstream system based on the serial number segment lock to acquire multi-source data;

[0130] The local writing module is used to perform writing operations on the multi-source data to generate the original data packet;

[0131] The hierarchical evidence storage and on-chain state machine verification module is used to encrypt and upload the original data packet to the IPFS cluster, obtain the globally unique IPFS hash address, construct an evidence storage transaction containing the IPFS hash address, and send the evidence storage transaction to the blockchain for verification and evidence storage.

[0132] The lock release module is used to initiate a lock release request to the distributed lock service after the evidence is stored, and to return the sequence number segment lock.

[0133] Example 3

[0134] Figure 3 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the electronic device includes a processor 21, a memory 22, an input device 23, and an output device 24; the number of processors 21 in the computer device can be one or more. Figure 3 Taking a processor 21 as an example; the processor 21, memory 22, input device 23, and output device 24 in an electronic device can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0135] The memory 22, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules. The processor 21 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 22, thereby implementing the key data binding method based on hierarchical locks and blockchain in Embodiment 1.

[0136] The memory 22 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. In some instances, the memory 22 may further include memory remotely located relative to the processor 21, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0137] Input device 23 can be used to receive user input such as ID and password. Output device 24 is used to output the network configuration page.

[0138] Example 4

[0139] Embodiment 4 of the present invention also provides a computer-readable storage medium, wherein the computer-executable instructions, when executed by a computer processor, are used to implement the key data binding method based on hierarchical locks and blockchain as provided in Embodiment 1.

[0140] The storage medium containing computer-executable instructions provided in the embodiments of the present invention is not limited to the method operation provided in Embodiment 1, but can also execute related operations in the key data binding method based on hierarchical locks and blockchain provided in any embodiment of the present invention.

[0141] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A key data binding method based on hierarchical locks and blockchain, characterized in that, include: Initiate a lock request to the distributed lock service. Upon receiving a successful response, establish a dynamic lease mechanism and acquire a sequence number segment lock. Based on the serial number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data; The multi-source data is written to generate the original data packet; The original data packet is encrypted and uploaded to the IPFS cluster to obtain a globally unique IPFS hash address. A notarization transaction containing the IPFS hash address is constructed, and the notarization transaction is sent to the blockchain for verification and notarization. After the evidence is stored, a lock release request is sent to the distributed lock service, and the sequence number segment lock is returned.

2. The key data binding method based on hierarchical locks and blockchain according to claim 1, characterized in that, Based on the sequence number segment lock, a batch data retrieval request is initiated to each upstream system to obtain multi-source data, including: A unified data adaptation layer is constructed, which includes a three-layer architecture of adapter, converter and bus; The adapter obtains raw data from the upstream system and transmits the raw data to the converter. The converter automatically selects a parser and mapping rules based on the data source identifier, converts the raw data to a standard exchange format, and pushes the data in the standard exchange format onto the bus; The data pushed onto the bus in the standard exchange format is verified, and the verified data is used as multi-source data.

3. The key data binding method based on hierarchical locks and blockchain according to claim 2, characterized in that, Verification of data in the standard exchange format pushed onto the bus also includes: Obtain the latest local validation rules, and use these rules to validate data in the standard exchange format: If the data verification for the standard exchange format fails within the validity period of the serial number segment lock, the serial number segment lock is actively released, and the exception information is encapsulated into a structured log and reported.

4. The key data binding method based on hierarchical locks and blockchain according to claim 1, characterized in that, Constructing a notarization transaction containing the IPFS hash address includes: Extract key fields from the original data packet, calculate the hash value of the key fields, and form a fingerprint set in the form of key-value pairs; Extract the lock credentials of the serial number segment lock to form a process credential; Use the IPFS hash address as the data pointer for the evidence storage transaction; Obtain business information and use the business information to form a business context; wherein, the business information includes device chip ID hash, operation timestamp, and workstation ID; The fingerprint set, the process credential, the data pointer, and the business context are used to construct a notarized transaction.

5. The key data binding method based on hierarchical locks and blockchain according to claim 4, characterized in that, Extract key fields for global uniqueness verification from the original data packet, calculate the hash value of the key fields, and form a fingerprint set in key-value pair form, including: According to the preset business rule base, the fields that must be globally unique for the current device type are identified from the original data packet as key fields; wherein, the key fields include hardware serial number, network MAC address, chip ID and security chip public key hash; A collision-resistant hashing algorithm is used to independently hash the original value of each key field to generate a unique fingerprint; The unique fingerprint is incorporated into the transaction data structure in the form of key-value pairs to form a fingerprint set.

6. The key data binding method based on hierarchical locks and blockchain according to claim 5, characterized in that, Extracting the lock credentials for the serial number segment lock includes: The lock credentials include: a globally unique lock ID, a lock number range, an grant timestamp, a lease validity period, and a digital signature for the lock service; The lock certificate is encapsulated as a process certificate into the evidence storage transaction.

7. The key data binding method based on hierarchical locks and blockchain according to claim 6, characterized in that, Sending the evidence-stored transaction to the blockchain for verification and evidence storage includes: The digital signature of the lock service is verified using the public key of the lock service. The validity of the evidence-based transaction is verified by the lease term; Verify the consistency between the locked number segment and the serial number range implied by the unique fingerprint.

8. A key data binding system based on hierarchical locks and blockchain, used to implement the key data binding method based on hierarchical locks and blockchain as described in any one of claims 1 to 7, characterized in that, include: The tiered lock application and dynamic lease establishment module is used to initiate lock application requests to the distributed lock service. When a successful response is received, a dynamic lease mechanism is established and a sequence number segment lock is acquired. The multi-source data acquisition module is used to initiate batch data retrieval requests to each upstream system based on the serial number segment lock to acquire multi-source data; The local writing module is used to perform writing operations on the multi-source data to generate the original data packet; The hierarchical evidence storage and on-chain state machine verification module is used to encrypt and upload the original data packet to the IPFS cluster, obtain the globally unique IPFS hash address, construct an evidence storage transaction containing the IPFS hash address, and send the evidence storage transaction to the blockchain for verification and evidence storage. The lock release module is used to initiate a lock release request to the distributed lock service after the evidence is stored, and to return the sequence number segment lock.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the key data binding method based on hierarchical locks and blockchain as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the key data binding method based on hierarchical locks and blockchain as described in any one of claims 1 to 7.

Images