Method, device, program product and electronic device for updating user role attributes

Abstract

The application discloses a user role attribute updating method and device, a program product and electronic equipment, relates to the technical field of blockchains or other related technical fields, and the method comprises the following steps: generating a user identifier and L user credentials based on a role change request submitted by a user; generating a cross-chain message based on the user identifier and the L user credentials, wherein the cross-chain message comprises the user identifier, a Merkle root of the L user credentials and target proof, and the target proof is used to represent that a role attribute change in each user credential meets a preset business rule; after the cross-chain message is sent to L blockchains through an asynchronous broadcast mode, performing a verification operation on the received cross-chain message through each blockchain; and updating the role attribute of the user in the local access control list of the corresponding blockchain based on the cross-chain message that passes the verification operation. The application solves the technical problem of high cost of user role attribute updating when the user role change involves multiple blockchains.

Description

Technical Field

[0001] This application relates to the field of blockchain technology or other related technical fields. Specifically, it relates to a method, apparatus, program product, and electronic device for updating user role attributes. Background Technology

[0002] As blockchain technology is increasingly used in enterprise-level applications, its ability to handle complex business processes and facilitate information interconnection is facing severe challenges. Complex business activities often involve multiple parties, multi-level approvals, and dynamic state transitions, requiring blockchain systems to possess sophisticated and programmable access control mechanisms. The existing phenomenon of "blockchain silos" restricts the free flow of assets and various types of information, and how to control user access permissions during cross-chain interactions is also an important issue.

[0003] Existing technologies focus on single-chain permission certification or "one-to-one" dual-chain interactive identity verification, such as the cross-chain messaging mechanism of Hyperledger Fabric (a permissioned blockchain platform) or Polkadot XCMP (a cross-chain message passing protocol), used to achieve on-chain user authentication or cross-chain mapping of assets (especially fungible tokens) between different blockchains. However, there are still gaps in the control of on-chain user permissions. Furthermore, in existing technologies, each change of user role requires a separate XCMP (Cross-Chain Message Passing) message or Hyperledger Fabric relay transaction, with costs increasing linearly with the number of chains. Especially in multi-level approval scenarios, the accumulated gas fees are significant, making it difficult to meet the needs of large-scale business. This results in high costs for updating user role attributes when user role changes involve multiple blockchains.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, program product, and electronic device for updating user role attributes, to at least solve the technical problem of high cost of updating user role attributes when user role changes involve multiple blockchains.

[0006] According to one aspect of this application, a method for updating user role attributes is provided, comprising: generating a user identifier and L user credentials based on a role change request submitted by a user, wherein L is a positive integer, the role change request is used to apply for updating the user's role attributes in L blockchains, and each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes; generating a cross-chain message based on the user identifier and the L user credentials, wherein the cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof, the target proof being used to characterize that the change of the role attributes in each user credential satisfies a preset business rule; after sending the cross-chain message to the L blockchains via asynchronous broadcast, performing a verification operation on the received cross-chain message through each blockchain; and updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation.

[0007] Optionally, generating a user identifier and L user credentials based on a user-submitted role change request includes: generating a user identifier through an identifier registration center based on a preset multi-signature algorithm and the role change request, and storing the correspondence between the user identifier and the user's public key, a chain list, and a revocation list, wherein the chain list is used to store the identifiers of L blockchains, and the revocation list is used to store expired historical identifiers; generating an initial credential for each blockchain through a credential issuance center based on the user identifier, the new role attributes corresponding to the user in each blockchain updated by the role change request, and the validity period; and signing the initial credential for each blockchain through the credential issuance center based on the private key of the business system to obtain L user credentials corresponding to the L blockchains.

[0008] Optionally, generating a cross-chain message based on a user identifier and L user credentials includes: generating a Merkle tree based on the L user credentials using a proof generation engine; determining the Merkle root of the L user credentials based on the Merkle tree; generating a target proof based on the Merkle root of the L user credentials; and encapsulating the user identifier, the Merkle root of the L user credentials, and the target proof using a cross-chain broadcast engine to obtain the cross-chain message.

[0009] Optionally, a verification operation is performed on the received cross-chain message through each blockchain, including: obtaining the relay chain consensus signature of the cross-chain message through a preset routing contract deployed in each blockchain, and parsing the cross-chain message to obtain the parsing result, wherein the relay chain consensus signature is a signature generated by the relay chain based on the cross-chain message through a consensus mechanism, and the parsing result includes a user identifier, a Merkle root of L user credentials, and a target proof; performing a first verification operation on the relay chain consensus signature through the preset routing contract in each blockchain, and performing a second verification operation on the target proof in the parsing result, wherein the first verification operation is used to detect whether the cross-chain message has been tampered with by an attacker, and the second verification operation is used to detect whether the change of the user's new role attribute meets the preset business rules.

[0010] Optionally, updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation includes: obtaining the Merkle root of L user credentials from the parsing result of the cross-chain message that has passed the verification operation; querying the L user credentials in the off-chain cluster based on the Merkle root of L user credentials, wherein the off-chain cluster is used to store each user credential; generating an update instruction corresponding to each of the L blockchains based on the queried L user credentials; and updating the user's role attributes in the local access control list of each blockchain through the control engine based on the update instruction corresponding to each blockchain.

[0011] Optionally, after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation, the method for updating the user role attributes further includes: storing the cross-chain message, the target proof, the hash values ​​corresponding to the L user credentials, and the update records of the local access control list of each blockchain as audit log data in a preset audit blockchain.

[0012] Optionally, after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation, the method for updating the user role attributes further includes: obtaining the latest revocation list and chain list from the identifier registry through the state synchronization module; querying the latest local access control list of each blockchain based on the identifier of each blockchain in the chain list; detecting whether there is a conflict between the user identifier of the user to whom the role attributes belong in the latest local access control list of each blockchain and the expired historical identifier in the revocation list; and performing a rollback operation on the latest local access control list of the i-th blockchain if there is a conflict between the user identifier of the user to whom the role attributes belong in the latest local access control list of the i-th blockchain and the historical identifier.

[0013] According to another aspect of this application, a user role attribute updating device is also provided, comprising: a first generation unit, configured to generate a user identifier and L user credentials based on a role change request submitted by a user, wherein L is a positive integer, the role change request is used to apply for updating the user's role attributes in L blockchains, and each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes; a second generation unit, configured to generate a cross-chain message based on the user identifier and L user credentials, wherein the cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof, the target proof being used to characterize that the change of the role attributes in each user credential satisfies a preset business rule; a target verification unit, configured to perform a verification operation on the received cross-chain message through each blockchain after sending the cross-chain message to the L blockchains via asynchronous broadcast; and a target update unit, configured to update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation.

[0014] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein, when the computer program is running, a method for updating user role attributes that controls the computer program product to perform any of the above-mentioned actions is provided.

[0015] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method for updating user role attributes as described above.

[0016] In this application, a user identifier and L user credentials are first generated based on a user-submitted role change request, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes. Then, a cross-chain message is generated based on the user identifier and L user credentials. The cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof. The target proof is used to demonstrate that the change of the role attributes in each user credential satisfies preset business rules. Then, after the cross-chain message is sent to the L blockchains via asynchronous broadcast, each blockchain performs a verification operation on the received cross-chain message. Subsequently, the user's role attributes in the local access control list of the corresponding blockchain are updated based on the cross-chain message that has passed the verification operation.

[0017] As can be seen from the above, this application adopts a method of generating cross-chain messages based on user identifiers and multi-user credentials. By asynchronously broadcasting the cross-chain message to L blockchains, and having each blockchain verify the target proof in the message to update the user role attributes in the local access control list, the application achieves the goal of centrally and efficiently updating user role attributes in scenarios involving multiple blockchains. This reduces the cost of updating user role attributes and avoids the technical effect of gas fees increasing linearly with the number of chains due to the need to send multiple cross-chain messages or relay transactions for a single role change. In turn, it solves the technical problem of high cost of updating user role attributes when user role changes involve multiple blockchains. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for updating user role attributes, according to an embodiment of this application.

[0020] Figure 2 This is a flowchart of an optional method for updating user role attributes according to an embodiment of this application;

[0021] Figure 3 This is a flowchart of an optional user role attribute update system according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of an optional user role attribute updating device according to an embodiment of this application;

[0023] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] It should also be noted that all information and data (including but not limited to information used for display and analysis) involved in this application are authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send a request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0027] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary security measures have been taken. They do not violate public order and good morals. In addition, this application provides corresponding operation entry points for users to choose to agree to authorization or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0028] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0029] Hyperledger Fabric: A permissioned blockchain platform for enterprises that uses a modular architecture and achieves data isolation and pluggable consensus through channels.

[0030] Polkadot XCMP: A protocol in the Polkadot network used for the secure, asynchronous transmission of cross-chain messages between parachains.

[0031] MSP (Membership Service Provider): A component in Hyperledger Fabric responsible for managing organizational identity, certificate issuance and verification, used to implement trusted authentication of members.

[0032] X.509: A digital certificate standard based on Public Key Infrastructure (PKI) for binding identities and public keys in a network.

[0033] ACL (Access Control List): A list in chaincode or system that shows which subjects have what operation permissions.

[0034] ABAC (Attribute-Based Access Control): A control model that dynamically determines access permissions based on subject, resource, and environment attributes.

[0035] Relay-Chain and Para-chain: The relay-chain provides network-wide consensus and cross-chain scheduling, while the para-chain is an independent execution chain mounted on the relay-chain. It sends and receives messages through XCM (cross-chain message format), and the messages can carry any custom data (including role identifiers).

[0036] XCMP (Cross-Chain Message Passing): The underlying protocol used by Polkadot to send, forward, and confirm messages between parachains.

[0037] XCM (Cross-Chain Message Format): A unified cross-chain message structure in the Polkadot / cross-chain ecosystem, defining the instruction, asset, and data fields of a message.

[0038] Substrate Account: An account model based on Substrate (Polkadot framework) that uses public key hashes to identify on-chain accounts.

[0039] Gas: A unit of measurement for the fees required to execute transactions or smart contracts on public blockchains such as Ethereum, used to prevent resource abuse.

[0040] BLS (Boneh-Lynn-Shacham) multisignature: An aggregated signature scheme based on the BLS12-381 (a 381-bit elliptic curve based on the BLS12 pairing friendly curve) curve, which can compress multiple signatures into a single signature to achieve efficient multi-party consensus.

[0041] Verifiable Credential (VC): A credential that carries attribute information and is protected by a digital signature, and can be securely verified across blockchains to verify its authenticity and integrity.

[0042] ECDSA / Ed25519: Two elliptic curve digital signature algorithms, used for Ethereum and other blockchains, and for modern, efficient signature scenarios, respectively.

[0043] Credential Authority: A trusted entity or organization responsible for issuing, revoking, and managing verifiable credentials.

[0044] Merkle root: The hash aggregation result of all leaf data in the Merkle tree, used to concisely prove the integrity of a set of data on the chain.

[0045] SNARK / PLONK Batch Proofs: An efficient implementation of zero-knowledge proofs, capable of verifying a large number of assertions at once in proofs of constant size.

[0046] Cosmos IBC: Cosmos Network's inter-blockchain communication protocol enables the transfer of assets and data between different chains.

[0047] Axelar GMP: A General Message Passing service provided by the Axelar network for securely forwarding cross-chain messages between heterogeneous blockchains.

[0048] In one optional related technical embodiment, a cross-chain messaging method based on Hyperledger Fabric is provided, the workflow of which is as follows:

[0049] (1) The client submits a transaction request, carrying a signature certificate;

[0050] (2) The endorsement node checks the certificate attributes (e.g., role=auditor) based on the ACL / ABAC in the chaincode;

[0051] (3) After successful endorsement, the product enters the sorting service and is finally written into the ledger.

[0052] In one optional related technical embodiment, a cross-chain messaging method based on Polkadot XCMP is provided, the workflow of which is as follows:

[0053] (1) The source parachain encapsulates the role change information into an XCM message and submits it to the relay chain;

[0054] (2) The relay chain confirms the message in the consensus round and forwards it to the target parachain;

[0055] (3) The runtime module of the target parachain parses the XCM and updates the local role table according to the permission control contract of this chain.

[0056] As can be seen from the above, the Hyperledger Fabric and PolkadotXCMP solutions have the following technical shortcomings when synchronizing cross-chain permissions:

[0057] (1) Inconsistent identity: Hyperledger Fabric relies on the X.509 certificate system, while Polkadot adopts the Substrate Account model. There is a lack of a unique identifier that can be directly mapped between the two, which means that cross-chain roles can only be achieved through manual mapping or additional bridging contracts, which can easily lead to inconsistencies and management costs.

[0058] (2) High cost of cross-chain interaction: Each role change requires sending an XCMP message or Hyperledger Fabric relay transaction separately. The cost increases linearly with the number of chains. Especially in multi-level approval scenarios, the accumulated fees such as Gas are significant and difficult to meet the needs of large-scale business.

[0059] (3) Difficulties in governance and expansion: When adding a new chain, the organization certificate, channel policy or custom XCM parsing module must be reconfigured. The lack of a unified permission model and standardized cross-chain workflow description leads to an exponential increase in the workload of deployment and auditing when the system is expanded.

[0060] (4) Security depends on a single point: The integrity of cross-chain messages depends on the relay chain or centralized bridge nodes. If a fork occurs or a node acts maliciously, role information may be tampered with, thereby undermining business compliance.

[0061] To address the technical deficiencies in the above embodiments, this application uses user identifier + user public key as the unique cross-chain identifier, constructs a unified cross-chain attribute and ABAC permission control framework, and combines batch zero-knowledge proof (ZKP) with one-time asynchronous broadcast, thereby eliminating the technical bottlenecks of inconsistent cross-chain role identities, high interaction costs, difficulty in governance expansion, and single point of security dependence during the user role change process.

[0062] The present application will now be described in detail with reference to various embodiments.

[0063] Example 1

[0064] According to an embodiment of this application, an embodiment of a method for updating user role attributes is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0065] The method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) according to an optional embodiment of this application for implementing a method for updating user role attributes. For example... Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0066] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0067] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the user role attribute update method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned user role attribute update method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0068] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0069] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0070] Under the aforementioned operating environment, this application provides a user role attribute update system (hereinafter referred to as the update system) for executing the user role attribute update method in this application. Figure 2 This is a flowchart of an optional user role attribute update method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0071] Step S201: Generate a user identifier and L user credentials based on the role change request submitted by the user, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes.

[0072] Optionally, the update system generates user identifiers based on a preset multi-signature algorithm and role change requests through an identifier registration center, and synchronously stores the correspondence between user identifiers and users' public keys, chain lists, and revocation lists. The update system generates initial credentials for each blockchain based on user identifiers, the new role attributes of users in each blockchain that are applying for updates through role change requests, and the validity period through a credential issuance center. Then, the credential issuance center signs the initial credentials for each blockchain to obtain L user credentials for L blockchains.

[0073] Optionally, the user identifier is used to uniformly identify the same user across all blockchains; L user credentials refer to verifiable credentials generated for L different blockchains, each containing corresponding role attributes; and new role attributes refer to the permission level or functional role that the user possesses, as determined after approval.

[0074] Optionally, the update system unifies users' cross-chain identities through user identifiers generated by the identifier registry center, solving the problem of inconsistent user identity systems between different blockchains in traditional technologies. By generating user credentials independently for each chain, the update system lays the data foundation for subsequent batch generation of target proofs. Furthermore, the update system transforms unstructured role change requests into standard format user credentials, enabling the subsequent proof generation engine to easily collect the Merkle roots corresponding to these user credentials, thereby supporting subsequent batch verification without processing complex raw business data.

[0075] Step S202: Generate a cross-chain message based on the user identifier and L user credentials. The cross-chain message includes the user identifier, the Merkle root of the L user credentials, and the target proof. The target proof is used to characterize that the change of the role attribute in each user credential satisfies the preset business rules.

[0076] Optionally, the update system first generates a Merkle tree based on L user credentials using a proof generation engine. Then, it determines the Merkle root of the L user credentials based on the Merkle tree. Next, it generates the target proof based on the Merkle root of the L user credentials. Subsequently, it encapsulates the user identifier, the Merkle root of the L user credentials, and the target proof to obtain a cross-chain message.

[0077] Optionally, Merklegen refers to the aggregated result of the hash values ​​of L user credentials, used to characterize the overall state of all user credentials; the target proof is a zero-knowledge proof used to verify that L user credentials satisfy preset business rules. The size of the target proof is fixed and does not increase with the number of credentials.

[0078] Optionally, the update system utilizes Merkle root and zero-knowledge proof technology to compress the L user credentials that originally needed to be verified one by one into a fixed-size target proof data. This avoids transmitting a large amount of original credential data in cross-chain messages, thereby reducing bandwidth usage and on-chain storage costs. At the same time, the zero-knowledge proof mechanism can prevent forged credentials or role changes of unauthorized users from passing verification, thus improving the security of the business system.

[0079] Step S203: After sending the cross-chain message to L blockchains via asynchronous broadcast, each blockchain performs a verification operation on the received cross-chain message.

[0080] Optionally, the verification operation performed by the update system on the received cross-chain message through each blockchain includes a first verification operation and a second verification operation. The first verification operation is used to detect whether the cross-chain message has been tampered with by an attacker, and the second verification operation is used to detect whether the change of the user's new role attribute meets the preset business rules.

[0081] Optionally, asynchronous broadcasting means that after the sender of the cross-chain message issues a request, it can continue the subsequent process without waiting for confirmation from all target chains, and the receiver processes the cross-chain message asynchronously.

[0082] Optionally, the update system adopts an asynchronous broadcast method, which allows a single network interaction to cover L blockchains. Compared with the traditional serial or chain-by-chain interaction method, this reduces the number of interactions, thereby reducing the time latency of cross-chain communication. Furthermore, the update system uses a dual verification mechanism of relay chain signature + ZKP to ensure that messages are not tampered with, ensure the compliance of user role changes, and eliminate the dependence on centralized bridge nodes, thus improving the security of the system.

[0083] Step S204: Update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation.

[0084] Optionally, for cross-chain messages that pass the verification operation, the control engine on each blockchain parses the Merkle root in the cross-chain message, then queries the specific content of L user credentials based on the Merkle root, extracts the new role attributes, and generates an update instruction corresponding to each blockchain based on the extracted new role attributes. Then, the control engine executes the update instruction to update the user's role attributes in the local access control list of the corresponding blockchain.

[0085] Optionally, a local access control list is a local data structure on the blockchain used to store and manage the mapping relationship between user roles and permissions.

[0086] Optionally, the update system proves the compliance of user role changes based on cross-chain messages that have passed the verification operation. The local control engine can directly trust the cross-chain messages and execute the update operation without having to perform cross-chain queries or complex secondary verifications again, thereby improving the efficiency of updating user role attributes and ensuring the consistency of user role status across chains.

[0087] As can be seen from the above, this application adopts a method of generating cross-chain messages based on user identifiers and multi-user credentials. By asynchronously broadcasting the cross-chain message to L blockchains, and having each blockchain verify the target proof in the message to update the user role attributes in the local access control list, the application achieves the goal of centrally and efficiently updating user role attributes in scenarios involving multiple blockchains. This reduces the cost of updating user role attributes and avoids the technical effect of gas fees increasing linearly with the number of chains due to the need to send multiple cross-chain messages or relay transactions for a single role change. In turn, it solves the technical problem of high cost of updating user role attributes when user role changes involve multiple blockchains.

[0088] In one optional embodiment, the update system first generates user identifiers based on a preset multi-signature algorithm and role change requests through an identifier registration center, and stores the correspondence between user identifiers and users' public keys, a chain list, and a revocation list. The chain list stores the identifiers of L blockchains, and the revocation list stores expired historical identifiers. Then, the credential issuance center generates an initial credential for each blockchain based on the user identifiers, the new role attributes corresponding to users in each blockchain that are applying for updates through role change requests, and the validity period. Finally, the credential issuance center signs the initial credential for each blockchain based on the private key of the business system to obtain L user credentials corresponding to the L blockchains.

[0089] Optionally, the identifier (DID) registration center is responsible for the generation, parsing, and on-chain mapping of unique DIDs in the network. It receives DID creation requests submitted by business systems, uses the BLS multisignature algorithm (i.e., the preset algorithm) to generate globally unique DID information bodies (i.e., user identifiers), and records the mapping of user identifiers and user public keys, the chain list, and the revocable revocation list.

[0090] Optionally, the credential issuance center is used to issue verifiable credentials (VC, i.e., the aforementioned user credentials) based on DID. The verifiable credential contains the new role attributes that the user wants to change to (such as role=auditor, level=3) and the validity period. The VC uses ECDSA / Ed25519 to sign the role attributes, and the signer is the private key of the business system or the entrusted credential authority.

[0091] Optionally, the update system generates user identifiers and L user credentials through the above steps, and the technical effects that can be achieved include: (1) standardizing and unifying the management of cross-chain identities: by generating user identifiers based on a "preset multi-signature algorithm" through the identifier registration center, and storing the correspondence between user identifiers and user public keys, the existing technologies of Hyperledger Fabric (dependent on X.509) and Polkadot (dependent on Substrate) are solved. (1) Addressing the issue of inconsistent identity systems among heterogeneous chains such as Account, this mechanism establishes a unique and verifiable unified identity foundation across cross-chain systems, enabling the same user to verify their ownership through public keys on any chain, eliminating the inconsistencies and management costs caused by manual identity mapping; (2) Establishing a refined and timely foundation for access control: The user credentials generated by the credential issuance center contain new role attributes and validity periods, making access control no longer limited to static identity authentication, but rather dynamic authorization based on attributes. By limiting the validity period of the credentials, the system can accurately control the effective time window of user permissions, providing a structured data foundation for subsequent role-based access control; (3) Ensuring the authenticity and non-repudiation of credentials: The credential issuance center uses the private key of the business system to sign the initial credentials to obtain user credentials, ensuring that only user credentials issued by compliant entities with the corresponding private keys can be recognized as valid by subsequent preset routing contracts and control engines. This mechanism utilizes cryptographic signature mechanisms to prevent credential forgery and permission tampering, laying a secure foundation for trusted identity verification in cross-chain interactions.

[0092] In one alternative embodiment, the update system first generates a Merkle tree based on L user credentials using a proof generation engine. Then, it determines the Merkle root of the L user credentials based on the Merkle tree. Next, it generates a target proof based on the Merkle root of the L user credentials. Subsequently, it encapsulates the user identifier, the Merkle root of the L user credentials, and the target proof using a cross-chain broadcast engine to obtain a cross-chain message.

[0093] Optionally, in the case where a business operation involves role changes across multiple chains (such as approval chain A→B→C), the proof (ZKP) generation engine collects the Merkle roots of all VCs (i.e., L user credentials) and generates SNARK / PLONK batch proofs (i.e. target proofs) to prove that all VCs are issued by compliant DID holders and that the changes in role attributes meet preset business rules. The size of the target proof is fixed (approximately 200-300 bytes) and does not change linearly with the number of chains involved in the change.

[0094] Optionally, the cross-chain broadcast engine packages the DID, the Merkle root corresponding to the VC, and the ZKP proof to obtain a cross-chain message body with a uniform format. Then, it sends the cross-chain message through the Polkadot XCMP, Cosmos IBC, or Axelar GMP platform. To reduce costs, the cross-chain broadcast engine adopts a one-time asynchronous batch broadcast mechanism, that is, a single broadcast can cover any number of target blockchains.

[0095] Optionally, the update system encapsulates the cross-chain message through the above steps, and the technical effects that can be achieved include: (1) reducing cross-chain interaction fees: In traditional technology, if the role changes of L users are involved, L independent cross-chain transactions or message transmissions are often required, resulting in gas fees or relay fees increasing linearly or even exponentially with L; In this embodiment, the proof generation engine compresses L user credentials into a target proof of a fixed size and moves the original credential data to off-chain storage, retaining only the Merkle root on the chain, thereby avoiding the increase in fees caused by the increase in the number of chains; (2) ensuring the efficiency of batch user credential verification: By constructing the Merkle tree and extracting the Merkle root, the update system can ensure the efficiency of L user credential verification by using cryptographic hash characteristics without transmitting all the original credential data. The user credentials are not tampered with during transmission and storage. The receiver only needs to verify the proof corresponding to the Merkle root to confirm the validity of all credentials. This solves the problem of security single point of dependence of cross-chain message integrity on relay chain or centralized bridge node in traditional technology. By combining Merkle root with zero-knowledge proof, mathematical level guarantee of data integrity is achieved, while reducing the pressure of on-chain data storage and verification time. (3) Improve the security of privacy protection and permission verification: This embodiment uses target proof to verify the legality and attribute compliance of L user credentials, instead of directly broadcasting the plaintext of all credentials. This makes it impossible for third parties or attacking nodes to directly obtain the specific role attribute details of L users from cross-chain messages, and prevents the security risks caused by the exposure of user credentials.

[0096] In one optional embodiment, the update system first obtains the relay chain consensus signature of the cross-chain message through a preset routing contract deployed in each blockchain, and parses the cross-chain message to obtain the parsing result. The relay chain consensus signature is a signature generated by the relay chain based on the cross-chain message through a consensus mechanism. The parsing result includes a user identifier, a Merkle root of L user credentials, and a target proof. Then, a first verification operation is performed on the relay chain consensus signature through the preset routing contract in each blockchain, and a second verification operation is performed on the target proof in the parsing result. The first verification operation is used to detect whether the cross-chain message has been tampered with by an attacker, and the second verification operation is used to detect whether the change of the user's new role attribute meets the preset business rules.

[0097] Optionally, the update system deploys a lightweight pre-routing contract on each blockchain in the message routing layer. The pre-routing contract is responsible for verifying the source of cross-chain messages (relay chain signature + ZKP verification) and distributing valid messages to the ABAC engine (i.e., control engine) of the local chain. The pre-routing contract stores a massive list of VCs in an off-chain cluster and only retains the Merkle root and ZKP on the chain, thereby reducing on-chain storage costs.

[0098] Optionally, the update system verifies cross-chain messages through the above steps, and the technical effects that can be achieved include: (1) Ensuring the integrity of cross-chain messages: By performing the first verification operation, the network consensus security of the relay chain is utilized, which enables the identification of the risk of tampering with message content during cross-chain transmission, preventing role information tampering caused by malicious actions of relay chain nodes or network attacks, and ensuring business compliance; (2) Reducing computation and storage costs and ensuring the credibility of attribute changes: By performing the second verification operation to verify the target proof (i.e., ZKP batch proof), the preset routing contract can confirm that the role attribute changes in L user credentials conform to the preset business rules without obtaining the detailed content of the plaintext of each user credential (VC). Therefore, it is not necessary to download and verify the complete VC on each target blockchain. Only a fixed-size ZKP proof needs to be verified, which reduces gas consumption and on-chain storage space. Moreover, one verification can cover the permission changes of L users, avoiding the processing overhead that grows linearly with the number of chains or users in the traditional solution.

[0099] In one optional embodiment, the update system first obtains the Merkle root of L user credentials from the parsing result of the cross-chain message that has passed the verification operation. Then, based on the Merkle root of the L user credentials, it queries the off-chain cluster to obtain L user credentials, where the off-chain cluster is used to store each user credential. Then, based on the obtained L user credentials, it generates an update instruction corresponding to each of the L blockchains. Subsequently, the control engine updates the role attributes of the users in the local access control list of each blockchain based on the update instruction corresponding to each blockchain.

[0100] Optionally, the ABAC engine is used to parse the role attributes in the VC and map them to the local access control list (ACL) of this chain. The ABAC engine includes two interfaces: write and query. The write interface is used to accept role update instructions from the Router and update the local role status; the query interface is used to support business contracts to call the ABAC engine for permission verification during execution, which only verifies the local mapping and does not require cross-chain query.

[0101] Optionally, the update system updates the user role attributes in the local access control list of each blockchain through the above steps. The technical effects that can be achieved include: (1) reducing on-chain storage costs and gas fees: In this embodiment, Merkle root is used to perform integrity verification on the chain (combined with ZKP), only retaining the hash digest, while the specific L user credentials are stored in the off-chain cluster. This mechanism of storing stubs on the chain and storing the original data off-chain reduces the cost of cross-chain interaction and on-chain storage; (2) realizing batch role changes: The update system can process the permission changes of L users in one communication cycle through the one-time broadcast of the cross-chain broadcast engine, combined with the batch proof capability of ZKP. After parsing the Merkle root in the result, the complete L user credentials are obtained by querying the off-chain cluster, realizing the decoupling of verification logic and data acquisition. This enables the system to efficiently handle large-scale, multi-user permission change scenarios without initiating cross-chain transactions for each user separately; (3) Ensure the atomicity and consistency of permission updates: In this embodiment, the control engine updates the local access control list of each blockchain based on the update instruction. Since all update instructions originate from the same rigorously verified cross-chain message and ZKP proof, it ensures that the logic of changing the same group of user roles is consistent across multiple blockchains, thus ensuring data consistency during the multi-level transfer of user roles.

[0102] In one optional embodiment, after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation, the update system stores the cross-chain message, the target proof, the hash values ​​corresponding to L user credentials, and the update record of the local access control list of each blockchain as audit log data in a preset audit blockchain.

[0103] Optionally, the update system writes cross-chain messages, ZKP proofs, all VCs, and changes to role attributes into an immutable audit ledger through the regulatory audit module. The audit ledger is stored on a pre-defined audit blockchain, and provides a query API for regulatory agencies or internal auditors to retrieve snapshots of user role status at different points in time.

[0104] Optionally, the update system achieves the immutability and traceability of the entire operation by centrally storing the aforementioned multidimensional data into a preset audit blockchain. By writing cross-chain messages, target proofs, hash values ​​corresponding to L user credentials, and ACL update records into the immutable preset audit blockchain, the update system ensures that all data from the initiation of permission change (VC issuance), cross-chain transmission (broadcast engine), legality verification (ZKP verification) to the final state taking effect (ABAC update) is solidified, thereby guaranteeing the authenticity and integrity of the audit log and meeting the strict compliance requirements of financial-grade application scenarios.

[0105] In one optional embodiment, after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation, the update system first obtains the latest revocation list and chain list from the identifier registry through the state synchronization module. Then, it queries the latest local access control list of each blockchain based on the identifier of each blockchain in the chain list. Next, it checks whether there is a conflict between the user identifier of the user whose role attributes belong to the latest local access control list of each blockchain and the expired historical identifier in the revocation list. Subsequently, if there is a conflict between the user identifier of the user whose role attributes belong to the latest local access control list of the i-th blockchain and the historical identifier, a rollback operation is performed on the latest local access control list of the i-th blockchain.

[0106] Optionally, to ensure state consistency among multiple chains, the update system periodically (e.g., every 10 minutes) pulls the latest revocation list and chain list from the DID registry center through the state synchronization module and broadcasts state verification messages to each chain. If a chain's role mapping is found to be inconsistent with the overall network state, a rollback transaction is automatically triggered (the rollback transaction is executed through the on-chain governance contract) to ensure the consistency of user roles and permissions across the entire network.

[0107] Optionally, the technical effects that the update system can achieve by performing the rollback operation through the above steps include: (1) achieving eventual consistency and atomicity guarantee of cross-chain permission status: In traditional technology, the asynchronous nature of cross-chain messages may cause the permission update on a certain chain to be delayed or inconsistent with the status of other chains. In this embodiment, the latest authoritative revocation list is obtained from the identifier registry center periodically through the state synchronization module, and the latest local access control list of each blockchain is compared with it, which solves the problem of local state inconsistency caused by network delay or message loss, and achieves eventual consistency of permission status between multiple chains; (2) providing an automated anomaly detection and compliance error correction mechanism: by detecting whether there is a conflict between the user identifier of the user to which the role attribute belongs and the expired historical identifier, the system can automatically discover abnormal scenarios where the local permission status and the global revocation status are inconsistent. Especially after multi-level transfer or batch broadcast, if a chain fails to receive the revocation message in time or a fork occurs, it is very easy for expired permissions to occur. In this embodiment, no manual intervention is required to automatically identify such risks, which improves the robustness of the system; (3) preventing compliance risks caused by single point of failure: performing the rollback operation in the case of conflict improves the system's ability to resist malicious attacks.

[0108] In one alternative embodiment, Figure 3 This is a flowchart of an optional user role attribute update system according to an embodiment of this application, such as... Figure 3As shown, the system includes: a DID registration center, a credential issuance center, a ZKP generation engine, a cross-chain broadcast engine, a message routing layer, an ABAC engine, a state synchronization module, and a regulatory audit module. Each of these modules can be deployed independently and interconnected through standardized interfaces.

[0109] Optionally, the steps for updating user role attributes through the above update system are as follows:

[0110] (1) Business Initiation: The business system submits a role change request (e.g., "User A is promoted from auditor to approver").

[0111] (2) DID and VC generation: The DID registration center is called to obtain the user's DID, and the credential issuance center issues a VC containing new role attributes for the DID.

[0112] (3) Batch preparation: If the user role change operation involves changes to multiple chains, the ZKP generation engine collects all VCs, builds a Merkle tree based on all VCs, and generates batch ZKPs.

[0113] (4) Cross-chain broadcast: The cross-chain broadcast engine packages {DID, rootVC, ZKP} into a cross-chain message and sends it to all target blockchains using a one-time asynchronous broadcast. Here, rootVC represents a VC that contains new role attributes.

[0114] (5) Routing and verification: Verify the relay chain signature of the cross-chain message and the batch ZKP carried by the cross-chain message through the preset routing contract of each target blockchain to ensure that the cross-chain message is complete and has not been tampered with.

[0115] (6) The rootVC in the verified cross-chain message is handed over to the target blockchain’s local ABAC engine to parse the VC and update the local roleMap (i.e., the local access control list).

[0116] (7) Audit Log: The complete cross-chain message, ZKP, and VC hash are written into the preset audit blockchain through the regulatory audit module to form an unalterable audit log.

[0117] (8) Status synchronization: The status synchronization module periodically checks the information in the network-wide cancellation list and the chain list. If inconsistency is found, governance rollback is triggered.

[0118] (9) Business completion: The business system receives a success receipt, and subsequent business contracts will directly query the ABAC engine of this chain to complete the permission verification during execution.

[0119] Example 2

[0120] This application embodiment can also provide a user role attribute updating device. It should be noted that the user role attribute updating device of this application embodiment can be used to execute the user role attribute updating method provided in this application embodiment. The following is a description of the user role attribute updating device provided in this application embodiment.

[0121] According to an embodiment of this application, an apparatus for implementing the above-described method for updating user role attributes is also provided. Figure 4 This is a schematic diagram of an optional user role attribute updating device according to an embodiment of this application, such as... Figure 4 As shown, the device includes: a first generation unit 401, a second generation unit 402, a target verification unit 403, and a target update unit 404.

[0122] Optionally, the first generation unit 401 is used to generate a user identifier and L user credentials based on the role change request submitted by the user, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes. The second generation unit 402 is used to generate a cross-chain message based on the user identifier and L user credentials. The cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof. The target proof is used to characterize that the change of the role attributes in each user credential satisfies the preset business rules. The target verification unit 403 is used to perform a verification operation on the received cross-chain message through each blockchain after sending the cross-chain message to the L blockchains via asynchronous broadcast. The target update unit 404 is used to update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation.

[0123] As described above, this device generates cross-chain messages based on user identifiers and multiple user credentials. These messages are then asynchronously broadcast to L blockchains, and each blockchain verifies the target proof within the message to update the user role attributes in its local access control list. This achieves the goal of centrally and efficiently updating user role attributes in scenarios involving multiple blockchains. This reduces the cost of updating user role attributes and avoids the linear increase in Gas fees caused by sending multiple cross-chain messages or relay transactions for each role change. Ultimately, it solves the technical problem of high costs associated with updating user role attributes when multiple blockchains are involved in a user role change.

[0124] In one optional embodiment, the first generation unit 401 includes: a first generation subunit, a second generation subunit, and a signature subunit.

[0125] Optionally, the first generation subunit is used to generate user identifiers through the identifier registration center based on a preset multi-signature algorithm and role change requests, and to store the correspondence between user identifiers and users' public keys, a chain list, and a revocation list, wherein the chain list is used to store the identifiers of L blockchains, and the revocation list is used to store expired historical identifiers; the second generation subunit is used to generate initial credentials for each blockchain through the credential issuance center based on user identifiers, the new role attributes corresponding to users in each blockchain updated by role change requests, and the validity period; the signing subunit is used to sign the initial credentials for each blockchain through the credential issuance center based on the private key of the business system, to obtain L user credentials corresponding to L blockchains.

[0126] In one optional embodiment, the second generation unit 402 includes: a third generation subunit, a determination subunit, a fourth generation subunit, and an encapsulation subunit.

[0127] Optionally, the third generation subunit is used to generate a Merkle tree based on L user credentials through a proof generation engine; the determination subunit is used to determine the Merkle root of L user credentials based on the Merkle tree; the fourth generation subunit is used to generate a target proof based on the Merkle root of L user credentials; and the encapsulation subunit is used to encapsulate the user identifier, the Merkle root of L user credentials, and the target proof through a cross-chain broadcast engine to obtain a cross-chain message.

[0128] In an optional embodiment, the target verification unit 403 includes a parsing subunit and a verification subunit.

[0129] Optionally, a parsing subunit is used to obtain the relay chain consensus signature of the cross-chain message through a preset routing contract deployed in each blockchain, and to parse the cross-chain message to obtain the parsing result. The relay chain consensus signature is a signature generated by the relay chain based on the cross-chain message through a consensus mechanism. The parsing result includes a user identifier, a Merkle root of L user credentials, and a target proof. A verification subunit is used to perform a first verification operation on the relay chain consensus signature through a preset routing contract in each blockchain, and to perform a second verification operation on the target proof in the parsing result. The first verification operation is used to detect whether the cross-chain message has been tampered with by an attacker, and the second verification operation is used to detect whether the change of the user's new role attribute meets the preset business rules.

[0130] In one optional embodiment, the target update unit 404 includes: an acquisition subunit, a query subunit, a fifth generation subunit, and an update subunit.

[0131] Optionally, the following subunits are configured: a first subunit for obtaining the Merkle root of L user credentials from the parsing result of the cross-chain message passed by the verification operation; a second subunit for querying L user credentials in the off-chain cluster based on the Merkle root of the L user credentials, wherein the off-chain cluster is used to store each user credential; a third subunit for generating update instructions for each of the L blockchains based on the queried L user credentials; and an fourth subunit for updating the role attributes of users in the local access control list of each blockchain based on the update instructions corresponding to each blockchain through the control engine.

[0132] In an optional embodiment, the user role attribute updating device further includes a storage unit.

[0133] Optionally, the storage unit is used to store the cross-chain message, the target proof, the hash values ​​corresponding to L user credentials, and the update record of the local access control list of each blockchain as audit log data in a preset audit blockchain after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation.

[0134] In one optional embodiment, the user role attribute updating device further includes: a list acquisition unit, a list query unit, a list detection unit, and a list rollback unit.

[0135] Optionally, the list acquisition unit is used to obtain the latest revocation list and chain list from the identifier registry through the state synchronization module after updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation; the list query unit is used to query the latest local access control list of each blockchain based on the identifier of each blockchain in the chain list; the list detection unit is used to detect whether there is a conflict between the user identifier of the user whose role attributes belong to the latest local access control list of each blockchain and the expired historical identifier in the revocation list; and the list rollback unit is used to perform a rollback operation on the latest local access control list of the i-th blockchain if there is a conflict between the user identifier of the user whose role attributes belong to the latest local access control list of the i-th blockchain and the historical identifier.

[0136] It should be noted that the first generation unit 401, the second generation unit 402, the target verification unit 403, and the target update unit 404 mentioned above correspond to steps S201 to S204 in the method embodiment. The instances and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware components or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and can run in the computer terminal 10 provided in the embodiment.

[0137] Example 3

[0138] Embodiments of this application can also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 5 As shown, the electronic device includes: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0139] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to realize the above-mentioned method for updating user role attributes.

[0140] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0141] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: Generate a user identifier and L user credentials based on a user-submitted role change request, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes. Generate a cross-chain message based on the user identifier and L user credentials. The cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof. The target proof is used to characterize that the change of role attributes in each user credential satisfies preset business rules. After sending the cross-chain message to the L blockchains via asynchronous broadcast, perform a verification operation on the received cross-chain message through each blockchain. Update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message that has passed the verification operation.

[0142] This application provides a scheme for updating user role attributes. The scheme generates cross-chain messages based on user identifiers and multiple user credentials. These messages are asynchronously broadcast to L blockchains, and each blockchain verifies the target proof in the message to update the user role attributes in its local access control list. This achieves centralized and efficient updating of user role attributes in scenarios involving multiple blockchains. It reduces the cost of updating user role attributes and avoids the linear increase in gas fees with the number of chains caused by sending multiple cross-chain messages or relay transactions for each role change. This solves the technical problem of high cost for updating user role attributes when user role changes involve multiple blockchains.

[0143] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0144] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0145] Example 4

[0146] Embodiments of this application may also provide a storage medium.

[0147] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the user role attribute update method provided in the above method embodiment.

[0148] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0149] This application also provides a computer program product, which, when executed on a data processing device, is adapted to perform method steps for updating user role attributes.

[0150] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0151] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0152] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0153] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0155] If the integrated unit is implemented as 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 this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0156] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for updating user role attributes, characterized in that, include: Based on the role change request submitted by the user, a user identifier and L user credentials are generated, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes. A cross-chain message is generated based on the user identifier and the L user credentials, wherein the cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof, and the target proof is used to characterize that the change of the role attribute in each user credential satisfies a preset business rule; After the cross-chain message is sent to the L blockchains via asynchronous broadcast, each blockchain performs a verification operation on the received cross-chain message. The user's role attributes in the local access control list of the corresponding blockchain are updated based on the cross-chain message obtained through the verification operation.

2. The method for updating user role attributes according to claim 1, characterized in that, Based on the user-submitted role change request, a user identifier and L user credentials are generated, including: The identifier registration center generates the user identifier based on a preset multisignature algorithm and the role change request, and stores the correspondence between the user identifier and the user's public key, a chain list, and a revocation list. The chain list is used to store the identifiers of the L blockchains, and the revocation list is used to store expired historical identifiers. The certificate issuance center generates an initial certificate for each blockchain based on the user identifier, the new role attributes corresponding to the user in each blockchain updated according to the role change request, and the validity period. The certificate issuance center signs the initial certificate corresponding to each blockchain based on the private key of the business system to obtain L user certificates corresponding to the L blockchains.

3. The method for updating user role attributes according to claim 1, characterized in that, Generate a cross-chain message based on the user identifier and the L user credentials, including: The proof generation engine generates a Merkle tree based on the L user credentials; The Merkle root of the L user credentials is determined based on the Merkle tree; The target proof is generated based on the L user credentials in the Merkle root. The cross-chain message is obtained by encapsulating the user identifier, the Merkle root of the L user credentials, and the target proof through a cross-chain broadcast engine.

4. The method for updating user role attributes according to claim 1, characterized in that, Perform verification operations on the received cross-chain messages through each blockchain, including: The relay chain consensus signature of the cross-chain message is obtained by the preset routing contract deployed in each blockchain, and the cross-chain message is parsed to obtain the parsing result. The relay chain consensus signature is a signature generated by the relay chain based on the cross-chain message through a consensus mechanism. The parsing result includes the user identifier, the Merkle root of the L user credentials, and the target proof. The first verification operation is performed on the consensus signature of the relay chain through the preset routing contract in each blockchain, and the second verification operation is performed on the target proof in the parsing result. The first verification operation is used to detect whether the cross-chain message has been tampered with by an attacker, and the second verification operation is used to detect whether the change of the user's new role attribute meets the preset business rules.

5. The method for updating user role attributes according to claim 4, characterized in that, Update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed through the verification operation, including: Obtain the Merkle root of L user credentials from the parsing result of the cross-chain message passed by the verification operation; Based on the L user credentials, Merkle retrieves the L user credentials from an off-chain cluster, where the off-chain cluster is used to store each user credential. Based on the L user credentials obtained from the query, an update instruction is generated for each of the L blockchains; The control engine updates the user role attributes in the local access control list of each blockchain based on the update instructions corresponding to each blockchain.

6. The method for updating user role attributes according to claim 1, characterized in that, After updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation, the method for updating the user role attributes further includes: The cross-chain message, the target proof, the hash values ​​corresponding to the L user credentials, and the update records of the local access control list of each blockchain are stored as audit log data in a preset audit blockchain.

7. The method for updating user role attributes according to claim 1, characterized in that, After updating the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation, the method for updating the user role attributes further includes: The state synchronization module obtains the latest revocation list and chain list from the identifier registry center; Based on the identifier of each blockchain in the chain list, the latest local access control list of each blockchain is obtained by querying; Check whether there is a conflict between the user identifier of the user to whom the role attribute belongs in the latest local access control list of each blockchain and the expired historical identifier in the revocation list; If there is a conflict between the user identifier of the user to whom the role attribute belongs in the latest local access control list of the i-th blockchain and the historical identifier, a rollback operation is performed on the latest local access control list of the i-th blockchain.

8. A device for updating user role attributes, characterized in that, include: The first generation unit is used to generate a user identifier and L user credentials based on the role change request submitted by the user, where L is a positive integer. The role change request is used to apply for updating the user's role attributes in L blockchains. Each user credential includes the new role attributes corresponding to the user in each blockchain and the validity period of the new role attributes. The second generation unit is used to generate a cross-chain message based on the user identifier and the L user credentials, wherein the cross-chain message includes the user identifier, the Merkle root of the L user credentials, and a target proof, and the target proof is used to characterize that the change of the role attribute in each user credential satisfies a preset business rule. The target verification unit is used to perform verification operations on the received cross-chain messages through each of the L blockchains after the cross-chain messages are sent to the L blockchains via asynchronous broadcast. The target update unit is used to update the user's role attributes in the local access control list of the corresponding blockchain based on the cross-chain message passed by the verification operation.

9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is executed, it controls the computer program product to perform the user role attribute update method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the user role attribute update method according to any one of claims 1 to 7.

Images