HK40091909A - Digital asset management method and related products - Google Patents

Description

Digital asset management methods and related products

Technical Field

This application belongs to the field of blockchain technology, specifically relating to a digital asset management method, a digital asset management device, a computer-readable medium, an electronic device, and a computer program product.

Background Technology

Digital assets refer to assets owned or controlled by a company or individual, existing in the form of electronic data, held in the ordinary course of business for sale, or in the process of production. Blockchain can be used for the recording and storage of digital assets; however, due to the completely decentralized nature of blockchain, any business entity can anonymously issue and hold them, making digital assets difficult to regulate and prone to speculative activities.

Summary of the Invention

The purpose of this application is to provide a digital asset management method, digital asset management device, computer-readable medium, electronic device, and computer program product that at least to some extent overcomes the technical problems of difficulties in digital asset supervision in related technologies.

Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

According to one aspect of the embodiments of this application, a digital asset management method is provided, the method comprising:

In response to asset issuance requests initiated by asset issuers, content review is conducted on the digital assets to be issued;

When the content review result is approved, the approved digital assets are saved, and a unique asset storage address is obtained;

Return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets.

The digital assets, after being signed, are uploaded to the consortium blockchain network to bind them to the asset account of the asset issuer.

The asset issuer is added to the witness network that communicates with the consortium blockchain network, so that the asset issuer can synchronously witness the on-chain data in the consortium blockchain network.

According to one aspect of the embodiments of this application, a digital asset management device is provided, the device comprising:

The review module is configured to respond to asset issuance requests initiated by asset issuers and conduct content review of the digital assets to be issued.

The storage module is configured to save the approved digital assets when the content review result is "approved", and obtain a unique asset storage address;

The signature module is configured to return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets.

The on-chain module is configured to process the signed digital assets on the consortium blockchain network to bind the digital assets to the asset account of the asset issuer.

The witnessing module is configured to add the asset issuer to a witnessing network that communicates with the consortium blockchain network, so that the asset issuer can synchronously witness the on-chain data in the consortium blockchain network.

According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the digital asset management method as described in the above technical solutions.

According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a digital asset management method as described above by executing the executable instructions.

According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the digital asset management method as described above.

In the technical solution provided in this application embodiment, the asset issuance platform reviews the digital assets requested for issuance by the asset issuer and saves the approved digital assets to a designated address, enabling the asset issuer to digitally sign the approved digital assets. Furthermore, issuing the digitally signed digital assets on the blockchain can separate the issuance right from the ownership of digital assets. That is, the asset issuance platform has the right to issue a digital asset, while the asset issuer holds the ownership of the digital asset. Therefore, it can reduce the difficulty of regulating digital assets and improve the controllability of issuing digital assets on the blockchain.

It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application.

Attached Figure Description

The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

Figure 1 shows a schematic diagram of the composition of the blockchain system in an embodiment of this application.

Figure 2 illustrates the composition structure of a blockchain maintained on a blockchain network.

Figure 3 illustrates the network architecture of a blockchain network applying the technical solution of this application.

Figure 4 shows a flowchart of the steps of a digital asset management method in one embodiment of this application.

Figure 5 shows a flowchart of the steps for content moderation of digital assets in one embodiment of this application.

Figure 6 illustrates a business process diagram of digital asset management performed by an asset issuance platform in one embodiment of this application.

Figure 7 illustrates a network architecture for managing digital assets in one embodiment of this application.

Figure 8 shows a structural block diagram of the digital asset management device provided in an embodiment of this application.

Figure 9 shows a computer system architecture block diagram for implementing an electronic device according to an embodiment of this application.

Detailed Implementation

Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and/or processor devices and/or microcontroller devices.

The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations/steps, nor do they necessarily have to be performed in the described order. For example, some operations/steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

In the specific implementation of this application, data related to the digital asset accounts and asset information of the business entity are involved. When the various embodiments of this application are applied to specific products or technologies, the permission or consent of the business entity is required, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

The relevant terms used in the embodiments of this application are explained as follows.

Asset issuance platform: Provides a channel for asset issuance, helping asset issuers issue assets on the blockchain. The asset issuer holds a pair of public and private keys and an address generated by the public key. The asset is issued to the corresponding address, which represents the asset issuer's ownership of the asset.

Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. Public blockchains offer the highest degree of decentralization. Nodes/participants in a public blockchain can read data on the chain, publish transactions, and compete for the right to record new blocks; moreover, nodes/participants can freely join and leave the public blockchain. Private blockchains, on the other hand, have their record-keeping and data reading permissions controlled by a specific organization or institution. Participants are fewer and cannot join arbitrarily; they must be approved by the organization or institution. Consortium blockchains, also known as community blockchains, are blockchains whose consensus process is controlled by pre-selected nodes. They are a hybrid of public and private blockchains, achieving "partial decentralization." Each node on the chain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of interested parties to jointly maintain the blockchain's operation. Through consortium blockchains, new participants can join an existing blockchain and share data without having to build it from scratch. Whether it's a public blockchain, a private blockchain, or a consortium blockchain, they can all potentially offer smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed through transactions on the blockchain system. Smart contracts can be defined in the form of code.

Smart contracts, also known as chaincode or application code, are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Deployed on nodes within a blockchain network, they carry the business logic for executing transactions and run in an isolated environment (such as a container or virtual machine). These contract programs, automatically executed by nodes in a blockchain system based on specific conditions, can manipulate data stored on the chain and are a crucial means for business entities to interact with the blockchain and utilize it to implement business logic. The purpose of smart contracts is to provide a more secure method than traditional contracts and reduce other transaction costs associated with contracts. They allow for trusted transactions without a third party, and these transactions are traceable and irreversible.

A blockchain is a shared digital ledger with a chained-block data structure, built on transparent and trusted rules in a peer-to-peer network environment. It is designed to be tamper-proof, tamper-proof, and traceable. The chained-block data structure stores transactions occurring over a period of time in units of blocks, which are then linked chronologically into a chain using cryptographic algorithms. The ledger is distributed to all member nodes in the network, permanently recording the history of asset transactions between peer nodes in the network within the sequential chain of blocks linked by hash cryptographic algorithms. All confirmed and verified transactions are linked from the beginning of the chain to the latest block, hence the name blockchain. A blockchain can serve as a single source of truth, and members of a blockchain network can only view transactions relevant to them.

Figure 1 illustrates the composition of a blockchain system according to an embodiment of this application. The blockchain system 100 may include at least one client 110 and a blockchain network 120. The blockchain network 120 includes at least one blockchain node 121. The client 110 may be various electronic devices such as smartphones, tablets, laptops, desktop computers, smart wearable devices, smart in-vehicle devices, smart payment terminals, and facial recognition terminals. By installing the corresponding client application, it can provide blockchain data services to business entities. The blockchain node 121 may be a terminal device or a server. For example, the blockchain node 121 may be an independent physical server, a server cluster composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

In blockchain network 120, each blockchain node 121 receives input information during normal operation and maintains shared data within the blockchain network based on the received input information. To ensure information interoperability, information connections can exist between the various blockchain nodes 121, allowing them to transmit information to each other. For example, when any blockchain node 121 in blockchain network 120 receives input information and broadcasts it within the blockchain network 120, other node devices in blockchain network 120 can obtain the input information according to a consensus algorithm and store it as shared data.

Each blockchain node 121 in the blockchain network 120 has a corresponding node identifier. Each blockchain node 121 can also store the node identifiers of other blockchain nodes in the same blockchain network, so that the generated block can be broadcast to other nodes in the blockchain network 120 based on their node identifiers. Each blockchain node 121 can maintain a node identifier list as shown in Table 1, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 shows a node identifier list using IP addresses as an example.

Table 1

Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

Figure 2 illustrates the structure of a blockchain maintained on a blockchain network. As shown in Figure 2, the blockchain consists of multiple sequentially connected blocks. Whenever new data needs to be written to the blockchain, this data is aggregated into a newly generated block. The newly generated block is then linked to the end of the blockchain. A consensus algorithm ensures that newly added blocks on each node device 121 are identical. The block body of each block records the data of the current block, while its block header stores the hash value of the preceding block. If the transaction data in the preceding block changes, the hash value of the current block will also change accordingly. Therefore, data uploaded to the blockchain network is difficult to tamper with, improving the reliability of shared data.

Figure 3 illustrates the network architecture of a blockchain network applying the technical solution of this application. As shown in Figure 3, in application scenarios involving the issuance of digital assets, the asset issuer 310, the asset issuance platform 320, and the third-party platform 330 located in the blockchain network jointly maintain one or more blockchains 340.

The asset issuer (310) is the business entity that issues and holds digital assets; it can be a corporate entity or an individual. Digital assets issued on the blockchain are owned by the corresponding asset issuer.

Asset Issuance Platform 320 is a business platform that provides asset issuance services for Asset Issuer 310. When Asset Issuer 310 needs to issue digital assets, it needs to be reviewed by Asset Issuance Platform 320. After the review is approved, Asset Issuance Platform 320 will issue the assets on its behalf. In other words, Asset Issuance Platform 320 has the right to issue digital assets.

Third-party platform 330 is a third-party institution that conducts compliance reviews and supervision of digital asset issuance, transfer, delisting and other trading businesses.

When an asset issuer 310 requests to issue digital assets on the blockchain, it can send the corresponding business request to the asset issuance platform 320, which will conduct a business review. Simultaneously, a third-party platform 330 can review and supervise the legality and compliance of the asset issuance business. Once both the asset issuance platform 320 and the third-party platform 330 have approved the request, the asset issuance platform 320 can store the digital assets to be issued on the blockchain 340, thus binding the digital assets to the asset issuer 310's asset account.

To ensure the effectiveness and credibility of the review of digital asset issuance, the review process data and results data can be stored on the blockchain 340. Decentralized data storage can effectively avoid trust crises and improve the reliability and stability of digital asset issuance.

The following detailed description, in conjunction with specific embodiments, outlines the technical solutions provided in this application, including digital asset management methods, digital asset management devices, computer-readable media, electronic devices, and computer program products.

Figure 4 shows a flowchart of the steps of a digital asset management method in one embodiment of this application. This digital asset management method is executed by the asset issuance platform shown in Figure 3. As shown in Figure 4, the digital asset management method in this embodiment of the application mainly includes the following steps S410 to S450.

Step S410: In response to the asset issuance request initiated by the asset issuer, conduct content review of the digital assets to be issued.

Digital assets to be issued include digital assets carried by digital media such as images, audio or video. The asset issuance request initiated by the asset issuer is a business request to issue digital assets on the blockchain. After the issuance of digital assets is completed, asset transactions can be carried out on the blockchain.

When an asset issuance platform receives an asset issuance request from an asset issuer, it can first conduct a content review, specifically checking whether the digital asset to be issued meets the quality standards for online issuance. If it meets the corresponding quality standards, the content review result is deemed approved. If it does not meet the corresponding quality standards, the content review result is deemed unapproved.

For example, for digital assets carried by images, the quality standards for online release can be verified by checking whether parameters such as image format, image resolution, image size, and image capacity meet the quality standards for online release; for digital assets carried by audio, the quality standards for online release can be verified by checking whether parameters such as audio format, audio sampling rate, bitrate, and number of channels meet the quality standards for online release; and for digital assets carried by video, the quality standards for online release can be verified by checking whether parameters such as video format, video resolution, frame rate, and bitrate meet the quality standards for online release.

Step S420: When the content review result is approved, save the approved digital assets and obtain a unique asset storage address.

The content stored in digital assets can include the asset object and metadata describing the asset object. The asset object can be the object itself carried by digital media such as images, audio, and video. Metadata is textual information describing the asset object, such as the asset object's name, type, and details. The asset object and metadata of a digital asset can be stored together or separately.

An asset storage address is a unique network address that can be used to locate and query digital assets. Through this network address, the storage location of the digital asset can be accurately located, thereby obtaining the asset object and its metadata.

In one embodiment of this application, the asset object and metadata of a digital asset can be stored together in the same storage location, or they can be stored separately. When the asset object and metadata of a digital asset are stored separately, the storage address of the asset object can be written into the metadata, so that the corresponding asset object can be queried through the metadata.

Step S430: Return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets.

After the asset issuance platform completes the storage of digital assets, it can return the asset storage address to the asset issuer. The digital assets that the asset issuer can query through the asset storage address are those that have been approved by the asset issuance platform. By transmitting data between the asset issuance platform and the asset issuer in the form of asset storage addresses, the consistency of the digital asset content before and after the review and signing can be guaranteed, preventing cheating during the digital asset issuance process, and also preventing data loss or leakage of digital assets.

After the asset issuer signs the approved digital assets, they obtain digitally signed digital assets. This digital signature is unique to the asset issuer and cannot be forged by other entities; it also serves as valid proof of the digital asset's authenticity. The asset issuer can either store the digitally signed digital assets at the same asset storage address or send them to the asset issuance platform.

In one embodiment of this application, the asset issuer may hold a public key and a private key that make up an asymmetric key pair. When digitally signing a digital asset, the issuer may first extract an asset digest from the digital asset using a digest extraction algorithm, and then use the private key to encrypt the asset digest to form a digital signature. This digital signature can be verified using the public key.

An asset digest is a fixed-length string that uniquely corresponds to a digital asset. It is generated by applying a one-way hash encryption function to the digital asset. If a digital asset is tampered with during the issuance process, the alteration can be determined by comparing the newly generated digest after issuance with the original digest before issuance. Therefore, the asset digest ensures the integrity of the digital asset. The asset digest uses a one-way hash function to map the plaintext of the digital asset to be issued into a string of ciphertext, also known as a digital fingerprint. The asset digest has a fixed length, and different plaintext digests will always result in different ciphertexts, while the same plaintext will always have the same digest. The digest extraction algorithm in the embodiments of this application may include, for example, MD (Message Digest), SHA (Secure Hash Algorithm), MAC (Message Authentication Code), and other algorithms.

A digital signature is a message digest algorithm with a key, consisting of a public key and a private key, used to verify data integrity, authenticate data origin, and prevent repudiation. It follows the OSI reference model, involving private key signing and public key verification. It is also a combination of asymmetric encryption and message digest algorithms. Common digital signature algorithms include RSA, DSA, and ECDSA.

Based on the RSA algorithm, a pair of RSA keys can be generated first. One is a secret key, which is kept by the business entity; the other is a public key, which can be made public and even registered on a web server. To improve security, RSA keys should be at least 500 bits long, with 1024 bits generally recommended. This makes the encryption computationally intensive. To reduce computation, when transmitting information, a combination of traditional encryption methods and public-key encryption methods is often used. That is, the information is encrypted using an improved DES or IDEA session key, and then the session key and message digest are encrypted using the RSA key. After receiving the information, the recipient decrypts it using different keys and can verify the message digest.

A key feature of DSA (Digital Signature Algorithm) is that two prime numbers are publicly disclosed. This allows any entity to verify whether p and q were randomly generated or manipulated, even without knowing the private key, when using p and q from other entities.

ECDSA (Elliptic Curve Digital Signature Algorithm) is a combination of ECC (Elliptic Curve Cryptography) and DSA. The entire signing process is similar to DSA, but the difference is that the algorithm used in the signature is ECC, and the final signed value is also divided into two parameters, r and s.

Step S440: The signed digital assets are uploaded to the consortium blockchain network to bind the digital assets to the asset issuer's asset account.

An asset issuance platform can maintain a transaction buffer pool. Whenever a digital asset with a digital signature is generated, the platform can construct an on-chain transaction based on that digital asset and store it in the transaction buffer pool. On-chain asset transactions are used to bind digital assets to the asset issuer's asset account.

Each block in a blockchain comprises two data storage areas: a block header and a block body. The block body stores all the data recorded in the current block. The block header stores the link information between the current block and the previous block. Using the data stored in the block header, all blocks can be linked one by one to form a complete blockchain. When the block generation conditions are met, asset transactions stored in the transaction buffer pool can be packaged and written into the block body of the current block to be uploaded to the blockchain. Simultaneously, the block header data of the previous block (i.e., the most recently generated block) in the blockchain network can be obtained. Based on this block header data, the parent block characteristic value of the current block can be calculated. For example, the SHA256 algorithm can be used to hash the block header data of the previous block to obtain a hash value, which can then be used as the parent block characteristic value of the current block. The block generation conditions can be a specified time threshold since the previous block was generated, a specified data volume threshold in the transaction buffer pool, or other preset conditions that trigger the generation of a new block. This application embodiment does not specifically limit these conditions.

Based on the data stored in the block body, a hash value can be obtained as the block body characteristic value of the current block. Taking hash encoding as an example, all data in the block body can be stored in the form of a Merkle tree. Specifically, the data can be stored in the leaf nodes of the Merkle tree. The data stored in every two adjacent leaf nodes is combined and hashed again to obtain the hash value stored in a child node. By using this method of combining the hash values stored in child nodes in pairs and performing hash operations layer by layer upwards, a root node hash value can be obtained. This root node hash value can be used as the block body characteristic value of the current block.

After calculating the parent block feature value and the block body feature value, a timestamp can be generated based on the current time. This timestamp records the generation time of the current block. Then, the parent block feature value, the block body feature value, and the timestamp are stored together in the block header of the current block. The current block, consisting of the block header and block body, is broadcast to the blockchain network for consensus authentication. After successful consensus authentication, all or some of the blockchain nodes in the blockchain network save the current block, thus completing the process of adding the current block to the blockchain.

Step S450: Add the asset issuer to the witness network that communicates with the consortium blockchain network, so that the asset issuer can synchronously witness the on-chain data in the consortium blockchain network.

By adding asset issuers to the witness network, it becomes possible for them to synchronously share a portion of the data on the blockchain consensus network. This enhances network openness while maintaining the security and controllability of the consortium blockchain network's data. The issuance rights of digital assets are managed by the asset issuance platform, while ownership of the digital assets remains with the asset issuer. The asset issuance platform's review process and results are stored on the blockchain and can be synchronously shared with the asset issuer through the witness network, making the asset issuance process open and transparent.

In the digital asset management method provided in this application embodiment, the asset issuance platform reviews the digital assets requested for issuance by the asset issuer and saves the approved digital assets to a designated address, enabling the asset issuer to digitally sign the approved digital assets. Further, issuing the digitally signed digital assets on the blockchain can separate the issuance right and ownership of digital assets. That is, the asset issuance platform has the right to issue a digital asset, while the asset issuer holds the ownership of the digital asset. Therefore, it can reduce the difficulty of regulating digital assets and improve the controllability of issuing digital assets on the blockchain.

Figure 5 illustrates a flowchart of the steps for content review of digital assets in one embodiment of this application. As shown in Figure 5, based on the above embodiment, the method for content review of the digital assets to be issued in step S410 may include the following steps S510 to S530.

Step S510: Parse the asset issuance request to obtain the asset information of the digital asset to be issued carried in the asset issuance request and the digital signature associated with the asset information. The asset information includes the asset object used to carry the digital asset and the metadata used to describe the digital asset.

When an asset issuer requests to issue digital assets, it can use its own private key to sign the asset information, obtain a digital signature associated with the asset information, and then send the asset information and the associated digital signature to the asset issuance platform through an asset issuance request.

Asset objects can be, for example, objects carried by digital media such as images, audio, and video. Metadata is textual information used to describe asset objects, which may include information such as the name, type, and details of the asset object.

Step S520: Verify the digital signature using the public key of the asset issuer.

By verifying the digital signatures associated with asset information, the reliability of the asset information's origin and the security of the data can be verified.

In one embodiment of this application, the public key of the asset issuer can be obtained through peer-to-peer data transmission, or the public key of the asset issuer publicly disclosed on the blockchain network can be obtained by querying the blockchain.

First, the digital signature associated with the asset information is decrypted using the asset issuer's public key to obtain the digest to be verified. Then, the asset information is processed to extract the asset digest. Finally, a consistency check is performed between the digest to be verified and the asset digest to obtain the signature verification result of the digital signature.

Signature verification of digital digests enhances the security and reliability of related data. The private key used by the asset issuer for signing and the publicly available public key on the blockchain network form an asymmetric key pair. The asset issuance platform uses the same digest algorithm as the issuer to extract the asset information, resulting in an asset digest. If the data source is accurate and the data has not been tampered with during transmission, the digest to be verified obtained after decryption using the asset issuer's public key should match the original asset digest. Therefore, if the digest to be verified matches the asset digest, the signature verification is successful; if the digest to be verified does not match the transaction digest, the signature verification fails.

Step S530: When the signature verification result is successful, perform content review on the asset information.

In one embodiment of this application, a method for content review of asset information may include: determining the asset type of the digital asset to be issued based on metadata; obtaining quality standards and a third-party platform corresponding to the asset type of the digital asset; conducting quality review of the asset information according to the quality standards; and when the quality review result is that the review is passed, initiating a review request to the third-party platform so that the third-party platform can conduct regulatory review of the asset information.

In one embodiment of this application, the asset type of a digital asset can be determined based on the type of medium carrying the digital asset. This asset type may include, for example, image assets, audio assets, video assets, etc. By identifying the asset type of a digital asset, quality standards and third-party platforms corresponding to that asset type can be obtained.

Quality standards corresponding to asset types can include audit parameters used to evaluate asset quality, as well as corresponding parameter standard values or parameter thresholds. For example, audit parameters for evaluating the quality of image assets can include at least one of several parameters such as image format, image resolution, image size, and image size; audit parameters for evaluating the quality of audio assets can include at least one of several parameters such as audio format, audio sampling rate, bitrate, and number of channels; and audit parameters for evaluating the quality of video assets can include at least one of several parameters such as video format, video resolution, frame rate, and bitrate. By comparing each audit parameter with its corresponding parameter standard value or parameter threshold, it can be determined whether the image asset meets the quality standards for online release.

Third-party platforms are institutions that conduct legality and compliance reviews of digital asset issuance in accordance with relevant laws and regulations. For different types of digital assets, regulatory review can be conducted by a unified third-party platform, or by different types of third-party platforms.

By conducting quality assessments and regulatory audits of digital assets, the platform can control the online issuance of digital assets, ensuring the quality of issuance while also managing the issuance rights and preventing speculative activities.

In one embodiment of this application, the asset objects and metadata of digital assets can be stored together using the same storage method, or they can be stored separately using different storage methods.

In one embodiment of this application, the asset storage address may include a Uniform Resource Locator (URL) for querying digital assets. When storing approved digital assets, the asset object carrying the digital asset can be saved to a distributed file system to obtain the file storage location of the asset object in the distributed file system; a URL linking to the asset object is then generated based on the file storage location.

In one embodiment of this application, the asset storage address may further include a hash pointer for querying digital assets. When storing approved digital assets, the metadata describing the digital assets can be updated according to the Uniform Resource Locator (URL); the updated metadata is saved to the blockchain to obtain the block storage location of the metadata on the blockchain; and a hash pointer for querying the metadata on the blockchain is generated based on the block storage location. Compared to ordinary pointers, hash pointers store not only the memory location of the data but also the hash value of that data. Ordinary pointers can only retrieve data, while hash pointers can also lock the data content and can be used to determine whether the data content has been modified.

In one embodiment of this application, after binding digital assets to the asset issuer's asset account, the issued digital assets can be transferred or delisted in response to a business request initiated by the asset issuer.

In one embodiment of this application, in response to an asset transfer request initiated by the asset issuer, an authorization review is performed on the digital asset to be transferred. When the authorization review result is approved, the binding relationship between the asset issuer's asset account and the digital asset is released, and the digital asset is bound to the asset recipient's asset account. The authorization review of the digital asset to be transferred may include verifying whether the asset issuer and the asset recipient have the authority to conduct the asset transaction, and may also include verifying whether the digital asset meets pre-set transaction conditions. For example, when the digital asset is launched, its transaction conditions can be agreed upon through a smart contract, and the digital asset can only be transferred if the corresponding transaction conditions are met.

In one embodiment of this application, in response to an asset delisting request initiated by the asset issuer, an authorization review is conducted on the digital asset to be delisted. When the authorization review is successful, the binding relationship between the asset issuer's asset account and the digital asset is released, and the digital asset is marked as a delisted asset. Transfer transactions of delisted assets will be restricted; they can only be transferred after the asset is relisted. The authorization review of the digital asset to be delisted may include whether the asset issuer has the authority to delist the asset, and may also include reviewing whether the digital asset meets pre-set delisting conditions. For example, when a digital asset is launched, delisting conditions can be agreed upon through a smart contract; the digital asset can only be delisted when the corresponding delisting conditions are met.

By reviewing requests for the transfer and delisting of digital assets through an asset issuance platform, the business operations of digital assets issued online can be effectively controlled, thereby improving the controllability of digital asset transactions.

Figure 6 illustrates a business process diagram of digital asset management by an asset issuance platform in one embodiment of this application. As shown in Figure 6, the management of digital assets involves an asset issuer 601, an asset issuance platform 602, and a third-party platform 603.

Asset issuer 601 is the business entity that issues and holds digital assets, such as a corporate entity or natural person. Digital assets issued on the blockchain are owned by the corresponding asset issuer. Asset issuance platform 602 is a business platform that provides asset issuance services to asset issuer 601. When asset issuer 601 needs to issue digital assets, it can undergo review through asset issuance platform 602, and after approval, asset issuance platform 602 will issue the assets on its behalf; that is, asset issuance platform 602 has the right to issue digital assets. Third-party platform 603 is a third-party institution that conducts compliance reviews and supervision of digital asset issuance, transfer, delisting, and other trading activities.

When an asset issuer 601 needs to issue digital assets, it can submit an asset issuance request to the asset issuance platform 602. Based on the asset issuance request, the assets to be reviewed can be uploaded to the asset issuance platform 602, which will conduct a business review of the assets to be reviewed. At the same time, a third-party platform 603 can conduct a legality and compliance review and supervision of the assets to be reviewed.

The asset issuance platform 602 can determine the asset type of the asset to be reviewed based on metadata; then obtain the quality standards and third-party platforms corresponding to the asset type of the asset to be reviewed; conduct quality review of the asset to be reviewed according to the quality standards; when the quality review result is that the review is passed, it can send a review request to the third-party platform 603, which will then conduct regulatory review of the asset to be reviewed.

The asset issuance platform 602 can determine the asset type of the asset to be reviewed based on the media type carrying the digital asset. This asset type may include, for example, image assets, audio assets, and video assets. By identifying the asset type of the asset to be reviewed, the platform can obtain the corresponding quality standards and third-party platforms. The quality standards corresponding to the asset type may include review parameters used to evaluate asset quality, as well as corresponding parameter standard values or parameter thresholds. For example, review parameters for evaluating the asset quality of image assets may include at least one of several parameters such as image format, image resolution, image size, and image capacity; review parameters for evaluating the asset quality of audio assets may include at least one of several parameters such as audio format, audio sampling rate, bitrate, and number of channels; and review parameters for evaluating the asset quality of video assets may include at least one of several parameters such as video format, video resolution, frame rate, and bitrate. By comparing each review parameter with its corresponding parameter standard value or parameter threshold, it can be determined whether the image asset meets the quality standards for online issuance.

When the asset issuance platform 602 and the third-party platform 603 approve the asset to be reviewed, the asset can be marked as approved. Subsequently, the asset issuance platform 602 can process the asset on-chain. After the asset is completed on blockchain 604, the approved asset can be bound to the asset account of the asset issuer 601.

When an asset issuer 601 needs to delist a digital asset, it can submit an asset delisting request to the asset issuance platform 602. This allows the asset issuance platform 602 to mark the online-issued digital asset designated by the asset issuer 601 as an asset to be delisted. The asset issuance platform 602 conducts an authorization review of the asset to be delisted. When the authorization review is successful, the platform removes the binding relationship between the asset issuer 602's asset account and the asset to be delisted, and marks the asset as delisted. Transfers of delisted assets will be restricted; they can only be transferred after the asset is relisted. The authorization review for delisted assets may include whether the asset issuer 601 has the authority to delist the asset, and may also include verifying whether the asset meets pre-set delisting conditions. For example, delisting conditions can be agreed upon through a smart contract when the asset is issued online; the asset can only be delisted if the corresponding conditions are met.

In one embodiment of this application, after the asset issuance platform 602 conducts content review of the digital assets to be issued, it can also collect process data and result data of the content review, and then process the process data and result data on the blockchain. By processing the review operation of the asset issuance platform 602 on the blockchain, the review data of the digital assets can be synchronously stored on the blockchain, enabling blockchain nodes in the blockchain network to supervise the review process of the asset issuance platform 602, while achieving decentralized archiving of the review data and improving the reliability of the online issuance of digital assets.

In one embodiment of this application, the digital assets issued by the asset issuance platform can be a type of unique digital asset, characterized by indivisibility, non-substitutability, and uniqueness. Each unit of the digital asset possesses a unique and irreplaceable identifier and is not interchangeable. In other words, the digital asset is indivisible, with the smallest unit being 1. This means that each unit of the digital asset is a unique individual.

Digital assets have numerous applications, including gaming and ticketing. For example, in gaming, digital assets can be used as in-game pets, props, clothing, or other items; in intellectual property, they can represent a painting, a song, a patent, a video, a photograph, or other intellectual property; in physical assets, tangible assets like real estate can be virtualized using digital assets, allowing them to circulate in financial markets; in record-keeping and identity verification, digital assets can be used to verify identities and various documents such as birth certificates, driver's licenses, and academic certificates, securely storing these documents in digital form to prevent misuse or tampering; in financial documents, invoices, orders, insurance policies, and bills can be converted into digital assets for trading; and in ticketing, concert tickets, movie tickets, and theater tickets can be tagged with digital assets.

Figure 7 illustrates a network architecture for managing digital assets in one embodiment of this application. As shown in Figure 7, business entity 701, acting as the asset issuer, can request the issuance of digital assets from asset issuance platform 702. Asset issuance platform 702 is used to implement business functions such as reviewing issuance requests, managing resources, and on-chain issuance.

After the asset issuance platform 702 completes the review of the digital assets, the business entity 701 can sign the digital assets, and then the asset issuance platform 702 will process the signed digital assets on the blockchain.

In the 703 blockchain consensus network, digital assets that have undergone signature processing are uploaded to the blockchain. The 703 blockchain consensus network is a consortium blockchain network used for managing digital asset transactions. A consortium blockchain, also known as a community blockchain, refers to a blockchain whose consensus process is controlled by pre-selected nodes. It is a hybrid of public and private blockchains, achieving "partial decentralization." Using a consortium blockchain network for digital asset transaction management can overcome the problems of poor controllability in public blockchains and poor openness in private blockchains, achieving open and controllable issuance and management of digital assets.

In one embodiment of this application, the asset issuance platform 702 can write the signed digital asset into the block to be added to the blockchain; broadcast the block to be added to the blockchain consensus network so that the consensus nodes in the blockchain consensus network can perform consensus authentication on the block to be added to the blockchain; when the consensus authentication result is that the authentication is successful, the block to be added to the blockchain maintained by the blockchain consensus network is added, and the block height of the blockchain is updated.

The asset issuance platform 702 and each blockchain node in the blockchain consensus network can maintain their own transaction buffer pool. Whenever a digital asset with a digital signature is generated, the asset issuance platform can construct an on-chain transaction based on that digital asset and store it in the transaction buffer pool. The on-chain transaction binds the digital asset to the asset issuer's asset account. Each block in the blockchain includes two data storage areas: a block header and a block body. The block body stores all the data recorded in the current block. The block header stores the link information between the current block and the previous block. Using the data stored in the block header, all blocks can be linked one by one to form a complete blockchain. When the block generation conditions are met, the on-chain transaction stored in the transaction buffer pool can be packaged and written into the block body of the current block to be added to the blockchain. Simultaneously, the block header data of the previous block (i.e., the most recently generated block) in the blockchain network can be obtained, and the parent block characteristic value of the current block can be calculated based on this block header data. For example, the SHA256 algorithm can be used to hash the block header data of the previous block to obtain a hash value, which can then be used as the parent block feature value of the current block. Block generation conditions can be a specified time threshold since the previous block was generated, a specified data volume threshold in the transaction buffer pool, or other preset conditions used to trigger the generation of a new block.

In one embodiment of this application, in response to a node deployment request initiated by business entity 701, the entity access interface carried in the node deployment request can be obtained, and then the entity access interface can be called to deploy the business entity's data nodes in the witness network 704. The witness network 704 is a data node network used to synchronously witness on-chain transactions of the blockchain consensus network. For example, business entity 701 includes a first business party, a second business party, and a third business party. By calling the entity access interface configured by each business party, corresponding data nodes can be deployed in the witness network 704. Each data node can witness the consortium blockchain data consensus process and consensus results, realizing partial public disclosure of the consortium blockchain network consensus data and improving the business openness and availability of the asset issuance platform.

By clearing data on the blockchain maintained by the blockchain consensus network 703, the clearing results can be synchronized to the witness network 704, which communicates with the blockchain consensus network 703.

In one embodiment of this application, the block header data of the newly added block after updating the block height and the business entity related to the blockchain header data are obtained from the data clearing results; the block header data is broadcast on the witness network to send the block header data to the data nodes deployed by the business entity in the witness network.

By deploying data nodes in the witness network, business parties can synchronously share portions of data on the blockchain consensus network, improving network openness while maintaining the security and controllability of consortium blockchain network data. The issuance rights of digital assets are managed by the asset issuance platform, while ownership of the digital assets remains with the asset issuer. The asset issuance platform's review process and results are stored on the blockchain and can be synchronously shared with the asset issuer through the synchronization network, making the asset issuance process open and transparent.

It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and/or one step may be broken down into multiple steps.

The following describes an embodiment of the apparatus described in this application, which can be used to execute the digital asset management method described in the above embodiments of this application. Figure 8 schematically shows a structural block diagram of the digital asset management apparatus provided in the embodiment of this application. As shown in Figure 8, the digital asset management apparatus 800 mainly includes:

The review module 810 is configured to review the content of the digital assets to be issued in response to the asset issuance request initiated by the asset issuer.

The storage module 820 is configured to save the approved digital assets when the content review result is "approved", and obtain a unique asset storage address.

The signature module 830 is configured to return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets.

The on-chain module 840 is configured to process the signed digital assets on the consortium blockchain network to bind the digital assets to the asset account of the asset issuer.

Witness module 850 is configured to add asset issuers to a witness network that communicates with the consortium blockchain network, so that asset issuers can synchronously witness the on-chain data in the consortium blockchain network.

In one embodiment of this application, based on the above embodiments, the review module 810 may further include:

The request parsing module 811 is configured to parse the asset issuance request to obtain the asset information of the digital asset to be issued carried in the asset issuance request and the digital signature associated with the asset information. The asset information includes an asset object for carrying the digital asset and metadata for describing the digital asset.

The signature verification module 812 is configured to verify the digital signature based on the public key of the asset issuer;

The content review module 813 is configured to review the asset information when the signature verification result is successful.

In one embodiment of this application, based on the above embodiments, the content review module 813 may be further configured to: determine the asset type of the digital asset to be issued based on the metadata; obtain the quality standards and third-party platforms corresponding to the asset type of the digital asset; conduct quality review of the asset information according to the quality standards; and when the quality review result is that the review is passed, initiate a review request to the third-party platform so that the third-party platform can conduct regulatory review of the asset information.

In one embodiment of this application, based on the above embodiments, the asset storage address includes a Uniform Resource Locator (URL) for querying the digital asset; the storage module 820 may further include:

The object storage module 821 is configured to save the asset object used to carry the digital asset to a distributed file system, and obtain the file storage location of the asset object in the distributed file system;

The locator generation module 822 is configured to generate a Uniform Resource Locator (URL) that links to the asset object based on the file's save location.

In one embodiment of this application, based on the above embodiments, the asset storage address further includes a hash pointer for querying the digital asset; the storage module 820 may further include:

Metadata update module 823 is configured to update the metadata used to describe the digital asset based on the Uniform Resource Locator;

Metadata storage module 824 is configured to save updated metadata to the blockchain, thereby obtaining the block storage location of the metadata on the blockchain;

The pointer generation module 825 is configured to generate a hash pointer for querying the metadata on the blockchain based on the block storage location.

In one embodiment of this application, based on the above embodiments, the digital asset management device 800 further includes an asset transfer module 860, which is configured to: respond to an asset transfer request initiated by the asset issuer, perform an authorization review on the digital asset to be transferred; when the authorization review result is approved, release the binding relationship between the asset issuer's asset account and the digital asset, and bind the digital asset to the asset recipient's asset account.

In one embodiment of this application, based on the above embodiments, the digital asset management device 800 further includes an asset delisting module 870, which is configured to: respond to an asset delisting request initiated by the asset issuer, perform permission review on the digital asset to be delisted; when the permission review result is approved, remove the binding relationship between the asset issuer's asset account and the digital asset, and mark the digital asset as a delisted asset.

In one embodiment of this application, based on the above embodiments, the digital asset management device 800 further includes an audit and on-chain module 880, which is configured to: collect process data and result data of content audit; and perform on-chain processing on the process data and result data.

In one embodiment of this application, based on the above embodiments, the digital asset includes digital assets, and the on-chain module 840 may further include:

The asset on-chain module 841 is configured to perform on-chain processing on digital assets that have undergone signature processing in a blockchain consensus network, wherein the blockchain consensus network is a consortium blockchain network used for transaction management of the digital assets.

The data synchronization module 842 is configured to perform data clearing on the blockchain maintained by the blockchain consensus network and synchronize the data clearing results to the witness network that communicates with the blockchain consensus network. The witness network is a data node network used to synchronously witness on-chain transactions of the blockchain consensus network.

In one embodiment of this application, based on the above embodiments, the asset on-chain module 841 can be further configured to: write the digital asset after signature processing into the block to be on-chain; broadcast the block to be on-chain on the blockchain consensus network so that the consensus nodes in the blockchain consensus network can perform consensus authentication on the block to be on-chain; when the consensus authentication result is successful, add the block to be on-chain to the blockchain maintained by the blockchain consensus network and update the block height of the blockchain.

In one embodiment of this application, based on the above embodiments, the data synchronization module 842 may be further configured to: obtain the block header data of the newly added block after updating the block height and the business entity related to the blockchain header data from the data clearing results; broadcast the block header data on the witness network to send the block header data to the data nodes deployed by the business entity in the witness network.

In one embodiment of this application, based on the above embodiments, before sending the block header data to the data node deployed by the business entity in the witness network, the on-chain module 840 may further include a node deployment module 843, which is configured to: in response to a node deployment request initiated by the business entity, obtain the entity access interface carried in the node deployment request; and call the entity access interface to deploy the data node of the business entity in the witness network.

The specific details of the digital asset management device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

Figure 9 schematically illustrates a computer system architecture block diagram for implementing an electronic device according to an embodiment of this application.

It should be noted that the computer system 900 of the electronic device shown in Figure 9 is only an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

As shown in Figure 9, the computer system 900 includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 902 or programs loaded from storage section 908 into random access memory (RAM) 903. The RAM 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input/output interface 905 (I/O interface) is also connected to the bus 904.

The following components are connected to the input/output interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a local area network card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input/output interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and/or installed from removable medium 911. When the computer program is executed by central processing unit 901, it performs various functions defined in the system of this application.

It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims (16)

1. A digital asset management method, characterized in that it includes: In response to asset issuance requests initiated by asset issuers, content review is conducted on the digital assets to be issued; When the content review result is approved, the approved digital assets are saved, and a unique asset storage address is obtained; Return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets. The digital assets, after being signed, are uploaded to the consortium blockchain network to bind them to the asset account of the asset issuer. The asset issuer is added to the witness network that communicates with the consortium blockchain network, so that the asset issuer can synchronously witness the on-chain data in the consortium blockchain network. 2. The digital asset management method according to claim 1, characterized in that, the content review of the digital assets to be issued includes: The asset issuance request is parsed to obtain the asset information of the digital asset to be issued carried in the asset issuance request and the digital signature associated with the asset information. The asset information includes an asset object used to carry the digital asset and metadata used to describe the digital asset. The digital signature is verified using the public key of the asset issuer. When the signature verification result is successful, the asset information is subject to content review. 3. The digital asset management method according to claim 2, characterized in that, content review of the asset information includes: The asset type of the digital asset to be issued is determined based on the metadata; Obtain quality standards and third-party platforms corresponding to the asset type of the digital asset; The asset information shall be audited in accordance with the aforementioned quality standards; When the quality audit results in a pass, an audit request is sent to the third-party platform so that the third-party platform can conduct a regulatory review of the asset information. 4. The digital asset management method according to claim 1, characterized in that the asset storage address includes a Uniform Resource Locator (URL) for querying the digital asset; storing approved digital assets includes: The asset object used to carry the digital asset is saved to the distributed file system, and the file storage location of the asset object in the distributed file system is obtained. Generate a Uniform Resource Locator (URL) that links to the asset object based on the file's storage location. 5. The digital asset management method according to claim 4, characterized in that the asset storage address further includes a hash pointer for querying the digital asset; storing approved digital assets further includes: Update the metadata describing the digital asset based on the Uniform Resource Locator; The updated metadata is saved to the blockchain, and the block location of the metadata on the blockchain is obtained; A hash pointer is generated based on the block storage location for querying the metadata on the blockchain. 6. The digital asset management method according to claim 1, characterized in that, after binding the digital asset to the asset issuer's asset account, the method further includes: In response to an asset transfer request initiated by the asset issuer, the system performs an authorization review of the digital assets to be transferred. When the permission review result is approved, the binding relationship between the asset issuer's asset account and the digital asset is removed, and the digital asset is bound to the asset recipient's asset account. 7. The digital asset management method according to claim 1, characterized in that, after binding the digital asset to the asset issuer's asset account, the method further includes: In response to asset delisting requests initiated by asset issuers, the system conducts access control reviews of the digital assets to be delisted. When the permission review result is approved, the binding relationship between the asset issuer's asset account and the digital asset is removed, and the digital asset is marked as a delisted asset. 8. The digital asset management method according to claim 1, characterized in that, after content review of the digital assets to be issued, the method further includes: Collect process and result data for content review; The process data and result data are then processed and uploaded to the blockchain. 9. The digital asset management method according to any one of claims 1 to 8, characterized in that, the digital assets after signature processing are processed for on-chain processing in a consortium blockchain network, including: In a blockchain consensus network, digital assets that have undergone signature processing are uploaded to the blockchain. The blockchain consensus network is a consortium blockchain network used for transaction management of the digital assets. The blockchain maintained by the blockchain consensus network is cleared, and the clearing results are synchronized to the witnessing network that communicates with the blockchain consensus network. The witnessing network is a data node network used to synchronously witness the on-chain transactions of the blockchain consensus network. 10. The digital asset management method according to claim 9, characterized in that, the digital assets after signature processing are processed for on-chain processing in a blockchain consensus network, including: Write the signed digital assets into the block to be added to the blockchain; The block to be added to the blockchain is broadcast on the blockchain consensus network so that the consensus nodes in the blockchain consensus network can perform consensus authentication on the block to be added to the blockchain. When the consensus authentication result is successful, the block to be added to the blockchain is added to the blockchain maintained by the blockchain consensus network, and the block height of the blockchain is updated. 11. The digital asset management method according to claim 9, characterized in that synchronizing the data clearing result to the witness network that communicates with the blockchain consensus network includes: Obtain the block header data of the newly added block after updating the block height, as well as the business entities related to the blockchain header data, from the data clearing results; The block header data is broadcast on the witness network to send the block header data to the data nodes deployed by the business entity in the witness network. 12. The digital asset management method according to claim 11, characterized in that, before sending the block header data to the data node deployed by the business entity in the witness network, the method further includes: In response to a node deployment request initiated by a business entity, obtain the entity access interface carried in the node deployment request; The main access interface is invoked to deploy the data node of the business entity in the witness network. 13. A digital asset management device, characterized in that it comprises: The review module is configured to respond to asset issuance requests initiated by asset issuers and conduct content review of the digital assets to be issued. The storage module is configured to save the approved digital assets when the content review result is "approved", and obtain a unique asset storage address; The signature module is configured to return the asset storage address to the asset issuer so that the asset issuer can sign the approved digital assets. The on-chain module is configured to process the signed digital assets on the consortium blockchain network to bind the digital assets to the asset account of the asset issuer. The witnessing module is configured to add the asset issuer to a witnessing network that communicates with the consortium blockchain network, so that the asset issuer can synchronously witness the on-chain data in the consortium blockchain network. 14. A computer-readable medium, characterized in that a computer program is stored on the computer-readable medium, and the computer program, when executed by a processor, implements the digital asset management method according to any one of claims 1 to 12. 15. An electronic device, characterized in that it comprises: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to cause the electronic device to perform the digital asset management method according to any one of claims 1 to 12 by executing the executable instructions. 16. A computer program product comprising a computer program, characterized in that, when the computer program is executed by a processor, it implements the digital asset management method according to any one of claims 1 to 12.