Role change, user registration method and related device

Abstract

Embodiments of this application provide a method and related apparatus for role change and user registration. The method includes: determining a target user role based on received transaction data including a blockchain wallet address; obtaining a target role metadata token representing the target user role corresponding to the blockchain wallet address; and, based on the blockchain wallet address and the target role metadata token, invoking a dynamic non-fungible digital token smart contract to change the role metadata token bound to the client's dynamic non-fungible digital token to the target role metadata token. This application enables dynamic role change, reducing the resource waste caused by multiple minting of non-fungible digital tokens.

Description

Technical Field

[0001] The implementation methods in this application relate to the blockchain field, and specifically to a method, apparatus, device, and storage medium for role change and user registration. Background Art

[0002] Non-fungible digital tokens are unique, trusted digital certificates of equity within the blockchain network. Each non-fungible digital token has a digital signature that makes it unique and irreplaceable.

[0003] Currently, non-fungible digital tokens can be used to represent a user's role within a network. For example, a website can grant a user a non-fungible digital token representing their role within the website. In some cases, a user's role may change. For example, a website user may initially have a "normal" role. Points are accumulated based on daily visits. After a certain period of usage, if the points reach a certain threshold, the user's role is upgraded to a "premium" role. Due to the uniqueness and immutability of non-fungible digital tokens, a non-fungible digital token representing a normal role is typically generated for the user, followed by a subsequent non-fungible digital token representing a premium role. A user may change roles multiple times within a website, resulting in multiple non-fungible digital tokens representing different roles. This can create challenges for network service providers in managing user roles. Summary of the Invention

[0004] The embodiments of the present application provide a method, apparatus, device, and storage medium for role change and user registration, which can improve the convenience of user role management for network service providers to a certain extent.

[0005] One embodiment of the present application provides a method for changing a user role, including:

[0006] Determine the target user role based on the received transaction data including the blockchain wallet address; wherein different user roles have different access rights, the blockchain wallet address corresponds to a dynamic non-fungible digital token with a bound role metadata token, and the role metadata token is used to represent the metadata stored in the blockchain for representing the user role; obtain the target role metadata token representing the target user role corresponding to the blockchain wallet address; wherein different user roles correspond to different role metadata tokens; the target role metadata token is used to represent the metadata stored in the blockchain for representing the target user role; based on the blockchain wallet address and the target role metadata token, call the dynamic non-fungible digital token smart contract to change the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token.

[0007] One embodiment of the present application provides a user registration method, which is applied to a service server and includes:

[0008] Receive an access request sent by a user through a client; wherein the access request is accompanied by a blockchain wallet address bound to the client; obtain multiple role metadata tokens; wherein the role metadata token is used to represent metadata stored in the blockchain for representing user roles, and different metadata represent different user roles; different user roles have different access rights; determine an initial role metadata token among multiple role metadata tokens; based on the blockchain wallet address and the initial role metadata token, call a dynamic non-fungible digital token smart contract to generate a dynamic non-fungible digital token for the blockchain wallet address; wherein the dynamic non-fungible digital token is bound to the initial role metadata token; wherein the dynamic non-fungible digital token can switch the bound role metadata token among multiple role metadata tokens; send the dynamic non-fungible digital token to the client.

[0009] One embodiment of the present application further provides a device for changing a user role, comprising:

[0010] A data receiving unit is used to determine a target user role based on received transaction data including a blockchain wallet address; different user roles have different access rights; the blockchain wallet address corresponds to a dynamic non-fungible digital token with a bound role metadata token; the role metadata token is used to represent metadata stored in the blockchain for representing the user role; a target token acquisition unit is used to obtain a target role metadata token representing the target user role corresponding to the blockchain wallet address; different user roles correspond to different role metadata tokens; the target role metadata token is used to represent metadata stored in the blockchain for representing the target user role; a calling unit is used to call a dynamic non-fungible digital token smart contract based on the blockchain wallet address and the target role metadata token, so that the role metadata token bound to the dynamic non-fungible digital token is changed to the target role metadata token.

[0011] One embodiment of the present application further provides a user registration device, comprising:

[0012] A request receiving unit is used to receive an access request; wherein the access request is accompanied by the blockchain wallet address of the user's client; a token acquisition unit is used to obtain multiple role metadata tokens corresponding to the blockchain wallet address; wherein the role metadata token is used to represent the metadata stored in the blockchain for representing the user role; wherein different metadata represent different user roles; and different user roles have different access rights; a determination unit is used to determine the initial role metadata token among multiple role metadata tokens; a calling unit is used to call the dynamic non-fungible digital token smart contract based on the blockchain wallet address and the initial role metadata token to generate a dynamic non-fungible digital token for the user; wherein the dynamic non-fungible digital token is bound to the initial role metadata token; a sending unit is used to send the dynamic non-fungible digital token to the user's client.

[0013] An embodiment of the present application provides an electronic device, including a memory and one or more processors communicatively connected to the memory; when the processor executes the computer program, any of the above-mentioned user registration methods or user role change methods is implemented.

[0014] One embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, any of the above-mentioned user registration methods or user role change methods is implemented.

[0015] The implementation method provided by this application stores multiple metadata representing user roles in the blockchain corresponding to a blockchain wallet address, thereby enabling the dynamic non-fungible digital token generated for the blockchain wallet address to switch between multiple metadata according to a smart contract. Because different metadata represent different user roles, the user role represented by the dynamic non-fungible digital token can be changed by switching metadata. In this way, users can have a dynamic non-fungible digital token representing their current user role, which effectively represents the user's permissions. This reduces the problems caused by multiple non-fungible digital tokens representing different user roles and brings convenience to the management of user roles. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A schematic diagram of multi-terminal interaction for user registration and role change provided in one embodiment of this application.

[0017] Figure 2 A flowchart of a user registration method provided in one embodiment of the present application.

[0018] Figure 3 A flowchart of a method for changing a user role provided in one embodiment of the present application.

[0019] Figure 4 A schematic diagram of a user registration device provided in accordance with one embodiment of the present application.

[0020] Figure 5 A schematic diagram of a device for changing a user role provided in one embodiment of the present application.

[0021] Figure 6 A schematic diagram of a computer device provided for one embodiment of the present application. DETAILED DESCRIPTION

[0022] In related technologies, users of network services can have user roles, and different user roles can have different permissions. Thus, by distinguishing user roles, different permissions can be granted to users. Specifically, for example, when a user registers on a website, an initial user role is assigned to the user.

[0023] The application of non-fungible digital token technology to user roles, combined with the uniqueness and non-fungible nature of non-fungible digital tokens, makes user rights management very clear. In some cases, a user's role may change. For example, over time, a user role may evolve from a standard role to a higher-level role, granting greater permissions. Alternatively, a user may initially register with a higher-level role, but after reaching the expiration date and not renewing, they may need to return to a standard role. Therefore, when a user registers or changes their role, a non-fungible digital token can be minted based on the user's blockchain wallet address and user data. The minted non-fungible digital token is then sent to the user's wallet address, allowing the user to use the corresponding role permissions.

[0024] As users accumulate more time and frequency on a website, their behavior data changes accordingly. The inventors discovered that when this data changes, a new non-fungible digital token needs to be minted for the user. This means that the same user may have multiple non-fungible digital tokens for the same website. Because different non-fungible digital tokens represent different user roles, each role has different permissions. This creates significant challenges in user permission management.

[0025] Therefore, it is necessary to provide a method for user registration and role change, which can reduce the troubles caused by multiple non-homogeneous digital tokens representing different user roles and bring convenience to the management of user roles.

[0026] See also Figure 1During the user registration process, client 10 is available for user use. Users can interact with the client to browse pages, send access requests, and more. Client 10 may be bound to a blockchain wallet address. Users can use client 10 to send access requests to business server 11. After receiving the access request, business server 11 can obtain the blockchain wallet address from the access request. Furthermore, business server 11 can generate multiple pieces of metadata representing the user's role according to a pre-configured script. It then calls an interface on blockchain 12 with these metadata, storing the metadata in blockchain 12. Blockchain 12 stores the metadata and generates a role metadata token for each piece of metadata. Blockchain 12 sends the role metadata token to business server 11. For new user registrations, an initial role is set. Business server 11 can use the initial role metadata token representing the initial role and the blockchain wallet address to call the dynamic non-fungible digital token smart contract 13. The dynamic non-fungible digital token smart contract 13 uses the initial role metadata token and blockchain wallet address to generate a dynamic non-fungible digital token according to the contents of the configured smart contract. This dynamic non-fungible digital token can be used to represent the role permissions possessed by the user. The dynamic non-fungible digital token smart contract 13 can send the dynamic non-fungible digital token to the client 10, and the user can view the dynamic non-fungible digital token owned by the client 10. Of course, the dynamic non-fungible digital token smart contract 13 can also call the interface of the blockchain 12 with the generated dynamic non-fungible digital token to store the generated dynamic non-fungible digital token in the blockchain 12.

[0027] During the user role change process, the user can use client 10 to access the functions provided by business server 11. The interaction between client 10 and business server 11 generates some user data. Server 11 can match the user data with pre-set role change conditions. As the user uses client 10, more and more user data is generated. If server 11 determines that the user data matches the pre-set role change conditions, it can reassign the user's target user role according to pre-set settings. Furthermore, the target role metadata token and blockchain wallet address corresponding to the target user role can be sent to oracle 14. After receiving the target role metadata token and blockchain wallet address, oracle 14 can further provide the target role metadata token and blockchain wallet address to the dynamic non-fungible digital token smart contract 13. In this way, the dynamic non-fungible digital token smart contract 13 obtains the dynamic non-fungible digital token corresponding to the blockchain wallet address and changes the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token. This achieves the change of the user role represented by the dynamic homogeneous digital token. Subsequently, the dynamic non-fungible digital token smart contract 13 can send the dynamic non-fungible digital token bound to the target role metadata token to the client 10 for user reference.

[0028] See also Figure 2 One embodiment of the present application provides a user registration method. The user registration method can be applied to a business server. The business server can be an electronic device with certain computing and processing capabilities. It can have a network communication module, a processor, a memory, etc. Of course, the business server can also refer to software running in an electronic device. The business server can also be a distributed server, which can be a system with multiple processors, memories, network communication modules, etc. operating in collaboration. Alternatively, the business server can also be a server cluster formed by several servers. Alternatively, with the development of science and technology, the business server can also be a new technical means that can realize the corresponding functions of the embodiment of the specification. For example, it can be a new form of "server" based on quantum computing. The user registration method may include the following steps.

[0029] Step S111: Receive an access request sent by the user through the client; wherein the access request is accompanied by the blockchain wallet address bound to the client.

[0030] In some cases, users may be required to register their information when visiting a website for the first time. When accessing a website, the client initiates an access request, which is received by the service server. The access request may include user behavior information such as the client's blockchain wallet address, access history, and access duration. The service server will record the blockchain wallet address to facilitate information exchange.

[0031] In this embodiment, the access request can be a data processing instruction issued by a user operating a client to represent the user's business needs. Specifically, for example, the access request can be a user registration request issued by the user. Of course, the access request can also be a user's request to access a page.

[0032] In this embodiment, the blockchain wallet address can be a unique account address generated for a user by the blockchain service. The blockchain wallet address can be used in network communications as a user identifier. Specifically, the service server or blockchain can record the blockchain wallet address of the user client and send user access requests to the client via the network based on the blockchain wallet address.

[0033] Step S112: Acquire multiple role metadata tokens; wherein the role metadata token is used to represent metadata stored in the blockchain for representing user roles; wherein different metadata represent different user roles; and different user roles have different access rights.

[0034] In some cases, different user roles have different access rights. However, currently, when users register or change roles, new non-fungible digital tokens must be minted for them, as different roles correspond to different access rights. This means that each time a user changes roles, a new non-fungible digital token must be minted. This current approach can result in multiple non-fungible digital tokens for the same user, complicating user rights management. Furthermore, the increasing number of non-fungible digital tokens can lead to resource waste. Therefore, to reduce the minting of multiple non-fungible digital tokens for the same user and minimize resource waste, multiple metadata tokens are obtained during user registration. Metadata tokens represent the user's role. Different metadata indicates different user roles. When a user changes roles, the associated metadata token can be simply changed, eliminating the need to mint a new non-fungible digital token. This reduces resource waste.

[0035] In this embodiment, a role metadata token can be used to represent metadata representing a user's role stored on the blockchain. The metadata can be pre-stored on the blockchain, leveraging the blockchain's inherent data security mechanisms to ensure that the metadata is stored in a relatively secure and trustworthy state. In some embodiments, a business server can execute a pre-configured script to generate multiple metadata, then call a blockchain-provided interface to store the metadata on the blockchain. In some embodiments, the role metadata token can be the blockchain storage address where the metadata is stored. Specifically, for example, user roles can include regular user, platinum user, administrator, and other user roles; different user roles often correspond to different information. Therefore, different user role metadata tokens are needed to represent each user's multiple roles. Specifically, the role metadata token can be a method of authenticating user roles, with each role metadata token corresponding to only one user role. In other words, if the client corresponding to the blockchain wallet address has multiple user roles available, such as regular user, platinum user, and administrator, it will need to obtain metadata tokens corresponding to the regular user, platinum user, and administrator roles. Specifically, the client can obtain the role metadata token of the metadata currently stored in the blockchain, and when receiving the client's access request, allocate the corresponding multiple role metadata tokens in the blockchain to the blockchain wallet address; or, based on the client's access request, generate corresponding metadata based on the multiple user roles that the client can select, and allocate them to the client's blockchain wallet address; and then bind the corresponding role metadata token based on the user's user role selection.

[0036] Metadata can be descriptive information about a user. Metadata can be set for different users, allowing them to be distinguished through metadata, or further characterized based on metadata. Specifically, metadata can include various information, such as user roles, permissions, and image identifiers. For example, website user roles can be classified as regular users, platinum users, and administrators. Regular users accessing a website may only see a fixed color or style, while platinum users can customize the color or style of the interface. Therefore, different user roles correspond to different display content and operational permissions, and the corresponding metadata also differs. Therefore, different metadata represent different user roles. Each metadata represents a specific user role, so metadata corresponding to all user roles must be uploaded to the blockchain network. During user registration, the corresponding metadata is selected based on the user client's access request.

[0037] In this embodiment, different user roles may have different access rights. Specifically, access rights may be based on predefined user roles, i.e., identity identifiers, to restrict access to certain information, and access rights are usually set and managed by system administrators. Different user roles may have different access rights when accessing a website. For example, when an ordinary user visits a certain video website, they can only watch free video files; when a platinum user visits the same video website, they can not only watch free video files, but also watch files exclusive to platinum users. In addition, it should be noted that ordinary users can be upgraded to platinum users in a variety of ways. At this time, the ordinary user role switches to a platinum user, and the ordinary user can use the same rights as the platinum user; correspondingly, the platinum user can also be downgraded to an ordinary user based on their user behavior, that is, the role switches to an ordinary user, and the user can only have ordinary user access rights.

[0038] Step S113: Determine an initial role metadata token among the multiple role metadata tokens.

[0039] In this embodiment, when a user registers, an initialization role will be set for the user. Specifically, for example, the initialization role for the user can be set as an ordinary user, or as an administrator, but the user's initial role will usually not be left empty. In some embodiments, the access request can also be a registration request received from a user-operated client, and the registration request can carry the user's registration information. The initialization role for the user can be determined based on the user's registration information, and then the initial role metadata token can be determined. In some embodiments, the business server can also provide the registration information to the management end of the staff, and the staff operates the management end to specify the initialization role for the user. The business server can receive the role designation data sent by the management end, and thus use the user role indicated by the role designation data as the initialization role.

[0040] Step S114: Based on the blockchain wallet address and the initial role metadata token, the dynamic non-fungible digital token smart contract is called to generate a dynamic non-fungible digital token for the blockchain wallet address; wherein the dynamic non-fungible digital token is bound to the initial role metadata token; wherein the dynamic non-fungible digital token can switch the bound role metadata token among multiple role metadata tokens.

[0041] Since the dynamic non-fungible digital token can change the bound metadata token, while the non-fungible digital token cannot be changed, the embodiment of the present application calls the dynamic non-fungible digital token smart contract based on the blockchain wallet address and the initial role metadata token to generate a dynamic non-fungible digital token for the blockchain wallet address, thereby realizing the switching of bound role metadata tokens among multiple role metadata tokens.

[0042] Step S115: Send the dynamic non-homogeneous digital token to the client.

[0043] In some cases, the user's client's blockchain wallet address serves as an identity identifier. Based on the user's initial role, the website assigns corresponding permissions by minting a non-fungible digital token. Once the non-fungible digital token is minted, it is sent to the client. The client proves ownership of the non-fungible digital token by presenting the website with a signature of the blockchain wallet address. Once the signature is successfully verified, the user can use the corresponding permissions. However, when the user's information changes, the corresponding permissions must also be upgraded or downgraded. Since non-fungible digital tokens are immutable and cannot be synchronized with changes, the non-fungible digital token must be re-minted based on the user's information and the client's blockchain wallet address. When user information changes, non-fungible digital tokens must be minted multiple times for the same client's wallet address, which can lead to a waste of resources. Therefore, the inventors propose in this embodiment to generate multiple role metadata tokens for the user during registration and mint dynamic non-fungible digital tokens for the user. In the initial state, the corresponding role metadata token can be selected based on the initial role set for the user.

[0044] In this embodiment, a smart contract can be a specific contract program running on a blockchain. Specifically, when user behavior data changes, the smart contract can verify whether the user behavior data can be used to change permissions based on the preset contract conditions. If the user behavior data meets the preset conditions, the smart contract will generate a dynamic non-fungible digital token and bind it to the role metadata token.

[0045] In some embodiments, obtaining multiple role metadata tokens includes: generating multiple metadata representing user roles according to pre-configured metadata generation rules; calling a service interface of the blockchain to enable the blockchain to store the multiple metadata and generate a role metadata token corresponding to each metadata; and receiving the role metadata token fed back by the blockchain.

[0046] In this embodiment, the business server can be pre-configured with metadata generation rules. Specifically, the metadata generation rules can specify the metadata to be generated. Specifically, the metadata generation rules can be a script that, when called, instantiates multiple metadata representing user roles. For example, the metadata generation rules can pre-specify specific values ​​for the generated metadata, such as standard role, platinum user, and administrator. The generated metadata can be modified by modifying the script.

[0047] The business server can call the blockchain's service interface to provide the generated metadata to the blockchain through this service interface. The blockchain's service interface can be an interface tool pre-integrated into the business server. After receiving the metadata, the blockchain stores it, thereby obtaining a role metadata token. The role metadata token can be used to represent the metadata storage address in the blockchain. This allows the role metadata token to represent the metadata. The blockchain can then return the role metadata token to the business server.

[0048] In some embodiments, user data generated by a user using a client can be obtained; when the user data matches a preset role change condition, a target role metadata token is determined among multiple role metadata tokens; based on the blockchain wallet address and the target role metadata token, a dynamic non-fungible digital token smart contract is called to change the role metadata token bound to the user's dynamic non-fungible digital token from the initial role metadata token to the target role metadata token.

[0049] In this embodiment, user data can be used to represent the data generated by the user's use of the client. Specifically, for example, user data may include, but is not limited to, basic information of users authorized to access, frequently visited pages, consumption patterns, transaction data, and duration of use, among other user behavior data.

[0050] In this embodiment, role change conditions can be preset based on different user roles and role permissions. The preset role change conditions are used to constrain the conditions for changing a user role. When user data indicates that the preset role change conditions have been met, the user role change operation is executed. Specifically, the preset role change conditions may include the preset conditions and the corresponding user role. Thus, when the user data meets the preset conditions, the user role can be changed to the user role corresponding to the preset conditions. Specifically, the preset conditions may include data such as the user's cumulative usage time, the user's transaction amount, and the number of times the user has shared. For example, a shopping platform may have a preset role change condition that requires the user's cumulative transaction amount to reach 10,000 yuan. When the user's cumulative transaction amount reaches the preset value, the user's role can be upgraded to a member user. At this point, the user enjoys the member user permissions after the role change, for example, a member user can enjoy a specific discount when purchasing the same product. In some embodiments, the preset conditions can be represented by regular expressions. Thus, user data can be input into the regular expression and a matching result can be obtained. Of course, in some embodiments, a pre-trained machine learning model can also be used to determine whether the user data matches the preset conditions.

[0051] In this embodiment, when the preset role change conditions are met, the role metadata token bound to the dynamic non-fungible digital token needs to be changed to achieve the change of the user's user role. Specifically, for example, the user's target user role can be determined according to the preset role change conditions, and then the target metadata representing the target user role can be determined. After obtaining the target role metadata token for the target metadata, the role metadata token bound to the dynamic non-fungible digital token can be changed to the target role metadata token.

[0052] In some embodiments, based on the user's blockchain wallet address and the target role metadata token, calling the dynamic non-fungible digital token smart contract includes: sending the client's blockchain wallet address and the target role metadata token to the oracle, so that the oracle provides the blockchain wallet address and the target role metadata token to the dynamic non-fungible digital token smart contract.

[0053] In some cases, when changes in user behavior data necessitate a role change, the user's blockchain wallet address and the target role metadata token corresponding to the desired user role can be sent to a dynamic non-fungible digital token smart contract to modify the bound token. Specifically, a business server can send a user change request, including the user's blockchain wallet address and target role metadata token, to the dynamic non-fungible digital token smart contract. This role change is achieved by modifying the role metadata token bound to the dynamic non-fungible digital token. Alternatively, the business server can send the user's blockchain wallet address and target role metadata token to an oracle, which then provides transaction data to the dynamic non-fungible digital token smart contract.

[0054] In some implementations, the client's blockchain wallet address and target role metadata token are sent to an oracle, which then provides the blockchain wallet address and target role metadata token to the dynamic non-fungible digital token smart contract. Specifically, the service server can determine based on user behavior data. If the user behavior data meets the preset role change conditions, the oracle then sends the user's blockchain address and the desired role change to the oracle, which then sends the data information to the dynamic non-fungible digital token smart contract. Of course, the service server can also directly send the user behavior data and the user's blockchain address to the oracle without determining the user behavior data. The oracle can also set the preset role change conditions. In this way, the oracle can determine whether the user behavior data meets the preset role change conditions. After the oracle makes the determination, it sends the transaction data to the dynamic non-fungible digital token smart contract for verification.

[0055] See also Figure 3One embodiment of the present application provides a method for changing a user role. The method for changing a user role can be applied to an oracle. The method for changing a user role can include the following steps.

[0056] Step S121: Determine the target user role based on the received transaction data including the blockchain wallet address; wherein different user roles have different access rights; wherein the blockchain wallet address corresponds to a dynamic non-fungible digital token bound to a role metadata token; wherein the role metadata token is used to represent metadata stored in the blockchain for representing the user role.

[0057] In some cases, user transaction data can be sent directly from a business server to a dynamic non-fungible digital token smart contract. In this case, the business server, as a centralized device, provides user transaction data that is not fully trustworthy to the dynamic non-fungible digital token smart contract. Therefore, an oracle receives transaction data sent by the business server. Oracles are the trusted means by which blockchains interact with the outside world, inputting external information into the blockchain and triggering the dynamic non-fungible digital token smart contract. The oracle's credibility assessment improves the authenticity of user transaction data sent to the dynamic non-fungible digital token smart contract.

[0058] In this embodiment, the same user can have different user roles, and correspondingly, different user roles have different access rights. Different users can use their client's blockchain wallet address as an identity identifier. By binding a dynamic non-fungible digital token to a role metadata token and sending it to the client's blockchain wallet address, the user obtains their initial user role. Specifically, the user role metadata token represents the metadata stored on the blockchain that represents the user role. This user role metadata can include information such as the user role and role permissions.

[0059] Step S122: Obtain a target role metadata token representing the target user role corresponding to the blockchain wallet address; wherein different user roles correspond to different role metadata tokens; the target role metadata token is used to represent the metadata stored in the blockchain for representing the target user role.

[0060] In this embodiment, different user roles have different corresponding role permissions. Therefore, different user roles correspond to different role metadata. A role metadata token is used to represent the metadata representing the target user role stored in the blockchain. Therefore, different user roles correspond to different role metadata tokens. Specifically, based on the target role corresponding to the client's blockchain wallet address, a corresponding role metadata token can be selected for the user, allowing the user to obtain the target role.

[0061] Step S123: Based on the blockchain wallet address and the target role metadata token, the dynamic non-fungible digital token smart contract is called to change the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token.

[0062] In some cases, users will have an initial role when registering. As the user's usage behavior changes, their corresponding behavioral data will change, so the user's target role will also need to be changed accordingly. Through the dynamic non-fungible digital token smart contract, the role metadata token corresponding to the target role is bound to the user's target role, realizing the user role change, thereby reducing the resource waste caused by multiple non-fungible digital tokens minted for the same user.

[0063] In this embodiment, when the business server determines that the user role needs to be changed, the business server will send the user transaction data including the blockchain wallet address of the user client and the required role change to the oracle. The oracle will make a judgment based on the obtained user behavior data and send it to the smart contract for verification. The user role metadata token bound to the dynamic non-fungible digital token will be changed to the role metadata token corresponding to the target role that the user needs to change.

[0064] In this embodiment, a dynamic non-fungible digital token can modify its bound metadata token via a smart contract based on data changes, enabling the corresponding non-fungible digital token to change accordingly. For example, on a shopping website, when a user's transaction data reaches a preset amount, their behavior data changes, and their corresponding permissions also need to be modified, allowing them to upgrade from a regular user to a platinum user. In this way, if the user's behavior data matches the preset conditions, the corresponding metadata token is determined from multiple role metadata tokens, and the dynamic non-fungible digital token is bound to the role metadata token. Accordingly, in the user's initial state, the dynamic non-fungible digital token can be bound to the initial role metadata token based on the initial role set for the user.

[0065] In some embodiments, determining the target user role based on receiving transaction data including a blockchain wallet address sent by a business server may include: reading the target user role corresponding to the blockchain wallet address in the transaction data, wherein the transaction data includes the blockchain wallet address and target user role with corresponding records; or, when the user data carried in the transaction data matches the preset role change conditions, determining the user's target user role from multiple preset user roles, wherein the user data is data generated by the user using the client.

[0066] In this embodiment, the transaction data received by the oracle may include the corresponding blockchain wallet address and target user role. This designates the target user role within the transaction data. Furthermore, the business server can designate the target user role corresponding to the blockchain wallet address based on business logic, facilitating business processing. In some embodiments, the transaction data provided by the business server may include user data, and the oracle may be configured with preset role change conditions. Thus, when the user data matches the preset role change conditions, the target user role is determined from multiple preset user roles. Because the data processed by the oracle is trusted, the oracle can communicate directly with the dynamic non-fungible digital token smart contract, making the operation of changing the user role represented by the dynamic non-fungible digital token more reliable.

[0067] See also Figure 4 One embodiment of the present application further provides a user registration device 200 . The user registration device 200 may include: a request receiving unit 210 , a token acquiring unit 220 , a determining unit 230 , a calling unit 240 , and a sending unit 250 .

[0068] The request receiving unit 210 is used to receive an access request; wherein the access request is accompanied by the blockchain wallet address of the user's client.

[0069] The token acquisition unit 220 is used to acquire multiple role metadata tokens; wherein the role metadata token is used to represent the metadata stored in the blockchain for representing the user role; wherein different metadata represents different user roles; and different user roles have different access rights.

[0070] The determining unit 230 is configured to determine an initial role metadata token from among the multiple role metadata tokens.

[0071] The calling unit 240 is used to call the dynamic non-fungible digital token smart contract based on the blockchain wallet address and the initial role metadata token to generate a dynamic non-fungible digital token for the blockchain wallet address; wherein the dynamic non-fungible digital token is bound to the initial role metadata token.

[0072] The sending unit 250 is used to send the dynamic non-homogeneous digital token to the user's client.

[0073] The functions and effects achieved by the user registration device provided in this embodiment can be explained in comparison with the aforementioned embodiments and will not be described in detail.

[0074] In some embodiments, the token acquisition unit may include: a generation module, used to generate multiple metadata representing the user role according to pre-configured metadata generation rules; a calling module, used to call the service interface of the blockchain so that the blockchain stores multiple metadata and generates a role metadata token corresponding to each metadata; and a receiving module, used to receive the role metadata token fed back by the blockchain.

[0075] In some embodiments, the user registration device further includes: a data acquisition unit configured to acquire user data generated by a user using a client; a matching unit configured to determine a target role metadata token from a plurality of role metadata tokens when the user data matches a preset role change condition; and a calling unit configured to call a dynamic non-fungible digital token smart contract based on a blockchain wallet address and the target role metadata token, thereby changing the role metadata token bound to the user's dynamic non-fungible digital token from the initial role metadata token to the target role metadata token.

[0076] In some embodiments, the calling unit includes: a sending module for sending transaction data including the client's blockchain wallet address and the target role metadata token to the oracle, so that the oracle provides transaction data to the dynamic non-fungible digital token smart contract.

[0077] See also Figure 5 One embodiment of the present application further provides a user role changing device 300 . The user role changing device may include: a data receiving unit 310 , a target token obtaining unit 320 , and a calling unit 330 .

[0078] The data receiving unit 310 is configured to determine a target user role based on received transaction data including a blockchain wallet address, wherein different user roles have different access rights; wherein the blockchain wallet address corresponds to a dynamic non-fungible digital token bound to a role metadata token; wherein the role metadata token is used to represent metadata stored in the blockchain for representing the user role.

[0079] The target token acquisition unit 320 is used to obtain a target role metadata token representing the target user role corresponding to the blockchain wallet address; wherein different user roles correspond to different role metadata tokens; the target role metadata token is used to represent the metadata stored in the blockchain for representing the target user role.

[0080] The calling unit 330 is configured to call the dynamic non-fungible digital token smart contract based on the blockchain wallet address and the target role metadata token, so as to change the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token.

[0081] The functions and effects achieved by the user role changing device provided in this embodiment can be explained in comparison with the aforementioned embodiments and will not be described in detail.

[0082] In some embodiments, the determination unit may include: a reading module for reading the target user role corresponding to the blockchain wallet address in the transaction data; wherein the transaction data includes the blockchain wallet address and target user role with corresponding records; or, a determination module for determining the user's target user role among multiple preset user roles when the user data carried in the transaction data matches the preset role change conditions; wherein the user data is data generated by the user using the client.

[0083] See also Figure 6 . The embodiment of the present application also provides an electronic device 400, including a memory 440, and one or more processors 470 communicatively connected to the memory 440; the memory 440 stores a computer program 450 that can be executed by one or more processors 470, and the computer program 450 is executed by one or more processors 470 to enable one or more processors 470 to implement a user registration method as in any of the above embodiments, or to enable one or more processors 470 to implement a user role change method as in any of the above embodiments. In this embodiment, the electronic device 400 may further include an internal memory 410 that can cache data for the processor 470, a communication interface 420 for communicating data with the outside, an input device 430 for inputting data to the electronic device 400, and a system bus 480 that connects the various components of the electronic device 400. The memory 440 may also store an operating system 460. Those skilled in the art may also set other components for the electronic device 400, which will not be repeated here.

[0084] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, characterized in that when the computer program is executed by a processor, it implements a user registration method as in any of the above embodiments, or implements a user role changing method as in any of the above embodiments.

[0085] The embodiments of the present application further provide a computer program product comprising instructions, which, when executed by a computer, enables the computer to perform the method in any of the above embodiments.

[0086] It should be understood that the specific examples herein are only intended to help those skilled in the art better understand the embodiments of the present application, rather than to limit the scope of the present invention.

[0087] It can be understood that in the various implementation methods of this application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the implementation method of this application.

[0088] It can be understood that the various embodiments described in this application can be implemented individually or in combination, and the embodiments of this application are not limited to this.

[0089] Unless otherwise indicated, all technical and scientific terms used in the embodiments of the present application have the same meaning as those commonly understood by those skilled in the art in the technical field of the present application. The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit the scope of this application. The term "and / or" used in this application includes any and all combinations of one or more related listed items. The singular forms "a", "above", and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise.

[0090] It is understood that the processor in the embodiments of the present application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above-mentioned method embodiment can be completed by hardware integrated logic circuits in the processor or by software instructions. The above-mentioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above-mentioned method.

[0091] It will be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (programmable ROM, PROM), an erasable programmable read-only memory (erasable PROM, EPROM), an electrically erasable programmable read-only memory (EEPROM) or flash memory. The volatile memory may be a random access memory (RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0092] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, devices and units can refer to the corresponding processes in the aforementioned method implementation methods and will not be repeated here.

[0094] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0095] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0096] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0097] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various implementation methods of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0098] The above are only specific embodiments of the present application, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for changing a user role, characterized in that: The method is applied to an oracle, and the method includes: Determining a target user role based on transaction data including a blockchain wallet address sent by a receiving service server; wherein different user roles have different access rights, and the blockchain wallet address corresponds to a dynamic non-fungible digital token bound to a role metadata token, wherein the role metadata token is used to represent metadata stored in the blockchain that represents the user role; Obtaining a target role metadata token representing the target user role corresponding to the blockchain wallet address; wherein different user roles correspond to different role metadata tokens, and the target role metadata token is used to represent metadata stored in the blockchain for representing the target user role; Based on the blockchain wallet address and the target role metadata token, the dynamic non-fungible digital token smart contract is called to change the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token.

2. The method according to claim 1, characterized in that The determining of the target user role according to the transaction data including the blockchain wallet address sent by the receiving service server includes: Reading the target user role corresponding to the blockchain wallet address in the transaction data; wherein the transaction data includes the blockchain wallet address and target user role with corresponding records; or, When the user data carried in the transaction data matches the preset role change condition, the target user role of the user is determined from a plurality of preset user roles; wherein the user data is data generated by the user using the client.

3. A user registration method, characterized in that: Applied to a business server, the method includes: Receive an access request sent by a user through a client; wherein the access request is accompanied by a blockchain wallet address bound to the client; Acquire multiple role metadata tokens; wherein the role metadata tokens are used to represent metadata stored in the blockchain for representing user roles; wherein different metadata represent different user roles; and different user roles have different access rights; determining an initial role metadata token among the plurality of role metadata tokens; Based on the blockchain wallet address and the initial role metadata token, a dynamic non-fungible digital token smart contract is called to generate a dynamic non-fungible digital token for the blockchain wallet address; wherein the dynamic non-fungible digital token is bound to the initial role metadata token, and the dynamic non-fungible digital token can switch the bound role metadata token among the multiple role metadata tokens; Sending the dynamic non-homogeneous digital token to the client.

4. The method according to claim 3, characterized in that The method of obtaining multiple role metadata tokens includes: Generate multiple metadata representing the user role according to pre-configured metadata generation rules; Calling a service interface of the blockchain to enable the blockchain to store the plurality of metadata and generate a role metadata token corresponding to each metadata; Receive the plurality of role metadata tokens fed back by the blockchain.

5. The method according to claim 3, characterized in that The method further comprises: Obtaining user data generated by the user using the client; determining a target role metadata token from among the plurality of role metadata tokens if the user data matches a preset role change condition; Based on the blockchain wallet address and the target role metadata token, the dynamic non-fungible digital token smart contract is called to change the role metadata token bound to the user's dynamic non-fungible digital token from the initial role metadata token to the target role metadata token.

6. The method according to claim 5, characterized in that The calling of the dynamic non-fungible digital token smart contract based on the user's blockchain wallet address and the target role metadata token includes: Send the client's blockchain wallet address and the target role metadata token to the oracle, so that the oracle provides the blockchain wallet address and the target role metadata token to the dynamic non-fungible digital token smart contract.

7. A device for changing a user role, characterized in that: include: A data receiving unit, configured to determine a target user role based on received transaction data including a blockchain wallet address; wherein different user roles have different access rights; wherein the blockchain wallet address corresponds to a dynamic non-fungible digital token bound to a role metadata token; wherein the role metadata token is used to represent metadata stored in the blockchain that represents the user role; a target token acquisition unit, configured to acquire a target role metadata token representing the target user role corresponding to the blockchain wallet address; wherein different user roles correspond to different role metadata tokens; and wherein the target role metadata token is used to represent metadata stored in the blockchain for representing the target user role; The calling unit is configured to call the dynamic non-fungible digital token smart contract based on the blockchain wallet address and the target role metadata token, so as to change the role metadata token bound to the dynamic non-fungible digital token to the target role metadata token.

8. A user registration device, characterized in that: include: A request receiving unit, configured to receive an access request, wherein the access request is accompanied by a blockchain wallet address of a user's client; A token acquisition unit, configured to acquire a plurality of role metadata tokens; wherein the role metadata tokens are used to represent metadata stored in the blockchain for representing user roles; wherein different metadata represent different user roles; and different user roles have different access rights; a determining unit, configured to determine an initial role metadata token among the plurality of role metadata tokens; A calling unit, configured to call a dynamic non-fungible digital token smart contract based on the blockchain wallet address and the initial role metadata token, and generate a dynamic non-fungible digital token for the blockchain wallet address; wherein the dynamic non-fungible digital token is bound to the initial role metadata token; A sending unit is used to send the dynamic non-homogeneous digital token to the user's client.

9. An electronic device comprising a memory, and one or more processors communicatively coupled to the memory; The memory stores a computer program that can be executed by the one or more processors, and the computer program is executed by the one or more processors to enable the one or more processors to implement the user role changing method as described in claim 1 or 2, or to enable the one or more processors to implement the user registration method as described in any one of claims 3 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the method for changing the user role according to claim 1 or 2, or implements the user registration method according to any one of claims 3 to 6.

Images