Blockchain-based identity information management method, node, and blockchain system

Abstract

The embodiment of the present application discloses a blockchain-based identity information management method, node, and blockchain system to implement light node management of identity information. The method includes: a first node obtains a block header of a first block to be synchronized from a second node, and verifies whether a chain structure is satisfied between the first block and the previous block of the first block based on the characteristic information included in the block header of the first block and the certificate revocation list (CRL) identifier included in the block header of the first block. If satisfied, it is determined that the first block carries the CRL, and the CRL is obtained from the second node. Alternatively, the second node determines to update the identity information stored in the first block, generates a third block based on the first block and the second block, the second block is the latest block in the current update cycle, the first block and the second block are the previous blocks of the third block, the third block stores the updated identity information in the first block, and the third block is stored on the fork of the main link where the first block is located.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain-based identity information management method, node, and blockchain system. Background Art

[0002] Blockchain is a secure implementation of a distributed ledger, storing transaction information in blocks as a data structure. This structure maintains a chain of blocks. By recording the history of all transactions, blockchain maintains a continuously growing, shareable, and immutable record of transactions. Because blockchains need to record all transaction history, the storage burden on blockchain endorsement nodes in the IoT's big data landscape increases at a rate of terabytes (TB) per year. To alleviate this storage burden, endorsement nodes can be categorized as light nodes or full nodes.

[0003] Full nodes maintain a blockchain consisting of multiple blocks. Each block includes a block header and specific transaction information. Full nodes can participate in consensus with other full nodes to generate and verify new blocks. Light nodes maintain only the block header for each block and do not record specific transaction information. In other words, the blocks they maintain only include the block header, not the specific transaction information. When a light node needs to verify the validity of a transaction in a block, it can obtain auxiliary verification information, calculate the block header based on the auxiliary verification information, and then determine that the transaction information is located in the block containing the block header information based on the calculated block header information.

[0004] As can be seen above, light nodes can perceive blockchain records of transaction information, such as which block the transaction resides on. However, since specific transaction information is stored on full nodes, light nodes are unable to perceive specific transaction information, such as identity management information, payment, and other transaction contexts. For example, while light nodes provide excellent support for non-revocable identity management architectures, they cannot effectively detect updated or revoked identities if other nodes intentionally conceal revoked identity information when synchronizing transaction information to light nodes. This prevents light nodes from effectively recording revoked identities and managing transaction information such as identity information. Therefore, ensuring that blockchain light nodes can effectively record revoked identities and prevent fraud by dishonest identity holders, or even dishonest light nodes, is a key issue in implementing lightweight blockchain identity management in IoT and IoV scenarios. Summary of the Invention

[0005] The present application provides a blockchain-based identity information management method, node, and blockchain system to enable light nodes to manage identity information, especially revoked identity information.

[0006] To achieve the above objectives, the present invention adopts the following technical solutions:

[0007] In a first aspect, a blockchain-based identity information management method is provided. In a possible implementation, the method includes: a first node verifies whether a chain structure is satisfied between the first block and a preceding block of the first block based on characteristic information included in a block header of the first block; if the chain structure is not satisfied between the first block and the preceding block of the first block, the first node verifies whether a chain structure is satisfied between the first block and the preceding block of the first block based on the characteristic information included in the block header of the first block and a certificate revocation list CRL identifier; if satisfied, determining that the first block carries the CRL; and the first node obtains the CRL from the second node.

[0008] Based on the method shown in the first aspect, the block with the identity information revocation record has a structurally different signature feature from other blocks. For example, a CRL identifier is configured for the block with the identity information revocation record. When the block with the identity information revocation record is chained with the previous block, the CRL identifier must be combined to ensure that the block with the identity information revocation record and the previous block satisfy the chain structure. In this way, when the CRL identifier is ignored, that is, the CRL identifier does not participate in the verification of the chain structure, the chain rule between the block with the identity information revocation record and the previous block cannot be passed. When a new block is synchronized, if the downstream light node finds that the current block can only successfully verify the chain rule in combination with the CRL identifier, it will determine that the current block has a CRL identifier stored in it and obtain the CRL from the upstream node. By influencing the CRL identifier of the blockchain chain structure verification, the blockchain can structurally identify whether the target block contains a CRL and use it to request the CRL, making it impossible for the upstream node to hide the fact that there is an identity information revocation record, avoiding the risk of the revoked record being ignored by the light node (such as malicious hiding and interference) and not being synchronized with the entire network. At the same time, in blockchain-based identity management, for light nodes, only identity information revocation records are recorded on the blockchain, and there is no need to maintain all historical transaction information of the entire chain, which significantly reduces the authentication and dynamic delays and communication burdens brought by identity revocation.

[0009] In one possible design, the first node determines whether a hash value calculated by using the characteristic information included in the block header of the first block as a hash input parameter is the same as the hash value of the predecessor block of the first block; if they are the same, the first block and the predecessor block of the first block satisfy a chain structure; if they are different, the first block and the predecessor block of the first block do not satisfy a chain structure.

[0010] In one possible design, the first node determines whether a hash value calculated by using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block; if they are the same, the first block and the preceding block of the first block satisfy a chain structure; if they are different, the first block and the preceding block of the first block do not satisfy a chain structure.

[0011] In one possible design, the CRL is a full list or a differential list.

[0012] In another possible implementation, the scheme described in the first aspect can also be: the first node obtains identity authentication information, the identity authentication information includes the identity information to be verified, the address information of the first block registered with the identity information, and the verification auxiliary information AuxI corresponding to the identity information; the first node determines the first block based on the address information of the first block; if there is a fork in the first block, the third block is determined based on the first block and the second block, the second block is the latest block in the current update cycle, the first block and the second block are the predecessor blocks of the third block, the third block stores the updated identity information in the first block, and the third block is an update block corresponding to the first block located on the forked link; the first node verifies the identity information based on the identity information to be verified, the AuxI corresponding to the identity information, and the third block.

[0013] Another possible implementation method based on the first aspect is to store the updated information in the block in a new block without destroying the main link characteristics of the blockchain, and store the updated block on a fork connected to the main link. With this forked topological relationship, it is possible to perceive the update of the content in a certain block and achieve identity authentication.

[0014] In one possible design, the first node uses the characteristic information included in the block header of the first block and the characteristic information included in the block header of the second block as hash input parameters to calculate a hash value; the first node compares the calculated hash value with the hash value corresponding to each block on the forked link, and uses the block with the same calculated hash value as the third block.

[0015] In one possible design, the first node performs a hash calculation based on the identity information to be verified and the AuxI corresponding to the identity information to obtain a hash value. If the hash value is the same as the hash root of the third block, the identity information is determined to be valid; if the hash value is different from the hash root of the third block, the identity information is determined to be invalid.

[0016] In one possible design, the third block and the last block at the end of the current update cycle serve as the predecessor of the fourth block, which in turn serves as the first block of the next update cycle. This creates a chain structure between the updated block on the fork and the block of the next update cycle. After the update cycle ends, awareness of the updated block is mandatory; otherwise, the next block cannot be passed. This prevents lazy or malicious light nodes from hiding the updated block (i.e., the updated content), and prevents them from maintaining old versions of updated blocks for long periods of time while concealing the fact that relevant identity information has been updated.

[0017] In a second aspect, a blockchain node is provided. The blockchain node can implement the functions performed by the first node in the first aspect or the possible design of the first aspect, and the functions can be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, a processing unit. The processing unit is configured to verify whether a chain structure is satisfied between the first block and the preceding block of the first block based on characteristic information included in the block header of the first block; if the chain structure is not satisfied between the first block and the preceding block of the first block, the processing unit verifies whether a chain structure is satisfied between the first block and the preceding block of the first block based on the characteristic information included in the block header of the first block and a certificate revocation list (CRL) identifier; if so, it is determined that the first block carries a CRL; and the processing unit obtains the CRL from the second node.

[0018] In one possible design, the processing unit is specifically used to determine whether a hash value calculated by using characteristic information included in the block header of the first block as a hash input parameter is the same as a hash value of a preceding block of the first block; if they are the same, the first block and the preceding block of the first block satisfy a chain structure; if they are different, the first block and the preceding block of the first block do not satisfy a chain structure.

[0019] In one possible design, the processing unit is specifically used to determine whether a hash value calculated by using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block; if they are the same, the first block and the preceding block of the first block satisfy a chain structure; if they are different, the first block and the preceding block of the first block do not satisfy a chain structure.

[0020] In one possible design, the CRL is a full list or a differential list.

[0021] In one possible design, the blockchain node also includes a receiving unit, which is used to obtain identity authentication information, where the identity authentication information includes the identity information to be verified, the address information of the first block in which the identity information is registered, and the verification auxiliary information AuxI corresponding to the identity information; the processing unit determines the first block based on the address information of the first block; if there is a fork in the first block, a third block is determined based on the first block and the second block, where the second block is the latest block in the current update cycle, the first block and the second block are the predecessor blocks of the third block, and the third block stores the updated identity information in the first block. The third block is an update block corresponding to the first block and located on the forked link; the processing unit is also used to verify the identity information based on the identity information to be verified, the AuxI corresponding to the identity information, and the third block.

[0022] In one possible design, the processing unit is specifically configured to calculate a hash value using the characteristic information included in the block header of the first block and the characteristic information included in the block header of the second block as hash input parameters; the processing unit is further configured to compare the calculated hash value with the hash value corresponding to each block on the forked link, and to use the block with the same calculated hash value as the third block.

[0023] In one possible design, the processing unit is also used to perform a hash calculation based on the identity information to be verified and the AuxI corresponding to the identity information to obtain a hash value. If the hash value is the same as the hash root of the third block, the identity information is determined to be valid; if the hash value is different from the hash root of the third block, the identity information is determined to be invalid.

[0024] In one possible design, the third block and the last block at the end of the current update cycle are the predecessor blocks of the fourth block, and the fourth block is the first block of the next update cycle.

[0025] In a third aspect, a blockchain node is provided. The blockchain node may be a first node or a chip or system-on-chip within the first node. The blockchain node may implement the functions performed by the first node in the aforementioned aspects or possible designs, and the functions may be implemented in hardware. In one possible design, the blockchain node may include a processor. The processor may be configured to support the blockchain node in implementing the functions described in the aforementioned first aspect or any possible design of the first aspect. For example, the processor may be configured to verify, based on characteristic information included in a block header of a first block, whether a chain structure is established between the first block and its predecessor. If the chain structure is not established between the first block and its predecessor, the processor may verify, based on the characteristic information included in the block header of the first block and a certificate revocation list (CRL) identifier, whether a chain structure is established between the first block and its predecessor. If so, the processor determines that the first block carries a CRL. The processing unit may obtain the CRL from a second node. In another possible design, the blockchain node may further include a memory configured to store computer-executable instructions and data necessary for the blockchain node. When the blockchain node is running, the processor executes the computer-executable instructions stored in the memory to enable the blockchain node to perform the blockchain-based identity information management method as described in the first aspect or any possible design of the first aspect.

[0026] Among them, the specific implementation method of the blockchain node can refer to the behavioral function of the first node in the blockchain-based identity information management method provided by the first aspect or any possible design of the first aspect.

[0027] In a fourth aspect, a blockchain node is provided, comprising one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code or computer instructions; when the one or more processors execute the computer instructions, the blockchain node executes the blockchain-based identity information management method as described in the first aspect or any possible design of the first aspect.

[0028] In a fifth aspect, a computer-readable storage medium is provided, which stores computer instructions or programs. When the computer instructions or programs are run on a computer, the computer executes the blockchain-based identity information management method as described in the first aspect or any possible design of the first aspect.

[0029] In a sixth aspect, a computer program product comprising instructions is provided, which, when run on a computer, enables the computer to execute the blockchain-based identity information management method as described in the first aspect or any possible design of the first aspect.

[0030] In the seventh aspect, a chip system is provided, comprising one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and computer program code or computer instructions are stored in the one or more memories; when the one or more processors execute the computer program code or computer instructions, the chip system executes the blockchain-based identity information management method as described in the first aspect or any possible design of the first aspect.

[0031] Among them, the technical effects brought about by any design method in the third to seventh aspects can refer to the technical effects brought about by any possible design in the first to second aspects mentioned above, and will not be repeated here.

[0032] In an eighth aspect, a blockchain-based identity information management method is provided, the method including: a second node obtains a certificate revocation list CRL; the second node generates a first block based on the obtained CRL, the CRL is stored in the block body of the first block, and a hash value calculated using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block.

[0033] Based on an implementation method of the seventh aspect, a block with an identity information revocation record has a structurally different marking feature from other blocks. For example, a CRL identifier is configured for the block with the identity information revocation record. When the block with the identity information revocation record is chained with the previous block, the CRL identifier must be combined to ensure that the block with the identity information revocation record and the previous block satisfy the chain structure. In this way, when the CRL identifier is ignored, that is, the CRL identifier does not participate in the verification of the chain structure, the chain rule between the block with the identity information revocation record and the previous block cannot be passed. When a new block is synchronized, if the downstream light node finds that the current block can only successfully verify the chain rule in combination with the CRL identifier, it will determine that the current block has a CRL identifier stored in it and obtain the CRL from the upstream node. By influencing the CRL identifier of the blockchain chain structure verification, the blockchain can structurally identify whether the target block contains a CRL and use it to request the CRL, making it impossible for the upstream node to hide the fact that there is an identity information revocation record, avoiding the risk of the revoked record being ignored by the light node (such as malicious hiding and interference) and not being synchronized with the entire network. At the same time, in blockchain-based identity management, for light nodes, only identity information revocation records are recorded on the blockchain, and there is no need to maintain all historical transaction information of the entire chain, which significantly reduces the authentication and dynamic delays and communication burdens brought by identity revocation.

[0034] In one possible design, the second node receives a CRL from a CRL server, and the CRL server stores authorization information corresponding to the CRL.

[0035] In one possible design, the CRL is a full list or a differential list.

[0036] In another implementation of the seventh aspect, the second node determines to update the identity information stored in the first block; the second node generates a third block based on the first block and the second block, the second block being the latest block in the current update cycle, the first block and the second block being the predecessor blocks of the third block, the third block storing the updated identity information in the first block, and the third block being the update block corresponding to the first block; the second node stores the third block on a fork of the main link where the first block is located. Based on another implementation of the seventh aspect, without destroying the main link characteristics of the blockchain, the updated information in the block is stored in a new block, and the updated block is stored on a fork connected to the main link. By virtue of this forked topological relationship, updates to the content in a certain block can be perceived.

[0037] In one possible design, the second node generates a fourth block based on the third block and the last block at the end of the current update cycle. The third and last blocks serve as predecessors of the fourth block, and the fourth block serves as the first block of the next update cycle. This creates a chain structure between the updated block on the fork and the block of the next update cycle. After the update cycle ends, awareness of the updated block is mandatory; otherwise, the next block cannot be passed. This prevents lazy or malicious light nodes from hiding the updated block (i.e., the updated content), and prevents them from maintaining old versions of updated blocks for long periods of time while concealing the fact that relevant identity information has been updated.

[0038] In one possible design, the second node sends an auxiliary information change notification to the BSS associated with the terminal whose identity information is updated, and the auxiliary information change notification is used to trigger the BSS to send updated verification auxiliary information AuxI to the terminal.

[0039] In the ninth aspect, a blockchain node is provided. The blockchain node can implement the functions performed by the second node in the eighth aspect or the possible design of the eighth aspect, and the functions can be implemented by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above functions. For example, a receiving unit and a processing unit. The receiving unit is used to obtain a certificate revocation list CRL; the processing unit is used to generate a first block based on the obtained CRL, the block body of the first block stores the CRL, and the hash value calculated by using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the previous block of the first block.

[0040] In one possible design, the receiving unit is specifically used to receive the CRL from the CRL server, and the CRL server stores the authorization information corresponding to the CRL.

[0041] In one possible design, the CRL is a full list or a differential list.

[0042] In one possible design, the processing unit is further used to determine whether to update the identity information stored in the first block; the processing unit is further used to generate a third block based on the first block and the second block, where the second block is the latest block in the current update cycle, the first block and the second block are predecessor blocks of the third block, the third block stores the updated identity information in the first block, and the third block is an updated block corresponding to the first block; the processing unit is further used to store the third block on a fork of the main link where the first block is located.

[0043] In one possible design, the processing unit is further used to generate a fourth block based on the third block and the last block at the end of the current update cycle, the third block and the last block are predecessor blocks of the fourth block, and the fourth block is the first block of the next update cycle.

[0044] In one possible design, the blockchain node also includes a sending unit, which is used to send an auxiliary information change notification to the BSS associated with the terminal whose identity information is updated. The auxiliary information change notification is used to trigger the BSS to send updated verification auxiliary information AuxI to the terminal.

[0045] In a tenth aspect, a blockchain node is provided. The blockchain node may be a second node or a chip or system-on-chip within the second node. The blockchain node may implement the functions performed by the second node in each of the above aspects or possible designs, and the functions may be implemented in hardware. In one possible design, the blockchain node may include a transceiver and a processor. The transceiver and processor may be used to support the blockchain node in implementing the functions described in the eighth aspect or any of the possible designs of the eighth aspect. For example, the transceiver may be used to obtain a certificate revocation list (CRL); the processor may be used to generate a first block based on the obtained CRL, wherein the CRL is stored in the block body of the first block, and the hash value calculated using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block. In another possible design, the blockchain node may further include a memory for storing computer-executable instructions and data necessary for the blockchain node. When the blockchain node is running, the processor executes the computer-executable instructions stored in the memory, causing the blockchain node to perform the blockchain-based identity information management method described in the eighth aspect or any of the possible designs of the eighth aspect.

[0046] Among them, the specific implementation method of the blockchain node can refer to the behavioral function of the second node in the blockchain-based identity information management method provided by the eighth aspect or any possible design of the eighth aspect.

[0047] In the eleventh aspect, a blockchain node is provided, which includes one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code or computer instructions; when the one or more processors execute the computer instructions, the blockchain node executes the blockchain-based identity information management method as described in the eighth aspect or any possible design of the eighth aspect.

[0048] In the twelfth aspect, a computer-readable storage medium is provided, which stores computer instructions or programs. When the computer instructions or programs are run on a computer, the computer executes the blockchain-based identity information management method as described in the eighth aspect or any possible design of the eighth aspect.

[0049] In the thirteenth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the blockchain-based identity information management method as described in the eighth aspect or any possible design of the eighth aspect.

[0050] In the fourteenth aspect, a chip system is provided, comprising one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, and computer program codes or computer instructions are stored in the one or more memories; when the one or more processors execute the computer program codes or computer instructions, the chip system executes the blockchain-based identity information management method as described in the eighth aspect or any possible design of the eighth aspect.

[0051] Among them, the technical effects brought about by any design method in the tenth to fourteenth aspects can refer to the technical effects brought about by any possible design in the eighth to ninth aspects mentioned above, and will not be repeated here.

[0052] In the fifteenth aspect, a blockchain system is provided, which includes the blockchain node described in any one of the second to third aspects and the blockchain node described in any one of the eighth to ninth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1a This is a diagram of the separation of full node and light node deployment;

[0054] Figure 1b A diagram showing the organizational relationship of transaction information;

[0055] Figure 2 A schematic diagram of the blockchain system provided in an embodiment of the present application;

[0056] Figure 3 A schematic diagram of the structure of a blockchain node provided in an embodiment of the present application;

[0057] Figure 4 A flowchart of a blockchain-based identity information management method provided in an embodiment of the present application;

[0058] Figure 5 A flowchart of a blockchain-based identity information management method provided in an embodiment of the present application;

[0059] Figure 6 A flowchart of a blockchain-based identity information management method provided in an embodiment of the present application;

[0060] Figure 7 A schematic diagram of fork structure-aware identity revocation and block update based on blockchain provided in an embodiment of the present application;

[0061] Figure 8 A flowchart of another blockchain-based management method provided in an embodiment of the present application;

[0062] Figure 9 A schematic diagram of identity information verification provided in an embodiment of the present application;

[0063] Figure 10 A schematic diagram of the structure of a blockchain node 100 provided in an embodiment of the present application;

[0064] Figure 11 A schematic diagram of the structure of a blockchain node 110 provided in an embodiment of the present application;

[0065] Figure 12 A schematic diagram of the structure of a blockchain system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0066] Before introducing the embodiments of the present application, the technical terms involved in the embodiments of the present application are described.

[0067] Blockchain is a secure implementation of a distributed ledger that uses blocks as a data structure to store transaction information. For example, several computing devices in a blockchain system jointly "keep accounts" (i.e., record transaction information) using blocks as a data structure, collectively maintaining a complete distributed database. In a blockchain system, any node can generate a new block based on transaction information sent by a client and broadcast it to other nodes. Other nodes then verify the block. Once all nodes in the blockchain system reach consensus, the new block can be added to the blockchain. A blockchain can include multiple blocks, with adjacent nodes forming a chain structure. This chain structure ensures that once a block is added to each node's replica after consensus, it cannot be altered (or tampered with).

[0068] Transaction information refers to data created by a client through any node and ultimately published to the blockchain's distributed database. Depending on the specific application scenario, transaction information can include transfer records, smart contract records, settlement records, data records, and user identity information records. Transaction information can be divided into narrow and broad categories. In the narrow sense, transaction information refers to a value transfer published by a client to the blockchain. For example, in the traditional Bitcoin blockchain network, transaction information can be the data of a client-initiated transfer within the blockchain. In the broad sense, transaction information refers to any data published by a client to the blockchain. For example, an operator can build a consortium blockchain based on actual business needs and deploy online services (such as rental services, vehicle dispatch services, insurance claims processing, credit services, and medical services) within the consortium blockchain. In such a consortium chain, transaction information can be a business message or service request published by a client within the consortium chain with business intent. Alternatively, transaction information can be data sent by a client to the blockchain to change the client's account status (such as account balance) or user identity credentials.

[0069] It should be noted that, in this application, any information published by a client to a blockchain's distributed database can be considered "transaction information" in this application. To address the limited capabilities of endorsement nodes in the Internet of Things (IoT), current research on blockchain technology in the IoT field is to categorize endorsement nodes into light nodes and full nodes.

[0070] Among them, such as Figure 1a As shown in the figure, full nodes are consistent with traditional endorsement nodes, maintaining all transaction information of the entire chain, and participating in consensus with other full nodes to generate and verify new blocks; light nodes only maintain the block header information of each block and do not record the specific information of each transaction. Figure 1aThe figure shows the relationship between the information maintained by light nodes and full nodes. Compared to full nodes, light nodes remove all transaction information within a block organized in a hash tree from their storage, retaining only the root of the tree (Tx_Root) related to transactions. However, the information maintained by light nodes still retains the essential characteristics of a blockchain and can still verify the correctness of the chain structure between the previous block and the subsequent block: when a light node obtains a new block after having already verified the previous block, it can determine the validity of the new block by verifying the hash result of the new block and whether the content of the Pre_Hash field of the new block matches the hash of the previous block.

[0071] A block is the smallest unit used to record and store electronic transaction information in a blockchain. Blocks are generated one by one in chronological order, and each block records all transactions that occurred during its creation. All blocks are aggregated to form a chain of records, which is called a blockchain. Block sizes may be the same or different in different blockchain systems. A block can consist of a header and a body.

[0072] The block header, also known as the transaction header, primarily records one or more characteristic information of the current block. For example, the block header may include a timestamp, a hash summary of all transaction information in the current block (e.g., the hash root (Tx_Root) of all transaction information organized in a hash tree) (or transaction root), information necessary to form a chain structure with the previous block of the current block (e.g., the hash value of the previous block of the current block (Prev_Hash)), the number of transactions (transaction count), and at least one of the following: a random number (nonce). The timestamp can be used to indicate the time when the current block was generated. To determine the hash value of the current block, the various characteristic information in the block header of the current block is concatenated in a predetermined order to form a string. This string is then hashed to obtain a hash value, which becomes the hash value of the current block. Because the values ​​of the characteristic information included in the block header of different blocks typically vary, each block is uniquely associated with a hash value. Since each block uniquely corresponds to a hash value, and the block header of each block includes the hash value of the previous block (or previous block), multiple blocks can form a blockchain.

[0073] The block body can be used to store transaction information. All transaction information in the block body can be stored in the block in the form of a hash tree. Each transaction information corresponds to a hash value and auxiliary information (AuxI). The block header contains the hash root of all transaction information in the block body organized in a hash tree.

[0074] For example, Figure 1b A schematic diagram of a hash tree is shown in Figure 1b As shown, the hash tree includes leaf nodes and root nodes ( Figure 1b Each node corresponds to a hash value, and the leaf node includes the hash value corresponding to the transaction information and the AuxI corresponding to the transaction information. The leaf nodes in the bottom row are the nodes corresponding to each transaction information. For each transaction information (not limited to identity information or identity credentials), the light node as a verifier only knows the hash root and its validity. Therefore, in addition to the record to be proven, the record prover also needs to verify the AuxI. Figure 1b As shown in the figure, assume that a block contains four identity records: ID1 to ID4. For ID1, which is on the far left, its auxiliary verification information is the node marked as 2 in the figure. When proving that ID1 exists in this block, the prover presents the identity certificate and AuxI. The verifier can calculate the final hash value that is consistent with the hash root in the block header (node ​​marked as 3) through bottom-up hashing. This means that this identity information is registered on the blockchain.

[0075] It should be noted that in the hash tree, the sibling nodes of all nodes on the entire path from the leaf node to the root node corresponding to a transaction information, for example, Figure 1b As shown, the AuxI auxiliary information of ID1 is the two nodes marked as 2. The hash value finally calculated based on ID1 and the AuxI corresponding to the two nodes marked as 2 is consistent with the hash root corresponding to the root node marked as 3, which means that the verification is successful and ID1 itself is registered on the blockchain.

[0076] In a split full node / light node model, after full nodes confirm a new block through consensus, they synchronize the new block's header to light nodes. Light nodes then synchronize their headers with each other, ensuring rapid network-wide synchronization. Currently, the light node model's technology is primarily used to record and verify the authenticity of IoT device perception information. During each consensus cycle, the IoT reports perception information to the blockchain (full nodes) in the form of transactions. Full nodes organize the information into new blocks using a hash tree and broadcast the information. Light nodes receive a new block header with a verifiable chain structure. IoT devices that have reported perception information obtain an AuxI based on the tree structure of the block on the full node. Subsequently, when light nodes need to verify the validity of a particular perception information, the prover uses the AuxI to prove that the information exists in the corresponding block on the blockchain.

[0077] However, current blockchains using a light node model are limited to perceiving information on the blockchain record and have not expanded into core blockchain services, such as identity management or even transaction environments like payments. For example, light nodes provide excellent support for non-revocable identity management architectures. However, when revoking an identity, the hash information stored by the light node cannot detect identity updates or revocations. When a revoked user attempts to inform the validator that their identity was previously registered on the blockchain, they fail to acknowledge that their identity revocation information is also recorded on the blockchain. For example, in identity management, suppose a terminal's identity information is successfully registered in block k but is revoked in block k+j (where j > 0). (The revocation is not restricted to a specific type, but the transactions in that block indicate that the terminal's identity information registered in block k has been revoked.) However, to the light node validator, block k and block k+j appear to be two separate blocks, each containing transactions that are hashed to obscure any semantic information. Therefore, for the terminal, when it proves its identity information in the kth block by verifying the auxiliary information, it must be forced to indicate that its identity information has been revoked. However, for the attacker, this will not be done and can be evaded, making the light node unable to perceive that the terminal's identity information has been revoked.

[0078] In order to solve the problem of light node management identity information, the present application provides a blockchain-based identity information management method, which may include: configuring a CRL identifier for the block storing the CRL, considering the CRL identifier when forming a chain, and only when the block storing the CRL and the previous block of the block are combined with the CRL identifier can the chain structure between the blocks be satisfied. If the CRL identifier is ignored, the chain of the block carrying the CRL will not be realized. Specifically, the method can refer to the following Figures 4 and 5 As described in the corresponding embodiments.

[0079] Alternatively, the present application also provides a blockchain-based identity information management method, which may include: when updating the identity information in a block, storing the updated identity information in the block in the update block, and storing the update block on the forked link, so that the new block corresponding to the updated block is determined through the forked structure of the blockchain, and the validity of the identity information is verified in the new block. Specifically, the method can refer to the following Figure 6 or Figure 8 shown.

[0080] The following describes the blockchain-based identity information management method provided by this application in conjunction with the accompanying drawings.

[0081] Figure 2 A block chain system structure diagram provided in an embodiment of the present application is as follows: Figure 2As shown, the blockchain system may include terminals (or clients), full nodes, and light nodes. Light nodes may include untrusted nodes and trusted nodes. Figure 2 The blockchain system shown may also include access points, business support systems (BSS), certificate revocation lists (CRL) servers, etc. The CRL server can be deployed independently or integrated into a full node without restriction. Figure 2 The accompanying drawings are for illustrative purposes only. Figure 2 The network elements shown and the number of network elements are not limited.

[0082] Below Figure 2 Introduce each network element in:

[0083] A terminal can be terminal equipment (TE), user equipment (UE), mobile station (MS), or mobile terminal (MT). Specifically, a terminal can be a mobile phone, tablet computer, or computer with wireless transceiver capabilities. It can also be a virtual reality (VR) terminal, augmented reality (AR) terminal, wireless terminal for industrial control, wireless terminal for autonomous driving, wireless terminal for telemedicine, wireless terminal for smart grids, wireless terminal for smart cities, smart home, or in-vehicle terminal. Users can use the terminal in the blockchain system to create chaincodes, initiate transactions, and perform other functions. The terminal can be deployed on any electronic device and implemented using the blockchain system's corresponding software development kit (SDK). The electronic device communicates with nodes in the blockchain network to implement the corresponding terminal functions.

[0084] Among them, the full node and light node are as mentioned above, which are used to generate blockchain and store / record transaction information in the form of blockchain.

[0085] The CRL server can perform authorization authentication for identity information revocation records.

[0086] The BSS may manage terminals within its area, such as managing the registration method of identity information of the terminals within its area.

[0087] Access nodes are primarily used to implement terminal resource scheduling, wireless resource management, wireless access control, and other functions. Specifically, an access node can be a small base station, a wireless access point, a transmission receive point (TRP), a transmission point (TP), or any other type of access node.

[0088] It should be noted that the node in this application can be understood as a processing unit. In one implementation, the node can be a physical device, such as a server or a terminal device. In another implementation, the node can be a virtual computer; a virtual computer is a general term for the operating environment virtualized by software in all types of virtualized devices, and this concept includes virtual machines and containers. In other implementations, a node can be a process or a thread; a thread is the smallest unit that the operating system can perform computational scheduling. A thread is contained in a process and is the actual operating unit in the process; a process is an operation activity of a program in a computer on a certain data set, and is the basic unit for resource allocation and scheduling in the system.

[0089] In the specific implementation, Figure 3 Each node shown can be Figure 3 The structure shown or including Figure 3 Parts shown. Figure 3 This is a schematic diagram of the composition of an apparatus 300 provided in an embodiment of the present application. When the apparatus 300 has the functions of a terminal as described in an embodiment of the present application, the apparatus 300 may be a terminal or a chip or system-on-chip in the terminal. When the apparatus 300 has the functions of an access node as described in an embodiment of the present application, the apparatus 300 may be an access node or a chip or system-on-chip in the access node.

[0090] like Figure 3 As shown, the apparatus 300 may include a processor 301, a communication line 302, and a communication interface 303. Furthermore, the apparatus 300 may also include a memory 304. The processor 301, the memory 304, and the communication interface 303 may be connected via the communication line 302.

[0091] The processor 301 may be a central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 301 may also be other devices with processing functions, such as circuits, devices, or software modules.

[0092] The communication line 302 is used to transmit information between the components included in the device 300.

[0093] The communication interface 303 is used to communicate with other devices or other communication networks. The other communication network can be Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc. The communication interface 303 can be a radio frequency module, a transceiver, or any device capable of achieving communication. The embodiment of the present application is described using the communication interface 303 as an example of a radio frequency module, wherein the radio frequency module may include an antenna, a radio frequency circuit, etc., and the radio frequency circuit may include a radio frequency integrated chip, a power amplifier, etc.

[0094] The memory 304 is used to store instructions, where the instructions may be computer programs.

[0095] The memory 304 may be a read-only memory (ROM) or other types of static storage devices that can store static information and / or instructions, or a random access memory (RAM) or other types of dynamic storage devices that can store information and / or instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage, magnetic disk storage media, or other magnetic storage devices. Optical disc storage includes compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.

[0096] It should be noted that memory 304 can exist independently of processor 301 or can be integrated with processor 301. Memory 304 can be used to store instructions, program code, or data. Memory 304 can be located within or outside device 300, without limitation. Processor 301 is configured to execute instructions stored in memory 304 to implement the data transmission methods provided in the following embodiments of this application.

[0097] In one example, the processor 301 may include one or more CPUs, such as Figure 3 CPU0 and CPU1 in.

[0098] As an optional implementation, the apparatus 300 includes multiple processors, for example, Figure 3 In addition to the processor 301, a processor 307 may also be included.

[0099] As an optional implementation, the apparatus 300 further includes an output device 305 and an input device 306. The input device 306 is a keyboard, a mouse, a microphone, or a joystick, and the output device 305 is a display screen, a speaker, or other devices.

[0100] It should be noted that the device 300 can be a desktop computer, a portable computer, a network server, a mobile phone, a tablet computer, a wireless terminal, an embedded device, a chip system or a computer with a Figure 3 In addition, Figure 3 The structure shown in the figure does not constitute a limitation on the device, except Figure 3 In addition to the components shown, the device may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0101] In the embodiment of the present application, the chip system can be composed of chips, or can include chips and other discrete devices.

[0102] Below is Figure 2 Taking the architecture shown in FIG. 1 as an example, the blockchain-based identity information management method provided by the embodiment of the present application is described. It should be noted that, in the following embodiments, each device may have Figure 3The components shown, the message names or parameter names in the messages exchanged between the various devices in the embodiment of the present application are only examples, and other names may also be used in specific implementations. For example, the synchronization described in the embodiment of the present application can be replaced by terms such as consensus. The determination in the embodiment of the present application can also be understood as creation (create) or generation (generate), and the "include" in the embodiment of the present application can also be understood as "carry", etc., and the embodiment of the present application does not make specific limitations on this. In addition, it should be noted that the present application is not limited to identity management based on blockchain, such as identity revocation management, and can also manage other deliberately hidden information based on blockchain, such as modified / updated transaction information, etc., that is, the method described in the present application can also manage other deliberately hidden information without limitation.

[0103] Figure 4 This application provides a blockchain-based identity information management method, such as Figure 4 As shown, this may include:

[0104] Step 401: The second node obtains a certificate revocation list (CRL).

[0105] The second node can be Figure 2 There is no restriction on full nodes or light nodes in the system shown.

[0106] Among them, the CRL may include identity information revocation records (or certificate revocation records) collected over a period of time. The identity information revocation record may record one or more revoked identity information, revocation time, revocation reason, etc. Such identity information may be identity information registered with the blockchain of the second node, or expired identity information, etc. The present application is not limited to storing identity information revocation records in the form of a list, and may also be stored in other forms without limitation. In addition, the present application is not limited to calling the list including identity information revocation records a CRL, and may also be named by other names without limitation.

[0107] In each embodiment of the present application, the CRL can be a full list or a differential list, without limitation. The full list can refer to a CRL that stores all / all identity information revocation records collected within a period of time (such as one or several consecutive update cycles), and the differential list can refer to a CRL that only stores incremental identity information revocation records collected within the current update cycle / at the current moment. Incremental identity information revocation records refer to some identity information revocation records that are newly added based on the identity information revocation records collected in the previous update cycle adjacent to the current update cycle. For example, taking the collection of identity information revocation records within four update cycles as an example, all identity information revocation records within the four update cycles can be stored in the CRL, or all identity information revocation records within the first update cycle can be stored in CRL1 during the first update cycle, and the identity information revocation records newly added based on CRL1 during the second update cycle can be stored in CRL2, the identity information revocation records newly added based on CRL2 during the third update cycle can be stored in CRL3, and the identity information revocation records newly added based on CRL3 during the fourth update cycle can be stored in CRL4.

[0108] Exemplarily, when the second node is a full node, if the CRL server is deployed independently of the second node, the second node can obtain the CRL from the CRL server. In this case, the CRL server verifies the validity of each identity information revocation record in the CRL, retains the identity information revocation records that are not valid, does not store the identity information revocation records that are not valid in the CRL, and stores the valid identity information revocation records in the CRL and sends them to the second node. If the CRL server is integrated on the second node, the second node can obtain the CRL from the BSS. When the second node is a light node, the second node can obtain the CRL from the upstream node or source node of the second node. The way the second node obtains the CRL from the upstream node or source node is the same as the way the first node obtains the CRL from the second node in the embodiment of the present application.

[0109] It should be noted that if the CRL server is integrated on the second node, after the second node obtains the CRL from the BSS, it can verify the validity of each identity information revocation record included in the CRL, eliminate the identity information revocation records that are not valid in the CRL, and retain the identity information revocation records that are valid.

[0110] Step 402: The second node generates a first block based on the obtained CRL. The CRL is stored in the block body of the first block. The hash value calculated by using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the previous block of the first block.

[0111] Exemplarily, the second node may store the CRL in the block body of the first block. Furthermore, the second node sets a block header for the first block, wherein the first block, combined with the CRL identifier, satisfies a chain structure with the preceding block of the first block. For example, a hash value obtained by using the characteristic information included in the block header and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block.

[0112] The CRL identifier can be used to determine whether the current block contains / carries a CRL, or alternatively, the CRL identifier can be used to detect whether a CRL exists. The CRL identifier can be any combination of bits, letters, and numbers and can be configured as needed without limitation. Once the current block contains a CRL, the CRL identifier is combined with the characteristic information of the block header as hash input parameters for the hash calculation. The calculated hash result is the same as that of the previous block. In other words, if the hash value calculated based on the characteristic information of the block header of the first block is the same as the hash value of the previous block, then the current block is determined to not contain a CRL. Conversely, if the hash value calculated based on the characteristic information of the block header of the first block is different from the hash value of the previous block, but the hash value calculated based on the characteristic information of the block header of the first block is the same as the hash value of the previous block, then the current block is determined to contain a CRL.

[0113] For example, taking the second node as a full node, after the second node obtains the CRL, it generates the first block in the following manner: initialize the first block (that is, the first block is empty), carry the CRL list in the block body of the first block, and at the same time, set the characteristic information in the block header of the first block, such as the hash root corresponding to the CRL list, the random number, the hash value of the previous block, the number of transactions corresponding to the CRL, the timestamp, etc., so that the hash value obtained by hashing the characteristic information in the block header of the first block together with the CRL identifier is the same as the hash value of the previous block of the first block, satisfying the chain structure.

[0114] It should be noted that after the CRL is determined, the hash root (Tx_Root) corresponding to the CRL list, the hash value (Prev_Hash) of the previous block, the number of transactions corresponding to the CRL, and the timestamp (timestamp) are fixed and cannot be adjusted. Only the random number is adjustable. At this time, setting the characteristic information in the block header of the first block mainly means setting the value of the random number, so that the hash value obtained by hashing the characteristic information in the block header of the first block including the random number together with the CRL identifier is the same as the hash value of the previous block of the first block.

[0115] The description of each feature information included in the block header of the first block can be referred to above and will not be repeated here. This application does not change the structure of the block header, and the feature information included in the block header and the meaning of each feature information are the same as in the existing standard.

[0116] At this point, the second node completes the consensus of the first block, which is the block storing the CRL.

[0117] Furthermore, the second node sends a revocation response, such as sending a revocation response to the CRL server, where the revocation response is used to indicate that the CRL is successfully stored on the block.

[0118] Step 403: The second node synchronizes the block header of the first block to the first node.

[0119] The first node can be called an endorsement node. Figure 1a The first node can be a node different from the second node in Figure 1a The light nodes in Figure 1a The full nodes in the [ ] are not limited. The first node can include at least one blockchain, and each blockchain can include at least one block. Between the first node and the second node, the first node can be called a downstream node, and the second node can be called an upstream node or source node.

[0120] Illustratively, the second node may send synchronization information, where the synchronization information carries the block header of the first block.

[0121] Step 404: The first node obtains the block header of the first block to be synchronized.

[0122] Illustratively, the first node may monitor the synchronization information sent by the second node and carrying the block header of the first block, and obtain the block header of the first block from the received synchronization information.

[0123] Step 405: The first node verifies whether the first block and the preceding block of the first block satisfy a chain structure based on the characteristic information included in the block header of the first block.

[0124] Exemplarily, the first node can use characteristic information of the block header of the first block (such as a hash root, a timestamp, a random number, etc.) as a hash input parameter, and input it into the hash algorithm to calculate the hash value of the first block. If the calculated hash value is the same as the hash value of the preceding block of the first block, it is determined that the chain structure is satisfied; otherwise, it is determined that the chain structure is not satisfied.

[0125] The hash algorithm may include a secure hash algorithm (SHA) 256 or a hash-based message authentication code (HMAC) algorithm, etc., without limitation.

[0126] Step 406: If the first block and the preceding block of the first block do not satisfy the chain structure, the first node verifies whether the first block and the preceding block of the first block satisfy the chain structure based on the characteristic information and CRL identifier included in the block header of the first block. If so, it is determined that the first block carries the CRL.

[0127] Exemplarily, the first node can input the characteristic information of the block header of the first block (such as hash root, timestamp, random number, etc.) and the CRL identifier as hash input parameters into the hash algorithm to calculate a hash value. If the calculated hash value is the same as the hash value of the preceding block of the first block, it is determined that the first block and the preceding block of the first block satisfy the chain structure, and the first block carries the CRL.

[0128] Step 407: The first node obtains the CRL from the second node, and stores the obtained CRL in the first block, such as storing the CRL in the block body of the first block.

[0129] For example, a first node may send a request message to a second node, the request message may include a hash root included in the block header of the first block, and the request message may be used to request a CRL. The second node receives the hash root included in the block header of the first block, uses the received hash root as an index to search each block in the blockchain locally stored by the second node, finds the block that includes the hash root, obtains the CRL from the found block, and sends it to the first node.

[0130] At this point, the synchronization of the first block from the second node to the first node is completed.

[0131] Furthermore, if the CRL is a full list, then after the first node obtains the CRL, it can clear the previously cached CRL, such as clearing the CRL stored in the previous update cycle. For example, taking the collection of identity information revocation records within four update cycles as an example, in the first update cycle, all identity information revocation records within the first update cycle are stored in CRL1. In the second update cycle, the identity information revocation records newly added based on CRL1 are stored in CRL2. In the third update cycle, the identity information revocation records newly added based on CRL2 are stored in CRL3. In the fourth update cycle, if the full list of CRLs is obtained, CRL3, CRL2, and CRL1 can be cleared.

[0132] Furthermore, if the first node only uses the characteristic information included in the block header of the first block as the hash input parameter and verifies that the first block and the preceding block of the first block satisfy the chain structure, it is determined that there is no CRL in the first block, and there is no need to execute steps 406-407, and there is no need to synchronize the CRL. Only the block header of the first block needs to be synchronized.

[0133] based on Figure 4 In the method shown, a block with an identity information revocation record has structurally different marking features from other blocks. For example, a CRL identifier is configured for the block with the identity information revocation record. When the block with the identity information revocation record is chained with a preceding block, the CRL identifier must be combined to ensure that the block with the identity information revocation record and the preceding block satisfy the chain structure. Therefore, if the CRL identifier is ignored, that is, the CRL identifier does not participate in the verification of the chain structure, the chain rule between the block with the identity information revocation record and the preceding block cannot be passed. When a new block is synchronized, if the downstream light node finds that the current block can only successfully verify the chain rule in combination with the CRL identifier, it will determine that the current block has a CRL identifier stored in it and obtain the CRL from the upstream node. By influencing the CRL identifier of the blockchain chain structure verification, the blockchain can structurally identify whether the target block contains a CRL and use it to request the CRL, making it impossible for the upstream node to hide the fact that there is an identity information revocation record, avoiding the risk of the revoked record being ignored by the light node (such as malicious hiding and interference) and not being synchronized with the entire network. At the same time, in blockchain-based identity management, for light nodes, only identity information revocation records are recorded on the blockchain, and there is no need to maintain all historical transaction information of the entire chain, which significantly reduces the authentication and dynamic delays and communication burdens brought by identity revocation.

[0134] Figure 4 The method shown is compared with existing identity management technologies other than Sovrin and Hyperledger Indy. Figure 4 In the method shown, the blockchain endorsement node can be deployed as a light node when serving as a query node. This makes this embodiment advantageous in querying and verifying blockchain-based identity registration records in latency-sensitive or capacity-constrained business scenarios. Compared with the Cryptographic Accumulator mechanism of Sovrin / Hyperledger Indy, Figure 4 In the method shown, a tolerable storage requirement is imposed on the blockchain light node serving as the identity authentication node, such as storing only the CRL. This ensures that during the identity revocation process, there is no need for the trusted maintainer of the accumulator to issue auxiliary information to the holder of the non-revokated identity, thereby alleviating the burden on the holder of the non-revokated identity.

[0135] The following example uses the CRL server to independently deploy, register the terminal's identity information to the block first, and then revoke the terminal's identity information. Figure 4 The method shown is described in detail. Figure 5 A flowchart of a blockchain-based identity information management method provided in an embodiment of the present application is as follows: Figure 5 As shown, the method may include:

[0136] Step 501: The terminal and the BSS negotiate the registration of identity information. If the negotiation is successful, step 502 is executed.

[0137] Exemplarily, the negotiation between a terminal and a BSS regarding the registration of identity information may include: the terminal sending a first request to the BSS, the first request carrying identity information (e.g., an identity ID). The first request may be used to request registration of the identity information. The identity information may be new identity information, such as identity information that has not been previously registered or stored in a blockchain, or the identity information may be expired and needs to be continued in use. The BSS receives the first request sent by the terminal, performs authorization verification on the terminal, and determines whether the terminal is allowed to register or store the identity information in the blockchain. If the terminal is allowed to register the identity information in the blockchain, the terminal is determined to be a legitimate user and the negotiation is successful. Conversely, if the terminal is not allowed to register the identity information in the blockchain, the terminal is determined to be an illegal user and the negotiation fails.

[0138] The BSS can determine whether to allow the terminal to register its identity information on the blockchain based on the terminal's contract information. The terminal's contract information can be used to indicate certain services the terminal signed when joining the network, such as a contract to use blockchain data storage. If the contract information indicates that the terminal has signed a contract to use blockchain data storage, then the terminal is allowed to register its identity information on the blockchain. Otherwise, the terminal is not allowed to register its identity information on the blockchain, and the process ends.

[0139] It should be noted that multiple terminals within the BSS domain (or referred to as the BSS coverage area or the BSS management area) can refer to the above process to negotiate the registration of identity information with the BSS. Figure 5 The identity information in the method shown can also be replaced by transaction information and other information without limitation.

[0140] Step 502: The BSS sends a second request to the second node.

[0141] The second node can be Figure 4 The above steps are as described in step 401 and will not be described in detail here.

[0142] The second request may be used to request that the identity information of the terminal be registered / stored on the blockchain of the second node, and the second request may carry the identity information of the terminal.

[0143] It should be noted that the BSS can execute the process shown in step 501, negotiate with multiple terminals, and after the negotiation, carry the identity information of multiple terminals in a second request and send it to the second node, so as to realize the registration of multiple identity information to the second node through one request message; or, the BSS carries the identity information of multiple terminals in multiple second requests, and one second request carries the identity information of one terminal.

[0144] If the second request carries identity information of multiple terminals, the BSS may send the second request to the second node according to Figure 1b The hash tree process shown organizes multiple identity information within its own domain, configures AuxI for each terminal's identity information, and obtains hash roots corresponding to the multiple identity information. In this case, the second request can also carry hash trees corresponding to the multiple identity information. Alternatively, the BSS does not generate a hash tree, but instead, after receiving the second request, the second node generates a hash tree based on the multiple identity information carried in the second request.

[0145] Among them, BSS organizes multiple identity information into Figure 1b The hash tree method shown can refer to the existing technology and will not be described in detail. For example, one or more other BSSs can refer to the method shown in step 502 to send multiple identity information under their own domain to the second node.

[0146] Step 503: The second node receives the second request from the BSS, and stores (or registers / saves) the identity information carried in the second request in block 1.

[0147] Exemplarily, after receiving the second request sent by the BSS, the second node organizes the multiple identity information sent by the BSS into a hash tree, writes it into the block body of block 1, completes the consensus on the identity information record, and at the same time, configures the block header of block 1 so that block 1 and the previous block of block 1 satisfy a chain structure, such as the hash value obtained by using the characteristic information of the block header of block 1 as the hash input parameter is the same as the hash value of the previous block. It should be noted that if the second request sent by the BSS received by the second node carries a hash tree, the second node does not destroy the hash tree sent by each BSS, that is, does not destroy the organizational relationship of the BSS for the identity information within its domain, and uses the hash root submitted by each BSS as a leaf node to organize a binary tree, and saves the binary tree in the block body of block 1.

[0148] Before the second node records the identity information sent by the BSS in the block, in order to ensure the legitimacy of the local registration, the method further includes: the second node verifies the legitimacy of the BSS. If the BSS is legal, the identity information sent by the BSS is recorded in the block; otherwise, if the BSS is illegal, the identity information sent by the BSS is not recorded.

[0149] Among them, the second node can verify the legitimacy of the BSS in the following manner: the second node sends a verification request to the management personnel, the verification request is used to verify whether the BSS is legal, and the verification request may include identification information of the BSS used to identify the BSS. After receiving the verification request, the management personnel checks whether the BSS is the BSS that manages the area based on the identification information of the BSS. If so, it is determined that the BSS is legal, and an indication information of the legality of the BSS is sent to the second node. Otherwise, it is determined that the BSS is illegal, and an indication information of the illegality of the BSS is sent to the second node.

[0150] Furthermore, the second node connects block 1 to the blockchain in chronological order, such as connecting it to the previous block of block 1.

[0151] Step 504: The second node sends the address information of block 1 and the AuxI corresponding to each identity information in block 1 to the BSS.

[0152] The address information of block 1 can be used to identify the location of block 1 in which blockchain. The address information of block 1 can also be named as the record address of block 1 without limitation.

[0153] It should be noted that, in one example, the second node may send the AuxI corresponding to the identity information of each terminal to the BSS, that is, the AuxI sent may be for each terminal. In another example, corresponding to step 503, when the BSS organizes the identity information of the terminal itself to generate a hash tree, the second node may send the hash root corresponding to the hash tree generated by the BSS to the BSS. The BSS may generate the AuxI corresponding to the identity information of each terminal based on the hash tree organized by itself, and send it to each terminal accordingly. At this time, the AuxI is for each BSS, with the BSS as the granularity.

[0154] Step 505: The second node synchronizes the block header of block 1 to the first node.

[0155] For example, the second node can synchronize the characteristic information in the block header of block 1 to the first node, that is, the summary information in the block header of block 1. It should be noted that if there is no CRL in this block 1, the synchronization process of this block 1 is completed. Otherwise, Figure 4In the method shown, steps 403-407 are used to synchronize the current block 1. After the first node receives the synchronization information, it first checks the chain rule to confirm the validity and type of block 1 (whether it is a block storing a CRL). If block 1 is not a block storing a CRL and block 1 cannot be chained with the previous block, it means that block 1 is an invalid block and a new synchronization source is sought. If block 1 is a block storing a CRL, the CRL in block 1 is requested.

[0156] It should be noted that this application does not limit the execution steps of step 504 and step 505. Figure 5 As shown, step 504 is performed first and then step 505. Alternatively, step 505 may be performed first and then step 504, or both step 504 and step 505 may be performed simultaneously, without limitation.

[0157] The above steps 501 to 506 are a process of registering the identity information of the terminal. Furthermore, the registered identity information can also be revoked. The process is shown in the following steps 506 to 512.

[0158] Step 506: The terminal and the BSS negotiate to revoke the identity information. If the negotiation is successful, step 507 is executed. If the negotiation fails, the process ends.

[0159] In one example, the revocation of identity information is initiated by a terminal. For example, the negotiation between the terminal and the BSS regarding the revocation of identity information may include: the terminal determines that its own identity information (or credential information) has been leaked, and needs to revoke its own identity information. The terminal sends a third request to the BSS, the third request carrying identity information (such as an identity ID). The third request is used to request the revocation of the identity information, which may be identity information previously registered in the blockchain. The BSS receives the third request sent by the terminal, performs authorization verification on the terminal, and determines whether the terminal is allowed to revoke the identity information. If the terminal is allowed to revoke the identity information, the negotiation is successful. Conversely, if the terminal is not allowed to revoke the identity information, the negotiation fails.

[0160] In another example, the request for revocation of identity information is initiated by the BSS. For example, the negotiation between the terminal and the BSS on the revocation of identity information may include: the BSS discovers that a terminal in its domain has violated regulations or has other qualification problems, and the BSS sends a third request to the terminal. The third request carries identity information (such as identity ID). The third request is used to request the revocation of the identity information of the terminal. The identity information of the terminal may be the identity information previously registered in the blockchain. After the terminal receives the third request sent by the BSS, if it agrees to revoke its own identity information, it sends a response message to the BSS, and the negotiation is successful. On the contrary, if the terminal finds that the BSS's revocation is unreasonable and does not agree to revoke its own identity information, it sends a rejection message to the BSS, and the negotiation fails.

[0161] Step 507: The BSS initiates a revocation authorization request to the CRL server.

[0162] Among them, the revocation authorization application may include all identity information authorized by the BSS that needs to be revoked this time, and may also include other information, such as authorization information such as the revocation authorization certificate. The revocation authorization certificate may include arbitrable certificates such as the operator's signature / BSS's signature.

[0163] Step 508: The CRL server receives the revocation application, confirms whether the revocation application is valid, and generates a CRL if the revocation application is valid.

[0164] Illustratively, the CRL server may determine whether the revocation authorization application is valid based on the signature in the revocation authorization information, the validity of the signature, and whether the signing subject has the authority to revoke the identity registration.

[0165] Among them, the CRL can be a full list or a differential list, which is not described in detail.

[0166] Step 509: The CRL server sends the CRL to the second node, that is, the CRL is shared with the second node.

[0167] It should be noted that in this application, when the CRL reaches consensus in the blockchain, the CRL removes the revocation authorization certificate and other information included in the revocation authorization application in step 507, retaining only the key identifier of the revoked identity information, and the CRL server locally retains the revocation authorization certificate for future arbitration. Since the CRL server is associated with a distributed deployment of all nodes, at each consensus, the CRL of this block organizes the identity information that needs to be revoked collected by all CRL servers to generate the CRL. It should be noted that the revoked identity information does not need to be organized in a hash tree.

[0168] Step 510: The second node receives the CRL from the CRL server, stores the CRL in block 2, completes the CRL consensus, and sends a revocation feedback result to the CRL server, BSS, and terminal.

[0169] The revocation feedback result may be used to indicate that the revoked identity information is successfully recorded in the block, indicating that the revocation is successful.

[0170] Among them, the second node storing the CRL in block 2 may include: the second node storing the CRL in the block body of block 2, and implementing the chaining rule of block 2 in combination with the CRL identifier, such as setting the characteristic information included in the block header of block 2 in combination with the CRL identifier, so that the hash value calculated by using the characteristic information included in the block header of block 2 and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of block 2.

[0171] Step 511: The second node synchronizes the block header of block 2 to the first node.

[0172] Among them, the process of synchronizing the block header of block 2 from the second node to the first node can refer to the process of synchronizing the block header of block 1 from the second node to the first node, which is not repeated here.

[0173] Step 512: The first node receives the block header of block 2. If the chain rule detects that block 2 is a block that stores a CRL, the first node obtains the CRL from the second node and stores the obtained CRL in block 2, completing the synchronization of block 2. Furthermore, if the obtained CRL is a full list, the CRL stored in the block body of the previous historical block is cleared, that is, the block body of the historical block is deleted, and only the block header of the historical block is retained.

[0174] Among them, the process of the first node detecting that block 2 is a block storing a CRL through the chain rule can refer to the description of steps 405-406, such as the first node first using the characteristic information included in the block header of block 2 as a hash input parameter to obtain a hash value and comparing it with the hash value of the previous block. If they are different, the first node then uses the characteristic information and the CRL identifier included in the block header of block 2 as hash input parameters to obtain a hash value. If the obtained hash value is the same as the hash value of the previous block, it is determined that block 2 is a block storing a CRL.

[0175] It should be noted that for light nodes newly added to the blockchain system or those that have been offline for a long time, such as the first node, there is a possibility that they will synchronize multiple blocks at once after going online. On the newly synchronized blockchain, multiple blocks will have CRL identifiers, and some of these blocks with CRL identifiers may not contain specific identity revocation records at the time of synchronization. In this case, the first node needs to determine whether these blocks intentionally conceal the necessary identity revocation records and whether subsequent blocks in the blockchain have the full set of CRLs. If so, the synchronized information is valid.

[0176] based on Figure 5In the method shown, this embodiment sets a CRL identifier that influences blockchain chain structure verification, enabling the blockchain to structurally identify whether a target block contains a CRL. This allows light nodes to record identity revocation records in a streamlined manner while maintaining their record-only nature of block headers. Therefore, this embodiment supports the global deployment of endorsement nodes in distributed networks such as the IoT. In blockchain-based identity management, the implementation of support for light nodes significantly reduces the authentication and dynamic latency and communication burden associated with identity revocation. Furthermore, the identity revocation information recorded on the blockchain does not include the identity revocation authorization, retaining only the identifier of the revoked identity, which is storage-friendly for light nodes. Furthermore, the CRL server locally stores authorization information. If a UE discovers its identity has been revoked during identity authentication and believes that a CRL server has recorded its identity revocation without authorization, it can file an appeal. While this process may result in a functional loss for honest UEs, given that the CRL server is a carrier-level blockchain module, the risk of arbitration and accountability is outweighed. Therefore, it provides sufficient protection to ensure the authorization of each identity revocation record.

[0177] above Figure 4 or Figure 5 In the manner shown, the CRL identifier is involved in the chain structure verification between the block carrying the CRL and the previous block, and the CRL identifier is used to verify whether the current block carries the CRL. The light node synchronizes the CRL as an example to describe the identity information management method based on blockchain provided by the embodiment of the present application. Alternatively, the embodiment of the present application also provides an identity information management method based on blockchain: when the identity information in a block is updated (such as revoked), the updated identity information is stored in a new block, and the new block and the updated block are not in the same fork, such as the updated block is on the main link, and the updated block (ie, the new block) is on the forked link, that is, there are two new and old versions of the block in the blockchain system, and the light node is aware of the change in the block through the change in the blockchain topology. Specifically, this process can refer to Figure 6 shown.

[0178] Figure 6 A flowchart of another blockchain-based identity information management method provided in an embodiment of the present application is as follows: Figure 6 As shown, the method may include:

[0179] Step 601: The second node determines to update (eg, revoke) the identity information stored in the first block.

[0180] The first block may be any block on the first blockchain, and multiple identity information is registered in the first block. The first block may include a block header and a block body. As described above, the block header may include one or more feature information, and the block body may include multiple identity information organized in the form of a hash tree.

[0181] Exemplarily, the second node may receive a fourth request from the BSS, where the fourth request may be used to request the revocation / update of the identity information of the terminal. The fourth request may include the address information of the first block and the identity information revocation record of the terminal. The address information of the first block may be fed back to the terminal by the second node through the BSS after the identity information of the terminal is successfully registered with / stored in the first block.

[0182] Step 602: The second node generates a third block based on the first block and the second block.

[0183] The second block may be the latest block on the first blockchain. For example, the second block may be a block being generated on the first blockchain or a block that has just been generated. At this time, the next block of the second block has not yet started to be generated.

[0184] Among them, the third block satisfies the chain structure with the first block and the second block, and the hash value calculated by the hash input parameter of the block header of the third block is the same as the hash value obtained by taking the characteristic information of the block header of the first block and the characteristic information of the block header of the second block as the hash input parameter. At the same time, the second node updates all identity information in the first block, such as updating the identity information that is determined to be updated, retaining the identity information that is not determined to be updated unchanged, and storing the updated identity information in the block body of the third block. If it is determined to revoke the identity information in the first block, the identity information that is determined to be revoked is deleted, the identity information that is not revoked is retained, and all identity information that is not revoked in the first block is stored in the block body of the third block.

[0185] From the above, it can be seen that the first block and the second block can serve as the parent block / predecessor block of the third block, that is, the third block has two predecessor blocks, the first block and the second block. The first block can be the source block of the third block. The first block can store the identity information before the update, and the third block can store the identity information after the update. The second block can serve as the timing block of the third block and generate the third block within the update cycle of the second block.

[0186] Step 603: The second node does not directly use the third block as a subsequent block on the first blockchain, but instead records the third block on the forked link of the first blockchain.

[0187] Furthermore, the second node may configure a label for the first block, which may be used to identify that the first block is forked in the chain structure or that the identity information stored in the first block is invalid, and that there is a new block corresponding to the first block, which stores the updated identity information in the first block.

[0188] Further optionally, the second node synchronizes the block header of the third block to the first node.

[0189] In this way, the updated block (such as the third block) corresponding to the first block can be recorded on the forked link of the blockchain where the first block is located. Later, when the identity authentication node verifies whether the identity information of a terminal is valid, it can be known through the chain structure of the forked record that the content of the first block has been updated, the first block is an invalid block, and the identity authentication cannot be performed through the first block. Then, the third block corresponding to the first block is found and the identity information of the terminal is verified through the third block. Specifically, the process of identity authentication node verifying identity information can refer to the following Figure 9 shown.

[0190] Further optionally, in order to avoid lazy or malicious nodes deliberately hiding the updated block (such as the third block) and not synchronizing the updated block to other nodes, resulting in other nodes being unable to perceive that the identity information has been updated, the second node can also use the updated block and the predecessor block of the fourth block on the first blockchain as the predecessor block / parent block of the fourth block when generating the next block on the first blockchain, such as the fourth block, so that the third block and the predecessor block of the fourth block satisfy a chain structure, such as the hash value calculated by taking the characteristic information of the block header of the third block and the characteristic information of the block header of the predecessor block of the fourth block as hash input parameters is the same as the hash value obtained by taking the characteristic information in the block header of the fourth block as the hash input parameter.

[0191] In this way, a chain relationship can be established between the third block and the next newly generated block on the first blockchain, so that when other nodes, such as the first node, synchronize the next newly generated block on the first blockchain (such as the fourth block), they can perceive the existence of the third block through the chain relationship and check whether the third block has been synchronized from the second node. If not, they obtain the third block from the second node and synchronize the third block to the first node to avoid missing the third block and the updated identity information.

[0192] The fourth block may be the first block in the update cycle next to the update cycle of the second block, and the preceding block of the fourth block may be the last block in the update cycle of the second block.

[0193] For example, Figure 7 Identity information and block update mechanism perceived by light nodes, such as Figure 7 As shown, the blockchain is divided into multiple update cycles. Each update cycle consists of several consensus-validated blocks that form a blockchain in chronological order. When the identity information in a block (which can be one or more identity information) is revoked, let this block be denoted as Bx. Block Bx can be from the current update cycle or a different update cycle. Assume that the latest block is Bt. With Bx and Bt as predecessor blocks, the updated block Updated Bx is formed as the subsequent block. That is, Updated Bx has two predecessor blocks. Of these two blocks, Bx represents the updated block. The content of Updated Bx is based on the changes to the content of Bx. Bt is a timing block that only indicates the update time of Updated Bx. The content of Updated Bx has no logical relationship with the content of block Bt. The updated block Updated Bx is not directly used as a subsequent node on the main chain, but as a fork. If the identity of the updated block Updated Bx is further revoked, the latest version will be directly connected from the fork, and the latest block on the main chain at that time will be bound as the timing block, and Bx will be used as the source block of the updated block on the fork.

[0194] Further, such as Figure 7 As shown, at the end of the current update cycle, let the last block of that update cycle be Bp. The existence of the updated block Updated Bx generated during this update cycle must be reflected in the block Bq of the next update cycle to ensure non-repudiation of the block update. Specifically, the last block of all updated blocks on the forked chain during this update cycle, along with Bp, serves as the predecessor of Bq, forming a chain rule. Ignoring any of these updated blocks will prevent Bq from being verified. This means that when verifying the chain structure between Bq and the predecessor block on the main chain where Bq resides, the last updated block on the fork must be included; otherwise, the chain structure verification will fail.

[0195] based on Figure 7 The method shown, without compromising the blockchain's main chain, stores updated information in a block in a new block and stores the updated block on a fork connected to the main chain. This forked topology allows for the perception of updates to the content in a block. Simultaneously, a chain structure is formed between the updated block on the fork and the block of the next update cycle. After the update cycle ends, the perception of the updated block is mandatory; otherwise, the next block cannot be passed. This prevents lazy or malicious light nodes from hiding the updated block (i.e., the updated content), and prevents them from maintaining old versions of the updated block for long periods of time while concealing the fact that the relevant identity information has been updated.

[0196] In the following example, the first block is block 1, and the terminal's identity information is first registered to block 1, and then the terminal's identity information is revoked. Figure 6 The method shown is described in detail. Figure 8 A flowchart of a blockchain-based identity information management method provided in an embodiment of the present application is as follows: Figure 8 As shown, the method may include:

[0197] Figure 8 A flowchart of another blockchain-based identity information management method provided in an embodiment of the present application is as follows: Figure 8 As shown, the method may include:

[0198] Step 801: The terminal and the BSS negotiate the registration of identity information. If the negotiation is successful, step 802 is executed.

[0199] Among them, step 801 can refer to step 501 and will not be described in detail.

[0200] Step 802: The BSS sends a second request to the second node.

[0201] Among them, step 802 can refer to step 502 and will not be described in detail.

[0202] Step 803: The second node receives the second request from the BSS, and stores (or registers / saves) the identity information carried in the second request in block 1.

[0203] Among them, step 803 can refer to step 503 and will not be described in detail.

[0204] Step 804: The second node sends the address information of block 1 and the AuxI corresponding to each identity information in block 1 to the BSS.

[0205] Among them, step 804 can refer to step 504 and is not described in detail.

[0206] Furthermore, the BSS sends the address information of block 1 and the AuxI corresponding to each identity information in block 1 to the terminal.

[0207] Step 805: The second node synchronizes the block header of block 1 to the first node.

[0208] Among them, step 805 can refer to step 505 and will not be described in detail.

[0209] It should be noted that this application does not limit the execution steps of step 804 and step 805. Figure 5As shown, step 804 is performed first and then step 805. Alternatively, step 805 may be performed first and then step 804, or both step 804 and step 805 may be performed simultaneously, without limitation.

[0210] Step 806: The terminal and the BSS negotiate to revoke the identity information. If the negotiation is successful, step 807 is executed. If the negotiation fails, the process ends.

[0211] Among them, step 806 can refer to step 506 and is not described in detail.

[0212] Step 807: The BSS sends a fourth request to the second node.

[0213] The fourth request may be used to request the revocation / update of the terminal's identity information. The fourth request may include the address information of block 1, the terminal's identity information (such as an identity ID or user identity certificate), AuxI, and a revocation flag, etc. The revocation flag is used to indicate the revocation of the terminal's identity information. The address information of block 1 may be fed back to the terminal by the second node through the BSS after the terminal's identity information is successfully registered / stored in block 1 in step 804.

[0214] It should be noted that the second node may carry identity information of one or more terminals that need to be revoked, and the BSS may send one or more fourth requests to the second node without limitation.

[0215] Step 808: The second node receives the fourth request and determines to update the identity information in block 1 according to the fourth request.

[0216] Exemplarily, the second node finds block 1 based on the address information of block 1 carried by the fourth request, and verifies the validity of the identity information carried by the fourth request, such as calculating the hash root based on the identity information and AuxI. If the calculated hash root is the same as the hash root of the hash tree including the identity information in block 1, the identity information verification passes, and after the identity information is valid, it is determined to update (such as revoking block 1) the identity information.

[0217] It should be noted that the blockchain may accept multiple requests for revoking identity information within a unified consensus. Multiple revoked identity information may correspond to one or different historical blocks. If they correspond to different historical blocks, subsequent steps 809 to 813 are processed separately for each history. If they correspond to the same historical block, steps 809 to 813 are executed once to update the content in the historical block, and the updated content is stored in the new block on the fork.

[0218] Step 809: The second node updates the identity information in block 1, forms a new hash tree with the updated identity information, and stores the new hash tree in block 2, where block 2 corresponds to two previous blocks: block 1 and the latest block on the main link like block 1 in the current update cycle.

[0219] Among them, block 2 can be called the update block, and block 1 can be called the block to be updated. In the block body of block 2, while retaining the tree structure of the hash tree of the block to be updated (block 1), the revoked identity information on the hash tree in block 1 is deleted, and the hash value of the corresponding node in the hash tree is changed according to the output of the hash, including the hash root of the entire hash tree and AuxI, and the updated hash tree is stored in the block body of block 2. At this time, the updated hash tree retains the identity information that has not been revoked in block 1, and the AuxI corresponding to the unrevoked identity information has been updated. For example, if the following information is stored in block 1: Figure 1b As shown in the hash tree, there are the ID of user 1, user 2, user 3 and user 4 on the hash tree. At this time, if the ID of user 1 is revoked, the second node needs to update the hash tree, delete the ID of user 1 on the hash tree, retain the ID of user 2, user 3 and user 4, and update AuxI and the hash root of the hash tree.

[0220] Among them, the hash value obtained by calculating the characteristic parameters included in the block header of block 2 as hash input parameters is the same as the hash value obtained by calculating the characteristic parameters included in the block header of block 1 and the characteristic information included in the block header of the latest block in the current update cycle as hash input parameters, that is, the characteristic parameters included in the block header of block 1 are composed of a first string, the characteristic information included in the block header of the latest block in the current update cycle is composed of a second string, the first string and the second string are input as hash input parameters to the hash algorithm to obtain a hash value 1, and the characteristic parameters included in the block header of block 2 are input as hash input parameters to the hash algorithm to obtain a hash value 2, and the hash value 1 is the same as the hash value 2.

[0221] It should be noted that, as described in this application, inputting the characteristic parameters included in the block header as hash input parameters into the hash algorithm to obtain a hash value may refer to: inputting other characteristic information included in the block header except the hash value of the previous block as hash input parameters into the hash algorithm to obtain a hash value.

[0222] Step 810: The second node sends an auxiliary information change notification to BSS.re.

[0223] The BSS.re may be the BSS.re associated with the terminal whose identity information has been revoked, and the BSS.re manages the terminal whose identity information has been revoked. In this application, the terminal whose identity information has been revoked may be referred to as terminal.re.

[0224] Among them, the auxiliary information change notification can be used to trigger BSS.re to send the updated AuxI to the terminal whose identity information has not been revoked. The auxiliary information change notification may include the revoked identity information and the updated AuxI, or, when the hash tree is organized by BSS.re, the auxiliary information change notification may include the revoked identity information under the management of the BSS.re.

[0225] Step 811: BSS.re receives the auxiliary information change notification and sends the updated AuxI to terminal.re.

[0226] Exemplarily, if the auxiliary information change notification received by the BSS.re includes an updated AuxI, the updated AuxI is directly sent to the terminal.re. If the auxiliary information change notification received by the BSS.re includes revoked identity information under the management of the BSS.re, the BSS.re deletes the revoked identity information from the hash tree, modifies the AuxI in the hash tree according to the hash output, and sends the updated AuxI to the terminal.re.

[0227] Step 812: The second node synchronizes the block header of block 2 to the first node.

[0228] The process of synchronizing the block header of block 2 from the second node to the first node can be referred to the process of synchronizing the block header of block 1 from the second node to the first node, and will not be described in detail. It should be noted that the first node can act as a relay to synchronize the new block 2 to other light nodes, such as the third node.

[0229] In this step, when the first node synchronizes the block header of block 2, it verifies the chain structure relationship between block 2, block 1 and the latest block in the current update cycle, and can know that block 2 has two predecessor blocks and is located on a fork structure. It can know which historical block (such as block 1) the block 2 is updated from. In the subsequent verification, the first node can perceive that the content of the corresponding historical block (block 1) has been changed, and needs to verify the validity of the identity information through the updated version of the block (such as block 2). Specifically, the process can refer to the following Figure 9 Furthermore, the first node can mark the synchronized block 2 as an updated version of block 1.

[0230] Step 813: After the current update cycle ends, the second node generates the first block of the next update cycle: block 3. The second node sets the characteristic information in the block header of block 3 based on block 2 and the last block in the current update cycle, so that block 2 and the last block in the current update cycle serve as the predecessor blocks of block 3.

[0231] Exemplarily, the hash value obtained by calculating the characteristic parameters included in the block header of block 3 as hash input parameters is the same as the hash value obtained by calculating the characteristic parameters included in the block header of block 2 and the characteristic information included in the block header of the last block in the current update cycle as hash input parameters, that is, the characteristic parameters included in the block header of block 2 are composed of a first string, and the characteristic information included in the block header of the last block in the current update cycle is composed of a second string. The first string and the second string are input as hash input parameters into the hash algorithm to obtain a hash value 3, and the characteristic parameters included in the block header of block 3 are input as hash input parameters into the hash algorithm to obtain a hash value 4. The values ​​of hash value 3 and hash value 4 are the same.

[0232] This way, when the blockchain reaches consensus, all updated blocks since the current update cycle, including the latest block since the current update cycle, can be used as the predecessor blocks of the new main chain block, ensuring the historical non-repudiation of block changes during the current update cycle. After this step, light nodes cannot complete a valid blockchain extension without ignoring the reality of block updates.

[0233] based on Figure 8 The method shown, without destroying the main chain characteristics of the blockchain, stores the updated information in block 1 in a new block 2, and stores the updated block 2 on a fork connected to the main chain. This forked topology allows the perception of updates to the content in block 1. At the same time, a chain structure is formed between the updated block 2 on the fork and the block 3 of the next update cycle. After the update cycle ends, the perception of the updated block 2 is mandatory; otherwise, the next block 3 cannot be passed, making it impossible for lazy or malicious light nodes to hide the updated block 2.

[0234] The following combination Figure 9 The process shown takes the first node as an authentication node for verifying whether the identity information is valid / whether it has been changed as an example to describe the authentication process. Figure 9 An authentication flow chart provided in an embodiment of the present application is as follows: Figure 9 As shown, the above may include:

[0235] Step 901: The identity holder sends a fifth request to the identity authentication node through the terminal used by the identity holder.

[0236] The identity authentication node may be the first node or other nodes without limitation.

[0237] The fifth request may request the authentication node to verify whether the terminal's identity information has been revoked or updated. The fifth request may include authentication information, which may include the identity information to be verified / pending, the address of the first block where the identity information is registered / stored, and the AuxI. If the terminal previously obtained an updated AuxI provided by the BSS.re, the fifth request will be for the updated AuxI.

[0238] Step 902: The identity authentication node receives the fifth request and verifies the validity of the identity information carried in the fifth request. If the identity information is valid, the following steps 903 to 906 are executed.

[0239] For example, identity information is a verification public key. The identity holder can use signature and authentication methods to have the authentication node verify the validity of the identity. Generally speaking, the verifier must confirm the following two points during this process: the other party is the holder of a certain identity and the identity is registered on the blockchain.

[0240] Step 903: The identity authentication node sends the address information of the first block where the identity information is registered / stored and AuxI to the first node according to the fifth request.

[0241] It should be noted that the identity authentication node itself can serve as a blockchain light node, such as the first node. If so, the subsequent steps 904 to 906 are all internal execution processes of the identity authentication node.

[0242] Step 904: The first node receives the address information and AuxI of the first block where the identity information is registered / stored, and queries the first block where the identity information is registered / stored based on the address information of the first block. If it is found that there is an updated version of the first block, such as the third block, step 905 is executed.

[0243] Exemplarily, the first node can find the first block based on the address information of the first block. If it is determined that the first block has forked in the structure to obtain a new first block: the third block, indicating that the first block contains a revoked identity, the latest version of the first block: the third block is then queried based on the fork. Specifically, it can be verified whether the chain structure is satisfied between the first block on the fork, the latest first block that is simultaneously agreed upon with the first block on the fork, and the first block. For example, characteristic information included in the first block header of the latest first block that is simultaneously agreed upon with the first block on the fork and characteristic information included in the first block header of the first block are used as hash input parameters to calculate a hash value. The characteristic information included in the first block header of the first block on the fork is used as a hash input parameter to calculate another hash value. If the two hash values ​​are the same, then the chain structure between the three first blocks is satisfied, and the first block on the fork is used as the latest version of the first block.

[0244] Step 905: The first node returns the first block header of the third block to the authentication node.

[0245] Step 906: The authentication node calculates the first hash root based on AuxI. If the first hash root is the same as the hash root in the first block header of the third block in step 905, the identity information verification is successful. Otherwise, the identity information verification fails and the identity information may be revoked.

[0246] based on Figure 9 The method shown can verify the identity information of a terminal by finding an updated version of the historical block of the revoked identity information based on a forked chain structure, and verify whether the identity information is revoked based on the updated version.

[0247] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of method. In order to realize the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner 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 to be beyond the scope of this application.

[0248] In the embodiment of the present application, the node can be divided into functional modules according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or software functional modules. Optionally, the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0249] Figure 10 The block diagram shows a block chain node 100. The block chain node 100 can be a first node, a chip in the first node, a system on a chip, or other devices capable of implementing the functions of the first node in the above method. The block chain node 100 can be used to perform the functions of the first node involved in the above method embodiment. As an implementation method, Figure 10 The blockchain node 100 shown includes: a receiving unit 1001 and a processing unit 1002.

[0250] The receiving unit 1001 is configured to obtain a block header of a first block to be synchronized from the first node. For example, the receiving unit 1001 may support the blockchain node 100 in executing steps 404 and 512.

[0251] Processing unit 1002 is configured to verify, based on characteristic information included in a block header of the first block, whether a chain structure is satisfied between the first block and a preceding block of the first block; if the chain structure is not satisfied between the first block and the preceding block of the first block, then the first node verifies, based on the characteristic information included in the block header of the first block and a certificate revocation list (CRL) identifier, whether a chain structure is satisfied between the first block and the preceding block of the first block; if so, determining that the first block carries the CRL. For example, processing unit 1002 supports blockchain node 100 in executing steps 406 and 512.

[0252] The receiving unit 1001 is further configured for the first node to obtain the CRL from the second node. For example, the receiving unit 1001 may support the blockchain node 100 to perform step 407.

[0253] Specifically, the above Figure 4-Figure 5 All relevant contents of each step involved in the method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here. Figure 4-Figure 5 The function of the first node in the blockchain-based identity information management method shown can therefore achieve the same effect as the above-mentioned blockchain-based identity information management method.

[0254] In another possible implementation, receiving unit 1001 is configured to obtain identity authentication information, where the identity authentication information includes the identity information to be verified, the address information of the first block in which the identity information is registered, and auxiliary verification information AuxI corresponding to the identity information. For example, receiving unit 1001 is configured to support blockchain node 100 in executing step 904.

[0255] Processing unit 1002 is configured to determine the first block based on the address information of the first block. If the first block is forked, determine a third block based on the first block and the second block, where the second block is the latest block in the current update cycle, the first block and the second block are predecessors of the third block, and the third block stores the updated identity information in the first block. The third block is an updated block corresponding to the first block and located on the forked link. For example, processing unit 1002 is configured to support blockchain node 100 in executing step 904.

[0256] The processing unit 1002 is further configured to verify the identity information based on the identity information to be verified, the AuxI corresponding to the identity information, and the third block. For example, the processing unit 1002 is configured to support the blockchain node 100 in executing step 906.

[0257] Specifically, the above Figure 9 All relevant contents of each step involved in the method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here. Figure 9 The function of the first node in the authentication method can thus achieve the same effect as in the above authentication method.

[0258] As another possible implementation method, Figure 10 The blockchain node 100 shown includes: a processing module and a communication module. The processing module is used to control and manage the actions of the blockchain node 100. For example, the processing module can integrate the functions of the processing unit 1002 and can be used to support the blockchain node 100 in executing steps 406, 512, and 906 and other processes of the technology described herein. The communication module can integrate the functions of the receiving unit 1001 and can be used to support the blockchain node 100 in executing steps 404, 512, and 904 and communicating with other network entities, such as Figure 2 The blockchain node 100 may further include a storage module for storing instructions and / or data. When the instructions are executed by the processing module, the processing module implements the method on the first node side described above.

[0259] The processing module may be a processor, a controller, a module or a circuit. It may implement or execute various exemplary logic blocks described in conjunction with the disclosure of this application. The communication module may be a transceiver circuit, a pin, an interface circuit, a bus interface, or a communication interface. The storage module may be a memory. When the processing module is a processor, the communication module is a communication interface, and the storage module is a memory, the blockchain node 100 involved in the embodiment of the present application may be Figure 3 The device shown.

[0260] Figure 11 The block diagram shows a block chain node 110, which can be a second node, a chip in the second node, a system on a chip, or other devices capable of implementing the functions of the second node in the above method. The block chain node 110 can be used to perform the functions of the second node involved in the above method embodiment. As an implementation method, Figure 11 The blockchain node 110 shown includes: a receiving unit 1101 and a processing unit 1102.

[0261] The receiving unit 1101 is configured to obtain a certificate revocation list (CRL). For example, the receiving unit 1101 supports the blockchain node in executing steps 401 and 510.

[0262] Processing unit 1102 is configured to generate a first block based on the obtained CRL, wherein the CRL is stored in a block body of the first block, and a hash value calculated using characteristic information included in a block header of the first block and the CRL identifier as hash input parameters is the same as a hash value of a preceding block of the first block. For example, processing unit 1102 supports a blockchain node in executing steps 402 and 510.

[0263] Specifically, the above Figure 4-Figure 5 All relevant contents of each step involved in the embodiment of the method shown can be referred to the functional description of the corresponding functional module, and will not be repeated here. Figure 4-Figure 5 The function of the second node in the blockchain-based identity information management method shown can therefore achieve the same effect as the above-mentioned blockchain-based identity information management method.

[0264] In another possible design, the processing unit 1102 is configured to determine whether to update the identity information stored in the first block, and to generate a third block based on the first block and the second block, where the second block is the latest block in a current update cycle, the first block and the second block are predecessor blocks of the third block, the third block stores the updated identity information in the first block, and the third block is an updated block corresponding to the first block.

[0265] The processing unit 1102 is further configured to store the third block on a fork of the main chain where the first block is located. For example, the processing unit 1102 supports the blockchain node to execute steps 601 to 603, step 808, and step 809.

[0266] Specifically, the above Figure 6 or Figure 8 All relevant contents of each step involved in the embodiment of the method shown can be referred to the functional description of the corresponding functional module, and will not be repeated here. Figure 6 or Figure 8 The function of the second node in the blockchain-based identity information management method shown can therefore achieve the same effect as the above-mentioned blockchain-based identity information management method.

[0267] As another possible implementation method, Figure 11 The blockchain node 110 shown includes: a processing module and a communication module. The processing module is used to control and manage the actions of the blockchain node 110. For example, the processing module can integrate the functions of the processing unit and can be used to support the blockchain node 110 to perform steps 601 to 603, steps 808 and 809 and the actions of the second node described herein except for the sending and receiving actions. The communication module can integrate the functions of the receiving unit 1101 and can be used to support the blockchain node 110 to perform steps 401 and 510 and communicate with other network entities, such as Figure 2 The blockchain node 110 may further include a storage module for storing instructions and / or data of the blockchain node 110. When the instructions are executed by the processing module, the processing module may implement the above-mentioned second node-side method.

[0268] Among them, the processing module can be a processor, a controller, a module or a circuit. It can implement or execute various exemplary logic blocks described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of DSP and microprocessors, etc. The communication module can be a transceiver circuit, a pin, an interface circuit, a bus interface, or a communication interface. The storage module can be a memory. When the processing module is a processor, the communication module is a communication interface, and the storage module is a memory, the blockchain node 110 involved in the embodiment of the present application can be Figure 3 The device shown.

[0269] In the embodiments of the present application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0270] In an embodiment of the present application, the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or a volatile memory (volatile memory), such as a random-access memory (RAM). The memory is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory in an embodiment of the present application may also be a circuit or any other device that can implement a storage function, for storing instructions and / or data.

[0271] Figure 12 A structural diagram of a blockchain system provided in an embodiment of the present application is shown in FIG. Figure 12 As shown, the blockchain system may include: a first node 120 and a second node 121. The first node 120 may have the functions of the blockchain node 100 described above. The second node 121 may have the functions of the blockchain node 110 described above.

[0272] In one example, the first node 120 obtains the block header of the first block to be synchronized from the second node 121;

[0273] The first node 120 verifies whether the first block and the preceding block of the first block satisfy a chain structure based on the characteristic information included in the block header of the first block;

[0274] If the first block and its predecessor block do not satisfy the chain structure, the first node 120 verifies whether the first block and its predecessor block satisfy the chain structure based on the characteristic information included in the block header of the first block and the certificate revocation list (CRL) identifier. If so, it is determined that the first block carries the CRL.

[0275] The first node 120 obtains the CRL from the second node 121 .

[0276] In another example, the first node 120 obtains identity authentication information, which includes identity information to be verified, address information of a first block where the identity information is registered, and verification auxiliary information AuxI corresponding to the identity information;

[0277] The first node 120 determines the first block based on the address information of the first block. If the first block is forked, the third block is determined based on the first block and the second block. The second block is the latest block in the current update cycle. The first block and the second block are the predecessor blocks of the third block. The third block stores the updated identity information in the first block. The third block is an updated block corresponding to the first block and is located on the forked link.

[0278] The first node 120 verifies the identity information according to the identity information to be verified, the AuxI corresponding to the identity information, and the third block.

[0279] Specifically, the specific implementation process of the first node 120 and the second node 121 can refer to the above Figure 4-Figure 9 The execution process of the first node and the second node in the method embodiment will not be described in detail here.

[0280] The embodiments of the present application also provide a computer-readable storage medium. All or part of the processes in the above-mentioned method embodiments can be completed by a computer program to instruct the relevant hardware, and the program can be stored in the above-mentioned computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments. The computer-readable storage medium can be a terminal device of any of the above-mentioned embodiments, such as: an internal storage unit including a data sending end and / or a data receiving end, such as a hard disk or memory of the terminal device. The above-mentioned computer-readable storage medium can also be an external storage device of the above-mentioned terminal device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. equipped on the above-mentioned terminal device. Furthermore, the above-mentioned computer-readable storage medium can also include both the internal storage unit of the above-mentioned terminal device and an external storage device. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program and other programs and data required by the above-mentioned terminal device. The above-mentioned computer-readable storage medium can also be used to temporarily store data that has been output or is to be output.

[0281] The present application also provides a computer instruction. All or part of the process in the above method embodiment can be completed by the computer instruction to instruct the relevant hardware (such as a computer, processor, network device, and terminal, etc.). The program can be stored in the above computer-readable storage medium.

[0282] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0283] Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, blockchain node, or data center to another website, computer, blockchain node, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that can be accessed by a computer, or a data terminal such as a blockchain node or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0284] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0285] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or 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 device, 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.

[0286] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0287] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0288] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially 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, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0289] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A blockchain-based identity information management method, characterized in that: The method comprises: The first node obtains the block header of the first block to be synchronized from the second node; The first node verifies, based on characteristic information included in the block header of the first block, whether the first block and a preceding block of the first block satisfy a chain structure; If the first block and the preceding block of the first block do not satisfy a chain structure, the first node verifies whether a hash value calculated using the characteristic information included in the block header of the first block and the certificate revocation list (CRL) identifier as hash input parameters is the same as the hash value of the preceding block of the first block, and verifies whether the first block and the preceding block of the first block satisfy a chain structure. If so, it is determined that the first block carries the CRL. The first node obtains the CRL from the second node.

2. The method according to claim 1, characterized in that Verifying, by the first node, whether a chain structure is satisfied between the first block and a preceding block of the first block according to characteristic information included in the block header of the first block includes: The first node determines whether a hash value calculated by using the characteristic information included in the block header of the first block as a hash input parameter is the same as a hash value of a preceding block of the first block; If they are the same, then the first block and the preceding block of the first block satisfy a chain structure; If they are different, the first block and the preceding block of the first block do not satisfy the chain structure.

3. The method according to claim 1 or 2, characterized in that The first node verifies whether a hash value calculated by using characteristic information included in a block header of the first block and a certificate revocation list (CRL) identifier as hash input parameters is the same as a hash value of a preceding block of the first block, and verifies whether the first block and the preceding block of the first block satisfy a chain structure, including: If they are the same, then the first block and the preceding block of the first block satisfy a chain structure; If they are different, the first block and the preceding block of the first block do not satisfy the chain structure.

4. The method according to claim 1 or 2, characterized in that The CRL is a full list or a differential list.

5. A blockchain-based identity information management method, characterized in that: The method comprises: The second node obtains the certificate revocation list CRL; The second node generates a first block based on the obtained CRL, the CRL is stored in the block body of the first block, and a hash value calculated by using the characteristic information included in the block header of the first block and the CRL identifier as hash input parameters is the same as the hash value of the preceding block of the first block.

6. The method according to claim 5, characterized in that The second node acquiring the CRL includes: The second node receives a CRL from a CRL server, where the CRL server stores authorization information corresponding to the CRL.

7. The method according to claim 5 or 6, characterized in that The CRL is a full list or a differential list.

8. A blockchain system, characterized in that: The blockchain system includes the first node according to any one of claims 1 to 4 and the second node according to any one of claims 5 to 7.

9. A blockchain node, characterized in that: include: One or more processors, and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories store computer instructions; when the one or more processors execute the computer instructions, the computer instructions implement the blockchain-based identity information management method according to any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that The method comprises instructions, which, when executed on a computer, enable the computer to implement the blockchain-based identity information management method according to any one of claims 1 to 4.

11. A computer program product, characterized in that When the method is run on a computer, the computer is enabled to implement the blockchain-based identity information management method as described in any one of claims 1 to 4.

12. A blockchain node, characterized in that: include: One or more processors, and one or more memories; the one or more memories are coupled to the one or more processors, and the one or more memories store computer instructions; when the one or more processors execute the computer instructions, the computer instructions implement the blockchain-based identity information management method as described in any one of claims 5 to 7.

13. A computer-readable storage medium, characterized in that The method comprises instructions, which, when executed on a computer, enable the computer to implement the blockchain-based identity information management method as described in any one of claims 5 to 7.

14. A computer program product, characterized in that When the method is run on a computer, the computer is enabled to implement the blockchain-based identity information management method as described in any one of claims 5 to 7.

Images