Data archiving method and apparatus

Abstract

This specification provides a data archiving method and apparatus through one or more embodiments. The method is applied to a first blockchain node in a first blockchain network, where a second blockchain node in a second blockchain network is also deployed in the node device where the first blockchain node is located. The first blockchain network is managed by the second blockchain network. The method includes: acquiring a data archiving event generated by the second blockchain node executing a data archiving transaction, the data archiving event including node indication information and data indication information; if the node indication information indicates that the first blockchain node is a node to be archived, performing archiving processing on the data to be archived indicated by the data indication information to obtain archived data; updating a locally maintained first access path to a second access path, the first access path and the second access path being used to access the data to be archived and the archived data, respectively.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a data archiving method and apparatus. Background Technology

[0002] Blockchain technology, built on top of transmission networks (such as peer-to-peer networks), is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Nodes in a blockchain network sequentially link data blocks into a chain-like data structure, creating a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable.

[0003] Each node in a blockchain network maintains its own blockchain data. As the blockchain network continues to operate and its scale increases, there is a need to archive this blockchain data.

[0004] In related technologies, operations and maintenance personnel typically archive the blockchain data stored locally on each blockchain node's device. However, this approach not only results in low efficiency for the personnel's archiving operations but also makes these operations untraceable, meaning the archiving process cannot be recorded, posing a significant security risk. Summary of the Invention

[0005] In view of the above, one or more embodiments of this specification provide a data archiving method and apparatus.

[0006] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0007] According to a first aspect of one or more embodiments of this specification, a data archiving method is proposed, applied to a first blockchain node in a first blockchain network, wherein a second blockchain node in a second blockchain network is also deployed in the node device where the first blockchain node is located, and the first blockchain network is managed by the second blockchain network. The method includes:

[0008] Obtain the data archiving event generated by the second blockchain node executing the data archiving transaction, wherein the data archiving event includes node indication information and data indication information;

[0009] When the node indication information indicates that the first blockchain node is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data;

[0010] The locally maintained first access path is updated to the second access path, and the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0011] According to a second aspect of one or more embodiments of this specification, a data archiving method is proposed, applied to any blockchain node in a blockchain network, the method comprising:

[0012] Execute data archiving transactions to obtain node indication information and data indication information;

[0013] When the node indication information indicates that any of the blockchain nodes is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data;

[0014] The locally maintained first access path is updated to the second access path, and the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0015] According to a third aspect of one or more embodiments of this specification, a data archiving apparatus is provided, applied to a first blockchain node in a first blockchain network, wherein a second blockchain node in a second blockchain network is also deployed in the node device where the first blockchain node is located, and the first blockchain network is managed by the second blockchain network. The apparatus includes:

[0016] An event acquisition unit is used to acquire data archiving events generated by the second blockchain node executing data archiving transactions. The data archiving events include node indication information and data indication information.

[0017] The data archiving unit is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that the first blockchain node is the node to be archived;

[0018] The path update unit is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0019] According to a fourth aspect of one or more embodiments of this specification, a data archiving apparatus is provided, applied to any blockchain node in a blockchain network, the apparatus comprising:

[0020] The transaction execution unit is used to execute data archiving transactions in order to obtain node indication information and data indication information;

[0021] The data archiving unit is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that any of the blockchain nodes is a node to be archived, so as to obtain archived data.

[0022] The path update unit is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0023] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0024] processor;

[0025] Memory used to store processor-executable instructions;

[0026] The processor implements the method as described in any one of the first or second aspects by executing the executable instructions.

[0027] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in any one of the first or second aspects.

[0028] In the above embodiment, the second blockchain node in the second blockchain network executes a data archiving transaction to generate a data archiving event containing node indication information and data indication information. The first blockchain node in the first blockchain network responds to the event. If the node indication information indicates that the first blockchain node is a node to be archived, the node performs archiving processing on the data to be archived indicated by the data indication information to obtain archived data, and updates the locally maintained first access path for accessing the data to be archived to a second access path for accessing the archived data.

[0029] Understandably, because the first blockchain network is managed by the second blockchain network, the first blockchain network is a subnet, and the nodes within it are subnet nodes. Correspondingly, the second blockchain network is the mainnet, and the nodes within it are mainnet nodes. Through this method, the mainnet nodes can control the corresponding subnet nodes to archive the data they maintain by executing data archiving transactions. In other words, the mainnet can control specific blockchain nodes within a subnet to perform targeted archiving of specific blockchain data. Furthermore, updating the access address of the data to be archived to the access address of the archived data also facilitates normal access to the archived data by subnet nodes, thereby ensuring the normal operation of the archived blockchain subnet. In this method, centralized control of subnet data archiving is achieved through transactions executed by the mainnet nodes. On the one hand, it eliminates the need for maintenance personnel to perform off-chain archiving operations on the node devices of each subnet node, greatly improving the efficiency of blockchain data archiving. On the other hand, the operation records of the aforementioned data archiving transactions are stored in the blockchain mainnet, so the data archiving process is traceable, achieving accurate recording and reliable storage of the archiving process, and effectively improving the security of the blockchain data archiving process. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 This is a schematic diagram of a blockchain network provided in an exemplary embodiment.

[0032] Figure 2 This is a flowchart of a data archiving method provided in an exemplary embodiment.

[0033] Figure 3 This is a schematic diagram of a data archiving process provided in an exemplary embodiment.

[0034] Figure 4 This is a schematic diagram of another data archiving process provided in an exemplary embodiment.

[0035] Figure 5 This is a flowchart of another data archiving method provided in an exemplary embodiment.

[0036] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0037] Figure 7 This is a block diagram of a data archiving apparatus provided in an exemplary embodiment.

[0038] Figure 8 This is a block diagram of another data archiving apparatus provided in an exemplary embodiment. Detailed Implementation

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

[0040] Individuals or organizations can participate in a blockchain network as node members, such as by participating in the creation of a blockchain network or joining an existing one. Any individual or organization may participate in only one blockchain network or multiple blockchain networks.

[0041] Due to the decentralized nature of blockchain networks, all blockchain nodes typically maintain the same block data, making it difficult to meet the specific needs of some nodes. Taking a consortium blockchain as an example, all consortium members (i.e., node members within the consortium) can form a blockchain network. Each member has a corresponding blockchain node within this network and can access all transactions and related data occurring on the network through their respective nodes. However, in some cases, some consortium members may wish to complete transactions with confidentiality requirements. These members want these transactions to be notarized on the blockchain or leverage other advantages of blockchain technology, while preventing other consortium members from seeing these transactions and related data. Although these members can form a new blockchain network, similar to the one with all members, building a new blockchain network from scratch requires significant resources, and both the establishment and configuration processes are very time-consuming. The needs of consortium members are often temporary or time-sensitive, causing the newly established blockchain network to quickly lose its purpose as the need disappears, further increasing the construction cost of the aforementioned blockchain network. The needs of alliance members often change, and the alliance members corresponding to each need are often different. Therefore, whenever the alliance members change, it may be necessary to build a new blockchain network, resulting in a huge waste of resources and time.

[0042] Therefore, an existing blockchain network can be used as the main network, and subnets can be built upon this main network. In consortium blockchain scenarios like those described above, consortium members can build their own subnets based on their specific needs, even while already participating in the main network. Because subnets are built upon the main network, the resource consumption and time required for subnet construction are significantly reduced compared to building a completely independent blockchain network, resulting in greater flexibility.

[0043] The process of quickly building a blockchain subnet based on the blockchain mainnet is as follows: Each blockchain node in the blockchain mainnet obtains a transaction for building the blockchain subnet. The transaction contains the configuration information of the blockchain subnet. The configuration information includes the identity information of the node members participating in building the blockchain subnet. Each blockchain node in the blockchain mainnet executes the transaction to expose the configuration information. When the configuration information contains the identity information of the node members corresponding to the first blockchain node, the node device deploying the first blockchain node starts a second blockchain node belonging to the blockchain subnet based on the genesis block containing the configuration information.

[0044] by Figure 1 For example, the mainnet of the blockchain is mainnet0, and this network contains blockchain nodes such as nodeA, nodeB, nodeC, nodeD, and nodeE. Assume that nodeA, nodeB, nodeC, and nodeD want to establish a blockchain subnet: If nodeA is the administrator and only administrators are allowed to initiate transactions to establish a blockchain subnet, then nodeA can initiate the aforementioned transaction to mainnet0. If nodeE is the administrator and only administrators are allowed to initiate transactions to establish a blockchain subnet, then nodesA through nodeD need to request nodeE to initiate the aforementioned transaction to mainnet0. If nodeE is the administrator but allows ordinary users to initiate transactions to establish a blockchain subnet, then nodesA through nodeE can all initiate the aforementioned transaction to mainnet0. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to build the blockchain subnet does not necessarily participate in the blockchain subnet being built. For example, although the blockchain subnet is ultimately built by nodeA, nodeB, nodeC and nodeD, nodeE can initiate the above transaction to build the blockchain subnet to mainnet0, and it is not necessarily nodeA to nodeD that initiate the transaction to build the blockchain subnet.

[0045] It's easy to understand that when building a blockchain subnet on top of the mainnet, a logical hierarchical relationship exists between the subnet and the mainnet. For example, in... Figure 1 When building a blockchain subnet 1 on mainnet0, as shown, mainnet0 can be considered to be at the first layer and subnet1 at the second layer. In one scenario, the blockchain mainnet in this specification can be an underlying blockchain network, meaning the blockchain mainnet is not a blockchain subnet built on top of other blockchain networks, for example... Figure 1 In this context, `mainnet0` can be considered the mainnet of the underlying blockchain network. Alternatively, the mainnet in this specification can also be a subnet of another blockchain network, such as... Figure 1 Based on subnet1, another blockchain subnet, subnet1.1, is further built. At this point, subnet1 can be considered the blockchain mainnet corresponding to subnet1.1, and this does not affect the fact that subnet1 also belongs to the blockchain subnet created on mainnet0. It can be seen that the blockchain mainnet and blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain mainnet in some cases and the blockchain subnet in other cases.

[0046] After the aforementioned transactions for establishing a blockchain subnet are sent to the main blockchain network, they are consensus-reached by the consensus nodes within the main network. Once consensus is reached, each main network node executes the transaction to complete the establishment of the blockchain subnet. The consensus process depends on the consensus mechanism employed, and this specification does not impose any limitations on it.

[0047] By including configuration information in the transactions for building the blockchain subnet, this information can be used to configure the subnet to meet networking requirements. For example, by including node member identity information in the configuration information, it is possible to specify which blockchain nodes will be included in the subnet.

[0048] The identity information of node members may include the node's public key, or other information that can characterize the node's identity, such as the node ID. This specification does not impose any restrictions on this. Taking the public key as an example, each blockchain node has one or more corresponding public-private key pairs. The blockchain node holds the private key, while the public key is publicly available and uniquely corresponds to that private key. Therefore, the identity of the corresponding blockchain node can be represented by the public key. Thus, for blockchain nodes that wish to become members of a blockchain subnet, their public keys can be added to the aforementioned transactions for building the blockchain subnet, serving as the identity information of these node members. The aforementioned public-private key pairs can be used in the signature verification process. For example, in a consensus algorithm using signatures, such as nodeA1 in subnet1 signing a message with its own private key and broadcasting the signed message in subnet1, nodeB1, nodeC1, and nodeD1 can use nodeA1's public key to sign and verify the received message, confirming that the message they received indeed came from nodeA1 and has not been tampered with.

[0049] The configuration information can be used to indicate the node members corresponding to any mainnet node in the blockchain mainnet. When building a blockchain subnet, the mainnet node does not directly participate in the subnet construction or become a node member. Instead, the node device used to deploy the mainnet node generates the subnet node, which then becomes a node member within the blockchain subnet. Therefore, the mainnet node and the subnet node correspond to the same blockchain member, such as the same consortium blockchain member in a consortium blockchain scenario. However, the mainnet node belongs to the blockchain mainnet, and the subnet node belongs to the blockchain subnet, allowing the blockchain member to participate in transactions in both the mainnet and the subnet. Furthermore, since the mainnet and subnet are two independent blockchain networks, the blocks generated by the mainnet nodes and the blocks generated by the subnet nodes are stored in different storage devices on the node devices (such as databases). This achieves mutual isolation between the storage used by the mainnet nodes and the subnet nodes. Therefore, the data generated by the subnet is only synchronized among the node members of the subnet, so that blockchain members who only participate in the mainnet cannot obtain the data generated on the subnet. This achieves data isolation between the mainnet and the subnet, and meets the small-scale transaction needs of some blockchain members (i.e., blockchain members participating in the subnet).

[0050] Furthermore, the mainnet node and the subnet node are logically separated blockchain nodes. From a physical device perspective, this means that the node devices of both nodes participate in both the mainnet and the subnet simultaneously. Because the mainnet and subnet are independent of each other, their identity systems are also independent. Therefore, even if the mainnet node and the subnet node use the exact same public key, they should still be considered different blockchain nodes. For example, in... Figure 1 In the diagram, nodeA in mainnet0 is equivalent to the aforementioned mainnet node, and the node device that deploys nodeA (i.e., node device 1) generates nodeA1 belonging to subnet1. This nodeA1 is equivalent to the aforementioned subnet node. Therefore, since the identity systems are independent, whether the public key used by the subnet node differs from that of the mainnet node does not affect the implementation of the scheme described in this specification.

[0051] Of course, the node members of a blockchain subnet are not necessarily only some of the node members of the main blockchain. In some cases, the node members of a blockchain subnet can be completely identical to those of the main blockchain. In this case, all blockchain members can access data from both the main blockchain and the blockchain subnet, but the data generated by the main blockchain and the blockchain subnet can still be isolated from each other. For example, one type of business can be implemented on the main blockchain and another type of business can be implemented on the blockchain subnet, thus ensuring that the business data generated by these two types of businesses are isolated from each other.

[0052] In addition to the node member identity information mentioned above, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the blockchain subnet administrator, and attribute configurations for the blockchain platform code, etc., which are not limited in this specification. The network identifier is used to uniquely identify the blockchain subnet; therefore, the network identifier of the blockchain subnet should be distinct from the blockchain mainnet and other blockchain subnets built on the blockchain mainnet. The identity information of the blockchain subnet administrator may, for example, be the public key of the node member acting as the administrator; the administrators of the blockchain mainnet and the blockchain subnet may be the same or different.

[0053] One advantage of building blockchain subnets via the mainnet is that since the mainnet node is already deployed on the node device that generates the subnet node, the blockchain platform code used by the mainnet node can be reused on the subnet node, eliminating the need for repeated deployment of the blockchain platform code and greatly improving the efficiency of building the blockchain subnet. Therefore, if the configuration information does not include attribute configurations for the blockchain platform code, the subnet node can reuse the attribute configurations used on the mainnet node; if the configuration information includes attribute configurations for the blockchain platform code, the subnet node can adopt those attribute configurations, making the attribute configurations used by the subnet node independent of the mainnet node's attribute configurations. Attribute configurations for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., but this specification does not impose any restrictions on these.

[0054] Transactions for building a blockchain subnet include transactions that invoke contracts. These transactions may specify the address of the invoked smart contract, the method of invocation, and the parameters passed in. For example, the invoked contract may be the aforementioned genesis contract or system contract, the invoked method may be the method for building a blockchain subnet, and the passed parameters may include the aforementioned configuration information. In one embodiment, the transaction may include the following information:

[0055] From: Administrator

[0056] To: Subnet

[0057] method: AddSubnet(string)

[0058] string:genesis

[0059] The `from` field contains information about the initiator of the transaction, such as `Administrator` indicating that the initiator is an administrator; the `to` field contains the address of the smart contract being called, such as the address of the Subnet contract; the `method` field contains the method being called, such as `AddSubnet(string)` in the Subnet contract, where `string` is a parameter in the `AddSubnet()` method. In the example above, `genesis` represents the value of this parameter, which is the aforementioned configuration information.

[0060] Taking the transaction executed by nodes nodeA to nodeE on mainnet0, which calls the AddSubnet() method in the Subnet contract, as an example. After the transaction passes consensus, nodes A to E execute the AddSubnet() method respectively, passing in the configuration information, and obtain the corresponding execution results.

[0061] After a node in a blockchain network executes a transaction that invokes a smart contract, it generates a corresponding receipt to record information related to the execution of that smart contract. This allows the system to retrieve information about the contract execution result by querying the transaction receipt. The contract execution result can be represented as an event within the receipt. The messaging mechanism can use these events to transmit messages, triggering corresponding processing by blockchain nodes. An event's structure could be, for example:

[0062] Event:

[0063] [topic][data]

[0064] [topic][data] ......

[0066] In the example above, there can be one or more events; each event includes fields such as topic and data. Blockchain nodes can listen to the topic of an event, and if a predefined topic is detected, they can perform pre-defined processing, or read relevant content from the data field of the corresponding event, and perform pre-defined processing based on the read content.

[0067] In the event mechanism described above, it's equivalent to having a client with listening capabilities on the listening party (e.g., a user with listening needs). This client might run an SDK (Software Development Kit) to implement the listening function, allowing it to listen for events generated by the blockchain node. The blockchain node only needs to generate receipts normally. Besides the event mechanism, transaction information can be revealed in other ways. For example, listening code can be embedded in the blockchain platform code running on the blockchain node. This listening code can monitor one or more types of data, such as the transaction content of blockchain transactions, the contract status of smart contracts, and receipts generated by contracts, and send the monitored data to a predefined listening party. Because the listening code is deployed in the blockchain platform code, rather than on the listening party's client, this listening code-based implementation is more proactive than the event mechanism. The listening code can be added to the blockchain platform code by the blockchain platform developers during development, or it can be embedded by the listening party based on its own needs; this specification does not impose any restrictions on this.

[0068] As can be seen, the execution result of the aforementioned Subnet contract can include the configuration information. This execution result can be contained in the receipt mentioned above, which may include events related to the execution of the AddSubnet() method, i.e., networking events. The topic of a networking event can contain a predefined networking event identifier to distinguish it from other events. For example, in an event related to the execution of the AddSubnet() method, the topic content is the keyword "subnet," and this keyword is different from the topics in events generated by other methods. Then, by listening to the topics contained in each event in the generated receipt, nodes A through E can determine that they have listened to an event related to the execution of the AddSubnet() method, i.e., a networking event, if they listen to a topic containing the keyword "subnet." For example, the events in the receipt are as follows:

[0069] Event:

[0070] [topic:other][data]

[0071] [topic:subnet][data]

[0072] So, when nodes A through E detect the first event, since its topic content is "other," they determine that the event is unrelated to the `AddSubnet()` method. Similarly, when nodes A through E detect the second event, since its topic content is "subnet," they determine that the event is related to the `AddSubnet()` method. They then read the corresponding `data` field, which contains the aforementioned configuration information. For example, if the configuration information includes the public keys of the blockchain subnet's node members, the content of the `data` field might include:

[0073] {subnet1;

[0074] The public key of nodeA, the IP address of nodeA, the port number of nodeA, etc.;

[0075] The public key of nodeB, the IP address of nodeB, the port number of nodeB, etc.;

[0076] The public key of nodeC, the IP address of nodeC, the port number of nodeC, etc.;

[0077] The public key of nodeD, the IP address of nodeD, the port number of nodeD, etc.;

[0078] }

[0079] Here, subnet1 is the network identifier of the blockchain subnet to be created. Each blockchain node in the mainnet can record the network identifiers of all blockchain subnets already created on that mainnet, or other information related to these subnets. This information can be maintained, for example, in the aforementioned Subnet contract, specifically corresponding to the values ​​of one or more contract states contained within that Subnet contract. Then, nodes A through E can determine whether subnet1 already exists based on the recorded network identifiers of all created blockchain subnets. If it does not exist, it means subnet1 is the new blockchain subnet to be created; if it exists, it means subnet1 already exists.

[0080] In addition to using the network identifier of the new blockchain subnet to be created, a predefined new network identifier can also be used. This new network identifier indicates that the corresponding networking event is used to form a new blockchain subnet. For example, subnet1 can be replaced with newsubnet, which is a predefined new network identifier. When nodeA to nodeE recognize that the data field contains newsubnet, they can determine that the event containing newsubnet is a networking event and a new blockchain subnet needs to be created.

[0081] Besides the network identifier subnet1, the aforementioned data field also includes identity information for each node member. The node device deploying the mainnet node can listen to the generated receipts, and if it detects the networking event and the content of the networking event indicates that the mainnet node belongs to the node member, the node device deploying the mainnet node can obtain the configuration information or genesis block contained in the networking event. Alternatively, the mainnet node can listen to the generated receipts, and if it detects the networking event and the content of the networking event indicates that the mainnet node itself belongs to the node member, it can trigger the node device deploying the mainnet node to obtain the configuration information or genesis block contained in the networking event.

[0082] As mentioned earlier, node devices can directly monitor receipts. Assuming nodes A through E are deployed on nodes 1 through 5 respectively, and nodes 1 through 5 can monitor receipts generated by nodes A through E, then if they detect that subnet 1 is a newly formed blockchain subnet, nodes 1 through 5 can further identify the identity information of the node members contained in the data field to determine their own processing method. Taking node A and node 1 as an example: if node 1 finds that the data field contains identity information such as node A's public key, IP address, and port number, then node 1, having obtained the configuration information from the data field based on the aforementioned message mechanism, can generate a genesis block containing this configuration information, and then deploy node A1 locally. Node A1 then loads the generated genesis block to become a subnet node of subnet 1. Similarly, node 2 can generate node B1, node 3 can generate node C1, and node 4 can generate node D1. Furthermore, if node device 5 finds that the identity information contained in the data field does not match its own, then node device 5 will not generate the genesis block based on the configuration information in the data field, nor will it generate a blockchain node in subnet1.

[0083] As mentioned earlier, blockchain nodes in the mainnet can listen to receipts and trigger relevant processing based on the listening results. For example, if nodes A through E determine that subnet1 is a newly formed blockchain subnet, they will further identify the identity information of the node members contained in the data field to determine their own processing method. For instance, nodes A through D will find their own identity information, such as public key, IP address, and port number, in the data field. Assuming nodes A through D are deployed on node devices 1 through 4 respectively, taking node A and node device 1 as an example: node A will trigger node device 1, causing node device 1 to obtain configuration information from the data field based on the aforementioned message mechanism and generate a genesis block containing this configuration information. Node device 1 will also deploy node A1 locally, which loads the generated genesis block, thus becoming a subnet node in subnet1. Similarly, node B will trigger node device 2 to generate node B1, node C will trigger node device 3 to generate node C1, and node D will trigger node device 4 to generate node D1. Furthermore, nodeE will find that the identity information contained in the data field does not match its own. Assuming that nodeE is deployed on node device 5, then node device 5 will not generate the genesis block based on the configuration information in the data field, nor will it generate nodes in subnet1.

[0084] As mentioned earlier, the first mainnet node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information pre-generated for nodeA1 to nodeD1, and be different from the identity information of nodeA to nodeD. Taking nodeA and node device 1 as an example: if node device 1 finds nodeA1's identity information in the data field, it can generate a genesis block, deploy nodeA1, and have nodeA1 load the genesis block; or, if nodeA finds nodeA1's identity information in the data field, then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and have nodeA1 load the genesis block. The processing methods for other blockchain nodes or node devices are similar, and will not be elaborated here.

[0085] In addition to configuration information, the execution result of a contract can include a genesis block. In other words, besides including configuration information in the data field, a genesis block containing configuration information can also be generated directly during the execution of the contract call, thus including the genesis block in the data field. For the aforementioned nodes A to D, the corresponding node devices 1 to 4 can directly obtain the genesis block from the data field through the message mechanism without having to generate it themselves, which can improve the deployment efficiency of nodes A1 to D1.

[0086] A node device deploys a blockchain node by creating an instance running the blockchain platform code within a process. For a mainnet node, the node device creates a first instance within the aforementioned process, and this first instance runs the blockchain platform code. Similarly, for a subnet node, the node device creates a second instance, distinct from the first instance, within the aforementioned process, and this second instance runs the blockchain platform code. For example, a node device can first create a first instance within the process to form a mainnet node in the blockchain mainnet; when a node member corresponding to that node device wishes to participate in building a blockchain subnet, it can create a second instance within the aforementioned process. This second instance is distinct from the first instance and forms a subnet node within the blockchain subnet. When the first instance and the second instance reside in the same process, since cross-process interaction is not involved, the deployment difficulty of the subnet node can be reduced and the deployment efficiency improved. Of course, the second instance may also reside in different processes on the node device than the first instance, and this specification does not impose any restrictions on this. For example, the node device can create the first instance in the first process to form a mainnet node in the blockchain mainnet. When the node member corresponding to the node device wants to participate in the formation of the blockchain subnet, it can start a second process that is different from the first process and create a second instance in the second process. This second instance is different from the first instance mentioned above, and thus forms a subnet node in the blockchain subnet. In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on the node device. The blocks generated by each blockchain node deployed on the node device can be stored in different storage (e.g., database) on the node device, and the storage used by each blockchain node deployed on any node device is isolated from each other.

[0087] Using the methods described above, blockchain subnets managed by the mainnet can be created on the mainnet. Figure 1For example, for mainnet0 containing nodes A through E, subnet1 can be created based on mainnet0. Subnet1 contains nodes A1 through D1, and any subnet node in subnet1 and its corresponding mainnet node in mainnet0 are deployed on the same node device. For example, node A and node A1 are deployed on node device 1, node B and node B1 are deployed on node device 2, node C and node C1 are deployed on node device 3, and node D and node D1 are deployed on node device 4. Similarly, subnet2 or more blockchain subnets can be created on mainnet0, where subnet2 contains nodes A2, B2, C2, and E2, and node A is deployed on the same node device as node A1, node A2, node B is deployed on the same node device as node B1, node B2, node C is deployed on the same node device as node C1, node D is deployed on the same node device as node D1, and node E is deployed on the same node device as node E2. Furthermore, subnets such as subnet1 and subnet2 can be used as the main blockchain network, and further subnets can be created on top of them. For example, a subnet subnet1.1 can be created based on subnet1. The process is similar to the creation of subnet1 or subnet2, except that the main blockchain network is replaced by the subnet subnet1. This will not be elaborated further here. As shown in the figure, node device 1 deploys the main network node nodeA and subnet nodes nodeA1 and nodeA2; node devices 2 and 3 are similar to node device 1 and will not be elaborated further; node device 4 deploys the main network node nodeD and subnet node nodeD1; and node device 5 deploys the main network node nodeE and subnet node nodeE2.

[0088] Besides selecting node members through transactions on the mainnet to create a subnet, other methods can be used to create subnets and subject them to the management of the mainnet. For example, a subnet can be created on the mainnet through registration (hereinafter referred to as registration networking). This allows an existing blockchain network to be directly registered with the mainnet, making the newly registered network a subnet of the mainnet. Through a registration-based network approach, the subnet information of the blockchain subnet to be built is directly registered to the main blockchain network. This allows the main blockchain network to acquire relevant information about the subnet (by receiving and executing transactions from the subnet to be built, which associate its identity information with the subnet identifier assigned to that subnet). This information includes the subnet identifier and its operational status, as well as the public keys and plugin configuration information of each node member, and the IP addresses and port information of each node device. This information is written into the contract status of the corresponding system contract on the main blockchain network. Thus, the main blockchain network gains management rights over the subnet. After registration, the subnet is considered complete. Because the registration-based network approach does not require specifying node members on the main blockchain network through transactions, the subnet nodes in a subnet built through this method can be completely or partially different from the node devices deployed on the main blockchain network. For example… Figure 1 In mainnet0, a subnet3 was created using a registration networking method. Figure 1 (Not shown in the image) Assuming that the mainnet nodes nodeA to nodeE contained in mainnet0 are deployed on node devices 1 to 5 respectively, then the subnet nodes corresponding to subnet3 can be deployed on any other node device other than node devices 1 to 5. Alternatively, one or more subnet nodes in subnet3 can be deployed on any node device among node devices 1 to 5 (but it is still necessary to ensure that only one subnet node of subnet4 is deployed on each node device), while the other subnet nodes in subnet3 can be deployed on any other node device other than node devices 1 to 5. Of course, the subnet nodes in subnet4 can also all be deployed on node devices 1 to 5, which will not be elaborated further.

[0089] Cross-chain interaction can be achieved between any two blockchain networks within the blockchain mainnet and blockchain subnet created in the above manner. Taking nodeC belonging to mainnet0 and nodeC1 belonging to subnet1 as an example, ... Figure 1As can be seen, both are deployed on node device 3. nodeC and nodeC1 are specifically blockchain node instances (hereinafter referred to as blockchain nodes) formed by running blockchain platform code in a virtual machine deployed locally on node device 3. The data related to nodeC during its operation is stored in the mainnet database corresponding to nodeC, while the data related to nodeC1 during its operation is stored in the subnet database corresponding to nodeC1. Both the mainnet database and the subnet database belong to the storage space of node device 3. In addition, blockchain consensus code can be deployed on node device 3. By running this consensus code, node device 3 can form a consensus component instance locally. Furthermore, P2P component code managed in the form of plugins can also be deployed on the node device. By running this P2P component code, the node device can form a P2P component instance locally, i.e., a P2P plugin. A P2P plugin deployed on any node device can be shared and used by different blockchain nodes on that node device. For example, nodeC and nodeC1 on node device 3 can call the same P2P plugin running on node device 3 to share its functionality and data. Node device 3 can also deploy blockchain business code. By running the blockchain business code, node device 3 can form a business instance locally. Node device 3 can implement at least one business instance, such as a storage instance for implementing data read / write functions, a computing instance for implementing privacy computing and other computing functions, an encryption instance for implementing data encryption functions, etc., which will not be elaborated further.

[0090] In the embodiments described in this specification, the mainnet nodes and subnet nodes on the same node device share the blockchain communication plugin running on that node device, such as the aforementioned P2P plugin. Specifically, the network connection link established when forming mainnet0 can be established by nodeC and nodeE using the P2P plugins on node devices 3 and 5, respectively. Since the P2P plugin on a node device can be shared by all blockchain nodes on that node device, nodeC1 in subnet1 can establish a network connection with the P2P plugin running on node device 5 (to which nodeE2 belongs) by calling the P2P plugin running locally on node device 3, leveraging the P2P plugin-based network connection between node devices 3 and 5 established when forming mainnet0. This allows cross-chain messages to be sent to node device 5, further enabling network communication with nodeE2. This method eliminates the need to establish a new network connection link between the source blockchain network and the destination blockchain network; instead, it utilizes the pre-established network connection link on the underlying blockchain mainnet to achieve network communication between the source node in the source blockchain network and the destination node in the destination blockchain network.

[0091] To meet the need for archiving blockchain data, related technologies typically involve operations and maintenance personnel manually archiving the blockchain data stored locally on each blockchain node. However, this approach requires operations and maintenance personnel to manually perform off-chain archiving operations on each node. Therefore, not only is the archiving operation inefficient, but the process is also untraceable, meaning there is no way to record the archiving process, posing a significant security risk.

[0092] To address the aforementioned technical problems in related technologies, this specification proposes a data archiving method that achieves on-chain archiving of blockchain data by executing blockchain transactions. The following detailed description of this solution is provided in conjunction with the accompanying drawings.

[0093] Figure 2 This is a flowchart of a data archiving method proposed in an embodiment of this specification. Figure 2 As can be seen, the method is applied to the first blockchain node in the first blockchain network. The node device where the first blockchain node is located also has a second blockchain node in the second blockchain network deployed. The first blockchain network is managed by the second blockchain network. The method includes steps 202-206.

[0094] Step 202: Obtain the data archiving event generated by the second blockchain node executing the data archiving transaction. The data archiving event includes node indication information and data indication information.

[0095] In this scheme, the first blockchain node in the first blockchain network and the second blockchain node in the second blockchain network are deployed on the same node device. The first blockchain network is managed by the second blockchain network. Therefore, the first blockchain network is a blockchain subnet, and the first blockchain node is a subnet node within that subnet; the second blockchain network is the blockchain mainnet, and the second blockchain node is a mainnet node within that mainnet. This scheme can be applied to the aforementioned first blockchain node. In fact, the first blockchain node can be any subnet node within the first blockchain network. For clarity, the following embodiments use the first blockchain network as an example. Figure 1 The subent1, the first blockchain node is nodeA1, and the second blockchain network is... Figure 1 The following explanation uses mainent0 and the second blockchain node, nodeA, as an example.

[0096] In this scheme, the data archiving transaction can be initiated by the administrator or maintenance personnel of the second blockchain network, or it can be initiated by an ordinary user corresponding to any blockchain node in the second blockchain network. Specifically, the data archiving transaction can be initiated through any mainnet node in the second blockchain network.

[0097] Each blockchain node in the second blockchain network can generate a data archiving event by executing the data archiving transaction. This event includes node indication information and data indication information. This data is used to determine the blockchain subnet requiring archiving (hereinafter referred to as the subnet to be archived), the subnet nodes within that subnet requiring archiving (hereinafter referred to as the nodes to be archived), and the data to be archived. The node indication information can be the subnet identifier of the subnet to be archived and the node identifier of the nodes to be archived, indicating which subnet nodes within which blockchain subnet will perform the archiving operation. The data indication information can be the data identifier of the data to be archived, indicating which blockchain data will be archived. The subnet identifier and node identifier can be specific identifiers or identifier ranges. For example, if the subnet identifier field is "all", it indicates that all blockchain subnets managed by the main blockchain network are the subnets to be archived. Conversely, if the node identifier field for a given blockchain subnet is "all", it indicates that all subnet nodes within that blockchain subnet are the nodes to be archived. The data to be archived, indicated by the data identifier, is blockchain data maintained by the first blockchain node itself. This data is generated by the first blockchain node during its participation in blockchain transactions within the first blockchain network and can be stored in the local storage space of the node device where the first blockchain node resides. Specifically, the node identifier can be node identity information such as the node's public key. The aforementioned data identifier can be a block height range, storage address range, data index information, etc., which will not be elaborated further. In addition, the data archiving event may also include the storage address of the archived data (i.e., the storage address corresponding to the second access path below), so that the archived data is stored in the corresponding storage space according to this storage address.

[0098] In one embodiment, the node indication information and data indication information in the data archiving event can indicate a fixed object, used to achieve a one-time archiving process for the data to be archived. Figure 1 For example, the data archiving events generated by the mainnet nodes in mainent0 when executing data archiving transactions may include the subnet identifier of subnet1, the node identifiers of nodeA1 and nodeB1 in subnet1, and the block height range of 0 to 10000. This information is used to indicate that nodeA1 and nodeB1 in subnet1 need to perform archiving processing on blocks with block heights in the range of 1 to 10000. Clearly, in response to the above data archiving events, nodeA1 and nodeB1 can perform archiving processing on the aforementioned blocks respectively.

[0099] In another embodiment, the node indication information and data indication information in the data archiving event can also indicate non-fixed objects, and the event can also include periodic archiving times to enable periodic multiple archiving of the data to be archived. Still using... Figure 1 For example, in the data archiving events generated by the data archiving transactions executed by each mainnet node in mainnet0, the values ​​of its subnet identifier field and node identifier field can both be "all", and the value of the data identifier field can be "black_new_all". Additionally, the archiving interval can be 7 days. In response to these data archiving events, each subnet node in subnet1 and subnet2 can periodically archive the blocks it maintains at 7-day intervals. For instance, after the first archiving of blocks with heights between 0 and 1000, if the block height reaches 1200 after 7 days, a second archiving can be performed on newly added blocks with heights between 1001 and 1200 after 7 days. Of course, after adding other blockchain subnets to mainnet0, the subnet nodes in those subnets can also periodically archive the blocks they maintain according to the above information, which will not be elaborated further. In this way, the blockchain mainnet can control the first blockchain node in the first blockchain network to periodically archive newly added blocks through data archiving events, without having to execute the data archiving transaction multiple times, which helps to improve the management efficiency of archiving processing.

[0100] It is understood that node indication information and node indication information included in the data archiving transaction can be recorded in the data archiving transaction. Based on this, when the second blockchain node executes the transaction, it can determine whether to generate the data archiving event based on the status of the data archiving event node indicated by the node indication information. For example, during the execution of the data archiving transaction, the second blockchain node can determine the node to be archived in the subnet to be archived based on the node indication information, and generate the data archiving event only if it is determined that the first blockchain node is in a running state. As mentioned above, the blockchain mainnet is used to manage the corresponding blockchain subnets, and the mainnet nodes of the mainnet can maintain the subnet status information of each subnet and the node status information of the corresponding subnet nodes in each subnet. Accordingly, the second blockchain node can first query the status of the subnet to be archived based on the subnet status information maintained locally: if it is determined that the subnet to be archived is in a running state, it can further query the status of the node to be archived in the node status information corresponding to the subnet; if it is determined that the node to be archived is in a running state, the data archiving event can be generated. Of course, if the node indication information indicates multiple nodes to be archived, and if it is determined through the above method that some of these nodes are in a running state, the data archiving event can still be generated normally, allowing these nodes to archive the data they maintain. However, if it is determined through the above method that all nodes to be archived are in a non-running state, the second blockchain node can refuse to generate the data archiving event—since none of the nodes can perform archiving, generating the data archiving event is meaningless. Therefore, the first blockchain node being in a running state indicates that both the first blockchain node and the first blockchain network it belongs to are running. Through the above method, the second blockchain node can determine that the first blockchain node is in a running state when generating the data archiving event, meaning it can respond normally to the event. Generating the event in this case can, to some extent, ensure that the event's production is meaningful, and that the generated event can be successfully executed and responded to by the first blockchain node.

[0101] In one embodiment, the first blockchain node can obtain the data archiving event generated by the second blockchain node executing a data archiving transaction through various methods. As mentioned above, blockchain networks typically support event listening mechanisms, so the first blockchain node can utilize this mechanism to listen for the data archiving event. It is understood that because various blockchain nodes in the second blockchain network can generate the same data archiving event by executing the same data archiving transaction, the data archiving event actually listened to by the first blockchain node can be generated by any blockchain node in the second blockchain network executing a data archiving transaction, and is not limited to the second blockchain node deployed on the same node device as the first blockchain node. This embodiment of the specification does not impose such limitations. Through the aforementioned event listening mechanism, the generation and response processes of the data archiving event can be asynchronously implemented, which helps improve the overall processing efficiency of blockchain transactions for both the first and second blockchain networks. Alternatively, to minimize the time consumed by the first blockchain node in obtaining the data archiving event, the second blockchain node can also proactively send the data archiving event it generates to the first blockchain node. For example, after generating the data archiving event, the second blockchain node can determine whether the first blockchain node deployed on its own node device is the aforementioned node to be archived, based on the node indication information contained therein. If the first blockchain node is indeed the node to be archived, the second blockchain node will send the data archiving event to that node. In this way, the second blockchain node can send the event specifically to the first blockchain node upon generating the data archiving event, so that the latter can respond to the event and perform archiving processing as soon as possible. Alternatively, the second blockchain node can send the event only if it is certain that the first blockchain network is operational, to maximize the chances that the event can be successfully executed and responded to by the first blockchain node.

[0102] Step 204: If the node indication information indicates that the first blockchain node is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data.

[0103] As mentioned earlier, the node indication information can be the identity information of the node to be archived. Therefore, if the node indication information includes its own identity information, the first blockchain node can determine that it is the node to be archived, that is, it needs to archive the data it maintains. The node identity information of the first blockchain node can be its public key or its node identifier in the first blockchain network, etc., which will not be elaborated further.

[0104] Step 206: Update the locally maintained first access path to the second access path. The first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0105] In the above embodiment, the second blockchain node in the second blockchain network executes a data archiving transaction to generate a data archiving event containing node indication information and data indication information. The first blockchain node in the first blockchain network responds to the event. If the node indication information indicates that the first blockchain node is a node to be archived, the node performs archiving processing on the data to be archived indicated by the data indication information to obtain archived data, and updates the locally maintained first access path for accessing the data to be archived to a second access path for accessing the archived data.

[0106] Understandably, because the first blockchain network is managed by the second blockchain network, the first blockchain network is a subnet, and the nodes within it are subnet nodes. Correspondingly, the second blockchain network is the mainnet, and the nodes within it are mainnet nodes. Through this method, the mainnet nodes can control the corresponding subnet nodes to archive the data they maintain by executing data archiving transactions. In other words, the mainnet can control specific blockchain nodes within a subnet to perform targeted archiving of specific blockchain data. Furthermore, updating the access address of the data to be archived to the access address of the archived data also facilitates normal access to the archived data by subnet nodes, thereby ensuring the normal operation of the archived blockchain subnet. In this method, centralized control of subnet data archiving is achieved through transactions executed by the mainnet nodes. On the one hand, it eliminates the need for maintenance personnel to perform off-chain archiving operations on the node devices of each subnet node, greatly improving the efficiency of blockchain data archiving. On the other hand, the operation records of the aforementioned data archiving transactions are stored in the blockchain mainnet, so the data archiving process is traceable, achieving accurate recording and reliable storage of the archiving process, and effectively improving the security of the blockchain data archiving process.

[0107] Upon receiving the data archiving event, the first blockchain node can determine the node to be archived based on the node indication information contained therein. If it determines itself to be the node to be archived, it responds to the event by archiving the data to be archived as indicated by the data indication information to obtain the archived data. As mentioned earlier, the first and second blockchain nodes are essentially node instances running node code. These two instances can run in the same process or different processes created by the node device. It is understood that the two node instances are run by different threads. In this scenario, if the first blockchain node is run by the first thread in its own process, the first blockchain node can create a second thread within that process, distinct from the first thread, and trigger this second thread to archive the data to be archived as indicated by the data execution information. In this way, the archiving process of the first blockchain node is implemented by the second thread, while the first thread implements the original node functions of the first blockchain node (such as executing blockchain transactions and transaction consensus). The archiving process of the first blockchain node is separated from the original node functions, which effectively avoids the interference that the archiving process described in this solution may cause to the original node functions of the first blockchain node, and ensures that the first blockchain node has high operational stability during the archiving process.

[0108] In the embodiments of this specification, the data to be archived can be blocks maintained by the first blockchain node, and any block can contain blockchain transactions and transaction receipts; alternatively, the data to be archived can also contain state data or other types of data maintained by the first blockchain node, which will not be elaborated further. Taking a block as an example, the data indication information can include a block height range. Obviously, each block whose block height is within this block height range is the data to be archived. At this time, the first blockchain node can perform archiving processing on the above-mentioned blocks. The process of archiving the above-mentioned blocks can include packaging, compressing, and generating archived data from each block.

[0109] It should be noted that the data indication information described in the embodiments of this specification can indicate the corresponding data to be archived for each node to be archived. As mentioned above, the data indication information can indicate the same data to be archived for each node to be archived, such that each node to be archived can archive the corresponding blocks it maintains according to the above-mentioned block height range. Alternatively, the data indication information can also indicate different data to be archived for each node to be archived. (Continuing with...) Figure 1For example, in the case where the first blockchain network is subnet1 and the nodes to be archived are nodeA1 and nodeB1 in subnet0, the data indication information in the data archiving event can indicate that the block height range for nodeA1 is H1 to H2, and the block height range for nodeB1 is H3 to H4. Based on this information, nodeA1 can archive the blocks it maintains with block heights between H1 and H2 to obtain the corresponding archived data, and nodeB1 can archive the blocks it maintains with block heights between H3 and H4 to obtain the corresponding archived data. Through this method, data archiving transactions can specify the corresponding data to be archived for each node to be archived, enabling differentiated archiving processing for each node and helping to meet the personalized archiving needs of different subnet nodes.

[0110] In one embodiment, the first blockchain node can perform the above-mentioned archiving process using snapshots to generate archived data. For example, the first blockchain node can determine the data to be archived from the historical data it maintains locally based on the data indication information, then generate a data snapshot of the data to be archived at the snapshot time, and generate archived data based on the data snapshot. The historical data maintained locally by the first blockchain node can be all the blockchain data generated by the first blockchain node during its participation in blockchain transactions within the first blockchain network. Considering that the historical data generated by the first blockchain node is usually large in volume, determining the data to be archived first and then generating targeted data snapshots helps avoid ineffective processing and improves snapshot efficiency. For example, if the data to be archived indicated by the data indication information is a block, the first blockchain node can generate a data snapshot for the current block without having to generate a data snapshot for its own maintained state data. Furthermore, various technologies can be used to generate data snapshots, such as clone snapshots, splitmirror snapshots, copy-on-write (COW) snapshots, and redirect-on-write (ROW) snapshots, etc., which can be found in the relevant technical documentation and will not be elaborated here.

[0111] Taking historical data as a block as an example, such as Figure 3 As shown, over time, the first blockchain node generates blocks sequentially (along the timeline in the diagram). At a snapshot time (corresponding to the current block), the first blockchain node can generate a data snapshot of each historical block already generated at that time, and generate the corresponding archived data based on this data snapshot. Of course, after the snapshot time, the first blockchain node may generate a new block (i.e., the latest block).

[0112] In fact, the reason for archiving the data maintained by the first blockchain node itself is mainly because the first blockchain node has a relatively weak demand for the data to be archived, while the data to be archived occupies a large amount of high-efficiency storage space in the node device where the first blockchain node is located, resulting in low storage space utilization of the node device. Therefore, data with low access frequency among the data maintained by the first blockchain node should be archived (i.e., the data to be archived should be data with low access frequency), while data with high access frequency should be avoided from being archived as much as possible. However, since the initiator of the data archiving transaction may not know which data in the first blockchain node is hot data and which is not, the data to be archived indicated by the data indication information in the data archiving event may contain data that is frequently accessed by the first blockchain node. In this case, the first blockchain node should avoid archiving this part of the data. For example, the first blockchain node can determine the hot data (corresponding to the data with high access frequency) in the data snapshot based on the access records of the data to be archived, and generate the archived data based on the non-hot data (corresponding to the data with low access frequency) in the data snapshot other than the hot data. In this way, the first blockchain node can archive only non-hot data with low access frequency, while avoiding archiving hot data with high access frequency. This effectively avoids the problem of frequent access to archived data that may result from archiving hot data, and effectively realizes the practical significance of archiving.

[0113] After the archiving process is completed, in addition to updating the access path, the first blockchain node can also delete the data to be archived to reclaim the storage space occupied by it. Furthermore, since the data snapshot is an intermediate step in the archiving process, it can also be deleted after the archiving process is complete. Of course, both the data to be archived and the data snapshot can be deleted. However, because the first blockchain node needs to frequently access some historical data corresponding to the hot data, it can retain a portion of the historical data corresponding to the hot data so that the first blockchain node can continue to access it later.

[0114] Taking historical data as an example, combined with Figure 4 The above archiving process will be explained. For example... Figure 4As shown, the first blockchain node can determine the data to be archived from all historical blocks before the current block based on the data indication information. For example, if the block height range specified by the data indication information is H(1) to H(n), then the first blockchain node can determine that each block with a blockchain height of H(1), H(2), ..., H(n) is the data to be archived, and thus the first blockchain node can generate a data snapshot for the aforementioned data to be archived. Taking the use of cloning snapshot technology as an example, the data snapshot generated for the data to be archived is equivalent to a copy of the data to be archived. At this time, the first blockchain node can determine the hot data and non-hot data in the data snapshot based on the access records of the aforementioned data to be archived. Let's assume that the block height of the hot data is H(n-1) to H(n), and the block height of the non-hot data is H(1) to H(n-2). At this time, the first blockchain node can generate archived data for the aforementioned non-hot data. The archiving process performed by the first blockchain node on the hot data may include compression and archiving. Compression may employ pruning (to reduce the number of parameters and computational load) and quantization (to compress the data size). Archiving may be performed by mixing various non-hot data using a dump (such as mongodump) method and outputting them to a file, which can then be used as the archived data.

[0115] After the above archiving process is completed, the first blockchain node can update the first access path maintained locally for accessing the data to be archived to the second access path for users to access the archived data. It is understood that, in the case of performing the aforementioned archiving process on non-hot data, the first access path is used to access the portion of historical data corresponding to the non-hot data, while the storage space and access path of the portion of historical data corresponding to the hot data are unaffected. Figure 4 As shown, before the path update, the first blockchain node can read blocks with block heights of H(1) to H(n-2) through the first access path; after the path update, the first blockchain node can read the archived data through the second access path, while the aforementioned blocks are deleted from the storage space corresponding to the first access path, and the first blockchain node naturally cannot continue to access them. For blocks with block heights of H(n-1) to H(n), the path update does not affect these blocks; therefore, before and after the path update, the first blockchain node can read these blocks through the corresponding access address.

[0116] In one embodiment, the first blockchain node can update the path by restarting. For example, the first blockchain node can pause the blockchain transaction it is processing and restart the first blockchain node to update the locally maintained first access path to the second access path. The first blockchain node can trigger its own restart in response to a received restart command. This command can be issued by the administrator of the first or second blockchain network, by a regular user corresponding to the first blockchain node, or by the maintenance personnel of the node device where the first blockchain node is located. This embodiment of the specification does not limit this. In this way, after the archiving process of the first blockchain node is completed, the aforementioned personnel can choose a suitable time (such as the early morning when there are fewer blockchain transactions in the first blockchain network) to trigger the first blockchain node to restart, thereby avoiding interruption of the first blockchain node's normal processing of blockchain transactions in the first blockchain network.

[0117] Considering that after the first blockchain node obtains the archived data through the archiving process, it also needs to update the access path of the data to be archived to the access path of the archived data, the first blockchain node may be unable to participate in the processing of blockchain transactions in the first blockchain network during the access path update process (such as the aforementioned restart). Especially when the proportion of nodes to be archived in the first blockchain network is large, or even when all subnet nodes are nodes to be archived, if all nodes to be archived perform archiving and path update processing simultaneously or separately within a short period, it may cause the first blockchain network to be unable to process blockchain transactions normally for a period of time, or even result in operational accidents. To avoid the occurrence of the above-mentioned unexpected situations, the data archiving event can assign a corresponding processing time to each node to be archived, so as to control each node to complete the above-mentioned archiving process and path update within its corresponding processing time. For example, the data archiving event also includes an archiving time. The first blockchain node receiving the data archiving event can perform archiving processing on the data to be archived indicated by the data indication information according to the archiving time. The archiving times for different nodes to be archived should be as different as possible, and the archiving times can take into account the time required for archiving processing. In this way, the data archiving transaction can control each node to be archived in the first blockchain network to perform archiving processing at the corresponding archiving time, thereby minimizing the adverse impact on the performance of the first blockchain network that a large number of nodes to be archived may perform archiving processing at the same time or in a short period of time.

[0118] Furthermore, it is understood that the nodes in the first blockchain network may have different types to perform different functions, such as consensus nodes for data consensus and transaction execution nodes for executing blockchain transactions. To address this, the data archiving events can be designed to distribute the archiving times of different nodes of the same type more evenly, to avoid a large number of nodes of the same type performing archiving simultaneously or within a short period. This ensures that at any given time, a sufficient number of nodes of the same type can participate in processing the corresponding type of blockchain transaction, thereby improving the operational stability of the first blockchain network.

[0119] In the embodiments of this specification, the first access path points to the first local storage space in the node device where the first blockchain node is located; while the second access path points to a second local storage space in the node device where the first blockchain node is located, which is different from the first local storage space. The second local storage space can be a storage space with high read / write performance in the node device, such as the local database corresponding to the first blockchain node. In this way, data to be archived stored in high-performance storage space can be transferred to low-performance storage space (as archived data) for storage, thereby ensuring the normal operation of the first blockchain node (i.e., the first blockchain node can still access the archived data normally according to the updated second access address) while saving high-performance storage space in the node device. Alternatively, the second access path can also point to other storage spaces outside the node device where the first blockchain node is located. In this way, data to be archived stored in the local storage space of the node device can be transferred to a storage space outside the node device for storage, thereby ensuring the normal operation of the first blockchain node while saving local storage space in the node device.

[0120] In addition, considering that the first blockchain node may not be able to participate in the blockchain transactions of the first blockchain network during the path update process, and that other nodes in the first blockchain network may generate the latest data during the path update (such as a restart), in order to ensure that the first blockchain node can continue to participate in the blockchain transactions of the first blockchain network after the path update, the first blockchain node can synchronize the latest data generated after the snapshot time from other nodes in the first blockchain network.

[0121] This concludes the description of the data archiving scheme presented in this paper. As seen from the foregoing embodiments, this data archiving scheme is implemented based on a blockchain mainnet and blockchain subnet scenario. In fact, this specification also proposes a data archiving scheme based on any blockchain network, which will be described below with reference to the accompanying drawings.

[0122] Figure 5 This is a flowchart illustrating another data archiving method provided in an exemplary embodiment. For example... Figure 5 As shown, this method is applied to any blockchain node in a blockchain network, and the method may include the following steps:

[0123] Step 502: Execute the data archiving transaction to obtain node indication information and data indication information.

[0124] Step 504: If the node indication information indicates that any of the blockchain nodes is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data.

[0125] Step 506: Update the locally maintained first access path to the second access path. The first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0126] First, it should be noted that the blockchain network described in this solution can be any blockchain network. For example, the blockchain network can be an independent blockchain network that neither manages nor is managed by other blockchain networks, such as... Figure 1 The example shown is mainnet1. For instance, this blockchain network can also be a non-independent blockchain network, which can manage other blockchain networks, such as... Figure 1 The mainnet0 shown can also be managed by other blockchain networks, such as... Figure 1 The subnet1 or subnet2 shown.

[0127] and Figure 1 The difference in this scheme is that the data archiving transactions are executed by the blockchain nodes within the blockchain network itself, and the nodes to be archived within these nodes respond to the data archiving event by archiving the data they maintain. For example, in the case of the blockchain network being mainnet1, nodes F to H in this network can execute the data archiving transaction to generate a data archiving event, and nodes E, F, and / or G can respond to this event as nodes to be archived and perform archiving processing. As another example, in the case of the blockchain network being mainnet0, nodes A to E in this network can execute the data archiving transaction to generate a data archiving event, and at least one node can respond to this event as a node to be archived and perform archiving processing. Yet another example, in the case of the blockchain network being subnet1, nodes A1 to D1 in this network can execute the data archiving transaction to generate a data archiving event, and at least one node can respond to this event as a node to be archived and perform archiving processing; these scenarios will not be elaborated further.

[0128] In one embodiment, any blockchain node may determine itself as a node to be archived if the node indication information includes the identity information of the first blockchain node.

[0129] In one embodiment, the data archiving transaction includes an archiving time, at which point any blockchain node can archive the data to be archived as indicated by the data indication information according to the archiving time.

[0130] In one embodiment, any blockchain node is run by a first thread. At this time, any blockchain node can create a second thread in its own process and trigger the second thread to archive the data to be archived as indicated by the data indication information.

[0131] In one embodiment, the data indication information includes a block height range, at which point any blockchain node can archive blocks whose block heights are within the block height range.

[0132] The individual can determine the data to be archived from the historical data maintained locally based on the data indication information, then generate a data snapshot of the data to be archived at the snapshot time, and generate archived data based on the data snapshot.

[0133] In one embodiment, any blockchain node can determine the hot data in the data snapshot based on the access records of the data to be archived, and generate archived data based on the non-hot data in the data snapshot other than the hot data. Subsequently, a portion of the historical data corresponding to the hot data can also be retained.

[0134] In one embodiment, any of the blockchain nodes may also delete the data to be archived and / or the data snapshot.

[0135] In one embodiment, after updating the locally maintained first access path to the second access path, any blockchain node can also synchronize the latest data generated after the snapshot time from other nodes in the blockchain network.

[0136] In one embodiment, any blockchain node can update its path by restarting. For example, any blockchain node can pause the blockchain transaction it is processing and then restart the node to update the locally maintained first access path to the second access path.

[0137] In one embodiment, the first access path points to a first local storage space in the node device where any blockchain node is located; the second access path points to a second local storage space in the node device that is different from the first local storage space; or, the second access path points to other storage spaces outside the node device.

[0138] For detailed implementation methods of the above embodiments, please refer to [link / reference]. Figure 1 The descriptions of the corresponding embodiments will not be repeated here.

[0139] In this scheme, any blockchain node in the blockchain network executes a data archiving transaction to obtain node indication information and data indication information. Then, if the node indication information indicates that the blockchain node is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data, and the locally maintained first access path for accessing the data to be archived is updated to a second access path for accessing the archived data.

[0140] It is understandable that any blockchain node in the blockchain network can archive data to be archived by executing data archiving transactions, enabling centralized control over data archiving. Furthermore, updating the access address of the data to be archived to the access address of the archived data also helps any blockchain node to access the archived data normally, thus ensuring the normal operation of the blockchain network after archiving. Therefore, on the one hand, maintenance personnel do not need to perform off-chain archiving operations on the node devices of each data archiving node, greatly improving the efficiency of blockchain data archiving; on the other hand, the execution records of the aforementioned data archiving transactions are stored in the blockchain network, making the data archiving process traceable, achieving accurate recording and reliable evidence storage of the archiving process, and effectively improving the security of the blockchain data archiving process.

[0141] Figure 6 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 6 At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, memory 608, and non-volatile memory 610, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into memory 608 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0142] like Figure 7 As shown, Figure 7 This is a block diagram of a data archiving apparatus provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 6 The device shown is used to implement the technical solution of this specification. This device is applied to a first blockchain node in a first blockchain network. The node device where the first blockchain node is located also deploys a second blockchain node in a second blockchain network. The first blockchain network is managed by the second blockchain network. The device includes:

[0143] The event acquisition unit 701 is used to acquire the data archiving event generated by the second blockchain node executing the data archiving transaction. The data archiving event includes node indication information and data indication information.

[0144] The data archiving unit 702 is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that the first blockchain node is the node to be archived;

[0145] The path update unit 703 is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0146] Optionally, the data archiving unit 702 is further configured to:

[0147] Listen for data archiving events generated by the second blockchain node executing data archiving transactions; or...

[0148] The data archiving event is received from the second blockchain node in response to the node indication information indicating that the first blockchain node is the node to be archived.

[0149] Optionally, the data archiving event is sent by the second blockchain node after determining that the first blockchain network is in operation.

[0150] Optionally, the node indication information indicating that the first blockchain node is a node to be archived includes:

[0151] The node indication information includes the identity information of the first blockchain node.

[0152] Optionally, the data archiving event further includes the archiving time, and the data archiving unit 702 is further configured to:

[0153] According to the stated archiving time, the data to be archived as indicated by the data indication information is archived.

[0154] Optionally, the first blockchain node is run by the first thread, and the data archiving unit 702 is further used for:

[0155] A second thread is created within the process of the first blockchain node, and the second thread is triggered to archive the data to be archived as indicated by the data indication information.

[0156] Optionally, the data indication information includes a block height range, and the data archiving unit 702 is further configured to:

[0157] Archive each block whose block height is within the specified block height range.

[0158] Optionally, the data archiving unit 702 is further configured to:

[0159] Based on the data indication information, determine the data to be archived from the locally maintained historical data;

[0160] At the snapshot time, a data snapshot is generated on the data to be archived, and archived data is generated based on the data snapshot.

[0161] Optional,

[0162] The data archiving unit 702 is further configured to: determine the hot data in the data snapshot based on the access records of the data to be archived, and generate archived data based on the non-hot data in the data snapshot other than the hot data;

[0163] The device also includes a data retention unit 704, used to retain a portion of the historical data corresponding to the hot data.

[0164] Optional, also includes:

[0165] The data deletion unit 705 is used to delete the data to be archived and / or the data snapshot.

[0166] Optional, also includes:

[0167] The data synchronization unit 706 is used to synchronize the latest data generated after the snapshot time from other nodes in the first blockchain network after the first access path maintained locally is updated to the second access path.

[0168] Optionally, the path update unit 703 is further configured to:

[0169] Suspend ongoing blockchain transactions;

[0170] Restart the first blockchain node to update the locally maintained first access path to the second access path.

[0171] Optional,

[0172] The first access path points to the first local storage space in the node device where the first blockchain node is located;

[0173] The second access path points to a second local storage space in the node device where the first blockchain node is located, which is different from the first local storage space; or, the second access path points to other storage spaces outside the node device where the first blockchain node is located.

[0174] like Figure 8 As shown, Figure 8 This is a block diagram of another data archiving apparatus provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 6 The device shown is used to implement the technical solution described in this specification. This device is applied to any blockchain node in a blockchain network, and the device includes:

[0175] The transaction execution unit 801 is used to execute data archiving transactions to obtain node indication information and data indication information;

[0176] The data archiving unit 802 is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that any blockchain node is a node to be archived, and to obtain archived data.

[0177] The path update unit 803 is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

[0178] Optionally, the data indication information includes a block height range, and the data archiving unit 802 is further configured to:

[0179] Archive each block whose block height is within the specified block height range.

[0180] Optionally, the data archiving unit 802 is further configured to:

[0181] Based on the data indication information, determine the data to be archived from the locally maintained historical data;

[0182] At the snapshot time, a data snapshot is generated on the data to be archived, and archived data is generated based on the data snapshot.

[0183] Optional, also includes:

[0184] The data synchronization unit 804 is used to synchronize the latest data generated after the snapshot time from other nodes in the blockchain network after updating the locally maintained first access path to the second access path.

[0185] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0186] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0187] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0188] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0189] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0190] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0191] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0192] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0193] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A data archiving method, applied to a first blockchain node in a first blockchain network, wherein a second blockchain node in a second blockchain network is also deployed in the node device where the first blockchain node is located, and the first blockchain network is managed by the second blockchain network, the method comprising: Obtain the data archiving event generated by the second blockchain node executing the data archiving transaction, wherein the data archiving event includes node indication information and data indication information; When the node indication information indicates that the first blockchain node is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data, including: determining the data to be archived in the locally maintained historical data according to the data indication information, generating a data snapshot of the data to be archived at the snapshot time, and generating archived data based on the data snapshot; The locally maintained first access path is updated to the second access path, and the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

2. The method according to claim 1, wherein obtaining the data archiving event generated by the second blockchain node executing the data archiving transaction includes: Listen for data archiving events generated by the second blockchain node executing data archiving transactions; or, The data archiving event is received from the second blockchain node in response to the node indication information indicating that the first blockchain node is the node to be archived.

3. The method according to claim 2, wherein the data archiving event is sent by the second blockchain node when it is determined that the first blockchain network is in operation.

4. The method according to claim 1, wherein the node indication information indicates that the first blockchain node is a node to be archived, comprising: The node indication information includes the identity information of the first blockchain node.

5. The method according to claim 1, wherein the data archiving event further includes an archiving time, and the archiving process for the data to be archived indicated by the data indication information includes: According to the stated archiving time, the data to be archived as indicated by the data indication information is archived.

6. The method according to claim 1, wherein the first blockchain node is run by a first thread, and the archiving process of the data to be archived indicated by the data indication information includes: A second thread is created within the process of the first blockchain node, and the second thread is triggered to archive the data to be archived as indicated by the data indication information.

7. The method according to claim 1, wherein the data indication information includes a block height range, and the archiving process for the data to be archived indicated by the data indication information includes: Archive each block whose block height is within the specified block height range.

8. The method according to claim 1, The process of generating archived data based on the data snapshot includes: Based on the access records of the data to be archived, hot data in the data snapshot is determined, and archived data is generated based on the non-hot data in the data snapshot other than the hot data. The method further includes: retaining a portion of the historical data corresponding to the hotspot data.

9. The method according to claim 1, further comprising: Delete the data to be archived and / or the data snapshot.

10. The method according to claim 1, further comprising: After updating the locally maintained first access path to the second access path, the latest data generated after the snapshot time is synchronized from other nodes in the first blockchain network.

11. The method according to claim 1, wherein updating the locally maintained first access path to the second access path comprises: Suspend ongoing blockchain transactions; Restart the first blockchain node to update the locally maintained first access path to the second access path.

12. The method according to claim 1, The first access path points to the first local storage space in the node device where the first blockchain node is located; The second access path points to a second local storage space in the node device where the first blockchain node is located, which is different from the first local storage space; or, the second access path points to other storage spaces outside the node device where the first blockchain node is located.

13. A data archiving method, applied to any blockchain node in a blockchain network, the method comprising: Execute data archiving transactions to obtain node indication information and data indication information; When the node indication information indicates that any of the blockchain nodes is a node to be archived, the data to be archived indicated by the data indication information is archived to obtain archived data, including: determining the data to be archived in the locally maintained historical data according to the data indication information, generating a data snapshot of the data to be archived at the snapshot time, and generating archived data based on the data snapshot; The locally maintained first access path is updated to the second access path, and the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

14. The method according to claim 13, wherein the data indication information includes a block height range, and the archiving process of the data to be archived indicated by the data indication information to obtain archived data includes: Archive each block whose block height is within the specified block height range.

15. The method of claim 13, further comprising: After updating the locally maintained first access path to the second access path, the latest data generated after the snapshot time is synchronized from other nodes in the blockchain network.

16. A data archiving device, applied to a first blockchain node in a first blockchain network, wherein a second blockchain node in a second blockchain network is also deployed in the node device where the first blockchain node is located, and the first blockchain network is managed by the second blockchain network, the device comprising: An event acquisition unit is used to acquire data archiving events generated by the second blockchain node executing data archiving transactions. The data archiving events include node indication information and data indication information. A data archiving unit is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that the first blockchain node is the node to be archived. The data archiving unit includes: determining the data to be archived in the locally maintained historical data according to the data indication information, generating a data snapshot of the data to be archived at the snapshot time, and generating the archived data based on the data snapshot. The path update unit is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

17. A data archiving device, applied to any blockchain node in a blockchain network, the device comprising: The transaction execution unit is used to execute data archiving transactions in order to obtain node indication information and data indication information; A data archiving unit is used to archive the data to be archived indicated by the data indication information when the node indication information indicates that any blockchain node is a node to be archived, and to obtain archived data, including: determining the data to be archived in the locally maintained historical data according to the data indication information, generating a data snapshot of the data to be archived at the snapshot time, and generating archived data based on the data snapshot; The path update unit is used to update the locally maintained first access path to a second access path, wherein the first access path and the second access path are used to access the data to be archived and the archived data, respectively.

18. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-15 by executing the executable instructions.

19. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-15.

Images