A method, system and medium for authenticating a digital rights certificate

Abstract

The application provides a digital right certificate right-proving method, system and medium, relates to the technical field of right certificates, and the method comprises the following steps: analyzing original digital assets, constructing a standardized metadata object, and storing the standardized metadata object to a decentralized storage network; constructing a transaction data packet by using a smart contract, and submitting the transaction data packet to a block chain network to complete on-chain storage; updating a block chain world state database, establishing a mapping relationship between a certificate identifier and a user identity identifier, and completing final state fixation of right-proving data; and outputting an on-chain certificate identifier and a transaction hash as a right-proving result. The application solves the technical problem that, in the prior art, due to the fact that right ownership declaration and right object are stored in a separated manner, and right ownership relationship is fixed in a final state depending on a transaction log rather than a world state, evidence storage drifts, and the authenticity and integrity of digital assets are affected, and in combination with a block chain, the application realizes cryptographic anchoring of right declaration and right object, and guarantees consistency of on-chain and off-chain data and asset safety.

Description

Technical Field

[0001] This application relates to the field of rights certificate technology, specifically to a method, system and medium for confirming rights of digital rights certificates. Background Technology

[0002] As informatization deepens, society has transformed from a singular, physical environment into a diverse, integrated digital environment where the real and virtual worlds intertwine and information flows freely. Single, fixed physical assets, incorporating the characteristics of the information age, have become various information assets. However, current methods for proving the uniqueness and ownership of assets have not kept pace. There are few unified systems and solutions in the market for verifying the rights to personal assets. Some intangible assets with secondary value are frequently stolen, such as personal identification information and contact details being maliciously obtained and sold, or frequent game account theft incidents, causing incalculable losses to holders. Currently, most asset verification methods use certificates and encryption, with official authoritative certificates issued and then entrusted to users for safekeeping. Users can use certificate signing to guarantee the ownership of the certificate. Under this scheme, users need to actively safeguard both official certificates and personal certificates, a complex and cumbersome process, and its limitations are only applicable to protecting a portion of assets.

[0003] Some solutions attempt to store the original files of digital assets on the blockchain through transactions, hoping to leverage the immutability of on-chain data to achieve ownership claims. However, on-chain certificates and original asset / metadata files are stored separately. Only hash values ​​or metadata links are stored on-chain. When off-chain storage nodes fail or centralized gateways become unavailable, the original assets cannot be located and recovered, and the on-chain evidence becomes redundant data that cannot be linked to the actual object, resulting in the evidence drift problem. Furthermore, the final record of ownership relies solely on blockchain transaction logs, rather than the core storage unit that writes to the on-chain world state. This prevents light nodes or forensic institutions from quickly obtaining cryptographically verifiable ownership proof through a single state query, requiring them to trace back the entire historical transaction history, severely reducing the efficiency of verifying ownership information.

[0004] In summary, existing technologies suffer from technical problems such as the separate storage of ownership statements and the objects of rights, and the fact that ownership relationships are only finalized based on transaction logs rather than world states, leading to evidence drift and further affecting the authenticity and integrity of digital assets. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, and medium for confirming the ownership of digital rights certificates, in order to solve the technical problems in the prior art where the ownership declaration and the rights object are stored separately, and the ownership relationship is only finalized by transaction logs rather than world state, resulting in evidence drift and further affecting the authenticity and integrity of digital assets.

[0006] To achieve the above objectives, this application provides a method, system, and medium for confirming the rights of digital rights certificates.

[0007] Firstly, this application provides a method for confirming the ownership of digital rights certificates. This method is implemented through a digital rights certificate confirmation system, comprising: acquiring original digital assets and user identity identifiers; parsing the original digital assets and constructing a standardized metadata object; storing the original digital assets in a decentralized storage network to obtain a content addressing identifier; associating the content addressing identifier with the standardized metadata object to generate a metadata access path; based on the metadata access path, constructing a certificate minting transaction data packet according to the data interface standard specified by the on-chain smart contract; encoding the user identity identifier and the metadata access path as the transaction payload of the transaction data packet; submitting the transaction data packet to the blockchain network, completing on-chain storage after consensus confirmation, and obtaining the corresponding block height and transaction hash; based on the on-chain completion status, triggering an update of the blockchain world state database, establishing a unique mapping relationship between the on-chain certificate identifier and the user identity identifier, writing the metadata access path into the state storage unit corresponding to the mapping relationship, and completing the final state determination of the ownership confirmation data; and outputting the on-chain certificate identifier and the transaction hash as the ownership confirmation result.

[0008] Optionally, the attribute fields of the original digital asset are extracted, including asset name, asset description and asset type information; the extracted attribute fields are normalized according to a preset data model to generate a data structure that conforms to the on-chain certificate standard, which serves as the standardized metadata object.

[0009] Optionally, the original digital asset is submitted to the IPFS network, whereby the IPFS network calculates and generates a unique CID identifier based on the data content of the original digital asset; the CID identifier returned by the IPFS network is received, and the CID identifier is used as the content addressing identifier, and a decentralized access path for the original digital asset is constructed based on the CID identifier.

[0010] Optionally, the standardized metadata object is encapsulated into a metadata file; the metadata file is stored in a decentralized storage network to obtain the metadata content addressing identifier corresponding to the metadata file; the metadata content addressing identifier is bound to the content addressing identifier, and the combined identifier after binding is used as the metadata access path.

[0011] Optionally, the contract address and its ABI definition file of the on-chain smart contract are obtained, and the method selector and parameter type list of the credential minting method are parsed from the ABI definition file. According to the parameter type list, the user identity identifier is format-validated and filled according to the address type specification to generate a first encoded parameter, and the metadata access path is length-prefixed and serialized according to the string type specification to generate a second encoded parameter. The method selector, the first encoded parameter, and the second encoded parameter are concatenated according to the parameter arrangement order specified in the ABI definition to generate a call data payload. The current transaction sequence number of the user's on-chain account is obtained, and based on the current transaction sequence number, the contract address, the call data payload, and the user's digital signature, it is encapsulated into the credential minting transaction data packet according to the blockchain network transaction protocol specification.

[0012] Optionally, the on-chain smart contract conforms to the ERC-721 or ERC-1155 standard protocol, and the transaction payload fields encapsulate method selectors and parameter encoding data that conform to the standard protocol.

[0013] Optionally, the encryption mode identifier selected by the user terminal is obtained, wherein the encryption mode identifier indicates a symmetric encryption mode or an asymmetric encryption mode; if the encryption mode identifier indicates a symmetric encryption mode, a symmetric key and an initialization vector are generated, and a symmetric encryption operation is performed on the metadata access path, replacing the plaintext with ciphertext in the encoding of the transaction payload; if the encryption mode identifier indicates an asymmetric encryption mode, the public key of the user terminal is obtained, and an asymmetric encryption operation is performed on the metadata access path based on the public key, replacing the plaintext with ciphertext in the encoding of the transaction payload.

[0014] Optionally, ticketing parameters are obtained, including ticket category identifier, ticket category name, and maximum supply of the ticket category. If the ticketing parameters indicate the minting of special tickets, a smart contract based on the ERC-721 standard is invoked to generate a unique on-chain credential identifier for each ticket. The improved smart contract embeds a ticket status field and includes a verification method and a cancellation method. The cancellation method is operated by the event organizer. After cancellation, the ticket status changes from valid to cancelled and is uniquely held by the holder as a digital collectible. If the ticketing parameters indicate the minting of ordinary tickets, a smart contract based on the ERC-1155 standard is invoked to create a ticket category with a ticket category identifier and maximum supply of the ticket category. Multiple homogeneous tickets are minted in batches under the ticket category and allocated to target user addresses.

[0015] Secondly, this application also provides a digital rights certificate confirmation system for executing a digital rights certificate confirmation method as described in the first aspect, wherein the digital rights certificate confirmation system includes: a data parsing module for obtaining the original digital asset and user identity identifier, parsing the original digital asset, and constructing a standardized metadata object; a distributed storage module for storing the original digital asset in a decentralized storage network, obtaining a content addressing identifier, and associating the content addressing identifier with the standardized metadata object to generate a metadata access path; and an on-chain packaging module for packaging according to the metadata access path and the data interface standard specified by the on-chain smart contract. A credential minting transaction data packet is constructed, encoding the user identity identifier and the metadata access path into the transaction payload of the transaction data packet; an on-chain storage module is used to submit the transaction data packet to the blockchain network, complete on-chain storage after consensus confirmation, and obtain the corresponding block height and transaction hash; a state determination module is used to trigger an update of the blockchain world state database based on the on-chain completion state, establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, write the metadata access path into the state storage unit corresponding to the mapping relationship, and complete the final state determination of the rights confirmation data; a result output module is used to output the on-chain credential identifier and the transaction hash as the rights confirmation result.

[0016] Thirdly, a computer-readable storage medium storing a computer program that, when executed, implements the steps of the method for confirming the rights of a digital rights certificate as described in any of the first aspects above.

[0017] One or more technical solutions provided in this application have at least the following technical effects or advantages: By acquiring the original digital assets and user identity identifiers, the original digital assets are parsed to construct a standardized metadata object; the original digital assets are stored in a decentralized storage network to obtain a content addressing identifier, and the content addressing identifier is associated with the standardized metadata object to generate a metadata access path; based on the metadata access path, a credential minting transaction data packet is constructed according to the data interface standard specified by the on-chain smart contract, and the user identity identifier and the metadata access path are encoded as the transaction payload of the transaction data packet; the transaction data packet is submitted to the blockchain network, and after consensus confirmation, on-chain storage is completed, obtaining the corresponding block height and transaction hash; based on the on-chain completion status, the blockchain world state database is updated to establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, and the metadata access path is written into the state storage unit corresponding to the mapping relationship to complete the final state determination of the rights confirmation data; the on-chain credential identifier and the transaction hash are output as the rights confirmation result. In other words, by parsing the original digital assets to construct standardized metadata objects, the asset ontology is stored in a decentralized storage network to obtain content addressing identifiers and generate accessible paths. The user identity identifier and the path are encoded into transaction payloads and submitted to the blockchain, which forcibly triggers the update of the blockchain world state database, thus completing the finalization of the ownership data and ensuring the consistency of on-chain and off-chain data and asset security.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a method for confirming the ownership of a digital rights certificate according to this application.

[0021] Figure 2 This is a schematic diagram of the structure of a digital rights certificate confirmation system according to this application.

[0022] Figure labeling: Data parsing module 11, distributed storage module 12, on-chain packaging module 13, on-chain storage module 14, state settlement module 15, result output module 16. Detailed Implementation

[0023] This application provides a method, system, and medium for confirming the ownership of digital rights certificates. It addresses the technical problem in existing technologies where ownership declarations and the actual rights objects are stored separately, and ownership relationships are only finalized through transaction logs rather than the world state, leading to evidence drift and further affecting the authenticity and integrity of digital assets. By parsing the original digital assets to construct standardized metadata objects, storing the asset ontology in a decentralized storage network to obtain content addressing identifiers and generate accessible paths, and encoding the user's identity identifier and this path into a transaction payload, the application submits the transaction to the blockchain and forcibly triggers an update to the blockchain world state database. This finalizes the ownership confirmation data, ensuring consistency between on-chain and off-chain data and asset security.

[0024] The technical solutions of this application will now be clearly and completely described 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. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0025] Example 1, please refer to the appendix. Figure 1 This application provides a method for confirming the ownership of a digital rights certificate, wherein the method is applied to a system for confirming the ownership of a digital rights certificate, and the method specifically includes the following steps: S100: Obtain the original digital assets and user identity identifiers, perform data parsing on the original digital assets, and construct a standardized metadata object.

[0026] Furthermore, S100 of this application includes: extracting attribute fields of the original digital asset, the attribute fields including asset name, asset description and asset type information; performing format normalization processing on the extracted attribute fields according to a preset data model to generate a data structure that conforms to the on-chain certificate standard, as the standardized metadata object.

[0027] Specifically, this involves acquiring the original digital asset files and user identification information submitted by the user through a client application. The original digital assets are the digital content to be verified, such as image files, audio files, video files, 3D model files, document files, or game equipment data—any digital creation or digital rights carrier existing in binary form. The user identification is information used to uniquely represent a user's identity within the blockchain network. It is typically the user's blockchain account address, a fixed-length string of characters generated by hashing the public key and verifying its encoding, representing the user's digital identity in the decentralized network.

[0028] The original digital assets are opened using file input / output streaming technology, and the basic attribute information embedded in the file's header information area is read. For common digital image file formats, the header area typically contains data such as creator information, creation tool information, image size information, and copyright notices; for digital audio files, the header area contains information such as artist name, album name, track title, and sample rate. Three core attribute fields—asset name, asset description, and asset type information—are extracted from the header information. When a certain attribute field is missing from the file header information, the user is prompted through the user interface to manually fill in the content of that field to ensure that all necessary fields have valid values.

[0029] Read the configuration information of the preset data model to obtain the data type constraints, format specifications and valid value ranges for each attribute field.

[0030] For the asset name field, a normalization operation is performed according to the requirements of the preset data model. The character encoding is uniformly converted to the general character encoding standard format, all whitespace characters at the beginning and end of the string are removed, multiple consecutive whitespace characters are compressed into a single space, and special control characters that may exist in the string are filtered or escaped to make the asset name conform to the general text storage and display specifications.

[0031] For the asset description field, normalization is performed according to the requirements of the preset data model. After completing character encoding conversion and whitespace character processing, compliance checks are performed on the length of the description text. When the length of the description text exceeds the maximum length limit specified by the preset data model, the text is truncated according to the intelligent truncation strategy, and an ellipsis mark is added at the truncation position to prompt the user that the content has been truncated.

[0032] For the asset type information field, a normalization operation is performed according to the enumeration value mapping table of the preset data model. The original asset type information is fuzzily matched with the enumeration values ​​in the mapping table. If the match is successful, the asset type information is converted into the standard enumeration code corresponding to the mapping table. If the match fails, the asset type information is classified into other preset category enumeration values, and the original type value is recorded as a custom label and retained in the extended field of the metadata.

[0033] Based on the field arrangement order and hierarchical structure defined in the preset data model, all normalized attribute fields are assembled into a complete data structure in key-value pairs. This strictly adheres to the naming conventions specified in the on-chain credential standard, ensuring that the data types of the field values ​​are completely consistent with the data types required by the on-chain credential standard, and that the nesting hierarchy between fields matches the parsing logic of the on-chain smart contract. After assembly, the data structure undergoes integrity verification, confirming that all required fields have valid non-empty values, that the data types of each field conform to the type constraints of the preset data model, and that the values ​​of each field are within the legal range specified by the preset data model. Upon successful verification, the data structure is output as a standardized metadata object.

[0034] S200: Store the original digital assets in a decentralized storage network, obtain a content addressing identifier, and associate the content addressing identifier with the standardized metadata object to generate a metadata access path.

[0035] Furthermore, S200 of this application includes: submitting the original digital asset to the IPFS network, whereby the IPFS network calculates and generates a unique CID identifier based on the data content of the original digital asset; receiving the CID identifier returned by the IPFS network, using the CID identifier as the content addressing identifier, and constructing a decentralized access path for the original digital asset based on the CID identifier.

[0036] Furthermore, this application also includes the following steps: encapsulating the standardized metadata object into a metadata file; storing the metadata file in a decentralized storage network to obtain the metadata content addressing identifier corresponding to the metadata file; binding the metadata content addressing identifier with the content addressing identifier, and using the combined identifier after binding as the metadata access path.

[0037] Specifically, the original digital asset is converted into a complete binary data stream and encapsulated according to the data format and transmission protocol specified by the IPFS network. The encapsulated data is then sent to one or more access nodes in the IPFS network via a network connection. Upon receiving the binary data of the original digital asset, the IPFS network performs content addressing processing, dividing all the binary bytes of the original data into multiple equal-sized data blocks according to a preset block size. Each data block undergoes independent cryptographic hash calculation to obtain a sub-block hash value. The IPFS network then organizes all sub-block hash values ​​according to a specific tree structure, performs cryptographic hash calculation on the root node of the tree structure, and finally generates a top-level hash value representing the complete original digital asset content. The IPFS network encodes this top-level hash value according to multi-base encoding rules to generate a unique identifier conforming to the CID specification format. After generating the CID identifier, the IPFS network stores each data block of the original digital asset, indexed by its corresponding sub-block hash value, on multiple storage nodes within the network. The top-level CID identifier is then published as a global retrieval index for the complete file in the network's distributed hash table, allowing any node in the network to route and locate the node storing the file's data block using this CID identifier. The unique CID identifier generated by the IPFS network for the original digital asset is extracted from the returned response data packet; it is a string with a fixed format.

[0038] IPFS is a content-addressed decentralized distributed storage network protocol. Each node can independently store and provide data. Files are no longer located based on the address of a centralized server, but are addressed and retrieved through a unique identifier calculated from the file content itself. The unique CID (Content Identifier) ​​is the core addressing identifier used to uniquely identify and locate data content in the IPFS network. The unique CID is generated based on the cryptographic hash value of the data content through multi-base encoding, ensuring its uniqueness. The same data content will have the exact same CID calculated by any node at any time, while different data content will generate completely different CIDs even if they differ by only a single bit. The CID is the unique credential for obtaining data in the IPFS network; users only need to hold this identifier to retrieve and obtain the corresponding original data content from any node in the network.

[0039] The system receives the CID identifier returned by the IPFS network and formats it according to the IPFS Uniform Resource Identifier specification. A protocol type prefix string is added to the front of the CID identifier to declare that the access protocol used by the path is IPFS. The CID identifier is then appended to the protocol prefix as the core location parameter of the path. After concatenation, a complete decentralized access path string is obtained, containing two core components: the access protocol identifier and the data content location identifier. Any network client supporting the IPFS protocol can directly locate and obtain the complete data content of the original digital asset through this path. The decentralized access path is a Uniform Resource Identifier used to locate and obtain specific data content in a decentralized storage network. It uses a specific protocol prefix to identify the access protocol type of the decentralized storage network, followed by the CID identifier of the data content. Any user holding a decentralized access path can access and download the data content pointed to by the path through a network client that supports the corresponding protocol, without needing any centralized gateway or authorization authentication.

[0040] The metadata encapsulation process is initiated, converting the standardized metadata object from an in-memory data structure into a text file format according to a preset serialization format. During the conversion, each field in the standardized metadata object is traversed, with the field name used as a text label and the field value as the corresponding text content, generating the corresponding text representation according to the syntax rules specified in the serialization format. A preset metadata version number and metadata file format identifier are written to the file header. After traversing and serializing all fields, a complete metadata file is generated, which records all the contents of the standardized metadata object in text format.

[0041] The complete text content of the metadata file is submitted to the IPFS network according to the IPFS network's transmission protocol. Upon receiving the text data of the metadata file, the IPFS network performs the same block processing, hash calculation, and distributed storage process described above. Specifically, it calculates and generates a unique content address identifier (CID) for the file based on its entire text content and returns this unique CID to the system. This unique CID serves as the unique location identifier for the metadata file within the IPFS network. Its generation logic is entirely based on the text content of the metadata file and is independent of and unaffected by the original digital asset's CID identifier.

[0042] The original digital asset content addressing identifier is written as a newly added associated field value into the metadata object, generating an updated metadata object. This updated metadata object is then repackaged into a new metadata file and stored on the IPFS network, yielding the final version of the metadata content addressing identifier. This final version of the metadata content addressing identifier is used as the main part of the metadata access path, formatted and concatenated according to the Uniform Resource Identifier (URI) specification of decentralized storage networks. During concatenation, a protocol type prefix is ​​added to the front of the final version of the metadata content addressing identifier to generate a complete metadata access path string. Using the final version of the metadata file as the entry point, when a user accesses this path, they first obtain the metadata file containing the original asset's CID binding field. Then, through the binding fields within this file, they further obtain the original digital asset itself, thus achieving the technical effect of indirectly accessing the original digital asset through a single combined identifier path.

[0043] Storing standardized metadata objects as independent files in a decentralized storage network gives these metadata files a content addressing identifier and lifecycle independent of the original digital asset. When the description information of the digital asset needs to be updated or corrected, only the metadata file needs to be repackaged and a new metadata content addressing identifier needs to be generated. There is no need to restore and upload the bulky original digital asset ontology, which significantly reduces the network transmission cost and storage overhead of metadata updates. Using the final version of the metadata content addressing identifier as the main body of the metadata access path, users only need to hold a path string to ultimately access the original digital asset ontology through the intermediary reference of the metadata file. This allows on-chain credentials to indirectly achieve dual anchoring of the original asset and metadata description information by recording only one metadata access path, simplifying on-chain storage content while ensuring the integrity and accuracy of the rights object positioning information.

[0044] S300: Based on the metadata access path, construct a credential minting transaction data packet according to the data interface standard specified by the on-chain smart contract, and encode the user identity and the metadata access path into the transaction payload of the transaction data packet.

[0045] Furthermore, S300 of this application includes: obtaining the contract address of the on-chain smart contract and its ABI definition file; parsing the method selector and parameter type list of the credential minting method from the ABI definition file; according to the parameter type list, performing format verification and filling processing on the user identity identifier according to the address type specification to generate a first encoding parameter, and performing length prefix encoding and serialization processing on the metadata access path according to the string type specification to generate a second encoding parameter; concatenating the method selector, the first encoding parameter, and the second encoding parameter according to the parameter arrangement order specified in the ABI definition to generate a call data payload; obtaining the current transaction sequence number of the on-chain account of the user terminal, and encapsulating the credential minting transaction data packet according to the blockchain network transaction protocol specification based on the current transaction sequence number, the contract address, the call data payload, and the digital signature of the user terminal.

[0046] Furthermore, this application also includes the following steps: the on-chain smart contract follows the ERC-721 standard protocol or the ERC-1155 standard protocol, and the fields of the transaction payload encapsulate method selectors and parameter encoding data that conform to the standard protocol.

[0047] Specifically, the contract address and ABI definition file of the target smart contract are obtained from the blockchain network or local cache. The smart contract has been pre-deployed on the blockchain network, and its contract address is a fixed-length string. Simultaneously, the ABI definition file of the target smart contract is obtained, which records the interface information of all callable methods exposed by the contract in a structured manner.

[0048] Based on the requirements of the rights confirmation business, the entry point for the document creation method is located from the ABI definition file. The method selector and a list of parameter types for all required input parameters are then parsed. During parsing, the first parameter type of the document creation method is identified as an address type used to receive the user identity identifier of the document recipient, and the second parameter type is a string type used to receive the metadata access path. It is confirmed that the target smart contract strictly adheres to the ERC-721 or ERC-1155 standard protocol. The smart contract implements the interface specifications defined by the corresponding standard and embeds the method selector naming rules and parameter encoding rules required by the standard protocol in the interface implementation, ensuring that the method selector and parameter encoding data in the generated transaction payload are fully compatible with the standard protocol.

[0049] On-chain smart contracts follow either the ERC-721 or ERC-1155 standard protocols. The ERC-721 standard protocol is a non-fungible certificate specification interface defined by Ethereum Request Proposal 721, which stipulates that each certificate identifier is unique, and different certificates are not interchangeable or indivisible. It is suitable for scenarios where each digital rights certificate needs to be independently identified and independently verified. The ERC-1155 standard protocol is a multi-type certificate specification interface defined by Ethereum Request Proposal 1155, which allows the simultaneous management of fungible and non-fungible certificates in the same contract. It supports the batch minting, transfer, and destruction of multiple certificates in a single transaction, and is suitable for scenarios that require efficient batch processing of certificates, such as the large-scale distribution of equipment in games or the batch issuance of tickets in ticketing systems.

[0050] The first input parameter, the user identifier, is encoded using the address type. The original string value of the user identifier, i.e., the user's blockchain account address, undergoes format validation to ensure its length matches the standard length required by the address specification and that all characters are within the allowed character range for the address type. After successful format validation, padding is performed according to the address type encoding specification: since the address type occupies a fixed 32 bytes of storage space in the blockchain virtual machine, and the effective length of the original address string is typically 20 bytes, leading zeros are added to the high bits of the original address data to expand it to a fixed-length 32-byte encoded value. After padding, the first encoded parameter is obtained, with a fixed length of 64 hexadecimal characters.

[0051] The second input parameter, the metadata access path, is encoded as a string. Since strings are dynamic-length data types, their encoding differs fundamentally from fixed-length data types. The complete string value of the metadata access path is obtained, and its byte length is measured. This length value is encoded into a 32-byte hexadecimal value according to the string type encoding specification, serving as the prefix of the string parameter to inform the virtual machine of the total number of bytes of string data to be read subsequently. Each character of the metadata access path string is converted into its corresponding hexadecimal encoded value, and all character encodings are arranged sequentially after the length prefix to form the complete encoded sequence of the string content. The length prefix encoding and the string content encoding together constitute the second encoding parameter, the total length of which dynamically changes with the actual length of the metadata access path.

[0052] The method selector is placed at the very beginning of the call data payload. The first and second encoded parameters are then concatenated after the method selector in the order specified in the parameter type list in the ABI definition file. The method selector, the first encoded parameter, and the second encoded parameter are arranged closely together in this order to form a complete call data payload. All data is in hexadecimal encoding format, which fully complies with the format requirements of the blockchain virtual machine for transaction input data. When parsing this payload, the virtual machine can accurately locate the method selector to identify the target function and parse the actual values ​​of each parameter one by one according to the parameter type list.

[0053] The total number of transactions sent by this account address is obtained by querying the blockchain network, which is the current transaction sequence number. The transaction data packet is assembled, organizing all transaction elements according to the blockchain network transaction protocol specifications. These specifications define the set of fields that must be included in the transaction data packet, the order of these fields, and the encoding format of each field. The current transaction sequence number, the target contract address, the data payload, and the network fee parameters required for transaction execution are then sequentially filled into the corresponding fields of the transaction data packet.

[0054] The transaction data packet, excluding the signature, is serialized and concatenated according to the transaction protocol specifications to obtain a data sequence to be signed. This data sequence is then input into a digital signature algorithm, using the user's private key as the signing key, to generate a unique digital signature value for the transaction content. The generated digital signature value is then filled into the reserved signature field in the transaction data packet, completing the final encapsulation of the transaction data packet. The encapsulated credential-minting transaction data packet contains all necessary information, including the transaction sequence number, contract address, call data payload, and digital signature. Any blockchain node that obtains this data packet can verify the digital signature to confirm that the transaction was indeed initiated by the user and that the content has not been tampered with, and can verify the transaction sequence number to confirm that the transaction has not yet been submitted for execution.

[0055] The current transaction sequence number is entered into the sequence number field of the transaction data packet, the target contract address is entered into the recipient address field of the transaction data packet, and the call data payload is entered into the payload field of the transaction data packet. A digital signature operation is performed on the main content of the encapsulated transaction data packet. A digital signature value for the transaction is generated using the private key of the user's blockchain account, and this signature value is entered into the signature field of the transaction data packet. The credential-minting transaction data packet contains all the necessary information from the user's intent to establish ownership to the on-chain state change. Any blockchain node that obtains this data packet can verify the legality and uniqueness of the transaction by verifying the digital signature and transaction sequence number.

[0056] S400: Submit the transaction data packet to the blockchain network, and after consensus confirmation, complete the on-chain storage to obtain the corresponding block height and transaction hash.

[0057] Specifically, the token minting transaction data packet is broadcast to the blockchain network, encapsulated in binary format as a data frame conforming to the network transmission protocol, and sent to one or more peer-to-peer nodes in the blockchain network through peer-to-peer network connections. Nodes receiving the transaction data packet perform preliminary verification locally and then forward it to other peer nodes connected to them.

[0058] Each node in the blockchain network independently verifies the legality of a transaction upon receiving it. This verification includes checking if the sender's digital signature matches the sender's account address declared in the transaction data packet, confirming that the transaction was indeed initiated by the account holder and that the transaction content has not been tampered with after signing. The node also verifies if the sender's current transaction sequence number matches the transaction sequence number declared in the transaction data packet, ensuring that the transaction is not a duplicate submission of an already executed transaction. Furthermore, the node verifies if the sender's account balance is sufficient to cover the network fees incurred by the transaction, preventing transaction failure due to insufficient funds. Finally, the node verifies if the transaction data packet format conforms to the blockchain network transaction protocol specifications, including the correct length of each field and the validity of the encoding. Transactions that pass all verifications are considered valid and are placed in the node's local transaction pool to await inclusion in a block. Transactions that fail verification are discarded by the node.

[0059] In a blockchain network, the block-producing node selects a batch of transactions to be confirmed from its local transaction pool according to a certain selection strategy. The selected transactions are organized and arranged according to a specific data structure to form a candidate transaction list. This candidate transaction list, along with auxiliary information such as the hash reference of the previous block, timestamp, and digital signature of the block-producing node, are packaged together to construct a candidate block.

[0060] The completed candidate block is broadcast to all other nodes in the blockchain network. Upon receiving a candidate block, each node performs an independent consensus verification process. Each verification node first verifies whether the candidate block's format conforms to the blockchain protocol specifications, verifies whether the hash reference of the previous block in the block header points to the latest block in the current chain to ensure correct chaining of blocks, verifies whether each transaction in the block has passed legality checks and is free from double-spending, and verifies the validity of the block-producing node's digital signature to confirm the block-producing node's legitimacy. When a majority of nodes in the network have verified all the content of the candidate block and reached a consensus, the candidate block is confirmed through consensus.

[0061] The consensus-confirmed candidate blocks are appended to the end of the blockchain ledger, which in turn triggers an update to the blockchain world state database. This involves executing the smart contract call logic contained in each transaction and updating the account state and contract storage state.

[0062] By listening to event notifications on the blockchain network, the block height of the block containing the transaction and its transaction hash can be obtained. The block height and transaction hash serve as the physical coordinates and logical identifier of the transaction on the blockchain. The block height is the sequence number of a newly generated block in the blockchain. The height of the genesis block is 0 or 1, and it increases by 1 for each subsequent block. The block height and block hash together constitute the unique coordinates of a block in the blockchain, allowing precise retrieval of the block and all transactions it contains. The transaction hash is a unique identifier obtained by cryptographically hashing the entire content of a transaction data packet, serving as a unique global identifier for the transaction. Transaction hashes are unique, meaning different transaction contents have different hash values; they are also irreversible, meaning the original transaction content cannot be deduced from the hash value. Any third party can precisely retrieve the complete details of the transaction in a blockchain explorer using the transaction hash, including the transaction time, sender address, receiver address, transaction payload, and execution status.

[0063] S500: Based on the on-chain completion status, trigger the update of the blockchain world state database, establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, write the metadata access path into the state storage unit corresponding to the mapping relationship, and complete the final status determination of the confirmation data.

[0064] Specifically, after a transaction is confirmed on the blockchain, each node in the blockchain network begins executing the smart contract logic invoked by the transaction. The user's identity and metadata access path are decoded from the transaction payload. The number of currently minted credentials is read from its internally stored credential counter, and this number is incremented by 1 to serve as the on-chain credential identifier for the new credential.

[0065] Two key write operations are performed. The first write establishes a unique mapping between the newly generated credential identifier and the user identity identifier, that is, writes a record to the world state database indicating that the credential number belongs to the user address. The second write writes the metadata access path to the state storage unit corresponding to the credential identifier, that is, solidifies the rights object location information pointed to by the credential into part of the on-chain state.

[0066] After the write operation is completed, the blockchain virtual machine summarizes all state changes, calculates the new state root hash value, and writes this hash value into the block header of the new block, completing the final confirmation of the world state. The ownership confirmation data has completed the final state determination, and the unique mapping relationship between the credential identifier and the user address, as well as the corresponding metadata access path, has been permanently written into the world state database of all network nodes, becoming an immutable part of the current blockchain ledger.

[0067] S600: Output the on-chain credential identifier and the transaction hash as the confirmation result.

[0068] Specifically, once the blockchain world state database is updated and the smart contract minting event is successfully recorded on the blockchain, the on-chain credential identifier and transaction hash are retrieved from the blockchain network, organized according to a preset format, and returned to the user through the user application interface or API. After obtaining the confirmation result, the user can retrieve the complete details of the confirmed transaction in the blockchain explorer using the transaction hash, including the transaction time, sending address, and execution status. Simultaneously, the user can use the credential identifier to query the current holder of the credential in the world state, thereby proving ownership to third parties. For subsequent transfers of the credential, authorization of use, or legal action, the user can submit these two identifiers to locate the confirmation record.

[0069] Furthermore, this application also includes the following steps: obtaining an encryption mode identifier selected by the user terminal, wherein the encryption mode identifier indicates a symmetric encryption mode or an asymmetric encryption mode; if the encryption mode identifier indicates a symmetric encryption mode, generating a symmetric key and an initialization vector, performing a symmetric encryption operation on the metadata access path, and replacing plaintext with ciphertext in the encoding of the transaction payload; if the encryption mode identifier indicates an asymmetric encryption mode, obtaining the public key of the user terminal, performing an asymmetric encryption operation on the metadata access path based on the public key, and replacing plaintext with ciphertext in the encoding of the transaction payload.

[0070] Specifically, it obtains the encryption mode identifier selected by the user when initiating the rights confirmation request. This is the encryption option selected by the user through the client interface, used to indicate which encryption method is used to protect the privacy of the metadata access path.

[0071] If the user selects symmetric encryption mode, a secure random number generator is invoked to generate a symmetric key and an initialization vector. The length of the symmetric key is determined by the symmetric encryption algorithm used, typically 32 bytes; the initialization vector is a fixed-length random byte sequence, usually 16 bytes. The symmetric key and initialization vector are used to perform symmetric encryption on the complete string of the metadata access path, converting the original plaintext path into unreadable ciphertext data. After encryption, the ciphertext data replaces the original plaintext metadata access path. The symmetric key and initialization vector must be returned to the user through a secure channel for safekeeping.

[0072] If the user selects asymmetric encryption mode, the user's public key can be obtained from the user's blockchain account information or from the digital certificate provided by the user. Using this public key, an asymmetric encryption operation is performed on the complete string of the metadata access path, converting the original plaintext path into ciphertext data. After encryption, the ciphertext data replaces the original plaintext metadata access path and participates in the encoding process of subsequent transaction payloads. Because encryption uses the user's public key, only the user holding the corresponding private key can decrypt and restore the path.

[0073] After encryption is completed, the original plaintext path is replaced with ciphertext for ABI encoding and transaction construction. Only the ciphertext data is publicly stored on the chain, and no third party without the decryption key can know the actual content of the metadata access path from the on-chain data.

[0074] Furthermore, this application also includes the following steps: obtaining configuration ticketing parameters, including ticket category identifier, ticket category name, and maximum supply of ticket category; if the ticketing parameters indicate the minting of special tickets, invoking a smart contract based on the ERC-721 standard to generate a unique on-chain credential identifier for each ticket, embedding a ticket status field into the improved smart contract, and including a ticket verification method and a cancellation method, wherein the cancellation method is operated by the event organizer, and after cancellation, the ticket status changes from valid to cancelled and is uniquely held by the holder as a digital collectible; if the ticketing parameters indicate the minting of ordinary tickets, invoking a smart contract based on the ERC-1155 standard to create a ticket category with a ticket category identifier and maximum supply of ticket category in the smart contract, and minting multiple homogeneous tickets in batches under the ticket category and allocating them to target user addresses.

[0075] Specifically, if ticketing parameters indicate the minting of special tickets, a smart contract based on an improved ERC-721 standard is invoked, extending the standard ERC-721. An embedded ticket status field is added, ensuring that each credential identifier not only records the holder's address but also the ticket's current validity or redemption status. A new verification method is added for external validation of ticket validity. A new redemption method is also added, with contract-level permission checks for the event organizer's address; only pre-defined event organizer accounts can successfully invoke the method. During minting, a unique on-chain credential identifier is generated for each ticket, with each credential independently recording the holder's address and initial validity status. During ticket circulation, holders can view their tickets in wallets or platforms supporting this improved contract. When a ticket holder checks their ticket at the event venue, the event organizer invokes the redemption method, switching the ticket status of the corresponding credential identifier from valid to redeemed. After redemption, the holder's address remains unchanged, and the redeemed ticket is permanently retained as the holder's digital collectible.

[0076] If the ticketing parameters indicate the minting of ordinary tickets, a smart contract based on the ERC-1155 standard is invoked. The contract creates a new ticket class uniquely identified by a ticket class identifier, sets its name to the ticket class name in the ticketing parameters, and sets the maximum supply of this ticket class to the maximum supply in the ticketing parameters. After creation, a specified number of homogeneous tickets are minted in a single transaction and distributed to the target user addresses in one go. Under the ERC-1155 standard, each user address's balance under this ticket class increases by the corresponding amount. All tickets minted in the same batch are functionally and attribute-wise identical, requiring no individually assigned unique credential identifiers.

[0077] The public blockchain-based approach establishes the uniqueness and ownership of credentials, providing a relatively unified credential system for the protection of digital assets. This creates another protective barrier for asset security, effectively protecting personal assets from infringement.

[0078] In summary, the method for confirming digital rights certificates provided in this application has the following technical effects: By acquiring the original digital assets and user identity identifiers, the original digital assets are parsed to construct a standardized metadata object; the original digital assets are stored in a decentralized storage network to obtain a content addressing identifier, and the content addressing identifier is associated with the standardized metadata object to generate a metadata access path; based on the metadata access path, a credential minting transaction data packet is constructed according to the data interface standard specified by the on-chain smart contract, and the user identity identifier and the metadata access path are encoded as the transaction payload of the transaction data packet; the transaction data packet is submitted to the blockchain network, and after consensus confirmation, on-chain storage is completed, obtaining the corresponding block height and transaction hash; based on the on-chain completion status, the blockchain world state database is updated to establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, and the metadata access path is written into the state storage unit corresponding to the mapping relationship to complete the final state determination of the rights confirmation data; the on-chain credential identifier and the transaction hash are output as the rights confirmation result. In other words, by parsing the original digital assets to construct standardized metadata objects, the asset ontology is stored in a decentralized storage network to obtain content addressing identifiers and generate accessible paths. The user identity identifier and the path are encoded into transaction payloads and submitted to the blockchain, which forcibly triggers the update of the blockchain world state database, thus completing the finalization of the ownership data and ensuring the consistency of on-chain and off-chain data and asset security.

[0079] Example 2: Based on the same inventive concept as the method for confirming digital rights certificates in Example 1, this application also provides a system for confirming digital rights certificates. Please refer to the appendix. Figure 2The digital rights certificate confirmation system includes: a data parsing module 11, used to obtain the original digital asset and user identity identifier, parse the original digital asset, and construct a standardized metadata object; a distributed storage module 12, used to store the original digital asset in a decentralized storage network, obtain a content addressing identifier, and associate the content addressing identifier with the standardized metadata object to generate a metadata access path; and an on-chain packaging module 13, used to construct a certificate minting transaction data package based on the metadata access path and according to the data interface standard specified by the on-chain smart contract, and to package the user identity identifier and the metadata... The access path is encoded as the transaction payload of the transaction data packet; the on-chain storage module 14 is used to submit the transaction data packet to the blockchain network, complete the on-chain storage after consensus confirmation, and obtain the corresponding block height and transaction hash; the state determination module 15 is used to trigger the update of the blockchain world state database based on the on-chain completion state, establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, write the metadata access path into the state storage unit corresponding to the mapping relationship, and complete the final state determination of the rights confirmation data; the result output module 16 is used to output the on-chain credential identifier and the transaction hash as the rights confirmation result.

[0080] Furthermore, the data parsing module 11 in the digital rights certificate confirmation system is also used to: extract the attribute fields of the original digital asset, the attribute fields including asset name, asset description and asset type information; perform format normalization processing on the extracted attribute fields according to the preset data model to generate a data structure that conforms to the on-chain certificate standard, as the standardized metadata object.

[0081] Furthermore, the distributed storage module 12 in the digital rights certificate confirmation system is also used to: submit the original digital asset to the IPFS network, whereby the IPFS network calculates and generates a unique CID identifier based on the data content of the original digital asset; receive the CID identifier returned by the IPFS network, use the CID identifier as the content addressing identifier, and construct a decentralized access path for the original digital asset based on the CID identifier.

[0082] Furthermore, the distributed storage module 12 in the digital rights certificate confirmation system is also used to: encapsulate the standardized metadata object into a metadata file; store the metadata file in a decentralized storage network to obtain the metadata content addressing identifier corresponding to the metadata file; bind the metadata content addressing identifier with the content addressing identifier, and use the combined identifier after binding as the metadata access path.

[0083] Furthermore, the on-chain packaging module 13 in the digital rights certificate confirmation system is also used for: obtaining the contract address of the on-chain smart contract and its ABI definition file; parsing the method selector and parameter type list of the certificate minting method from the ABI definition file; according to the parameter type list, performing format verification and filling processing on the user identity identifier according to the address type specification to generate a first encoding parameter; performing length prefix encoding and serialization processing on the metadata access path according to the string type specification to generate a second encoding parameter; concatenating the method selector, the first encoding parameter, and the second encoding parameter according to the parameter arrangement order specified in the ABI definition to generate a call data payload; obtaining the current transaction sequence number of the user's on-chain account; and encapsulating the certificate minting transaction data packet according to the blockchain network transaction protocol specification based on the current transaction sequence number, the contract address, the call data payload, and the user's digital signature.

[0084] Furthermore, the on-chain packaging module 13 in the digital rights certificate confirmation system is also used for: the on-chain smart contract follows the ERC-721 standard protocol or the ERC-1155 standard protocol, and the transaction payload fields encapsulate method selectors and parameter encoding data that conform to the standard protocol.

[0085] Furthermore, the digital rights certificate confirmation system is also used for: obtaining an encryption mode identifier selected by the user terminal, wherein the encryption mode identifier indicates a symmetric encryption mode or an asymmetric encryption mode; if the encryption mode identifier indicates a symmetric encryption mode, generating a symmetric key and an initialization vector, performing a symmetric encryption operation on the metadata access path, and replacing plaintext with ciphertext in the encoding of the transaction payload; if the encryption mode identifier indicates an asymmetric encryption mode, obtaining the user terminal's public key, performing an asymmetric encryption operation on the metadata access path based on the public key, and replacing plaintext with ciphertext in the encoding of the transaction payload.

[0086] Furthermore, the digital rights certificate confirmation system is also used for: obtaining configuration ticketing parameters, including ticket category identifier, ticket category name, and maximum supply of the ticket category; if the ticketing parameters indicate the minting of special tickets, calling a smart contract based on the ERC-721 standard to generate a unique on-chain certificate identifier for each ticket, the improved smart contract embedding a ticket status field and including a ticket verification method and a cancellation method, the cancellation method being operated by the event organizer, after cancellation the ticket status changing from valid to cancelled and being uniquely held by the holder as a digital collectible; if the ticketing parameters indicate the minting of ordinary tickets, calling a smart contract based on the ERC-1155 standard to create a ticket category with a ticket category identifier and maximum supply of the ticket category in the smart contract, and minting multiple homogeneous tickets in batches under the ticket category and allocating them to target user addresses.

[0087] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The method and specific example for confirming the ownership of a digital rights certificate in the aforementioned embodiment one are also applicable to the system for confirming the ownership of a digital rights certificate in this embodiment. Through the foregoing detailed description of the method for confirming the ownership of a digital rights certificate, those skilled in the art can clearly understand the system for confirming the ownership of a digital rights certificate in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0088] In embodiment three, based on the same inventive concept as the method for confirming the rights of a digital rights certificate in embodiment one, this application also provides a computer-readable storage medium storing a computer program, which, when executed, implements the steps of the method for confirming the rights of a digital rights certificate as described in any one of embodiments one above.

[0089] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0090] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for confirming ownership of digital rights certificates, characterized in that, include: Obtain the original digital assets and user identity identifiers, parse the data of the original digital assets, and construct a standardized metadata object; The original digital assets are stored in a decentralized storage network to obtain a content addressing identifier, and the content addressing identifier is associated with the standardized metadata object to generate a metadata access path; Based on the metadata access path, a credential minting transaction data packet is constructed according to the data interface standard specified by the on-chain smart contract, and the user identity identifier and the metadata access path are encoded into the transaction payload of the transaction data packet; The transaction data packet is submitted to the blockchain network, and after consensus confirmation, it is stored on the chain to obtain the corresponding block height and transaction hash. Based on the completion status of on-chain, the blockchain world state database is updated, a unique mapping relationship is established between the on-chain credential identifier and the user identity identifier, the metadata access path is written into the state storage unit corresponding to the mapping relationship, and the final status of the confirmation data is settled. The on-chain credential identifier and the transaction hash are output as the confirmation result.

2. The method for confirming the ownership of digital rights certificates according to claim 1, characterized in that, The original digital assets are parsed and standardized metadata objects are constructed, including: Extract the attribute fields of the original digital asset, including asset name, asset description and asset type information; The extracted attribute fields are normalized according to the preset data model to generate a data structure that conforms to the on-chain credential standard, which serves as the standardized metadata object.

3. The method for confirming the ownership of digital rights certificates according to claim 1, characterized in that, Storing the original digital assets in a decentralized storage network to obtain a content addressing identifier includes: The original digital asset is submitted to the IPFS network, where the IPFS network calculates and generates a unique CID identifier based on the data content of the original digital asset. The system receives the CID identifier returned by the IPFS network, uses the CID identifier as the content addressing identifier, and constructs a decentralized access path for the original digital asset based on the CID identifier.

4. The method for confirming the ownership of digital rights certificates according to claim 1, characterized in that, Generate metadata access paths, including: The standardized metadata object is encapsulated into a metadata file; The metadata file is stored in a decentralized storage network to obtain the metadata content addressing identifier corresponding to the metadata file; The metadata content addressing identifier is bound to the content addressing identifier, and the combined identifier after binding is used as the metadata access path.

5. The method for confirming the ownership of digital rights certificates according to claim 1, characterized in that, Based on the aforementioned metadata access path, a credential minting transaction data package is constructed according to the data interface standard specified by the on-chain smart contract, including: Obtain the contract address and ABI definition file of the on-chain smart contract, and parse the method selector and parameter type list of the credential minting method from the ABI definition file; According to the parameter type list, the user identity identifier is format-validated and filled according to the address type specification to generate the first encoding parameter, and the metadata access path is length-prefix-encoded and serialized according to the string type specification to generate the second encoding parameter; The method selector, the first encoding parameter, and the second encoding parameter are concatenated according to the parameter arrangement order specified in the ABI definition to generate the call data payload; Obtain the current transaction sequence number of the on-chain account on the user's end, and based on the current transaction sequence number, the contract address, the call data payload, and the digital signature of the user's end, encapsulate it into the credential casting transaction data packet in accordance with the blockchain network transaction protocol specification.

6. The method for confirming the ownership of digital rights certificates according to claim 5, characterized in that, The on-chain smart contract follows the ERC-721 or ERC-1155 standard protocol, and the transaction payload fields encapsulate method selectors and parameter encoding data that conform to the standard protocol.

7. The method for confirming the ownership of digital rights certificates according to claim 1, characterized in that, Also includes: Obtain the encryption mode identifier selected by the user, wherein the encryption mode identifier indicates a symmetric encryption mode or an asymmetric encryption mode; If the encryption mode identifier indicates a symmetric encryption mode, a symmetric key and an initialization vector are generated, and a symmetric encryption operation is performed on the metadata access path to replace the plaintext in the encoding of the transaction payload; If the encryption mode identifier indicates an asymmetric encryption mode, obtain the public key of the user terminal, perform asymmetric encryption operation on the metadata access path based on the public key, and replace the plaintext with ciphertext in the encoding of the transaction payload.

8. The method for confirming the ownership of digital rights certificates according to claim 6, characterized in that, Also includes: Retrieve the ticketing parameters, which include ticket category identifier, ticket category name, and maximum ticket supply for each category; If the ticketing parameters indicate the minting of special tickets, a smart contract based on the improved ERC-721 standard is invoked to generate a unique on-chain credential identifier for each ticket. The improved smart contract embeds a ticket status field and includes a ticket verification method and a cancellation method. The cancellation method is operated by the event organizer. After cancellation, the ticket status changes from valid to cancelled and is held exclusively by the holder as a digital collectible. If the ticketing parameters indicate the minting of ordinary tickets, a smart contract based on the ERC-1155 standard is invoked. In the smart contract, a ticket class with a ticket class identifier and a maximum supply of the ticket class is created. Multiple homogeneous tickets are then minted in batches under the ticket class and allocated to the target user addresses.

9. A system for confirming the ownership of digital rights certificates, characterized in that, The steps for implementing the method for confirming ownership of a digital rights certificate according to any one of claims 1 to 8, wherein the system for confirming ownership of a digital rights certificate comprises: The data parsing module is used to obtain the original digital assets and user identity identifiers, parse the original digital assets, and construct standardized metadata objects. A distributed storage module is used to store the original digital assets to a decentralized storage network, obtain a content addressing identifier, and associate the content addressing identifier with the standardized metadata object to generate a metadata access path; The on-chain packaging module is used to construct a credential minting transaction data packet based on the metadata access path and in accordance with the data interface standard specified by the on-chain smart contract, and to encode the user identity and the metadata access path into the transaction payload of the transaction data packet; The on-chain storage module is used to submit the transaction data packet to the blockchain network, complete the on-chain storage after consensus confirmation, and obtain the corresponding block height and transaction hash. The status determination module is used to trigger the update of the blockchain world state database based on the on-chain completion status, establish a unique mapping relationship between the on-chain credential identifier and the user identity identifier, write the metadata access path into the state storage unit corresponding to the mapping relationship, and complete the final status determination of the rights confirmation data. The result output module is used to output the on-chain credential identifier and the transaction hash as the confirmation result.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the method for confirming the rights of a digital rights certificate as described in any one of claims 1 to 8.

Images