Blockchain-based digital product verification method and related device

Abstract

This application provides a blockchain-based digital product verification method and related equipment, enabling decentralized third parties to perform tamper-proof and auditable automated verification of the identity and ownership of digital products. The method includes: extracting features from digital product data and encrypting and encoding them to generate a product identifier and corresponding product description metadata; digitally signing the product identifier and product description metadata based on the issuer's identity and constructing blockchain data to generate smart contract data corresponding to the digital product data; verifying the compliance of product operation request instructions based on the smart contract data; and modifying the smart contract data according to the verified product operation request instructions.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based digital product verification method and related equipment. Background Technology

[0002] The verification requirements for digital products aim to ensure that each digital asset can be uniquely identified, its integrity verifiable, its provenance and time traceable, its ownership attributable, and that it is auditable and protected against reuse during circulation / cancellation. Simultaneously, the verification process should be independently executable and low-latency for ordinary verifiers, without relying on real-time responses from the issuer. For privacy-sensitive scenarios, it should also support the verification of ownership or usage eligibility without disclosing sensitive information of the parties involved. Furthermore, the verification mechanism must possess cross-platform / cross-system interoperability, tamper-resistant and scalable engineering characteristics, and have a certain tolerance for common transformations such as format conversion or lossless compression, or a reproducible standardized processing procedure.

[0003] Existing digital product verification methods primarily rely on centralized or semi-centralized technologies, including database records and transaction logs maintained by the issuer or platform, PKI-based digital signature and certificate systems (CA certificates, TSA timestamps), dedicated DRM / license servers controlling access and verification, content recognition based on watermarking, perceptual hashing, and fingerprinting technologies, and proof / evidence provided by trusted third-party services (such as notarization / timestamping services). These methods typically determine authenticity and ownership by querying or comparing signatures / fingerprints with a central service provider, or by using embedded watermarks to trace the source and tampering at the content layer.

[0004] Existing verification methods rely excessively on trusted third parties or single-point records, lacking independent verifiability with minimal trust: when the issuer or third-party service is unavailable, compromised, or records are colluded to modify, the verification result cannot be independently confirmed; watermarks and perceived hashes are vulnerable to format changes, and PKI / CA models have practical problems with certificate revocation and cross-domain trust chains, making it difficult to simultaneously meet the requirements of immutability, decentralized verifiability, and privacy protection. Summary of the Invention

[0005] This application provides a blockchain-based digital product verification method and related equipment, which enables tamper-proof and auditable automated verification of the identity and ownership of digital products without the need for a centralized third party.

[0006] Firstly, this application provides a blockchain-based digital product verification method, the method comprising: The received digital product data is subjected to feature extraction and encryption encoding to generate product identifiers and corresponding product description metadata. Based on the received issuer identity identifier, the product identifier and the product description metadata are digitally signed and blockchain data is constructed to generate smart contract data corresponding to the digital product data; The received product operation request instruction is verified for compliance based on the smart contract data, and the smart contract data is modified according to the verified product operation request instruction.

[0007] In one possible implementation, the step of performing feature extraction and encryption encoding on the received digital product data to generate a product identifier and corresponding product description metadata includes: The received digital product data is divided into data blocks and the hash value of each data block is calculated using a preset binary stream method to form the first feature sequence. The digital product data is semantically parsed based on its data attributes to extract a second feature sequence; Based on the preset product description data type, descriptive metadata is extracted and structured description is performed on the digital product data to generate a third feature sequence; The first feature sequence, the second feature sequence, and the third feature sequence are serialized, concatenated, and hashed to generate a product identifier. The first feature sequence, the second feature sequence, and the third feature sequence are encapsulated to generate product description metadata.

[0008] In one possible implementation, the step of digitally signing and constructing blockchain data for the product identifier and product description metadata based on the received issuer identity identifier, and generating smart contract data corresponding to the digital product data, includes: The preset product issuance marker, preset blockchain address, recorded current timestamp, product identifier, and product description metadata are encapsulated into issuance declaration data; The issuance statement data is digitally signed using the received issuance private key to generate digital identity data corresponding to the issuance statement data; The issuance statement data and the digital identity data are verified by consensus nodes in a pre-defined blockchain network, checking their data format and signature data. Once the issuance statement data and the digital identity data are verified, the issuance statement data and the digital identity data are encapsulated according to the preset contract format and the product identifier using a preset mapping storage strategy to generate smart contract data corresponding to the digital product data.

[0009] In one possible implementation, when the product operation request instruction is a preset transaction instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received transaction instructions are parsed to obtain the transaction product identifier, ownership proof data, and transferee data; Based on the transaction product identifier, the corresponding smart contract data is obtained from the blockchain network, and the disposal permission of the transaction instruction is verified based on the smart contract data and the ownership proof data. When the ownership data in the smart contract data is consistent with the ownership proof data, the ownership data is changed to the transferee data, and an ownership change record is generated according to the preset change record method.

[0010] In one possible implementation, when the product operation request instruction is a preset verification instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received reconciliation instruction is parsed to obtain the reconciliation product identifier, the reconciliation party's voucher, and the reconciliation parameters; Based on the product verification identifier, obtain the corresponding smart contract data from the blockchain network, and then obtain the corresponding product current status data from the blockchain network based on the smart contract data; The verification mechanism uses a preset verification mechanism to perform multi-factor condition verification on the verification instruction based on the current status data of the product, the verification party's credentials, and the verification parameters. Once the verification instruction is verified, the current status data of the product is changed to the preset verified status data according to the preset verification method.

[0011] In one possible implementation, when the product operation request instruction is a preset cross-chain verification instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received cross-chain verification command is parsed to obtain the cross-chain product identifier, the target chain network identifier, the state type to be synchronized, and the cross-chain request authorization credential. Based on the cross-chain product identifier and the target chain network identifier, obtain the corresponding smart contract data from the target blockchain network; Based on the smart contract data, the type of state to be synchronized and the cross-chain request authorization certificate are authorized and verified. Once the cross-chain verification instruction passes verification, the corresponding target chain state data and inter-chain cryptographic proof are obtained from the target blockchain network according to the type of state to be synchronized. Once the inter-chain cryptographic proof is successfully verified through the preset cross-chain verification protocol, the target chain state data is written into the smart contract data according to the type of state to be synchronized.

[0012] Secondly, this application provides a blockchain-based digital product verification device, the device comprising: The product parsing module is used to extract features and encrypt the received digital product data to generate product identifiers and corresponding product description metadata. The issuance storage module is used to digitally sign and construct blockchain data for the product identifier and the product description metadata based on the received issuer identity identifier, and generate smart contract data corresponding to the digital product data; The request verification module is used to perform compliance verification on the received product operation request instruction based on the smart contract data, so as to modify the smart contract data according to the verified product operation request instruction.

[0013] In summary, this application includes at least the following beneficial technical effects: 1. By serializing and hashing multidimensional feature sequences to generate product identifiers, and by putting description hashes and issuance statements on the blockchain, the product identity and metadata are guaranteed to be immutable once registered, and their originality and integrity can be independently verified at any time.

[0014] 2. By leveraging issuer signatures, smart contract mapping, and compliance verification processes (including transaction permission verification and multi-factor write-off), automated atomic operations for ownership changes and write-offs are achieved, preventing reuse and fraud, and leaving auditable on-chain traces.

[0015] 3. By using cross-chain verification commands, inter-chain cryptographic proofs, and target chain state synchronization, the system breaks down inter-chain silos, enabling digital products registered on different chains to be trusted and used by entities on different chains, thereby expanding the system's applicability and mutual trust capabilities. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a blockchain-based digital product verification method provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a blockchain-based digital product verification device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of the computing device provided in the embodiments of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. With the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0018] The terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the description of embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but includes other elements not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] like Figure 1 The diagram shown is a flowchart illustrating a blockchain-based digital product verification method provided in this application embodiment. The blockchain-based digital product verification method provided in this application embodiment includes the following steps.

[0020] Step S1: Extract features and encrypt the received digital product data to generate product identifiers and corresponding product description metadata.

[0021] It should be understood that digital product data refers to the most original and unobfuscated or uncompressed core source files and authoritative information collection upon which digital goods rely during the creation and distribution stages, constituting a complete data package for an independent digital product. For example, for a specific mobile data package product, its data includes the original configuration data file provided by the operator, defining the package's capacity (e.g., 10GB nationwide data), validity period, applicable network (4G / 5G), and pricing rules; for a short drama digital content product, it includes its highest quality video source files, associated copyright statement text, drama metadata (e.g., drama title, number of episodes, lead actors), and the authorization terms document specified by the distributor. The distributor uploads the aforementioned internally reviewed and confirmed original files and information entries to this verification system through a secure management backend, signifying that the corresponding digital product needs to undergo digital identity registration.

[0022] First, based on the core requirement of digital goods anti-counterfeiting (i.e., the ability to detect illegal tampering at any byte level in the source file), this application adopts a preset binary stream method to treat the digital product data of digital goods as a continuous binary stream, and cuts it into a series of sequentially arranged data blocks of a fixed size (e.g., every 1024 bytes). For each independent data block, a cryptographic hash function (e.g., SHA-256) is further used to calculate a fixed-length, unique hash value. Then, the hash values ​​corresponding to each data block are sorted and concatenated according to the original data block order to form an ordered first feature sequence. The first feature sequence is like a precise "binary map" of the source file. Any minor modification to the content of the source file—for example, maliciously tampering with the traffic value in the traffic package configuration file from "10GB" to "20GB"—will cause a change in the binary content of at least one data block, resulting in a cascading change in the hash value of that data block and its potentially affected subsequent data blocks. Therefore, the first feature sequence provides a low-level, sensitive mathematical proof for the integrity of the product.

[0023] Simultaneously, to transcend the binary level, the essential characteristics of digital goods are captured from the semantic level, as understood and used by humans or business systems. This addresses legitimate processing methods that alter the binary form without changing the semantics, such as file format conversion or lossless compression. In this application's embodiments, the corresponding parser is invoked based on the type of uploaded data: for short drama video files, the parser extracts image feature vectors from keyframes, analyzes the voiceprint features of the audio track, and generates keyword vectors describing the plot; for mobile phone plan configuration data, the parser extracts and quantifies key business parameters, such as tariff values, data allowances, and rate limits. These features, parsed from the original data and representing the core meaning of the product, are aggregated and standardized to form a second feature sequence. Through these operations, even if the same data uses different formats (e.g., the same short drama converted from AVI to MP4), its content feature vectors remain highly similar, ensuring that semantically based product identification maintains consistency and recognizability across technical formats.

[0024] Meanwhile, to further focus on the external information attached to digital goods and authoritatively declared by the issuer, this application embodiment extracts a series of structured metadata from digital product data based on a pre-defined product description data type. For traffic-based digital goods, this includes, but is not limited to: the official name of the product (e.g., "Monthly 10GB Unlimited Play Package"), the digital certificate identifier of the issuer (e.g., AAA Corporation), creation / release date, version number, applicable copyright agreement number, and target sales region code. This information is required to be formatted according to a predefined schema to generate a machine-readable structured document, which itself constitutes a third feature sequence. Through the above operations, authoritative statements from legal, commercial, and regulatory perspectives are strongly bound to the technical characteristics of the product, so that the digital identity of the product not only includes "what" (technical characteristics) but also clarifies "who issued it, when, and under what name" (ownership and compliance information), providing a legally significant digital document for transaction verification and ownership tracing. The product description data type is a predefined and strictly structured metadata classification and format specification system. This system is specifically designed to guide and standardize the extraction, classification, and formatting of authoritative data describing the product's external attributes, ownership, commercial terms, and compliance information from the core original files of digital products. Product description data types include, but are not limited to: The first category is basic identification information, which includes the full product name officially named by the issuer (e.g., "5G Unlimited Monthly Package - 30GB Targeted Data"), a unique product code in the issuer's internal management system, and a version identifier used in marketing. The second category is ownership and source information, which mandates binding to the issuer's legal identity, such as using a digital certificate certified by an authoritative institution to identify the legal entity "AAA Co., Ltd.", and recording the product's initial generation or approved release timestamp within the system. The third category is commercial and regulatory information. For data package products, this type of data precisely describes its core service content, such as the total data allowance, whether it is nationwide, the speed limit, which specific apps it is bundled with (e.g., targeted data packages), and the specific start and end dates of its validity. For short drama content products, it includes copyright holder information, the scope of licensed use, and permitted playback terminal types. The fourth category is technical feature association information. This type of data aims to associate descriptive metadata with the technical feature sequence (such as the first and second feature sequences) generated in the preceding steps. For example, it records the data block size parameter used when generating the first feature sequence, or the semantic parsing model version number used when generating the second feature sequence, to ensure the reproducibility and auditability of the entire digital identity generation process.

[0025] After obtaining the feature sequences from the three dimensions mentioned above, the three sequences are first serialized and encoded according to a public and immutable rule (e.g., in the order of third, second, and first), transforming them into a single, longer composite byte stream. Subsequently, a hash function with higher encryption strength (e.g., SHA-512) is applied to the composite byte stream. This one-way hash function cohedes all the information from the three sequences into a fixed-length, unique digital fingerprint. Any tampering with the original product data or its metadata will alter at least one of the feature sequences, resulting in a discrepancy between the final calculated product identifier and the officially recorded identifier. This makes the product identifier an indisputable and unique technical identity card for the digital product globally.

[0026] Finally, a structured, self-describing digital product profile is created. The three feature sequences, along with their serialization format descriptions, hash algorithm identifiers, and other information, are encapsulated into a complete description file using a standard, interoperable data format (such as JSON-LD). This description file itself is also hashed (Description File Hash, DFH). The resulting product description metadata is a structured description file containing all the original feature sequence data and its own integrity check value (DFH). This product description metadata serves as the "source code" of the product identifier and the "reference standard" for verification, and is securely stored or publicly accessible. When verifying a digital product, the verifier can re-execute the standardized calculation process using the original feature sequences in this description metadata. If the same product identifier can be reproduced, it proves that the product is completely consistent with the product initially registered by the issuer, thus completing a closed loop from original data to a trusted digital identity.

[0027] Step S2: Based on the received issuer identity identifier, digitally sign the product identifier and the product description metadata and construct blockchain data to generate smart contract data corresponding to the digital product data.

[0028] The issuer's identity includes the issuer's private key, a top-secret cryptographic key held by the issuer on the blockchain network, representing its legal and technical identity. This private key is not shared with any server and is controlled solely by the issuer through a secure hardware module or encrypted container. To achieve public-key cryptography-based authentication and non-repudiation, ensuring that subsequent ownership claims can only be cryptographically performed by the holder of the private key, and that no other party can impersonate them, a series of elements are then encapsulated into issuance claim data. These elements include a pre-defined marker indicating that this operation is for the issuer and not other types of product issuance; a publicly available blockchain address derived from the public key corresponding to the issuer's private key, similar to a company's public bank account; a current timestamp accurate to milliseconds recorded by the system when the operation is triggered; and the product identifier and product description metadata obtained in step S1 above. This information is packaged into a release statement to create a complete and clearly defined "digital product birth certificate," where the product identifier is the product's fingerprint, the descriptive metadata is the product's structured profile, and the issuer's address and timestamp clarify "who" and "when" claimed to have created it.

[0029] Next, a digital signature is calculated on the issuance statement data based on the received issuing private key. First, a hash value is calculated on the complete content of the issuance statement data, resulting in a fixed-length digest. Then, this digest is encrypted using the issuer's strictly confidential issuing private key (e.g., using the Elliptic Curve Digital Signature Algorithm ECDSA). The result of this operation is a unique string of digital identity data, i.e., a digital signature. This signature is mathematically uniquely bound to the content of the statement data and the issuer's private key. Through the above operations, the following can be achieved: first, integrity verification—any tampering with the bytes of the statement data will cause signature verification to fail; second, identity authentication and non-repudiation—since only the corresponding private key can generate a signature that can be successfully verified by its public key, once the signature is generated and made public, the company cannot deny that it issued this statement. For example, when registering a newly launched short drama, this signature permanently locks the digital identity of the short drama with the issuer.

[0030] Subsequently, the digitally signed issuance statement data obtained through the above operations is broadcast as a special transaction to a pre-defined blockchain network. Consensus nodes in the network (such as proof-of-stake validators) rigorously verify the data. Verification consists of two main parts: first, data format verification, ensuring the transaction structure conforms to the blockchain protocol specifications and that all fields are complete and valid; second, and more crucially, signature data verification. Each node independently uses a public key paired with the issuer's private key (which can be derived from the issuer's blockchain address or obtained from the transaction) to decrypt the signature, obtaining digest A from the signature, and simultaneously recalculates the hash value of the received issuance statement data to obtain digest B. The nodes then compare digest A with digest B. Verification is considered successful only if both are completely identical. Through the above operations, the registration and binding between the issuer and the digital product no longer relies on the company's own claims or records in a centralized database, but is jointly reviewed and confirmed by numerous independent nodes worldwide according to publicly available cryptographic rules, thus transforming single-point trust into an objective fact guaranteed by network-wide consensus.

[0031] Once the issuance declaration data and digital identity data successfully pass the network-wide consensus verification, they will be packaged into a new block and become permanent. Through a pre-defined mapping storage strategy, based on a pre-defined contract format and product identifier, the declaration and signature data are encapsulated to generate the final smart contract data. Here, the "mapping storage strategy" is not a simple storage instruction, but rather a state storage logic designed within the blockchain smart contract. Specifically, it calls a function in a smart contract deployed on the chain specifically for product registration. Upon receiving the verified transaction data, this function executes the core logic: using the product identifier (PRH) as a globally unique query key, it creates or updates a corresponding record in the smart contract's state storage space. The content (value) of this record follows a pre-defined contract format, typically including at least the issuer's blockchain address, the hash value of the product description metadata, and the product issuance timestamp. The encapsulation process can be conceptually understood as establishing an index in an immutable, public distributed ledger (smart contract state): Key: Product Identifier — Value: {Address A, Description File Hash: Hash(DF), Issuance Time: T}. For example, through the aforementioned operation, the product identifier of the "20GB monthly general data package" is permanently mapped in the blockchain's smart contract to the company's address and the hash of the data package's description file. The generated smart contract data is a decentralized, authoritative "identity card" registry created for digital products. This registry is automatically managed by code, globally verifiable, and cannot be unilaterally tampered with by anyone. Subsequently, in any situation requiring verification of the data package's authenticity or ownership, such as user confirmation of ownership after purchase or inventory checks by partners, there is no need to contact the company's centralized server; simply querying the blockchain smart contract to verify whether the issuer information corresponding to the product identifier matches the official information is sufficient.

[0032] Step S3: Perform compliance verification on the received product operation request instruction based on the smart contract data, and modify the smart contract data according to the verified product operation request instruction.

[0033] Upon receiving a product operation request instruction, it's crucial to analyze the instruction to identify its type, given the fundamental differences in compliance logic, required data elements, and ultimate modifications to smart contract data across different types of requests. By examining specific fields within the instruction structure, it's routed to the correct, highly specialized verification process branch, ensuring complex verification logic can be effectively implemented. This field explicitly declares the intent category of the request, such as "ownership transfer" (corresponding to a transaction instruction), "consumption verification" (corresponding to a reimbursement instruction), or "cross-chain state synchronization" (corresponding to a cross-chain verification instruction).

[0034] Upon receiving a pre-defined transaction instruction, the verification process for the transfer of ownership of digital goods is triggered. First, the system parses the received transaction instruction, separating the transaction product identifier, ownership proof data, and transferee data. Taking user A transferring a "monthly movie membership" to user B as an example, the transaction product identifier is the unique hash value of the membership; the ownership proof data is a cryptographic credential (such as a digital signature) generated by user A using their private key to prove their current ownership of the membership; and the transferee data is user B's blockchain receiving address. The structured input necessary for verification and change operations is extracted through data parsing. Next, using the transaction product identifier as a query key, the latest smart contract data is retrieved in real-time from the blockchain network. The current officially registered owner (ownership data) of the membership is read from the decentralized ledger, serving as the benchmark for determining the legality of the transaction. Subsequently, this embodiment employs cryptographic comparison to verify the disposal authority of the transaction instruction based on the smart contract data and ownership proof data. For example, user A's public key (which can be derived from their blockchain address or transaction instructions) is used to decrypt the signature in the ownership proof data, obtaining a digest. Simultaneously, the hash of the relevant content in the transaction instructions is calculated to obtain another digest, and the two are compared for consistency. More importantly, it is necessary to compare whether the address of user A verified by the signature matches the "ownership data" (i.e., the owner's address) currently recorded in the smart contract data. This ensures that only the current true owner of the goods in a legal and technical sense can initiate a valid transfer, preventing theft or fraudulent sales at the source. When the ownership data in the smart contract data matches the ownership proof data, confirming that user A has the legal right to dispose of the goods, the value of the "ownership data" field in the smart contract data is changed from user A's address to user B's address by calling the pre-built ownership transfer function in the blockchain smart contract. Simultaneously, according to the preset change recording method, the hash, timestamp, and addresses of both parties in this transfer transaction are written to the blockchain as a permanent ownership change record (event log). Through the above operations, not only is the transfer of ownership completed, but a publicly auditable and tamper-proof transaction history chain is also formed.

[0035] When a pre-defined redemption instruction is received, it corresponds to the scenario where the digital goods are ultimately consumed or used. The system obtains the redemption product identifier, the redeemer's credentials, and redemption parameters. For example, if a user holds a "convenience store coupon" issued by AAA company, the redemption product identifier is the coupon's digital ID; the redeemer's credentials are the signature of the convenience store's POS system's authorized private key; and the redemption parameters may include the consumption time, store geolocation code, etc. Data parsing clarifies "what is redeemed," "who is redeeming," and "under what conditions." Subsequently, the blockchain is queried based on the redemption product identifier to obtain the corresponding smart contract data, and further, from or through related queries, the current status data of the product is obtained, such as whether the coupon is "unused" or "used." The purpose of obtaining this status data is to prevent the goods from being reused, which is crucial to ensuring the scarcity and value of digital goods. Next, the preset verification mechanism adopted in this application embodiment is an integrated logic judgment engine: First, it verifies whether the current status of the product is "unused"; second, it verifies the validity of the verification party's credentials, that is, confirms whether the convenience store initiating the verification is a legitimate verification point authorized by AAA Company; finally, it verifies whether the verification parameters conform to preset rules, such as whether the consumption time is within the coupon's validity period, or whether the store location is within the permitted usage area. Only when all conditions are met is the verification considered successful. Business rules (such as validity period, geographical restrictions) are encoded into automatically executable code to ensure that every verification is strictly compliant. After the verification instruction passes all verifications, according to the preset verification method, the smart contract's verification function is called to change the product's current status data from "unused" to the preset "verified" status data. From this point on, the coupon is atomically and permanently marked as invalid on the chain, and any attempt to redeem it again will be rejected due to the status check failure, thereby completely eliminating the problem of multiple reuse of digital goods.

[0036] Upon receiving a pre-defined cross-chain verification command, the system handles the complex requirement of confirming and synchronizing the identity or status of digital goods across different blockchain networks. First, the received cross-chain verification command is parsed to obtain the cross-chain product identifier, the target chain network identifier, the type of state to be synchronized, and the cross-chain request authorization credential. For example, the ownership of the broadcasting rights to an exclusive short drama series held by Company AAA is recorded on Chain A, but now its authenticity needs to be verified in a derivatives trading market on Chain B. Here, the cross-chain product identifier is the ID of the short drama broadcasting rights; the target chain network identifier is the chain ID of Chain B; the type of state to be synchronized might be "current ownership status"; and the authorization credential is a digital signature issued by the owner on Chain A, agreeing to conduct this cross-chain status query. The parsing clarifies the object, target, content, and permissions of the cross-chain operation. Subsequently, based on the cross-chain product identifier and the target chain network identifier, the corresponding smart contract data is obtained from the target blockchain network through a cross-chain bridge or relay service to retrieve the original claim information from the external chain. Next, the authorization verification adopted in this application confirms two points: first, whether the product state type (such as ownership) recorded on the target chain is allowed to be queried and synchronized; second, whether the requester (i.e., the issuer of the authorization certificate) is the current legitimate owner recorded on the target chain or its explicitly authorized agent. This is a security prerequisite for cross-chain operations, ensuring that the request for state synchronization is legal and authorized. After the cross-chain verification instruction passes this authorization verification, more accurate target chain state data (such as the specific address of the current owner) and key inter-chain cryptographic proofs (such as the Merkel proof of the state data in the state tree of a specific block of the target chain) are obtained from the target blockchain network according to the state type to be synchronized. This allows for independent verification of the authenticity of the obtained state data without relying on the honesty of the target chain nodes. After the inter-chain cryptographic proof is effectively verified through the preset cross-chain verification protocol, the verified and accurate target chain state data is written into the smart contract data of the local chain according to the state type to be synchronized. For example, in the smart contract of Chain B, a state mapping record is created for the playback rights of the short drama on Chain A, updating its current owner address to the address just verified and synchronized from Chain A. A trusted mirror of the external chain's state, based on cryptographic evidence, is established on the local chain, enabling the digital commodity to achieve mutual recognition of identity and synchronization of state across ecosystems without migration, greatly expanding its circulation scope and interoperability.

[0037] Please see Figure 2 , Figure 2 This is a schematic diagram of a blockchain-based digital product verification device provided in an embodiment of this application. Figure 2 As shown, the blockchain-based digital product verification device 2 includes: a product analysis module 21, an issuance storage module 22, and a request verification module 23.

[0038] Product parsing module 21 is used to extract features and encrypt and encode the received digital product data to generate product identifiers and corresponding product description metadata. The issuance storage module 22 is used to digitally sign and construct blockchain data for the product identifier and the product description metadata based on the received issuer identity identifier, and generate smart contract data corresponding to the digital product data; The request verification module 23 is used to perform compliance verification on the received product operation request instruction based on the smart contract data, so as to change the smart contract data according to the verified product operation request instruction.

[0039] In one possible implementation, the product parsing module 21 is specifically used for: The received digital product data is divided into data blocks and the hash value of each data block is calculated using a preset binary stream method to form the first feature sequence. The digital product data is semantically parsed based on its data attributes to extract a second feature sequence; Based on the preset product description data type, descriptive metadata is extracted and structured description is performed on the digital product data to generate a third feature sequence; The first feature sequence, the second feature sequence, and the third feature sequence are serialized, concatenated, and hashed to generate a product identifier. The first feature sequence, the second feature sequence, and the third feature sequence are encapsulated to generate product description metadata.

[0040] In one possible implementation, the issuance storage module 22 is specifically used for: The preset product issuance marker, preset blockchain address, recorded current timestamp, product identifier, and product description metadata are encapsulated into issuance declaration data; The issuance statement data is digitally signed using the received issuance private key to generate digital identity data corresponding to the issuance statement data; The issuance statement data and the digital identity data are verified by consensus nodes in a pre-defined blockchain network, checking their data format and signature data. Once the issuance statement data and the digital identity data are verified, the issuance statement data and the digital identity data are encapsulated according to the preset contract format and the product identifier using a preset mapping storage strategy to generate smart contract data corresponding to the digital product data.

[0041] In one possible implementation, when the product operation request instruction is a preset transaction instruction, the request verification module 23 is used to: The received transaction instructions are parsed to obtain the transaction product identifier, ownership proof data, and transferee data; Based on the transaction product identifier, the corresponding smart contract data is obtained from the blockchain network, and the disposal permission of the transaction instruction is verified based on the smart contract data and the ownership proof data. When the ownership data in the smart contract data is consistent with the ownership proof data, the ownership data is changed to the transferee data, and an ownership change record is generated according to the preset change record method.

[0042] In one possible implementation, when the product operation request instruction is a preset verification instruction, the request verification module 23 is used to: The received reconciliation instruction is parsed to obtain the reconciliation product identifier, the reconciliation party's voucher, and the reconciliation parameters; Based on the product verification identifier, obtain the corresponding smart contract data from the blockchain network, and then obtain the corresponding product current status data from the blockchain network based on the smart contract data; The verification mechanism uses a preset verification mechanism to perform multi-factor condition verification on the verification instruction based on the current status data of the product, the verification party's credentials, and the verification parameters. Once the verification instruction is verified, the current status data of the product is changed to the preset verified status data according to the preset verification method.

[0043] In one possible implementation, when the product operation request instruction is a preset cross-chain verification instruction, the request verification module 23 is used to: The received cross-chain verification command is parsed to obtain the cross-chain product identifier, the target chain network identifier, the state type to be synchronized, and the cross-chain request authorization credential. Based on the cross-chain product identifier and the target chain network identifier, obtain the corresponding smart contract data from the target blockchain network; Based on the smart contract data, the type of state to be synchronized and the cross-chain request authorization certificate are authorized and verified. Once the cross-chain verification instruction passes verification, the corresponding target chain state data and inter-chain cryptographic proof are obtained from the target blockchain network according to the type of state to be synchronized. Once the inter-chain cryptographic proof is successfully verified through the preset cross-chain verification protocol, the target chain state data is written into the smart contract data according to the type of state to be synchronized.

[0044] The product parsing module 21, the issuance storage module 22, and the request verification module 23 can all be implemented in software or in hardware. For example, the implementation of the product parsing module 21 will be described below. Similarly, the implementation of the issuance storage module 22 and the request verification module 23 can refer to the implementation of the product parsing module 21.

[0045] As an example of a software functional unit, the product analysis module 21 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the product analysis module 21 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0046] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0047] As an example of a hardware functional unit, the product analysis module 21 may include at least one computing device, such as a server. Alternatively, the product analysis module 21 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0048] The product analysis module 21 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the multiple computing devices in the product analysis module 21 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices in the product analysis module 21 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0049] See Figure 3 As shown, Figure 3 This is a schematic diagram of a computing device provided in this application. The computing device 100 includes: a processor 104, a communication interface 108, a bus 102, and a memory 106. The processor 104, the communication interface 108, and the memory 106 communicate via the bus 102. In practical applications, communication can also be achieved through other means such as wireless transmission; however, this is not limited here.

[0050] The computing device 100 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the computing device 100.

[0051] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0052] The communication interface 108 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 100 and other devices or communication networks.

[0053] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus 102 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 102 may include a path for transmitting information between various components of the computing device 100 (e.g., memory 106, processor 104, communication interface 108).

[0054] Memory 106 may include volatile memory, such as random access memory (RAM). Memory 106 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0055] The memory 106 stores executable program code, and the processor 104 executes the executable program code to implement the functions of the aforementioned product parsing module 21, issuance storage module 22 and request verification module 23 respectively, thereby realizing the blockchain-based digital product verification method. That is, the memory 106 stores instructions for executing the blockchain-based digital product verification method.

[0056] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a blockchain-based digital product verification method, or instruct the computing device to perform a blockchain-based digital product verification method.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based digital product verification method, characterized in that, The method includes: The received digital product data is subjected to feature extraction and encryption encoding to generate product identifiers and corresponding product description metadata. Based on the received issuer identity identifier, the product identifier and the product description metadata are digitally signed and blockchain data is constructed to generate smart contract data corresponding to the digital product data; The received product operation request instruction is verified for compliance based on the smart contract data, and the smart contract data is modified according to the verified product operation request instruction.

2. The blockchain-based digital product verification method according to claim 1, characterized in that, The step of performing feature extraction and encryption encoding on the received digital product data to generate product identifiers and corresponding product description metadata includes: The received digital product data is divided into data blocks and the hash value of each data block is calculated using a preset binary stream method to form the first feature sequence. The digital product data is semantically parsed based on its data attributes to extract a second feature sequence; Based on the preset product description data type, descriptive metadata is extracted and structured description is performed on the digital product data to generate a third feature sequence; The first feature sequence, the second feature sequence, and the third feature sequence are serialized, concatenated, and hashed to generate a product identifier. The first feature sequence, the second feature sequence, and the third feature sequence are encapsulated to generate product description metadata.

3. The blockchain-based digital product verification method according to claim 1, characterized in that, The issuer identity identifier includes an issuer private key. The process of digitally signing the product identifier and the product description metadata based on the received issuer identity identifier, constructing blockchain data, and generating smart contract data corresponding to the digital product data includes: The preset product issuance marker, preset blockchain address, recorded current timestamp, product identifier, and product description metadata are encapsulated into issuance declaration data; The issuance statement data is digitally signed using the received issuance private key to generate digital identity data corresponding to the issuance statement data; The issuance statement data and the digital identity data are verified by consensus nodes in a pre-defined blockchain network, checking their data format and signature data. Once the issuance statement data and the digital identity data are verified, the issuance statement data and the digital identity data are encapsulated according to the preset contract format and the product identifier using a preset mapping storage strategy to generate smart contract data corresponding to the digital product data.

4. The blockchain-based digital product verification method according to claim 3, characterized in that, When the product operation request instruction is a preset transaction instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received transaction instructions are parsed to obtain the transaction product identifier, ownership proof data, and transferee data; Based on the transaction product identifier, the corresponding smart contract data is obtained from the blockchain network, and the disposal permission of the transaction instruction is verified based on the smart contract data and the ownership proof data. When the ownership data in the smart contract data is consistent with the ownership proof data, the ownership data is changed to the transferee data, and an ownership change record is generated according to the preset change record method.

5. The blockchain-based digital product verification method according to claim 3, characterized in that, When the product operation request instruction is a preset verification instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received reconciliation instruction is parsed to obtain the reconciliation product identifier, the reconciliation party's voucher, and the reconciliation parameters; Based on the product verification identifier, obtain the corresponding smart contract data from the blockchain network, and then obtain the corresponding product current status data from the blockchain network based on the smart contract data; The verification mechanism uses a preset verification mechanism to perform multi-factor condition verification on the verification instruction based on the current status data of the product, the verification party's credentials, and the verification parameters. Once the verification instruction is verified, the current status data of the product is changed to the preset verified status data according to the preset verification method.

6. The blockchain-based digital product verification method according to claim 3, characterized in that, When the product operation request instruction is a preset cross-chain verification instruction, the step of performing compliance verification on the received product operation request instruction based on the smart contract data, and then modifying the smart contract data according to the verified product operation request instruction, includes: The received cross-chain verification command is parsed to obtain the cross-chain product identifier, the target chain network identifier, the state type to be synchronized, and the cross-chain request authorization credential. Based on the cross-chain product identifier and the target chain network identifier, obtain the corresponding smart contract data from the target blockchain network; Based on the smart contract data, the type of state to be synchronized and the cross-chain request authorization certificate are authorized and verified. Once the cross-chain verification instruction passes verification, the corresponding target chain state data and inter-chain cryptographic proof are obtained from the target blockchain network according to the type of state to be synchronized. Once the inter-chain cryptographic proof is successfully verified through the preset cross-chain verification protocol, the target chain state data is written into the smart contract data according to the type of state to be synchronized.

7. A blockchain-based digital product verification device, applied to the blockchain-based digital product verification method of claim 1, characterized in that, The device includes: The product parsing module is used to extract features and encrypt the received digital product data to generate product identifiers and corresponding product description metadata. The issuance storage module is used to digitally sign and construct blockchain data for the product identifier and the product description metadata based on the received issuer identity identifier, and generate smart contract data corresponding to the digital product data; The request verification module is used to perform compliance verification on the received product operation request instruction based on the smart contract data, so as to modify the smart contract data according to the verified product operation request instruction.

8. A computing device, characterized in that, The computing device includes: At least one processor; and, A memory and a communication interface that are communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the at least one processor implements the blockchain-based digital product verification method according to any one of claims 1 to 6 by executing the instructions stored in the memory.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the blockchain-based digital product verification method according to any one of claims 1 to 6.

Images