Secret key updating method and device of block chain node, electronic equipment and readable medium

Abstract

The invention provides a key updating method and device of a block chain node, electronic equipment and a readable medium. The method comprises: when a target node is added to a block chain, obtaining a node chaining notification of the target node and a to-be-updated data key corresponding to encrypted data in the block chain, the encrypted data in the block chain being obtained by encrypting the to-be-updated data key; generating a data key parameter corresponding to the to-be-updated data key according to the node uplink notification; encrypting the data key parameter through the to-be-updated data key to obtain an encryption parameter; the encryption parameter is linked in the block chain, so that other nodes in the block chain verify the data key parameter based on the encrypted data; generating a target data key according to the data key parameter and the to-be-updated data key; and sending the target data key to the target node to update the to-be-updated data key of each node in the block chain. According to the method, backward data leakage of encrypted data in the block chain can be prevented.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and readable medium for updating a key of a blockchain node. Background Art

[0002] The operation of blockchain relies on the complete disclosure of data on the chain, so the security of on-chain data has attracted much attention. Currently, critical blockchain data with high security requirements is generally stored on the chain in an encrypted manner.

[0003] In related technologies, when a new node joins the blockchain, the data key used for data encryption is usually sent to the newly joined node so that the new node can encrypt and decrypt the data to access the data.

[0004] However, in this scheme, after obtaining the data key, the newly joined node can decrypt all encrypted data in the blockchain, resulting in the exposure of historical encrypted data to the newly joined node, causing backward data leakage of encrypted data and affecting data security. Summary of the Invention

[0005] Based on the above technical problems, the present application provides a key update method, device, electronic device and readable medium for a blockchain node to prevent backward data leakage of encrypted data in the blockchain and improve the backward data security of the blockchain.

[0006] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0007] According to one aspect of an embodiment of the present application, a method for updating a key of a blockchain node is provided, comprising:

[0008] When a target node joins the blockchain, obtaining a node on-chain notification of the target node and a data key to be updated corresponding to the encrypted data in the blockchain, wherein the encrypted data in the blockchain is encrypted using the data key to be updated;

[0009] Generate data key parameters corresponding to the data key to be updated according to the node on-chain notification;

[0010] Encrypting the data key parameter using the data key to be updated to obtain an encrypted parameter;

[0011] Uploading the encryption parameters to the blockchain so that other nodes in the blockchain can verify the data key parameters based on the encrypted data;

[0012] Generate a target data key according to the data key parameters and the data key to be updated;

[0013] The target data key is sent to the target node to update the data key to be updated of each node in the blockchain.

[0014] According to one aspect of an embodiment of the present application, a key update device for a blockchain node is provided, comprising:

[0015] a key acquisition module configured to, when a target node joins a blockchain, acquire a node on-chain notification from the target node and a data key to be updated corresponding to the encrypted data in the blockchain, wherein the encrypted data in the blockchain is encrypted using the data key to be updated;

[0016] A parameter generation module, configured to generate a data key parameter corresponding to the data key to be updated according to the node on-chain notification;

[0017] a parameter encryption module configured to encrypt the data key parameter using the data key to be updated to obtain an encrypted parameter;

[0018] a parameter on-chain module configured to upload the encryption parameters to the blockchain, so that other nodes in the blockchain can verify the data key parameters based on the encrypted data;

[0019] a key generation module, configured to generate a target data key according to the data key parameters and the data key to be updated;

[0020] A key sending module is configured to send the target data key to the target node to update the data key to be updated of each node in the blockchain.

[0021] In some embodiments of the present application, based on the above technical solution, the node on-chain notification is a node on-chain transaction generated when the target node requests to join the blockchain; the key acquisition module is specifically configured to: obtain the node on-chain transaction of the target node in the blockchain; according to the node on-chain transaction, obtain the node on-chain block where the node on-chain transaction is located, and the node on-chain block is the block generated when the target node requests to join the blockchain; according to the target block index of the node on-chain block, obtain the data key to be updated corresponding to the target block index from the data key set, wherein the block index of the block in the blockchain corresponds to a data key.

[0022] In some embodiments of the present application, based on the above technical solution, the parameter generation module is specifically configured to: obtain the target block index of the node on-chain block where the node on-chain transaction is located; perform encryption calculation based on the target block index and the consensus private key of the local node to generate data key parameters.

[0023] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data verification module, which is configured to: receive a block on-chain request containing encryption parameters and a target block index, decrypt the encryption parameters according to the data key to be updated corresponding to the target block index to obtain data key parameters, verify the data key parameters according to the consensus public key of the blockchain node that generates the proposal consensus request and the target block index in the block on-chain request, and based on the verification result, perform a consensus vote on the block on-chain request.

[0024] In some embodiments of the present application, based on the above technical solution, the parameter chain module is specifically configured to: package the encryption parameters into a transaction block, broadcast the transaction block to the consensus node of the blockchain, so that the consensus node verifies the data key parameters according to the encryption parameters, and votes on the transaction block for chain-up based on the verification result, and according to the voting results of each consensus node on the transaction block for chain-up, the transaction block is chained in the blockchain.

[0025] In some embodiments of the present application, based on the above technical solution, the parameter chain module is specifically configured to: obtain a consensus node in the blockchain that has the data key to be updated; and broadcast the transaction block to the consensus node.

[0026] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a verification module, which is configured to: obtain a block chain proposal, the proposal block of the block chain proposal contains the key negotiation transaction of the target node, the key negotiation transaction contains key update parameters and a confirmation message, the confirmation message is encrypted according to a first confirmation key, the first confirmation key is generated by the target node according to the target data key and the key update parameters, a second confirmation key is generated according to the confirmation message and the data key corresponding to the latest block index in the blockchain, the confirmation message of the proposal block is decrypted according to the second confirmation key, and a proposal vote is performed on the block chain proposal according to the decryption result of the confirmation message, and when the key negotiation transaction of the target node is chained, the local target data key is updated to the second confirmation key.

[0027] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data reading module, which is configured to: obtain an encrypted data read request including a block index to be read and a data offset; obtain the block to be read and the data key corresponding to the block to be read according to the block index to be read; decrypt the encrypted data of the block to be read according to the data key corresponding to the block to be read to obtain decrypted data; and obtain target data from the decrypted data according to the data offset.

[0028] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data writing module, which is configured to: obtain the data processing result corresponding to the target data; encrypt the data processing result by the data key corresponding to the specified block index to obtain an encrypted data processing result; and upload the encrypted data processing result to the blockchain.

[0029] In some embodiments of the present application, based on the above technical solution, the data writing module is specifically configured to: perform block packaging according to the transactions to be chained in the local transaction pool to obtain a block header to be chained and a block body to be chained, package the encrypted data processing results to generate an encrypted block body, calculate the hash value of the encrypted block body, and add the hash value to the block header to be chained, package the block header to be chained, the block body to be chained and the encrypted block body to obtain a block to be chained, and broadcast a chain proposal for the block to be chained to the nodes in the blockchain to chain the block to be chained in the blockchain.

[0030] In some embodiments of the present application, based on the above technical solution, the key acquisition module is specifically configured to: receive the node on-chain notification broadcast by the target node, the node on-chain notification is a message broadcast when the target node becomes a consensus node in the blockchain, and the node on-chain notification includes a specified block index; according to the node on-chain notification, obtain the specified data key corresponding to the specified block index from the data key set as the data key to be updated, wherein the block index of the block in the blockchain corresponds to a data key, and the encrypted data contained in the block corresponding to the specified block index is encrypted by the specified data key.

[0031] According to one aspect of an embodiment of the present application, a blockchain updating method is provided, comprising:

[0032] Obtain the data to be encrypted and the transactions to be uploaded to the local transaction pool;

[0033] Encrypting the to-be-encrypted data using a target data key to obtain encrypted data, wherein the target data key is obtained by updating the current data key in the blockchain when the consensus node joins the blockchain;

[0034] Packaging the to-be-online transactions and the encrypted data to generate a to-be-online block, wherein the to-be-online block includes a block header, a block body, and an encrypted block body, wherein the block header includes description information of the to-be-online block, the block body includes the to-be-online transactions, and the encrypted block body includes the encrypted data;

[0035] The block to be chained is chained in the blockchain.

[0036] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the key update method of the blockchain node in the above technical solution by executing the executable instructions.

[0037] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, a key update method for a blockchain node in the above technical solution is implemented.

[0038] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the key update method for a blockchain node provided in the various optional implementations described above.

[0039] In an embodiment of the present application, when the data key needs to be updated, the data key parameters are first encrypted with the data key to be updated and then uploaded to the chain. After verification by each node, the target data key is generated using the data key parameters and the data key to be updated. Finally, the generated target data key is sent to the target node to complete the key update. Since the data key parameters in the blockchain are encrypted with the data key to be updated, and the target node only has the target data key, it cannot decrypt the data key parameters or reversely calculate the data key to be updated. This ensures that the target node can only access data subsequently encrypted using the target data key, but cannot access data encrypted with the data key to be updated. This ensures the confidentiality of historical data to newly added nodes, prevents backward data leakage of encrypted data in the blockchain, and improves the backward data security of the blockchain.

[0040] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, serve to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0042] Figure 1 This is a system architecture for a key update solution applied to blockchain nodes according to an embodiment of the present application.

[0043] Figure 2 This is a schematic diagram of the blockchain network in an embodiment of the present application.

[0044] Figure 3 This is a schematic diagram of blocks in a blockchain network in an embodiment of the present application.

[0045] Figure 4 Flowchart of a key update method for a blockchain node according to an embodiment of the present application.

[0046] Figure 5 Flowchart of a key update method for a blockchain node according to an embodiment of the present application.

[0047] Figure 6 Flowchart of a key update method for a blockchain node according to an embodiment of the present application.

[0048] Figure 7 Schematic diagram of the block data structure with a backward-safe block body in an embodiment of the present application.

[0049] Figure 8 This is a schematic flowchart of the block data chain in the embodiment of this application.

[0050] Figure 9 This is an overall schematic diagram of the blockchain backward security key negotiation process in an embodiment of the present application.

[0051] Figure 10 The block diagram schematically shows the composition of the key update device of the blockchain node in an embodiment of the present application.

[0052] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0053] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0054] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0055] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

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

[0057] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0058] It should be understood that the solution of this application can be applied in blockchain scenarios with encrypted data, and is specifically applied in the process of updating the data keys of each node when a new node joins the blockchain. The solution of this application is primarily applicable to consortium blockchains and can enhance backward data security within the blockchain. In this application, backward security of consortium blockchain data means that new nodes joining the consortium chain cannot access historical encrypted data. Consortium chains are typically built by multiple parties. Because the operation of blockchains relies on the complete disclosure of data on the chain, to protect data security, consortium chains choose to encrypt data before uploading it. Encrypted data itself has a certain degree of public accessibility. That is, nodes that participate in the consensus on uploading encrypted data to the chain should have access to this encrypted data, while nodes that do not participate in the consensus on uploading encrypted data to the chain do not have such access. For example, if 10 consensus nodes in a blockchain agree on a set of encrypted data and upload it to the chain, the encrypted data is accessible only to these 10 consensus nodes. Even if additional consensus nodes join later, the newly added consensus nodes should not be able to access the encrypted data that has already been uploaded to the chain.

[0059] The operation of blockchains relies on the complete disclosure of data on-chain, so the security of on-chain data is of great concern. Currently, critical, security-critical blockchain data is typically encrypted and stored on-chain. In related technologies, when a new node joins a blockchain, the data encryption key is typically sent to the new node, allowing it to encrypt and decrypt data and access it. However, in this solution, after obtaining the data key, the new node can decrypt all encrypted data in the blockchain. This exposes historical encrypted data to the new node, resulting in backward leakage of encrypted data and compromising data security.

[0060] Based on this, the technical solution of the embodiment of the present application proposes a key update solution for blockchain nodes. Specifically, Figure 1As shown, the system architecture 100 for a key update scheme for blockchain nodes according to an embodiment of the present application may include a terminal device 110, a network 120, and a server 130. Terminal device 110 may include a smartphone, tablet computer, laptop computer, intelligent voice interaction device, smart home appliance, vehicle-mounted terminal, aircraft, and the like. Server 130 may be a server that provides various services and may be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0061] Depending on the implementation needs, the system architecture in the embodiment of the present application can have any number of terminal devices, networks and servers. For example, the server 130 can be a server group composed of multiple server devices. In addition, the technical solution provided in the embodiment of the present application can be applied to the terminal device 110, can also be applied to the server 130, or can be implemented by the terminal device 110 and the server 130 together, and this application does not make any special restrictions on this. In the embodiment of the present application, the server 130 can be a server of a blockchain node, and the terminal device 110 can be a blockchain node or a user terminal, and the client software of the blockchain is running on the terminal device 110, so as to communicate with the server 130. When a new node joins the blockchain, the server 130 will execute the technical solution in this application to update the data keys of all nodes in the blockchain so that the new node can participate in the consensus process.

[0062] Both server 130 and terminal device 110 can be blockchain nodes in a blockchain. A blockchain is a peer-to-peer distributed ledger comprised of multiple nodes. Each node contains all transaction records, and all nodes are required to verify each transaction. Each node in a blockchain network can be either a full node or a local blockchain node. A full node can connect to other nodes, while a local blockchain node is an independent node running within the blockchain and is not connected to other nodes. A local blockchain node does not participate in the consensus mechanism of the blockchain network like a full node, but it can independently verify transactions and create new blocks. Only the first node can decrypt the confidential information sent by the second node to the first node, thereby obtaining the content and achieving confidential communication between the two nodes.

[0063] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks (i.e., blocks) generated by cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The blockchain is maintained by the nodes in the blockchain network. For example, in Figure 2 The blockchain network shown may include multiple nodes 201, which may be the individual clients that form the blockchain network. Each node 201 may receive input information during normal operation and, based on the received input information, maintain shared data within the blockchain network. To ensure information interoperability within the blockchain network, information connections may exist between each node in the blockchain network, allowing nodes to transmit information through these connections. For example, when any node in the blockchain network receives input information, the other nodes in the blockchain network obtain the input information according to a consensus algorithm and store it as shared data, ensuring that the data stored on all nodes in the blockchain network is consistent.

[0064] Each node in a blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes so that it can subsequently broadcast generated blocks to other nodes in the blockchain network based on the node identifiers of other nodes. Each node can maintain a node identifier list, storing the node name and node identifier in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0065] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 3 As shown in the figure, the blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, etc., and the block body stores the input information. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp, and difficulty value of the parent block, etc., and so on. Therefore, the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0066] The following is a detailed description of the implementation details of the technical solution of the embodiment of the present application: Figure 4The flowchart of the key update method of the blockchain node according to one embodiment of the present application is shown. The key update method of the blockchain node is applied to the blockchain system and can be executed by a device with computing and processing functions, such as a server or terminal device where the consensus node is located. Figure 4 As shown, the key update method of the blockchain node includes at least steps S410 to S460, which are described in detail as follows:

[0067] Step S410: When the target node joins the blockchain, the node on-chain notification of the target node and the data key to be updated corresponding to the encrypted data in the blockchain are obtained, wherein the encrypted data in the blockchain is encrypted using the data key to be updated.

[0068] In this embodiment, the target node is a newly joined blockchain node that becomes a consensus node. The blockchain can be a consortium blockchain. When the target node joins the blockchain, the blockchain's consensus node obtains the target node's node on-chain notification and the data key to be updated corresponding to the encrypted data in the blockchain. The node on-chain notification is information issued by the target node or the master node in the blockchain. Its function is to inform other consensus nodes in the blockchain that the target node has been on-chain, thereby enabling the target node to participate in subsequent blockchain operations, such as joining other nodes' broadcast lists, participating in consensus voting, and making block proposals. The node on-chain notification can be issued at any time after the target node is on-chain. In this embodiment, the blockchain contains encrypted data. This encrypted data is obtained by the consensus node using the data key to be updated to encrypt the original data, and then on-chaining the encrypted data. The data key to be updated is a key possessed by each consensus node in the blockchain. The data key is generally different from the key used by the consensus node for consensus. Its purpose is to encrypt the plaintext data, making it unreadable by those with the key. In this embodiment, a consensus node typically possesses both a consensus key and a data key. The data key is used to encrypt the data to be encrypted, and the consensus key is used to upload the encrypted data to the blockchain. It is understood that not all data needs to be encrypted. Therefore, both data and encrypted data may exist on the blockchain, while plaintext data can be directly read by all nodes.

[0069] Step S420: Generate data key parameters corresponding to the data key to be updated based on the node on-chain notification.

[0070] The data key parameter is a parameter used to update the data key to be updated, which is usually a random number generated based on a predetermined rule. For example, the consensus node can select a numerical value as a seed according to a predetermined rule, and generate a data key parameter based on the seed through a predetermined algorithm. It is understandable that the data key parameter is usually a parameter that can be verified, that is, for other nodes, after they receive the data key parameter, the data key to be updated and the seed, they can verify that the data key parameter is indeed generated based on the seed. The seed and algorithm can be determined by the consensus node and shared among the nodes. However, other nodes will not obtain the data key parameter by regenerating based on the seed through a predetermined algorithm. In some embodiments, the node chain notification may include information about the seed and information about the specified algorithm.

[0071] Step S430: encrypt the data key parameter using the data key to be updated to obtain an encrypted parameter.

[0072] The consensus node encrypts the data key parameters using the data key to be updated, obtaining the encrypted parameters. It is understood that these encrypted parameters are also accessible to nodes that possess the data key to be updated. However, the target node newly added to the blockchain does not possess the data key to be updated, and therefore cannot decrypt the encrypted data to obtain the data key parameters.

[0073] Step S440: uploading the encryption parameters to the blockchain so that other nodes in the blockchain can verify the data key parameters based on the encrypted data.

[0074] The consensus node will upload the encryption parameters to the blockchain. Specifically, it packages the encryption parameters into a block and submits a consensus proposal. Other nodes will verify the data key parameters based on the encrypted data during the consensus process. Specifically, after receiving the proposal, the other consensus nodes will encrypt the encryption parameters to obtain the data key parameters and then verify the correctness of these data key parameters based on a predetermined seed and algorithm. It is understandable that since the target node does not have the data key to be updated, it will not participate in the encryption parameter verification and consensus upload process. In other words, the data on the blockchain is still protected by the data key to be updated.

[0075] Step S450: Generate a target data key based on the data key parameters and the data key to be updated.

[0076] After the encryption parameters are uploaded to the blockchain, consensus nodes can confirm that the corresponding data key parameters are correct, thus reaching consensus among the consensus nodes in the blockchain. Therefore, the consensus nodes can generate a target data key based on the data key parameters and the data key to be updated. This target data key will replace the data key to be updated locally and become the data key used for the next encryption.

[0077] Step S460: Send the target data key to the target node to update the data key to be updated of each node in the blockchain.

[0078] The consensus node sends the target data key to the target node. Once the target node obtains the target data key, it can participate in the subsequent consensus process for encrypted data. Furthermore, after the encryption parameters are successfully uploaded to the blockchain, all other consensus nodes in the blockchain will generate a target data key and replace their local data keys with the target data key. After this, each consensus node will use the target data key to encrypt and upload data to the blockchain, completing the key update process for the blockchain nodes.

[0079] In an embodiment of the present application, when the data key needs to be updated, the data key parameters are first encrypted with the data key to be updated and then uploaded to the chain. After verification by each node, the target data key is generated using the data key parameters and the data key to be updated. Finally, the generated target data key is sent to the target node to complete the key update. Since the data key parameters in the blockchain are encrypted with the data key to be updated, and the target node only has the target data key, it cannot decrypt the data key parameters or reversely calculate the data key to be updated. This ensures that the target node can only access data subsequently encrypted using the target data key, but cannot access data encrypted with the data key to be updated. This ensures the confidentiality of historical data to newly added nodes, prevents backward data leakage of encrypted data in the blockchain, and improves the backward data security of the blockchain.

[0080] In some optional embodiments of the present application, based on other technical solutions of the present application, after sending the target data key to the target node, the consensus node will also perform a secondary key update. Specifically, the consensus node will obtain a block on-chain proposal. The proposal block of the block on-chain proposal contains the target node's key agreement transaction. The key agreement transaction contains key update parameters and a confirmation message. The confirmation message is encrypted using a first confirmation key, which is generated by the target node based on the target data key and the key update parameters. Then, the consensus node generates a second confirmation key based on the confirmation message and the data key corresponding to the latest block index in the blockchain. The consensus node then decrypts the confirmation message of the proposal block using the second confirmation key and, based on the decrypted confirmation message, votes on the block on-chain proposal. Finally, when the target node's key agreement transaction is on-chain, the consensus node updates the local target data key to the second confirmation key. In this embodiment, after receiving the target data key, the target node initiates a secondary key update process. During this process, the target node sends the key update parameters and encrypted confirmation message to other consensus nodes in the blockchain in plain text. The key update parameter is used to update the target data key to obtain the first confirmation key, and the confirmation message is generated by encrypting the first confirmation key. The consensus node will read the key negotiation transaction submitted by the target node from the block chain proposal, and generate the second confirmation key based on the plaintext key update parameter and the local target data key, and use the second confirmation key to decrypt the confirmation message. If the decryption is successful, it means that the first confirmation key is consistent with the second confirmation key, thereby confirming that the target data keys in each node are consistent. Each node will update the target data key to the confirmed and consistent second confirmation key. Through the secondary key update, it can be further confirmed that the key updates of all nodes are consistent, preventing the key obtained by the target node from being incorrect, and improving the security of the solution.

[0081] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of obtaining the target node's node on-chain notification and the data key to be updated corresponding to the encrypted data in the blockchain, the consensus node receives the node on-chain notification broadcast by the target node. The node on-chain notification is a message broadcast when the target node becomes a consensus node in the blockchain, and the node on-chain notification includes a specified block index. Then, based on the node on-chain notification, the consensus node obtains the specified data key corresponding to the specified block index from the data key set as the data key to be updated. The block index of a block in the blockchain corresponds to a data key, and the encrypted data contained in the block corresponding to the specified block index is encrypted using the specified data key. In this embodiment, the node on-chain notification is a message broadcast when the target node becomes a consensus node in the blockchain. This message can be sent directly by the target node to each node, without being on-chained through a blockchain transaction. The node on-chain notification typically includes a specified block index, which corresponds to the latest block in the blockchain at the time the target node is on-chain. In some embodiments, the specified block index can also be any historical block in the blockchain. By specifying a block index, you can obtain the specified data key corresponding to a specified block. By including the specified block index in the node chain notification, nodes that have the ability to decrypt the encrypted data in the specified block can participate in the key update process. This allows for flexible adjustment of the number and scope of consensus nodes participating in the key update, which helps improve the flexibility of the solution.

[0082] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 5 As shown, in a key update method for a blockchain node in one embodiment of the present application, a node on-chain notification is a node on-chain transaction generated when the target node requests to join the blockchain. The solution of the present application may include the following steps:

[0083] Step S510: When the target node joins the blockchain, obtain the node on-chain transaction of the target node in the blockchain;

[0084] Step S520: Obtain, based on the node on-chain transaction, the node on-chain block where the node on-chain transaction is located, where the node on-chain block is a block generated when the target node requests to join the blockchain;

[0085] Step S530: According to the target block index of the on-chain block of the node, obtain the data key to be updated corresponding to the target block index from the data key set, wherein the block index of the block in the blockchain corresponds to a data key, wherein the encrypted data in the on-chain block of the node is encrypted by the data key to be updated.

[0086] In an embodiment of the present application, a node on-chain notification is a node on-chain transaction generated when a target node requests to join the blockchain. This node on-chain transaction is typically a blockchain transaction submitted to the blockchain when or after the target node successfully joins the blockchain and becomes a consensus node. When or after the node on-chain transaction is packaged and uploaded to the blockchain, the master node can retrieve the node on-chain transaction from the transaction pool or on-chain blocks. Based on the node on-chain transaction, the master node can obtain the node on-chain block in which the transaction occurred. This node on-chain block is typically the block generated when the target node joined the blockchain. Based on the target block index of the node on-chain block, the master node obtains the data key to be updated corresponding to the target block index from the data key set. The consensus node contains a data key set, which includes each data key used by the consensus node since joining the blockchain. Each block index in the blockchain corresponds to a data key, and the data key set contains the relationship between data keys and block indexes. The encrypted data in the node on-chain block is encrypted using the data key to be updated. In this way, the consensus node can obtain the data key to be updated used by the target node when it joined the blockchain, thereby performing further data updates.

[0087] Step S540: Generate data key parameters corresponding to the data key to be updated based on the node on-chain notification.

[0088] Optionally, the implementation details of step S540 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0089] Step S550: encrypt the data key parameter using the data key to be updated to obtain an encrypted parameter.

[0090] Optionally, the implementation details of step S550 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0091] Step S560: uploading the encryption parameters to the blockchain so that other nodes in the blockchain can verify the data key parameters based on the encrypted data.

[0092] Optionally, the implementation details of step S560 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0093] Step S570: Generate a target data key based on the data key parameters and the data key to be updated.

[0094] Optionally, the implementation details of step S570 are the same as Figure 4 The step S450 shown in FIG is the same as that in FIG, and will not be repeated here.

[0095] Step S580: Send the target data key to the target node to update the data key to be updated of each node in the blockchain.

[0096] Optionally, the implementation details of step S580 are the same as Figure 4 The step S460 shown in FIG is the same as that in FIG, and will not be repeated here.

[0097] In an embodiment of the present application, when the data key needs to be updated, the data key parameters are first encrypted with the data key to be updated and then uploaded to the chain. After verification by each node, the target data key is generated using the data key parameters and the data key to be updated. Finally, the generated target data key is sent to the target node to complete the key update. Since the data key parameters in the blockchain are encrypted with the data key to be updated, and the target node only has the target data key, it cannot decrypt the data key parameters or reversely calculate the data key to be updated. This ensures that the target node can only access data subsequently encrypted using the target data key, but cannot access data encrypted with the data key to be updated. This ensures the confidentiality of historical data to newly added nodes, prevents backward data leakage of encrypted data in the blockchain, and improves the backward data security of the blockchain.

[0098] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of generating data key parameters corresponding to the data key to be updated based on the node on-chain notification, the consensus node will obtain the target block index of the node on-chain block where the node on-chain transaction is located, and then perform cryptographic calculations based on the target block index and the local node's consensus private key to generate the data key parameters. In this embodiment, the data key parameters are generated based on the target block index and the local node's consensus private key. Specifically, the generation method can use a verifiable random function (VRF). The target block index and consensus private key are input into the verifiable random function for calculation to obtain the data key parameters. It is understandable that inputting the same data into the verifiable random function multiple times will produce different results. This generation process also generates a verifiable random proof corresponding to the data key parameters. Other consensus nodes can use the verifiable random proof to prove that the data key parameters were indeed generated based on the target block index and the local node's consensus private key. By generating data key parameters through block index and private key, it is only necessary to provide data key parameters to each node. Each node can obtain other data required to verify the data key parameters on its own, reducing the amount of data communication between nodes and saving communication resources.

[0099] In some optional embodiments of the present application, based on other technical solutions of the present application, a consensus node also verifies block upload requests submitted by other consensus nodes. Specifically, a consensus node receives a block upload request containing encryption parameters and a target block index. It then decrypts the encryption parameters using the to-be-updated data key corresponding to the target block index to obtain the data key parameters. It then verifies the data key parameters using the consensus public key of the blockchain node that generated the proposed consensus request and the target block index in the block upload request. Finally, based on the verification results, it performs a consensus vote on the block upload request. The consensus node decrypts the encryption parameters using the to-be-updated data key corresponding to the target block index to obtain the data key parameters. The consensus node then verifies the data key parameters using the consensus public key and the target block index. A verifiable random proof exists for the data key parameters, which can be added to the encrypted data along with the data key parameters. The consensus node verifies the data key parameters using the consensus public key, the target block index, and the verifiable random proof to confirm that the data key parameters were indeed generated based on the target block index. By having consensus nodes verify data key parameters during the on-chain process, the verification process is combined with the block on-chain process without the need for additional communication, reducing the number of communications between nodes and improving communication efficiency.

[0100] In some optional embodiments of the present application, based on other technical solutions of the present application, during the process of uploading the encryption parameters to the blockchain, the consensus node packages the encryption parameters into a transaction block and then broadcasts the transaction block to the consensus nodes of the blockchain. The consensus nodes then verify the data key parameters based on the encryption parameters and vote on the transaction block for uploading based on the verification results. The transaction block is then uploaded to the blockchain based on the votes of each consensus node on the transaction block. The consensus node broadcasts the encryption parameters to other consensus nodes in the blockchain, thereby triggering the consensus uploading process in the blockchain. The consensus uploading process verifies the data key parameters based on the encryption parameters. Each consensus node votes on whether to upload the encryption parameters based on the verification results. If the voting result meets the consensus conditions, the transaction block is uploaded to the blockchain. By integrating the encryption parameter verification process into the block uploading process, the number of broadcast messages in the blockchain can be reduced, thereby reducing communication resource usage, avoiding transaction timeouts caused by excessive broadcast messages occupying resources, and improving the stability of the blockchain.

[0101] In some optional embodiments of the present application, based on other technical solutions of the present application, during the process of broadcasting the transaction block to the consensus nodes of the blockchain, the consensus nodes will obtain the consensus nodes in the blockchain that possess the data key to be updated, and then broadcast the transaction block to these consensus nodes. In this embodiment, the consensus nodes will select the consensus nodes in the blockchain that possess the data key to be updated, and then conduct a key negotiation consensus process with these consensus nodes. By screening the consensus nodes, the transaction block can be sent only to nodes that can decrypt and verify the transaction block, avoiding communication with nodes that cannot decrypt the transaction block, thus avoiding wasting communication resources and improving resource utilization efficiency.

[0102] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 6 As shown, in a key update method for a blockchain node in one embodiment of the present application, a node on-chain notification is a node on-chain transaction generated when the target node requests to join the blockchain. The solution of the present application may include the following steps:

[0103] Step S610: When the target node joins the blockchain, the node on-chain notification of the target node and the data key to be updated corresponding to the encrypted data in the blockchain are obtained, wherein the encrypted data in the blockchain is encrypted using the data key to be updated.

[0104] Optionally, the implementation details of step S510 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0105] Step S620: Generate data key parameters corresponding to the data key to be updated based on the node on-chain notification.

[0106] Optionally, the implementation details of step S620 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0107] Step S630: Encrypt the data key parameter using the data key to be updated to obtain an encryption parameter.

[0108] Optionally, the implementation details of step S630 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0109] Step S640: uploading the encryption parameters to the blockchain so that other nodes in the blockchain can verify the data key parameters based on the encrypted data.

[0110] Optionally, the implementation details of step S640 are the same as Figure 4The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0111] Step S650: Generate a target data key based on the data key parameters and the data key to be updated.

[0112] Optionally, the implementation details of step S650 are the same as Figure 4 The step S450 shown in FIG is the same as that in FIG, and will not be repeated here.

[0113] Step S660: Send the target data key to the target node to update the data key to be updated of each node in the blockchain.

[0114] Optionally, the implementation details of step S660 are the same as Figure 4 The step S460 shown in FIG is the same as that in FIG, and will not be repeated here.

[0115] Step S671, obtaining an encrypted data read request including a block index to be read and a data offset;

[0116] Step S672: Obtain the block to be read and the data key corresponding to the block to be read according to the index of the block to be read;

[0117] Step S673, decrypting the encrypted data of the block to be read according to the data key corresponding to the block to be read to obtain decrypted data;

[0118] Step S674: Obtain target data from the decrypted data according to the data offset.

[0119] In this embodiment, when a consensus node needs to read data, it retrieves the corresponding data key based on the block index. Specifically, the consensus node may receive an encrypted data read request containing the block index to be read and the data offset. This encrypted data read request is typically generated based on user instructions. The client can determine the block in which the data is located and the read address within the block based on the data requested, thereby determining the block index and data offset to be read. Based on the block index to be read, the consensus node can obtain the block to be read and the data key corresponding to the block to be read. The consensus node can then retrieve the locally stored data key set based on the block index to be read and find the data key corresponding to the block index to be read from the data key set. It is understood that the number of locally stored data keys may vary depending on when the consensus node joined the blockchain, and consensus nodes generally do not share their stored data keys with each other. If a consensus node does not find the data key corresponding to the block index to be read, it indicates that the node does not have the ability to read the encrypted data in the block to be read, and the read process ceases, resulting in a read failure. The block to be read will contain data encrypted with the corresponding data key. The consensus node decrypts the encrypted data in the block to be read based on the data key corresponding to the block to be read, thereby obtaining the decrypted data. The consensus node then retrieves the target data from the decrypted data based on the data offset. In an embodiment of the present application, the corresponding data key is obtained by block index to decrypt the encrypted data in the corresponding block. This allows the consensus node to only read encrypted data for which it has a local data key, thereby controlling read permissions on the encrypted data and improving data security.

[0120] In an embodiment of the present application, when the data key needs to be updated, the data key parameters are first encrypted with the data key to be updated and then uploaded to the chain. After verification by each node, the target data key is generated using the data key parameters and the data key to be updated. Finally, the generated target data key is sent to the target node to complete the key update. Since the data key parameters in the blockchain are encrypted with the data key to be updated, and the target node only has the target data key, it cannot decrypt the data key parameters or reversely calculate the data key to be updated. This ensures that the target node can only access data subsequently encrypted using the target data key, but cannot access data encrypted with the data key to be updated. This ensures the confidentiality of historical data to newly added nodes, prevents backward data leakage of encrypted data in the blockchain, and improves the backward data security of the blockchain.

[0121] In some optional embodiments of the present application, based on other technical solutions of the present application, after obtaining the target data from the decrypted data according to the data offset, the consensus node will also obtain the data processing result corresponding to the target data, and then encrypt the data processing result by the data key corresponding to the specified block index to obtain the encrypted data processing result, and then upload the encrypted data processing result to the blockchain. In the process of writing encrypted data, the data processing result is encrypted by the data key corresponding to the specified block index. The specified block index can be specified by the user or determined according to a predetermined rule. In this way, only nodes with the data key corresponding to the specified block index can participate in the consensus chain process, thereby being able to flexibly control the range of nodes participating in the encrypted data consensus, which is conducive to improving the flexibility of the solution.

[0122] In some optional embodiments of the present application, based on other technical solutions of the present application, during the process of uploading the encrypted data processing results to the blockchain, the consensus node will package the blocks based on the pending transactions in the local transaction pool, obtaining a pending block header and a pending block body, and package the encrypted data processing results into an encrypted block body. The consensus node then calculates a hash value for the encrypted block body and adds the hash value to the pending block header. Finally, the consensus node packages the pending block header, the pending block body, and the encrypted block body to obtain a pending block, and broadcasts a proposal for uploading the pending block to the nodes in the blockchain, thereby uploading the pending block to the blockchain. In this embodiment, a blockchain block contains three parts: a block header, a block body, and an encrypted block body. The pending transactions in the transaction pool are packaged into the pending block body, while the block information is packaged into the pending block header. The encrypted data is packaged into the encrypted block body. The hash value of the encrypted block body is also added to the block header. The block header, block body, and encrypted block body are packaged together into a block to be uploaded to the chain and broadcasted for upload. By setting up an encrypted block body in the block, the storage of encrypted data and plaintext data is separated, allowing different nodes to participate in the consensus process for different data. In other words, all consensus nodes can participate in the consensus process for plaintext data, while nodes that can decrypt the encrypted block body participate in the consensus process for the data in the encrypted block body. Through a separate encrypted block body, plaintext data is separated from encrypted data, which facilitates the separate management of encrypted and plaintext data and provides flexibility in the selection of consensus nodes in the solution.

[0123] In some optional embodiments of the present application, based on other technical solutions of the present application, a blockchain update method is provided. The blockchain update method is applied to a blockchain system and can be specifically executed by a device with computing and processing capabilities, such as a server or terminal device where a consensus node is located. The blockchain update includes:

[0124] Get the data to be encrypted and the transactions to be uploaded to the local transaction pool.

[0125] The data to be encrypted can be data added to the blockchain via a terminal or server. It is understood that the data to be encrypted can also be submitted to the blockchain in the form of a transaction. This data to be encrypted is only available to the consensus nodes currently on the blockchain. Consensus nodes that join later do not have access to encrypted data that was uploaded to the blockchain before they joined. Transactions to be uploaded are normal transactions on the blockchain, and their content is public on the blockchain, allowing nodes that join later to view the details of the transactions.

[0126] The encrypted data is encrypted using the target data key. The target data key is obtained by updating the current data key in the blockchain when the consensus node joins the blockchain. The target data key ensures that the encrypted data can only be viewed by a limited number of nodes. Each time a consensus node joins, the data key in the blockchain is updated, preventing later nodes from obtaining the old key used by the consensus node and, consequently, accessing data encrypted with the old key in the blockchain, thereby ensuring backward data security for this encrypted data. The specific update process for the target data key can be found in the above-described embodiments and will not be elaborated upon here.

[0127] A block to be on the chain is generated based on the transactions to be on the chain and the encrypted data. The block to be on the chain includes a block header, a block body, and an encrypted block body. The block header includes description information of the block to be on the chain, the block body includes the transactions to be on the chain, and the encrypted block body includes the encrypted data.

[0128] In this application, the blocks in the blockchain mainly include three parts, namely the block header, the block body, and the encrypted block body. The block header mainly contains descriptive information of the block header, such as the input information characteristic value of the current block, the block header characteristic value of the parent block, the version number, the timestamp, and the difficulty value. The block body mainly contains the data content that is publicly available in the blockchain, such as public blockchain transactions, and in this embodiment, transactions to be uploaded to the chain. The encrypted block body contains data that needs to be protected for backward data security. This data can only be accessed by nodes that have reached consensus on the parameters because these nodes have the encryption key for this information. The key used to encrypt the data in the encrypted block body will not be shared among the blockchain nodes and will be updated each time a new node joins, thereby ensuring that the nodes that join later cannot access the data encrypted by the nodes that joined earlier. Through a separate encrypted block body, the plaintext data is separated from the encrypted data, which is conducive to the separate management of encrypted data and plaintext data, providing flexibility in selecting consensus nodes in the solution.

[0129] The block to be chained is chained in the blockchain.

[0130] The process of consensus on the chain can adopt any available consensus process, which will not be detailed here.

[0131] The following is an example of the implementation details of the technical solution of the embodiment of the present application: Figure 7 , Figure 7 Schematic diagram of the block data structure with backward security block body in the embodiment of the present application. Figure 7 As shown, block data consists of three parts: a block header, a block body, and a backward-secure block body. The block body is the plaintext data on the blockchain, readable by all nodes. The data in the backward-secure block body is encrypted using the same key shared by all current nodes in the blockchain. As new nodes join the blockchain, they all switch to new keys. New nodes cannot obtain the old keys and cannot access the content in the backward-secure block body encrypted with the old keys. Only nodes that previously possessed the old keys can still access this encrypted data. When a new block body is added to the block data, the corresponding content of the new block body is added to the block header to ensure the security of the block data itself.

[0132] The block data structure changes, and the data chain process also changes accordingly. In this application, data chaining is divided into two processes: normal chaining and backward secure chaining. For ease of introduction, please refer to Figure 8 , Figure 8 This is a schematic flow chart of the block data chain in the embodiment of this application. Figure 8As shown in Figure 1, there are three nodes in the blockchain, where blockchain node A is a newly added node, while blockchain node B and blockchain node C are online nodes that are running stably in the blockchain. The negotiated key is the key obtained through negotiation among all the current online blockchain nodes and is used for symmetric encryption of the backward security block body. Figure 8 In this example, since blockchain node A is a newly joined blockchain node, it does not possess the negotiated key, while blockchain nodes B and C do possess the negotiated key. Each node has a ledger program—a program that maintains the blockchain's world state data, processes blockchain transactions, and handles the node's external communications. The blockchain also includes a system negotiation contract. This contract is used to negotiate key updates. It receives transaction inputs from the block body and, through the environment instructions of the smart contract virtual machine in the ledger program, retrieves decrypted data from the backward-secure block body. The block body stores all unencrypted blockchain data in plaintext, while the backward-secure block body stores encrypted data symmetrically encrypted with the negotiated key. This encryption is backward-secure.

[0133] The normal chain-up process can refer to the normal chain-up process of the block body. Figure 8 As shown in , blockchain nodes A, B, and C all participate in the block body on-chain process. Specifically, the accounting program of each node independently reads and writes the block body, and records it as

[0134] Block= <Hedaer,Body,Body BS >

[0135] The block consists of a header, a body, and a backward-safe body. BS The process of forming and reaching consensus and uploading plaintext data to the chain is to generate and write Hedaer and Body.

[0136] Backward security on-chain is the process of encrypting data with a negotiated key and then on-chain. For key sensitive data, when the blockchain node needs to encrypt and store key data (read and write), the accounting program with the negotiated key will encrypt and store this data, that is, the backward security block body. BS To write:

[0137] Body BS =Encrypt(Raw,P i )

[0138] Among them, P u The current encryption key. Different negotiation keys will be used after the nodes negotiate at different times. Encrypt() is the encryption function. Body BSTo process the original plaintext data Raw through P i Symmetrically encrypted backward-secure block.

[0139] The system negotiation contract is used for backward secure reading and writing. Specifically, in the blockchain’s smart contract virtual machine, the preset instruction “OP_BODYBS_READ[N, OFFSET]” is used to read the content of the backward secure block body corresponding to the block number of the current top stack element N with an offset of OFFSET. During the execution process, this part of the element will be read and the negotiated key P corresponding to the block number N will be used. i Decryption is as follows:

[0140] First, read the negotiated key index corresponding to block number N:

[0141] i=IndexOfP(N)

[0142] IndexOfP is a built-in function in the blockchain node that is used to read the index of the negotiated key corresponding to block number N. This index is then used to decrypt the raw content of the backward secure block body in block N as follows:

[0143] Raw=Decrypt(Block N .Body BS ,P i )

[0144] Content = Raw[OFFSET]

[0145] Among them, the function Decrypt() is a symmetric decryption function corresponding to the function Encrypt(). The Raw obtained by decryption is actually an array. The element Content at the offset OFFSET in the array is the encrypted content to be read by the OP_BODYBS_READ operation code.

[0146] Similarly, setting the “OP_BODYBS_WRITE” opcode means writing the current stack top into the backward-safe block body of block N.

[0147] For example, Figure 8 In the system key negotiation contract, D1 and D3 are normal on-chain data and can be read in plain text at will, while D2 and D4 require backward secure pointing to read and write.

[0148] After blockchain node A joins the blockchain, it will request a negotiation key. Blockchain nodes B and C will negotiate to update the data key and provide it to blockchain node A, thus entering a new encryption state. At the same time, while preventing the later-joined blockchain node A from obtaining the old data of blockchain nodes B and C, it can still participate in the consensus on the new data. For the sake of introduction, please refer to Figure 9 , Figure 9 This is a schematic diagram of the overall process of blockchain backward security key negotiation in the embodiment of this application. Figure 9 As shown in Figure 1, during the normal operation of the blockchain, data is securely stored, all nodes operate normally and can read and write data on the chain. This state can be marked as a secure state M, that is, Figure 9 In the example, the four hollow blockchain nodes can read and write the backward-secure block body. A new node (the solid node in the diagram) initiates the joining process through the blockchain consensus protocol. At this point, the solid node initiates a transaction (1) to the blockchain. After all hollow nodes receive the signal, they enter the state update phase. This transaction is packaged into blocks N-K. However, at this point, only the four hollow blockchain nodes in the blockchain can read and write the backward-secure block body. Therefore, for the remainder of the process, blocks N-K through N remain in their original security state, M.

[0149] The normal on-chain transaction of the solid node will trigger the function in the system negotiation contract. The hollow node that receives the transaction will run the following verifiable random function VRF: given an input X, such as the block number N-K, and a hollow node's accounting private key Sk, calculate a random output Y and a verifiable random proof Pro:

[0150] X=NK

[0151] Y, Pro=VRF(Sk,X)

[0152] The generated Y will be written into the backward security block by P_i as an encrypted update, that is, the newly added solid node will not be able to obtain the value of Y in the future. Figure 8 In the example, the value of Y corresponds to D2 or D4, which is the change in the encrypted key Delta.

[0153] The random output Y will be verified by all hollow nodes through the verifiable random process, i.e.

[0154] Valid=VRF_Verify(X,Y,Pro,Pk,)

[0155] If Valid is true, the random number selection is valid, and all hollow nodes update the negotiated key P they already have. i

[0156] P i+1 =P i +Y

[0157] After the updated P i+1 It can be sent from any hollow node to the newly added solid node.

[0158] The solid node will initiate a new key negotiation transaction in the normal on-chain transaction, perform a secondary update and confirmation to further confirm that the key updates of all nodes are consistent, and prevent the hollow node from sending the wrong key to do malicious things, as follows:

[0159] P i+2 =P i+1 +PUBLIC

[0160] PUBLIC is any random value sent by the solid node to the system negotiation contract after normal on-chain transmission. The value can be the hash value BlockN.Hash of the current block N.

[0161] exist Figure 8 In the example, the value of PUBLIC corresponds to D1 or D3, which is the change in the plaintext key Delta.

[0162] At the same time, through P i+2 Write a confirmation message to the secure block body to confirm that the changed key can be symmetrically decrypted by all nodes.

[0163] After the confirmation is completed, starting from block N+1, all nodes switch to the new key P i+2 , the system enters a new secure encrypted storage state M+1.

[0164] It should be noted that although the steps of the method of the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all steps must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0165] The following introduces the device implementation of the present application, which can be used to execute the key update method of the blockchain node in the above embodiment of the present application. Figure 10 The block diagram of the key update device of the blockchain node in the embodiment of the present application is schematically shown. Figure 10 As shown, the key update device 1000 of the blockchain node may mainly include:

[0166] The key acquisition module 1010 is configured to, when a target node joins a blockchain, acquire a node on-chain notification from the target node and a data key to be updated corresponding to the encrypted data in the blockchain, wherein the encrypted data in the blockchain is encrypted using the data key to be updated;

[0167] The parameter generation module 1020 is configured to generate a data key parameter corresponding to the data key to be updated according to the node on-chain notification;

[0168] The parameter encryption module 1030 is configured to encrypt the data key parameter using the data key to be updated to obtain an encrypted parameter;

[0169] a parameter on-chain module 1040 configured to on-chain the encryption parameters in the blockchain, so that other nodes in the blockchain can verify the data key parameters based on the encrypted data;

[0170] The key generation module 1050 is configured to generate a target data key according to the data key parameters and the data key to be updated;

[0171] The key sending module 1060 is configured to send the target data key to the target node to update the data key to be updated of each node in the blockchain.

[0172] In some embodiments of the present application, based on the above technical solution, the node on-chain notification is a node on-chain transaction generated when the target node requests to join the blockchain; the key acquisition module 1010 is specifically configured to: obtain the node on-chain transaction of the target node in the blockchain; according to the node on-chain transaction, obtain the node on-chain block where the node on-chain transaction is located, and the node on-chain block is the block generated when the target node requests to join the blockchain; according to the target block index of the node on-chain block, obtain the data key to be updated corresponding to the target block index from the data key set, wherein the block index of the block in the blockchain corresponds to a data key.

[0173] In some embodiments of the present application, based on the above technical solution, the parameter generation module 1020 is specifically configured to: obtain the target block index of the node on-chain block where the node on-chain transaction is located; perform encryption calculation based on the target block index and the consensus private key of the local node to generate data key parameters.

[0174] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data verification module, which is configured to: receive a block on-chain request containing encryption parameters and a target block index, decrypt the encryption parameters according to the data key to be updated corresponding to the target block index to obtain data key parameters, verify the data key parameters according to the consensus public key of the blockchain node that generates the proposal consensus request and the target block index in the block on-chain request, and based on the verification result, perform a consensus vote on the block on-chain request.

[0175] In some embodiments of the present application, based on the above technical solution, the parameter chain module 1040 is specifically configured to: package the encryption parameters into a transaction block, broadcast the transaction block to the consensus node of the blockchain, so that the consensus node verifies the data key parameters according to the encryption parameters, and votes on the transaction block for chaining based on the verification result, and according to the voting results of each consensus node on the transaction block for chaining, the transaction block is chained in the blockchain.

[0176] In some embodiments of the present application, based on the above technical solution, the parameter chain module 1040 is specifically configured to: obtain a consensus node in the blockchain that has the data key to be updated; and broadcast the transaction block to the consensus node.

[0177] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a verification module, which is configured to: obtain a block chain proposal, the proposal block of the block chain proposal contains the key negotiation transaction of the target node, the key negotiation transaction contains key update parameters and a confirmation message, the confirmation message is encrypted according to a first confirmation key, the first confirmation key is generated by the target node according to the target data key and the key update parameters, a second confirmation key is generated according to the confirmation message and the data key corresponding to the latest block index in the blockchain, the confirmation message of the proposal block is decrypted according to the second confirmation key, and a proposal vote is performed on the block chain proposal according to the decryption result of the confirmation message, and when the key negotiation transaction of the target node is chained, the local target data key is updated to the second confirmation key.

[0178] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data reading module, which is configured to: obtain an encrypted data read request including a block index to be read and a data offset; obtain the block to be read and the data key corresponding to the block to be read according to the block index to be read; decrypt the encrypted data of the block to be read according to the data key corresponding to the block to be read to obtain decrypted data; and obtain target data from the decrypted data according to the data offset.

[0179] In some embodiments of the present application, based on the above technical solution, the key update device of the blockchain node also includes a data writing module, which is configured to: obtain the data processing result corresponding to the target data; encrypt the data processing result by the data key corresponding to the specified block index to obtain an encrypted data processing result; and upload the encrypted data processing result to the blockchain.

[0180] In some embodiments of the present application, based on the above technical solution, the data writing module is specifically configured to: perform block packaging according to the transactions to be chained in the local transaction pool to obtain a block header to be chained and a block body to be chained, package the encrypted data processing results to generate an encrypted block body, calculate the hash value of the encrypted block body, and add the hash value to the block header to be chained, package the block header to be chained, the block body to be chained and the encrypted block body to obtain a block to be chained, and broadcast a chain proposal for the block to be chained to the nodes in the blockchain to chain the block to be chained in the blockchain.

[0181] In some embodiments of the present application, based on the above technical solution, the key acquisition module 1010 is specifically configured to: receive the node on-chain notification broadcast by the target node, the node on-chain notification is a message broadcast when the target node becomes a consensus node in the blockchain, and the node on-chain notification includes a specified block index; according to the node on-chain notification, obtain the specified data key corresponding to the specified block index from the data key set as the data key to be updated, wherein the block index of the block in the blockchain corresponds to a data key, and the encrypted data contained in the block corresponding to the specified block index is encrypted by the specified data key.

[0182] In some embodiments of the present application, a blockchain updating device is provided, comprising:

[0183] A data acquisition module configured to acquire data to be encrypted and transactions to be uploaded to the blockchain from the local transaction pool;

[0184] a data encryption module configured to encrypt the data to be encrypted using a target data key to obtain encrypted data, wherein the target data key is obtained by updating the current data key in the blockchain when the consensus node joins the blockchain;

[0185] a block packaging module configured to package the to-be-online transactions and the encrypted data to generate a to-be-online block, wherein the to-be-online block includes a block header, a block body, and an encrypted block body, wherein the block header includes description information of the to-be-online block, the block body includes the to-be-online transactions, and the encrypted block body includes the encrypted data;

[0186] The block chain module is configured to chain the block to be chained in the blockchain.

[0187] It should be noted that the apparatus provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0188] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown.

[0189] It should be noted that Figure 11 The computer system 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0190] like Figure 11 As shown, computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1102 or programs loaded from storage 1108 into random access memory (RAM) 1103. RAM 1103 also stores various programs and data required for system operation. CPU 1101, ROM 1102, and RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to bus 1104.

[0191] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, and the like; an output section 1107 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1108 including a hard disk; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. Removable media 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1110 as needed, so that computer programs read from the removable media can be installed in the storage section 1108 as needed.

[0192] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the various functions defined in the system of the present application are executed.

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

[0194] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0195] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0196] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0197] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0198] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for updating the key of a blockchain node, characterized in that: include: When a target node joins the blockchain, obtaining a node on-chain notification of the target node and a data key to be updated corresponding to the encrypted data in the blockchain, wherein the encrypted data in the blockchain is encrypted using the data key to be updated; Generate data key parameters corresponding to the data key to be updated according to the node on-chain notification; Encrypting the data key parameter using the data key to be updated to obtain an encrypted parameter; Uploading the encryption parameters to the blockchain so that other nodes in the blockchain can verify the data key parameters based on the encrypted data; Generate a target data key according to the data key parameters and the data key to be updated; The target data key is sent to the target node to update the data key to be updated of each node in the blockchain.

2. The method according to claim 1, characterized in that The node on-chain notification is a node on-chain transaction generated when the target node requests to join the blockchain; obtaining the node on-chain notification of the target node and the data key to be updated corresponding to the encrypted data in the blockchain includes: Get the node on-chain transaction of the target node in the blockchain; According to the node on-chain transaction, obtain the node on-chain block where the node on-chain transaction is located, where the node on-chain block is the block generated when the target node requests to join the blockchain; According to the target block index of the on-chain block of the node, the data key to be updated corresponding to the target block index is obtained from the data key set, wherein the block index of the block in the blockchain corresponds to a data key.

3. The method according to claim 2, characterized in that Generating data key parameters corresponding to the data key to be updated according to the node on-chain notification includes: Obtain the target block index of the node on-chain block where the node on-chain transaction is located; An encryption calculation is performed based on the target block index and the consensus private key of the local node to generate data key parameters.

4. The method according to claim 3, characterized in that The method further comprises: Receive a block upload request containing encryption parameters and target block index; Decrypting the encryption parameter according to the data key to be updated corresponding to the target block index to obtain a data key parameter; Verify the data key parameters based on the consensus public key of the blockchain node that generated the proposal consensus request and the target block index in the block on-chain request; Based on the verification results, a consensus vote is conducted on the block chain request.

5. The method according to claim 2, characterized in that The step of uploading the encryption parameters to the blockchain includes: Packaging the encrypted parameters into a transaction block; Broadcasting the transaction block to the consensus nodes of the blockchain, so that the consensus nodes verify the data key parameters according to the encryption parameters and vote on the transaction block based on the verification results; According to the voting results of each consensus node on the transaction block being put on the chain, the transaction block is put on the chain in the blockchain.

6. The method according to claim 5, characterized in that Broadcasting the transaction block to the consensus node of the blockchain includes: Obtaining a consensus node in the blockchain that has the data key to be updated; Broadcast the transaction block to the consensus node.

7. The method according to claim 1, characterized in that After sending the target data key to the target node, the method further includes: Obtaining a block on-chain proposal, where the proposal block of the block on-chain proposal includes a key agreement transaction of the target node, the key agreement transaction includes key update parameters and a confirmation message, and the confirmation message is encrypted using a first confirmation key generated by the target node based on the target data key and the key update parameters; Generate a second confirmation key based on the confirmation message and the data key corresponding to the latest block index in the blockchain; Decrypting the confirmation message of the proposal block according to the second confirmation key; Based on the decryption result of the confirmation message, a proposal vote is conducted on the block chain proposal; When the key agreement transaction of the target node is uploaded to the chain, the local target data key is updated to the second confirmation key.

8. The method according to claim 1, characterized in that The method further comprises: Get an encrypted data read request containing the block index and data offset to be read; Obtaining the block to be read and the data key corresponding to the block to be read according to the block index to be read; Decrypting the encrypted data of the block to be read according to the data key corresponding to the block to be read to obtain decrypted data; Target data is obtained from the decrypted data according to the data offset.

9. The method according to claim 8, characterized in that After obtaining the target data from the decrypted data according to the data offset, the method further includes: Obtaining a data processing result corresponding to the target data; Encrypt the data processing result using the data key corresponding to the specified block index to obtain an encrypted data processing result; The encrypted data processing result is uploaded to the blockchain.

10. The method according to claim 9, characterized in that The step of uploading the encrypted data processing result to the blockchain includes: Pack blocks based on the transactions to be put on the chain in the local transaction pool to obtain the block header and block body to be put on the chain; Packaging the encrypted data processing results to generate an encrypted block body; Calculate the hash value of the encrypted block body and add the hash value to the block header to be put on the chain; Packing the to-be-chained block header, the to-be-chained block body, and the encrypted block body to obtain a to-be-chained block; Broadcasting a proposal for the block to be chained to the nodes in the blockchain to chain the block to be chained in the blockchain.

11. The method according to claim 1, wherein The obtaining of the node on-chain notification of the target node and the data key to be updated corresponding to the encrypted data in the blockchain includes: Receive a node on-chain notification broadcast by the target node, where the node on-chain notification is a message broadcast when the target node becomes a consensus node in the blockchain, and the node on-chain notification includes a specified block index; According to the node on-chain notification, the specified data key corresponding to the specified block index is obtained from the data key set as the data key to be updated, wherein the block index of the block in the blockchain corresponds to a data key, and the encrypted data contained in the block corresponding to the specified block index is encrypted using the specified data key.

12. A blockchain update method, characterized in that: include: Obtain the data to be encrypted and the transactions to be uploaded to the local transaction pool; Encrypting the to-be-encrypted data using a target data key to obtain encrypted data, wherein the target data key is obtained by updating the current data key in the blockchain when the consensus node joins the blockchain; Packaging the to-be-online transactions and the encrypted data to generate a to-be-online block, wherein the to-be-online block includes a block header, a block body, and an encrypted block body, wherein the block header includes description information of the to-be-online block, the block body includes the to-be-online transactions, and the encrypted block body includes the encrypted data; The block to be chained is chained in the blockchain.

13. A key update device for a blockchain node, characterized in that: include: a key acquisition module configured to, when a target node joins a blockchain, acquire a node on-chain notification from the target node and a data key to be updated corresponding to the encrypted data in the blockchain, wherein the encrypted data in the blockchain is encrypted using the data key to be updated; A parameter generation module, configured to generate a data key parameter corresponding to the data key to be updated according to the node on-chain notification; a parameter encryption module configured to encrypt the data key parameter using the data key to be updated to obtain an encrypted parameter; a parameter on-chain module configured to upload the encryption parameters to the blockchain, so that other nodes in the blockchain can verify the data key parameters based on the encrypted data; a key generation module, configured to generate a target data key according to the data key parameters and the data key to be updated; A key sending module is configured to send the target data key to the target node to update the data key to be updated of each node in the blockchain.

14. An electronic device, characterized in that: include: processor; a memory for storing executable instructions of the processor; The processor is configured to execute the key update method of the blockchain node described in any one of claims 1 to 11 or the blockchain update method described in claim 12 by executing the executable instructions.

15. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the key update method of the blockchain node according to any one of claims 1 to 11 or the blockchain update method according to claim 12.

16. A computer program product, characterized in that The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor of the electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the key update method of the blockchain node as described in any one of claims 1 to 11 or the blockchain update method described in claim 12.

Images