CN116663068A

CN116663068A - Alliance chain archiving method, related device and medium

Info

Publication number: CN116663068A
Application number: CN202310951849.6A
Authority: CN
Inventors: 刘汉卿; 王宗友; 廖志勇; 朱耿良; 时一防; 黄杨峻; 刘区城; 聂凯轩
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-07-31
Filing date: 2023-07-31
Publication date: 2023-08-29
Anticipated expiration: 2043-07-31
Also published as: CN116663068B

Abstract

The present disclosure provides a federated chain archiving method, related apparatus, and medium. The alliance chain archiving method comprises the following steps: determining a target block to be archived on a block chain maintained by a target consensus node; generating a first number of target sub-blocks based on the target block; distributing a first number of target sub-blocks to individual consensus nodes in the federated chain consensus network for archiving and deleting target blocks from the blockchain; and responding to a recovery request for acquiring the target block, requesting target sub-blocks from each consensus node, and if a second number of target sub-blocks are received, recovering the second number of first sub-blocks based on the second number of target sub-blocks so as to combine the target block. According to the embodiment of the disclosure, the influence caused by the centralization of the archiving nodes in the alliance chain consensus network can be relieved, and the security of archiving block recovery is improved. The embodiment of the disclosure can be applied to various scenes such as alliance chains, structured information processing, security technology and the like.

Description

Alliance chain archiving method, related device and medium

Technical Field

The present disclosure relates to the field of blockchains, and in particular, to a federated chain archiving method, related apparatus, and medium.

Background

Currently, blockchain networks face the problem of data explosion. Each consensus node maintains a large number of blocks, but not every block is accessed frequently, so archive nodes are provided in the prior art. The archive node maintains a full volume block. Each consensus node may determine some blocks that are accessed less frequently and delete them. Once needed, it is recovered from the archiving node. In this way, the occupation of the storage space of the consensus node is reduced.

There are a large number of archiving nodes on the public-link consensus network. The total number of the consensus nodes on the alliance chain consensus network is small, the admission limit exists, and a large number of archiving nodes are not required to be maintained. Federated chain consensus networks often have only a small number of archive nodes, very "centralised". Once a small number of archive nodes are down, the archive blocks cannot be restored.

Disclosure of Invention

The embodiment of the disclosure provides a alliance chain archiving method, a related device and a medium, which can relieve the influence caused by the centralization of archiving nodes in an alliance chain consensus network and improve the security of archiving block recovery.

According to an aspect of the present disclosure, there is provided a federation chain archiving method applied to a target consensus node among a plurality of consensus nodes of a federation chain consensus network, the federation chain archiving method including:

Determining a target block to be archived on a blockchain maintained by the target consensus node;

generating a first number of target sub-blocks based on the target block, wherein the first number of target sub-blocks comprises a second number of first sub-blocks into which the target block is divided, the first number being greater than the second number;

distributing a first number of said target sub-blocks to each of said consensus nodes in said federated chain consensus network for archiving and deleting said target blocks from said blockchain;

and responding to a recovery request for acquiring the target block, requesting the target sub-blocks from each consensus node, and recovering a second number of the first sub-blocks based on the second number of the target sub-blocks if the second number of the target sub-blocks are received, so as to combine the target block.

According to an aspect of the present disclosure, there is provided a federated chain archive apparatus located at a target consensus node among a plurality of consensus nodes of a federated chain consensus network, the federated chain archive apparatus comprising:

a first determining unit, configured to determine a target block to be archived on a blockchain maintained by the target consensus node;

A first generation unit, configured to generate a first number of target sub-blocks based on the target block, where the first number of target sub-blocks includes a second number of first sub-blocks into which the target block is divided, and the first number is greater than the second number;

a distribution unit for distributing a first number of said target sub-blocks to each of said consensus nodes in said federated chain consensus network for archiving and deleting said target blocks from said blockchain;

and the request unit is used for responding to a recovery request for acquiring the target block, requesting the target subblocks to each consensus node, and recovering a second number of first subblocks based on the second number of target subblocks if the second number of target subblocks are received, so as to combine the target block.

Optionally, the first generating unit is specifically configured to:

dividing the target block into a second number of the first sub-blocks to form a first sub-block vector;

acquiring a first weight matrix, wherein the first weight matrix is provided with the first number of rows and the second number of columns, and the first second number of rows of the first weight matrix form an identity matrix;

Multiplying the first weight matrix with the first sub-block vector to obtain a target sub-block vector, wherein the target sub-block vector comprises a first number of target sub-blocks.

Optionally, the request unit is specifically configured to:

generating a second sub-block vector based on a second number of the target sub-blocks;

acquiring a second number of rows multiplied by a second number of the target sub-blocks as a second weight matrix from the first number of rows of the first weight matrix when the first weight matrix is multiplied by the first sub-block vector;

and recovering the first sub-block vector based on the second sub-block vector and the second weight matrix, and acquiring a second number of the first sub-blocks from the first sub-block vector.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federation chain archive apparatus further comprises: a fourth calling unit, configured to call a start interface of an archive contract on the blockchain, generate an archive index, and record the first weight matrix corresponding to the archive index into the archive contract;

the first generation unit is specifically configured to: acquiring the first weight matrix corresponding to the archiving index in the archiving contract based on the archiving index;

The request unit is further configured to, before obtaining, from the first number of rows of the first weight matrix, a second number of rows multiplied by a second number of the target sub-blocks when the first weight matrix is multiplied by the first sub-block vector, as a second weight matrix: and acquiring the first weight matrix corresponding to the archiving index in the archiving contract according to the archiving index.

Optionally, the target block is a plurality of continuous target blocks, and the first generating unit is specifically configured to:

a consecutive plurality of said target blocks are allocated to each of said consensus nodes, such that a first number of target sub-blocks are generated by each of said consensus nodes based on said target blocks to which said consensus nodes are allocated.

Optionally, the first generating unit is further specifically configured to:

for each target block, determining a first remainder of modulo operation between a first identification sequence number of the target block and a third number, wherein the third number is a number of common nodes of the alliance chain common-knowledge network when the target sub-block is distributed;

and distributing the target block to the consensus node with the second identification sequence number corresponding to the first remainder.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federation chain archive apparatus further comprises: a first calling unit, configured to call a start interface of an archive contract on the blockchain, where an archive index, a start block identifier and an end block identifier of a plurality of consecutive target blocks are recorded correspondingly in the archive contract;

the request unit is specifically configured to: acquiring the archiving index; and based on the archiving index, acquiring the starting block identifier and the ending block identifier corresponding to the archiving index in the archiving contract, taking a block between the starting block identifier and the ending block identifier as the target block, and generating a recovery request of the target block.

Optionally, the distribution unit is specifically configured to:

determining a second remainder of modulo operation of a third identification sequence number of the target sub-block and a third number for each target sub-block, wherein the third number is the number of common nodes of the alliance chain common-knowledge network when the target sub-block is distributed;

and distributing the target sub-block to the consensus node with the second identification sequence number corresponding to the second remainder for archiving.

Optionally, before requesting the target sub-block from each of the consensus nodes in response to a recovery request to acquire the target block, the coalition chain archive device further includes:

an identifying unit, configured to identify availability of a third number of the consensus nodes;

a second determining unit, configured to determine a first ratio of the number of available consensus nodes in a third number of the consensus nodes to the third number;

and the restoring unit is used for requesting the target subblocks from each consensus node in the alliance chain consensus network if the first ratio is determined to be lower than a first threshold value, restoring the second number of the first subblocks based on the received second number of the target subblocks, thereby combining the target blocks, and returning to the step of generating the first number of target subblocks based on the target blocks.

Optionally, the recovery unit is specifically configured to:

determining a second ratio of the second number to the first number;

and adding a ratio redundancy amount on the basis of the second ratio to obtain the first threshold.

Optionally, the identification unit is specifically configured to:

invoking a query interface of an archive contract on the blockchain to query a federation chain management contract to determine consensus nodes in the federation chain consensus network when a recovery request for the target block is obtained;

And acquiring the intersection of a third number of the consensus nodes and the consensus nodes in the alliance chain consensus network when acquiring the recovery request of the target block as the available consensus nodes.

Optionally, the recovery unit is specifically configured to:

if the first ratio is determined to be lower than a first threshold, setting, through the query interface, a repartition mark in the archive contract to a first value, wherein the first value indicates that the target sub-block needs to be regenerated for the target block;

querying the repartition mark in the archive contract to request the target sub-blocks from each of the consensus nodes in the federated chain consensus network when the repartition mark is the first value.

Optionally, the repartition mark is recorded in the archive contract corresponding to an archive index;

the recovery unit is also specifically configured to:

generating inquiry transaction every preset period, and determining a third remainder of modular operation of the abstract value of the inquiry transaction and the total number of files;

and calling the query interface by taking the third remainder as the archiving index, and querying the repartition mark corresponding to the archiving index in the archiving contract.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federation chain archive apparatus further comprises: a second calling unit, configured to call a start interface of an archive contract on the blockchain, determine each of the consensus nodes, the third number, and the first threshold in the federated chain consensus network, and record the respective consensus nodes, the third number, and the first threshold in the archive contract in correspondence with an archive index;

the identification unit is also specifically configured to: identifying availability of each of the consensus nodes in the archive contract corresponding to the archive index;

the second determining unit is further specifically configured to: determining a first ratio of the number of available consensus nodes to the third number corresponding to the archive index in the archive contract;

the recovery unit is also specifically configured to: and determining that the first ratio is lower than the first threshold corresponding to the archiving index in the archiving contract.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federation chain archive apparatus further comprises: a fifth calling unit, configured to call the state update interface of the archive contract on the blockchain, and set a first state flag in the archive contract to a first waiting state;

After distributing the first number of the target sub-blocks to each of the consensus nodes in the federated chain consensus network for archiving and deleting the target block from the blockchain, the fifth invoking unit is further configured to: invoking the state update interface of the archive contract on the blockchain to place a first state flag in the archive contract into an archive complete state;

after requesting the target sub-block from each of the consensus nodes in response to a recovery request to acquire the target block, the fifth invoking unit is further configured to: invoking the state update interface of the archive contract on the blockchain to place a first state flag in the archive contract into a recovery state.

Optionally, the federated chain consensus network further comprises an archiving node, wherein the archiving node archives the blocks to be recorded on the blockchain after a plurality of the consensus nodes have completed consensus on the blocks;

after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive apparatus further comprises: a third calling unit, configured to call a state update interface in an archive contract on the blockchain, and set a second state flag in the archive contract to a second waiting state; determining that the archiving node is successful in response to the second waiting state becoming a confirmation state, wherein the confirmation state is set by the archiving node after detecting the integrity of the target block on the blockchain and detecting success after recognizing that the second state flag becomes the second waiting state;

The request unit is further specifically configured to: and requesting the target block from the archiving node, and requesting the target sub-block from each consensus node when the request fails.

Optionally, the archiving node is a plurality of archiving nodes, the archiving contract records a target archiving node bound with the target consensus node, the target archiving node belongs to the plurality of archiving nodes, and the confirmation state is set by the target archiving node;

the request unit is further specifically configured to:

querying the target archive node of the archive contract record;

requesting the target block from the target archiving node.

Optionally, the first determining unit is specifically configured to:

determining the access frequency of each block on a block chain maintained by the target consensus node;

acquiring importance of each block on a block chain maintained by the target consensus node;

and determining a target block to be archived based on the access frequency and the importance.

According to an aspect of the present disclosure, there is provided an electronic device including a memory storing a computer program and a processor implementing a federation chain archiving method as described above when executing the computer program.

According to an aspect of the present disclosure, there is provided a computer-readable storage medium storing a computer program which, when executed by a processor, implements a federation chain archiving method as described above.

According to an aspect of the present disclosure, there is provided a computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the federated chain archiving method as described above.

In the embodiment of the disclosure, when the target block on the blockchain needs to be filed, the target block is divided into a plurality of sub-blocks and distributed to all consensus nodes in the alliance chain consensus network. Because the consensus nodes in the federated chain consensus network are not always fixed, sometimes with the consensus nodes being authorized to join and leave, when the target block needs to be restored, the consensus nodes in the federated chain consensus network may not have been those consensus nodes when each sub-block was distributed. Thus, some of the sub-blocks are extended on the basis of the second number of sub-blocks into which the target block is divided, so that not only the second number of sub-blocks but also the first number of target sub-blocks are generated in total. The first number is greater than the second number. Even if the target blocks need to be restored, the consensus nodes in the alliance chain consensus network are not completely the distributed sub-blocks, but only the second number of target sub-blocks can be correctly restored from the first number of target sub-blocks distributed at the beginning, so that the tolerance of exiting the consensus nodes which participate in the distribution at the beginning is improved. The method does not rely on archiving the archiving nodes in the alliance chain consensus network, thereby alleviating the influence caused by the centralization of the archiving nodes in the alliance chain consensus network. Even when the archiving node is down, the target block is divided into the sub-blocks to be backed up to each consensus node in the embodiment of the present disclosure, and the target block can still be restored when the target block needs to be restored, and the expansion of the second number into the first number of sub-blocks perfectly relieves the influence caused by the possible exit of the consensus nodes in the federation chain consensus network, so that the security of the archiving block restoration is greatly improved.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the disclosure. The objectives and other advantages of the disclosure will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings are included to provide a further understanding of the disclosed embodiments and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain, without limitation, the disclosed embodiments.

FIG. 1 is a schematic architecture diagram of a federated chain consensus network to which embodiments of the present disclosure are applied;

2A-2B are schematic diagrams of a federated chain archiving method applied in a block archiving scenario, in accordance with an embodiment of the present disclosure;

FIG. 3 is a flow chart of a federated chain archiving method in accordance with one embodiment of the present disclosure;

FIG. 4 is a flowchart of a particular implementation of invoking an archive contract, according to an embodiment of the present disclosure;

FIG. 5 is a flowchart of one implementation of step 320 of FIG. 3;

FIG. 6 is a flow chart of one implementation of step 510 of FIG. 5;

FIG. 7 is a schematic diagram of one embodiment of the allocation target block of FIG. 6 implemented using modulo arithmetic;

FIG. 8 is a flow chart of another implementation of step 320 in FIG. 3;

9A-9C are schematic illustrations of an implementation of the first number of target sub-blocks of FIG. 8 generated using a first weight matrix;

FIG. 10 is a flowchart of one implementation of step 330 of FIG. 3;

FIG. 11A is a schematic diagram of one particular implementation of the distribution target sub-block of FIG. 10 using modulo arithmetic;

FIG. 11B is a schematic diagram of another particular implementation of the distribution target sub-block of FIG. 10 using modulo arithmetic;

FIG. 12 is a flow chart of a federated chain archiving method prior to step 340 in accordance with another embodiment of the present disclosure;

FIG. 13 is a schematic diagram of one embodiment of the determination of repartition block of FIG. 12 using availability;

FIG. 14 is a flowchart of a specific implementation of FIG. 12 with respect to a first threshold;

FIG. 15 is a flowchart showing one embodiment of step 1210 of FIG. 12;

FIG. 16 is a schematic diagram of one embodiment of FIG. 15;

FIG. 17 is a flow chart of one embodiment of step 1230 of FIG. 12;

FIG. 18 is a flowchart of one particular implementation of step 1720 of FIG. 17;

FIG. 19 is a flowchart of one implementation of step 340 of FIG. 3;

FIG. 20 is a schematic diagram of one embodiment of FIG. 19;

FIG. 21 is a schematic diagram of a particular implementation of requesting a target block with an archiving node, according to one embodiment of the present disclosure;

FIG. 22 is a schematic diagram of a particular implementation of requesting a target block with a target archiving node, according to one embodiment of the present disclosure;

FIG. 23 is a flowchart of another implementation of step 340 of FIG. 3;

24A-24C are schematic diagrams of particular implementations of FIG. 23 for generating a first number of target sub-blocks;

FIG. 25 is an implementation detail view of a federated chain archiving method of an embodiment of the present disclosure;

FIG. 26 is a block diagram of a federated chain archive apparatus, in accordance with an embodiment of the present disclosure;

FIG. 27 is a terminal block diagram of implementing the federated chain archiving method illustrated in FIG. 3 in accordance with an embodiment of the present disclosure;

FIG. 28 is a server block diagram implementing the federated chain archiving method illustrated in FIG. 3 in accordance with an embodiment of the present disclosure.

Detailed Description

In order to make the objects, technical solutions and advantages of the present disclosure more apparent, the present disclosure will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present disclosure.

In the embodiments of the present application, when related processing is performed according to data related to characteristics of a target object, such as attribute information or attribute information set of the target object, permission or consent of the target object is obtained first, and related laws and regulations and standards are complied with for collection, use, processing, etc. of the data. In addition, when the embodiment of the application needs to acquire the attribute information of the target object, the independent permission or independent consent of the target object is acquired through a popup window or a jump to a confirmation page or the like, and after the independent permission or independent consent of the target object is explicitly acquired, the necessary target object related data for enabling the embodiment of the application to normally operate is acquired.

Before proceeding to further detailed description of the disclosed embodiments, the terms and terms involved in the disclosed embodiments are described, which are applicable to the following explanation:

artificial intelligence: the system is a theory, a method, a technology and an application system which simulate, extend and extend human intelligence by using a digital computer or a machine controlled by the digital computer, sense environment, acquire knowledge and acquire a target result by using the knowledge. In other words, artificial intelligence is an integrated technology of computer science that attempts to understand the essence of intelligence and to produce a new intelligent machine that can react in a similar way to human intelligence. Artificial intelligence, i.e. research on design principles and implementation methods of various intelligent machines, enables the machines to have functions of sensing, reasoning and decision. The artificial intelligence technology is a comprehensive subject, and relates to the technology with wide fields, namely the technology with a hardware level and the technology with a software level. Artificial intelligence infrastructure technologies generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technologies, operation/interaction systems, mechatronics, and the like. The artificial intelligence software technology mainly comprises a computer vision technology, a voice processing technology, a natural language processing technology, machine learning/deep learning and other directions. With research and advancement of artificial intelligence technology, research and application of artificial intelligence technology is being developed in various fields, such as common smart home, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned, automatic driving, unmanned aerial vehicles, robots, smart medical treatment, smart customer service, etc., and it is believed that with the development of technology, artificial intelligence technology will be applied in more fields and with increasing importance value.

Blockchain: blockchains are novel application modes of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain is essentially a de-centralized database, which is a series of data blocks that are generated in association using cryptographic methods, each of which contains a batch of information for a transaction that verifies the validity (anti-counterfeit) of its information and associates with the previous block.

Alliance chain: a blockchain with authentication functions only the subject that gets permission can send transactions to the federation chain. In other words, each transaction needs to be signed with a key that obtains the permissions on the federation chain to ultimately be booted.

Consensus node: nodes in the blockchain participating in exiting blocks and verifying other blocks, and the consensus node needs to execute each transaction on the chain. The consensus nodes of the federation chain need to be authorized to join.

A block: the basic data structure in the block chain comprises basic information such as a block time stamp, a block hash and the like in one block, and a plurality of transactions which are arranged in sequence.

Intelligent contract: the figure is complete with code running on the blockchain, one transaction can call the intelligent contract, and the code called the intelligent contract is executed on all consensus nodes. In embodiments of the present disclosure, archive contracts, federation chain management contracts are involved.

Erasure coding technique: the method mainly comprises the steps of encoding original data through an erasure code algorithm to obtain redundancy, and storing the data and the redundancy together to achieve the purpose of fault tolerance. The basic idea is that n blocks of original data elements are calculated to obtain m blocks of redundant elements (check blocks). For the n+m block elements, when any m block element is in error (including original data and redundant data), the original n block data can be recovered through a corresponding reconstruction algorithm.

System architecture and scenario description applied to embodiments of the present disclosure

Referring to the federated chain consensus network shown in FIG. 1, the federated chain consensus network refers to a blockchain network for archiving blocks. The federated chain consensus network includes a consensus node, and an archive node. The consensus node refers to a node that performs consensus and uplink for a block. For example, consensus node 1 generates a chunk, sends the chunk to consensus node 2-5 for verification, and after verification passes, the consensus node 1-5 records the chunk onto the blockchain maintained by the consensus node 1-5, respectively. An archiving node refers to a node that archives a block. For example, after consensus node 1-5 records a block onto the blockchain, the archiving node synchronizes the block data from the blockchain, completing the block archiving.

The consensus node and the archive node are both federation chain nodes in the federation chain. The federation chain node can be a stand-alone device, such as a separate computer or server, or can be part of a stand-alone device, such as a virtual machine partitioned on a server. The specific form of the federation link node is not limited herein.

The embodiments of the present disclosure may be applied in a variety of scenarios, such as the scenario of block archiving shown in fig. 2A-2B, and the like.

Referring to fig. 2A, fig. 2A differs from fig. 1 in that fig. 2A also shows the blockchain maintained by consensus node 5, and the archived blocks recorded by archiving node 2. The blockchain maintained by consensus node 5 is made up of 5 blocks, including blocks 1-5. The archived blocks recorded by archive node 2 are also blocks 1-5.

With continued reference to FIG. 2A, consensus node 5 requests archiving blocks 1-4, the specific process of archiving blocks is as follows:

when there is a block archiving requirement, any consensus node can initiate an archiving request, record the starting height and ending height of the alliance chain archiving block in the archiving contract, and set the archiving state in the archiving contract to wait (Waiting).

The archive node has a separate process for checking the archive contract, and once the archive state is found to be waiting, the archive node checks the integrity of the block data in the storage from the start height to the end height of the archive block, and if the data is complete, sends a response to the consensus node so that the consensus node sets the archive state in the archive contract to confirm (comfixed).

The consensus node also has a separate process to check the archive contract and, once the state in the archive contract is found to change from Waiting to Comfirmed, begin deleting the block data from the archive start height to the archive end height in the blockchain.

Through the archiving process described above, the blockchain maintained by consensus node 5 deletes blocks 1-4, the remaining blocks 5.

Referring to fig. 2B, the difference from fig. 2A is that fig. 2B illustrates a process in which the consensus node 5 requests recovery blocks 1-4 from the archiving node 2. The specific process of block recovery is as follows:

when there is a block recovery requirement, any consensus node queries the starting height and the ending height of the block to be recovered from the archiving contract, and then can initiate a recovery request to the archiving node.

The archiving node finds the blocks from the starting height to the ending height of the blocks to be restored from the storage based on the restoration request and sends the blocks to the consensus node.

The consensus node completes block recovery based on the blocks received from the archiving node.

Through the restoration process described above, consensus node 5 obtains blocks 1-4 from archive node 2 such that the blockchain maintained by consensus node 5 includes blocks 1-5.

However, federated chain consensus networks often have only a small number of archive nodes, such as the federated chain consensus networks shown in FIGS. 2A-2B, with two archive nodes, very "centralized". Once both archive nodes are down, the archive blocks cannot be restored, and the restoration safety of the archive blocks is affected.

For the public chain, due to the fact that the total number of the nodes is large, even if most nodes do not store historical block data any more, a large number of total nodes store total data, and certain decentralization characteristics are reserved for the public chain. However, for a federated chain, because the total number of federated chain nodes is small and there is an admission threshold, in most cases, historical archive data will only be stored in a small number of archive nodes. In some cases, the federation chain stores historical archive data even in the form of centralized storage. When the remaining nodes of the federation chain need to recover historical archive data, data can only be recovered from a very small number of archive nodes. The "centralized store" and the centralized recovery "are contradictory to the decentralized nature of the blockchain. In this case, once a problem of single point data loss of the archive node is encountered, the federation chain is most likely unable to recover the historical archive data.

The embodiment of the disclosure hopes that the process of recovering the archived data by the consensus nodes in the coalition chain consensus network is not dependent on the archiving nodes any more through a data redundancy backup mode, so that the archived data of the coalition chain is subjected to centralized storage and decentralized recovery. Meanwhile, the embodiment of the disclosure also ensures that the alliance chain still has the capability of recovering the archived data after a certain proportion of nodes exit the alliance chain in consideration of the joining and exiting mechanism of the archived consensus nodes in the alliance chain consensus network.

General description of embodiments of the disclosure

According to one embodiment of the present disclosure, a federated chain archiving method is provided.

The federated chain archiving method is generally applied in archiving business scenarios with a small number of archiving nodes in a federated chain consensus network, such as the scenario of block archiving shown in FIGS. 2A-2B. The alliance chain archiving method provided by the embodiment of the invention can relieve the influence caused by the centralization of the archiving nodes in the alliance chain consensus network and improve the security of archiving block recovery. The alliance chain archiving method is applied to a target consensus node in a plurality of consensus nodes of an alliance chain consensus network. For example, in the federated chain consensus network shown in FIG. 1, the target consensus node is any one of consensus nodes 1-5.

As shown in fig. 3, a federated chain archiving method in accordance with one embodiment of the present disclosure may include:

step 310, determining a target block to be archived on a blockchain maintained by a target consensus node;

step 320, generating a first number of target sub-blocks based on the target block;

step 330, distributing the first number of target sub-blocks to each consensus node in the federated chain consensus network for archiving and deleting target blocks from the blockchain;

step 340, in response to the recovery request for obtaining the target block, the target sub-block is requested to each consensus node, and if the second number of target sub-blocks is received, the second number of first sub-blocks is recovered based on the second number of target sub-blocks, so as to combine the target block.

Steps 310-340 are described in detail below.

At step 310, a blockchain is made up of a plurality of blocks, with different blockchains maintained by different consensus nodes. Embodiments of the present disclosure are directed to blockchains maintained by target consensus nodes. The target block to be archived refers to a block that needs to be archived among a plurality of blocks on the blockchain. Note that if a block is determined to be the target block to archive, after successful archiving, the block will be deleted on the blockchain.

In some embodiments, the target block to be archived may be determined based on a block archiving request received by the target consensus node. In a specific implementation of this embodiment, the target consensus node receives a block archiving request sent by a target object, extracts a start block identifier and an end block identifier from the block archiving request, and obtains a block between the start block identifier and the end block identifier from the blockchain, thereby obtaining a target block to be archived.

The benefit of this embodiment is that the accuracy of determining target blocks can be improved by determining which blocks need to be archived with a block archiving request of the target object.

In another embodiment, the target consensus node does not receive a block archiving request, but may determine the target blocks to archive by determining the access frequency and importance of each block on the blockchain.

In this embodiment, step 310 specifically includes:

determining the access frequency of each block on a block chain maintained by a target consensus node;

acquiring importance of each block on a block chain maintained by a target consensus node;

based on the access frequency and importance, a target block to be archived is determined.

In this embodiment, the access frequency refers to the frequency with which the target consensus node accesses a block after recording the block to the blockchain. The lower the access frequency of a block, the more the block should be the target block to be archived. For example, the blockchain includes 5 blocks, block 1, block 2, block 3, block 4, and block 5, respectively. After determining the access frequency of blocks 1-5, the access frequency of block 1 was 0.01 times/day, the access frequency of block 2 was 0.03 times/day, the access frequency of block 3 was 0.02 times/day, the access frequency of block 4 was 0.05 times/day, and the access frequency of block 5 was 2 times/day. By comparing the access frequencies of blocks 1-5, blocks 1-4 should be determined as target blocks to be archived as compared to block 5.

In this embodiment, importance is used to characterize the importance of a block. The lower the importance of a block, the more that block should be the target block to be archived. It should be noted that, one block typically stores a plurality of transactions, and these transactions may be classified into important type transactions and non-important type transactions. Important types of transactions have high requirements on data security, such as invoice reimbursement transactions. The importance of the block in which invoice reimbursement transactions are stored is 0.9. Non-critical type transactions have lower requirements on data security, such as weather information transactions. The importance of the block in which invoice reimbursement transactions are stored is 0.1.

After determining the access frequency and the importance, determining the target block to be archived based on the access frequency and the importance specifically includes:

determining a first score of the block according to the access frequency;

determining a second score of the block according to the importance;

determining a total score of the block according to the first score and the second score;

a target block to archive is determined based on the total score of the blocks.

In this embodiment, the first score of the block is determined according to the access frequency, and the access frequency range and the first score may be searched for in a table, or a formula method may be used.

(1) And searching the access frequency range and the first score comparison table according to the access frequency, so as to obtain a first score. An example of an access frequency versus first score table is as follows:

TABLE 1

For example, a range frequency of a certain block is 5 times/day, and look up table 1, the corresponding first score is 80.

The method for searching the range frequency and the first score comparison table has the advantages of simplicity, easiness, and low processing cost.

(2) When using the formula, the first score may be set to be proportional to the range frequency, for example:

f1 =k1·g1 equation 1

Wherein F1 represents a first fraction, G1 represents a range frequency, and K1 is a preset constant, which can be set according to actual needs. For example, k1=16, and g1=5 is substituted, and the first score f1=80.

The method for determining the first score through the formula has the advantages of high accuracy, and the formula can be adjusted according to the requirement, so that the flexibility is high.

The second score of the block may be determined according to the importance, by looking up a table of the importance and the second score, or by using a formula method.

(1) And searching an importance range and a second score comparison table according to the importance, and obtaining a second score. An example of a table of importance ranges versus first score is as follows:

TABLE 2

For example, the importance of a block is 0.8, and the lookup table 2 yields a corresponding second score of 90.

The method for searching the importance range and the second score comparison table has the advantages of simplicity, easiness, and low processing cost.

(2) When the formula is used, the second score may be set to be proportional to the importance, for example:

f2 =k2·g2 formula 2

Wherein F2 represents a second score, G2 represents importance, and K2 is a preset constant, which can be set according to actual needs. For example, k2=112.5, and g2=0.8 is substituted, and the second score f2=90.

The mode of determining the second score through the formula has the advantages of high accuracy, and the formula can be adjusted according to the requirement, so that the flexibility is high.

The total score of the block is determined based on the first score and the second score, and may be calculated by calculating an average or weighted average of the first score and the second score.

When the average of the first score and the second score is calculated as the total score, for example, the first score of the block is 80 and the second score is 90, the total score is (80+90)/2=85. The advantage of using the average to calculate the total score of the first transaction is that the impact of the access frequency and importance on the block as the target block to be archived can be equally reflected.

When calculating the weighted average of the first score and the second score as the total score, for example, weights of 0.6 and 0.4 are set for the access frequency and importance, respectively, the first score of the block is 80, and the second score is 90, the total score is 80×0.6+90×0.4=84. The advantage of using a weighted average to calculate the total score is that different weights can be set for the access frequency and importance, improving the flexibility of determining the target block to be archived.

The target block to be archived is determined based on the total score of the blocks, and the block with the total score greater than the score threshold value can be used as the target block to be archived, or the block with the total score arranged in the first several bits can be used as the target block to be archived.

The embodiment for determining the target block by using the access frequency and the importance degree has the advantages that the archiving requirements and the security requirements of different blocks are met according to the access frequency and the importance degree, and the flexibility and the security of data archiving are improved.

It should be noted that, after the target consensus node determines the target block to be archived, an archiving contract may be invoked to record some parameters of the current archiving task. The archiving contract includes a startup interface, a status update interface, and a query interface. The start-up interface refers to an interface for starting a new archiving task. The status update interface refers to an interface for updating the status of an archiving task. The query interface refers to an interface for querying parameters of an archiving task.

In an embodiment, referring to fig. 4, after step 310, the federated chain archiving method of an embodiment of the present disclosure further includes:

step 410, calling a starting interface of an archiving contract on a blockchain, generating an archiving index and a first weight matrix corresponding to the archiving index, and recording the archiving index into the archiving contract;

step 420, calling an initiation interface of an archive contract on a blockchain, and correspondingly recording an archive index, a start block identifier and an end block identifier of a plurality of continuous target blocks in the archive contract;

step 430, calling an initiation interface of an archive contract on the blockchain, determining each consensus node, a third number and a first threshold in the coalition chain consensus network, and recording the first threshold in the archive contract corresponding to the archive index;

step 440, call the status update interface of the archive contract on the blockchain, and set the first status flag in the archive contract to the first waiting status.

Steps 410-440 are described in detail below.

In step 410, the archive index refers to an index of one archive task, and the corresponding archive task can be found according to the archive index. The first weight matrix refers to a matrix for generating a first number of target sub-blocks based on the target block. Referring to table 3, an archive index (archieveld) and a first weight Matrix (Matrix) are recorded into an archive contract.

In step 420, the archive index here is the same as in step 410. The start block identification refers to a block identification of a first target block of the consecutive plurality of target blocks. The ending block identifier refers to a block identifier of a last target block of the consecutive plurality of target blocks. With continued reference to Table 3, an archive index (ArchiveID), a Start block identification (Start), and an End block identification (End) are recorded in the archive contract accordingly.

At step 430, individual consensus nodes in the federated chain consensus network are determined, which is equivalent to determining the consensus nodes in the federated chain consensus network that are involved in the archive. The third number refers to the number of consensus nodes participating in the archive. The first threshold, which refers to a previously set number of nodes threshold, is used to measure how many of the consensus nodes that participate in archiving remain available. With continued reference to Table 3, an archive index (ArchiveID), individual consensus nodes (partitients), a third number (partitientNum), and a first Threshold (Threshold) are recorded accordingly in the archive contract.

At step 440, a first status flag is used to indicate the status of the archiving task. The first status flags include a first wait state (Waiting), an archive completion state (Applied), an archive recovery state (Recovered), an archive Abort state (Abort). With continued reference to Table 3, the first Status flag (Status 1) in the archive contract is set to a first wait state (Waiting).

TABLE 3 Table 3

Note that in addition to the parameters involved in steps 410-440, the target consensus node corresponding to the archive index, and the repartition mark, the archive times may also be recorded in the archive contract. The target consensus node is the consensus node initiating the filing task. The repartitioning flag refers to whether the availability of the consensus nodes participating in archiving meets the requirements. The repartition mark comprises a first value and a second value. The first value indicates that the target sub-block needs to be regenerated for the target block. The second value indicates that no target sub-block needs to be regenerated for the target block. With continued reference to Table 3, an archive index (ArchiveID), target consensus node (Proposer), and repartition marker (IsAlive) are recorded accordingly in the archive contract.

The embodiment of recording each parameter in the archiving contract has the advantages that each parameter can be conveniently queried from the archiving contract based on the archiving index, and the processing efficiency is improved.

In another embodiment, referring to Table 4, the archive contract also maintains the archive times. The number of archives is incremented in the archival contract. For example, the target consensus node has performed two archives, the first archives having a start block of 1000 and a stop block of 2000; the starting block mark of the second archiving is 3000, and the ending block mark is 5000; the number of archives in the archive contract is 2.

TABLE 4 Table 4

After determining the target block to archive in step 310, a first number of target sub-blocks is generated based on the target block in step 320.

Specifically, the first number of target sub-blocks includes a second number of first sub-blocks into which the target block is divided, the first number being greater than the second number. It should be noted that, in the embodiment of the present disclosure, the target block is converted into the first number of target sub-blocks based on the erasure code principle, and compared with the direct blocking of the target block, the tolerance to the situation of exiting the common node and losing data of the common node is enhanced.

In step 330, a first number of target sub-blocks are distributed to individual consensus nodes in the federated chain consensus network for archiving and deleting target blocks from the blockchain.

Note that each consensus node in the federated chain consensus network comprises a target consensus node, that is, the target consensus node distributes the first number of target sub-blocks to each consensus node archive, including itself. The target consensus node deletes the target block from the blockchain after the distribution is completed. Therefore, the target consensus node only needs a small amount of storage space for storing few target sub-blocks, and compared with storing complete target blocks, the target consensus node saves the storage space and improves the utilization rate of storage resources.

In an embodiment, after step 330, the federated chain archiving method of an embodiment of the present disclosure further includes: the state update interface of the archive contract on the blockchain is invoked to place a first state flag in the archive contract into an archive complete state. For example, referring to table 3, the first Status flag (Status 1) in the archive contract is set to the archive complete Status (Applied). Thus, if the first state in the filing contract is inquired to be marked as the filing completion state, the filing task of the target block is successfully completed, and the state of the filing task is timely detected.

In step 340, in response to the recovery request for obtaining the target block, the target sub-block is requested from each consensus node, and if a second number of target sub-blocks are received, the second number of first sub-blocks are recovered based on the second number of target sub-blocks, thereby combining the target block.

Specifically, the recovery request is a request directed to the target consensus node to apply for recovery of the target block. The target consensus node requests target sub-blocks from the respective consensus nodes in response to the recovery request. Note that each consensus node here includes a target consensus node. It should be noted that, the consensus nodes in the federated chain consensus network may exit or fail, so each consensus node in step 340 is not necessarily the same as each consensus node in step 320, which results in that the original first number of target sub-blocks may not necessarily be completely reclaimed. However, since the embodiments of the present disclosure generate the target block into the first number of target sub-blocks based on the erasure code principle, and the first number of target sub-blocks includes the second number of first sub-blocks into which the target block is divided, the first number is greater than the second number. Thus, if a second number of target sub-blocks can be received, the second number of first sub-blocks can be restored based on the second number of target sub-blocks, thereby combining the target blocks.

In an embodiment, after step 340, the federated chain archiving method of an embodiment of the present disclosure further includes: the state update interface of the archive contract on the blockchain is invoked to place a first state flag in the archive contract into a recovery state. For example, referring to table 3, the first Status flag (Status 1) in the archive contract is set to the archive complete Status (Recovered). Thus, if the first state mark in the filing contract is queried to be the recovery state, the target block is recovered, and the state of the filing task is timely detected.

Through steps 310-340 described above, embodiments of the present disclosure do not rely on archiving archive nodes in a federated chain consensus network, thus mitigating the impact of archive node centralization in a federated chain consensus network. Even when the archiving node is down, the target block is divided into the sub-blocks to be backed up to each consensus node in the embodiment of the present disclosure, and the target block can still be restored when the target block needs to be restored, and the expansion of the second number into the first number of sub-blocks perfectly relieves the influence caused by the possible exit of the consensus nodes in the federation chain consensus network, so that the security of the archiving block restoration is greatly improved.

The above is a general description of steps 310-340. Since the specific implementation of step 310 is already detailed above, a detailed description will be developed below for the specific implementation of steps 320-340.

Detailed description of step 320

In step 320, a first number of target sub-blocks is generated based on the target block.

It should be noted that the target block may be one target block or a plurality of consecutive target blocks. In an embodiment, whether one target block or a plurality of consecutive target blocks, a first number of target sub-blocks is generated by the target consensus node on a per target block basis.

Considering that processing a plurality of consecutive target blocks by a target consensus node requires a significant amount of processing resources, in one embodiment, consecutive target blocks are allocated to each consensus node.

In particular implementations of this embodiment, referring to fig. 5, step 320 includes:

step 510, allocating a plurality of consecutive target blocks to respective consensus nodes such that a first number of target sub-blocks are generated by each consensus node based on the target blocks allocated by the consensus nodes.

The advantage of this embodiment is that the processing pressure of the target consensus node is shared by the respective consensus nodes, saving the processing resources of the target consensus node.

In one embodiment, referring to FIG. 6, step 510 comprises:

step 610, determining, for each target block, a first remainder of modulo operation of the first identification number and the third number of the target block;

step 620, the target block is allocated to the consensus node having the second identification number corresponding to the first remainder.

At step 610, the third number is the number of consensus nodes of the federated chain consensus network at the time the target sub-block was distributed.

It should be noted that, the target consensus node may call the start interface of the archive contract, initiate an allocation task, and specify the starting first identification number and the ending first identification number of the allocation task at this time. When the task is allocated to be executed, the archive contract automatically fills the fields of an archive index ArchiveID, each consensus node Particians, a third number ParticiantNum and the like. And establishing point-to-point connection between every two of all consensus nodes in the alliance chain consensus network, and starting to execute the allocation task. Let m total nodes, i.e. the third number, be m. And each consensus node obtains a second identification sequence number of the consensus node according to the ordering in the partial array recorded in the filing contract. For any target block with the first identification sequence number within the [ start first identification sequence number, end first identification sequence number ] interval, the target block with the first identification sequence number h is allocated to the common node with the second identification sequence number r to make a target sub-block, wherein r=h mod m.

For example, referring to fig. 7, the federated chain consensus network includes consensus node 0, consensus node 1, and consensus node 2, then the third number is 3. Assume that the consecutive target blocks are 6 consecutive target blocks, and the first identification number of the target blocks is 1-6. For target block 1, the first remainder is 1. For target block 2, the first remainder is 2. For target block 3, the first remainder is 0. For target block 4, the first remainder is 1. For target block 5, the first remainder is 2. For target block 6, the first remainder is 0.

In step 620, the target block is assigned to a consensus node having a second identification number corresponding to the first remainder. The second identification number of the consensus node 0 is 0, the second identification number of the consensus node 1 is 1, and the second identification number of the consensus node 2 is 2. With continued reference to fig. 7, target block 1 is assigned to consensus node 1, target block 2 is assigned to consensus node 2, target block 3 is assigned to consensus node 0, target block 4 is assigned to consensus node 1, target block 5 is assigned to consensus node 2, and target block 6 is assigned to consensus node 0.

It will be appreciated that each common node will likely be allocated to a plurality of target blocks, but when generating a first number of target sub-blocks, the first number of target sub-blocks is generated on a per target block basis.

The advantage of the embodiment of steps 610-620 is that the poll system allocation is implemented based on the first remainder obtained by the modulo operation, so that each consensus node can be ensured to have the possibility of being equally allocated to the target block, and the allocation fairness is improved.

In one embodiment, referring to fig. 8, step 320 comprises:

step 810, dividing the target block into a second number of first sub-blocks to form a first sub-block vector;

step 820, obtaining a first weight matrix;

step 830, multiplying the first weight matrix with the first sub-block vector to obtain a target sub-block vector, where the target sub-block vector includes a first number of target sub-blocks.

For each target block, the target consensus node serializes it, then divides it into a second number of first sub-blocks, and forms a first sub-block vector from the second number of first sub-blocks, step 810. For example, referring to fig. 9A, the target block is divided into k first sub-blocks including a first sub-block D ₁ First sub-block D ₂ Third party the third sub-block D _k . The first sub-block vector formed based on the k first sub-blocks is then a vector of dimension k x 1. Assuming k=5, the first sub-block vector is a 5*1-dimensional vector, e.g., the first sub-block vector is [ D ] ₁ ,D ₂ ,D ₃ ,D ₄ ,D ₅ ] ^T 。

In step 820, the first weight matrix is the same as the first weight matrix recorded in table 3, and each refers to a matrix that generates a first number of target sub-blocks based on the target block. The first weight matrix has a first number of rows and a second number of columns, and the first second number of rows of the first weight matrix form an identity matrix. The parameters of the second number +1 of rows to the first number of rows need to be self-defined by the consensus node. For example, referring to FIG. 9B, the first weight matrix M is { [1, 0], [0,1, 0], [0,

0,0,1],[M ₁₁ ,M ₁₂ ,...,...,M _1k ],...,...,[M ₂₁ ,M ₂₂ ,...,...,M _2k ],[M _z1 ,M _z2 ,...,...,M _zk ]}. The first weight matrix has k+z rows and k columns, and the first k rows form an identity matrix, which needs to be customized M ₁₁ To the point ofAnd a total of z x k parameters. Assuming k=5, z is equal to 3, and M ₁₁ To M ₃₅ A total of 3*5 parameters are { [1,2,3,4, 5]]，[2,3,4,5,1],[3,4,5,1,2]}. As shown in FIG. 9B, the first weight matrix M is { [1,0],[0,1,0,0,0],[0,0,1,0,0],[0,0,0,1,0],[0,0,0,0,1],[1

,2,3,4,5],[2,3,4,5,1],[3,4,5,1,2]}. It will be appreciated that z may be equal to k.

It should be noted that the parameters from the second number of +1 rows to the first number of rows may be set at will, but it is necessary to ensure that the first weight matrix is a reversible matrix.

In one embodiment, step 820 includes: based on the archive index, a first weight matrix corresponding to the archive index is obtained in the archive contract. Referring to table 3, after step 310, an archive index (archeveid) and a first weight Matrix (Matrix) are recorded into an archive contract. Thus, in step 820, a first weight Matrix (Matrix) may be obtained from the archive contract based on the archive index (archeveid).

In step 830, the first weight matrix is multiplied by the first sub-block vector to obtain a target sub-block vector, the target sub-block vector comprising a first number of target sub-blocks. For example, referring to fig. 9C, the first weight matrix M is multiplied by the first sub-block vector D to obtain a target sub-block vector D ₁ ,D ₂ ,D ₃ ,D ₄ ,D ₅ ,D ₆ ,D ₇ ,D ₈ ] ^T . Wherein D is ₆ =D ₁ +2*D ₂ +3*D ₃ +4*D ₄ +5*D ₅ ，D ₇ =2*D ₁ +3*D ₂ +4*D ₃ +5*D ₄ +1*D ₅ ，D ₈ =3*D ₁ +4*D ₂ +5*D ₃ +

1*D ₄ +2*D ₅ 。

The advantage of the embodiment of steps 810-830 is that the generation of the first number of target sub-blocks is achieved by means of the first weight matrix, and the parameters in the first weight matrix can be flexibly set, which increases the flexibility of generating the first number of target sub-blocks.

Detailed description of step 330

In one embodiment, referring to fig. 10, step 330 includes:

step 1010, determining, for each target sub-block, a second remainder of modulo operation of a third identification sequence number and a third number of the target sub-block;

and 1020, distributing the target sub-block to a consensus node with a second identification sequence number corresponding to the second remainder for archiving.

At step 1010, the third number is the number of consensus nodes of the federated chain consensus network at the time the target sub-block was distributed.

It should be noted that any consensus node in the federation chain consensus network may call the start interface of the archive contract, initiate a distribution task, and specify the start third identification number and the end third identification number of the distribution task at this time. The consensus node makes one target block into 2k target sub-blocks, and assigns the jth target sub-block to the jth node, with g=j mod m.

For example, referring to fig. 11A, the federated chain consensus network includes consensus node 0, consensus node 1, and consensus node 2, then the third number is 3. Assuming that a plurality of consecutive target blocks are 6 consecutive target blocks, target block 3 and target block 6 are allocated for consensus node 0. The consensus node 0 generates 4 target subblocks for the target block 3, including a target subblock 3.1, a target subblock 3.2, a target subblock 3.3, and a target subblock 3.4, for the target block 3. Correspondingly, the second remainder of target sub-block 3.1 is 1, the second remainder of target sub-block 3.2 is 2, the second remainder of target sub-block 3.3 is 0, and the second remainder of target sub-block 3.4 is 1. The consensus node 0 generates 4 target sub-blocks for the target block 6, including target sub-block 6.1, target sub-block 6.2, target sub-block 6.3, and target sub-block 6.4, for the target block 6. Correspondingly, the second remainder of target sub-block 6.1 is 1, the second remainder of target sub-block 6.2 is 2, the second remainder of target sub-block 6.3 is 0, and the second remainder of target sub-block 6.4 is 1.

In step 620, the target sub-block is distributed to a consensus node archive having a second identification number corresponding to the second remainder. The second identification number of the consensus node 0 is 0, the second identification number of the consensus node 1 is 1, and the second identification number of the consensus node 2 is 2. With continued reference to fig. 11A, the target block 3.1 is assigned to consensus node 1, the target block 3.2 is assigned to consensus node 2, the target block 3.3 is assigned to consensus node 0, and the target block 3.4 is assigned to consensus node 1. The target block 6.1 is allocated to the consensus node 1, the target block 6.2 is allocated to the consensus node 2, the target block 6.3 is allocated to the consensus node 0, and the target block 6.4 is allocated to the consensus node 1.

In one example, as shown in FIGS. 9A-9C, 8 target sub-blocks are generated based on a target block, specifically including D ₁ ,D ₂ ,D ₃ ,D ₄ ,D ₅ ,D ₆ ,D ₇ ,D ₈ . Referring to FIG. 11B, assume that the target consensus node generates a target sub-block D based on the target block ₁ -D ₈ . Target subblock D is set at target consensus node ₁ -D ₈ After archiving distributed to the consensus node with the second identification number corresponding to the second remainder, consensus node 0 obtains D ₃ And D ₆ The consensus node 1 obtains D ₁ 、D ₄ And D ₇ The consensus node 2 obtains D ₂ 、D ₅ And D ₈ 。

The advantage of the embodiment of steps 1010-1020 is that the poll system distribution is realized based on the second remainder obtained by the modulo operation, so that each consensus node can be ensured to have the possibility of being equally distributed to the target sub-block, and the distribution fairness is improved.

Detailed description of the steps between step 330 and step 340

It should be noted that, after step 330, the target consensus node has deleted the target block on the blockchain. If the target consensus node needs to restore the target block, a request is required to the consensus node distributed to the target sub-blocks, so as to restore the target block according to the received second number of target sub-blocks. However, if the consensus node is in an unavailable state, for example, a certain consensus node exits the federated chain consensus network or fails, the target consensus node is caused to fail to receive a sufficient second number of target sub-blocks, thereby resulting in failure to recover the target block. Thus, in one embodiment, to ensure that the target block can be restored, it is necessary to detect the availability of consensus nodes in a timely manner.

In this embodiment, referring to fig. 12, before step 340, the federation chain archiving method of this embodiment further includes:

step 1210, identifying availability of a third number of consensus nodes;

step 1220, determining a first ratio of the number of available consensus nodes to the third number of consensus nodes;

step 1230, if it is determined that the first ratio is lower than the first threshold, requesting target sub-blocks from each consensus node in the federated chain consensus network, recovering the second number of first sub-blocks based on the received second number of target sub-blocks, thereby combining the target blocks, and returning to the step of generating the first number of target sub-blocks based on the target blocks.

At step 1210, availability is used to indicate whether the consensus node is available. Availability includes an available state or a non-available state. If the consensus node is in an available state, the consensus node is an available consensus node. If the consensus node is in a non-available state, the consensus node is a non-available consensus node. For example, referring to fig. 13, the third number is 3, and there are 3 consensus nodes in the federated chain consensus network. The availability of 3 consensus nodes, namely the availability of consensus node 0, consensus node 1, and consensus node 2, is identified. After identifying availability, the availability of the consensus node 2 is found to be in a non-available state, and the available consensus nodes remain consensus node 0, and consensus node 1.

In one embodiment, step 1210 includes: availability of each consensus node in the archive contract corresponding to the archive index is identified. The benefit of this embodiment is that individual consensus nodes can be quickly determined by querying an archive contract with an archive index, thereby improving the efficiency of determining availability.

In step 1220, the first ratio refers to a ratio of the number of available nodes to the third number. The number of available nodes refers to the number of available consensus nodes.

In one embodiment, step 1220 includes: a first ratio of the number of available consensus nodes to a third number corresponding to an archive index in an archive contract is determined. A benefit of this embodiment is that the third number can be quickly determined by querying the archive contract with the archive index, thereby improving the efficiency of determining the first ratio.

For example, with continued reference to fig. 13, after determining that the available consensus nodes remain consensus node 0, and consensus node 1, the available node number is obtained as 2. Since the third number is 3, the first ratio is 2/3.

In one embodiment, referring to fig. 14, the first threshold is determined by:

step 1410, determining a second ratio of the second number to the first number;

step 1420, adding a redundancy value of the ratio based on the second ratio, resulting in a first threshold.

In this embodiment, it is assumed that the first number is 2k, the second number is k, and the second ratio is 50%. Below 50%, half of the consensus nodes that initially participated in archiving are said to be exited. The remaining target sub-blocks provided by the remaining consensus nodes are not sufficient to restore the target block. Thus, 70% can be set, leaving a redundancy amount. And cannot wait until less than 50% recovery.

The benefit of the embodiment of steps 1410-1420 is that by adding a redundancy amount to the ratio, ensuring that the first ratio is below the first threshold, the recovery and repartition of the target block can be triggered, ensuring that the target block can be recovered normally.

If the first ratio is determined to be lower than the first threshold, then it is indicated that there are consensus nodes in the federated chain consensus network that are not available and that re-blocking is required, otherwise the target block may not be restored. Thus, after determining that the first ratio is below the first threshold, the target consensus node requests target sub-blocks from each consensus node in the federated chain consensus network, recovers a second number of first sub-blocks based on the received second number of target sub-blocks, thereby combining target blocks, and returns to step 320.

In one embodiment, step 1230 includes: the first ratio is determined to be below a first threshold corresponding to an archive index in an archive contract. A benefit of this embodiment is that the archive contract may be queried quickly to determine the first threshold using the archive index, thereby improving the efficiency of determining that the first ratio is below the first threshold.

For example, with continued reference to FIG. 13, the target consensus node requests target sub-blocks from consensus node 0 and consensus node 1 in the federated chain consensus network. Consensus node 0 archives target subblocks D ₃ And D ₆ The consensus node 1 is filed with a target subblock D ₁ 、D ₄ And D ₇ . The target consensus node may receive the target sub-block D ₁ 、D ₃ 、D ₄ 、D ₆ 、D ₇ Then based on the received target subblock D ₁ 、D ₃ 、D ₄ 、D ₆ 、D ₇ Obtaining a target block. Finally, step 320 is returned.

The benefit of this embodiment of steps 1210-1230 is that by detecting the availability of the consensus node, recovery and re-blocking of the target block can be triggered, ensuring that the target block is not lost due to unavailability of the consensus node, improving data security.

In one embodiment, referring to fig. 15, step 1210 comprises:

step 1510, calling a query interface of an archive contract on the blockchain, querying a federation chain management contract to determine a consensus node in a federation chain consensus network when obtaining a recovery request of the target block;

Step 1520, obtain a third number of consensus nodes, intersection with the consensus nodes in the federated chain consensus network at the time of the recovery request for the target block, as available consensus nodes.

In this embodiment, a federation chain management contract refers to a contract that enables to obtain consensus nodes in a federated chain consensus network. By querying the federation chain management contract, a consensus node in the federation chain consensus network can be obtained when a recovery request for a target block is obtained. For example, referring to FIG. 16, the target consensus node determines that the federation chain consensus network exists { consensus node 0, consensus node 1, consensus node 2} when distributing the target sub-block. However, when the target consensus node invokes the query interface of the archive contract on the blockchain, querying the federation chain management contract, consensus node 2 is already unavailable. Thus, the target consensus node determines that { consensus node 0, consensus node 1} is present when the recovery request for the target block is acquired. From the intersection of { consensus node 0, consensus node 1, consensus node 2} and { consensus node 0, consensus node 1} it is determined that the available consensus nodes include consensus node 0, and consensus node 1.

The advantage of the embodiment of steps 1510-1520 is that the available consensus nodes can be quickly determined based on the intersection between the consensus node when the target sub-block is distributed and the consensus node when the recovery request is obtained, improving the processing efficiency.

In one embodiment, referring to FIG. 17, step 1230 comprises:

step 1710, if it is determined that the first ratio is lower than the first threshold, setting a repartition mark in the archive contract to the first value through the query interface;

step 1720, querying a repartition flag in the archive contract to request a target sub-block from each consensus node in the federated chain consensus network when the repartition flag is a first value.

At step 1710, the repartition flag includes a first value and a second value, the first value indicating that the target sub-block needs to be regenerated for the target block. For example, referring to Table 3, the repartition mark (IsAlive) in the archive contract is set to a first value, either 0 or false, by the query interface.

At step 1720, a target sub-block is requested from each consensus node in the federated chain consensus network, e.g., if the re-blocking flag is queried, e.g., if the first value is false.

The benefit of this embodiment of steps 1710-1720 is that by directly detecting whether the repartition flag is a first value, the detection efficiency is greatly improved compared to the need to compare the first ratio to the first threshold value to determine whether to repartition.

Referring to FIG. 18, in one embodiment, the repartition mark is recorded in an archive contract corresponding to an archive index, step 1720 comprising:

Step 1810, generating a query transaction every predetermined period, and determining a third remainder of modulo operation of a summary value of the query transaction and the total number of files;

step 1820, using the third remainder as the archive index, calling a query interface, and querying the repartition mark corresponding to the archive index in the archive contract.

In this embodiment, the predetermined period refers to a time period set in advance by the target consensus node. For example, the predetermined period is 2 hours, or 4 hours, etc. A query transaction refers to a transaction generated by a consensus node that queries for an archiving task. Note that. The consensus nodes in the alliance chain consensus network are all qualified to check the target blocks of history archiving, and the embodiment designs a spot check scheme based on the transaction abstract value, which specifically comprises the following steps: each consensus node operates an independent process, and each predetermined period is used for constructing a query transaction, calling a query interface of an archive contract, and determining an archive index of the spot check by using a third remainder (the third remainder is equal to the remainder of modulo operation of the abstract value of the transaction and the archive times ArchiveNum). If the re-blocking flag of the archive record becomes false in the current query, a target sub-block is requested from each consensus node in the federated chain consensus network.

The benefit of this embodiment of steps 1810-1820 is that the query re-blocking flag of the round robin system may be implemented based on the manner in which the re-blocking flag of the archive index corresponding to the third remainder query increases the flexibility of the query.

Detailed description of step 340

In one embodiment, referring to fig. 19, step 340 includes:

step 1910, acquiring an archive index;

step 1920, based on the archive index, acquiring a start block identifier and an end block identifier corresponding to the archive index in the archive contract;

step 1930, taking the block between the start block identifier and the end block identifier as the target block, and generating a recovery request of the target block.

In step 1910, the archive index may be obtained by performing a modulo operation on the summary value of the query transaction and the third remainder of the archive count in the above embodiment, or may be obtained by randomly selecting one from a plurality of historical archive indexes as the archive index by the target consensus node. For example, referring to fig. 20, an archive index of 001 is obtained.

In step 1920, a start block identification and an end block identification corresponding to the archive index are recorded in the archive contract. For example, with continued reference to fig. 20, the archive contract records a start block identification of 5 and an end block identification of 10 corresponding to the archive index 001; the start block identifier corresponding to the archive index 002 is 15, and the end block identifier is 30. Assuming that the archive index is 001, a start block identification of 5 and an end block identification of 10 may be obtained from the archive contract.

In step 1930, for example, with continued reference to fig. 20, the block between the start block identification of 5 and the end block identification of 10 is taken as the target block, and a recovery request for the target block is generated. Note that the target blocks here are specifically 6 consecutive target blocks.

The benefit of the embodiment of steps 1910-1930 is that the starting block identification and the ending block identification can be quickly determined from the archive contract based on the archive index, improving the determination efficiency and thus the processing efficiency of generating a recovery request for the target block.

In the above embodiment, the target consensus node directly requests the target sub-block from each consensus node after acquiring the recovery request. In another embodiment, however, the federated chain consensus network further includes an archiving node that archives the blocks after the plurality of consensus nodes have completed consensus on the blocks to be recorded onto the blockchain. In this embodiment, since the archive node has block data stored therein, the target consensus node may also request the target block from the archive node.

In particular implementations of this embodiment, after step 310, the federated chain archiving method of an embodiment of the present disclosure further includes: invoking a state update interface in an archive contract on the blockchain, and setting a second state flag in the archive contract to a second waiting state; determining that the archiving node is successfully archived in response to the second waiting state being changed to the confirmation state, wherein the confirmation state is set by the archiving node after the second state flag is recognized to be changed to the second waiting state, the integrity of the target block on the block chain is detected and the detection is successful;

correspondingly, step 340 includes: the target block is requested from the archiving node, and the target sub-block is requested from each consensus node when the request fails.

In particular, the second status flag is used to indicate the status of the archiving node for the archiving of the block. The second status flag includes a second Waiting status (Waiting), an acknowledge status (Applied). Referring to Table 5, a Status update interface in an archive contract on the blockchain is invoked, setting a second Status flag (Status 2) in the archive contract to a second wait state (Waiting). The archiving node detects the integrity of the target block on the blockchain and sets the second status flag to the validation state after the detection is successful. The target consensus node determines that archiving by the archiving node is successful in response to the second wait state changing to the acknowledgement state.

TABLE 5

After the target consensus node determines that the archiving node has completed archiving the target block, the target block is first requested from the archiving node when the target block needs to be requested at step 340. If the request can be successful, no request needs to be made to each consensus node. However, if the request fails, the target sub-block needs to be requested from each consensus node, so as to recover the target block according to the target sub-block. For example, referring to FIG. 21, the federated chain consensus network includes two archive nodes, archive node 0 and archive node 1, respectively. The target consensus node firstly requests the target blocks from the archiving node 0 and the archiving node 2, and in the case of failure of the request, the target consensus node requests the target sub-blocks from the consensus node 0, the consensus node 1 and the consensus node 2.

The embodiment for requesting the target blocks by means of the archiving node has the advantages that on one hand, the archiving node archives the whole target blocks, and under the condition that the archiving node works normally, the target consensus node can request the target blocks from the archiving node, and the target sub-blocks are not required to be acquired from all consensus nodes each time and then the target blocks are restored, so that the restoration efficiency of the target blocks is greatly improved. On the other hand, even if the archiving node fails, the request fails, the embodiment can acquire the target sub-blocks from each consensus node and then recover the target blocks, thereby relieving the defect of centralized recovery of the archiving node and improving the block recovery security.

In one embodiment, the archive node is a plurality of archive nodes, the archive contract records a target archive node bound to the target consensus node, the target archive node belongs to the plurality of archive nodes, and the validation state is set by the target archive node.

In particular implementations of this embodiment, step 340 includes:

querying a target archiving node of an archiving contract record;

the target archive node is requested for a target block, and when the request fails, each consensus node is requested for a target sub-block.

In this embodiment, referring to FIG. 22, the target consensus node queries the archive contract, and since the target archive node in the archive contract that records the binding is archive node 0, the target archive node is obtained as archive node 0. Then, the target consensus node requests the target block from the archive node 0, and requests the target sub-block from each consensus node when the request fails.

The benefit of this embodiment is that even if there are multiple archive nodes in the federated chain consensus network, once a target consensus node fails to request a bound target archive node, it does not request other archive nodes any more, but requests target sub-blocks directly from each consensus node, which can alleviate the impact of the collective failure of the archive nodes.

In one embodiment, referring to fig. 23, step 340 comprises:

step 2310, generating a second sub-block vector based on the second number of target sub-blocks;

step 2320, obtaining, from the first number of rows of the first weight matrix, a second number of rows multiplied by the second number of target sub-blocks as a second weight matrix when the first weight matrix is multiplied by the first sub-block vector;

step 2330, recovering the first sub-block vector based on the second sub-block vector and the second weight matrix, and obtaining a second number of first sub-blocks from the first sub-block vector.

At step 2310, the second number of target sub-blocks is part of the first number of target sub-blocks. For example, referring to fig. 24A, there is a consensus node 0, a consensus node 1, and a consensus node 2 in the federated chain consensus network. Wherein the consensus node 0 is filed with a target subblock D ₃ And D ₆ The consensus node 1 is filed with a target subblock D ₁ 、D ₄ And D ₇ The consensus node 2 is filed with D ₂ 、D ₅ And D ₈ . After the target consensus node requests the target subblocks from the respective consensus nodes, the target consensus node may receive the target subblock D due to the availability of the consensus node 2 being in an unavailable state ₁ 、D ₃ 、D ₄ 、D ₆ 、D ₇ . Then based on the target subblock D ₁ 、D ₃ 、D ₄ 、D ₆ 、D ₇ The second sub-block vector generated is [ D ] ₁ ，D ₃ ，D ₄ ，D ₆ ，D ₇ ] ^T 。

In step 2320, the second weight matrix is part of the first weight matrix, which is a matrix used to recover the second number of target sub-blocks out of the second number of first sub-blocks.

In an embodiment, prior to step 2320, the federated chain archiving method of this embodiment further includes: according to the archiving index, a first weight matrix corresponding to the archiving index is acquired in the archiving contract. Referring to table 3, the first weight matrix is recorded in the archive contract together with the archive index, and thus the target consensus node can acquire the first weight matrix corresponding to the archive index from the archive contract. The method has the advantages that the first weight matrix can be quickly acquired by utilizing the records in the archiving contract, and the acquisition efficiency of the first weight matrix is improved, so that the acquisition efficiency of the second weight matrix is improved.

For example, referring to fig. 24B, the first number is 8, the second number is 5, and the first weight matrix is a matrix of 8 rows and 5 columns. The first weight matrix M is { [1, 0], [0,1, 0], [0,1, 0]

,[0,0,0,1,0],[0,0,0,0,1],[1,2,3,4,5],[2,3,4,5,1],[3,4,5,1,2]}. Since 5 target subblocks are received as D ₁ 、D ₃ 、D ₄ 、D ₆ 、D ₇ Therefore, the 1 st row, the 3 rd row, the 4 th row, the 6 th row and the 7 th row are required to be obtained from the first weight matrix, and the second weight matrix is obtained as { [1,0 ],[0,0,1,0,0],[0,0,0,1,0],[1,2,3,4,5],[2,3,4,5,1]}。

In step 2330, the first sub-block vector is restored based on the second sub-block vector and the second weight matrix, and a second number of first sub-blocks are obtained from the first sub-block vector. Specifically, the first sub-block vector is obtained by multiplying the second sub-block vector by an inverse matrix of the second weight matrix. The principle is as follows:

formula (3)

Formula (4)

Wherein, the liquid crystal display device comprises a liquid crystal display device,representing a second sub-block vector, ">Representing a second weight matrix,/->An inverse matrix representing a second weight matrix, < +.>Representing a first sub-block vector. The method for solving the inverse matrix of the second weight matrix may be based on a concomitant matrix method, an elementary conversion method, or the like, and the present embodiment is not particularly limited.

For example, with continued reference to FIG. 24C, based on the second weight matrix being { [1, 0], [0,1, 0], [0,1, 0], [1,2,3,4,5], [2,3,4,5,1] } to obtain a second weight rectangle with an inverse matrix of { [1, 0], [ -1/2, -3/2, -9/2,1, -1/2], [0,1, 0]

,[0,0,1,0,0],[-1/2,1/2,17/2,-2,3/2]}. Multiplying the inverse matrix based on the second weight matrix with the second sub-block vector to obtain a first sub-block vector [ D ] ₁ ，D ₂ ，D ₃ ，D ₄ ，D ₅ ] ^T 。

Implementation detail diagram of alliance chain archiving method of embodiment of the disclosure

Details of implementation of the federated chain archiving method of embodiments of the present disclosure are illustrated in detail below with reference to FIG. 25.

At step 2510, the target consensus node determines a target block to archive on a blockchain maintained by the target consensus node;

in step 2520, the target block is divided into a second number of first sub-blocks to form a first sub-block vector, the first weight matrix is obtained, and the first weight matrix is multiplied by the first sub-block vector to obtain a target sub-block vector, wherein the target sub-block vector comprises a first number of target sub-blocks;

at step 2530, distributing a first number of target sub-blocks to individual consensus nodes in the federated chain consensus network for archiving and deleting target blocks from the blockchain;

in step 2540, in response to a recovery request to acquire a target block, requesting the target block from an archiving node;

in step 2550, requesting a target sub-block from each consensus node upon request failure;

if a second number of the target sub-blocks is received, generating a second sub-block vector based on the second number of target sub-blocks, step 2560; acquiring a second number of rows multiplied by a second number of target sub-blocks as a second weight matrix from the first number of rows of the first weight matrix when the first weight matrix is multiplied by the first sub-block vector; and recovering the first sub-block vector based on the second sub-block vector and the second weight matrix, and acquiring a second number of first sub-blocks from the first sub-block vector so as to combine the target block.

Advantages of this embodiment include, but are not limited to: the method can realize the centralized storage and the decentralization recovery of the archived data. Even when the archiving node is down, the target block is divided into the sub-blocks to be backed up to each consensus node in the embodiment of the present disclosure, and the target block can still be restored when the target block needs to be restored, and the expansion of the second number into the first number of sub-blocks perfectly relieves the influence caused by the possible exit of the consensus nodes in the federation chain consensus network, so that the security of the archiving block restoration is greatly improved. At the cost of certain data redundancy, all consensus nodes of the alliance chain can be ensured to recover the archived data on the premise of not depending on the archiving node. For a federation chain of n nodes, the storage overhead of (n-2)/n can be reduced after archiving (e.g., 80% storage can be reduced after archiving 10 consensus nodes).

Apparatus and device descriptions of embodiments of the present disclosure

It will be appreciated that, although the steps in the various flowcharts described above are shown in succession in the order indicated by the arrows, the steps are not necessarily executed in the order indicated by the arrows. The steps are not strictly limited in order unless explicitly stated in the present embodiment, and may be performed in other orders. Moreover, at least some of the steps in the flowcharts described above may include a plurality of steps or stages that are not necessarily performed at the same time but may be performed at different times, and the order of execution of the steps or stages is not necessarily sequential, but may be performed in turn or alternately with at least a portion of the steps or stages in other steps or other steps.

Fig. 26 is a schematic diagram of a structure of a federated chain archive 2600 provided by an embodiment of the present disclosure. A federated chain archive 2600 being located at a target consensus node of a plurality of consensus nodes of a federated chain consensus network, see fig. 26, the federated chain archive 2600 comprising:

a first determining unit 2610 for determining a target block to be archived on a block chain maintained by the target consensus node;

A first generating unit 2620 configured to generate a first number of target sub-blocks based on the target block, where the first number of target sub-blocks includes a second number of first sub-blocks into which the target block is divided, and the first number is greater than the second number;

a distribution unit 2630 for distributing the first number of target sub-blocks to respective consensus nodes in the federated chain consensus network for archiving and deleting target blocks from the blockchain;

the request unit 2640 is configured to request target sub-blocks from respective consensus nodes in response to a recovery request for acquiring the target block, and if a second number of target sub-blocks are received, recover the second number of first sub-blocks based on the second number of target sub-blocks, thereby combining the target block.

Alternatively, the first generating unit 2620 specifically functions to:

dividing the target block into a second number of first sub-blocks to form a first sub-block vector;

acquiring a first weight matrix, wherein the first weight matrix is provided with a first number of rows and a second number of columns, and the first second number of rows of the first weight matrix form an identity matrix;

Optionally, the requesting unit 2640 is further specifically configured to:

generating a second sub-block vector based on the second number of target sub-blocks;

acquiring a second number of rows multiplied by a second number of target sub-blocks as a second weight matrix from the first number of rows of the first weight matrix when the first weight matrix is multiplied by the first sub-block vector;

and recovering the first sub-block vector based on the second sub-block vector and the second weight matrix, and acquiring a second number of first sub-blocks from the first sub-block vector.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive 2600 further includes: a fourth calling unit, configured to call a starting interface of an archive contract on a blockchain, generate an archive index, and a first weight matrix corresponding to the archive index, and record the archive index into the archive contract;

the first generating unit 2620 specifically is configured to: acquiring a first weight matrix corresponding to the archive index in the archive contract based on the archive index;

the request unit 2640 is further specifically configured to, before obtaining, from the first number of rows of the first weight matrix, a second number of rows multiplied by the second number of target sub-blocks when the first weight matrix is multiplied by the first sub-block vector, as the second weight matrix: according to the archiving index, a first weight matrix corresponding to the archiving index is acquired in the archiving contract.

Optionally, the target block is a plurality of target blocks in succession, and the first generating unit 2620 is specifically configured to:

a continuous plurality of target blocks are allocated to respective consensus nodes such that a first number of target sub-blocks are generated by each consensus node based on the target blocks allocated by the consensus nodes.

Optionally, the first generating unit 2620 is further specifically configured to:

for each target block, determining a first remainder of modular operation of a first identification sequence number of the target block and a third number, wherein the third number is the number of common nodes of the alliance chain common network when distributing target sub-blocks;

and distributing the target block to a consensus node with a second identification sequence number corresponding to the first remainder.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive 2600 further includes:

a first calling unit (not shown) for calling a start interface of an archive contract on the blockchain, in which an archive index, and start block identifications and end block identifications of a plurality of consecutive target blocks are recorded correspondingly;

the request unit 2640 specifically is configured to: acquiring an archiving index; based on the archive index, a start block identifier and an end block identifier corresponding to the archive index are acquired in an archive contract, a block between the start block identifier and the end block identifier is used as a target block, and a recovery request of the target block is generated.

Optionally, the distributing unit 2630 is specifically configured to:

for each target sub-block, determining a second remainder of modulo operation between a third identification sequence number of the target sub-block and a third number, wherein the third number is the number of common nodes of the alliance chain common network when the target sub-block is distributed;

and distributing the target sub-block to a consensus node with a second identification sequence number corresponding to the second remainder for archiving.

Optionally, prior to requesting target sub-blocks from each consensus node in response to a recovery request to acquire a target block, federation chain archive apparatus 2600 further comprises:

an identification unit (not shown) for identifying availability of a third number of consensus nodes;

a second determining unit (not shown) for determining a first ratio of the number of available consensus nodes to the third number of consensus nodes;

a restoring unit (not shown) for requesting the target sub-blocks from each consensus node in the federated chain consensus network if the first ratio is determined to be lower than the first threshold, restoring the second number of first sub-blocks based on the received second number of target sub-blocks, thereby combining the target blocks, and returning to the step of generating the first number of target sub-blocks based on the target blocks.

Optionally, the recovery unit (not shown) is specifically configured to:

determining a second ratio of the second number to the first number;

and adding a ratio redundancy amount on the basis of the second ratio to obtain a first threshold.

Optionally, the identification unit (not shown) is specifically configured to:

invoking a query interface of an archive contract on the blockchain to query a federation chain management contract to determine consensus nodes in a federation chain consensus network when obtaining a recovery request of the target block;

an intersection of the third number of consensus nodes with a consensus node in the coalition chain consensus network at the time of the retrieval request of the target block is acquired as an available consensus node.

Optionally, the recovery unit (not shown) is specifically configured to:

if the first ratio is determined to be lower than a first threshold, setting a repartition block mark in the archiving contract to be a first value through a query interface, wherein the first value indicates that a target sub-block needs to be regenerated for the target block;

the repartition mark in the archive contract is queried to request a target sub-block from each consensus node in the federation chain consensus network when the repartition mark is a first value.

Optionally, the repartition mark is recorded in an archive contract corresponding to the archive index;

The recovery unit (not shown) is also specifically configured to:

and calling a query interface by taking the third remainder as an archive index, and querying a repartition mark corresponding to the archive index in the archive contract.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive 2600 further includes: a second calling unit (not shown) for calling a start interface of an archive contract on the blockchain, determining respective consensus nodes, a third number, and a first threshold in the federated chain consensus network, and recording in the archive contract corresponding to the archive index;

the identification unit (not shown) is also specifically configured to: identifying availability of each consensus node in the archive contract corresponding to the archive index;

the second determining unit (not shown) is also specifically configured to: determining a first ratio of the number of available consensus nodes to a third number corresponding to an archive index in an archive contract;

the recovery unit (not shown) is also specifically configured to: the first ratio is determined to be below a first threshold corresponding to an archive index in an archive contract.

Optionally, after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive 2600 further includes: a fifth calling unit (not shown) for calling a state update interface of the archive contract on the blockchain to set a first state flag in the archive contract to a first waiting state;

after distributing the first number of target sub-blocks to respective consensus nodes in the federated chain consensus network for archiving and deleting target blocks from the blockchain, a fifth invoking unit (not shown) is further configured to: invoking a state update interface of an archive contract on a blockchain, and setting a first state mark in the archive contract as an archive completion state;

after requesting the target sub-block from each consensus node in response to a recovery request to acquire the target block, a fifth invoking unit (not shown) is further configured to: invoking a state update interface of the archive contract on the blockchain to place a first state flag in the archive contract into a recovery state.

Optionally, the federation chain consensus network further comprises an archiving node, wherein the archiving node archives the blocks after the plurality of consensus nodes have completed consensus on the blocks to be recorded on the blockchain;

After determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archive 2600 further includes: a third invoking unit (not shown) for invoking a state update interface in the archive contract on the blockchain to place a second state flag in the archive contract into a second waiting state; determining that the archiving node is successfully archived in response to the second waiting state being changed to the confirmation state, wherein the confirmation state is set by the archiving node after the second state flag is recognized to be changed to the second waiting state, the integrity of the target block on the block chain is detected and the detection is successful;

the request unit 2640 is also specifically configured to: the target block is requested from the archiving node, and the target sub-block is requested from each consensus node when the request fails.

the request unit 2640 is also specifically configured to:

querying a target archiving node of an archiving contract record;

the target block is requested from the target archiving node.

Alternatively, the first determining unit 2610 is specifically configured to:

Referring to fig. 27, fig. 27 is a block diagram of a portion of a terminal implementing a coalition chain archiving method according to an embodiment of the present disclosure, the terminal including: radio Frequency (RF) circuit 2710, memory 2715, input unit 2730, display unit 2740, sensor 2750, audio circuit 2760, wireless fidelity (wireless fidelity, wiFi) module 2770, processor 2780, and power supply 2790. It will be appreciated by those skilled in the art that the terminal structure shown in fig. 27 is not limiting of a cell phone or computer and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.

The RF circuit 2710 may be used for receiving and transmitting signals during a message or a call, and particularly, after receiving downlink information of a base station, the signal is processed by the processor 2780; in addition, the data of the design uplink is sent to the base station.

The memory 2715 may be used to store software programs and modules, and the processor 2780 executes various functional applications of the object terminal and data processing by executing the software programs and modules stored in the memory 2715.

The input unit 2730 may be used to receive input numerical or character information and generate key signal inputs related to setting and function control of the object terminal. In particular, the input unit 2730 may include a touch panel 2731 and other input devices 2732.

The display unit 2740 may be used to display input information or provided information and various menus of the object terminal. The display unit 2740 may include a display panel 2741.

Audio circuitry 2760, speaker 2761, and microphone 2762 may provide an audio interface.

In this embodiment, the processor 2780 included in the terminal may perform the federation chain archiving method of the previous embodiment.

Terminals of embodiments of the present disclosure include, but are not limited to, cell phones, computers, intelligent voice interaction devices, intelligent home appliances, vehicle terminals, aircraft, and the like. Embodiments of the present invention may be applied to a variety of scenarios including, but not limited to, federated links, structured information processing, security techniques, data security, data storage, information techniques, and the like.

Fig. 28 is a block diagram of a portion of a server implementing a federated chain archiving method in accordance with an embodiment of the present disclosure. The servers may vary widely in configuration or performance and may include one or more central processing units (Central Processing Units, simply CPU) 2822 (e.g., one or more processors) and memory 2832, one or more storage media 2830 (e.g., one or more mass storage devices) storing applications 2842 or data 2844. Wherein the memory 2832 and storage medium 2830 may be transitory or persistent. The program stored on the storage medium 2830 may include one or more modules (not shown), each of which may include a series of instruction operations on the server. Still further, the central processor 2822 may be placed in communication with a storage medium 2830, executing a series of instruction operations in the storage medium 2830 on a server.

The server may also include one or more power supplies 2826, one or more wired or wireless network interfaces 2850, one or more input/output interfaces 2858, and/or one or more operating systems 2841, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like.

The central processor 2822 in the server may be used to perform the federated chain archiving method of embodiments of the present disclosure.

The disclosed embodiments also provide a computer readable storage medium storing program code for performing the coalition chain archiving method of the foregoing embodiments.

The disclosed embodiments also provide a computer program product comprising a computer program. The processor of the computer device reads the computer program and executes it, causing the computer device to perform the federation chain archiving method described above.

The terms "first," "second," "third," "fourth," and the like in the description of the present disclosure and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein, for example. Furthermore, the terms "comprises," "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.

It should be understood that in this disclosure, "at least one" means one or more, and "a plurality" means two or more. "and/or" for describing the association relationship of the association object, the representation may have three relationships, for example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

It should be understood that in the description of the embodiments of the present disclosure, the meaning of a plurality (or multiple) is two or more, and that greater than, less than, exceeding, etc. is understood to not include the present number, and that greater than, less than, within, etc. is understood to include the present number.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present disclosure may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present disclosure may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the various embodiments of the present disclosure. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

It should also be appreciated that the various implementations provided by the embodiments of the present disclosure may be arbitrarily combined to achieve different technical effects.

The above is a specific description of the embodiments of the present disclosure, but the present disclosure is not limited to the above embodiments, and various equivalent modifications and substitutions can be made by those skilled in the art without departing from the spirit of the present disclosure, and are included in the scope of the present disclosure as defined in the claims.

Claims

1. A federation chain archiving method, the federation chain archiving method applied to a target consensus node among a plurality of consensus nodes of a federation chain consensus network, the federation chain archiving method comprising:

2. The federation chain archiving method of claim 1, wherein the generating a first number of target sub-blocks based on the target block comprises:

3. The federation chain archiving method of claim 2, wherein the recovering a second number of the first sub-blocks based on a second number of the target sub-blocks comprises:

4. The federated chain archiving method of claim 1, wherein the target block is a continuous plurality of the target blocks;

the generating a first number of target sub-blocks based on the target block includes: a consecutive plurality of said target blocks are allocated to each of said consensus nodes, such that a first number of target sub-blocks are generated by each of said consensus nodes based on said target blocks to which said consensus nodes are allocated.

5. The federation chain archiving method according to claim 4, wherein said assigning a contiguous plurality of said target blocks to each of said consensus nodes comprises:

6. The federated chain archiving method of claim 4, wherein after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archiving method further comprises: invoking a start interface of an archive contract on the blockchain, correspondingly recording an archive index, and a start block identifier and an end block identifier of a plurality of continuous target blocks in the archive contract;

the recovery request for obtaining the target block includes: acquiring the archiving index; and based on the archiving index, acquiring the starting block identifier and the ending block identifier corresponding to the archiving index in the archiving contract, taking a block between the starting block identifier and the ending block identifier as the target block, and generating a recovery request of the target block.

7. The federation chain archiving method according to claim 1, wherein said distributing a first number of said target sub-blocks to each of said consensus nodes in said federated chain consensus network archives, comprising:

8. The federated chain archiving method of claim 7, wherein prior to requesting the target sub-block from each of the consensus nodes in response to a recovery request to acquire the target block, the federated chain archiving method further comprises:

identifying availability of a third number of said consensus nodes;

determining a first ratio of a number of available consensus nodes to a third number of the consensus nodes;

and if the first ratio is determined to be lower than a first threshold value, requesting the target sub-blocks from each consensus node in the alliance chain consensus network, recovering a second number of the first sub-blocks based on the received second number of the target sub-blocks, thereby combining the target blocks, and returning to the step of generating the first number of target sub-blocks based on the target blocks.

9. The federation chain archiving method according to claim 8, wherein the first threshold is determined by:

determining a second ratio of the second number to the first number;

10. The federation chain archiving method according to claim 8, wherein the identifying availability of a third number of the consensus nodes comprises:

11. The federation chain archiving method according to claim 10, wherein the requesting the target sub-block from each of the consensus nodes in the federated chain consensus network if the first ratio is determined to be below a first threshold comprises:

12. The federation chain archiving method according to claim 11, wherein the repartition mark is recorded in the archive contract corresponding to an archive index;

the querying the repartitioning token in the archive contract includes:

13. The federated chain archiving method of claim 8, wherein after determining the target block to archive on the blockchain maintained by the target consensus node, the federated chain archiving method further comprises: invoking a start interface of an archive contract on the blockchain, determining each of the consensus nodes, the third number, and the first threshold in the federated chain consensus network, recording into the archive contract corresponding to an archive index;

The identifying availability of a third number of the consensus nodes comprises: identifying availability of each of the consensus nodes in the archive contract corresponding to the archive index;

the determining a first ratio of the number of available consensus nodes to the third number of the consensus nodes comprises: determining a first ratio of the number of available consensus nodes to the third number corresponding to the archive index in the archive contract;

the determining that the first ratio is below a first threshold comprises: and determining that the first ratio is lower than the first threshold corresponding to the archiving index in the archiving contract.

14. The federated chain archiving method of claim 1, wherein the federated chain consensus network further comprises an archiving node, wherein the archiving node archives a block to be recorded onto the blockchain after a plurality of the consensus nodes have completed consensus for the block;

after determining the target block to be archived on the blockchain maintained by the target consensus node, the federated chain archiving method further includes: invoking a state update interface in an archive contract on the blockchain, placing a second state flag in the archive contract into a second waiting state; determining that the archiving node is successful in response to the second waiting state becoming a confirmation state, wherein the confirmation state is set by the archiving node after detecting the integrity of the target block on the blockchain and detecting success after recognizing that the second state flag becomes the second waiting state;

The requesting the target sub-block from each consensus node includes: and requesting the target block from the archiving node, and requesting the target sub-block from each consensus node when the request fails.

15. The federation chain archive method of claim 14, wherein the archive node is a plurality of the archive nodes, the archive contract records a target archive node bound to the target consensus node, the target archive node belongs to the plurality of archive nodes, and the validation state is set by the target archive node;

the requesting the target block from the archiving node includes:

querying the target archive node of the archive contract record;

requesting the target block from the target archiving node.

16. The federation chain archiving method according to claim 1, wherein the determining the target block to archive on the blockchain maintained by the target consensus node comprises:

17. A federated chain archive apparatus located at a target consensus node among a plurality of consensus nodes of a federated chain consensus network, the federated chain archive apparatus comprising:

18. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the federation chain archiving method according to any one of claims 1 to 16 when executing the computer program.

19. A computer readable storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the federation chain archiving method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program that is read and executed by a processor of a computer device to cause the computer device to perform the federation chain archiving method according to any one of claims 1 to 16.