Blockchain-based digital human management methods, devices, electronic equipment, and media

Abstract

This application discloses a blockchain-based digital human management method, device, electronic device, and medium, relating to the field of blockchain technology. The method includes: determining target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information; storing the target information in a multi-branch tree within the blockchain corresponding to the digital human; if the multi-branch tree meets preset compression conditions, performing node compression storage on the multi-branch tree to obtain a target block, and uploading the target block to the blockchain for consensus storage. This application improves the accuracy of configuration information configuration for digital humans, saves storage space, and thus improves the intelligence level of digital humans.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method, apparatus, electronic device, and medium for managing digital humans based on blockchain. Background Technology

[0002] In scenarios involving digital human intelligent customer service or business assistants, the configuration information related to the text content, dynamics and business processes, business interfaces called, and business system pages redirected to by the digital human is all configured in the digital human configuration platform. However, the configuration process lacks a verification process. If the initial configuration is incorrect or an error occurs during configuration changes, uncontrollable situations may arise when the digital human intelligent customer service or business assistant (hereinafter referred to as the digital human) provides services to users, leading to a failure to provide services normally. For example, if the configured digital human actions are incorrect, the digital human may display erroneous screens that do not match the content and scenario being broadcast. Furthermore, as user evaluation information for the digital human increases, the storage space occupied by storing evaluation information will increase, thus affecting the normal operation of the digital human.

[0003] Therefore, due to the low accuracy of configuration information for digital humans and the inability to store a large amount of evaluation information, the intelligence level of digital humans is low. Summary of the Invention

[0004] The main objective of this invention is to provide a blockchain-based digital human management method, device, electronic device, and medium, aiming to solve the technical problem of how to improve the intelligence level of digital humans.

[0005] To achieve the above objectives, this application provides a blockchain-based digital human management method, comprising the following steps:

[0006] Determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information;

[0007] The target information is stored in a multi-branch tree within the blockchain corresponding to the digital human;

[0008] If the multi-branch tree meets the preset compression conditions, then the nodes of the multi-branch tree are compressed and stored to obtain the target block, and the target block is uploaded to the blockchain for consensus storage.

[0009] Optionally, after determining the target information corresponding to the digital human, the process includes:

[0010] If the target information includes configuration information, and the configuration information is at least one of default configuration data and static configuration data, then it is detected whether the configuration information matches the stored data contained in the smart contract in the blockchain;

[0011] If the configuration information matches the stored data, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

[0012] Optionally, after determining the target information corresponding to the digital human, the method further includes:

[0013] If the target information includes configuration information, and the configuration information is dynamic configuration data, then it is detected whether the dynamic configuration data triggers the smart contract function contained in the smart contract in the blockchain, wherein the dynamic configuration data is configuration data sent by the business party account;

[0014] If a smart contract function is triggered, a modification confirmation message is generated based on the smart contract function and the configuration information, and the modification confirmation message is sent to the configuration party's account.

[0015] If a confirmation message is received from the configuration account, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

[0016] Optionally, before the step of storing the target information into the multi-branch tree of the block corresponding to the digital human identifier in the blockchain, the method further includes:

[0017] The root node is determined based on the root node hash value calculated based on the target information, and two child nodes are constructed with the root node as the parent node, wherein the two child nodes include a configuration node and an evaluation node;

[0018] A configuration subtree is constructed with the configuration node as the parent node, wherein the configuration subtree includes at least one configuration node;

[0019] An evaluation subtree is constructed with the evaluation node as the parent node, wherein the evaluation subtree includes at least one evaluation node;

[0020] A multi-branch tree is determined based on the root node, the configuration subtree, and the evaluation subtree, and the multi-branch tree is attached to the block in the blockchain corresponding to the digital human identifier.

[0021] Optionally, the step of storing the target information into a multi-branch tree in the blockchain corresponding to the digital human includes:

[0022] If the target information includes configuration information, then the configuration information is stored in a configuration node within the configuration subtree of the multi-way tree, wherein the configuration node storing the configuration information is a child node of the root node in the multi-way tree;

[0023] If the target information includes evaluation information, then the evaluation information is stored in the evaluation node of the evaluation subtree in the multi-branch tree.

[0024] Optionally, if the multi-way tree meets preset compression conditions, the step of compressing and storing the nodes of the multi-way tree to obtain the target block includes:

[0025] If the number of leaf nodes in the multi-way tree is greater than the preset number of nodes, then the multi-way tree is determined to meet the preset compression condition, wherein the leaf nodes include nodes in the configuration subtree and / or evaluation subtree of the multi-way tree;

[0026] Extract the data from the leaf nodes of the multi-way tree and form a first JSON structure. In the first JSON structure, use the upstream content as the value and the upstream timestamp as the primary key to compress the data and obtain the first compressed data.

[0027] The first compressed data is stored in the parent node of the leaf node, the leaf node is deleted, and the adjusted multi-way tree is obtained. The block with the adjusted multi-way tree is taken as the target block.

[0028] Optionally, if the multi-way tree meets preset compression conditions, the step of compressing and storing the nodes of the multi-way tree to obtain the target block further includes:

[0029] If a leaf node in a multi-way tree has a storage number of bytes greater than a preset number of bytes, then the multi-way tree is determined to meet the preset compression condition, and the leaf node with a storage number greater than the preset number of bytes is taken as the target leaf node.

[0030] Extract the number of nodes at the same level as the target leaf node to form a second JSON structure. In the second JSON structure, use the upstream timestamp as the primary key and the upstream content as the value to compress the data and obtain the second compressed data.

[0031] The second compressed data is stored in the parent node of the second leaf node to obtain the adjusted multi-branch tree, and the block with the adjusted multi-branch tree is used as the target block.

[0032] Furthermore, to achieve the above objectives, this application also provides a blockchain-based digital human management device, comprising:

[0033] A determination module is used to determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information;

[0034] The storage module is used to store the target information into a multi-branch tree in the blockchain corresponding to the digital human;

[0035] The compression module is used to compress and store the nodes of the multi-branch tree if the multi-branch tree meets the preset compression conditions, obtain the target block, and upload the target block to the blockchain for consensus storage.

[0036] In addition, to achieve the above objectives, this application also provides an electronic device, which includes: a memory, a processor, and a blockchain-based digital human management program stored on the memory and executable on the processor. When the blockchain-based digital human management program is executed by the processor, it implements the steps of the blockchain-based digital human management method described above.

[0037] In addition, to achieve the above objectives, this application also provides a medium, including a computer-readable storage medium, on which a blockchain-based digital human management program is stored, wherein when the blockchain-based digital human management program is executed by a processor, it implements the steps of the blockchain-based digital human management method as described above.

[0038] This application embodiment determines the target information corresponding to the digital human, stores the target information in a multi-branch tree within the blockchain corresponding to the digital human, and performs node compression storage on the multi-branch tree to reduce the storage resources occupied by the block before sending the block to the blockchain for consensus storage. Therefore, by storing the target information corresponding to the digital human in each node of the blockchain through blockchain consensus storage, losses due to human error or forgetfulness, and missed confirmations are reduced, thereby improving the accuracy of configuring information for the digital human.

[0039] Furthermore, since the target information includes at least one of configuration information and evaluation information, and multi-branch trees can perform node compression storage, storing at least one of the configuration information and evaluation information through a multi-branch tree saves storage space, allowing for the storage of more evaluation information without affecting the normal operation of the digital human. Therefore, the embodiments of this application improve the accuracy of configuring the configuration information of the digital human, thereby enabling the storage of more evaluation information without affecting the normal operation of the digital human, and improving the intelligence level of the digital human. Attached Figure Description

[0040] Figure 1 A schematic diagram of the system architecture for a digital human;

[0041] Figure 2 This is a flowchart illustrating the first embodiment of the blockchain-based digital human management method of this application;

[0042] Figure 3 This is a schematic diagram of the smart contract architecture in the blockchain-based digital human management method of this application;

[0043] Figure 4 This is a schematic diagram of the data confirmation template in the blockchain-based digital human management method of this application;

[0044] Figure 5 This is a flowchart illustrating the second embodiment of the blockchain-based digital human management method of this application;

[0045] Figure 6 This is a schematic diagram of a multi-branch tree in the blockchain-based digital human management method of this application;

[0046] Figure 7 This is a schematic diagram of the module of the blockchain-based digital human management device of this application;

[0047] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the blockchain-based digital human management method of this application.

[0048] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0050] In scenarios involving digital human intelligent customer service or business assistants (hereinafter referred to as digital humans), the system architecture is generally divided into an AI (Artificial Intelligence) capability layer, a business interface layer, and a business layer. The digital human intelligent business assistant from Digital Intelligence Business Travel will be used as an example for illustration. Its system architecture diagram is as follows: Figure 1As shown, it includes business modules, basic business components, business APIs (Application Programming Interfaces), a knowledge base, voice AI, and digital humans. The business modules can include multiple modules, such as business consultation, business processing, process consultation, and product marketing. Basic business components can include multiple components, such as a floating digital human entry point, a voice input box, a chat dialog box, and information presentation and confirmation boxes. Business APIs include multiple APIs, such as flight search API, flight order API, flight refund API, flight rescheduling API, hotel search API, hotel order API, hotel cancellation API, and work order API. The knowledge base can include multiple functions, such as knowledge base configuration, dictionary management, interactive pop-up management, and a business API integration configuration platform. Voice AI can include multiple functions, such as speech-to-text, text segmentation, intent recognition, text-to-speech, dialect switching, multi-turn dialogue, voice changing, and an SDK (Software Development Kit). The digital human includes multiple functional settings, such as dialect settings, gesture and lip-sync matching, live streaming integration, SDK, digital human generation from photos, digital human generation from videos, 2D (two-dimensional interactive animation) digital human, and a digital human configuration platform.

[0051] The interaction process between the digital human and the user can begin when the user clicks on the digital human in the digital human's business interface, leading to the digital human's interactive interface and display. The digital human broadcasts a default welcome message (one of the configuration information) configured on the digital human platform in the form of voice and facial expressions. Optionally, the broadcast can be real-time or non-real-time. Real-time broadcast means that the digital human's driving engine generates streaming media information in real time based on information such as text, actions, business processes, and called business interfaces; non-real-time broadcast means that streaming media information is generated in advance based on preset information such as text, actions, business processes, and called business interfaces in offline scenarios.

[0052] If user input is detected, the input methods include text box input and voice box input. The input information can be the user's desired transaction, such as the system's usage process, consultation rules, and transaction details. Input methods can include single-turn and multi-turn input. Taking booking a flight as an example, a single-turn input would be "Book me a flight from Beijing to Shanghai on June 1st." A multi-turn input would include multiple options, such as "I want to book a flight," "I'm departing from Beijing," "My destination is Shanghai," and "I'm departing on the morning of June 1st." When the user uses multi-turn input, the digital human will provide guided questions based on the configured workflow. For example, if the configured workflow is: Time - Departure Point - Destination Point, the scenario could be: User says: I want to book a flight; Digital human replies: Where are you departing from? User says: I'm departing from Beijing. Digital human replies: What is your destination? User says: My destination is Shanghai. Digital human replies: When do you plan to depart? User says: I'm departing on the morning of June 1st.

[0053] Optionally, when the digital human intelligent assistant receives text or voice from the server after the digital human interaction page, it performs word segmentation, intent recognition, and scenario matching (system usage flow, consultation business rules, and business processing are all different types of scenarios) on the text (voice is first converted to text). Based on the identified scenario, the digital human intelligent assistant acquires data (usually configured on the digital human operation platform). For example, for consultations on system usage flow and business rules, matching can be performed using configured knowledge base information; for business processing, the corresponding business interface is called to obtain data. Taking booking airline tickets as an example, based on the user's information and travel information (time, departure point, destination, mode of travel, etc.), the corresponding business interface is called to obtain various flights within the corresponding time period and cabin class suitable for the user level. The digital human displays this information in a pop-up window for the user to view, and simultaneously reads the corresponding content aloud via voice. Users can view content in the list. If they need to view details, they can click on a list item to be redirected to the business system's H5 details page (an H5 page designed using HTML5 front-end technology, i.e., a mobile page). After viewing the details, users can place an order on the H5 details page or return to the digital human H5 page. If users want to place an order directly, they can interact with the digital human via voice or text, such as saying "the second one," and the digital human will recognize the voice and place the order by selecting the second list item. After the business is completed, users can evaluate the service provided by the digital human.

[0054] Optionally, in the above process, the configuration information such as the text content, actions (including facial expressions), business processes, called business interfaces, and H5 page links of the business systems to which the digital human is redirected are all configured on the digital human configuration platform, while the evaluation of the digital human is stored in the database. However, due to the low accuracy of the configuration information for the digital human and the inability to store a large amount of evaluation information, the intelligence level of the digital human is low.

[0055] Therefore, this embodiment provides a blockchain-based digital human management method to circumvent the aforementioned shortcomings. Optionally, the configuration information required by the digital human during interaction (including various configuration contents, such as the initialization of digital human actions, expressions, and business processes, and changes to digital human actions, expressions, and business processes) must be configured on the blockchain and confirmed by the business party (i.e., the business party account in the following embodiment) to reach a consensus for on-chain storage. This ensures the immutability and reliability of the various configuration contents required by the digital human during interaction. When the digital human interacts with the user, authentication and verification of the required configuration contents of the digital human are performed from the blockchain to verify the legality of the various configuration contents required by the digital human (such as actions, expressions, and business processes). This ensures the accuracy and validity of the digital human configuration information. Furthermore, the evaluation of the digital human after completing the service will be stored on the blockchain. Based on the characteristics of small configuration information data and large evaluation information, a multi-branch tree storage with data compression capabilities is used. The multi-branch tree structure can be mounted in a block with a digital ID (IdentityDocument) as the main chain block to save storage space. This enables the configuration and use of the configuration information (such as actions, expressions, and business processes) required by digital humans in interactions, and the evaluation data of digital humans are all used in a way based on blockchain consensus. This avoids the phenomenon of incorrect configuration of the configuration information required by digital humans in interactions, improves the authenticity and reliability of the evaluation data corresponding to digital humans, and enhances the intelligence level of digital humans.

[0056] Optionally, the blockchain-based digital human management method in this embodiment can be closely integrated with blockchain (such as consortium blockchain).

[0057] Reference Figure 2 This application provides a blockchain-based digital human management method. In the first embodiment of the blockchain-based digital human management method, the method includes:

[0058] Step S10: Determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information;

[0059] In this embodiment, the digital human can be a virtual terminal machine, a simulated robot, or an intelligent program. The target information includes configuration information and evaluation information. The configuration information can include newly added and modified configuration information, encompassing various configuration elements such as text content, facial expressions, business processes, called business interfaces, and redirected business system H5 pages. The evaluation information can be information submitted by the user regarding the digital human. Optionally, the configuration information can be confirmed and configured by the digital human page developer (e.g., the configuration account) and / or the digital human business entity (e.g., the business account). The evaluation information can be submitted by the user using the digital human.

[0060] Optionally, during the digital human configuration and interaction process, the business account can use static configuration data pushed by the configuration account (such as the emoticons and actions corresponding to the digital human's welcome message, a static question-and-answer knowledge base, called business interfaces, and adjusted business system H5 business processes, etc.), as well as configure (or modify) the actions, emoticons, and business processes during the digital human interaction process. Optionally, the actions, emoticons, and business processes during the digital human interaction process can be maintained and changed at any time through the business account according to its needs.

[0061] Optionally, before the digital human interacts with the user, it is necessary to determine the configuration information (including various configuration contents) of the digital human and store the configuration information on the blockchain. Then, the digital human interacts with the user to complete various service tasks. After the service is completed, the user can evaluate the service, generate corresponding evaluation information, and store the evaluation information in the blockchain.

[0062] Optionally, if the digital human's configuration information has not been set, initial configuration information needs to be obtained first, and this initial configuration information is uploaded to the blockchain for storage as the target information. Optionally, the blockchain must at least include the node where the digital human management system resides. If the digital human's configuration information needs to be updated during its use, updated configuration information sent by the configuration party's account or the business party's account can be obtained, and this updated configuration information can be uploaded to the blockchain for storage as the target information. For example, various configuration contents required by the digital human in interaction, such as text content, actions and expressions, business processes, called business interfaces, and redirected business system H5 pages, are uploaded to the blockchain.

[0063] Optionally, if evaluation information targeting a digital human is received from a user or other type of account, the evaluation information can be uploaded to the blockchain for storage as target information.

[0064] Optionally, the target information can be sent to a node in the blockchain so that the target information can be processed on the blockchain through the nodes in the blockchain.

[0065] Step S20: Store the target information in the multi-branch tree of the block corresponding to the digital human in the blockchain;

[0066] Optionally, after receiving the target information, a blockchain node can upload the target information to all nodes within the blockchain for consensus. After consensus is reached, the target information is stored in each node of the blockchain, and the method of storing the target information can be the same across all nodes. Optionally, in any node of the blockchain, the blockchain link can be determined, and the block corresponding to the digital human in that link, as well as the multi-branch tree attached to that block, can be identified. Optionally, different identifiers can be pre-set for different digital humans and used as digital human identifiers, and it is suggested that different blocks in the blockchain correspond to different digital human identifiers. Optionally, each digital human has a different digital human identifier, and each digital human identifier corresponds one-to-one with a block in the blockchain.

[0067] Optionally, after determining the target information in a node of the blockchain, it can be determined whether the target information contains a digital human identifier. If it is determined that the target information contains a digital human identifier, the block corresponding to the digital human identifier is determined, and a multi-branch tree is attached to the block based on the digital human identifier. The target information is then stored in the multi-branch tree.

[0068] Optionally, in order to improve the accuracy and effectiveness of the configuration information of the digital human, the configuration information can be authenticated and verified based on the smart contract in the blockchain. After successful authentication and verification, the configuration information is stored in a multi-branch tree, and the block corresponding to the digital human identifier is updated based on the multi-branch tree storing the configuration information. The updated block is then uploaded to the blockchain so that the nodes in the blockchain can perform consensus storage.

[0069] Optionally, the evaluation information can be directly stored in the multi-branch tree of the block corresponding to the digital human identifier. Alternatively, the evaluation information can be authenticated and verified, and the authentication and verification method can be the same as that used for the configuration information.

[0070] Step S30: If the multi-branch tree meets the preset compression conditions, then the nodes of the multi-branch tree are compressed and stored to obtain the target block, and the target block is uploaded to the blockchain for consensus storage.

[0071] Optionally, the multi-way tree in the block can be detected in real time through smart contracts within the blockchain. This could involve detecting the number of bytes stored in each node of the multi-way tree, or detecting the number of nodes in the multi-way tree, to determine the storage resources occupied by the multi-way tree. Optionally, if storage resources are excessive, it can be determined that the multi-way tree meets preset compression conditions and needs to be compressed. Optionally, other rules can also be used to determine whether multi-way tree compression is necessary. If multi-way tree compression is required, node compression can be performed, such as compressing the nodes within the multi-way tree. The block containing the compressed multi-way tree is then used as the target block, and the target block is uploaded to the blockchain for consensus storage through blockchain nodes. In other words, the target block is stored in the local storage space of each node in the blockchain.

[0072] Optionally, in this embodiment, the configuration content required by the digital human during interaction (such as text content, actions (including expressions), business processes, called business interfaces, and redirected business system H5 pages) is recorded on the blockchain. During user interaction, this configuration content continuously undergoes authentication and data acquisition with the blockchain. Furthermore, dual verification of the configuration account and business account is performed on the blockchain based on smart contracts, and consensus is reached on the blockchain. Optionally, data already configured on the digital human operation platform, such as interactive expressions, actions, and business configurations, will be automatically triggered by smart contracts to verify the business side, and the feedback results will be recorded on the blockchain. After calculation by the smart contract, the data will be packaged into blocks and stored in the blockchain to form consensus, thereby reducing losses due to human error or omissions in configuration and confirmation. Optionally, data already configured on the digital human operation platform, such as interactive expressions, actions, and business configurations, needs to be authenticated from the blockchain to verify the legality of the digital human's actions, expressions, and business processes, thereby comprehensively ensuring the accuracy of the configuration information required by the digital human. Furthermore, when digital human actions, expressions, and business processes are used by the digital human, blockchain provides authentication capabilities, helping the digital human to support information dissemination through legitimate digital human actions, expressions, and business processes. Optionally, a multi-branch tree is used to store the digital human's configuration information (such as text content, actions (including expressions), business processes, called business interfaces, and redirected business system H5 pages) and evaluation information. Based on smart contracts, data in the multi-branch tree is compressed layer by layer towards the intermediate nodes, thereby saving storage space.

[0073] Furthermore, before performing the operation of uploading the target information to the blockchain in this embodiment, it is necessary to set up a smart contract on the blockchain and upload it to the blockchain for consensus storage.

[0074] Optionally, before uploading the target information to the blockchain, the smart contract corresponding to the digital human needs to be configured and uploaded to the blockchain, that is, the blockchain smart contract needs to be configured. Optionally, this can be done by obtaining and editing the smart contract, and publishing the smart contract to a node in a blockchain such as a consortium blockchain. After receiving the smart contract, the node in the consortium blockchain packages it into a block and publishes it to the consortium blockchain. The nodes in the consortium blockchain then reach a consensus on the block containing the smart contract through a consensus algorithm and store it in their local storage space. This completes the uploading of the smart contract to the blockchain.

[0075] Optionally, refer to Figure 3 A smart contract can include a contract metadata area, a contract data area, a contract area, and a contract data verification area. Optionally, the contract metadata area mainly contains the contract's metadata information. Fields can include contract number (string field type, field name: contract_num), contract name (string field type, field name: contract_name), contract version (string field type, field name: contract_version), and contract triggering method (integer field type, field name: contract_runway). Optionally, contract triggering methods include multiple types, such as real-time triggering and timed triggering. For real-time triggering, contract_runway = 0; for timed triggering, the trigger time is written as an integer string, such as 2023-04-10 10:00:00, which can be written as 20230410100000.

[0076] contract_runway=20230410100000.

[0077] Optionally, the contract data area can contain multiple fields, such as dataPreChg (data before modification), dataAfterChg (data after modification), DadaSender (the sender of configuration data configuration or modification, such as the configuration party's account), DataChecker (the confirmer of configuration data configuration or modification, such as the business party's account), DataConfirmation Method (dataCheckType), DataConfirmation Content Template (dataCheckTemplate), and Digital Human ID.

[0078] Optionally, the data before modification (dataPreChg) and the data after modification (dataAfterChg) are empty when the smart contract is uploaded to the blockchain. The contract's data structure is reused only when data modification requires uploading to the blockchain for smart contract parsing. Optionally, when the smart contract is uploaded to the blockchain, Party B will configure a whitelist of data senders so that the contract function can verify the legitimacy of the data sender. Optionally, the whitelist of data senders can be accounts on the digital human operation platform with relevant permissions to modify digital human actions, expressions, and business process data. Optionally, when data modification (such as modified configuration data) needs to be uploaded to the blockchain, Party B's dadaSender field can contain the account information of the digital human operation platform that initiated the data modification.

[0079] Optionally, when the contract is uploaded to the blockchain, Party A will configure a whitelist of data confirmers so that the contract functions can verify the legitimacy of the data confirmers. Optionally, the whitelist of data confirmers can be personnel account information associated with the business party's account. Optionally, when data modification (such as modified configuration data) needs to be uploaded to the blockchain, the data confirmation method field can be filled with data confirmation method information.

[0080] Optionally, data confirmation templates can be set for different data confirmation methods, for example, Figure 4 As shown, including the date (Year / Month / Day), XX modified the expression / business process of the XX digital human as follows; content before modification; content after modification; confirmer: XXX; Agree button; Disagree button; Date (Year / Month / Day).

[0081] Optionally, the contract area can contain a list of functions consisting of multiple contract functions and business interface callbacks. For example, a data confirmation sending contract function (function1), a data confirmation result contract function (function2), and a multi-branch tree compression contract function (function3).

[0082] Optionally, the format of the contract function can be:

[0083] Return value: function contract_name(input parameter list){

[0084] Function implementation

[0085] }

[0086] The return value is SQL (Structured Query Language) so that SQL can be executed efficiently.

[0087] Optionally, the business interface callback interface is an HTTP (Hypertext Transfer Protocol) callback method. The interface callback may include the URL (uniform resource locator) of the screenshot API; the access method of the interface, such as GET or POST; and the interface parameter list.

[0088] Optionally, taking the scenario of digital human action and expression data and business process data being uploaded to the blockchain and authenticated as an example, the contract area can include a data confirmation issuance contract function (function1) and a data confirmation result contract function (function2). Optionally, for the data confirmation issuance contract function (function1), it can verify whether the data confirmation method, the client's (Party B), and the data confirmation method match the whitelist information configured when the smart contract is uploaded to the blockchain. If they do not match, it returns FALSE. If they match, it verifies the data before and after modification. If both fields are empty, it means no data change has occurred, and no verification confirmation is initiated, returning FALSE. Otherwise, it returns TRUE and sends confirmation content to the client through the data confirmation method and data confirmation content template, so that the client can confirm and reply. Optionally, for the data confirmation result contract function (function2), if the reply is "agree," it changes the status stored in the blockchain to "modification confirmed"; otherwise, it indicates "disagreement with modification." For details, refer to the digital human action and expression data confirmation table shown in Table 2 below. It also returns whether the execution was successful; if successful, it returns TRUE. Optionally, for the multi-branch tree compression contract function function3, when the number of leaf nodes in the multi-branch tree exceeds a predetermined value or the number of leaf node data bytes exceeds a predetermined MB (bytes), the storage is compressed layer by layer upwards.

[0089] Alternatively, smart contracts can be stored in the local storage space of each node within the blockchain in the form of a table structure. For example, as shown in Table 1 below (i.e., the storage table structure of smart contracts in a local relational database):

[0090]

[0091]

[0092] Table 1

[0093] Optionally, the confirmation form for digital human actions, expressions, and business process data can be referenced as shown in Table 2 below.

[0094]

[0095]

[0096] Table 2

[0097] Optionally, the contract data verification area includes multiple fields, such as metadata verification, data area verification, and contract area verification.

[0098] In this embodiment, by determining the target information corresponding to the digital human, the target information is stored in a multi-branch tree within the blockchain's block corresponding to the digital human. The multi-branch tree can be compressed to reduce the storage resources occupied by the block before it is sent to the blockchain for consensus storage. This blockchain consensus storage method allows the target information corresponding to the digital human to be stored in each node of the blockchain, thereby reducing losses from misconfigurations and missed confirmations caused by human error or forgetfulness, and ultimately improving the accuracy of configuring information for the digital human.

[0099] Furthermore, since the target information includes at least one of configuration information and evaluation information, and multi-branch trees can perform node compression storage, storing at least one of the configuration information and evaluation information through a multi-branch tree saves storage space, allowing for the storage of more evaluation information without affecting the normal operation of the digital human. Therefore, the embodiments of this application improve the accuracy of configuring the configuration information of the digital human, thereby enabling the storage of more evaluation information without affecting the normal operation of the digital human, and improving the intelligence level of the digital human.

[0100] Furthermore, when the target information includes matching information, the configuration information needs to be successfully authenticated and verified through a smart contract in the blockchain before it is stored in the multi-branch tree. This allows the configuration information to be authenticated and verified through the blockchain before configuration, thereby improving the accuracy of configuration information for digital humans and thus enhancing the intelligence level of digital humans.

[0101] Furthermore, based on the first embodiment of this application described above, a second embodiment of the blockchain-based digital human management method of this application is proposed. In this embodiment, reference is made to... Figure 5 After step S30 above, which determines the target information corresponding to the digital human, the process includes:

[0102] Step a: If the target information includes configuration information, and the configuration information is at least one of default configuration data and static configuration data, then detect whether the configuration information matches the stored data contained in the smart contract in the blockchain;

[0103] Optionally, when a node in the blockchain receives configuration information as the target information, the type of configuration information can be determined. If the configuration information is default configuration data or static configuration data, authentication and verification of the configuration information can be performed through a smart contract in the blockchain. Optionally, it can be checked whether the configuration information matches the stored data contained in the smart contract in the blockchain, and then the authentication and verification success can be determined based on the matching result. Optionally, when authenticating and verifying the configuration information, it can be checked whether the configuration information contains a digital human identifier, so as to determine the digital human that needs to be configured based on the digital human identifier. Optionally, the digital human identifier can be used to identify digital humans, such as a digital human ID. Optionally, there can be multiple digital humans, and each digital human has a different digital human identifier.

[0104] Optionally, the configuration information may include multiple configuration data, which can be either default configuration data or static configuration data. Default configuration data may include the welcome message and greeting displayed on the digital human page. This default configuration data can be configured through the smart contract corresponding to the digital human, or it can be pushed to the blockchain by the client (e.g., a business account) for consensus before being used by the service provider (e.g., a configuration account) to determine the default configuration data. Optionally, static configuration data may include the digital human's welcome message (i.e., its corresponding emoticons and actions), a static question-and-answer knowledge base, called business interfaces, and the H5 page of the business system to which the user jumps. Static configuration data has a low data change frequency and is pushed to the blockchain by the client for consensus before being used by the service provider. Optionally, the main difference between static configuration data and default configuration data is that static configuration data is more closely related to the business and the scenario.

[0105] Step b: If the configuration information matches the stored data, then execute the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain.

[0106] Optionally, if the configuration information includes a digital human identifier, then the stored digital human identifier contained in the smart contract in the blockchain is determined, and it is checked whether the digital human identifier matches the stored digital human identifier. Optionally, if the digital human identifier matches the stored digital human identifier, then the authentication verification result of the configuration information is determined to be successful. That is, at this time, it can be considered that the configuration information matches the stored data contained in the smart contract in the blockchain, and then the subsequent operation of storing the target information in the multi-branch tree can be performed. Optionally, the stored data may include the stored digital human identifier.

[0107] Optionally, if the configuration information is determined to contain digital human identifiers, it is necessary to obtain the list of digital human identifiers contained in the smart contracts of the blockchain from the current blockchain nodes, and check whether the digital human identifiers match the stored digital human identifiers in the list. Optionally, each stored digital human identifier corresponds to one digital human, and each stored digital human identifier is different.

[0108] Optionally, if the digital human identifier matches the stored digital human identifier in the list of digital human identifiers, it can be determined that the authentication verification result of the configuration information is successful. At this time, the configuration information can be packaged into a block and uploaded to the blockchain for consensus storage through the current blockchain node.

[0109] Optionally, in one scenario, if the configuration information does not contain a digital human identifier, it can be determined that the configuration information is ordinary on-chain data, and it can be directly packaged into a block and uploaded to the blockchain through the current blockchain node for consensus storage.

[0110] In this embodiment, if the target information is determined to include configuration information, and the configuration information is at least one of default configuration data and static configuration data, and if the configuration information matches the data already stored in the smart contract, the authentication verification result is determined to be successful. Then, the configuration information can be packaged into the multi-branch tree in the block and sent to the blockchain for consensus storage, thereby ensuring the accuracy and validity of the configuration information.

[0111] Furthermore, after determining the target information corresponding to the digital human, the process also includes:

[0112] Step d: If the target information includes configuration information and the configuration information is dynamic configuration data, then detect whether the dynamic configuration data triggers the smart contract function contained in the smart contract in the blockchain, wherein the dynamic configuration data is configuration data sent by the business party account;

[0113] Step e: If a smart contract function is triggered, a modification confirmation message is generated based on the smart contract function and the configuration information, and the modification confirmation message is sent to the configuration party's account;

[0114] Step f: If a confirmation reply is received from the configuration account, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

[0115] Optionally, the dynamic configuration data may include actions, expressions, and business processes during digital human interaction. Optionally, the dynamic configuration data may be configured (or modified) by Party B on the digital human operation platform after consensus is reached through requirements discussion between Party A and Party B, and the configured data requires confirmation from Party A. Optionally, Party B sends the configuration data to nodes in the blockchain, triggering a smart contract for Party A's confirmation. If Party A confirms, the confirmation result is sent back to the blockchain, where the smart contract calculates and assembles the result into a block. After consensus is reached among various consortium blockchain nodes, the block is stored on each node for subsequent querying and use.

[0116] Optionally, when a node in the blockchain receives configuration information as the target information, the type of configuration information can be determined. If the configuration information is dynamic configuration data, and it is sent by the business party's account, it needs to be detected through the blockchain's smart contract to determine whether the dynamic configuration data triggers the smart contract function contained in the blockchain. Upon determining that the smart contract function has been triggered, a confirmation message is generated based on the configuration information and the data confirmation content template corresponding to the smart contract function, and sent to the configuration party's account. After receiving the reply confirmation message from the configuration party's account, it is packaged together with the configuration data into a block, at which point the authentication verification result can be confirmed as successful.

[0117] Optionally, Party A can be a business account, such as an account held by the digital human business party, and Party B can be a configuration account, such as an account held by the digital human page developer.

[0118] Optionally, in the digital human configuration platform, the editor (Party B) configures the digital human's actions, expressions, and business processes, including initial configuration and modification actions. The modified digital human actions, expressions, and business processes are sent as dynamic configuration data to the current node in the blockchain, such as node B. After receiving the dynamic configuration data, node B can package the data into a block and publish this block to the blockchain. Each node in the blockchain reaches a consensus on the block using a consensus algorithm and stores it in its local storage space. Optionally, after node B receives the dynamic configuration data, if a smart contract function is triggered (e.g., various contract functions within the contract area), a confirmation of the modification to Party A will be initiated. Upon receiving the confirmation from the smart contract, Party A will reply, which may include agreement or disagreement. Node B writes the reply information into a block and publishes the block to the consortium blockchain. Optionally, if node B detects that the reply information includes Party A's disagreement or confirmation of the modification or configuration information, a prompt is triggered in the smart contract to Party B. The smart contract then provides relevant information according to the prompt list and template. In the consortium blockchain, each node reaches a consensus on the block from step six using a consensus algorithm, and then stores it locally on its own node. At this point, the business party's confirmation information regarding the modified digital human actions (including expressions) and business process information has completed consensus and storage on the blockchain.

[0119] In this embodiment, by including configuration information in the target information, the configuration information being dynamic configuration data, and the dynamic configuration data triggering a smart contract function, modification confirmation information is generated based on the smart contract function and the configuration information, and sent to the configuration party's account. After receiving the confirmation information from the configuration party's account, the authentication verification result is determined to be successful. Then, the configuration information can be packaged into a block and sent to the blockchain for consensus storage, thereby ensuring the accuracy and validity of the configuration information.

[0120] Furthermore, before the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain, the method further includes:

[0121] Step g: Determine the root node based on the root node hash value calculated based on the target information, and construct two child nodes with the root node as the parent node, wherein the two child nodes include a configuration node and an evaluation node;

[0122] Step h: Construct a configuration subtree with the configuration node as the parent node, wherein the configuration subtree includes at least one configuration node;

[0123] Step i: Construct an evaluation subtree with the evaluation node as the parent node, wherein the evaluation subtree includes at least one evaluation node;

[0124] Step j: Determine a multi-branch tree based on the root node, the configuration subtree, and the evaluation subtree, and attach the multi-branch tree to the block in the blockchain corresponding to the digital human.

[0125] Optionally, the robot identifier contained in the target information can be determined, and a multi-branch tree can be constructed using the robot identifier, and then the multi-branch tree can be attached to the block corresponding to the digital human identifier.

[0126] Optionally, blocks can be constructed within the blockchain main chain using the digital human identifier as the core. A multi-branch tree can be attached to each block using the root node hash value. Optionally, the root node hash value can be calculated using the digital human identifier contained in the target information. Optionally, the multi-branch tree can be determined based on the root node hash value, and a root node can be identified within the multi-branch tree. Two fixed child nodes can be set under the root node: a configuration node and an evaluation node. Optionally, the configuration node can be used to store configuration information for various versions of the digital human configuration. The evaluation node can be used to store user evaluation information after each service provided by the digital human, facilitating subsequent service quality statistics and data compression storage.

[0127] Optionally, a configuration subtree can be constructed based on the configuration information, and an evaluation subtree can be constructed based on the evaluation information.

[0128] Optionally, a configuration subtree can be constructed with a configuration node as the parent node. When constructing the configuration subtree, it can be first determined whether the target information contains configuration information. If it contains configuration information, it is checked whether the block corresponding to the digital human identifier in the configuration information exists. If it does not exist, a new digital human identifier block needs to be created, and the hash value of the multi-branch tree is calculated. The multi-branch tree is then mounted in the blockchain, and the configuration information is added to the configuration node and mounted to the configuration node of the newly created multi-branch tree root node (such as the left subtree node). The hash value is calculated based on the configuration information and assigned to the configuration node hash value and the configuration subtree hash value respectively. Since there is only one node at this time, the two are the same. The root node hash value, configuration node hash value, and configuration subtree hash value of the multi-branch tree can be packaged into a block for consensus storage with various nodes in the blockchain.

[0129] Optionally, an evaluation subtree can be constructed with an evaluation node as the parent node.

[0130] When constructing the evaluation subtree, we can first determine whether the target information contains evaluation information. If it contains evaluation information, we check whether the block corresponding to the digital human identifier in the evaluation information exists. If it does not exist, we need to create a new digital human identifier block, calculate the hash value of the multi-branch tree, attach the multi-branch tree to the blockchain, and add the evaluation information to the evaluation node, thereby forming the evaluation subtree.

[0131] A tree structure with a root node, configuration subtree, and evaluation subtree can be used as a multi-branch tree, and the multi-branch tree, along with the root node hash value, can be attached to the block corresponding to the digital human identifier. Optionally, if multiple digital human identifiers exist, the multi-branch tree corresponding to each digital human identifier can be attached to its respective block.

[0132] For example, such as Figure 6 As shown, this includes the genesis block in the main chain, and blocks connected to the genesis block such as Digital Human ID=1, Digital Human ID=2, and Digital Human ID=n. Optionally, a multi-branch tree can be attached to each Digital Human ID block, for example, to the Digital Human ID=1 block. The multi-branch tree can include a root node, a configuration subtree, and an evaluation subtree. The configuration subtree can include multiple configuration nodes, such as latest configuration, configuration 3, configuration 2, and configuration 1. The evaluation subtree includes multiple evaluation nodes, such as group evaluation, two sub-nodes under group evaluation (branch evaluation), a sub-node under branch evaluation (department evaluation), and a sub-node under department evaluation (employee evaluation).

[0133] In this embodiment, the root node is determined by calculating the root node hash value based on the target information. Based on the root node, a configuration subtree with the configuration node as the parent node and an evaluation subtree with the evaluation node as the parent node are determined, and then a multi-branch tree is determined. The multi-branch tree is then mounted to the block, thereby ensuring the validity of the multi-branch tree mounted to the block.

[0134] Further, the step of storing the target information into a multi-branch tree within the blockchain corresponding to the digital human includes:

[0135] Step k: If the target information includes configuration information, then the configuration information is stored in a configuration node within the configuration subtree of the multi-way tree, wherein the configuration node storing the configuration information is a child node of the root node in the multi-way tree;

[0136] Step 1: If the target information includes evaluation information, then the evaluation information is stored in the evaluation node of the evaluation subtree in the multi-branch tree.

[0137] In this embodiment, when storing target information in a multi-branch tree, it is necessary to detect the type of target information. If the target information includes configuration information, the configuration information is added to the configuration node in the configuration subtree.

[0138] Optionally, if the block corresponding to the digital human identifier exists, and at least one configuration node exists in the configuration subtree, the configuration information can be added to the configuration node NEW, assuming the root node of the configuration subtree is OLD (i.e., the first configuration node of the configuration subtree). Optionally, if OLD has no left child node, NEW is used as the root node of the new configuration subtree, pointing to the root node of the multi-branch tree, becoming the left child node of the multi-branch tree root node, and the OLD node becomes the left child node of the NEW node. Optionally, if OLD has a left child node but no right child node, NEW can be used as the root node of the new configuration subtree, pointing to the root node of the multi-branch tree, becoming the left child node of the multi-branch tree root node, and the OLD node becomes the right child node of the NEW node. Optionally, if OLD has both a left and a right child node, NEW can be used as the root node of the new configuration subtree, pointing to the root node of the multi-branch tree, becoming the left child node of the multi-branch tree root node, and the OLD node becomes the left child node of the left child node of the NEW node. Similarly, a head-insertion-like approach is used to ensure the root node of the configuration subtree always contains the latest configuration information, facilitating efficient and convenient configuration retrieval. Optionally, after storing the configuration information in the configuration subtree, the hash value of the root node needs to be updated. For example, the hash value of each configuration node in the configuration subtree = hash(left subtree hash + right subtree hash), where, for a configuration node, the left and right subtree hashes are the hashes of the node's configuration content. Based on this method, the hash values ​​from the configuration node to its parent node to the root node can be calculated layer by layer. After calculation, the root node hash value, configuration node hash value, and configuration subtree hash value of the multi-branch tree can be packaged into a block for consensus storage with various nodes in the blockchain.

[0139] Optionally, when storing configuration information to a configuration subtree, a new configuration node can be generated at the connection point between the configuration subtree and the root node, and the configuration information can be stored in the new configuration node. The parent node of the new configuration node is the root node, and the child node is the original root node in the configuration subtree. Optionally, the root node of the configuration subtree (i.e., the first configuration node in the configuration subtree) can be determined, and the configuration information can be updated and stored in the root node of the configuration subtree.

[0140] Optionally, when the target information includes evaluation information, the evaluation information can be stored in the evaluation node of the evaluation subtree.

[0141] Optionally, the architecture of the evaluation subtree can be configured according to user needs. This embodiment only illustrates the following architecture: The root node of the evaluation subtree is the group node, the next level is the company node, the next level is the department node, and the next level is the employee node. Optionally, the group node is attached to the right subtree node of the root node of the multi-branch tree, the branch company node is attached to the left child node of the group node, and the department node is attached to the left child node of the branch company node. The user evaluation node (i.e., the employee node) is attached to the left child node of the department node.

[0142] Optionally, if the block corresponding to the digital human identifier in the evaluation information exists, it can be determined that the evaluation subtree has four nodes (e.g., group node, branch node, department node, and user evaluation node). Optionally, if there are no branch nodes under the group node, branch nodes, department nodes, and user evaluation nodes need to be constructed. The branch node is attached to a node of the group node, the department node is attached to the left node of the branch node, and the user evaluation node is attached to the left node of the department node. Optionally, if there are branch nodes but no department nodes under the group node, department nodes and user evaluation nodes are constructed. The department node is attached to a node of the branch node, and the user evaluation node is attached to the left node of the department node. Optionally, if there are both branch nodes and department nodes under the group node, user evaluation nodes are constructed and attached to a node of the department node. Optionally, the evaluation information can be stored in the user evaluation node (i.e., one type of evaluation node).

[0143] Optionally, after storing the evaluation information to the evaluation node, it is necessary to calculate the hash value based on the evaluation information, and calculate the hash value of the root node of the evaluation subtree, i.e. the group node, according to the configuration subtree hash value calculation process. These hash values ​​are then assigned to the hash values ​​of the evaluation node and the evaluation subtree, respectively. Finally, the hash values ​​of the root node of the multi-branch tree, the hash values ​​of the evaluation node, and the hash values ​​of the evaluation subtree are packaged into a block for consensus storage with each node in the consortium blockchain.

[0144] In this embodiment, by storing configuration information in the configuration node of the configuration subtree in the multi-branch tree and evaluation information in the evaluation node of the evaluation subtree in the multi-branch tree, the effective storage of configuration information and evaluation information is ensured.

[0145] Further, if the multi-way tree meets the preset compression conditions, the step of compressing and storing the nodes of the multi-way tree to obtain the target block includes:

[0146] Step m: If the number of leaf nodes in the multi-way tree is greater than the preset number of nodes, then the multi-way tree is determined to meet the preset compression condition, wherein the leaf nodes include nodes in the configuration subtree and / or evaluation subtree of the multi-way tree.

[0147] Step n: Extract the data from the leaf nodes of the multi-way tree and form a first JSON structure. In the first JSON structure, use the upstream content as the value and the upstream timestamp as the primary key to compress the data and obtain the first compressed data.

[0148] Step o: Store the first compressed data to the parent node of the leaf node, delete the leaf node to obtain the adjusted multi-way tree, and take the block with the adjusted multi-way tree as the target block.

[0149] In this embodiment, a smart contract in a blockchain node can determine whether the multi-branch tree in the block needs compression. Optionally, if the number of leaf nodes in the multi-branch tree is greater than a preset number of nodes (any number set by the user in advance, such as a predetermined value), the multi-branch tree can be determined to meet the preset compression conditions, and the multi-branch tree can be compressed and stored layer by layer upwards. Optionally, the layer-by-layer compression and storage processing of the multi-branch tree can be performed separately on the configuration subtree and the evaluation subtree, until only one configuration node remains in the configuration subtree and only one evaluation node remains in the evaluation subtree.

[0150] Optionally, a leaf node can be a configuration node in a configuration subtree or an evaluation node in an evaluation subtree.

[0151] Optionally, data from the leaf nodes of the multi-branched data structure can be extracted, formed into a JSON structure, and used as the first JSON structure. In the first JSON structure, the upstream content (such as evaluation information or configuration information) is used as the value, and the upstream timestamp is used as the primary key for data compression. The resulting compressed data is stored in the parent node of the leaf node, and the leaf node is then deleted, thus saving storage space for the leaf node. Optionally, leaf nodes without child nodes can be preferentially compressed and stored layer by layer upwards.

[0152] In this embodiment, by compressing and storing the leaf nodes in the multi-branch tree when the number of leaf nodes is greater than the preset number of nodes, storage space is saved.

[0153] Furthermore, if the multi-way tree meets the preset compression conditions, the step of compressing and storing the nodes of the multi-way tree to obtain the target block further includes:

[0154] Step p: If the number of bytes stored in a leaf node in the multi-way tree is greater than the preset number of bytes, then the multi-way tree is determined to meet the preset compression condition, and the leaf node with the greater than the preset number of bytes is taken as the target leaf node.

[0155] Step q: Extract the number of nodes at the same level as the target leaf node to form a second JSON structure. In the second JSON structure, use the upstream timestamp as the primary key and the upstream content as the value to compress the data and obtain the second compressed data.

[0156] Step u: Store the second compressed data to the parent node of the second leaf node to obtain the adjusted multi-branch tree, and use the block with the adjusted multi-branch tree as the target block.

[0157] Optionally, if it is detected that the number of storage bytes of a leaf node in the configuration subtree or evaluation subtree of the multi-way tree is greater than the preset number of bytes (the number of bytes set by the user in advance, such as the preset MB), it can be determined that the multi-way tree meets the preset compression conditions and that the multi-way tree needs to be compressed.

[0158] Optionally, node data at the same level as the target leaf node can be extracted from the multi-branch tree and formed into a JSON structure, which is then used as the second JSON structure. In the second JSON structure, the upstream content (such as evaluation information or configuration information) is used as the value, and the upstream timestamp is used as the primary key for data compression. The resulting compressed data is stored in the parent node of the leaf node. At this point, node data at the same level as the target leaf node is cleared, further saving data storage space. Optionally, the leaf node with cleared node data can be deleted. This yields an adjusted multi-branch tree, and the block with the adjusted multi-branch tree is used as the target block. For example, the block is updated and stored based on the adjusted multi-branch tree to obtain the target block.

[0159] In this embodiment, when the number of bytes of the target leaf node in the multi-branch tree is greater than a preset number of bytes, the leaf node is compressed and stored, thereby saving storage space.

[0160] In addition, refer to Figure 7 This application also provides a blockchain-based digital human management device, comprising:

[0161] The determining module A10 is used to determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information;

[0162] Storage module A20 is used to store the target information into a multi-branch tree in the blockchain corresponding to the digital human;

[0163] Compression module A30 is used to compress and store the nodes of the multi-branch tree if the multi-branch tree meets the preset compression conditions, obtain the target block, and upload the target block to the blockchain for consensus storage.

[0164] Optionally, module A10 is defined for:

[0165] If the target information includes configuration information, and the configuration information is at least one of default configuration data and static configuration data, then it is detected whether the configuration information matches the stored data contained in the smart contract in the blockchain;

[0166] If the configuration information matches the stored data, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

[0167] Optionally, module A10 is defined for:

[0168] If the target information includes configuration information, and the configuration information is dynamic configuration data, then it is detected whether the dynamic configuration data triggers the smart contract function contained in the smart contract in the blockchain, wherein the dynamic configuration data is configuration data sent by the business party account;

[0169] If a smart contract function is triggered, a modification confirmation message is generated based on the smart contract function and the configuration information, and the modification confirmation message is sent to the configuration party's account.

[0170] If a confirmation message is received from the configuration account, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

[0171] Optionally, the storage module A20 is used for:

[0172] The root node is determined based on the root node hash value calculated based on the target information, and two child nodes are constructed with the root node as the parent node, wherein the two child nodes include a configuration node and an evaluation node;

[0173] A configuration subtree is constructed with the configuration node as the parent node, wherein the configuration subtree includes at least one configuration node;

[0174] An evaluation subtree is constructed with the evaluation node as the parent node, wherein the evaluation subtree includes at least one evaluation node;

[0175] A multi-branch tree is determined based on the root node, the configuration subtree, and the evaluation subtree, and the multi-branch tree is attached to the block in the blockchain corresponding to the digital human.

[0176] Optionally, the storage module A20 is used for:

[0177] If the target information includes configuration information, then the configuration information is stored in a configuration node within the configuration subtree of the multi-way tree, wherein the configuration node storing the configuration information is a child node of the root node in the multi-way tree;

[0178] If the target information includes evaluation information, then the evaluation information is stored in the evaluation node of the evaluation subtree in the multi-branch tree.

[0179] Optionally, the compression module A30 is used for:

[0180] If the number of leaf nodes in the multi-way tree is greater than the preset number of nodes, then the multi-way tree is determined to meet the preset compression condition, wherein the leaf nodes include nodes in the configuration subtree and / or evaluation subtree of the multi-way tree;

[0181] Extract the data from the leaf nodes of the multi-way tree and form a first JSON structure. In the first JSON structure, use the upstream content as the value and the upstream timestamp as the primary key to compress the data and obtain the first compressed data.

[0182] The first compressed data is stored in the parent node of the leaf node, the leaf node is deleted, and the adjusted multi-way tree is obtained. The block with the adjusted multi-way tree is taken as the target block.

[0183] Optionally, the compression module A30 is used for:

[0184] If a leaf node in a multi-way tree has a storage number of bytes greater than a preset number of bytes, then the multi-way tree is determined to meet the preset compression condition, and the leaf node with a storage number greater than the preset number of bytes is taken as the target leaf node.

[0185] Extract the number of nodes at the same level as the target leaf node to form a second JSON structure. In the second JSON structure, use the upstream timestamp as the primary key and the upstream content as the value to compress the data and obtain the second compressed data.

[0186] The second compressed data is stored in the parent node of the second leaf node to obtain the adjusted multi-branch tree, and the block with the adjusted multi-branch tree is used as the target block.

[0187] In addition, this application also provides an electronic device, which includes a memory, a processor, and a blockchain-based digital human management program stored in the memory and capable of running on the processor. When the blockchain-based digital human management program is executed by the processor, it implements the steps of the blockchain-based digital human management method described above.

[0188] Furthermore, in one embodiment, Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention, as shown below. Figure 8As shown, at the hardware level, this electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk storage device. Of course, this electronic device may also include other hardware required for its functions. The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only a single bidirectional arrow is used in the diagram, but this does not imply that there is only one bus or one type of bus. The memory is used to store programs. Specifically, the program can include program code, which includes computer operation instructions. The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a shared resource access control device at the logical level. The processor executes the program stored in memory and specifically performs the steps of the aforementioned blockchain-based digital human management method.

[0189] The specific implementation of the electronic device in this application is basically the same as the embodiments of the blockchain-based digital human management method described above, and will not be repeated here.

[0190] In addition, to achieve the above objectives, this application also provides a computer storage medium, including a computer-readable storage medium, on which a blockchain-based digital human management program is stored, wherein when the blockchain-based digital human management program is executed by a processor, it implements the steps of the blockchain-based digital human management method described above.

[0191] The specific implementation of the computer-readable storage medium in this application is basically the same as the embodiments of the blockchain-based digital human management method described above, and will not be repeated here.

[0192] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0193] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A blockchain-based digital human management method, characterized in that, The blockchain-based digital human management method includes the following steps: Determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information; The target information is stored in a multi-branch tree within the blockchain corresponding to the digital human; If the multi-branch tree meets the preset compression conditions, then the nodes of the multi-branch tree are compressed and stored to obtain the target block, and the target block is uploaded to the blockchain for consensus storage. The step of compressing and storing the nodes of the multi-way tree to obtain the target block if the multi-way tree meets the preset compression conditions includes: If the number of leaf nodes in the multi-way tree is greater than the preset number of nodes, then the multi-way tree is determined to meet the preset compression condition, wherein the leaf nodes include nodes in the configuration subtree and / or evaluation subtree of the multi-way tree; Extract the data from the leaf nodes of the multi-way tree and form a first JSON structure. In the first JSON structure, use the upstream content as the value and the upstream timestamp as the primary key to compress the data and obtain the first compressed data. The first compressed data is stored in the parent node of the leaf node, the leaf node is deleted, and the adjusted multi-way tree is obtained. The block with the adjusted multi-way tree is taken as the target block.

2. The blockchain-based digital human management method as described in claim 1, characterized in that, After the step of determining the target information corresponding to the digital human, the following steps are included: If the target information includes configuration information, and the configuration information is at least one of default configuration data and static configuration data, then it is detected whether the configuration information matches the stored data contained in the smart contract in the blockchain; If the configuration information matches the stored data, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

3. The blockchain-based digital human management method as described in claim 1, characterized in that, After the step of determining the target information corresponding to the digital human, the method further includes: If the target information includes configuration information, and the configuration information is dynamic configuration data, then it is detected whether the dynamic configuration data triggers the smart contract function contained in the smart contract in the blockchain, wherein the dynamic configuration data is configuration data sent by the business party account; If a smart contract function is triggered, a modification confirmation message is generated based on the smart contract function and the configuration information, and the modification confirmation message is sent to the configuration party's account. If a confirmation message is received from the configuration account, then the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain is executed.

4. The blockchain-based digital human management method as described in claim 1, characterized in that, Before the step of storing the target information into the multi-branch tree of the block corresponding to the digital human in the blockchain, the method further includes: The root node is determined based on the root node hash value calculated based on the target information, and two child nodes are constructed with the root node as the parent node, wherein the two child nodes include a configuration node and an evaluation node; A configuration subtree is constructed with the configuration node as the parent node, wherein the configuration subtree includes at least one configuration node; An evaluation subtree is constructed with the evaluation node as the parent node, wherein the evaluation subtree includes at least one evaluation node; A multi-branch tree is determined based on the root node, the configuration subtree, and the evaluation subtree, and the multi-branch tree is attached to the block in the blockchain corresponding to the digital human.

5. The blockchain-based digital human management method as described in claim 4, characterized in that, The step of storing the target information into a multi-branch tree in the blockchain corresponding to the digital human includes: If the target information includes configuration information, then the configuration information is stored in a configuration node within the configuration subtree of the multi-way tree, wherein the configuration node storing the configuration information is a child node of the root node in the multi-way tree; If the target information includes evaluation information, then the evaluation information is stored in the evaluation node of the evaluation subtree in the multi-branch tree.

6. The blockchain-based digital human management method as described in claim 1, characterized in that, The step of performing node compression storage on the multi-way tree to obtain the target block if the multi-way tree meets the preset compression conditions includes: If a leaf node in a multi-way tree has a storage number of bytes greater than a preset number of bytes, then the multi-way tree is determined to meet the preset compression condition, and the leaf node with a storage number greater than the preset number of bytes is taken as the target leaf node. Extract the number of nodes at the same level as the target leaf node to form a second JSON structure. In the second JSON structure, use the upstream timestamp as the primary key and the upstream content as the value to compress the data and obtain the second compressed data. The second compressed data is stored in the parent node of the target leaf node to obtain the adjusted multi-way tree, and the block with the adjusted multi-way tree is taken as the target block.

7. A blockchain-based digital human management device, characterized in that, The blockchain-based digital human management device includes: A determination module is used to determine the target information corresponding to the digital human, wherein the target information includes at least one of configuration information and evaluation information; The storage module is used to store the target information into a multi-branch tree in the blockchain corresponding to the digital human; A compression module is used to compress and store the nodes of the multi-way tree to obtain a target block if the multi-way tree meets a preset compression condition, and then upload the target block to the blockchain for consensus storage. The step of compressing and storing the nodes of the multi-way tree to obtain a target block if the multi-way tree meets the preset compression condition includes: determining that the multi-way tree meets the preset compression condition if the number of leaf nodes in the multi-way tree is greater than a preset number of nodes, wherein the leaf nodes include nodes in the configuration subtree and / or evaluation subtree of the multi-way tree; extracting data from the leaf nodes of the multi-way tree to form a first JSON structure, compressing the data in the first JSON structure using the on-chain content as the value and the on-chain timestamp as the primary key to obtain first compressed data; storing the first compressed data in the parent node of the leaf node, deleting the leaf node to obtain an adjusted multi-way tree, and using the block with the adjusted multi-way tree as the target block.

8. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a blockchain-based digital human management program stored in the memory and executable on the processor, wherein the blockchain-based digital human management program, when executed by the processor, implements the steps of the blockchain-based digital human management method as described in any one of claims 1 to 6.

9. A medium, characterized in that, The medium includes a computer-readable storage medium storing a blockchain-based digital human management program, which, when executed by a processor, implements the steps of the blockchain-based digital human management method as described in any one of claims 1 to 6.

Images